IETF Logo Mail Archive

Re: [TLS] Curve25519 in TLS and Additional Curves in TLS

Manuel Pégourié-Gonnard <mpg@polarssl.org> Wed, 22 January 2014 23:45 UTC

Return-Path: <mpg@polarssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209B81A03C4 for <tls@ietfa.amsl.com>; Wed, 22 Jan 2014 15:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.893
X-Spam-Level: **
X-Spam-Status: No, score=2.893 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PdoESjPWQd3 for <tls@ietfa.amsl.com>; Wed, 22 Jan 2014 15:45:00 -0800 (PST)
Received: from mordell.elzevir.fr (unknown [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id 94B1C1A00C8 for <tls@ietf.org>; Wed, 22 Jan 2014 15:45:00 -0800 (PST)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 65DA316431 for <tls@ietf.org>; Thu, 23 Jan 2014 00:44:59 +0100 (CET)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 724282986C for <tls@ietf.org>; Thu, 23 Jan 2014 00:44:58 +0100 (CET)
Message-ID: <52E057F8.8040906@polarssl.org>
Date: Thu, 23 Jan 2014 00:44:56 +0100
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <87ob3456s1.fsf@latte.josefsson.org> <52E008DD.9050002@comodo.com>
In-Reply-To: <52E008DD.9050002@comodo.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 23:45:02 -0000

On 22/01/2014 19:07, Rob Stradling wrote:
> Simon, Section 2.1 says:
>    "Since Curve25519 are not designed to be used in signatures, clients
>     who offer ECDHE_ECDSA ciphersuites and advertise support for
>     Curve25519 in the elliptic_curves ClientHello extension SHOULD also
>     advertise support for at least one other curve, suitable for ECDSA.
>     Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common
>     curve is Curve25519."
> 
> Why is that "SHOULD" not a MUST?
> 
The idea is that, if a client offers ECDHE_ECDSA ciphersuites but no
ECDSA-capable curve, the handshake can still be completed if non-ECDSA
ciphersuites are offered too: the server will select one of these suites. In
this case, offering ECDHE_ECDSA suite is just a waste of bytes, but does not
harm interoperability.

Making it a SHOULD may simplify client-side implementations in which the user
can select the list of supported curves and ciphersuites, by allowing the
implementation not to filter the list of ciphersuites based on the selected curves.

Manuel.

v2.23.0 | Report a Bug | By Email