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 PROTECTED]> 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 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 _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
