-----Original Message-----
From: Curdle [mailto:curdle-bounces(_at_)ietf(_dot_)org] On Behalf Of Yoav Nir
Sent: Sunday, December 11, 2016 5:14 AM
To: secdir(_at_)ietf(_dot_)org
Cc: curdle(_at_)ietf(_dot_)org;
draft-ietf-curdle-cms-chacha20-poly1305(_dot_)all(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/curdle