Re: [TLS] Allow NamedGroups from the server?

[Andrei Popov <[e-mail]>]

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

Cheers,

Andrei

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



On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex <[e-mail]<mailto:[e-mail]>> wrote:
Eric Rescorla wrote:
> Dave Garrett <[e-mail]<mailto:[e-mail]>> wrote:
>
>> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla 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>
>>>
>>> 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.
>>
>> 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.


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

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