I believe what Raja is pointing out is that a server which accepts an ECDSA *client* certificate has no way to advertise to the client which curves it accepts. The signature algorithm list (and before TLS 1.2, the certificate types) do advertise ECDSA as a whole, but not curves. E.g., a client with both a P-256 and P-384 certificate may send P-384 when the server only accepted P-256. This issue existed in RFC 4492 as well.
Though I wouldn't say the implication is all curves must be implemented. Rather I think you just reject those curves you don't accept and manage your client certificate deployment so that all servers accept a curve before starting to use those certificates. That's not great, so TLS 1.3 fixes this by moving ECDSA curves into signature algorithms. It's too late to change supported_groups to allow a TLS 1.2 ServerHello acknowledgement since clients will unexpected server extensions[*], so I would suggest we just leave this in the awkward state for TLS 1.2 and say it is fixed in TLS 1.3. David [*] Although, glancing through ours, it seems we do accept and ignore a ServerHello supported_groups in TLS 1.2. We apparently came across a server implementation which sent it, contrary to the spec. On Mon, Jul 24, 2017 at 10:58 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Mon, Jul 24, 2017 at 01:48:13PM +0000, Raja ashok wrote: > > Hi Nir, Josefsson & Pegourie, > > > > As per section 5.2 server should send only "Supported Point Format" > > extensions in server hello message. And it doesn't require to send > > "Supported Elliptic Curve" extensions. Because of this if server is > > supporting only few Curves and if it receives unsupported Elliptic > > curve in client certificate message, then server might not be able > > to continue the handshake. > > In TLS 1.2, the client sends the list of curves (and other groups > and DHFs) it supports. The server picks one if it can. > > Thus if there is at least one common curve that both client and > server support, then the group selection will succeed (if there > is none, then no matter what one does things won't work). > > The actual curve server selected is transmitted in ServerKeyExchange > message. > > > In TLS 1.3, things get bit more complicated, since client can > signal it supports a group without sending a share for it (if > server selects such group, it needs to tell the client to retry > using HelloRetryRequest message). The server group selection is > in KeyShare extension in ServerHello message. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
