Subject: RE: [Cfrg] HMAC-MD5

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 10 Apr 2006 09:12:25 -0700

>From a standards point of view I think it makes total sense to have an
alternative MAC function specified for all current protocols. 

Merely specifying an algorithm does not force deployment. The more pertinent
question is whether to withdraw recognition for HMAC-MD5. I don't see any
evidence that points to decertification yet.

In other words make HMAC-SHA256 or MAC-AES a MUST, but keep HMAC-MD5 as
SHOULD for compatibility reasons where it is in use today and tell people to
expect it to be withdrawn at some date in the future.

Rather than do this piecemeal per protocol I would strongly suggest a single
RFC making the change across all the currently active PROPOSED or DRAFT
protocols. That way people know to recognize compatibility with RFC XXXX as
meaning up to current crypto requirements.

RFC XXXX could say something like 'To be described as compatible with this
RFC an application MUST implement the following cipher options (AES,
HMAC-256 or AES-MAC, SHA256, (RSA 2048 or DSA 2048) and SHOULD NOT implement
MD4, MD5, MD2, DES, IDEA, except where essential for compatibility reasons.'
Fix up the wording a bit to make sure the default is towards strong crypto.

The one exception to all this is HTTP Digest authentication, in that case
MD5 is not the weakest point in the system, the password itself is. As
public key crypto was encumbered at the time there was no way to add extra
randomness into the exchange. I don't know that there is an exchange
mechanism that is actually unencumbered that meets the necessary criteria at
the moment. 
_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg