Subject: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 04 Aug 2015 14:37:04 +0200

Hi,
 An open issue for draft-ietf-tls-chacha20-poly1305-00 raised by Eric 
Rescorla is that this draft doesn't use the draft-TLS 1.3 mechanism 
for setting the nonce per record [0]. Is there any support for 
switching these ciphersuites to draft-TLS 1.3 nonce mechanism even for 
TLS 1.2? The alternative is to use the TLS 1.2 mechanism with the 
redundant bytes redacted as the draft is now [1].

Are there any other issues than the listed above which may prevent
early code point assignment? 

[0]. https://www.ietf.org/mail-archive/web/tls/current/msg16374.html

[1]. https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-00

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Aug 2015 09:15:29 -0700

On 4 August 2015 at 05:37, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> Is there any support for

Personally, I would rather see the nonce construction follow the form
defined in the respective TLS version.  That means including redundant
bytes in TLS 1.2 and only getting the full advantage when we move to
TLS 1.3.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 4 Aug 2015 16:20:19 +0000

> defined in the respective TLS version.

Yes, consistency.  +1

---

From: David Benjamin <[email-masked]>
Date: Tue, 04 Aug 2015 17:22:01 +0000

On Tue, Aug 4, 2015 at 12:20 PM Salz, Rich <[email-masked]> wrote:

> > defined in the respective TLS version. [DB: Adding back in for context:
> "That means including redundant bytes in TLS 1.2 and only getting the full
> advantage when we move to TLS 1.3."]
>
> Yes, consistency.  +1
>

I think this already came up:
https://www.ietf.org/mail-archive/web/tls/current/msg16365.html

This is a waste of bandwidth. Consistency is generally good, but a weak
argument here. The complexity is minimal. If you don't care about
decrypting in-place, none of this matters. If you do care, you already have
to deal with:

- RC4 and TLS 1.0 CBC use no prefix on the ciphertext
- AES-GCM, TLS 1.1+ 3DES use an 8-byte prefix
- TLS 1.1+ AES CBC use a 16-byte prefix

Adding a 0-byte prefix cipher doesn't make anything worse. It already must
vary.

As for following what's defined in TLS 1.2, RFC 5246 just says that
GenericAEADCipher has a nonce_explicit field and:

   Each AEAD cipher suite MUST specify how the nonce supplied to the
   AEAD operation is constructed, and what is the length of the
   GenericAEADCipher.nonce_explicit part.

It then describes the 1.2 AES-GCM scheme, but prefaced with "In many cases,
it is appropriate to [...]". Saying nonce_explicit is empty and the nonce
is built from the sequence number is perfectly consistent here.

David

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 4 Aug 2015 10:24:15 -0700

> bytes in TLS 1.2 and only getting the full advantage when we move to

Martin,

In TLS 1.2, the explicit part of the nonce
(GenericAEADCipher.nonce_explicit in
https://tools.ietf.org/html/rfc5246#section-6.2.3.3) is allowed to be
zero-length. So it seems reasonable for
draft-ietf-tls-chacha20-poly1305 to use the draft-TLS 1.3 nonce
mechanism for TLS 1.2. The consistency you want to see seems to be
consistency with the AES GCM cipher suites, rather than with TLS 1.2.

My only concern with adopting the draft-TLS 1.3 nonce mechanism for
TLS 1.2 is that it is not final. It will be bad if
draft-ietf-tls-chacha20-poly1305 becomes an RFC before TLS 1.3 does,
and the final TLS 1.3 nonce mechanism is different.

Wan-Teh

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Aug 2015 10:35:30 -0700

On 4 August 2015 at 10:24, Wan-Teh Chang <[email-masked]> wrote:
> The consistency you want to see seems to be

Yes, this is correct.

RFC 5288:
             struct {
                opaque salt[4];
                opaque nonce_explicit[8];
             } GCMNonce;

RFC 6655:
                       struct {
             opaque salt[4];
             opaque nonce_explicit[8];
                       } CCMNonce;

Interestingly, RFC 6655 removes the explicit nonce for DTLS, but DTLS
only (if I'm reading it correctly).

Either way, I think that we should attempt to be consistent with
these.  Which suggests that perhaps we can adopt a zero-length
explicit nonce and borrow the 6655 DTLS construction.

As for the wasted bytes, I don't care for that.  We will fix that later.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 5 Aug 2015 13:44:20 +0300

> As for the wasted bytes, I don't care for that.  We will fix that later.

It is not just wasted bytes.

It is also increased auditing requirements: Auditing that the nonce 
generation is sound (e.g. not random).

And in constructs like this, if you get it wrong, you will notice very
quickly (contrast to AES-GCM nonce generation: Serious errors can remain
hidden).

Also, unifying the GCM scheme, CCM scheme the scheme from this draft
and TLS 1.3 scheme isn't hard (supporting CBC is loads more annoying,
as it is much harder to unify[1]).

[1] Well, there are tricks with TLS 1.1/1.2 CBC modes, but TLS 1.0
CBC modes just won't unify.

-Ilari

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 5 Aug 2015 11:13:45 -0700

> only (if I'm reading it correctly).

I don't see that special handling for DTLS in RFC 6655. The only
DTLS-specific statement in RFC 6655 is the clarification on how
to build a 64-bit seq_num:

   In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
   48-bit seq_num.

So I am afraid that you read it incorrectly.

It doesn't seem useful to be consistent with the AES GCM and CCM
cipher suites. In my experience implementing both ChaCha20+Poly1305
and AES GCM cipher suites in TLS 1.2, the lengths of the explicit
nonce can be easily parameterized.

I am now inclined to support adopting the draft-TLS 1.3 nonce
mechanism for TLS 1.2. Specifically, this means in TLS 1.2,
ChaCha20+Poly1305 has these parameters:

SecurityParameters.record_iv_length = 0  // zero-length explicit nonce.
                                         // No change from
                                         // draft-ietf-tls-chacha20-poly1305-00.

SecurityParameters.fixed_iv_length = 12  // increased from the value 4 used in
                                         // draft-ietf-tls-chacha20-poly1305-00.

Then, define the ChaChaNonce struct as described in the draft-TLS 1.3.

       struct {
           opaque nonce[12];
       } ChaChaNonce;

      1. The 64-bit record sequence number is padded to the left with
         zeroes to 96 bits (12 octets).
      2. The padded sequence number is XORed with either the
         client_write_IV (when the client is sending) or the
         server_write_IV (when the server is sending)
      3. Store the XOR result in ChaChaNonce.nonce.

Wan-Teh

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Aug 2015 11:02:21 -0700

>       3. Store the XOR result in ChaChaNonce.nonce.

This looks fine.  Note that the general construction in TLS 1.3 should
be, more formally:

assert(N_MAX > 64bits)
nonce = {client|server|_{read|write}_IV[0..N_MAX] XOR lpad0(seq_num)

Of course, ChaChaX sets N_MAX to 96 bits, so what you described was correct.

--Martin