>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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cfrg mailing list Cfrg at ietf.org https://www1.ietf.org/mailman/listinfo/cfrg