On Fri, Nov 1, 2019 at 3:09 PM Eric Rescorla <e...@rtfm.com> wrote: > > > On Fri, Nov 1, 2019 at 2:28 PM Rob Sayre <say...@gmail.com> wrote: > >> Hi, >> >> I am not sure how important these findings are, but I've noticed three >> instances of unnecessarily predictable inputs in ESNI: >> >> 1) Trailing padding after domain names are zeros. >> > 2) The checksum calculation seems to start with predictable version bytes >> in draft -04, and in shipping implementations >> > > I'm not aware of any cryptographic reason why these would be a problem. > It's reasonably common practice to have partially fixed inputs to the TLS > cryptographic functions (see, for instance, HMAC labels and the trailing > padding 0s in the record protection). In general, if this sort of thing > turns out to be a problem for some algorithm, we consider it to be a > problem with the algorithm. >
I see. But is there any reason to make these inputs predictably zero by spec? > > > 3) In practice, NSS inserts 8 bytes of zeros at the beginning of its AAD >> input (<https://github.com/tlswg/draft-ietf-tls-esni/issues/190>) >> > > I believe you're misreading the code. For historical reasons, the internal > NSS TLS AEAD API prefixes the AAD argument with the sequence number. When > we repurposed this code for ESNI, we just passed in a 0 sequence number. > That value is stripped off and is not part of the AAD computation. > I see, so you're saying that NSS adds 8 bytes to the AAD input, and then strips it off at some later point? I wouldn't exactly call that misreading. Maybe something to fix? thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
