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

(IMPORTANT) Call for AH-MD5 and ESP-DES to move forward



Ref:  Your note of Thu, 29 Feb 1996 16:54:52 -0500 (attached)

There is so much traffic in this list these days and I hate contributing
more but this may interest other people in addition to Perry.

Perry writes:

 > hugo@watson.ibm.com writes:
 > > We need to find a way to break this loop. I don't care about the word
 > > "replace" just about making clear that IPSEC-AH REQUIRES HMAC
 > > (as the default implementation).
 >
 > Thats fine, so long as we don't speak of "replacing", and so long as
 > we take some time to allow people to examine the transform. I would
 > want to see some considerable time taken between the time that an HMAC
 > based RFC is issued and the time it is advanced. No personal slight
 > intended, Hugo, but I've learned at this point that the only way to
 > get certainty out of cryptographers is to wait a year or two for the
 > dust to settle thoroughly. I fully believe your statements that no one

Waiting 1-2 years is unrealistic for IETF proposals.
However, I wish there was a more orderly scrutiny of security designs
for IETF protocols by cryptographers.

Photuris is a good example. It took me 6 drafts (from 03 to 09)
to convince Simpson to derive *independent* key bits for keyed-MD5 and DES.
Photuris still directly signs secret information which is a clearly wrong
cryptographic practice. Photuris confuses between MAC keys and data.
It does not handle key refreshment in a satisfactory way. It uses
unconstrained strings like SPI's as nonces, and incurs in some other
cryptographic sins. I didn't see where is the cryptographic community
that is inspecting this design.
It is actually very hard for cryptographers that are not directly involved
with this work to analyze these protocols in the implementation-oriented way
that they are written. They should be accompanied by a clear protocol
describing the basic flows and cryptographic rationale. But they are not.

What we did with HMAC is far more sound cryptographicaly as well as
for analysis, for presentation, and for exposure to cryptographers.

Moreover, notice that we have very clear proofs of security. That means that
there are no heuristics involved in the MAC construction except the minimal
and unavoidable assumptions that you need from MD5 (or your favorite
hash function). I wish I could always come with such strong arguments
for other cryptographic construction that I propose or use.

 > > As a general note: if we can't modify the standards during the
 > > standarization process why do we have that process in place.
 >
 > We can alter what is standard. However, it is often bad to alter what
 > already exists. When SMTP got revised, an extensions mechanism was
 > created -- existing SMTPs weren't broken. Sometime soon it will be
 > required that SMTP implementations support ESMTP, but it will
 > doubtless be a long while before ESMTP is totally universal, if
 > ever.

I repeat this very clearly. In my opinion (and I hope people will agree
and even say it ;-) NOW is the time to move to the new transform,
and, if possible, forget about the previous one.
Having two around will only create confusion and interoperability problems.


Hugo