On Dec 12, 2011, at 2:38 AM, Paul Hoffman wrote: > Greetings again. Alexey asked me to review draft-ietf-websec-key-pinning with > an eye towards which areas are likely to need more work. I hope the following > comments are helpful. > > - There needs to be an early balancing the advantages of pinning versus the > disadvantages. A description of the possible downsides should be at least > partially listed in Section 1, with a pointer to the Security Considerations. > > - Some of the significant disadvantages of pinning are not covered. The > biggest of these (although I could be wrong) is that an MITM can start using > the pinning header with a long max-age before the "real" site has used the > pinning header. When the user finally gets to the "real" site, they will not > connect to it because of the MITM's pin, giving the MITM a second attempt to > come back later. There are probably some other nasty consequences of this.
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. Maybe we can mitigate this with a version of this header (or another one) that says "no pins for the next x seconds" > > - While hash agility is a good thing, the current draft's way of doing this > is not the right way. I propose that it instead be changed to "must be > sha-256 or sha-384, and later algorithms can be added only by an RFC updating > this document". A year from now, "sha-256" is going to be ambiguous. Better to say "sha2-256". > > - The first paragraph of Section 3 should have its own sub-head to clarify > that it is not superior to the text in Section 3.1. But, more importantly, > Section 3 needs to list the areas where this protocol gives an MITM better > attacks than they have now, and should list those first. > > Early nit: The first paragraph of Section 1 makes it sound like the pinning > header "does not scale"; this is clearly not what is intended. > > --Paul Hoffman > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > > Scanned by Check Point Total Security Gateway. _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
