On Thu, May 1, 2014 at 7:17 AM, Daniel Kahn Gillmor <[email protected]> wrote:
>> Hopefully, when >> somebody publishes a research paper showing an improved attack on >> SHA-256 — say, preimage at a cost of 2**128 (yikes!) — we should >> immediately begin the deprecation process in anticipation of the >> attack improving to 2**80 soon. Conscientious site operators will >> observe the new spec, and update their headers, and will be ready for >> the time a year later when we say "...UAs MUST NOT honor SHA-256...". > > But in the meantime, clients which have already implemented SHA-3 (or > whatever) should be able to be protected against breaks in SHA-256, no? 2**128 is so expensive, and would be such an incredible improvement over the current cost of second-preimage attack (2**256) that frankly I'm willing to take the risk to keep the I-D from getting any more complicated. Second-preimage attack against SHA-256 is so much not our biggest problem right now — many other things are much more likely to go wrong. > It takes us a long long while to get around to deprecating things that > we know are broken. If both peers in a negotiation *can* handle > stronger mechanisms, they shouldn't have to wait for an official > deprecation of the weaker mechanism in order to get the benefit of the > stronger mechanism. First, we have to get any peers at all using HPKP. And we've been sluggish long enough (blame me first and foremost, of course). > I agree that we're talking about pretty intense hypotheticals here, but > i see no reason that we shouldn't specify the right thing in this draft > while we have the chance to provide this guidance. I'm a Worse Is Better believer, rather than a Right Thingist; especially when as far as anyone publicly knows, SHA-256 is very strong against second-preimage. We already moved to get rid of SHA-1 as a concession to the Right Thing (and, code simplification). > PS orthographic nitpick: in -12, you've got "interpretting" where i > think you mean "interpreting" Fixed, thanks. > PPS your link to [pin-break-codes] appears to be 404: > Perrin, T., "Self-Asserted Key Pinning", September 2011, > <http://trevp.net/SAKP/>. Oh yes, I believe Trevor mentioned this too. Got rid of it. https://code.google.com/p/key-pinning-draft/source/detail?r=9c118381b2b6e49384f2ea22e13247ea1c992fb9 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
