Subject: Re: [Gen-art] Re: Gen-ART review of draft-mcgrew-auth-enc-03.txt

From: mcgrew <[email-masked]>
Date: Thu, 11 Oct 2007 13:32:09 -0700

Hi Russ,

I personally like the smaller size, and so does Eric, so I'll get rid of the
bigger size.

Thanks,

David

On 10/11/07 1:16 PM, "Russ Housley" <[email-masked]> wrote:

> David:
> 
> I think that 2^16 is plenty for any packet or record environment.
> 
> Russ
> 
> 
> At 03:24 PM 10/11/2007, mcgrew wrote:
>> Hi Eric,
>> 
>> On 10/11/07 11:51 AM, "Eric Gray" <[email-masked]> wrote:
>> 
>>> David,
>>> 
>>> My first "gut-level" reaction to the maximum values you
>>> propose is (at least) a mild disquiet.  But what the actual
>>> values should be is beyond my knowledge in this area and - if
>>> you think they'll work, then that's fine with me.
>>> 
>>> Otherwise, the changes you propose are fine with me...
>> 
>> Are you concerned that the values of 2^16 or 2^32 octets are too big, or too
>> small?   My personal opinion is that, for almost all network-packet
>> processing that involves authentication, 2^16 octets is big enough.  It's
>> big enough for all IPv4, plus there are technical reasons why larger sizes
>> aren't really useful in practice (namely, on the decryption side, it is
>> necessary to perform some amount of buffering to ensure that data is not
>> used prior to the authentication check being performed).   The larger size
>> of 2^32 octets will handle all of IPv6 jumbograms, and it is common for
>> crypto algorithms to support (at least) this size.
>> 
>> I would personally think that an algorithm that supported P_MAX = 2048
>> octets would be OK, but I think that others might object to sizes this small
>> (based on some standards discussions - for example, ESP CTR and ESP GCM
>> support 2^32 octet packets on the odd chance that someday someone will care
>> about encrypting v6-jumbo packets).  At any rate, this small size would be
>> allowed by the spec; it only violate a SHOULD, not a MUST.
>> 
>> For non-network applications, it's reasonable to expect algorithms to handle
>> 2^64 octets or therabouts, I think.  (That's kind of funny when you think
>> that there are countries that only allow < 64-bit keys :-)
>> 
>> Please feel free to pass along suggestions if you can see a better wording.
>> 
>> Best regards,
>> 
>> David
>> 
>>> 
>>> --
>>> Eric Gray
>>> Principal Engineer
>>> Ericsson
>>> 
>>>> -----Original Message-----
>>>> From: mcgrew [mailto:[email-masked]]
>>>> Sent: Thursday, October 11, 2007 2:25 PM
>>>> To: Eric Gray
>>>> Cc: General Area Review Team; Tim Polk
>>>> Subject: Re: Gen-ART review of draft-mcgrew-auth-enc-03.txt
>>>> Importance: High
>>>> 
>>>> Hi Eric,
>>>> 
>>>> On 9/21/07 12:10 PM, "Eric Gray" <[email-masked]> wrote:
>>>> 
>>>>> I have been selected as the General Area Review Team (Gen-ART)
>>>>> reviewer for this draft (for background on Gen-ART, please see
>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>>>> 
>>>> 
>>>> Thanks for the review and the good comments!  I have put
>>>> together a new
>>>> version of the document based on your comments plus some that
>>>> came in from
>>>> Phil Rogaway and Jari Arkko, which is attached.
>>>> 
>>>>> Please resolve these comments along with any other comments you
>>>>> may receive.
>>>>> 
>>>>> 
>>>>> Document: An Interface and Algorithms for Authenticated Encryption
>>>>>                       draft-mcgrew-auth-enc-03.txt
>>>>> Reviewer: Eric Gray
>>>>> Review Date:  9/21/2007
>>>>> 
>>>>> Summary:
>>>>> =======
>>>>> This draft is nearly ready for publishing as a Proposed Standard.
>>>>> 
>>>>> Comments/Questions:
>>>>> ==================
>>>>> At several places, the acronym "AAD" is used when it appears as if
>>>>> "AEAD" was intended.
>>>> 
>>>> Actually, the acronyms are distinct, but apparently the
>>>> document neglected
>>>> to formally define what AAD is.  I've added a definition to
>>>> Section 1.  I
>>>> have also changed "Additional Authenticated Data" to
>>>> "Associated Data" based
>>>> on Phil's comments.
>>>> 
>>>>> This occurs in the following places:
>>>>> 
>>>>> o First sentence, next-to-last paragraph, on page 6
>>>>> o Throughout section 3.3 (both paragraphs, bottom Pp 10, top Pp 11)
>>>>> o First sentence, last paragraph, on page 14
>>>>> 
>>>>> One reason why this appears to be the case, is that section 3.3
>>>>> is entitled "Construction of AEAD Inputs" - but the very first
>>>>> sentence starts "If the AAD input ..."
>>>>> 
>>>>> If AAD is a distinct term, what does it mean?  If it is not a
>>>>> distinct term, well...
>>>>> 
>>>> ______________________________________________________________
>>>> _________
>>>>> 
>>>>> In section 4, second paragraph, is it possible to assign a P_MAX
>>>>> value of zero in a particular algorithm, and - if so - what does
>>>>> it mean to say:
>>>>> 
>>>>>   "Each AEAD algorithm MUST accept any plaintext with a
>>>> length between
>>>>>    zero and P_MAX octets, inclusive, where the value P_MAX
>>>> is specific
>>>>>    to that algorithm"
>>>>> 
>>>>> ?
>>>> 
>>>> I suggest the following addition:  "The value of P_MAX MUST
>>>> be larger than
>>>> zero, and SHOULD be at least 65,536 (2^16) octets; if
>>>> possible, it SHOULD be
>>>> at least 4,294,967,296 (2^32) octets.  These sizes are
>>>> typical upper limits
>>>> for network data packets.  Other applications may use even
>>>> larger values of
>>>> P_MAX, so it is desirable for general-purpose algorithms to
>>>> support higher
>>>> values."
>>>> 
>>>>> 
>>>>> Similar questions also apply to A_MAX and N_MAX in the third and
>>>>> fourth paragraphs (respectively) of the same section.
>>>> 
>>>> Some clarifications:
>>>> 
>>>> "The value of A_MAX MUST be larger than zero, and SHOULD be
>>>> at least 65,536
>>>> (2^16) octets; if possible, it SHOULD be at least 4,294,967,296 (2^32)
>>>> octets.   Other applications may use even larger values of
>>>> A_MAX, so it is
>>>> desirable for general-purpose algorithms to support higher values."
>>>> 
>>>> "The values of N_MAX and N_MIN MAY be equal."
>>>> 
>>>>> 
>>>> ______________________________________________________________
>>>> _________
>>>>> 
>>>>> In the last sentence of section 5.3.1, "he" should probably be
>>>>> "an attacker" (it is not clear who "he" is) and "ensues" should
>>>>> probably be "may ensue" (a vulnerability does not guarantee an
>>>>> attack).
>>>>> 
>>>> 
>>>> Good catch; I'll make that substitution.
>>>> 
>>>> Best regards,
>>>> 
>>>> David
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> _______________________________________________
>> Gen-art mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/gen-art

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art