Re: [TLS] predictability of inputs in ESNI

[Eric Rescorla <[e-mail]>]

On Fri, Nov 1, 2019 at 2:28 PM Rob Sayre <[e-mail]> 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.


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.


It seems like these values should all be allowed to be opaque, and I am not
> sure why NSS is prepending zeros to its AAD (although I asked in the github
> issue).
>

As I said, it's not.

-Ekr