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 agree that the above wording of rfc-4270 is BAD.
It should have said:
The Internet community needs to migrate in an orderly manner away from
SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms
for all security-related usages of hash functions in all protocols.
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
IMHO there is a serious defect in rfc-4270. The "integrity protection"
bullet ought to be bullet three, and MD5 is definitely _NOT_ suitable
for anything with the term "integrity" in it.
Integrity protection is terminology that is used in the
security&cryptographic area and this defect of rfc-4270 is going
to create misunderstandings.
MD5 (and SHA-1) are hash functions, and as such, they exhibit probabilistic
collisions for different inputs. MD5 is still useful for detection of
"accidental" errors due to noise or distortion, but it is not suited
to protect against intentional modification of data by an attacker.
There are other algorithms for detecting "accidental" errors, like
"ECC bits", or CRCs of various sizes, e.g.
Think of MD5 as an alternative to CRC128.
Ietf mailing list