On Fri, Nov 1, 2019 at 3:27 PM Rob Sayre <say...@gmail.com> wrote: > 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? >
Absent some reason not to, this seems like a reasonable design choice. At minimum, it has the advantage that it's easy to detect some classes of implementation errors. 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? > No. I'm saying that the function argument is called |additionalData| but that's not what's used as AAD in the actual cryptographic function. I wouldn't exactly call that misreading. > This seems like a definitional question that is not worth debating. Maybe something to fix? > This is not on topic for this mailing list. This internal interface is quite old and when we wrote the TLS 1.3 code, we considered changing it and decided it wasn't worth it. If you'd like to submit a CL to NSS which improves this, we'll take a look. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
