Data: In the most recent round of updates to interior routing cryptographic authentication, the collective conclusion was that HMAC-SHA-256 would be best for "mandatory" implementation, as it likely has the longest lifetime of the widely available (mode + algorithm) combinations. [RFC-5709, Section 3] The DNSsec specifications also seem to have settled upon SHA-256, rather than some different or shorter hash algorithm. [RFC-4509, Section 6.2] [RFC-5702, Section 8.1] A number of large commercial/financial/governmental users mandate that commercial products use cryptographic algorithms, modes, and implementations that have been approved/successfully evaluated under NIST FIPS-140. This creates a marketplace incentive to have/use NIST-compliant modes/algorithms, at least as openly specified implementation options for IETF protocols. [http://csrc.nist.gov/groups/STM/cavp/index.html] Identified weaknesses in MD5 don't necessarily apply to Keyed-MD5 or HMAC-MD5 **as used for datagram authentication by IETF interior routing protocols**. [RFC-5310, Section 1, Paragraph 7] [RFC-5709, Section 4, 2nd Paragraph] The recent round of IGP authentication updates provides a range of algorithm alternatives, particularly including the SHA family. [RFC-4822, RFC-5304, RFC-5310, RFC-5709] Those weaknesses in MD5 and also in SHA-1 reportedly *are* problematic in some other uses (e.g. X.509v3/PKIX certificates). [See references Wang04, Wang05, RR07, and RR08 in RFC-5709 for more information.] [RFC-5702] While the discussion in [RFC-4270] is valuable, at this point, nearly 5 years later, it necessarily is significantly incomplete. The sundry references into the published research literature cited in [RFC-5709] are also worth reading. NIST announced a "cryptographic hash algorithm competition" more than 2 years ago to seek a replacement for SHA-2. While this replacement will be known as SHA-3, it will not necessarily be related mathematically to the SHA-1/2 algorithm family. [http://csrc.nist.gov/groups/ST/hash/sha-3/index.html] Opinion: There probably is some value in having an open specification for less computationally intense "optional" (mode + algorithm)s, for example HMAC-MD5 or HMAC-SHA1. Obviously that ought to be optional-to-implement, but it likely would be useful for network operators (of any kind: educational, ISP, enterprise, other) to be able to make appropriate site-specific tradeoffs about which algorithm to deploy locally. For example, threat environments reportedly vary widely from one site to another. HMAC is generally preferred to Keyed, primarily because (A) it has some formal mathematics behind it and (B) HMAC is approved under NIST FIPS-140.[FIPS-198] [See above for why FIPS-140 matters commercially.] The IETF Security Area appears to be looking at other approaches (i.e. beyond SHA-2) as it thinks about future directions for cryptographic authentication. For example, one option specified in [RFC-5926] is AES-CMAC. Caveat: I am neither a mathematician nor a cryptographer. I'm simply reporting the results of a literature search, both in the research literature and in the always useful rfc-index.txt. > On 9th Sept 2010 at 16:56, Russ Housley wrote: >> Will any implementations be impacted? If not, we should ask the >> Security ADs for their best suggestion. On 9th Sept 2010 at !9:51, Roland Bless wrote: > At least we have one implementation, but it's nothing that > we couldn't change easily. So getting advice from the security > ADs would be good. RFC4270 recommends to change to > HMAC-SHA-256+, but I don't know whether there exist already better > alternatives. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf