One other thing...
I guess I wonder if the "ni" URI scheme thing [1] is really useful for this or not. That was after all the reason for the earlier discussion on this list. (I think.) Note that I don't really mind if the answer is yes or no. I do think that one way to use URIs to name things via hash function outputs is a good thing, and that two or more ways to do that would be a bad thing, but not all uses of hashes to identify things need to use URIs and I'm not sure which analysis applies here. In any case, be good to decide that too. S. [1] http://tools.ietf.org/html/farrell-decade-ni-00 On 12/12/2011 12: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. - 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". - 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
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
