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 Wood L.Wood@xxxxxxxxxxxx http://sat-net.com/L.Wood The IESG has received a request from an individual submitter to consider the following document: - 'Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms' <draft-turner-md5-seccon-update-07.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@xxxxxxxx mailing lists by 2010-12-22. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf