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

[Andrey Jivsov <[e-mail]>]

On 04/02/2014 11:22 AM, Alyssa Rowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
...