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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf