> -----Original Message----- > From: Curdle [mailto:curdle-bounces@xxxxxxxx] On Behalf Of Yoav Nir > Sent: Sunday, December 11, 2016 5:14 AM > To: secdir@xxxxxxxx > Cc: curdle@xxxxxxxx; draft-ietf-curdle-cms-chacha20-poly1305.all@xxxxxxxx; > ietf@xxxxxxxx > Subject: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 > > Reviewer: Yoav Nir > Review result: Has Nits > > 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. ChaCha20 was originally described in DJB's paper. There is still a complete description of the algorithm in [FORIETF]. Once could argue that it is a more complete description since it includes examples and test vectors. > > 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. That seems reasonable to add. Jim > > The Security Considerations section seems fine. > > Yoav > > _______________________________________________ > Curdle mailing list > Curdle@xxxxxxxx > https://www.ietf.org/mailman/listinfo/curdle