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 |