Re: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04

[Russ Housley <[e-mail]>]

Yoav:

Thanks for the review.  The document will be more clear about the handling of AAD because you reviewed it.

> 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.

The point of RFC 7539, I believe, is a reference that is readily available to the Internet community.  Does this rewording resolve your concern?

[FORIETF] provides a detailed algorithm description, examples, and test vectors of ChaCha20.

[FORIETF] also provides a detailed algorithm description, examples, and test vectors of Poly1305.


> 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.

I suggest the following replacement for the third paragraph in Section 3.

   The AEAD_CHACHA20_POLY1305 algorithm is used to authenticate the
   attributes located in the AuthEnvelopedData authAttrs field, if any
   are present, encipher the content located in the AuthEnvelopedData
   EncryptedContentInfo encryptedContent field, and to provide the
   message authentication code (MAC) located in the AuthEnvelopedData
   mac field.  The authenticated attributes are DER encoded to produce
   the AAD input value to the AEAD_CHACHA20_POLY1305 algorithm.  The
   ciphertext and the MAC are the two outputs of the
   AEAD_CHACHA20_POLY1305 algorithm.  Note that the MAC, which is called
   the authentication tag in [FORIETF], provides integrity protection
   for both the AuthEnvelopedData authAttrs and the AuthEnvelopedData
   EncryptedContentInfo encryptedContent.

Thanks,
  Russ