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

["Theodore Ts'o" <tytso@mit.edu>]

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