Subject: [TLS] Allow NamedGroups from the server?

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Oct 2015 16:56:13 -0700

https://github.com/tlswg/tls13-spec/issues/292

Presently, RFC 4492 only specifies the EC points it can support in
ServerHello, but does not let the server indicate which EC curves it
supports. Unless I'm missing something, this means that there's
no way for the server to indicate what groups it would support.

That seems less than ideal. There seem like three options here:

1. Put it in CertificateRequest
2. Send it in ServerHello
3. Do nothing.

Thoughts?
-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Oct 2015 17:01:06 -0700

2b. encrypted extensions over ServerHello

If we make this like signature_algorithms, then I think that I prefer
option 1.  I don't like that signature_algorithms is built that way, I
think that it's repulsive, but there are some advantages to doing it
that way, especially if we accept the fact that the client can
authenticate multiple times, so I'm willing to live with that.

On 21 October 2015 at 16:56, Eric Rescorla <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 22 Oct 2015 00:09:33 +0000

If it's true that the only use of this indication is client auth, then option 1 makes the most sense to me.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Wednesday, October 21, 2015 5:01 PM
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Allow NamedGroups from the server?

If we make this like signature_algorithms, then I think that I prefer option 1.  I don't like that signature_algorithms is built that way, I think that it's repulsive, but there are some advantages to doing it that way, especially if we accept the fact that the client can authenticate multiple times, so I'm willing to live with that.

On 21 October 2015 at 16:56, Eric Rescorla <[email-masked]> wrote:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2ftlswg%2ftls13-spec%2fissues%2f292&data=01%7c01%7cAndrei.Popov%
> 40microsoft.com%7c6625ee4cf40f4f52917108d2da73ea39%7c72f988bf86f141af9
> 1ab2d7cd011db47%7c1&sdata=qOVO5xpSgVIXG6%2fiMyP3zQSbeFwZlrDW1kcqvONCRD
> Y%3d
>
> supports. Unless I'm missing something, this means that there's no way 
> for the server to indicate what groups it would support.
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40micro
> soft.com%7c6625ee4cf40f4f52917108d2da73ea39%7c72f988bf86f141af91ab2d7c
> d011db47%7c1&sdata=%2f612ldpCER8pXNtxSxUfQjhuYcMAIZ2S3o1ozmxqqWI%3d
>

_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c6625ee4cf40f4f52917108d2da73ea39%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2f612ldpCER8pXNtxSxUfQjhuYcMAIZ2S3o1ozmxqqWI%3d

---

From: Dave Garrett <[email-masked]>
Date: Wed, 21 Oct 2015 20:29:06 -0400

> 2. Send it in ServerHello

I prefer #2. I don't think encryption is necessarily required for this, but EncryptedExtensions is fine too (Martin's 2b).

I'm generally against putting it in CertificateRequest, as we're reusing an existing hello extension so keeping it in a hello message (or it's trailing encrypted field) seems best. (restricted to TLS 1.3+ clients, though)

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Oct 2015 17:35:02 -0700

On Wed, Oct 21, 2015 at 5:29 PM, Dave Garrett <[email-masked]>
wrote:

> I prefer #2. I don't think encryption is necessarily required for this,
> but EncryptedExtensions is fine too (Martin's 2b).
>
> I'm generally against putting it in CertificateRequest, as we're reusing
> an existing hello extension so keeping it in a hello message (or it's
> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,
> though)

This would need to be limited to 1.3 in any case because in all the other
cases
it would be illegal.

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Thu, 22 Oct 2015 14:55:57 +0200 (CEST)

Eric Rescorla wrote:
> Dave Garrett <[email-masked]> wrote:
> 
> cases it would be illegal.

Why do you believe that it would be "illegal" for a TLSv1.[012] server
to return a "Supported Elliptic Curves" TLS extension in ServerHello
in response to the presence of such a TLS extension in ClientHello?

rfc4492 does not define semantics for the presence of "Supported Elliptic
Curves" TLS extension in ServerHello, but on a quick read, it also does
not prohibit including/sending it.

https://tools.ietf.org/html/rfc4492#section-5.2

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Oct 2015 06:29:22 -0700

> https://tools.ietf.org/html/rfc4492#section-5.2

Well, the draft says that it is defining two ClientHello extensions
(supported elliptic curves and supported point formats) and that it is
defining
one ServerHello extension, so if the server is sending supported elliptic
curves it's doing something undefined. I don't think you need to have
an explicit prohibition to suggest that doing something undefined isn't
great.

>From an implementation perspective, I wouldn't be surprised if client
implementations choked on the server sending this. I had to check
to see if NSS would do so. It doesn't, but given the way the code
is written, it wouldn't have surprised me if it checked that all extensions
were handled and choked otherwise.

-Ekr

-Martin

---

From: Andrei Popov <[email-masked]>
Date: Thu, 22 Oct 2015 17:06:04 +0000

Would the server-side “supported elliptic curves” be used for anything other than guiding client cert selection?

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, October 22, 2015 6:29 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Allow NamedGroups from the server?

On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex <[email-masked]<mailto:[email-masked]>> wrote:
Eric Rescorla wrote:
> Dave Garrett <[email-masked]<mailto:[email-masked]>> wrote:
>
>>> https://github.com/tlswg/tls13-spec/issues/292<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fissues%2f292&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c55fa019d2b514077868108d2dae4eab9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4FfUfD78WcOKL6JuvHQ4aX4jrXXR35XD858DhOTMkdc%3d>
>>>

https://tools.ietf.org/html/rfc4492#section-5.2<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc4492%23section-5.2&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c55fa019d2b514077868108d2dae4eab9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jNoHM%2frP9jxkRUPFaIsSzXfJcVmBwnqNM8M7Nm2vtwc%3d>

(supported elliptic curves and supported point formats) and that it is defining

-Ekr

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Oct 2015 10:07:46 -0700

Not that I am aware of.

On Thu, Oct 22, 2015 at 10:06 AM, Andrei Popov <[email-masked]>
wrote:

> Would the server-side “supported elliptic curves” be used for anything
> other than guiding client cert selection?
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, October 22, 2015 6:29 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] Allow NamedGroups from the server?
>
>
>
>
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fissues%2f292&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c55fa019d2b514077868108d2dae4eab9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4FfUfD78WcOKL6JuvHQ4aX4jrXXR35XD858DhOTMkdc%3d>
> >>>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc4492%23section-5.2&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c55fa019d2b514077868108d2dae4eab9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jNoHM%2frP9jxkRUPFaIsSzXfJcVmBwnqNM8M7Nm2vtwc%3d>
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 22 Oct 2015 17:11:50 +0000

Then my argument would be: why send extra bytes in each ServerHello when TLS client auth is not used most of the time? In this case, CertificateRequest seems to be a better place.

From: Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 10:08 AM
To: Andrei Popov <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [TLS] Allow NamedGroups from the server?

Not that I am aware of.

On Thu, Oct 22, 2015 at 10:06 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Would the server-side “supported elliptic curves” be used for anything other than guiding client cert selection?

Cheers,

Andrei

From: TLS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: Thursday, October 22, 2015 6:29 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Allow NamedGroups from the server?

-Ekr

-Martin

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Oct 2015 10:35:21 -0700

On 22 October 2015 at 10:11, Andrei Popov <[email-masked]> wrote:
> Then my argument would be: why send extra bytes in each ServerHello when TLS
> client auth is not used most of the time? In this case, CertificateRequest
> seems to be a better place.

I think that this is the best argument for CertificateRequest.

We can prohibit the inclusion of the extension in ServerHello (or
Server EncryptedExtensions) as we please then.  I would argue for
prohibiting it, since it has no purpose.

---

From: [email-masked] (Martin Rex)
Date: Thu, 22 Oct 2015 19:36:18 +0200 (CEST)

Andrei Popov wrote:
>
> Then my argument would be: why send extra bytes in each ServerHello
> when TLS client auth is not used most of the time? In this case,
> CertificateRequest seems to be a better place.

I'm perfectly OK with the server _not_ sending/including a TLS extension
"Supported Elliptic Curves" in ServerHello if the server is not going
to request a client certificate.

This is first of all about a fully backwards-compatible change of the
protocol, which does not need to be seperately negotiated, and which
is optional to use (for the server).

By including the information in "CertificateRequest", it will be
necessary to change the CertificateRequest PDU, and that will require
a new negotiation of such a changed PDU for existing TLS protocol
versions (TLSv1.0/1.1/1.2).

Conveying the information through ServerHello should work just fine
with existing implementations, does not need any additional negotiation
through ClientHello&ServerHello and does not need to change an existing
PDU (CertificateRequest).

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Oct 2015 10:39:39 -0700

> is optional to use (for the server).

It's not clear that it's in fact backwards compatible, since this is an
undefined
area in the spec.

As I mentioned earlier, I wasn't sure how NSS behaved here and so before
we even considered this [and I would still have to test to be totally sure]
and we would need to take some sort of measurement
from servers to determine that this does not cause bustage.

> versions (TLSv1.0/1.1/1.2).

We are already changing CertificateRequest in TLS 1.3 and we could (and
probably should do nothing for previous versions of TLS).

-Ekr

---

From: Andrei Popov <[email-masked]>
Date: Thu, 22 Oct 2015 18:10:47 +0000

To be clear, I'm in favor of introducing server-side NamedGroups in 1.3. I've no interest in making this change in any earlier protocol versions.

Cheers,

Andrei
________________________________
From: Eric Rescorla
Sent: 10/22/2015 10:40 AM
To: [email-masked]
Cc: Andrei Popov; [email-masked]
Subject: Re: [TLS] Allow NamedGroups from the server?

On Thu, Oct 22, 2015 at 10:36 AM, Martin Rex <[email-masked]<mailto:[email-masked]>> wrote:

It's not clear that it's in fact backwards compatible, since this is an undefined
area in the spec.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Thu, 22 Oct 2015 20:14:04 -0400

On Thursday, October 22, 2015 09:29:22 am Eric Rescorla wrote:
> implementations choked on the server sending this. [...]

Hence my side-note that we should be explicit that it's for TLS 1.3+ (even if it's implicit elsewhere).

> to request a client certificate.

Yes, I would expect we want it in TLS 1.3+ ServerHello (or EncryptedExtensions) IFF the server is going to request a client cert.

Dave