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

From: mcgrew <[email-masked]>
Date: Thu, 11 Oct 2007 11:25:18 -0700

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

---

From: "Eric Gray" <[email-masked]>
Date: Thu, 11 Oct 2007 13:51:28 -0500

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

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

---

From: mcgrew <[email-masked]>
Date: Thu, 11 Oct 2007 12:24:56 -0700

Hi Eric,

> 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

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Oct 2007 16:16:23 -0400

David:

I think that 2^16 is plenty for any packet or record environment.

Russ