Re: [Gen-art] Gen-ART LC Review of draft-ietf-nsis-nslp-auth-06

[RJ Atkinson <[e-mail]>]

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.