Re: [websec] A few comments on draft-ietf-websec-key-pinning

[Paul Hoffman <[e-mail]>]

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