Sean, thanks for your reply. As you suggest, that is too many dots for people to connect. I also take issue with RFC4270's claim that: The Internet protocol community needs to migrate in an orderly manner away from SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms. which is rather broad, and entirely without the context and qualifiers we're discussing. RFC4270 was not written for a general audience, but for a security audience. The Internet _security protocol_ community may well need to migrate from these for certain uses (despite there not yet being obvious things to move _to_), but RFC4270 and your draft's sum take-away message that MD5BADDONOTUSE overstates the case. I see that RFC4270 was published in November 2005, which predates (and possibly even caused) the MD5-always-bad-don't-use-it-at-all-ever security kerfluffles that Wes and I have run into by several years. The fact that MD5 is being marked DEPRECATED by your draft, coupled by this sentence in RFC4270, _will_ lead to security types using it as justification to remove MD5 from, well, everywhere. Despite the fact that, as you say, it's still good for five of seven uses, including integrity protection (which gets a mere sentence in 4270 as the last of the seven - it's imo an area that is often neglected in protocol design). I hope you can see how your 'good for five of seven' assessment doesn't match with the messages in DEPRECATED and the quote above. We need some clear language setting the boundaries for areas of concern where MD5 should not be used, and areas where it is still considered highly useful - language that is unambiguous to both security and non-security experts. Repeating the bullet list of the seven uses, if you like, and providing a short summary of why MD5 is and is not currently considered useful in each case. RFCs are not written solely for an audience competent in security matters, and the security audience is not always as competent as it likes to believe. Some explicit text to join the dots for the readers would be helpful. thanks, L. is not claiming any particular expertise in security. On 3 Dec 2010, at 15:56, Sean Turner wrote: > On 12/1/10 5:53 PM, L.Wood@xxxxxxxxxxxx wrote: >> forwarding comments as per last call request. >> >> Lloyd Wood >> http://tinyurl.com/lloydwood-ccsr >> ________________________________________ >> From: Wood L Dr (Electronic Eng) >> Sent: 01 December 2010 07:56 >> To: turners@xxxxxxxx; lily.chen@xxxxxxxx; alexey.melnikov@xxxxxxxxx >> Cc: Wood L Dr (Electronic Eng) >> Subject: Last Call draft-turner-md5-seccon-update >> >> http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/?include_text=1 >> >> says >> >> The attacks on HMAC-MD5 do not seem to indicate a practical >> vulnerability when used as a message authentication code. >> >> or, when used for error detection, which is not discussed. >> >> MD5 is still perfectly acceptable in non-security contexts, for detecting e.g. file corruption, as in checking that the .iso disk image downloaded is good to use. >> >> I've spent a lot of time in the IETF dealing with security types who believe that, because MD5 has flaws that affect security use, it should therefore not be used at all in any context -- although it's fine in a reliability-only context and very useful for detecting errors. (This topic has derailed protocol development, and has also been the subject of more than one IETF talk.) The document should imo indicate that MD5 remains acceptable in non-security contexts, and indicate clearly and verbosely that the document is limiting its scope to security applications only, not non-security applications. Security Fear, Uncertainty and Doubt should not be allowed to spill over into non-security contexts. >> >> I understand that this issue has been raised with the authors privately previously by others, but has not been addressed. >> > > Lloyd, > > Thanks for you comments. I remember the original comment from Wes. My > response (which may have been more terse) was to add in to the draft > that familiarity with RFC 4270 (the reference to HASH-Attack in the last > paragraph of Section 1 of the md-seccon-update draft) is assumed. RFC > 4270 Section 3 says: > > Of the above methods [there are 7], only the first two > [non-repudiable signatures and digital signatures in > certificates] are affected by collision attacks, and > even then, only in limited circumstances. > > Based on the "new" #s for collision attacks and what's in RFC 4270 that > means to me that using MD5 for anything that requires collision > resistance (2 of the 7 uses) is bad but if they're using it for the > other 5 they're okay. > > Do you think that's too many dots for people to connect? > > I'm not in favor or repeating everything in RFC 4270 (i.e., I'd rather > not be verbose). > > spt Lloyd Wood L.Wood@xxxxxxxxxxxx http://sat-net.com/L.Wood _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf