Wes,
I'm sympathetic to your concern, but I also think we need to specify
that this particular use needs to be "in-line" with the protocol (as
noted by Sam). How about the following changes in the introduction:
OLD:
[HASH-Attack] summarizes the use of hashes in many protocols and
discusses how attacks against a message digest algorithm's one-way
and collision-free properties affect and do not affect Internet
protocols. Familiarity with [HASH-Attack] is assumed.
NEW:
[HASH-Attack] summarizes the use of hashes in many protocols and
discusses how attacks against a message digest algorithm's one-way
and collision-free properties affect and do not affect Internet
protocols. Familiarity with [HASH-Attack] is assumed. One of the
uses of message digest algorithms in [HMAC-Attack] was integrity
protection. Where the MD5 checksum is used inline with the
protocol solely to protect against errors an MD5 checksum is still
an acceptable use. Applications and protocols need to clearly
state in their security considerations what security services, if
any, are expected from the MD5 checksum. In fact, any application
and protocol that employs MD5 needs to clearly state the expected
security services from their use of MD5.
spt
On 12/8/10 10:01 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
I think a published update to MD5 security considerations should clearly say what it's still fine to do with MD5, in addition to what it's not safe to do. This would mean adding a couple sentences, and that's about all it would really take to be clear on the issue:
"Since RFC 1321 was published, MD5 found popular use in checksuming large file transfers. This use of MD5 is still reasonable, as the level of collision resistance is of less importance in this application and MD5 may be significantly more efficient than cryptographically stronger algorithms. Communications, networking, and storage systems prone to errors (e.g. due to faulty hardware, drivers, bit-errors, faulty NAT/ALG algorithms, etc) do not implement the known MD5 collision-finding algorithms, and MD5 remains highly effective at detecting such errors."
________________________________________
From: Francis.Dupont@xxxxxxxxxx [Francis.Dupont@xxxxxxxxxx]
Sent: Wednesday, December 08, 2010 6:33 PM
To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Cc: L.Wood@xxxxxxxxxxxx; wes@xxxxxxxxxxxxxxx; iesg@xxxxxxxx; ietf@xxxxxxxx
Subject: Re: Last Call:<draft-turner-md5-seccon-update-07.txt> (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC
In your previous mail you wrote:
The logic doesn't make sense in this position. "Crypto modules
can't use MD5, thus no protocols at all should use MD5."
=> this is a silly/bad/... consequence of the crypto label
attached to the MD5 name. I understand you are not happy with
this but what do you propose?
Regards
Francis.Dupont@xxxxxxxxxx
PS: BTW I'd like to apply the argument only to *new* protocols.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf