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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf