Re: [TLS] predictability of inputs in ESNI

[Rob Sayre <[e-mail]>]

On Fri, Nov 1, 2019 at 3:09 PM Eric Rescorla <[e-mail]> wrote:

>
>
> 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.
>

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