Skip to main content

Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)
draft-dharkins-siv-aes-05

Revision differences

Document history

Date Rev. By Action
2020-03-25
05 Amy Vezza Downref to RFC 5297 approved by Last Call for draft-ietf-ntp-using-nts-for-ntp-28
2015-10-14
05 (System) Notify list changed from dharkins@arubanetworks.com, draft-dharkins-siv-aes@ietf.org to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2008-10-28
05 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2008-10-28
05 Cindy Morgan [Note]: 'RFC 5297' added by Cindy Morgan
2008-10-23
05 (System) RFC published
2008-07-25
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2008-07-24
05 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2008-07-24
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-07-17
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-07-17
05 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2008-07-17
05 (System) IANA Action state changed to In Progress
2008-07-17
05 Cindy Morgan IESG state changed to Approved-announcement sent
2008-07-17
05 Cindy Morgan IESG has approved the document
2008-07-17
05 Cindy Morgan Closed "Approve" ballot
2008-07-17
05 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Undefined by Pasi Eronen
2008-07-17
05 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to Undefined from Discuss by Pasi Eronen
2008-07-02
05 Pasi Eronen [Ballot discuss]
...just noticed that in 2008-06-19 telechat, I promised
to hold a DISCUSS for IANA. Will clear when Tim says everything
is OK.
2008-07-02
05 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to Discuss from No Objection by Pasi Eronen
2008-06-30
05 Pasi Eronen [Ballot comment]
2008-06-30
05 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Undefined by Pasi Eronen
2008-06-30
05 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to Undefined from Discuss by Pasi Eronen
2008-06-26
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-06-26
05 (System) New version available: draft-dharkins-siv-aes-05.txt
2008-06-20
05 (System) Removed from agenda for telechat - 2008-06-19
2008-06-19
05 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Cindy Morgan
2008-06-19
05 Pasi Eronen
[Ballot discuss]
Sections 6.1/6.2/6.3 say that P_MAX, A_MAX, N_MAX and C_MAX are
"unlimited"; this isn't literally true (the paper [DAE] seems to
suggest limit of …
[Ballot discuss]
Sections 6.1/6.2/6.3 say that P_MAX, A_MAX, N_MAX and C_MAX are
"unlimited"; this isn't literally true (the paper [DAE] seems to
suggest limit of 2^64 blocks; 800-38B recommends that CMAC-AES
shouldn't be used for more than 2^48 blocks, etc.).
2008-06-19
05 Chris Newman [Ballot comment]
2008-06-19
05 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Abstain by Chris Newman
2008-06-19
05 Pasi Eronen
[Ballot discuss]
So far, all crypto algorithms have been Informational RFCs -- it
seems this should be Informational, too.

Sections 6.1/6.2/6.3 say that P_MAX, A_MAX, …
[Ballot discuss]
So far, all crypto algorithms have been Informational RFCs -- it
seems this should be Informational, too.

Sections 6.1/6.2/6.3 say that P_MAX, A_MAX, N_MAX and C_MAX are
"unlimited"; this isn't literally true (the paper [DAE] seems to
suggest limit of 2^64 blocks; 800-38B recommends that CMAC-AES
shouldn't be used for more than 2^48 blocks, etc.).

IANA has concerns.
2008-06-19
05 Tim Polk Area acronymn has been changed to sec from gen
2008-06-19
05 Tim Polk Intended Status has been changed to Informational from Proposed Standard
2008-06-19
05 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-06-19
05 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-06-19
05 David Ward [Ballot comment]
Support Pasi and Russ' discuss and given the only alt is no-obj consent...
2008-06-19
05 David Ward [Ballot Position Update] New position, Abstain, has been recorded by David Ward
2008-06-19
05 Chris Newman [Ballot comment]
I don't consider myself qualified to review a cryptographic algorithm of
this nature to determine if it is of standards-track quality.
2008-06-19
05 Chris Newman [Ballot Position Update] New position, Abstain, has been recorded by Chris Newman
2008-06-19
05 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2008-06-19
05 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-06-19
05 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-06-19
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2008-06-18
05 Pasi Eronen
[Ballot discuss]
So far, all crypto algorithms have been Informational RFCs -- it
seems this should be Informational, too.

Sections 6.1/6.2/6.3 say that P_MAX, A_MAX, …
[Ballot discuss]
So far, all crypto algorithms have been Informational RFCs -- it
seems this should be Informational, too.

Sections 6.1/6.2/6.3 say that P_MAX, A_MAX, N_MAX and C_MAX are
"unlimited"; this isn't literally true (the paper [DAE] seems to
suggest limit of 2^64 blocks; 800-38B recommends that CMAC-AES
shouldn't be used for more than 2^48 blocks, etc.).
2008-06-18
05 Russ Housley
[Ballot comment]
It would be very helpful to spell out SIV in the Abstract and Title.

  Section 7: s/SIV provides privacy/SIV provides confidentiality/

  …
[Ballot comment]
It would be very helpful to spell out SIV in the Abstract and Title.

  Section 7: s/SIV provides privacy/SIV provides confidentiality/

  Section 7: s/unable to construct a string of bits/
              /unable to construct an alternate string of bits/
2008-06-18
05 Russ Housley
[Ballot discuss]
DISCUSS DISCUSS: The IETF generally publishes cryptographic
  algorithms and modes as Informational RFCs.  There are exceptions.
  Why is this one appropriate …
[Ballot discuss]
DISCUSS DISCUSS: The IETF generally publishes cryptographic
  algorithms and modes as Informational RFCs.  There are exceptions.
  Why is this one appropriate for the standards track?
2008-06-18
05 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-06-18
05 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-06-18
05 Cullen Jennings [Ballot comment]
Support Pasi discuss.
2008-06-18
05 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-06-18
05 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2008-06-18
05 Pasi Eronen [Ballot comment]
Reference [DAE] should be informative (it's not required to
implement), and should have more bibliographic details (where it was
published).
2008-06-18
05 Pasi Eronen
[Ballot discuss]
So far, all crypto algorithms have been Informational RFCs -- it
seems this should be Informational, too.

Sections 6.1/6.2/6.3 say that P_MAX, A_MAX, …
[Ballot discuss]
So far, all crypto algorithms have been Informational RFCs -- it
seems this should be Informational, too.

Sections 6.1/6.2/6.3 say that P_MAX, A_MAX, N_MAX and C_MAX are
"unlimited"; this isn't literally true (the paper [DAE] seems to
suggest limit of 2^64 blocks; 800-38B recommends that CMAC-AES
shouldn't be used for more than 2^48 blocks, etc.).

Sections 6.1/6.2/6.3: shouldn't N_MIN be 0 instead of 1?
2008-06-18
05 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2008-06-16
05 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2008-06-16
05 Tim Polk Ballot has been issued by Tim Polk
2008-06-16
05 Tim Polk Created "Approve" ballot
2008-06-11
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-06-11
04 (System) New version available: draft-dharkins-siv-aes-04.txt
2008-06-10
05 Tim Polk State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Tim Polk
2008-06-10
05 Tim Polk State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk
2008-06-10
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-05-27
05 Amanda Baber
IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Authenticated Encryption with Associated Data
(AEAD) Parameters" …
IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Authenticated Encryption with Associated Data
(AEAD) Parameters" registry at
http://www.iana.org/assignments/aead-parameters

Numeric ID Name Reference
----------- ---------------------------- ---------
[tbd1] AEAD_SIV_CMAC_256 [RFC-dharkins-siv-aes-02]
[tbd2] AEAD_SIV_CMAC_384 [RFC-dharkins-siv-aes-02]
[tbd3] AEAD_SIV_CMAC_512 [RFC-dharkins-siv-aes-02]

We understand the above to be the only IANA Action for this
document.
2008-05-22
05 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Carl Wallace.
2008-05-21
05 Tim Polk Placed on agenda for telechat - 2008-06-19 by Tim Polk
2008-05-20
03 (System) New version available: draft-dharkins-siv-aes-03.txt
2008-05-15
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Carl Wallace
2008-05-15
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Carl Wallace
2008-05-13
05 Amy Vezza Last call sent
2008-05-13
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-05-13
05 Tim Polk State Changes to Last Call Requested from Publication Requested by Tim Polk
2008-05-13
05 Tim Polk Last Call was requested by Tim Polk
2008-05-13
05 (System) Ballot writeup text was added
2008-05-13
05 (System) Last call text was added
2008-05-13
05 (System) Ballot approval text was added
2008-04-17
05 Cindy Morgan
Document Shepherd Write-Up per IESG Guidelines for draft-dharkins-siv-aes-02
------------------------------------------------------------------------------

(1.a) Who is the Document Shepherd for this document? Has the Document
      Shepherd …
Document Shepherd Write-Up per IESG Guidelines for draft-dharkins-siv-aes-02
------------------------------------------------------------------------------

(1.a) Who is the Document Shepherd for this document? Has the Document
      Shepherd personally reviewed this version of the document and, in
      particular, does he or she believe this version is ready for
      forwarding to the IESG for publication?

  Dan Harkins is the Document Shepherd. He has reviewed the -02
  version of the draft and believes it is ready for forwarding
  to the IESG for publication.

(1.b) Has the document had adequate review both from key members of the
      interested community and others? Does the Document Shepherd have any
      concerns about the depth or breadth of the reviews that have been
      performed?

  The document has been announced on the CFRG mailing. The document
  has been reviewed by both Phil Rogaway and David McGrew. The
  former is significant because the draft describes a cipher mode
  he co-designed, the latter is significant because the draft modifies
  an IANA registry he created with RFC5116.

  The Document Shepherd would feel much better if more people
  on the CFRG mailing list had voiced an opinion but does not think
  this signifies any flaws in the draft.

(1.c) Does the Document Shepherd have concerns that the document needs more
      review from a particular or broader perspective, e.g., security,
      operational complexity, someone familiar with AAA, internationalization
      or XML?

  The Document Shepherd does not believe the document needs review
  outside of the CFRG mailing list.

(1.d) Does the Document Shepherd have any specific concerns or issues with this
      document that the Responsible Area Director and/or the IESG should be aware
      of? For example, perhaps he or she is uncomfortable with certain parts of
      the document, or has concerns whether there really is a need for it. In any
      event, if the interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail those concerns
      here.

  There are two independent implementations of the "S2V with AES-CMAC"
  construction that is part of SIV but there is no other known
  implementation of the entire draft. The Document Shepherd
  feels that the test vectors for the complex S2V construction
  are correct. The other portion is CTR mode which has considerable
  test vectors to check correctness. Therefore the test vectors
  were not wholistically verified by another full SIV implementation.

  The IANA considerations modify a registry for the first time
  (after its creation by RFC5116). The cipher mode described by
  this draft has a critical difference between the cipher modes
  initially placed in the registry by RFC5116 and it is the
  draft author's opinion that the IANA considerations are correct
  but the Document Shepherd has a nagging concern regarding them.
  That concern involves the "MAX" definitions in the AEAD
  registry and whether those are physical limits or theoretical
  ("safe to here but the security guarantee is lost after here")
  limits. He feels they are physical but RFC5116 was not explicit
  on the mater.

(1.e) How solid is the consensus of the interested community behind this document?
      Does it represent the strong concurrence of a few individuals, with others
      being silent, or does the interested community as a whole understand and agree
      with it?

          The document solves a problem that has been discussed in the past
  on the CFRG list. That problem concerns the construction and
  management of nonces and the consequences of their not being managed
  correctly. SIV provides (a level of) security even when nonces are
  re-used (unlike other AEAD cipher modes like GCM and CCM) and is an
  important cipher mode.

  In addition SIV can be used in a deterministic "key wrapping"
  varient. Since SIV allows for AAD it is more useable than RFC3394.
  There is interest in WGs of the IETF (e.g. RADEXT) to use this
  particular varient.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
      so, please summarise the areas of conflict in separate email messages to the
      Responsible Area Director. (It should be in a separate email because this
      questionnaire is entered into the ID Tracker.)

  Noone has expressed any discontent with this document.

(1.g) Has the Document Shepherd personally verified that the document satisfies all
      ID nits? (See http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this
      check needs to be thorough. Has the document met all formal review criteria it
      needs to, such as the MIB Doctor, media type and URI type reviews?

  Yes, the idnits tool had no errors, no warnings, and identified
  3 comments all concerning using non-RFCs in normative
  references (see 1.h below).

(1.h) Has the document split its references into normative and informative? Are there
      normative references to documents that are not ready for advancement or are
      otherwise in an unclear state? If such normative references exist, what is the
      strategy for their completion? Are there normative references that are downward
      references, as described in [RFC3967]? If so, list these downward references to
      support the Area Director in the Last Call procedure for them [RFC3967].

  There are normative and informative references. All normative
  references exist. There are 3 "downward references":

  [CMAC]    Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: The CMAC Mode for Authentication", NIST Special
              Pulication 800-38B.

  [DAE]      Rogaway, P. and T. Shrimpton, "Deterministic Authenticated
              Encryption, A Provable-Security Treatment of the Key-Wrap
              Problem", September 2006.

  [MODES]    Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: Methods and Techniques", NIST Special
              Pulication 800-38A, 2001 edition.

  The Document Shepherd would welcome another opinion on whether
  these can be made Informative.

(1.i) Has the Document Shepherd verified that the document IANA consideration section
      exists and is consistent with the body of the document? If the document specifies
      protocol extensions, are reservations requested in appropriate IANA registries?
      Are the IANA registries clearly identified? If the document creates a new registry,
      does it define the proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggested a reasonable name for the
      new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document
      describes an Expert Review process has Shepherd conferred with the Responsible
      Area Director so that the IESG can appoint the needed Expert during the IESG
      Evaluation?

  The IANA Considerations section exists, is consistant, and
  clearly identifies the actions IANA is to take.

(1.j) Has the Document Shepherd verified that sections of the document that are written
      in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate
      correctly in an automated checker?

  There are no formal languages such as XML code, BNF rules,
  or MIB definitions in the draft.
2008-04-17
05 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-02-25
02 (System) New version available: draft-dharkins-siv-aes-02.txt
2007-11-19
01 (System) New version available: draft-dharkins-siv-aes-01.txt
2007-07-03
00 (System) New version available: draft-dharkins-siv-aes-00.txt