Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-02.txt

From: Daniel Migault <[email-masked]>
Date: Tue, 4 Oct 2016 17:43:10 -0400

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 26 Oct 2016 14:20:08 -0400

Hi,

The document has been in WGLC since September 22. No one opposed the
adoption of draft-housley-cms-chacha20-poly1305
<https://datatracker.ietf.org/doc/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 <[email-masked]>
wrote:

> 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:
> For clarity, it might be better to explicitly mention the key. The
> proposed text designates the input key as  256-bit key.
>
> OLD

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 27 Oct 2016 04:44:13 +0000

Daniel Migault <[email-masked]> writes:

>adoption of draft-housley-cms-chacha20-poly1305. The draft will be moved 
>forwad.

Just had a quick look now for dumpasn1 usage, since it still says:

  id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
          { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
            pkcs9(9) smime(16) alg(3) TBD1 }

  S/MIME Capabilities
            
  {{{ This can be written once the Object Identifier is assigned. }}}
  
you may want to move it somewhat slowly.

Peter.

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Oct 2016 14:38:52 -0400

> you may want to move it somewhat slowly.

This is assigned by IANA while the document is in the RFC Editor queue.  I’ll work with the RFC Editor to make sure the S/MIME Capabilities are updated once the assignment is made.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 28 Oct 2016 13:12:00 -0400

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.

> 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:  

Okay.  I’ll 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

Okay.  I’ll add that.

> 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:
>    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].

>    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.

>    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

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 29 Oct 2016 02:32:30 +0000

>>              and nonce using the procedure described in Section 2.6 of

You may also want to remove the duplicate "and and"...

Peter.

---

From: Russ Housley <[email-masked]>
Date: Sat, 29 Oct 2016 13:19:15 -0400

On Oct 28, 2016, at 10:32 PM, Peter Gutmann <[email-masked]> wrote:

> You may also want to remove the duplicate "and and"…

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