Skip to main content

Last Call Review of draft-ietf-curdle-cms-chacha20-poly1305-04
review-ietf-curdle-cms-chacha20-poly1305-04-secdir-lc-nir-2016-12-11-00

Request Review of draft-ietf-curdle-cms-chacha20-poly1305
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-12-16
Requested 2016-12-02
Authors Russ Housley
I-D last updated 2016-12-11
Completed reviews Opsdir Last Call review of -04 by Niclas Comstedt (diff)
Genart Last Call review of -04 by Matthew A. Miller (diff)
Secdir Last Call review of -04 by Yoav Nir (diff)
Opsdir Telechat review of -05 by Niclas Comstedt (diff)
Genart Telechat review of -05 by Matthew A. Miller (diff)
Assignment Reviewer Yoav Nir
State Completed
Request Last Call review on draft-ietf-curdle-cms-chacha20-poly1305 by Security Area Directorate Assigned
Reviewed revision 04 (document currently at 06)
Result Has nits
Completed 2016-12-11
review-ietf-curdle-cms-chacha20-poly1305-04-secdir-lc-nir-2016-12-11-00
Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

Summary: Ready with nits.

Introduction
   ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key
   and a 96-bit nonce.  ChaCha20 is described in [FORIETF].

ChaCha20 is described in DJB's paper. RFC 7539 just repeats the definition with
more detail, examples and test vectors. Same for Poly1305 in the next paragraph.

Section 3 describes how to use AEAD_CHACHA20_POLY1305 with AuthEnvelopedData.
The algorithm, as stated in section 1.1 has four inputs: a 256-bit key, a
96-bit nonce, an arbitrary length plaintext, and an arbitrary length additional
authenticated data (AAD). The key is generated by one of the methods in section
2 (Key Management); the nonce is generated by the sender. The text requires
that it be unique, but does not mandate of suggest a way of doing this. This is
fine. The plaintext according to section 3 is "the content located in the
AuthEnvelopedData EncryptedContentInfo encryptedContent field". and the tag is
stored in the AuthEnvelopedData mac field.

What's missing is the AAD. I could not find what goes into the AAD. This is
described in section 2.2 of RFC 5083, but it should be either repeated here or
referenced. It's jarring that the other inputs are described while this one is
omitted.

The Security Considerations section seems fine.

Yoav