An Interface and Algorithms for Authenticated Encryption
draft-mcgrew-auth-enc-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2007-11-15
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2007-11-14
|
05 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-11-14
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2007-11-14
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2007-11-14
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2007-11-14
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-11-14
|
05 | Amy Vezza | IESG has approved the document |
2007-11-14
|
05 | Amy Vezza | Closed "Approve" ballot |
2007-11-14
|
05 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2007-11-14
|
05 | (System) | IANA Action state changed to In Progress |
2007-11-09
|
05 | (System) | New version available: draft-mcgrew-auth-enc-05.txt |
2007-10-15
|
05 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
2007-10-12
|
04 | (System) | New version available: draft-mcgrew-auth-enc-04.txt |
2007-08-16
|
05 | Jari Arkko | [Ballot discuss] > The initial zero value MAY be omitted if it is convenient. > Thus at most 2^(8*C) nonces can be generated when the … [Ballot discuss] > The initial zero value MAY be omitted if it is convenient. > Thus at most 2^(8*C) nonces can be generated when the Counter > field is C octets in length. But this depends on whether the algorithm treats zero octets differently from no octets. If it treats them differently, then sending an empty string first, followed by all values fitting to an octet string of length C ... I think we get 1+2^(8*C) distinct nonces. |
2007-08-16
|
05 | Jari Arkko | [Ballot comment] |
2007-08-06
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-08-06
|
03 | (System) | New version available: draft-mcgrew-auth-enc-03.txt |
2007-07-30
|
05 | Tim Polk | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Tim Polk |
2007-07-06
|
05 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Charles Clancy. |
2007-07-06
|
05 | (System) | Removed from agenda for telechat - 2007-07-05 |
2007-07-05
|
05 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead by Amy Vezza |
2007-07-05
|
05 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2007-07-05
|
05 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2007-07-05
|
05 | Sam Hartman | [Ballot comment] This is excellent work. Section 4 discusses an IV, where I think it means to discuss a nonce in a couple places. Section … [Ballot comment] This is excellent work. Section 4 discusses an IV, where I think it means to discuss a nonce in a couple places. Section 5.1.1 implies that encrypting the same plaintext twice with AES GCM is problematic. It needs to make it more clear that this is in the context of nonce reuse. I'm a bit concerned that because of the variable size of nonces and because of the wide variety of nonce sizes that might be used this will be hard to use as a framework. I think if I were an application designer trying to use this as an abstract interface I'd first try a 12-byte nonce, then try some nonce size specific to my application, then try 0 byte nonce (to catch purely randomized algorithms) then give up. It would be nice if in addition to having a minimum and maximum nonce size there was a preferred nonce size. |
2007-07-05
|
05 | Sam Hartman | [Ballot Position Update] New position, Yes, has been recorded by Sam Hartman |
2007-07-05
|
05 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2007-07-05
|
05 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2007-07-04
|
05 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2007-07-04
|
05 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2007-07-04
|
05 | Chris Newman | [Ballot Position Update] New position, Yes, has been recorded by Chris Newman |
2007-07-04
|
05 | Chris Newman | [Ballot comment] Question: This is fairly abstract. Will we be seeing more concrete realizations of this idea in, for example, a PKCS #11 extension or … [Ballot comment] Question: This is fairly abstract. Will we be seeing more concrete realizations of this idea in, for example, a PKCS #11 extension or Java/C API bindings? Or is this something that crypto or security service libraries worry about and applications should ignore? Is there going to be a mailing list set up where people can _optionally_ get advice to refine their registration? (Mandatory list review is annoying, but optional list review is often helpful). I'm wondering if IANA will have a problem with this registry given this text: "The current specification requires that a registered algorithm provide a complete specification and a set of validation data; it is hoped that these prerequisites set the admission criteria appropriately." That sounds like you need an expert reviewer to verify that criteria is met. Editorial nits: > none that only encryption is random, and decryption is alwasy s/none/note/, s/alwasy/always/ > it MUST specify the number of octets in the largeset possible s/largeset/largest/ > rollback; threats and mitigations of are an area of active research. s/of are/in that scenario are/ > SHOULD use a nonce length of 12 octets, since with GCM is there is s/is there is/there is/ > Directly testing a randomized AEAD encryption algorithm using a test s/a test/test/ |
2007-07-03
|
05 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2007-07-03
|
05 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2007-07-03
|
05 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2007-07-03
|
05 | Jari Arkko | [Ballot discuss] This is a Discuss-discuss and once we've had the discussion and gotten a satisfactory answer, I will ballot Yes. I am puzzled by … [Ballot discuss] This is a Discuss-discuss and once we've had the discussion and gotten a satisfactory answer, I will ballot Yes. I am puzzled by the requirements on nonces: > Each nonce provided to distinct invocations of the > Authenticated Encryption operation MUST be distinct ... > The number of octets in the nonce MAY be zero, but SHOULD be > twelve (12) octets. It is obvious that zero length nonces are not unique, unless they are only used once per a given key. Is the minimum zero length requirement an oversight, or is it a feature designed to allow optimized operation? I realize that if the application uses a key only once, then the nonce is not needed, and that if you send multiple data segments then the first given nonce could be of zero length as long as the other ones are not. Then again, I wonder if such an optimization is really worthwhile. There is no requirement to communicate the nonce; in these applications the nonce can be entirely implicit. > The initial zero value MAY be omitted if it is convenient. > Thus at most 2^(8*C) nonces can be generated when the Counter > field is C octets in length. But this depends on whether the algorithm treats zero octets differently from no octets. If it treats them differently, then sending an empty string first, followed by all values fitting to an octet string of length C ... I think we get 1+2^(8*C) distinct nonces. Right? (Or should I drink my morning coffee before entering a Discuss?) |
2007-07-03
|
05 | Jari Arkko | [Ballot discuss] This is a Discuss-discuss and once we've had the discussion and gotten a satisfactory answer, I will ballot Yes. I am puzzled by … [Ballot discuss] This is a Discuss-discuss and once we've had the discussion and gotten a satisfactory answer, I will ballot Yes. I am puzzled by the requirements on nonces: > Each nonce provided to distinct invocations of the > Authenticated Encryption operation MUST be distinct ... > The number of octets in the nonce MAY be zero, but SHOULD be > twelve (12) octets. It is obvious that zero length nonces are not unique, unless they are only used once per a given key. Is the minimum zero length requirement an oversight, or is it a feature designed to allow optimized operation? I realize that if the application uses a key only once, then the nonce is not needed, and that if you send multiple data segments then the first given nonce could be of zero length as long as the other ones are not. Then again, I wonder if such an optimization is really worthwhile. There is no requirement to communicate the nonce; in these applications the nonce can be entirely implicit. > The initial zero value MAY be omitted if it is convenient. > Thus at most 2^(8*C) nonces can be generated when the Counter > field is C octets in length. But this depends on whether the algorithm treats zero octets differently from no octets. If it treats them differently, then sending an empty string first, followed by all values fitting to an octet string of length C ... I think we get 1+2^(8*C) distinct nonces. Right? |
2007-07-03
|
05 | Jari Arkko | [Ballot discuss] This is a Discuss-discuss and once we've had the discussion and gotten a satisfactory answer, I will ballot Yes. I am puzzled by … [Ballot discuss] This is a Discuss-discuss and once we've had the discussion and gotten a satisfactory answer, I will ballot Yes. I am puzzled by the requirements on nonces: > Each nonce provided to distinct invocations of the > Authenticated Encryption operation MUST be distinct ... > The number of octets in the nonce MAY be zero, but SHOULD be > twelve (12) octets. It is obvious that zero length nonces are not unique, unless they are only used once per a given key. Is the minimum zero length requirement an oversight, or is it a feature designed to allow optimized operation? I realize that if the application uses a key only once, then the nonce is not needed, and that if you send multiple data segments then the first given nonce could be of zero length as long as the other ones are not. Then again, I wonder if such an optimization is really worthwhile. There is no requirement to communicate the nonce; in these applications the nonce can be entirely implicit. |
2007-07-03
|
05 | Jari Arkko | [Ballot comment] > An nonce N. Isn't this "a nonce"? > The nonce MAY be included in P or A if it convenient to the … [Ballot comment] > An nonce N. Isn't this "a nonce"? > The nonce MAY be included in P or A if it convenient to the application. s/it/it is/ > though none that only encryption is random, and decryption is alwasy deterministic. s/alwasy/always/ Also, I cannot parse the beginning of this text fragment. Maybe you meant "though only encryption is random, and ..." |
2007-07-03
|
05 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2007-07-03
|
05 | Jari Arkko | [Ballot comment] > The nonce MAY be included in P or A if it convenient to the application. s/it/it is/ > though none that only … [Ballot comment] > The nonce MAY be included in P or A if it convenient to the application. s/it/it is/ > though none that only encryption is random, and decryption is alwasy deterministic. s/alwasy/always/ Also, I cannot parse the beginning of this text fragment. Maybe you meant "though only encryption is random, and ..." |
2007-07-02
|
05 | Lars Eggert | [Ballot discuss] Section 10.1., paragraph 2: > [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of > … [Ballot discuss] Section 10.1., paragraph 2: > [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of > Operation (GCM)", Submission to NIST http://csrc.nist.gov/ > CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf, > January 2004. DISCUSS: DOWNREF? Not (yet?) a standard by another SDO as far as I can tell. Or are we expecting the RFC Editor to hold this document until [GCM] becomes a NIST standard? |
2007-07-02
|
05 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2007-06-28
|
05 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2007-06-27
|
05 | Tim Polk | Ballot has been issued by Tim Polk |
2007-06-26
|
05 | Tim Polk | [Ballot Position Update] New position, Yes, has been recorded by Tim Polk |
2007-06-26
|
05 | Tim Polk | Created "Approve" ballot |
2007-06-14
|
05 | Yoshiko Fong | IANA Last Call Comments: [ Question: What does a Numeric ID of "0" mean? It should probably be declared in the creation of the registry … IANA Last Call Comments: [ Question: What does a Numeric ID of "0" mean? It should probably be declared in the creation of the registry ] Upon approval of this document, the IANA will create the following registry "AEAD Registry" located at http://www.iana.org/assignments/TBD Allocation policy: RFC or other permanant reference publication Initial contents of this registry will be: Numeric Identifier Name (AEAD_...) Reference 0-65535 ---------- ------------------------- --------- 0 ??? 1 AEAD_AES_128_GCM [RFC-mcgrew-auth-enc-02] section 5.1 2 AEAD_AES_256_GCM [RFC-mcgrew-auth-enc-02] section 5.2 3 AEAD_AES_128_CCM [RFC-mcgrew-auth-enc-02] section 5.3 4 AEAD_AES_256_CCM [RFC-mcgrew-auth-enc-02] section 5.4 5-32767 Reserved to IANA [RFC-mcgrew-auth-enc-02] 32768- Reserved for Private Use [RFC-mcgrew-auth-enc-02] 65535 We understand the above to be the only IANA Action for this document. |
2007-06-13
|
05 | Tim Polk | Placed on agenda for telechat - 2007-07-05 by Tim Polk |
2007-06-07
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Charles Clancy |
2007-06-07
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Charles Clancy |
2007-05-31
|
05 | Amy Vezza | Last call sent |
2007-05-31
|
05 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-05-31
|
05 | Tim Polk | Last Call was requested by Tim Polk |
2007-05-31
|
05 | Tim Polk | State Changes to Last Call Requested from AD Evaluation by Tim Polk |
2007-05-31
|
05 | (System) | Ballot writeup text was added |
2007-05-31
|
05 | (System) | Last call text was added |
2007-05-31
|
05 | (System) | Ballot approval text was added |
2007-05-31
|
05 | Tim Polk | State Changes to AD Evaluation from Publication Requested by Tim Polk |
2007-05-31
|
05 | Tim Polk | email from editor to Security Area Directors 5/2/2007; forwarded by Tim Polk to the Secretariat 5/31/2007 |
2007-05-31
|
05 | Tim Polk | Draft Added by Tim Polk in state Publication Requested |
2007-03-05
|
02 | (System) | New version available: draft-mcgrew-auth-enc-02.txt |
2006-10-25
|
01 | (System) | New version available: draft-mcgrew-auth-enc-01.txt |
2006-08-18
|
00 | (System) | New version available: draft-mcgrew-auth-enc-00.txt |