[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NMAC not HMAC, SHA not MD5



> From: "Perry E. Metzger" <perry@piermont.com>
> Subject: what I am proposing re HMAC
> 1) We leave 1828 alone. We do not advance it further but we do not
>    "replace" it, meaning new RFCs do NOT "supersede" it in the way a
>    replacement would.

Disagree.  We should advance to Draft Standard.  We have met the
requirements for Draft Standard.

> 2) We publish an RFC as a proposed standard for HMAC.

Disagree.  We should publish a proposed standard for NMAC, which has
supporting analysis from multiple researchers.

Oh, and I've already written the draft....

HMAC is merely conjectural, and is less efficient to implement than NMAC.

And HMAC derives its security from NMAC.  If anything, HMAC has a few
very specious assumptions.


> 3) We think of the HMAC transform not as a replacement for the
>    existing transforms but as a new transform. Any key negotiation
>    protocols that exist do not replace the meaning of "use the 1828
>    transform" with using HMAC -- they think of HMAC as a new
>    transform. I do not want the new RFC to "supersede" 1828 as a
>    replacement RFC would. One of the reasons I'm strongly opinioned on
>    this is that I expect this situation will occur over and over in
>    the next decade -- we will discover something and want to replace
>    what people are using. Right now we can fail to advance 1828 as
>    part of this process, but in general what we are doing is creating
>    NEW transforms, not REPLACING old ones.
>
Agreed!  Particularly with the latter.

> 4) We leave the HMAC RFC at proposed standard long enough for the crypto
>    community to really get its teeth in. Being at proposed should be
>    sufficient to encourage vendors to implement. I know Hugo would
>    probably like it to advance to draft standard more quickly, but my
>    gut instinct says "wait".

Agreed.

> 5) If we desire, we may issue a document clarifying 1828 for
>    historical reasons, but we do this as an informational RFC.
>
This is called an "applicability statement" and it is already provided
for in our standards process.  I have already begun writing it.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2