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