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 Wood
L(_dot_)Wood(_at_)surrey(_dot_)ac(_dot_)uk
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(_at_)ietf(_dot_)org mailing lists by 2010-12-22. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf