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

[Alyssa Rowan <[e-mail]>]

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


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
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTPFVKAAoJEOyEjtkWi2t6o3kP/1ZWnVr5jd7m3/S8H/IBY7kK
7VWgjlrgb3x6QqflU5xDwgrGNelp2m5FY4IKKUr0DPfIvGkXP+vKttXO+EWligq8
biP+DeObsstJ3Sb9tqd1pD4is3/Wb/Y6Zbo2PE+Qu5edF5wFX1lTJPtqMl9Lh6Ux
Wev+dgQD7EXf+tgw9MXB92dhs9qS+zMFBUfH79QEC7QJI4kH7KCQlzTVBHB0Px1g
wesrN0QEpgx1lY2/dw2lnejZaty6dsjbGKtYB416+qpNSlKvwSHchnFfz8dd/Krp
u8+/JW3hLgnQsv8DzFHj31ZQAYoE/3HjrqXqm9bA2U4CtuVl+Crhprc+7f7JpuXi
YfRZfY4+VswW2LRLRSHf1Gxa2oURqpEzYyk4R5XH7lIVBnD0nEqMoxLrHr3leA9a
aDhse6SCbytpACrpVh/a/U9mf27jT7yno9KVdGeX/0WdJQRDPu3s+gN26/38jwCk
tw3rxzCv911r4T7NA0vnwRW6lZLwAf6TWo64xJHcvDpq1QUFE61MJSOx4Z2H0xQ1
bXcZQoejEEkutYH0HXdbpsgr4aHsle8emwW9UdP6yyFzdRgN43QkAFUmKkMdRcrB
rVQoPPxuiTPr4VM/Ii4vOViOjvaHoEuN1cKt+F1oPV5/33uhQt1oA10cvomM4QZ9
RwgW7YnKIyZ0HxwGlkyn
=bm10
-----END PGP SIGNATURE-----