Re: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



L.Wood@xxxxxxxxxxxx wrote:
> 
> 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
> design).

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.
   http://en.wikipedia.org/wiki/Cyclic_redundancy_check

Think of MD5 as an alternative to CRC128.



-Martin
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]