Re: [TLS] Curve25519 in TLS

Manuel Pégourié-Gonnard <> Wed, 16 October 2013 13:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9282711E82A3 for <>; Wed, 16 Oct 2013 06:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TmB5qOns+uLg for <>; Wed, 16 Oct 2013 06:05:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 798F811E8268 for <>; Wed, 16 Oct 2013 06:05:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 3961B16153; Wed, 16 Oct 2013 15:05:04 +0200 (CEST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 95B51260A6; Wed, 16 Oct 2013 15:05:00 +0200 (CEST)
Message-ID: <>
Date: Wed, 16 Oct 2013 15:05:00 +0200
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
OpenPGP: id=98EED379; url=
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <>,
Subject: Re: [TLS] Curve25519 in TLS
X-Mailman-Version: 2.1.12
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: Wed, 16 Oct 2013 13:05:17 -0000

On 16/10/2013 08:42, Martin Rex wrote:
> Make it work completely _without_ rfc4492 bloat,
> and similar to DH instead, defining new KeyExchange Methods
> and seperate ciphersuites for it.
If we want to cover all existing key exchanges and ciphersuites, this would mean
defining four new key exchanges (ECDH25519-PSK,RSA,ECDSA,anon), and 52 new
ciphersuites currently. And then duplicating every ECDHE-based ciphersuite
defined in the future. And if at some point, a new Montgomery or Edwards curve
is proposed (maybe the recent curve3617), duplicating all that again.

That's quite a lot of trouble: what specific problem would it solve? What
exactly do you mean by RFC 4492 "bloat", and in which specific way defining new
key exchanges would make it lighter? As an implementer, I don't feel like adding
new key exchanges for Curve25519 would make my life any easier, as it would come
*in addition* to RFC 4492 support.

Anyway, I believe that cryptographic parameters agility is a highly desirable
property of a protocol like TLS, and RFC 4492 provide that, better than
specialised key exchanges supporting only one curve. If that solution had been
adopted in early 2006, the only one curve would probably have been a NIST curve
(curve25519 was very new at the time, while NIST curves had been around for
years), and you wouldn't be very happy now, I guess.

I hope my first post didn't give the wrong impression: I don't think the
framework from RFC 4492 is a misfit for the Curve25519 ECDH function, the only
real point of friction is the encoding of the public keys. The other remarks I
made are merely things I'd like to see clarified in the draft, and information
that seemed relevant to me to discuss the public key format.