Hi David, Great. Thanks for following up on this!
I think I now understand why the implementation of DH seemed buggy in one of the crypto libraries that I was reviewing. Regards, Maarten Op 19 mei 2016 21:22 schreef "David Benjamin" <david...@chromium.org>: > If the WG agrees with this change, I've put together a PR here: > https://github.com/tlswg/tls13-spec/pull/462 > > On Tue, May 17, 2016 at 4:14 PM David Benjamin <david...@chromium.org> > wrote: > >> 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 <hous...@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.bode...@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 >>> >>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
