On Dec 12, 2011, at 7:19 AM, Yoav Nir wrote: > > On Dec 12, 2011, at 5:06 PM, Paul Hoffman wrote: > >> >> On Dec 12, 2011, at 6:57 AM, Yoav Nir wrote: >> >>> Section 2.3 does say that pins must only be noted if they come over an >>> error-free HTTPS connection, where the chain contains the pinned SPKI. So >>> the MITM would have to be able to take over the DNS (at least for a while) >>> as in the attack described by David on 11-Dec. >> >> I don't agree that the MITM must control the DNS for this attack to work. As >> long as the MITM can intercept the TLS handshake, and the client isn't doing >> OCSP (or the MITM intercepts that too), using a rogue cert works; thus the >> rogue pinning works as well. > > The rogue cert works only if it validates. So the attacker will have to have > compromised the CA as well.
Of course. That is exactly the scenario (and pretty much the only scenario) where key pinning gives the relying party better security. > Besides, one could argue that using a certificate without OCSP or checking > the CRL is not "error-free", but that would have to be clarified. We disagree. OCSP and CRL checking only bring benefit to the relying party if a certificate is revoked. The key pinning scenario is about a rogue CA issuing a certificate they should not have. There is no revocation issue in that scenario, is there? >>> Maybe we can mitigate this with a version of this header (or another one) >>> that says "no pins for the next x seconds" >> >> That still doesn't deal with the site that hears about the pinning header >> after the MITM does. > > Agree, but it allows me to make my site safe from rogue pinning attacks now. Sure, but I don't think that is a good enough reason to argue against more information in the spec about this problem, which is what I am requesting. --Paul Hoffman _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
