From nobody Tue Oct 4 14:43:15 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27BB126D74 for ; Tue, 4 Oct 2016 14:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1NVjVugIKxJN for ; Tue, 4 Oct 2016 14:43:12 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45B01294FF for ; Tue, 4 Oct 2016 14:43:11 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id j37so73388551ioo.3 for ; Tue, 04 Oct 2016 14:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YWvk/luVzrbtgJlgnsEyDTHrgE+9K/STFp/CkUk2Y1c=; b=T0UghPjSQbFjd8jNC7JupHHsPrYxAm4Wi3tfMEPas1P2bk4bkeTXkCImSL6eT8aNuo wb+7NiEbsS1btSjg2jxYVEBZMM6DWo0AOWGleVX8YsNNtnG7xcV+zF0cSJcPvO/agUSn AcHT3I71gj2IH/LK+YpVG4QpS4uknnCZGU21ZfguQbQ1G1cMrq4b7J7+ZczosJ/BBfLH TSEfRnFgxsXV0T0KylkHnoKwCvzs4lSHkRe3Y4GhEw7ufn79dnd9kEOEhLLzSYh/uiAE CW25oqk/UfDDw4Die9iSgvtqmPoi62/MppfJPKm8wnVVAWEPx8GsbhkvPhgIqEQx71Bu QmoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YWvk/luVzrbtgJlgnsEyDTHrgE+9K/STFp/CkUk2Y1c=; b=UFebfwyU8UuwYm1SgmA7UGPMQMPLxt7nRrA4eB4JSHZm6OGuXCmufkdbqTNH0u8Bh5 +UAjh+NcqsjWMY0R5tJLGPoQK+vMcSgN+nVNXUeI4JhOq5UexxvzrEp1OVzrg+A4W1vb IHcexPUi5IZq5nTPWON5Pi4a76vVvKY9+NcqLJAgC1w1nzuiOt3p8DtoyWvxbBT3Q3Tn BzWOyL6nQW87a5x9/GfQWbZ/vnmmMBpg1TDjhFR7TBxtIB/bPLZQxItII5XXeCgamBr/ dBbbINwockEnwKDj93U9eeBNgLmf8yN2QVvTDE18jkS9eFZIpi+ILAZbCnGmcVeWtayQ hZyQ== X-Gm-Message-State: AA6/9Rmrqz/0/4I73TkXlYWk79ANwORRfIyIBE4qcYAi9iwIWzZ8RqMF1oC5PHjdJDS2YVp8ZCICG91qFO+MKQ== X-Received: by 10.107.164.103 with SMTP id n100mr6406421ioe.35.1475617390969; Tue, 04 Oct 2016 14:43:10 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.170.70 with HTTP; Tue, 4 Oct 2016 14:43:10 -0700 (PDT) In-Reply-To: <1f1d004911c0447fb5594b9a4ad78a8b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <147455438388.22522.16339907641035668344.idtracker@ietfa.amsl.com> <313384B3-818D-4CFA-81C4-005A9F551C72@vigilsec.com> <1f1d004911c0447fb5594b9a4ad78a8b@usma1ex-dag1mb1.msg.corp.akamai.com> From: Daniel Migault Date: Tue, 4 Oct 2016 17:43:10 -0400 X-Google-Sender-Auth: TpL7I60WMQOqD0Hq4Vbsv5xFNL4 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a1141c95669c9f1053e10f2a8 Archived-At: Cc: "curdle@ietf.org" , Russ Housley Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 21:43:14 -0000 --001a1141c95669c9f1053e10f2a8 Content-Type: text/plain; charset=UTF-8 Hi, I have reviewed the document. The document is clear to me and is ready to be sent to the IESG. I have some editorial comments/suggestions. Feel free to ignore them. BR, Daniel 1.1. The ChaCha20 and Poly1305 AEAD Construction As all length key size and paddings are mentionned, it might be usefull for completeness to specify the length of the poly1305 key. That said as the poly1305 and the input key have and the input key is designated as 256-bit key. In order to differentiate the input key from other 256-bit key, it might be good to replace "256-bit key" by "256-bit input key" or some equivalent. OLD: 1) A 256 bit Poly1305 one-time key is generated from the 256-bit key and and nonce using the procedure described in Section 2.6 of [FORIETF]. NEW: 1) A 256 bit Poly1305 one-time key is generated from the 256-bit key and and nonce using the procedure described in Section 2.6 of [FORIETF]. For clarity, it might be better to explicitly mention the key. The proposed text designates the input key as 256-bit key. OLD 2) The ChaCha20 encryption function is used to encrypt the plaintext, using the same key and nonce, and with the initial counter set to 1. NEW 2) The ChaCha20 encryption function is used to encrypt the plaintext, using the same 256-bit key and nonce, and with the initial counter set to 1. 2. Automated Key Management My understanding of [KEYMGM] is that to avoid the reuse of IV is a necessary condition for an automated key management. If nonce can be considered as an IV, I think the reason can be more explicit. OLD: The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key destroys the security guarantees. As a result, it can be extremely difficult to use AEAD_CHACHA20_POLY1305 securely when using statically configured keys. For safety's sake, implementations MUST use an automated key management system [KEYMGMT]. NEW: The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key destroys the security guarantees and means must be provided to maintain (key, nonce) unique. As mentioned in [KEYMGMT] this is a necessary arument to mandate an automated key management system. Depending on the cases additional requirements may be met, such as the possibility to update the key regularly. I am not sure this can be useful. In addition, nonce SHOULD NOT be generated randomly, but nonce generation SHOULD be managed, especially when the same key is used in different sessions. Note that, when the key is dedicated to a single session, key management may replace the nonce generation. Security Consideration. I noticed a one block difference with RFC7539 of one block. rfc7539#section-2.6 mentions: """ This limits the use of a single (key,nonce) combination to 2^32 blocks """ cms-chacha20 mentions: """ The amount of encrypted data possible in a single invocation of AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each """ On Thu, Sep 22, 2016 at 11:59 AM, Salz, Rich wrote: > > This update addresses the comments from Jim Schaad. > > > > I believe that this document is ready for WG Last Call. > > Looking through the archives, I believe all open issues have been > addressed. > > We'll now being a two-week WG last call, before passing it along to the > IESG. > > /r$, co-chair > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a1141c95669c9f1053e10f2a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have reviewed the docum= ent. The document is clear to me and is ready to be sent to the IESG. I hav= e some editorial comments/suggestions. Feel free to ignore them.

BR,
Daniel



1.1.=C2=A0 The ChaCha20 a= nd Poly1305 AEAD Construction

As all length key size and paddings ar= e mentionned, it might be usefull for completeness to specify the length of= the poly1305 key. That said as the poly1305 and the input key have and the= input key is designated as 256-bit key. In order to differentiate the inpu= t key from other 256-bit key, it might be good to replace "256-bit key= " by "256-bit input key" or some equivalent.

OLD:=C2= =A0
1) A 256 bit Poly1305 one-time key is generated from the 256-bit ke= y and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and nonce using t= he procedure described in Section 2.6 of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 [FORIETF].
NEW:
1) A 256 bit Poly1305 one-time key= is generated from the 256-bit key and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 and nonce using the procedure described in Section 2.6 of=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [FORIETF].
=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 =C2=A0
For clarity, it might be better to explicitly mention the key= . The proposed text designates the input key as=C2=A0 256-bit key.
=C2= =A0
OLD
2) The ChaCha20 encryption function is used to encrypt the=C2=A0=C2=A0 plaintext, using the same key and nonce, and with the initial=
=C2=A0=C2=A0 counter set to 1.
NEW
2) The ChaCha20 encryption fun= ction is used to encrypt the
=C2=A0=C2=A0 plaintext, using the same 256-= bit key and nonce, and with the initial
=C2=A0=C2=A0 counter set to 1.= =C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A02.=C2=A0 Automated= Key Management

My understanding of [KEYMGM] is that to avoid the re= use of IV is a necessary condition for an automated key management. If nonc= e can be considered as an IV, I think the reason can be more explicit.=C2= =A0

OLD:
=C2=A0=C2=A0 The reuse of an AEAD_CHACHA20_POLY1305 non= ce value with the same key
=C2=A0=C2=A0 destroys the security guarantees= .=C2=A0 As a result, it can be extremely
=C2=A0=C2=A0 difficult to use A= EAD_CHACHA20_POLY1305 securely when using
=C2=A0=C2=A0 statically config= ured keys.=C2=A0 For safety's sake, implementations MUST
=C2=A0=C2= =A0 use an automated key management system [KEYMGMT].

NEW:
=C2=A0= =C2=A0 The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key=
=C2=A0=C2=A0 destroys the security guarantees and means must be provide= d to maintain (key, nonce) unique. As mentioned in [KEYMGMT] this is a nece= ssary arument to mandate an automated key management system. Depending on t= he cases additional requirements may be met, such as the possibility to upd= ate the key regularly.

=C2=A0I am not sure this can be useful.
= =C2=A0=C2=A0 In addition, nonce SHOULD NOT be generated randomly, but nonce= generation SHOULD be managed, especially when the same key is used in diff= erent sessions. Note that, when the key is dedicated to a single session, k= ey management may replace the nonce generation.
=C2=A0=C2=A0
Securi= ty Consideration.

I noticed a one block difference with RFC7539 of o= ne block.
=C2=A0=C2=A0
rfc7539#section-2.6 mentions:
""= "
=C2=A0This limits the use of
=C2=A0a single (key,nonce) combin= ation to 2^32 blocks
"""
cms-chacha20 mentions:
&qu= ot;""
The amount of encrypted data possible in a single invoca= tion of
=C2=A0=C2=A0 AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octet= s each
"""




On Thu, Sep 22, 2016 at 11:59 = AM, Salz, Rich <rsalz@akamai.com> wrote:
> This update addresses the comments from= Jim Schaad.
>
> I believe that this document is ready for WG Last Call.

Looking through the archives, I believe all open issues have been ad= dressed.

We'll now being a two-week WG last call, before passing it along to the= IESG.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /r$, co-chair

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a1141c95669c9f1053e10f2a8-- From nobody Mon Oct 10 06:46:50 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9114B1296D6; Mon, 10 Oct 2016 06:46:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147610720658.31424.9172801361589123946.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2016 06:46:46 -0700 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 13:46:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : EdDSA for DNSSEC Authors : Ondrej Sury Robert Edmonds Filename : draft-ietf-curdle-dnskey-eddsa-01.txt Pages : 8 Date : 2016-10-10 Abstract: This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-dnskey-eddsa-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 10 06:50:54 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC3F129411; Mon, 10 Oct 2016 06:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.996 X-Spam-Level: X-Spam-Status: No, score=-9.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 oGeUoHfjFgV4; Mon, 10 Oct 2016 06:50:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5F6128E19; Mon, 10 Oct 2016 06:50:46 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 3DA8C6098D; Mon, 10 Oct 2016 15:50:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1476107445; bh=tVB94lt/xelSQL+N88JKtFiT3FTN9u0UyS3mefK0TDc=; h=Date:From:To; b=Cxw//TbelW3x1j1zf6eE+0PtYzISZYzDiJwl6pPF/tJdB/O2RUGBrb42i8bqi1ZVZ lh4kql0oZsdeCndx5dzbuzHZtG3qczFGbQIiB8SiqYrLxlSfms2Mht8Wh2ygV/56LT ambDH5nRH67Zfnicli2e1ffFKphDUFtJ0BWqanQw= Date: Mon, 10 Oct 2016 15:50:45 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: dnsop , curdle@ietf.org Message-ID: <1345867837.3524.1476107445205.JavaMail.zimbra@nic.cz> In-Reply-To: <147610720658.31424.9172801361589123946.idtracker@ietfa.amsl.com> References: <147610720658.31424.9172801361589123946.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF49 (Linux)/8.7.0_GA_1659) Thread-Topic: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt Thread-Index: Yl00YnlaBCkHauU322tsOkEZp/HHMg== X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [Curdle] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 13:50:49 -0000 Dear colleagues, this is just a refresh to keep the draft going as we are still waiting for irtf-cfrg-eddsa, but that looks like it's in IESG Review, so it might be a good time to have a final look and send the comments to /me or Robert or curdle WG mailing list. 1. https://datatracker.ietf.org/doc/draft-irtf-cfrg-eddsa/ Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Forwarded Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: curdle@ietf.org Sent: Monday, 10 October, 2016 15:46:46 Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the CURves, Deprecating and a Little more Encr= yption of the IETF. Title : EdDSA for DNSSEC Authors : Ondrej Sury Robert Edmonds =09Filename : draft-ietf-curdle-dnskey-eddsa-01.txt =09Pages : 8 =09Date : 2016-10-10 Abstract: This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-dnskey-eddsa-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Sat Oct 15 14:22:41 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568C9129578; Sat, 15 Oct 2016 14:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, 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 eckE8XVAeU9x; Sat, 15 Oct 2016 14:22:37 -0700 (PDT) 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 D5857129563; Sat, 15 Oct 2016 14:22:36 -0700 (PDT) Received: from hebrews (50.45.239.150) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 15 Oct 2016 14:35:22 -0700 From: Jim Schaad To: 'Deirdre Connolly' , , References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sat, 15 Oct 2016 14:21:59 -0700 Message-ID: <01ab01d2272a$2c0a7c00$841f7400$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AC_01D226EF.7FAED850" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQK2d0TroNuVIE0A27Dc80J1726oxAFE/8j7ntc9qBA= X-Originating-IP: [50.45.239.150] Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 21:22:39 -0000 ------=_NextPart_000_01AC_01D226EF.7FAED850 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes that would be me unable to type for some reason. I seem to want to = do this spelling error on a regular basis and I don=E2=80=99t know why. =20 Jim =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Deirdre = Connolly Sent: Friday, September 30, 2016 11:09 AM To: internet-drafts@ietf.org; i-d-announce@ietf.org Cc: curdle@ietf.org Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt =20 Nit:=20 =20 > This document specify algorithm identifiers and ASN.1 encoding = formats for Elliptical Curve constructs... =20 'Elliptical' is not commonly used, 'elliptic' is more normative. = 'Elliptic' is used 7 times in the draft, this is the only usage of = 'elliptical'. =20 =20 On Fri, Aug 19, 2016 at 8:30 AM > wrote: A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. Title : Algorithm Identifiers for Ed25519, Ed25519ph, = Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key = Infrastructure Authors : Simon Josefsson Jim Schaad Filename : draft-ietf-curdle-pkix-01.txt Pages : 15 Date : 2016-08-15 Abstract: This document specify algorithm identifiers and ASN.1 encoding formats for Elliptical Curve constructs using the Curve25519 and Curve448 curves. The signature algorithms covered are Ed25519, Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered are X25519 and X448. The Encoding for Public Key, Private Key and EdDSA digital signature structures is provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-pkix-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix-01 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org = . Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_01AC_01D226EF.7FAED850 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Yes that = would be me unable to type for some reason.=C2=A0 I seem to want to do = this spelling error on a regular basis and I don=E2=80=99t know = why.

 

Jim

 

 

From:<= /b> = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Deirdre = Connolly
Sent: Friday, September 30, 2016 11:09 = AM
To: internet-drafts@ietf.org; = i-d-announce@ietf.org
Cc: curdle@ietf.org
Subject: = Re: [Curdle] I-D Action: = draft-ietf-curdle-pkix-01.txt

 

Nit: 

 

> =  This document specify algorithm identifiers and ASN.1 encoding = formats for Elliptical Curve constructs...

 

'Elliptical' is not commonly used, 'elliptic' is more = normative. 'Elliptic' is used 7 times in the draft, this is the only = usage of 'elliptical'.

 

 

On = Fri, Aug 19, 2016 at 8:30 AM <internet-drafts@ietf.org>= wrote:


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the CURves, Deprecating and = a Little more Encryption of the IETF.

        = Title           : Algorithm Identifiers = for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the = Internet X.509 Public Key Infrastructure
        = Authors         : Simon Josefsson
  =                     =     Jim Schaad
        Filename  =       : draft-ietf-curdle-pkix-01.txt
    =     Pages           : = 15
        Date          =   : 2016-08-15

Abstract:
   This document = specify algorithm identifiers and ASN.1 encoding
   formats = for Elliptical Curve constructs using the Curve25519 and
  =  Curve448 curves.  The signature algorithms covered are = Ed25519,
   Ed25519ph, Ed448 and Ed448ph.  The key = agreement algorithm covered
   are X25519 and X448.  = The Encoding for Public Key, Private Key and
   EdDSA = digital signature structures is provided.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix= /

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-curdle-pkix-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-p= kix-01


Please note that it may take a couple of minutes = from the time of submission
until the htmlized version and diff are = available at tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

________= _______________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

------=_NextPart_000_01AC_01D226EF.7FAED850-- From nobody Fri Oct 21 16:22:44 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEEE129513; Fri, 21 Oct 2016 16:21:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709206778.28214.4418682669945568170.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:07 -0700 Archived-At: Cc: curdle@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Curdle] curdle - Requested session has been scheduled for IETF 97 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:08 -0000 Dear Daniel Migault, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. curdle Session 1 (1:00:00) Friday, Afternoon Session I 1150-1320 Room Name: Studio 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: CURves, Deprecating and a Little more Encryption Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: lamps acme trans sacm tcpinc saag ipsecme i2nsf tls radext Second Priority: dots Special Requests: --------------------------------------------------------- From nobody Wed Oct 26 10:37:42 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D045129582 for ; Wed, 26 Oct 2016 10:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1-d0ICWEG85j for ; Wed, 26 Oct 2016 10:37:38 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B4D129557 for ; Wed, 26 Oct 2016 10:37:38 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id u124so12289136ywg.3 for ; Wed, 26 Oct 2016 10:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=gEVLJRnl6inVuaKtGvADCvBSKdu0Lq/33YRj69KfLgU=; b=hf+eOelq0RXlafUOgrEp9xRIvpUi/ECqrsJQjgBht9uCkohLknfildfHkTFFZo358G mbU5akDXFnZAfml0/nsSdzyv0/RB3uG1FtJzYHqZTz3l2S24iwbInPN8C3/2v6xCUvqm LZFJZLtFy9CfTfJVBBDpKiwzwWXq9YRY6yCfjZlOMUuOCzHrsQvJycMf/wIwI18K+rA8 a8ZZ1W1DaifN8eVQToa2XMkD9r9qfx2tXRYNkxQSUANTOvY1fwdPB9zmDmLugsT3meuO iX4C5XZmwDTJHyNEq0H+lUZKlkzq9d6ST++F+sgFYdR6SSJzWKU4J8jsKRzc9c5feKxY 8Wvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=gEVLJRnl6inVuaKtGvADCvBSKdu0Lq/33YRj69KfLgU=; b=gXvO8M/5Uh9Zp7VmRtVJbZxKiF0tFftGCzrYwpUSgiSXnNll5/BznbMiNOoHj4HtR7 v1r8k7RQpCpA4kIfGxwIz/doA8/20ZQIqzw7qzvc/aXP4g3bzhyPV2JgvL3lSuvbmAth JwYzz/9RAVr1g1A4OlDgMMV9HjAyKVPbYPjAxoUuhGA3hQuX2fDaGFys0bZxHFx+N120 c9mrP86spl2pC+huQdPH3dU7nBZ9fgWmKT/RgoEpywdFDLBC2hv/uiOUmnZ7yiKiwxzE TbYcA4duOkfMMcdFWmeDomWAreqFnS7stKzu2f0CryOmdPh6EAQP7RcxpP1Fx7bcaTMP mpHQ== X-Gm-Message-State: ABUngvcJupPtqo6JVQWnOqz0rZVlp2pei2MwOD9/IYOvtXBq2QgnioWhXC6NJZlGvFw7e3WT9c+JR9HiyszSZw== X-Received: by 10.36.175.83 with SMTP id l19mr7493214iti.48.1477503456938; Wed, 26 Oct 2016 10:37:36 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Wed, 26 Oct 2016 10:37:36 -0700 (PDT) From: Daniel Migault Date: Wed, 26 Oct 2016 13:37:36 -0400 X-Google-Sender-Auth: HYr3Iv7wCdcGUVqb4dOHBdq8Pjw Message-ID: To: curdle@ietf.org Content-Type: multipart/alternative; boundary=f403045dadc6b48f84053fc8142c Archived-At: Subject: [Curdle] CURDLE meeting in IETF97 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 17:37:39 -0000 --f403045dadc6b48f84053fc8142c Content-Type: text/plain; charset=UTF-8 Hi, We are preparing the CURDLE meeting at the IETF97 in Seoul. We would like to know who intends to present. In case you need slides for your presentation please provide the slides by Wednesday 16. Yours, Rich and Daniel --f403045dadc6b48f84053fc8142c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

=C2=A0

We are preparing the CURDLE meeting at the IETF97 in= Seoul. We would like to know who intends to present. In case you need slides for y= our presentation please provide the slides by Wednesday 16.

=C2=A0

Yours,

Rich and Daniel

=C2=A0

--f403045dadc6b48f84053fc8142c-- From nobody Wed Oct 26 11:20:13 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5E6129429 for ; Wed, 26 Oct 2016 11:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 usw7RINpUM1Z for ; Wed, 26 Oct 2016 11:20:10 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D661295B5 for ; Wed, 26 Oct 2016 11:20:09 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id w3so14086112ywg.1 for ; Wed, 26 Oct 2016 11:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GQvVD8lTFR+gO/2mxDnWoFFQCcD7mCBDkW1vZaWD9Zs=; b=uliPQ3El7vGVjoCUJohuljSb5Xa1FEfNVWsO/oNwHfxsQpYjsgkzgbtEjhhnlLYNdo gDZvHe1PMxRVRqnnFRO3GmAwk5lyYWNQr0nDJbnvq66VDuf97rqU1xeauKzQw0QZHbXn UgWjEvnLWGGm5c9upZpmtH/qAPcCVomneNVB1Q+pba+kHPpufYw/ubTAAXIV8PFbl/7c 4E3GnbmhFVTmhmfcje4oC/XMQ4oyY0ZWRgLxIcZRg+ltQ5X2Btk5qNs1jBotvisGVfza yNZpb5bdAh7xoQz8eG79kJATH/5rvNxDWd+/MlGc5kkXpvDY2aeTkgXFGK9BrClUP57v 36rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GQvVD8lTFR+gO/2mxDnWoFFQCcD7mCBDkW1vZaWD9Zs=; b=iZIHnCFqazG7vIWbrzquMWcAtjqkDYceThB+YhICBa/mOHTCaCAmcISqRYILi7KRFa Z3WSejhTUioApRJrI21ryE0u6avS6jSJ4kYQfucuykIZM6ON7/YBTPkCYd0+BiXGB7ED w8701aeLGO4k9u4h0lCCMSHZ6w9QHXlZg5pVSzIM7xPN6k79czs3DhlpRlfRlQfa9t7C Y1DssYQ+Mshz7caRKsM+ERNb1gV+cpI5saq2RUeKt3dP0Kj0yLRqvrBnrTeMR9fuFHgL 91JzcKc0aFfo3hFY5c901+/KkUWH83xrzvKfJmuYAc89c0m07Ui+aVdW0lRJiunNEZMN LpEw== X-Gm-Message-State: ABUngvdql02Lw46MWayUGRZjTOdeB+QRxjCkaWo02zx3r5wevxAd83e4NC6p2TUfpYbmaGbypHl+vCt6QnTEaA== X-Received: by 10.36.95.2 with SMTP id r2mr3718796itb.48.1477506009098; Wed, 26 Oct 2016 11:20:09 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Wed, 26 Oct 2016 11:20:08 -0700 (PDT) In-Reply-To: References: <147455438388.22522.16339907641035668344.idtracker@ietfa.amsl.com> <313384B3-818D-4CFA-81C4-005A9F551C72@vigilsec.com> <1f1d004911c0447fb5594b9a4ad78a8b@usma1ex-dag1mb1.msg.corp.akamai.com> From: Daniel Migault Date: Wed, 26 Oct 2016 14:20:08 -0400 X-Google-Sender-Auth: xsvXb-tFWgYpR04USc5gr2uq9vo Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11448ce0d36ee2053fc8ac2e Archived-At: Cc: "curdle@ietf.org" , Russ Housley Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 18:20:11 -0000 --001a11448ce0d36ee2053fc8ac2e Content-Type: text/plain; charset=UTF-8 Hi, The document has been in WGLC since September 22. No one opposed the adoption of draft-housley-cms-chacha20-poly1305 . The draft will be moved forwad. Yours, Rich and Daniel On Tue, Oct 4, 2016 at 5:43 PM, Daniel Migault wrote: > Hi, > > I have reviewed the document. The document is clear to me and is ready to > be sent to the IESG. I have some editorial comments/suggestions. Feel free > to ignore them. > > BR, > Daniel > > > > 1.1. The ChaCha20 and Poly1305 AEAD Construction > > As all length key size and paddings are mentionned, it might be usefull > for completeness to specify the length of the poly1305 key. That said as > the poly1305 and the input key have and the input key is designated as > 256-bit key. In order to differentiate the input key from other 256-bit > key, it might be good to replace "256-bit key" by "256-bit input key" or > some equivalent. > > OLD: > 1) A 256 bit Poly1305 one-time key is generated from the 256-bit key and > and nonce using the procedure described in Section 2.6 of > [FORIETF]. > NEW: > 1) A 256 bit Poly1305 one-time key is generated from the 256-bit key and > and nonce using the procedure described in Section 2.6 of > [FORIETF]. > > > For clarity, it might be better to explicitly mention the key. The > proposed text designates the input key as 256-bit key. > > OLD > 2) The ChaCha20 encryption function is used to encrypt the > plaintext, using the same key and nonce, and with the initial > counter set to 1. > NEW > 2) The ChaCha20 encryption function is used to encrypt the > plaintext, using the same 256-bit key and nonce, and with the initial > counter set to 1. > > > 2. Automated Key Management > > My understanding of [KEYMGM] is that to avoid the reuse of IV is a > necessary condition for an automated key management. If nonce can be > considered as an IV, I think the reason can be more explicit. > > OLD: > The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key > destroys the security guarantees. As a result, it can be extremely > difficult to use AEAD_CHACHA20_POLY1305 securely when using > statically configured keys. For safety's sake, implementations MUST > use an automated key management system [KEYMGMT]. > > NEW: > The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key > destroys the security guarantees and means must be provided to maintain > (key, nonce) unique. As mentioned in [KEYMGMT] this is a necessary arument > to mandate an automated key management system. Depending on the cases > additional requirements may be met, such as the possibility to update the > key regularly. > > I am not sure this can be useful. > In addition, nonce SHOULD NOT be generated randomly, but nonce > generation SHOULD be managed, especially when the same key is used in > different sessions. Note that, when the key is dedicated to a single > session, key management may replace the nonce generation. > > Security Consideration. > > I noticed a one block difference with RFC7539 of one block. > > rfc7539#section-2.6 mentions: > """ > This limits the use of > a single (key,nonce) combination to 2^32 blocks > """ > cms-chacha20 mentions: > """ > The amount of encrypted data possible in a single invocation of > AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each > """ > > > > > On Thu, Sep 22, 2016 at 11:59 AM, Salz, Rich wrote: > >> > This update addresses the comments from Jim Schaad. >> > >> > I believe that this document is ready for WG Last Call. >> >> Looking through the archives, I believe all open issues have been >> addressed. >> >> We'll now being a two-week WG last call, before passing it along to the >> IESG. >> >> /r$, co-chair >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> > > --001a11448ce0d36ee2053fc8ac2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The document has been in = WGLC since September 22. No one opposed the adoption of draft-housley-cms-chacha20-poly1305. The draft will be mov= ed forwad.

Yours,

Rich and Dan= iel

On Tue, Oct 4, 2016 at 5:43 PM, Daniel Migault <daniel.migaul= t@ericsson.com> wrote:
Hi,

I have reviewed the document.= The document is clear to me and is ready to be sent to the IESG. I have so= me editorial comments/suggestions. Feel free to ignore them.

= BR,
Daniel



1.1.=C2=A0 The ChaCha20 and P= oly1305 AEAD Construction

As all length key size and paddings are me= ntionned, it might be usefull for completeness to specify the length of the= poly1305 key. That said as the poly1305 and the input key have and the inp= ut key is designated as 256-bit key. In order to differentiate the input ke= y from other 256-bit key, it might be good to replace "256-bit key&quo= t; by "256-bit input key" or some equivalent.

OLD:=C2=A0 =
1) A 256 bit Poly1305 one-time key is generated from the 256-bit key an= d
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and nonce using the p= rocedure described in Section 2.6 of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 [FORIETF].
NEW:
1) A 256 bit Poly1305 one-time key is= generated from the 256-bit key and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 and nonce using the procedure described in Section 2.6 of
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [FORIETF].
=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0
For clarity, it might be better to explicitly mention the key. Th= e proposed text designates the input key as=C2=A0 256-bit key.
=C2=A0OLD
2) The ChaCha20 encryption function is used to encrypt the
=C2= =A0=C2=A0 plaintext, using the same key and nonce, and with the initial
= =C2=A0=C2=A0 counter set to 1.
NEW
2) The ChaCha20 encryption functio= n is used to encrypt the
=C2=A0=C2=A0 plaintext, using the same 256-bit = key and nonce, and with the initial
=C2=A0=C2=A0 counter set to 1.=C2=A0= =C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A02.=C2=A0 Automated Key M= anagement

My understanding of [KEYMGM] is that to avoid the reuse of= IV is a necessary condition for an automated key management. If nonce can = be considered as an IV, I think the reason can be more explicit.=C2=A0
=
OLD:
=C2=A0=C2=A0 The reuse of an AEAD_CHACHA20_POLY1305 nonce value= with the same key
=C2=A0=C2=A0 destroys the security guarantees.=C2=A0 = As a result, it can be extremely
=C2=A0=C2=A0 difficult to use AEAD_CHAC= HA20_POLY1305 securely when using
=C2=A0=C2=A0 statically configured key= s.=C2=A0 For safety's sake, implementations MUST
=C2=A0=C2=A0 use an= automated key management system [KEYMGMT].

NEW:
=C2=A0=C2=A0 The= reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key
=C2=A0= =C2=A0 destroys the security guarantees and means must be provided to maint= ain (key, nonce) unique. As mentioned in [KEYMGMT] this is a necessary arum= ent to mandate an automated key management system. Depending on the cases a= dditional requirements may be met, such as the possibility to update the ke= y regularly.

=C2=A0I am not sure this can be useful.
=C2=A0=C2= =A0 In addition, nonce SHOULD NOT be generated randomly, but nonce generati= on SHOULD be managed, especially when the same key is used in different ses= sions. Note that, when the key is dedicated to a single session, key manage= ment may replace the nonce generation.
=C2=A0=C2=A0
Security Consid= eration.

I noticed a one block difference with RFC7539 of one block.=
=C2=A0=C2=A0
rfc7539#section-2.6 mentions:
"""=C2=A0This limits the use of
=C2=A0a single (key,nonce) combination to = 2^32 blocks
"""
cms-chacha20 mentions:
""= "
The amount of encrypted data possible in a single invocation of=C2=A0=C2=A0 AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each"""



=

On Thu, Sep 22, 2016 at 11:59 AM, Salz, Rich <rsalz@akamai.com> wrote:
> This update address= es the comments from Jim Schaad.
>
> I believe that this document is ready for WG Last Call.

Looking through the archives, I believe all open issues have been ad= dressed.

We'll now being a two-week WG last call, before passing it along to the= IESG.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /r$, co-chair

_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


--001a11448ce0d36ee2053fc8ac2e-- From nobody Wed Oct 26 21:44:37 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73752129A0D for ; Wed, 26 Oct 2016 21:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 m8KAJ-7LKO14 for ; Wed, 26 Oct 2016 21:44:33 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990D11296B4 for ; Wed, 26 Oct 2016 21:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1477543472; x=1509079472; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IyWaQvs1MYlckd+qqt255lzoer0HtZ+I9sZ69cGlHG8=; b=oCa/bXHxwS6x0yG19zMl9qEjCocLApD++N9b/EZorhJDfLmlV929ohjx PERYSb9tuIN16h80pZAn7DrydUQoJcdeBXDIIqCLnV/wcNjoN8zlVl479 Qo0wsgkeMw+jyABDLIxrrfa+Z3c5DfNIetnW8bH3HO/f5e3PJAKQpl+bZ VCoDSZU/XbKKkM+zEQRxpXaa5DhOQLrcOdK8kJ0HELpxUGpxpM+oi8dgJ fYVqCqkCtypFaPH4C2D/kBNdJZsZmPdJxZ7hL6L9vhGIY3nHmpWQVfl4N C5b5Km3VvM7zmuxCx6JH8JuS39hCkDXZ3uDe1VZqt55SYLBu3YgQYEY9i g==; X-IronPort-AV: E=Sophos;i="5.31,404,1473076800"; d="scan'208";a="112267976" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from uxcn13-tdc-a.uoa.auckland.ac.nz ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Oct 2016 17:44:13 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 27 Oct 2016 17:44:13 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 27 Oct 2016 17:44:13 +1300 From: Peter Gutmann To: Daniel Migault , "Salz, Rich" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-02.txt Thread-Index: AQHSL7WbMQcs8ZhZJU2ukgidFlqSZaC7uYel Date: Thu, 27 Oct 2016 04:44:13 +0000 Message-ID: <1477543453285.82075@cs.auckland.ac.nz> References: <147455438388.22522.16339907641035668344.idtracker@ietfa.amsl.com> <313384B3-818D-4CFA-81C4-005A9F551C72@vigilsec.com> <1f1d004911c0447fb5594b9a4ad78a8b@usma1ex-dag1mb1.msg.corp.akamai.com> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "curdle@ietf.org" , Russ Housley Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 04:44:36 -0000 Daniel Migault writes:=0A= =0A= >The document has been in WGLC since September 22. No one opposed the =0A= >adoption of draft-housley-cms-chacha20-poly1305. The draft will be moved = =0A= >forwad.=0A= =0A= Just had a quick look now for dumpasn1 usage, since it still says:=0A= =0A= =A0 id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=3D=0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0 { iso(1) member-body(2) us(840) rsadsi(113549) = pkcs(1)=0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pkcs9(9) smime(16) alg(3) TBD1 }=0A= =0A= =A0 S/MIME Capabilities=0A= =A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=0A= =A0 {{{ This can be written once the Object Identifier is assigned. }}}=0A= =A0 =0A= you may want to move it somewhat slowly.=0A= =0A= Peter.=0A= =0A= = From nobody Thu Oct 27 11:40:29 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E917B12959A for ; Thu, 27 Oct 2016 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 RWVkCZn42Thi for ; Thu, 27 Oct 2016 11:40:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD28C1295C4 for ; Thu, 27 Oct 2016 11:40:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 29731300AC2 for ; Thu, 27 Oct 2016 14:40:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oWkal9xv0iFK for ; Thu, 27 Oct 2016 14:40:24 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 8AF02300259; Thu, 27 Oct 2016 14:40:24 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <1477543453285.82075@cs.auckland.ac.nz> Date: Thu, 27 Oct 2016 14:38:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50472950-361D-4ECE-BC5F-FAD01E1BDBA8@vigilsec.com> References: <147455438388.22522.16339907641035668344.idtracker@ietfa.amsl.com> <313384B3-818D-4CFA-81C4-005A9F551C72@vigilsec.com> <1f1d004911c0447fb5594b9a4ad78a8b@usma1ex-dag1mb1.msg.corp.akamai.com> , <1477543453285.82075@cs.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "Salz, Rich" , Daniel Migault , "curdle@ietf.org" Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 18:40:28 -0000 On Oct 27, 2016, at 12:44 AM, Peter Gutmann = wrote: > Daniel Migault writes: >=20 >> The document has been in WGLC since September 22. No one opposed the=20= >> adoption of draft-housley-cms-chacha20-poly1305. The draft will be = moved=20 >> forwad. >=20 > Just had a quick look now for dumpasn1 usage, since it still says: >=20 > id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=3D > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs9(9) smime(16) alg(3) TBD1 } >=20 > S/MIME Capabilities > =20 > {{{ This can be written once the Object Identifier is assigned. }}} > =20 > you may want to move it somewhat slowly. This is assigned by IANA while the document is in the RFC Editor queue. = I=92ll work with the RFC Editor to make sure the S/MIME Capabilities are = updated once the assignment is made. Russ= From nobody Fri Oct 28 10:12:10 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31182129515 for ; Fri, 28 Oct 2016 10:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 Z-Ml8HxIx8Vy for ; Fri, 28 Oct 2016 10:12:06 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8CA129436 for ; Fri, 28 Oct 2016 10:12:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 08252300A9B for ; Fri, 28 Oct 2016 13:12:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SPO3GvNj68Rs for ; Fri, 28 Oct 2016 13:12:02 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 61119300A04; Fri, 28 Oct 2016 13:12:02 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A6ED6170-2305-418F-A90B-CE2ABE2C1F25" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 28 Oct 2016 13:12:00 -0400 Message-Id: <18ABA5BF-AF7F-419A-8BB7-2C09327B6DB6@vigilsec.com> References: <147455438388.22522.16339907641035668344.idtracker@ietfa.amsl.com> <313384B3-818D-4CFA-81C4-005A9F551C72@vigilsec.com> <1f1d004911c0447fb5594b9a4ad78a8b@usma1ex-dag1mb1.msg.corp.akamai.com> To: Daniel Migault X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 17:12:09 -0000 --Apple-Mail=_A6ED6170-2305-418F-A90B-CE2ABE2C1F25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Daniel: I will post an update that takes care of the comments below. Please = pass the -03 document to the IESG for approval and publication. Responding to the comments below. > 1.1. The ChaCha20 and Poly1305 AEAD Construction >=20 > As all length key size and paddings are mentionned, it might be = usefull for completeness to specify the length of the poly1305 key. That = said as the poly1305 and the input key have and the input key is = designated as 256-bit key. In order to differentiate the input key from = other 256-bit key, it might be good to replace "256-bit key" by "256-bit = input key" or some equivalent.=20 >=20 > OLD: =20 > 1) A 256 bit Poly1305 one-time key is generated from the 256-bit key = and > and nonce using the procedure described in Section 2.6 of > [FORIETF]. > NEW: > 1) A 256 bit Poly1305 one-time key is generated from the 256-bit key = and > and nonce using the procedure described in Section 2.6 of > [FORIETF]. Okay. I=92ll add that. > For clarity, it might be better to explicitly mention the key. The = proposed text designates the input key as 256-bit key.=20 > =20 > OLD > 2) The ChaCha20 encryption function is used to encrypt the > plaintext, using the same key and nonce, and with the initial > counter set to 1. > NEW > 2) The ChaCha20 encryption function is used to encrypt the > plaintext, using the same 256-bit key and nonce, and with the = initial > counter set to 1. =20 Okay. I=92ll add that. > 2. Automated Key Management >=20 > My understanding of [KEYMGM] is that to avoid the reuse of IV is a = necessary condition for an automated key management. If nonce can be = considered as an IV, I think the reason can be more explicit. =20 >=20 > OLD: > The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same = key > destroys the security guarantees. As a result, it can be extremely > difficult to use AEAD_CHACHA20_POLY1305 securely when using > statically configured keys. For safety's sake, implementations = MUST > use an automated key management system [KEYMGMT]. >=20 > NEW: > The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same = key > destroys the security guarantees and means must be provided to = maintain (key, nonce) unique. As mentioned in [KEYMGMT] this is a = necessary arument to mandate an automated key management system. = Depending on the cases additional requirements may be met, such as the = possibility to update the key regularly.=20 I think we want to be very declarative here. Your proposal removes the = MUST, and I think that is a problem. I suggest instead: The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key destroys the security guarantees. I can be extremely difficult to use a statically configured AEAD_CHACHA20_POLY1305 key and never repeat a nonce value. For safety's sake, implementations MUST use an automated key management system [KEYMGMT]. > I am not sure this can be useful.=20 > In addition, nonce SHOULD NOT be generated randomly, but nonce = generation SHOULD be managed, especially when the same key is used in = different sessions. Note that, when the key is dedicated to a single = session, key management may replace the nonce generation.=20 In the CMS context, I do not think this is helpful. If a fresh = AEAD_CHACHA20_POLY1305 key is generated for each AuthEnvelopedData, then = there is only one nonce value that is consumed per key. So, this is not = helpful to the implementer at the CMS layer, but it might be very = helpful to a crypto library that is used by CMS and other security = protocols. > Security Consideration. >=20 > I noticed a one block difference with RFC7539 of one block. > =20 > rfc7539#section-2.6 mentions: > """ > This limits the use of > a single (key,nonce) combination to 2^32 blocks > """ > cms-chacha20 mentions: > """ > The amount of encrypted data possible in a single invocation of > AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each > """ At the bottom of page 20, RFC 7539 says: 1. The amount of encrypted data possible in a single invocation is 2^32-1 blocks of 64 bytes each, because of the size of the block counter field in the ChaCha20 block function. This gives a total of 247,877,906,880 bytes, or nearly 256 GB. Russ --Apple-Mail=_A6ED6170-2305-418F-A90B-CE2ABE2C1F25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Daniel:

I will post an update = that takes care of the comments below.  Please pass the -03 = document to the IESG for approval and = publication.

Responding to the comments = below.

1.1.  The ChaCha20 and Poly1305 AEAD = Construction

As all length key size and paddings are mentionned, = it might be usefull for completeness to specify the length of the = poly1305 key. That said as the poly1305 and the input key have and the = input key is designated as 256-bit key. In order to differentiate the = input key from other 256-bit key, it might be good to replace "256-bit = key" by "256-bit input key" or some equivalent.

OLD:  =
1) A 256 bit Poly1305 one-time key is generated from the 256-bit key = and
         and nonce using = the procedure described in Section 2.6 = of
         = [FORIETF].
NEW:
1) A 256 bit Poly1305 one-time key is generated = from the 256-bit key = and
         and nonce using = the procedure described in Section 2.6 = of
         = [FORIETF].

<= /div>Okay.  I=92ll add that.

For clarity, it might be = better to explicitly mention the key. The proposed text designates the = input key as  256-bit key. 
 
OLD
2) The = ChaCha20 encryption function is used to encrypt the
   = plaintext, using the same key and nonce, and with the = initial
   counter set to 1.
NEW
2) The ChaCha20 = encryption function is used to encrypt the
   plaintext, = using the same 256-bit key and nonce, and with the = initial
   counter set to 1.   =

Okay.=  I=92ll add that.

 2.  Automated Key = Management

My understanding of [KEYMGM] is that to avoid the = reuse of IV is a necessary condition for an automated key management. If = nonce can be considered as an IV, I think the reason can be more = explicit. 

OLD:
   The reuse of an = AEAD_CHACHA20_POLY1305 nonce value with the same key
   = destroys the security guarantees.  As a result, it can be = extremely
   difficult to use AEAD_CHACHA20_POLY1305 = securely when using
   statically configured keys.  = For safety's sake, implementations MUST
   use an automated = key management system [KEYMGMT].

NEW:
   The reuse = of an AEAD_CHACHA20_POLY1305 nonce value with the same = key
   destroys the security guarantees and means must be = provided to maintain (key, nonce) unique. As mentioned in [KEYMGMT] this = is a necessary arument to mandate an automated key management system. = Depending on the cases additional requirements may be met, such as the = possibility to update the key regularly. =

I = think we want to be very declarative here.  Your proposal removes = the MUST, and I think that is a problem.  I suggest = instead:

   The reuse of an = AEAD_CHACHA20_POLY1305 nonce value with the same key
  =  destroys the security guarantees.  I can be extremely = difficult to
   use a statically configured = AEAD_CHACHA20_POLY1305 key and never
   repeat a = nonce value.  For safety's sake, implementations MUST use = an
   automated key management system = [KEYMGMT].

 I am not sure this can be useful. =
   In addition, nonce SHOULD NOT be generated randomly, = but nonce generation SHOULD be managed, especially when the same key is = used in different sessions. Note that, when the key is dedicated to a = single session, key management may replace the nonce generation. =

In = the CMS context, I do not think this is helpful.  If a fresh = AEAD_CHACHA20_POLY1305 key is generated for each AuthEnvelopedData, then = there is only one nonce value that is consumed per key.  So, this = is not helpful to the implementer at the CMS layer, but it might be very = helpful to a crypto library that is used by CMS and other security = protocols.

Security Consideration.

I noticed a = one block difference with RFC7539 of one block.
   =
rfc7539#section-2.6 mentions:
"""
 This limits the use = of
 a single (key,nonce) combination to 2^32 = blocks
"""
cms-chacha20 mentions:
"""
The amount of = encrypted data possible in a single invocation of
   = AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets = each
"""
At the bottom of page 20, RFC 7539 = says:

   1.  The amount of = encrypted data possible in a single invocation is
  =      2^32-1 blocks of 64 bytes each, because of the size = of the block
       counter field in the = ChaCha20 block function.  This gives a total
  =      of 247,877,906,880 bytes, or nearly 256 = GB.

Russ

= --Apple-Mail=_A6ED6170-2305-418F-A90B-CE2ABE2C1F25-- From nobody Fri Oct 28 10:17:19 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D681294F3; Fri, 28 Oct 2016 10:17:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147767503391.24899.15058793706608847160.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2016 10:17:13 -0700 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 17:17:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) Author : Russell Housley Filename : draft-ietf-curdle-cms-chacha20-poly1305-03.txt Pages : 8 Date : 2016-10-28 Abstract: This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-chacha20-poly1305-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-chacha20-poly1305-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 28 19:32:38 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C8A129470 for ; Fri, 28 Oct 2016 19:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 wUwm6a9izFLd for ; Fri, 28 Oct 2016 19:32:34 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7A212944A for ; Fri, 28 Oct 2016 19:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1477708354; x=1509244354; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=R2Y5h77byAbvQiILg6qamFlvfrb9a29mCSwNwvPWW10=; b=HRM/doNd3rU8WESH0d5dIFHKzjQQO4ddHyggwUyt6DOBbK3U375h5cpd ILWep1ktoqWeaH1H9F/rRW2gs6XETRLMOQ9FbRI2jBrviUE3YBBnF64pG YQp/LxmhXt17RcVtJotf3G9SxHa5QAWRxJFxWGuadtZCXVlBJFyuZK84S fyawB3jBvnVOwEmt/o1WJL8avCKLNqH/3Q5PffwCZf2kZ5Vq/ItybTT2D pN61mxZkK6z9AU7fGSOQeEMQBUVtm+TU3l2WtKygmgxCG2jDEauH5w3I4 vo0wUTW6EQPlKRye9PlDY4ISqReUkEvaBbFt0+T4UMyfAAiYN3QeL72Wc g==; X-IronPort-AV: E=Sophos;i="5.31,561,1473076800"; d="scan'208";a="112533200" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Oct 2016 15:32:30 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 29 Oct 2016 15:32:30 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 29 Oct 2016 15:32:30 +1300 From: Peter Gutmann To: Russ Housley , Daniel Migault Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-02.txt Thread-Index: AQHSL7WbMQcs8ZhZJU2ukgidFlqSZaC9Q3AAgAF2Z3A= Date: Sat, 29 Oct 2016 02:32:30 +0000 Message-ID: <1477708341338.3478@cs.auckland.ac.nz> References: <147455438388.22522.16339907641035668344.idtracker@ietfa.amsl.com> <313384B3-818D-4CFA-81C4-005A9F551C72@vigilsec.com> <1f1d004911c0447fb5594b9a4ad78a8b@usma1ex-dag1mb1.msg.corp.akamai.com> , <18ABA5BF-AF7F-419A-8BB7-2C09327B6DB6@vigilsec.com> In-Reply-To: <18ABA5BF-AF7F-419A-8BB7-2C09327B6DB6@vigilsec.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 02:32:38 -0000 Russ Housley writes:=0A= =0A= >>=A0=A0=A0=A0 1) A 256 bit Poly1305 one-time key is generated from the 256= -bit key and=0A= >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 and nonce using the procedure des= cribed in Section 2.6 of=0A= >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [FORIETF].=0A= >=0A= >Okay.=A0 I=92ll add that.=0A= =0A= You may also want to remove the duplicate "and and"...=0A= =0A= Peter.=0A= =0A= = From nobody Sat Oct 29 10:19:22 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D56129559 for ; Sat, 29 Oct 2016 10:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 CqBS5G-2QWRz for ; Sat, 29 Oct 2016 10:19:19 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B40129555 for ; Sat, 29 Oct 2016 10:19:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E9050300AB0 for ; Sat, 29 Oct 2016 13:19:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id neGDIiaUHpdG for ; Sat, 29 Oct 2016 13:19:16 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BBA013005A5; Sat, 29 Oct 2016 13:19:16 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <1477708341338.3478@cs.auckland.ac.nz> Date: Sat, 29 Oct 2016 13:19:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147455438388.22522.16339907641035668344.idtracker@ietfa.amsl.com> <313384B3-818D-4CFA-81C4-005A9F551C72@vigilsec.com> <1f1d004911c0447fb5594b9a4ad78a8b@usma1ex-dag1mb1.msg.corp.akamai.com> , <18ABA5BF-AF7F-419A-8BB7-2C09327B6DB6@vigilsec.com> <1477708341338.3478@cs.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 17:19:20 -0000 On Oct 28, 2016, at 10:32 PM, Peter Gutmann = wrote: > Russ Housley writes: >=20 >>> 1) A 256 bit Poly1305 one-time key is generated from the = 256-bit key and >>> and nonce using the procedure described in Section 2.6 = of >>> [FORIETF]. >>=20 >> Okay. I=92ll add that. >=20 > You may also want to remove the duplicate "and and"=85 I caught that duplicate; draft-ietf-curdle-cms-chacha20-poly1305-03.txt = says: 1) A 256-bit Poly1305 one-time key is generated from the input 256-bit key and nonce using the procedure described in Section 2.6 of [FORIETF]. Russ From nobody Mon Oct 31 15:58:33 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFED7129992; Mon, 31 Oct 2016 15:58:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795470991.23286.13339069603763100075.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 15:58:29 -0700 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:58:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure Authors : Simon Josefsson Jim Schaad Filename : draft-ietf-curdle-pkix-02.txt Pages : 15 Date : 2016-10-31 Abstract: This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the Curve25519 and Curve448 curves. The signature algorithms covered are Ed25519, Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered are X25519 and X448. The Encoding for Public Key, Private Key and EdDSA digital signature structures is provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-pkix-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/