Hi Eric, On 10/11/07 11:51 AM, "Eric Gray" <[EMAIL PROTECTED]> 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 PROTECTED] >> 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 PROTECTED]> 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 protected] https://www1.ietf.org/mailman/listinfo/gen-art
