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

Ilari Liusvaara <> Mon, 24 July 2017 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 926D0131C32 for <>; Mon, 24 Jul 2017 07:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MI2yXDbC9TEs for <>; Mon, 24 Jul 2017 07:58:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 77BC8127058 for <>; Mon, 24 Jul 2017 07:58:20 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8171D222A6; Mon, 24 Jul 2017 17:58:18 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id 2TTiDNgGewob; Mon, 24 Jul 2017 17:58:18 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 437B1C4; Mon, 24 Jul 2017 17:58:16 +0300 (EEST)
Date: Mon, 24 Jul 2017 17:58:16 +0300
From: Ilari Liusvaara <>
To: Raja ashok <>
Cc: "<>" <>
Message-ID: <20170724145815.xuhzjqsbnf5eardr@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: NeoMutt/20170609 (1.8.3)
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: Mon, 24 Jul 2017 14:58:23 -0000

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.