Re: [TLS] Should we require compressed points

[Michael StJohns <[e-mail]>]

On 11/1/2014 4:59 PM, Manuel Pégourié-Gonnard wrote:
> On 01/11/2014 19:24, Michael StJohns wrote:
>> On 11/1/2014 1:21 PM, Manuel Pégourié-Gonnard wrote:
>>> On 31/10/2014 19:31, Ilari Liusvaara wrote:
>>>> Note that 8.1.1 does not quite match that beheviour, since it specifes
>>>> leading zero octets to be stripped (whereas DHE "element" encoding
>>>> doesn't seem to specify if zeroes are stripped or not)
>>>>
>>> I think it makes sense to accept non-canonical representation of DHE elements as
>>> long as it's not ambiguous (be liberal in what you accept), while for the PMS
>>> it's necessary to be strict in order to ensure interop. But I wouldn't be oppose
>>> to something like "DHE elemens MUST be encoded without leading zeroes, but
>>> implementations MAY accept leading zeroes in their encoding".
>> Sorry - this won't work.
>>
>> This (8.1.2) is about taking the derived shared secret and representing
>> it as a byte string for input into a key derivation function (the TLS
>> PRF for 1.2 basically).
>>
> Sorry for not being clear: I was referring to the part about representing DHE
> elements on the wire, not as part of the PMS. Here we agree the representation
> has to be unique (I was trying to say that actually, but I must have missed a
> few words).
>
> Let me try and rephrase:
> - for the PMS the RFC needs to specify if the representation is fixed-length or
> without leading zeroes.
> - for the on-the-wire representation it doesn't matter AFAICS.

There are well defined formats for bignums as bignums (e.g. the DH 
public params):
>    Note that in some cases (e.g., DH parameters) it is necessary to
>     represent integers as opaque vectors.  In such cases, they are
>     represented as unsigned integers (i.e., leading zero octets are not
>     required even if the most significant bit is set).

The text is actually subject to some small quibbling - it should be 
"represented as unsigned big-endian integers" to avoid doubt.

So the unique representation for DH stuff is the on-the-wire standard 
representation of a positive bignum.  I don't think there really needs 
to be any further restriction of the on-the-wire format.

> - so I'm not shocked by the fact that the requirement about encoding on-the-wire
> and for the PMS are different for ff-dh.
> - but I wouldn't mind either if the on-the-wire requirements were aligned to the
> stricter requirements that are necessary for the PMS, for the sake of
> uniformity/simplicity, as long as implementations are allowed to be liberal
> about on-the-wire representation (unless there is a security risk in doing so,
> which I don't think there is).

The PMS is an octet string key, the DH params are bignums.   I wish the 
TLS "DH shared secret-to-octet string PMS" function would align with the 
standards and with other common uses, but that boat sailed years ago.  I 
don't think there's any good reason to further restrict the 
representation (among other things, some bignum libs return the 
magnitude array without leading zeros, while others return a leading 
zero  array if the high bit of the value is set). The current encoding 
just lets you drop that value into the wire format.

Mike

>
> Manuel.
>
>