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

On Thu, Apr 3, 2014 at 1:55 AM, Manuel Pégourié-Gonnard
<mpg@polarssl.org> 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.

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?

Sincerely,
Watson Ladd

>
> Manuel.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin