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.