Subject: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls

From: Sean Turner <[email-masked]>
Date: Tue, 19 May 2015 17:31:59 -0400

All,

This message serves two purposes:

1) It is the WG call for adoption of:

http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-chacha-tls/

This draft specifies the use of the ChaCha stream cipher with Poly1305 in the TLS and DTLS protocols.  The WG needs this draft to specify code points in support of the recent MTI consensus call (see http://www.ietf.org/mail-archive/web/tls/current/msg16343.html).  If you object to the adoption of this draft as a WG item, please respond to the list indicating why by 20150602.

2) It is a request for an early code point assignment:

We have a request for an early code point assignment for the cipher suites listed in the draft.  If you have a concern with an early code point assignment for the ciphers listed in this draft, please respond to the list indicating why by 20150602.  

Thanks,

J&S

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 May 2015 00:51:40 +0300

1) All for it

2) I question the need for TLS_DHE_ ciphersuites, and I seriously doubt anybody’s going to use those with ChaCha20 “in the wild”. Other than that, I’m all for early assignment as it would allow us to get the algorithms into code-bases and test interoperability quicker.

Yoav

> On May 20, 2015, at 12:31 AM, Sean Turner <[email-masked]> wrote:
> 
> All,
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 May 2015 15:14:43 -0700

> 2) I question the need for TLS_DHE_ ciphersuites, and I seriously doubt anybody’s going to use those with ChaCha20 “in the wild”. Other than that, I’m all for early assignment as it would allow us…

I tend to agree.  Can someone reply with a brief explanation of why
each of the following is needed?  Hopefully better than what I was
able to devise:

TLS_RSA_WITH_CHACHA20_POLY1305
Because we're scared of ephemeral key exchange for some reason ?

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
Because ECDHE is good, and RSA is widespread.

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
Because this is what we actually want.

TLS_DHE_RSA_WITH_CHACHA20_POLY1305
Because we need a backup for EC.

TLS_DHE_PSK_WITH_CHACHA20_POLY1305
Because ECDHE is nice, but we need a backup, even for little things ?

TLS_PSK_WITH_CHACHA20_POLY1305
Because little things don't like paying for asymmetric crypto.

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305
Because little things need nice things too.

TLS_RSA_PSK_WITH_CHACHA20_POLY1305
Because little things like doing bignum exponentiation without any PFS
payoff, but RSA alone isn't "secure enough" ?

The thing that concerns me most is that we aren't saying that PFS is
required outside of PSK.  I understand the carve-out we've made for
the little things, but I don't understand why we are defining
RSA-based suites without PFS.

Of comparable concern is the RSA_PSK stuff.  I wasn't around for the
definition of these originally, but they make basically no sense to
me.

I get the DHE_PSK thing if you justify it using the same basis as
DHE_RSA, but it might be that the little things can just take a pass
on PFS without ECDHE.

Would it be unreasonable to cut the list to ... ?
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_DHE_RSA_WITH_CHACHA20_POLY1305
TLS_PSK_WITH_CHACHA20_POLY1305
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305

Also, I'm not against DHE in general, and I think that it's worth
keeping around for a little longer. However.  If we consider DHE_RSA
worth doing, then the only logic I can concoct would provide almost
equal justification for DHE_ECDSA.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 May 2015 15:14:32 -0700

On Tue, May 19, 2015 at 2:31 PM, Sean Turner <[email-masked]> wrote:

> This draft specifies the use of the ChaCha stream cipher with Poly1305 in
> the TLS and DTLS protocols.  The WG needs this draft to specify code points
> in support of the recent MTI consensus call (see
> http://www.ietf.org/mail-archive/web/tls/current/msg16343.html).  If you
> object to the adoption of this draft as a WG item, please respond to the
> list indicating why by 20150602.
>
> We have a request for an early code point assignment for the cipher suites
> listed in the draft.  If you have a concern with an early code point
> assignment for the ciphers listed in this draft, please respond to the list
> indicating why by 20150602.
>

I am in favor of this draft.

Prior to doing the code point assignment, however, we should resolve
the question of the per-record nonce algorithm. The current draft uses
an algorithm that is not consistent either with the algorithm we use for
GCM or TLS 1.3.

- TLS 1.2 GCM: 32-bit fixed salt || 64-bit explicit per-record IV
- TLS 1.3: fixed mask XORed with the record sequence number
- ChaCha: 32-bit fixed salt || record sequence number

On another thread, people have expressed the opinion that ChaCha should
be consistent with GCM for both 1.2 and 1.3, but if we're going to do that
we minimally need to change the algorithm for 1.2 (at the cost of 8 bytes
per record).

I don't have a strong opinion about this, but we should resolve it now.

-Ekr

Thanks,

---

From: Benjamin Beurdouche <[email-masked]>
Date: Wed, 20 May 2015 00:27:57 +0200

> On 20 May 2015, at 00:14, Martin Thomson <[email-masked]> wrote:
> 
> Because we’re scared of ephemeral key exchange for some reason ?

I am not, so you shouldn’t =P

> Because ECDHE is good, and RSA is widespread.

Yes

> Because this is what we actually want.

Yes

> Because we need a backup for EC.

Better safe than sorry.

> Because ECDHE is nice, but we need a backup, even for little things ?

Is this sentence hiding something ? ;)
I am really not sure about this one, why since there is EC…

> Because little things don’t like paying for asymmetric crypto.

Fair enough

> Because little things need nice things too.

Yes

> payoff, but RSA alone isn’t "secure enough" ?

Arf ! chop off it’s RSA ! 

> definition of these originally, but they make basically no sense to

Agreed

> TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305

I completely agree with Martin on this list, we probably do not need more ciphersuites than those.

> equal justification for DHE_ECDSA.

I really don’t think DHE_ECDSA will ever by massively used …
It would be like having RSA_ECDSA =s..

Cheers,
B.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 May 2015 05:30:40 +0000

I'm in favor of support, but we should trim the code point list.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 20 May 2015 02:43:04 -0400 (EDT)

----- Original Message -----
> - ChaCha: 32-bit fixed salt || record sequence number

I think the chacha draft is consistent with the TLS 1.2 GCM draft. The TLS
1.2 GCM draft allows as an option (MAY) to have "32-bit fixed salt || record sequence number",
and in fact all implementations do that. So this draft simply ratifies that
approach and changes that requirement to MUST. The approach in TLS 1.3 is a novel 
one and I don't think it suits this draft.
 
regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 20 May 2015 02:58:01 -0400 (EDT)

----- Original Message -----
> each of the following is needed?  Hopefully better than what I was

I don't think one would have to explain each and every usage
of a ciphersuite. If applications don't need it they won't use it. 

> Because we're scared of ephemeral key exchange for some reason ?

I believe the main argument is that this draft is supposed to provide 
ciphersuites to used by existing protocols and applications which already 
use RSA. Yes, I agree that some of them would need to be updated to provide 
PFS, but this draft doesn't update those apps/protocols. A protocol that
I know that relies on the RSA ciphersuites is the anyconnect vpn protocol
(even though its usage doesn't affect PFS).

> Because ECDHE is nice, but we need a backup, even for little things ?

That was my intention. To provide DHE as backup to ECDHE, since they 
are not susceptible to the same attacks.  It is now
especially relevant since we will have fixed groups for DHE.

> payoff, but RSA alone isn't "secure enough" ?

I don't have much data for this ciphersuite. If someone has a strong argument
on why it shouldn't be included I wouldn't object.

> RSA-based suites without PFS.

I agree. However, note that this draft is not the place to argue for that,
but rather the protocols that rely on non-PFS ciphersuites.

> definition of these originally, but they make basically no sense to

The idea was to provide both certificate auth for the server and PSK
auth for the client. The implementation was less than ideal.

> equal justification for DHE_ECDSA.

There is no DHE_ECDSA key exchange defined for TLS. Otherwise there would
be no reason for these ciphersuites to be there.
 
regards,
Nikos

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 May 2015 08:12:54 +0100

Hi,

While I am generally against ciphersuite proliferation I
think its a good idea to register some of these now. I
would note however that you only need the temporary
registrations for things with which people want to work
now - any future proofing can be done as the draft
progresses so the WG do not need to decide all of this
now. And of course, there is always the potential for
non-interoperable changes to happen during the WG
process which is another good reason to not register
more than the absolute minimum of codepoints now.

So please restrict the early registration list to
those that are needed *right now*. Anything that can
wait months, should wait months.

Thanks,
S.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 May 2015 14:10:21 +0300

At ipsecme, we had a few incompatible changes between WG adoption of our 
own chacha draft, and WGLC. So I would recommend against early 
registration altogether.

Thanks,
	Yaron

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 20 May 2015 13:20:43 +0200

> own chacha draft, and WGLC. So I would recommend against early 

Could you summarize the changes done for ipsecme in case they are
relevant for this draft as well?

regards,
Nikos

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 May 2015 14:23:58 +0300

I cannot, sorry. But a diff between -00 and -08 shows (among other 
things) differences in the order of data items that are covered by the 
Poly1305 tag.

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 May 2015 16:10:36 +0300

> On May 20, 2015, at 2:20 PM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 

Not much. The changes were mostly clarifications, examples, and fixing the construction of AAD for Poly1305 input for both IPsec and IKE.

We did have some TBDs in the draft over whether we would set the 32-bit salt to zero or derive it from keying material (as for GCM). We decided on the latter. That question is also open in this working group, at least for TLS 1.2.

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 May 2015 06:21:25 -0700

On Tue, May 19, 2015 at 11:43 PM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> approach and changes that requirement to MUST.

Not just that. It also doesn't carry the RSN on the wire, which the GCM one
does.

-Ekr

The approach in TLS 1.3 is a novel

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 May 2015 18:13:52 +0300

> On May 20, 2015, at 4:21 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, May 19, 2015 at 11:43 PM, Nikos Mavrogiannopoulos <[email-masked] <mailto:[email-masked]>> wrote:
> Not just that. It also doesn't carry the RSN on the wire, which the GCM one does.

Yes, there’s that. I think that we should leave the record IV (which this draft makes equal to the RSN, while RFC 5288 allows to be chosen in any way)  in the record for TLS 1.2. 
In 1.3 we’re anyway planning to do it differently and omit the IV, so we should do it there for both algorithms
It’s a waste of 8 bytes, but that will give us one more reason to implement 1.3, no?

Yoav

---

From: Adam Langley <[email-masked]>
Date: Wed, 20 May 2015 08:15:31 -0700

On Wed, May 20, 2015 at 8:13 AM, Yoav Nir <[email-masked]> wrote:
> Yes, there’s that. I think that we should leave the record IV (which this
> draft makes equal to the RSN, while RFC 5288 allows to be chosen in any way)
> in the record for TLS 1.2.

Nope, not going waste 8 bytes per record for no reason. The world has
wasted enough network bandwidth on that in AES-GCM already.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 May 2015 08:29:56 -0700

On Wed, May 20, 2015 at 8:15 AM, Adam Langley <[email-masked]>
wrote:

> > It’s a waste of 8 bytes, but that will give us one more reason to
> implement
> > 1.3, no?
>

What would you think of just adopting the 1.3 approach then?

I don't have a strong opinion on this, but it seems a pity to have three
separate mechanisms.

-Ekr

---

From: Adam Langley <[email-masked]>
Date: Wed, 20 May 2015 08:33:05 -0700

> What would you think of just adopting the 1.3 approach then?

Sure. Although I half suspect that the final TLS might change again
and we would still end up with three modes :) But that's not a big
deal.

Cheers

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 May 2015 08:35:22 -0700

On Wed, May 20, 2015 at 8:33 AM, Adam Langley <[email-masked]>
wrote:

> Sure. Although I half suspect

half suspect? optimist!

that the final TLS might change again
> and we would still end up with three modes :) But that's not a big

It will mean that we need a different set of code points than the current
ones, right?

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 20 May 2015 11:56:25 -0400 (EDT)

----- Original Message -----
> I don't have a strong opinion on this, but it seems a pity to have three

I don't really see it as a separate mechanism, it just omits the bytes which
are redundant. The TLS 1.3 is a separate mechanism, and TLS 1.3 is not final
yet. While I'd prefer to see the draft published than not, I wouldn't like to
use an experimental mechanism, and my preference would be to use the current
mechanism without the redundant bytes.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 May 2015 09:02:45 -0700

On Wed, May 20, 2015 at 8:56 AM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> are redundant.

Well, it's separate in the sense that you can't just swap out the GCM for
ChaCha
alg-ids.

As I said, I don't feel strongly about this, but I do feel strongly that we
should
decide this before doing the code point allocation (it's not an obstacle to
accepting the draft), and since Yoav has raised the point about consistency,
we should probably address it now.

-Ekr

> The TLS 1.3 is a separate mechanism, and TLS 1.3 is not final

---

From: Adam Langley <[email-masked]>
Date: Wed, 20 May 2015 09:09:11 -0700

> It will mean that we need a different set of code points than the current

Not quite sure that I follow you here:

We will need a different set of code points than the ones currently
squatted for ChaCha (0xcc13 etc), but the draft already specifies
that. (And the AEAD construction is slightly different.)

However, if we specified the current TLS 1.3 nonce scheme for ChaCha
in TLS 1.2, but TLS 1.3 changed before it was final, I don't think the
code points would need to change again. It would just be the case that
the code points, when used in TLS 1.3, use whatever TLS 1.3 ends up
doing and, in previous versions, they use what TLS 1.3 does now.

Cheers

AGL

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 May 2015 16:11:38 +0000

> would need to change again. It would just be the case that the code points,
> when used in TLS 1.3, use whatever TLS 1.3 ends up doing and, in previous
> versions, they use what TLS 1.3 does now.

Have we done that before, had codepoints whose meaning depended on verson?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 May 2015 09:13:10 -0700

> that. (And the AEAD construction is slightly different.)

Oh, sorry, I hadn't noticed that. I agree with your analysis below.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 May 2015 09:13:25 -0700

TLS 1.1 mass changed the way we do IVs for all cipher suites.

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 May 2015 21:01:09 +0300

> On May 20, 2015, at 7:02 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, May 20, 2015 at 8:56 AM, Nikos Mavrogiannopoulos <[email-masked] <mailto:[email-masked]>> wrote:
> Well, it's separate in the sense that you can't just swap out the GCM for ChaCha
> alg-ids.
> 
> As I said, I don't feel strongly about this,

TBH I don’t feel strongly about this either. It’s a bit of an ugly piece of code to handle this, but not ugly enough to make it worth arguing this for a long time.

> but I do feel strongly that we should
> decide this before doing the code point allocation

That’s your call, but as Stephen said there is always the potential for non-interoperable changes to happen during the WG process. I don’t see this as blocking, but I was told the same at IPsecME when I made the same request.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 May 2015 11:23:27 -0700

On 20 May 2015 at 11:01, Yoav Nir <[email-masked]> wrote:
> That’s your call, but as Stephen said there is always the potential for
> non-interoperable changes to happen during the WG process. I don’t see this
> as blocking, but I was told the same at IPsecME when I made the same
> request.

We're talking about a code point allocation.  That usually requires a
commitment to semantics first.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 May 2015 21:43:39 +0300

> On May 20, 2015, at 9:23 PM, Martin Thomson <[email-masked]> wrote:
> 

There’s never a commitment. Until a draft is approved by the IESG anything can be changed.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 May 2015 11:46:33 -0700

> There’s never a commitment. Until a draft is approved by the IESG anything can be changed.

What value is there in a code point if no two parties are able to
agree on its semantics?  I believe that the conditions for an early
request are:

1. we agree that there is enough demand for whatever it is now and
don't want to wait until the IESG approve a spec
2. we agree that the semantics are stable enough

This might meet the first, but it looks like the second is a little less firm.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 May 2015 22:27:38 +0300

> On May 20, 2015, at 9:46 PM, Martin Thomson <[email-masked]> wrote:
> 
> agree on its semantics?  

But we do agree on the semantics. They are whatever’s in the latest draft. And that’s good enough to implement and test interoperability. Of course if you ship it as anything other than an experimental feature, you are risking getting interoperability problems later, but this is no different from any draft, including those that do not require code point assignments.

> I believe that the conditions for an early
> request are:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 27 May 2015 12:10:05 +0300

On Tue, May 19, 2015 at 05:31:59PM -0400, Sean Turner wrote:
> This draft specifies the use of the ChaCha stream cipher with Poly1305
> in the TLS and DTLS protocols.  The WG needs this draft to specify code
> points in support of the recent MTI consensus call (see 
> http://www.ietf.org/mail-archive/web/tls/current/msg16343.html).
> If you object to the adoption of this draft as a WG item, please respond
> to the list indicating why by 20150602.

Adopt.

> We have a request for an early code point assignment for the cipher
> suites listed in the draft.  If you have a concern with an early code
> point assignment for the ciphers listed in this draft, please respond
> to the list indicating why by 20150602.  

I agree that the list of codepoints is bit broad for initial assignment.
Thomson's list (DHE_RSA, ECDHE_RSA, ECDHE_ECDSA, PSK, ECDHE_PSK) looks
reasonable. No concerns on early assignment on those.

Reading the Editor's Copy, the spec looks deployable. No concerns there.

Regarding nonce generation method, I did some programming experiments
with that, and I have no cocerns there.

-Ilari