RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt

["Housley, Russ" <rhousley@rsasecurity.com>]

Scott:

>>>[David]
>>>To be precise, using a 192-bit AES key rather than a 64-bit 'secret 
>>>counter component'
>>>does not provide more security.  This is because precomputation attacks are
>>>foiled equally well by either method, and the security level of a
>>>cryptosystem is determined by the minimum effective attack.  A 192-bit AES
>>>key does potentially provide protection against more types of attacks, of
>>>course.

>>[Russ]
>>It seems to me that the inclusion of a public value that cannot be 
>>predicted by the attacker provides the same protection against 
>>precomputation attacks.  That is the reason that the truncated SPI is 
>>included in the counter block in the current document.

>[Scott]
>Just one obvious comment: if the security analysis of 
>draft-ietf-ipsec-ciph-aes-ctr-00.txt was done under the assumption that 
>(truncated) SPIs are unpredictable (or at least nonconstant), the draft 
>should explicitly require that the (truncated) SPIs be unpredictable (or 
>at least nonconstant).  Currently, RFC2401, 2406 impose no such 
>requirement on an implementation.

[Russ]
I have updated the last paragraph of the Design Rationale section to 
capture the sense of this discussion.  I agree that corresponding changes 
to ESP would be desirable.

The updated paragraph now says:

    The inclusion of the truncated SPI provides a weak countermeasure
    against precomputation attacks.  For this countermeasure to be
    effective, the attacker must not be able to predict the least
    significant 24 bits of the SPI well in advance of security
    association establishment.  The use of long keys provides a strong
    countermeasure to these attacks, and AES offers key sizes that thwart
    these attacks for many decades to come.

Thanks for your review,
    Russ