The IESG has approved the following document: - 'SIV Authenticated Encryption using AES ' <draft-dharkins-siv-aes-05.txt> as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dharkins-siv-aes-05.txt Technical Summary 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" variant. Since SIV allows for AAD it is more useable than RFC3394. Working Group Summary This document is not the product of any IETF working group, but has been discussed on the CFRG list and presented at IETF meetings in several working groups. There is interest in WGs of the IETF (e.g. RADEXT) to use this particular mode. Document Quality This mode has been widely discussed in academic circles, and 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. Personnel Dan Harkins is the Document Shepherd for this document. The Responsible Area Director is Tim Polk. IANA Note 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 matter. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
