On 3 Dec 2010, at 21:40, Martin Rex wrote:
L(_dot_)Wood(_at_)surrey(_dot_)ac(_dot_)uk 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(_dot_)Wood(_at_)surrey(_dot_)ac(_dot_)uk
http://sat-net.com/L.Wood
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf