On 3 Dec 2010, at 21:40, Martin Rex wrote: > 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. That wording is better, though I would also add a qualifier on the front by saying 'away from reliance for security purposes on SHA-1 and MD-5...'. This should imo be filed as an erratum on RFC4270. >> 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, The list isn't explicitly ranked. But putting the reliability point last does say something interesting about the security mindset... if it's not a deliberate attack, it's just not interesting or worthy of note. > and MD5 is definitely _NOT_ suitable > for anything with the term "integrity" in it. That depends imo on whether "integrity" is used as a term in a security context by a security person, or by anyone else. (I am not using the term as a security person, but have been forced to use it when talking to security people who have little notion of protection against errors or of reliability.) > Integrity protection is terminology that is used in the > security&cryptographic area and this defect of rfc-4270 is going > to create misunderstandings. Yes. We've actually run into this problem previously, and had to carefully use the terms when talking to those who focus on terminology used, rather than the overall point that is trying to be made. This leads to verbal gyrations and a degree of doubletalk. 'Integrity' and 'protection' do have meanings outside security, and were used long before their specific use in a security context (cf database integrity, system integrity, even integrity protection in chemical plants). From context here and the rest of the sentence, it's imo clear that reliability is what is being referred to. I don't think this is necessarily a second erratum, but then I'm not a security type, and think that this is an example of why mathematicians often invent new terms, rather than overloading old ones. > 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, or segmentation/reassembly overwriting bugs or... it can be used to support the the end-to-end-principle. > but it is not suited > to protect against intentional modification of data by an attacker. agreed. > 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. Well, MD5 is not a cyclic code, and CRC128 wouldn't cope well with checking across anywhere near the sizes that MD5 can support; 128-bit MD5 has been compared in error-detection strength (nb not crypto strength!) to CRC2048++, which would be a rather complex polynomial. But I'm not so much of a purist that I would stall at nitpicking your terminology here. Instead, I agree that the overall point that you're making here is expressing exactly the point about MD5 that I've been trying to make, in relatively simple language for laymen. To come back to where we came in, MD5 is fine for detecting errors in a non-security context - but readers of RFC4270 and draft-turner-md5-seccon-update are not going to pick that up from a casual read, and will come away with 'MD5 bad, do not use' (and what's the alternative?). draft-turner-md5-seccon-update needs to be much, much clearer on this and in setting scope for use of MD5. regards, L. > > > > -Martin Lloyd Wood L.Wood@xxxxxxxxxxxx http://sat-net.com/L.Wood _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf