[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
> A week has gone by and there doesn't appear to have been any
> discussion on this point which Andrew has raised. Does anybody think
> that the extra use of keying material used by AES-XCBC-MAC is a
> problem? We will assume that silence means people are OK with it as
> it currently stands.
Okay, so either everyone agrees with the design decision or no one cares. On
this list, it's usually best to assume the latter.
> Andrew, how strongly do you feel about requesting the draft be
> modified to include discussion of this tradeoff? I suspect that if
> you contribute text to the document authors, it would probably
> increase the likelihood that the draft will include discussion on this
> point. :-)
I'm not fanatical about this particular issue, but I think that many drafts
could benefit from some explanation of the design rationale. This may save
us a bunch of redundant questions on the mailing list 2 years from now (the
downside being that vague drafts may be more likely to progress to RFC if no
one can find anything concrete to object to).
XCBC-MAC does not appear to be controversial, so it would be better to
document the design decision, especially since the crucial reference in the
draft [XCBC-MAC-1] is a broken link. I already suggested this to the authors
by private e-mail some time back. It could be as simple as a 2 sentence
add-on:
AES-XCBC-MAC-96 actually requires 384 bits of keying material (128
bits for the AES keysize + 2 times the blocksize). This keying mate-
rial can either be provided through the key generation mechanism or
it can be generated from a single 128-bit key. The latter approach
has been selected for AES-XCBC-MAC-96, since it is analogous to other
authenticators used within IPsec.
"The reason XCBC-MAC uses 3 keys is so the length of the input stream does
not need to be known in advance. This may be useful for systems that do
one-pass assembly of large packets."
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso@mit.edu]
> Sent: Thursday, May 30, 2002 11:49 AM
> To: Andrew Krywaniuk
> Cc: ipsec@lists.tislabs.com
> Subject: Re: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
>
>
> On Thu, May 23, 2002 at 02:59:51PM -0400, Andrew Krywaniuk wrote:
> > This draft hasn't really been discussed on the list much. I
> guess people
> > figure that "hey, it's just another crypto algorithm...
> there can't be
> > anything controversial about it".
> >
> > The issue which Dave brought up at the meeting and which I
> sent to the
> > authors is that XCBC-MAC skirts the "obvious" solution of
> prepending the
> > length of the buffer to the hash input. There is an
> engineering tradeoff
> > here, which is not mentioned in the draft.
> >
> > AES-XCBC-MAC:
> > a) requires 384 bits of keymat
> > b) does not require that the length of the message be pre-computed
> >
> > The "obvious" solution:
> > a) requires 128 bits of keymat
> > b) requires that the length of the message be pre-computed
> >
> > Clearly, issue (b) was an important motivation in the
> design of XCBC-MAC.
> >
> > My personal opinion is that this rationale makes sense,
> since key storage
> > capacity is unlikely to be the limiting factor in the
> design of any future
> > hardware. However, the tradeoff ought to at least be
> discussed on the list
> > and acknowledged in the draft.
>
> A week has gone by and there doesn't appear to have been any
> discussion on this point which Andrew has raised. Does anybody think
> that the extra use of keying material used by AES-XCBC-MAC is a
> problem? We will assume that silence means people are OK with it as
> it currently stands.
>
> Andrew, how strongly do you feel about requesting the draft be
> modified to include discussion of this tradeoff? I suspect that if
> you contribute text to the document authors, it would probably
> increase the likelihood that the draft will include discussion on this
> point. :-)
>
> - Ted
>