Re: [TLS] predictability of inputs in ESNI

[Rob Sayre <[e-mail]>]

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

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

I don't think the current spec is a good idea. It mandates padding with
zeros, and lets servers dictate a length. I think the client should dictate
the length, at least.



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

Hey now, you're the one that wrote "misreading" initially. If "additional
data" is not what's used as "additional authenticated data" in the end,
fine.



>
> Maybe something to fix?
>>
>
> This is not on topic for this mailing list.
>

I think it is, since no one could read any ESNI draft and get the DNS
record's checksum right, at the very least. So, there are some issues where
it can be hard to tell if the spec is wrong, my implementation is wrong, or
another implementation is wrong.

thanks,
Rob