Subject: [oauth] Algorithm choice (from the 'tother list)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 1 Dec 2008 12:30:00 -0800

We should not specify SHA-1 as a required algorithm.

This has nothing to do with the security arguments. It is just a matter of it being one of those arguments that the security area has pretty much decided not to have. The issue is not just the convenience or not of this particular protocol deployment, it is the fact that the algorithm choice does matter in some cases and arguing the difference is simply too much effort.

In most cases HMAC-MD5 is perfectly adequate. DIGEST-MD5 is perfectly adequate. But I would not specify them for a new standards proposal regardless of the cryptographic requirements. I regret not changing the MD5 requirement to SHA. Not doing so has led to a huge amount of IETF bandwidth since as folk propose updating it even though the strength of the DIGEST construction is much greater than the strength of SHA-1 (or come to that SHA-256).

If we are only using MAC functions, CMAC-AES would be a better long term choice than HMAC-SHA256 as we know that SHA256 is likely to change in future while CMAC is a NIST approved standard. I seem to recall it will be slower, but does that matter here?

When HMAC was written we were confident about our hash functions and worried about our encryption algorithms, in fact we had no encryption algorithm of choice at the time. Today that is not the case and CMAC offers the best possible future proofing.

I would like CFRG to periodically issue an RFC specifying a small set of preferred crypto algorithms. This would allow folk to specify TLS+RFCxxxx crypto or IPSEC+RFCxxxx crypto as a requirement. It would allow us to update the mandatory crypto suites for every IETF protocol in one go (assuming the protocol in question supported the new alg). It would also smooth the way for deployment of a coherent ECC based suite., just specify TLS+RFCxxxy or such.

If such a document were issued today the cipher suite recommendation would clearly be:
   AES128/192/256, SHA2*, CMAC-AES, RSA2048 [or DSA2048 if compact signatures are required]

The only questionable algorithm there is SHA2. I can well imagine in some instances wanting to insist on SHA512 instead of SHA256 because you do get more rounds with more key a well. The fact that SHA2 is a less preferred choice means that HMAC-SHA2 is also less preferred. Not because we have any specific concern, but we have a choice and it is a liability.

I think you could then make an argument for HMAC-SHA256 and Camilla being on a list of 'acceptable crypto' that may be supported but is not mandatory.
_______________________________________________
oauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth