Re: [TLS] Should we require compressed points

[Michael StJohns <[e-mail]>]

Below - inline.

On 11/1/2014 1:21 PM, Manuel Pégourié-Gonnard wrote:
> On 31/10/2014 19:31, Ilari Liusvaara wrote:
>> On Fri, Oct 31, 2014 at 10:34:52AM -0700, Eric Rescorla wrote:
>>> This discussion seems to be settling, so I've prepared a pull request
>>> that implements Bodo's suggestion:
>>>
>>> https://github.com/tlswg/tls13-spec/pull/86
>>   
>> I think 8.1.2 (ECDHE premaster secret calculation) should be modified
>> as well, to specify using the fixed wire encoding of selected group for
>> premaster secret.
>>
> Just to be clear: this would change the way the PMS is computed for the existing
> curves, right? I'm not opposed to it, I just want to make sure we're on the same
> line.
>
>> This is to avoid problems with more "odd" encodings.
>>
> I think this is indeed a very desirable outcome, that is achieved by your proposal.
>
>> 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).

For example, the bignum value '1' can be represented as 01, as 00 00 00 
01 or with any number of leading bytes.   But KDF ({01}) gives you a 
different result than KDF ({00 00 00 01}) etc.

In X9.42, X9.62 and in the NIST version of DH/ECDH, the bignum result of 
the ECDH operation is translated to a byte string via an "Integer to 
Octet String" conversion.   In all of these, the length of the octet 
string is fixed to match the order of one of the parameters, is big 
endian, and is not variable in length (e.g. the leading 00 bytes are not 
truncated).  TLS - for I'm sure what must have been good reasons at the 
time - decided to do it differently for DH (by truncating leading 0 bytes).

However, TLS ECDH matches the guidances in X9.62 and in SP800-56A which 
preserves leading zeros and has a fixed shared secret length based on 
the curve parameters.  (RFC4492, section 5.10).

The point of the above is that the conversion from the bignum shared 
secret to the octet string used as the premaster secret prior to being 
input into the key derivation function needs to be of a well-known 
length for any given parameter set so MUST is a "MUST" for DH.

Ideally, I'd really like to be able to use standard libraries rather 
than TLS specific ones, so I'd rather have the following going forward:

"If TLS1.3 or later is negotiated, DHE octet strings representing 
derived shared secrets MUST be encoded according X9.42 7.6.3 and NIST 
SP800-56A C.1 and leading 0 octets to the required length (= CEIL(t/8) 
where t = log2(p) where p is the large prime field order) MUST be 
preserved; otherwise for TLS1.2 and before, those octet strings MUST be 
encoded without leading 0 octets."

Note that I'm not adamant about the above - I expect that plain DH will 
begin to go away due to the relative benefits of ECDH, so negotiating an 
ECDH  shared secret allows for the use of normal libraries.  But 
whatever the choice it needs to be a MUST.

Mike





>
> Manuel.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls