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(_dot_)Wood(_at_)surrey(_dot_)ac(_dot_)uk 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(_at_)ieca(_dot_)com; lily(_dot_)chen(_at_)nist(_dot_)gov;
alexey(_dot_)melnikov(_at_)isode(_dot_)com
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(_dot_)Wood(_at_)surrey(_dot_)ac(_dot_)uk
http://sat-net.com/L.Wood
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf