So, I'm sympathetic to the idea that we in the security community can be
overly paranoid. however I'm more sympathetic to the idea that it's
hard to figure out what uses are security sensitive and what uses are
not. At least in the case of md5, where backward compatibility concerns
don't dictate otherwise, I'd say that moving away is better than not.
Let me take a specific example from earlier in this discussion. The
claim was made that using md5 to verify the checksum of ISOs downloaded
off the Internet is still good. That depends entirely on what you're
trying to protect against. If your concern is simply errors in the
download and concerns that the TCP checksum may be inadequate, then I
agree. However it's also fairly common to have md5 checksums on an
initial page and then direct people to mirrors for the actual
ISO. There, you're also protecting against substitution attacks mounted
between the original page and the iso.
If md5 is used in exactly the same context as the data, I agree it is
still fine. However, the moment you separate the checksum from the
data--by putting one in e-mail, one on a post-it note, one on a
different mirror, you have made the hash security sensitive.
For this specific use, I think the extra length of SHA-1 is worth it,
and I think it is reasonable for us to recommend that something stronger
than MD5 is appropriate. (SHA-2 would be better, although the length of
SHA-2 starts to get prohibitive.)
It's very easy for the security of a hash function to become
important. I at least find it difficult to easily determine whether a
particular use of a hash is security sensitive. I find that I disagree
with the results from people who claim that this analysis is easy often
enough that I'm reluctant to conclude that I'm simply unusually slow at
thinking through these sorts of issues. So, I suggest that the problem
of deciding whether the security of a hash is important may be a bit
tricky. While we should not spread panic and we should be sensitive to
these issues, I also would rather us err on the side of security in our
recommendation.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf