Re: [TLS] Doubts in draft-ietf-tls-rfc4492bis

Raja ashok <> Tue, 25 July 2017 05:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39648127B57 for <>; Mon, 24 Jul 2017 22:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4eXImsmN9Q4Y for <>; Mon, 24 Jul 2017 22:26:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48830126DC2 for <>; Mon, 24 Jul 2017 22:26:42 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DLF98987; Tue, 25 Jul 2017 05:26:40 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 25 Jul 2017 06:26:38 +0100
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Tue, 25 Jul 2017 10:56:27 +0530
From: Raja ashok <>
To: David Benjamin <>
CC: "<>" <>
Thread-Topic: [TLS] Doubts in draft-ietf-tls-rfc4492bis
Thread-Index: AQHTBI1O+/71ZfDgdUGLLrPh7n3g+qJizhUAgAEsEvA=
Date: Tue, 25 Jul 2017 05:26:26 +0000
Message-ID: <>
References: <> <20170724145815.xuhzjqsbnf5eardr@LK-Perkele-VII> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2301389BLREML503MBXchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5976D690.00F5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f2f69cd4c5132b3e19eb3d4111334657
Archived-At: <>
Subject: Re: [TLS] Doubts in draft-ietf-tls-rfc4492bis
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jul 2017 05:26:46 -0000

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.



Raja Ashok V K
Huawei Technologies
Bangalore, India
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 []
Sent: 24 July 2017 21:57
To: Ilari Liusvaara; Raja ashok
Cc: <>
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.


[*] 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 <<>> 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

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.


TLS mailing list<>