Not that I am aware of. On Thu, Oct 22, 2015 at 10:06 AM, Andrei Popov <andrei.po...@microsoft.com> wrote:
> 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> wrote: > > Eric Rescorla wrote: > > Dave Garrett <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
