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

[Stephen Farrell <[e-mail]>]

Hiya,

I think we've one change pending from Yoav's review. There
were also some nits from the opsdir review [1] posted over
the holidays.

Do we think we can have an update with those fixes in the
next week? If so, I'll put this on the Jan 19th telechat
for approval. (If it's somehow easier for these changes to
be done as an RFC editor note, that's fine too - just
send me the text for that.)

Thanks,
S.

[1]
https://datatracker.ietf.org/doc/review-ietf-curdle-cms-chacha20-poly1305-04-opsdir-lc-comstedt-2016-12-24/

On 12/12/16 22:11, Jim Schaad wrote:
> 
> 
>> -----Original Message-----
>> From: Curdle [mailto:[e-mail]] On Behalf Of Yoav Nir
>> Sent: Sunday, December 11, 2016 5:14 AM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail];
>> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/curdle
> 
>