[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
hugo@watson.ibm.com writes:
> We need to find a way to break this loop. I don't care about the wor
d
> "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
who has seen your work has had any trouble with it, but recall that
similar statements were made the last time around -- it would be
better if we gave it some time. This isn't to say we should advance
something else in its place, you understand. It is just to say we
should be more carefull.
Of course, all along the unanimous opinion of the cryptographic theoreticians
has been that keyed hash functions were an unknown -- they weren't designed
to do that, and it wasn't clear that they were secure in this mode. But
we went ahead anyway.
> 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.
Right. And if ESMTP had been proposed way back when, before RFC821 was
officially blessed, it would have been a different matter. If we're going
to change it, now is the time. We should certainly use a different transform
number for HMAC, to make the transition easier, but we should have only
one full standard.
RFC1828 is a ``Proposed Standard''. Let me quote from RFC1880, the current
instantiation of STD 1:
4.1.3. Proposed Standard Protocol
These are protocol proposals that may be considered by the IESG
for standardization in the future. Implementation and testing by
several groups is desirable. Revision of the protocol
specification is likely.
Note carefully: revision is *likely*. If we're going to change it, now is
the time -- after it goes to Draft, it's too late for fixes of this nature
(absent, say, the discovery of a feasible attack).