[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: what I am proposing re HMAC
-----BEGIN PGP SIGNED MESSAGE-----
content-type: text/plain; charset=us-ascii
Just to be clear, what I am proposing on HMAC is this:
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.
Agreed, but see the comments to #5
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.
This points out a weakness in the current IPSEC document structure.
Each key management method (ISAKMP, Photuris, SKIP, manual) has to
solve the exact same problem of "how do I name the transforms".
The author of a new transform needs to allocate separate transform
id's for each different key management protocol.
If there was a common algorithm-id spec defined by the transform-level
architecture, the work needed to define new transforms and hook them
into the key management infrastructure would be somewhat simplified.
[I'd suggest starting with SKIP's algorithm id's because early
versions of SKIP have actually been deployed, but it looks to me that
the way SKIP handles algorithm id's makes handling combined
encryption/MAC/... transforms messy.]
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. The new transforms are then
encouraged to be "must implement".
I'm in violent agreement with this..
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". Proofs are good, I fully believe Hugo is
a good crypto guy and that his proofs are excellent, but this is
engineering at this point, not math. Proposed standard should be
sufficient for a while.
5) If we desire, we may issue a document clarifying 1828 for
historical reasons, but we do this as an informational RFC.
Instead, why not:
(a) in the HMAC draft suggest that implementors implement
HMAC-MD5 (or whatever it's called) in addition to 1828
(b) have the IESG relabel 1828 as "historic" when HMAC goes to
PS or DS...
- Bill
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMTcyQVpj/0M1dMJ/AQEdfgP+K8VcZziZ6NUYyGy6GaL3/KtLvOV/Q7zV
WvzHPX77weOh6G2qvaQRmmDU15mih+U1mwEl7FZ/c5ZR2n+XFxL6t4tXiDRugX3G
U/PEXtoswpEZUshZ4L7cg6TVqox4U+xV+W3nmJLsBBoL+OZu5Tlt0K49iWE2pmm0
1dhBmEnacIY=
=Npz1
-----END PGP SIGNATURE-----
References: