Document Action: 'SIV Authenticated Encryption using AES' to Informational RFC

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 mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce