RE: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04
Jim Schaad <ietf@augustcellars.com> Mon, 12 December 2016 22:11 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC91B12943B; Mon, 12 Dec 2016 14:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level:
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mlk2zrq5eIFd; Mon, 12 Dec 2016 14:11:47 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBC9129793; Mon, 12 Dec 2016 14:11:43 -0800 (PST)
Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 14:31:18 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Yoav Nir' <ynir.ietf@gmail.com>, secdir@ietf.org
References: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com>
In-Reply-To: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com>
Subject: RE: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04
Date: Mon, 12 Dec 2016 14:11:34 -0800
Message-ID: <0e1501d254c4$b542c1e0$1fc845a0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQNAj1+knqelScWc7hRTFF3lbOB1zp4oahLg
Content-Language: en-us
X-Originating-IP: [173.8.216.38]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/uF_jPciXs940kObTFY4si5FvSx8>
Cc: curdle@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 22:11:51 -0000
> -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Yoav Nir > Sent: Sunday, December 11, 2016 5:14 AM > To: secdir@ietf.org > Cc: curdle@ietf.org; draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org; > ietf@ietf.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@ietf.org > https://www.ietf.org/mailman/listinfo/curdle