Review of draft-ietf-curdle-cms-chacha20-poly1305-04

[Yoav Nir <[e-mail]>]

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.

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