Subject: [TLS] draft-ietf-tls-tls13-16

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Sep 2016 16:42:14 -0700

I just uploaded draft-16.

   https://tools.ietf.org/html/draft-ietf-tls-tls13-16

The primary changes are listed below.

- New version negotiation format (*) [IMPORTANT: this got lost in the
ChangeLog]

- Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better
backwards compatibility (*)

- Move HelloRetryRequest.selected_group to an extension (*)

- Clarify the behavior of no exporter context and make it the same
  as an empty context.(*)

- New KeyUpdate format that allows for requesting/not-requesting an
  answer (*)

- New certificate_required alert (*)

- Forbid CertificateRequest with 0-RTT and PSK.

- Relax requirement to check SNI for 0-RTT.

-Ekr

---

From: Stephen Checkoway <[email-masked]>
Date: Wed, 28 Sep 2016 11:02:38 -0500

> On Sep 22, 2016, at 6:42 PM, Eric Rescorla <[email-masked]> wrote:
> 
> - New version negotiation format (*) [IMPORTANT: this got lost in the ChangeLog]

4.2.1 Supported Versions says, "The extension contains a list of
   supported versions in preference order, with the most preferred
   version first."

C.2 Negotiating with an older client says, "If the
   "supported_versions" extension is present, the server MUST negotiate
   the highest server-supported version found in that extension."

I'm skeptical of the server respecting client preferences in any situation*, but if servers are required to negotiate the highest supported version (which I think is sensible), then there's no point to the client giving preference order.

I propose moving the text about which version a server must negotiate out of the appendix to 4.2.1 and replacing the text mentioning client preference order with arbitrary order. (We could mandate descending version order, but it seems silly for the server to reject 0304, 0302, 0303 
if it's willing to negotiate 0304, for example.)

* The only time to take the client's preference into account is if the server really has no opinion on an option--e.g., two equivalent-strength cipher suites--but the client can specify a preference for an option that requires less computation/power for it. But I'm not entirely convinced that's worth the implementation cost.

-- 
Stephen Checkoway

---

From: Martin Thomson <[email-masked]>
Date: Thu, 29 Sep 2016 02:08:12 +1000

> * The only time to take the client's preference into account is if the server really has no opinion on an option--e.g., two equivalent-strength cipher suites--but the client can specify a preferenc…

I generally agree, though we just added one small exception to NSS,
and have been discussing another for a while now:  Respecting client
preference for ChaCha over GCM makes a real difference for clients
that don't have AES-NI.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 Sep 2016 16:08:53 +0000

>    the highest server-supported version found in that extension."

I agree that an appendix is the wrong place to put this.  And that specifying the client order is pointless.

But I disagree with this being a MUST.  There may be times when the server knows more than the client and will know that a lower version is more appropriate.  E.g., interfering middleboxes or regulatory regimes.
 
--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 Sep 2016 16:11:07 +0000

> I generally agree, though we just added one small exception to NSS, and
> have been discussing another for a while now:  Respecting client preference
> for ChaCha over GCM makes a real difference for clients that don't have AES-
> NI.

Yes, a number of net companies do this (Google, CloudFlare, Akamai and no doubt others).  OpenSSL will support something like this in a future release (boringSSL has "equivalence classes" but the syntax and limitations aren't great).

But it doesn't matter -- it's still the server choosing what to do :)
--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Stephen Checkoway <[email-masked]>
Date: Wed, 28 Sep 2016 11:18:45 -0500

> On Sep 28, 2016, at 11:08 AM, Salz, Rich <[email-masked]> wrote:
> 
> 

Seems reasonable. How about making selection from the list (if the extension is present) a MUST and selecting the highest server-supported version is RECOMMENDED? Perhaps the second part is unnecessary.

-- 
Stephen Checkoway

---

From: [email-masked] (Martin Rex)
Date: Wed, 28 Sep 2016 18:28:13 +0200 (CEST)

> But it doesn't matter -- it's still the server choosing what to do :)

For all TLS protocol parameters where the client presents a list
and the server selects one element from that list, it is a
server-local (policy) decision which one element it chooses.

Describing the order of elements in such lists as "client preference order" 
has led to numerous bogus server implementations, which erroneously
default to "do what the client proposes", rather than "do what the server
admin has configured".

Out-of-curiosity, is the ChaCha-over-GCM to be configurable for the
server admin, or is it hidden black magic?

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 Sep 2016 16:37:04 +0000

> Out-of-curiosity, is the ChaCha-over-GCM to be configurable for the server
> admin, or is it hidden black magic?

On the server-side, I think most of them work the same way:  if the client puts ChaCha at the start of its list, and the server is configured with ChaCha as one of its ciphers, then the server "moves" Chacha to the front of its list and proceeds as normal.  I think the CloudFlare patches just implemented that policy in code, based on patches they posted. I'm not going to say how Akamai did it except that no animal sacrifice is involved. I don't know how Google did it, but see next paragraph.

On the crypto-library side, boringSSL had equivalence classes so you could specify that by configuring the CIPHER list. If running in a server, and the configured ciphers were like "[AES:CHACHA]:3DES:RC4" for example, then either AES or ChaCha would be picked.  I don't know if Google servers use that, but I'd be a bit surprised if they didn't.

As for OpenSSL, we need to figure out something.  The "ciphers" syntax is showing its age.

---

From: Adam Langley <[email-masked]>
Date: Wed, 28 Sep 2016 10:06:35 -0700

> As for OpenSSL, we need to figure out something.  The "ciphers" syntax is showing its age.

The equal-preference groupings have worked pretty well for us in terms
of making the right thing happen and being understandable to
non-experts. I certainly agree that the ciphers mini-language could do
with some renewal overall.

But I think a lot of the need for it is also going away. We've spent
years worrying about should we do forward security? Do we put RC4
ahead of AES-CBC because of BEAST / POODLE / etc? What about the poor
performance of AES-GCM with Java (for a while)?

But since we've now drastically reduced the number of options, and
those options are (fingers crossed) less shitty than before, I'd hope
that a default would work for the vast majority of TLS 1.3 users.

Cheers

AGL

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Sep 2016 10:14:55 -0700

I don't really agree that we shouldn't specify client order. We do that
everywhere else in TLS.

Rather, I think we should relax the requirement to pick the highest one,
which is just a holdover from a less expressive negotiation mechanism.

-Ekr

On Wed, Sep 28, 2016 at 9:18 AM, Stephen Checkoway <[email-masked]> wrote:

> > I agree that an appendix is the wrong place to put this.  And that
> specifying the client order is pointless.
> >
> > But I disagree with this being a MUST.  There may be times when the
> server knows more than the client and will know that a lower version is
> more appropriate.  E.g., interfering middleboxes or regulatory regimes.
>
> Seems reasonable. How about making selection from the list (if the
> extension is present) a MUST and selecting the highest server-supported
> version is RECOMMENDED? Perhaps the second part is unnecessary.
>
> --
> Stephen Checkoway
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 28 Sep 2016 18:31:17 +0000

Ø  I don't really agree that we shouldn't specify client order. We do that everywhere else in TLS.
+ 1
While I agree that the server should be using the server’s preferences in most cases, I see no reason for the client to not list protocol versions (and cipher suites, for that matter) in the client’s order of preference. The client needs to send all supported options; no need to randomize the order.

Ø  Rather, I think we should relax the requirement to pick the highest one, which is just a holdover from a less expressive negotiation mechanism.
In addition, it’s not always clear what the “highest” TLS version is, e.g. in the presence of national TLS “standards”. E.g. a particular server may prefer TLS 0x0100 over TLS 0x0304.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Wednesday, September 28, 2016 10:15 AM
To: Stephen Checkoway <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] draft-ietf-tls-tls13-16

I don't really agree that we shouldn't specify client order. We do that everywhere else in TLS.

Rather, I think we should relax the requirement to pick the highest one, which is just a holdover from a less expressive negotiation mechanism.

-Ekr

On Wed, Sep 28, 2016 at 9:18 AM, Stephen Checkoway <[email-masked]<mailto:[email-masked]>> wrote:

> On Sep 28, 2016, at 11:08 AM, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:
>
>

--
Stephen Checkoway

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls