RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt

["David A. Mcgrew" <[e-mail]>]

Ted, Andrew,

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Theodore Ts'o
> Sent: Thursday, May 30, 2002 8:49 AM
> To: Andrew Krywaniuk
> Cc: [e-mail]
> 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.

I agree with Andrew on this point (and was on vacation for the last week
:-).  IMO it makes sense for the WG to record that kind of rationale, and
the draft is the natural place to do that.

As for the tradeoff, XCBC-MAC seems like a fine choice to me, though
hardware vendors may not like the increased memory requirement.

David

>
> 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