On 10/08/15 11:28, Ben Laurie wrote:
On Sat, 8 Aug 2015 at 17:56 Bryan Ford <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
