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

[Andrey Jivsov <[e-mail]>]

On 04/03/2014 09:52 AM, Watson Ladd wrote:
> On Thu, Apr 3, 2014 at 1:55 AM, Manuel Pégourié-Gonnard
> <[e-mail]> wrote:
>> On 03/04/2014 08:03, Andrey Jivsov wrote:
>>> 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?
>>>
>> The intention of the current draft is that the wire format be
>>
>> 32 xx xx ... xx
>>
>> So the "additional length byte" is indeed just the one from the TLS encoding.
>>
>> In the next iteration of the draft, it might change to
>>
>> 33 tt xx xx .. xx
>>
>> Where tt would be an "encoding type" which would allow for future extensions
>> like transmitting y too, or a bit of y, or (parts of) other representation (eg
>> Edwards coordinates).
> I don't think this is a good idea. At the time when one side sees the
> point it is too late to negotiate. So points with different encodings
> should be indicated as different in the Client Hello message to enable
> negotiation of which one to send. Furthermore, I don't see benefit to
> the potential extensions yet for pure DH.
I second this.

> Also, do we really need a length prefix on a string that is always 32
> bytes long? I get that the TLS encoding provides that, but length
> prefix formats are a can of worms: what should happen when 33 0 or 32
> 32 xx .. are encountered?
>
I assume you are commenting on the case with tt present. Certainly, 
there will need to be consistency checks with such a tt.

My reply regarding the current draft with clarification from Manuel follows:

RFC 5246 is listed as a normative reference. As such, it defines the the 
encoding for the

    opaque something <1..2^8-1>

The reader is expected to know that "something" is encoded with an additional byte for the length. Thus, I find the item (2) in sec. 2.3 confusing (IMHO more confusing than helpful).

>     Note that ECPoint.point differs from the definition of public keys in
>     [Curve25519  <http://tools.ietf.org/html/draft-josefsson-tls-curve25519-04#ref-Curve25519>] in two ways: (1) the byte-ordering is big-endian, wich
>     is more uniform with how big integers are represented in TLS, and (2)
>     there is an additional length byte (so ECpoint.point is actually 33
>     bytes), again for uniformity (and extensibility).

Would the following be clearer:

> Unlike the definition of public keys specified in [Curve25519],
> ECPoint.point uses big-endian byte ordering. As defined in [RFC5246],
> the ECPoint.point is serialized with one-byte block size. The payload must be 32
> bytes, even when one or more leading bytes are zeros.


...