Re: [TLS] Curve25519 in TLS (Martin Rex) Thu, 17 October 2013 18:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 216B911E82A9 for <>; Thu, 17 Oct 2013 11:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ze7fSNWqdrhz for <>; Thu, 17 Oct 2013 11:30:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 88F8F11E81A2 for <>; Thu, 17 Oct 2013 11:30:18 -0700 (PDT)
Received: from by (26) with ESMTP id r9HIUF8l017742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Oct 2013 20:30:15 +0200 (MEST)
In-Reply-To: <>
To: Simon Josefsson <>
Date: Thu, 17 Oct 2013 20:30:15 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <>, "" <>
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: Thu, 17 Oct 2013 18:30:34 -0000

Simon Josefsson wrote:
> 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 should probably be a variable length vector so that the
format can be reused beyond curve25519 for similar curves with
longer keys (is curve3617 such a thing?)

> 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.

Extending plus subsetting rfc4492, so that PDUs and code points
for ECDH cipher suites can be shared between curve25519 and other
ECC curves, seems appropriate and acceptable.

But I would highly appreciate if the generic bloat, brittleness and
timing-sensitive ECC math of regular rfc4492 can be avoided as much
as possible.  So a new, simplified/specialized ECPoint format that
is mandatory for use with curve25519 and relatives, would help a lot.