On Wed, Jan 10, 2018 at 12:25 PM, Patrick McManus <mcmanus@ducksong.com> wrote: > > I've always viewed DNS + TLS as kind of a belt-and-suspenders kind of >> thing, where one needs to mount two (usually unrelated) exploits to >> successfully hijack an origin. I'm uncomfortable with backing down from >> that, but this might just be due to a misperception on my part: is CT >> deployed broadly enough that it provides a viable backstop against such >> attacks? (On a quick glance, I believe that zero of the ten defects I cited >> in my earlier message would have been thwarted by OCSP). >> >> /a >> > > The tradeoffs here are well tread ground by the working group. > > Chrome will be requiring CT participation for all new publicly trusted > certificates issued after April 2018. Being in a public log is currently > very common because of this and of course an ORIGIN implementation is free > to ignore ORIGIN where it doesn't feel there are sufficient suspenders in > place. > I'm not sure I agree with Adam about the tradeoffs here, but I don't really see that CT helps that much. Consider the case where the attacker gets a certificate for server A. They also get an OCSP response for A (with validity of a week or so). If they do OCSP stapling, they will be able to impersonate A for the entire duration of the OCSP response. That's a pretty significant time period. And for attackers who control the network, you get an even longer period if they block OCSP (the central revocation mechanisms used by Chrome and Safari might be partial mitigations here or might not, depending...) -Ekr > > > >
Received on Wednesday, 10 January 2018 20:52:25 UTC