On 2 June 2014 17:57, Nico Williams <[email protected]> wrote: > On Tue, May 13, 2014 at 3:41 AM, Dmitry Belyavsky <[email protected]> wrote: >> Here are my ideas about "strict" behaviour of the TLS client: >> >> [...] > > IMO log checking should be mostly asynchronous. This means that CT > couldn't detect MITMing CAs in real-time, but that's OK because CT is > about CA reputation, and all we care about is that when we detect > lying CAs we can report them. > > This means that clients mostly should only reject TLS connections when > there's no evidence of server certs being logged in an acceptable log. > > It also means we need some mechanism for reporting lying CAs. Thus > far reporting via blogs, news outlets, and trust anchor set managers, > has been good enough, and I'm not sure that we need anything more than > any async notification to users (and upstreams) by browsers (and other > clients). > > There are privacy protection considerations in reporting lying CAs: > report the name about which they lied, just the log entry(ies) that > are missing, or just an assertion that they lied? > > Again, as I see it CT is purely a reputation-based system. Reputation > is established (and blemished/destroyed) asynchronously.
Just to be clear here - logs do not provide reputation. They provide a mechanism by which others can establish reputation. I hope we agree on this important point! > > This is important: we cannot be adding too much latency to TLS. By > doing log checking asynchronously we won't be. Right. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
