Would the server-side “supported elliptic curves” be used for anything other than guiding client cert selection?
Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Thursday, October 22, 2015 6:29 AM To: m...@sap.com Cc: tls@ietf.org Subject: Re: [TLS] Allow NamedGroups from the server? On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex <m...@sap.com<mailto:m...@sap.com>> wrote: Eric Rescorla wrote: > Dave Garrett <davemgarr...@gmail.com<mailto:davemgarr...@gmail.com>> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
