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

Andrey Jivsov <> Thu, 03 April 2014 06:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B59C1A00C2 for <>; Wed, 2 Apr 2014 23:04:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ROmlP61VJbFi for <>; Wed, 2 Apr 2014 23:03:55 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe2d:44:76:96:27:227]) by (Postfix) with ESMTP id 5C4671A00B9 for <>; Wed, 2 Apr 2014 23:03:55 -0700 (PDT)
Received: from ([]) by with comcast id lHxa1n00616AWCU01J3rAT; Thu, 03 Apr 2014 06:03:51 +0000
Received: from [] ([]) by with comcast id lJ3q1n0014uhcbK8SJ3qqs; Thu, 03 Apr 2014 06:03:51 +0000
Message-ID: <>
Date: Wed, 02 Apr 2014 23:03:49 -0700
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1396505031; bh=dFhaTEjF3p3jfp5/fwGlmI6FES0z27BusgsUDlnksPc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Jxet6QmQLBAF5owjvdp1r2Ae5OnxzU9iW/p2PWhW9MOhPdXmoE+BWX0Nm8cGaShhp vn2v0aw94OFyy9irot2KotMu9Vp8yJrrK6adkVxCCs9U49bGpKNxgpJXQRgPCPwgky 4UjeNQqVBbxbkkqu6uKL/FCXIUwG4fPP2tDcEf15MGAcJLF0kbQdOurHCTCRoDo72M b8/C+VFieT6OTiR3kyaX7LTuZ/ouKCUvOGfykFNc54tY+1/YkbPgWcxRr1wZKRfIy7 N30nfoY0LVzUYsNYn3SitS6qZ5awDWnYjUQdfO5xPkUump2VQRbPlF+z6WTcl/CM3c Ydxhf3zL9hCdw==
Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Apr 2014 06:04:01 -0000

On 04/02/2014 11:22 AM, Alyssa Rowan wrote:
> Hash: SHA512
> On 02/04/2014 17:43, Kurt Roeckx wrote:
>> So what's the status of this? [draft-josefsson-tls-curve25519]
> As I recall, there were only three issues raised in the discussion in
> January (and one tiny one I'm raising now that is very easily fixed in
> the normal course of RFC editing). Discussion seemed to just peter out
> after then.
> If I may summarise where we left off (and _please_ speak out if you
> feel I'm grossly mischaracterising anything or got anything wrong!):—
> 1. Draft-04 uses its own point format, a 'big-endian' representation,
>     (and adds a length byte).
>     That differed from every existing Curve25519 implementation in the
>     wild, which use a 'little-endian' representation.
>     • Both Rich Salz and Robert Ransom spoke strongly for simply using
>       the existing little-endian format used by all Curve25519
>       implementations already in the wild, and pointed out there was no
>       technical reason to break compatibility and change that to
>       anything else.
>       [No such technical reasons were seemingly presented in the ensuing
>        discussion. /akr]
>     • Manuel Pégourié-Gonnard wasn't married to the point format in -04,
>       had no objection to using the existing little-endian format, and
>       requested comments 'in the next few days' from anyone who did have
>       objections.
>     • Watson Ladd said endianness wasn't a good reason to vote no, and
>       asked please not to reignite the endianness 'holy war'.
>     • Nikos Mavrogiannopoulos pointed out protocols are often expected
>       to outlive existing implementations and aren't typically designed
>       based on them.
>       [Although this one would, presumably, be an exception? /akr]
>       He also pointed out almost all IETF protocols use the big-endian
>       format for transferring integers, so that implementations would be
>       prepared for any endian issues anyway.
>     • James Cloos suggested 'Internet-endian is the better choice'.
>       [I presume, from context, that he meant big-endian. /akr]
>     • Bill Frantz simply pointed out that it wouldn't be unprecedented
>       to have little-endian data in an Internet Protocol.
>     [For what it's worth - i.e. almost nothing! - I myself favour
>      matching the Curve25519 reference: so, little-endian. /akr]
> 2. We need to specify what, exactly, to do with the unused high bit.
>     As the discussion in January covered, except for one, buggy
>     implementation, all Curve25519 implementations in the wild always
>     produce 0, and always ignore it.
>     We should probably specify that as required behaviour; it allows for
>     using it for something else later, which was discussed. Manuel
>     agreed that implementations SHOULD mask off the high bit. That's not
>     in draft-04, but it should be in -05?
>     There was talk about maybe using it later for sign-of-y or something
>     else, for other protocols. I don't know if that went anywhere.
>     [Again, I favour the draft simply matching the original Curve25519
>      implementation: high bit SHOULD be 0, high bit SHOULD be ignored.
>      /akr]
> 3. The length byte was talked about, and the consensus seemed broadly
>     to be: specify 32 now, allow 64 for if we want, say, an Edwards-form
>     y-coordinate for some other protocol later, and have the first 32
>     bytes of that match the 32-byte format.
>     [I have no position on this. /akr]

The ECPoint is defined as follows,

            struct {
                opaque point <1..2^8-1>;
            } ECPoint;

Is the format on the wire per section 2.3
    33 32 xx xx xx ... xx
or, suggested,
    65 64 xx xx xx ... xx yy yy yy ... yy ?

Or I am reading it incorrectly and the extra byte mentioned in the draft 
is actully a part of standard TLS encoding of the length byte?

At first I interpreted it as former. Then the question is why the 
(excessive) length byte is needed? The negotiated Curve25519 tells that 
32 bytes are expected. (If there are 64, there is a y there.)

> 4. The NamedCurve value allocation is still [TBD1] in -04 - we'd need an
>     actual value allocated before implementing that in the wild (outside
>     of pure testing, where we can just use a private value)?
> That's about all I can remember. Were there any other substantive issues?
> Thanks for reminding us about the stalled discussion.
> I'm keen to start getting things out there myself: if we can wrap up
> the remaining issues, I think that'd be good for everyone.
> - --
> /akr