Ah, the 'but security, unlike transport, is actually important' argument. Having seen subscribers to that philosophy unsuccessfully attempt to design transport protocols (and raise the MD5 issue repeatedly, because it's considered a security issue, and they're at home with security), I would argue that there is a lack of appreciation and understanding of the nuances of transport protocol issues in the IETF. Reliability, implications of the end-to-end protocol, feedback loops... Today's crypto hash is tomorrow's probably-not-a-collision error detection, with no claims to security or protection against deliberate attacks. MD5 has made that transition, just because some collisions can be calculated. Better protocols will follow, because collisions will eventually be found. Considering entropy suggests this. Ethernet CRCs have collisions, but they have a useful role in error detection. Checksums are not secure, but that is not what they are used for. And they suffice for that purpose. No-one complains about Ethernet CRCs or one's complement checksums (OMG you can swap entire bvtes in TCP and just swap addresses and the echo server still works!) being insecure. Perhaps they still should. Being adequate for purpose is not enough if they're not secure! I find it difficult to care about the digest function fashion of the day. (For MD5, see RFC6151.) But watching security people make a hash of transport protocol design really isn't fun. That and the lack of transport expertise concerns me. Lloyd Wood http://sat-net.com/L.Wood/dtn > Congestion control is essential else we have congestive collapse, which > I have had to find and fix in my time; but I am positing that for most > of the IETF, congestion control is a solved topic and little expertise > is needed, in contrast to Security which is for ever changing (SHA2 or > SHA3 or will MD5 still suffice?). Yes, a high-level of skill exists, > especially in the ICCRG (and I struggle to follow it) but I wonder if we > need that skill in the IETF ie a basic familiarity with what TCP offers > and UDP does not will serve most of our work.