Re: [TLS] Should we require compressed points

[Manuel Pégourié-Gonnard <[e-mail]>]

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.
- 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).

Manuel.