Hi David, Thanks for your response.
If it is already fixed in TLS1.3, then I also feel ok to leave this behavior for older version (TLS1.2 and earlier). Recently I started reading TLS1.3 specification, I will go through fully to get more info. Regards, Ashok ________________________________ [Company_logo] Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ________________________________ 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: David Benjamin [mailto:david...@chromium.org] Sent: 24 July 2017 21:57 To: Ilari Liusvaara; Raja ashok Cc: <tls@ietf.org> Subject: Re: [TLS] Doubts in draft-ietf-tls-rfc4492bis 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<mailto: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<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
