Re: [TLS] Diffie-Hellman: value of Z - the shared secret

Reviving this thread, I also think it would also be a good idea if 1.3 did
not stripping zeros from Z. Having this logic is rather dubious w.r.t.
treating secret data in constant-time. And as Bill Cox mentioned elsewhere
in this thread, this odd behavior has caused interoperability issues in the
past.

I don't think we have to be worried about inconsistency with 1.2 as, by the
time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE is
already a very different beast from TLS 1.2 DHE. At this point, the only
thing they meaningfully share is they happen to use the same code points.

David

On Thu, Apr 7, 2016 at 10:37 AM Russ Housley <housley@vigilsec.com> wrote:

> I would prefer to always use the full, known-length byte string for Z.  In
> my experience, it is better to know the lengths of byte strings instead of
> stripping leading zeroes.  The difference in the speed of the HKDF
> computation by omitting the leading zeros is not significant.  Alignment
> with NIST SP 800-56A is nice, but it is not the reason for my preference.
>
> Russ
>
>
> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes <maarten.bodewes@gmail.com>
> wrote:
>
> > Hi all,
> >
> > I see that the leading zero is stripped off of the value of Z (the
> shared secret) before it is used as input to HKDF. This seems to be
> compatible with TLS 1.2. Then again, it is not compatible with e.g.
> NISP800-56A which uses the value of Z with the same size of the prime in
> octets. Furthermore, it is also different with regards to handling the
> coordinate X as used in ECDH.
> >
> > Was this a conscious decision to keep compatibility with TLS? Has the
> use of the value of Z including zero octets been considered?
> >
> > Regards,
> > Maarten
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets