Skip to main content

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