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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf