Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct

[Tom Ritter <[e-mail]>]

I'm an author, so +1 to adopt?

I reiterate Ben's point that we don't believe this draft has privacy
problems.  (Well you can _opt in_ to having privacy problems by using
a trusted auditor, which does leak your browsing history, but that's
not the expected use case for most clients by far.  The other two
approaches are designed to be privacy preserving.)

On 24 July 2015 at 08:09, Rob Stradling <[e-mail]> wrote:
> On 24/07/15 12:09, Ben Laurie wrote:
> <snip>
>>
>>     But say we enhance CT so clients can demand STHs *with* cert
>>     inclusion proofs from the web servers they talk to - as I suggested
>>     in the meeting today, and which I believe Ben Laurie mentioned is
>>     already in the works.  Then any Web client that does this will be
>>     proactively protected from MITM attacks involving faked, forked, or
>>     otherwise bad log entries.  And the client doesn’t have to
>>     compromise its privacy by gossiping with anyone.
>
> <snip>
>>
>> 2. Our original design for CT did indeed have certs served along with an
>> STH and an inclusion proof. Unfortunately, CAs categorically rejected
>> this approach because of the latency it introduced in the certificate
>> issuance process. Personally, I think it would be a better approach. Now
>> CAs are more accepting of CT, perhaps it would be worth revisiting the
>> question with them?
>
>
> I think we need to make this approach available as an option.  We should
> retain the lower-latency option (i.e. SCTs) too though.
>
> TRAC ticket 10 already aims to do this.
>
> DV certs are typically validated and issued quickly.  For EV certs and
> name-constrained Sub-CA certs, the process can take days/weeks/months, so
> added latency in issuance may be less of a concern.
>
> When OCSP Stapling and/or the CT TLS extension are used to convey "CT
> objects" to TLS clients, the TLS server could send SCTs for the first few
> hours, then switch to sending inclusion proofs / STHs once the log has
> generated them.

I like it. I like the OCSP approach better than Certs though, because
it eliminates the requirement of "private-enough DNS" to retrieve
Inclusion Proofs in STH Pollination, and lets more privacy-concerned
clients participate in STH Pollination.  (Because an Inclusion Proof
to a STH in a cert would be a very old STH, which we could not gossip
because (over time) that STH will become rarer and rarer and probably
lead to a fingerprint.

-tom