[Trans] CT "Lite" idea (was Re: Call for adoption, draft-linus-trans-gossip-ct)

[Rob Stradling <[e-mail]>]

On 10/08/15 11:28, Ben Laurie wrote:
> On Sat, 8 Aug 2015 at 17:56 Bryan Ford <[e-mail]
> <mailto:[e-mail]>> wrote:
<snip>
>> Out of curiosity, has anyone floated or elaborated on the idea of what
>> CT would look like if simplified not to rely on SCTs at all?
>
> I believe I already mentioned that the original plan was to use
> inclusion proofs, not SCTs. CAs did not like the consequent delay in
> certificate issuance.

Gossip seeks to strengthen CT, whereas the following idea proposes a 
weaker form of CT that could be much easier to deploy in the short-term. 
  This could form part of an incremental deployment strategy towards 
"full" CT.


PROBLEM

The long-term goal is for TLS clients to be able to abort TLS handshakes 
if an insufficient number of valid SCTs (or inclusion proofs - see TRAC 
ticket #10) are provided.  To achieve this goal, we will need the vast 
majority of the TLS servers on the planet to be upgraded and/or the vast 
majority of the CAs on the planet to embed SCTs in certs and/or OCSP 
responses.

This could take years!  While we wait...


IDEA

When a TLS server sends a cert accompanied by zero SCTs / inclusion 
proofs, let the TLS client attempt to fetch and verify an inclusion 
proof (from each known log?) for each certificate encountered.
(This would require a new log API for looking up an inclusion proof by 
certificate hash).
There are 3 possible outcomes:
1. If the TLS client obtains a valid inclusion proof, then all is well.
2. If the TLS client can't obtain any responses from any logs, it should 
act as if all is well (i.e. soft-fail).
3. If the TLS client receives responses from at least 1(?) log, 
indicating that there are zero inclusion proofs for the cert in 
question, it should flag the cert (to the browser vendor?) as 
potentially not logged.

TLS clients could start behaving this way sooner rather than later, 
since the only prerequisite is that each cert must be logged.  (And of 
course adding a cert to a log is something that can be done by the CA, 
the domain owner, or indeed anyone else that encounters the cert).

If CAs are required (by browser root inclusion policies) to log all 
certs they issue, then any evidence of certs not being logged would 
prove CA misbehaviour.

Ideally the "there are zero inclusion proofs for this cert" response 
from the log would be signed by the log, so that it's possible for 
anyone who has a valid and sufficiently old SCT for that cert to prove 
log misbehaviour.

If there are a large number of logs, it might be impractical for TLS 
clients to try to fetch inclusion proofs from all of them, so there 
might need to be some sort of mechanism for figuring out which subset of 
logs should be checked.


No doubt there are rough edges in this initial proposal, but is this 
idea worth pursuing?

Or do folks feel that pursuing this idea would be too much of a 
distraction, and that we should instead focus on the long-term goal of 
getting "full" CT specified and deployed?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online