Subject: Re: [TLS] Should we require compressed points

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 01 Nov 2014 18:21:22 +0100

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

Manuel.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Nov 2014 10:35:54 -0700

Can you send a Pull Request with what you are looking for here?

Thanks,
-Ekr

On Fri, Oct 31, 2014 at 11:31 AM, Ilari Liusvaara <
[email-masked]> wrote:

> -Ilari

---

From: Michael StJohns <[email-masked]>
Date: Sat, 01 Nov 2014 14:24:24 -0400

Below - inline.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 01 Nov 2014 21:59:20 +0100

> it as a byte string for input into a key derivation function (the TLS 
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.

---

From: Michael StJohns <[email-masked]>
Date: Sat, 01 Nov 2014 18:03:58 -0400

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

> 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