Re: [TLS] Curve25519 in TLS

Simon Josefsson <> Wed, 16 October 2013 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38C5E11E814B for <>; Wed, 16 Oct 2013 13:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w+5OaQAECSY5 for <>; Wed, 16 Oct 2013 13:17:51 -0700 (PDT)
Received: from ( [IPv6:2001:9b0:1:1702::100]) by (Postfix) with ESMTP id 7C23411E813A for <>; Wed, 16 Oct 2013 13:17:51 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4) with ESMTP id r9GKGfhn006919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Oct 2013 22:16:42 +0200
Date: Wed, 16 Oct 2013 22:16:40 +0200
From: Simon Josefsson <>
To: Manuel =?ISO-8859-1?B?UOlnb3VyaektR29ubmFyZA==?= <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.97.8 at
X-Virus-Status: Clean
Cc: "" <>
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 20:17:52 -0000

You wrote:

> Thinking about it, I'm inclined to say we don't need to define a new
> ECPointFormat entry, the I-D should just mandate that support for
> (resp. use of) curve25519 implies support for (resp. use of) the
> associated (unamed) point format. This avoids possible consistency
> issues like a client advertising support for the curve but not for
> the associated point format.
> Similarly, the usual point formats have a leading byte indicating the
> format used, that should IMO be dropped for curve25519.
> So this would lead to the definition that, for this curve, instead of
> containing "the byte string representation of a field element
> following the conversion routine in Section 4.3.3 of ANSI X9.62", the
> point member of the ECPoint structure contains an opaque[32]
> representing the x-coordinate of the point.

This sounds like a feasible approach to me.  Maybe we need to put this
solution in writing, and maybe put some of the other options in writing
as well, to allow people to make an informed decision of where to go.  I
think this thread has been quite informative, and I'm hoping we can
reach some early consensus and update the draft with that.