Re: [TLS] ESNI and padding

[Stephen Farrell <[e-mail]>]

On 20/06/2019 14:16, Ben Schwartz wrote:
> However, as a matter of overhead, your test suggests that RFC 8467 roughly
> doubles the size of each query packet.  That's similar to the proportional
> effect of maximum ESNI padding on a typical ClientHello.  Proportionally, I
> expect RFC 8467 adds more padding to the whole DNS transaction than current
> ESNI adds to the whole TLS handshake.  It might even be true in absolute
> terms, on average.  In the context of a full TLS connection, the
> proportional impact of ESNI is even smaller.

Sure, compared to the full TLS exchange padded_length==260
isn't so much.

> 
>> Again though, I think considering DNS query padding argues
>> that this ought be a client-driven thing and not tied to the
>> ESNIKeys.
> 
> One important difference between these cases is that DNS is essentially an
> "open world", where no one knows the whole space of possibilities, whereas
> a specific server is a "closed world", a finite set of domains (known only
> to the server operator).  That puts the server operator in the unique
> position to make correct padding decisions, and also makes the adversary's
> job much easier if the padding is incorrect.

True, but not always true, in the sense that the server
s/w may not have such an easy job knowing the sizes in
all deployments (for Certificate padding) and similarly
keeping that in whack with the padded_length in the DNS
can be tricky as it can involve multiple entities. (But
I'm starting to repeat myself:-)

> 
>> If no padding was used for DoT or DoH, the ESNI
>> length may already have leaked regardless of the padded_length.
>> That said, I'm not sure what, if any, padding is being done
>> by DoT or DoH clients. (I use stubby and it does some padding
>> sometimes but I'm not sure what.)
>>
> In general, I think we should assume that no SNI information is leaking
> through other channels when making design choices for ESNI.  Otherwise, we
> risk ESNI itself becoming the limiting factor in the future as those other
> leaks are fixed.

Sure. I fully agree with that, but nonetheless if DNS
query padding and ESNI padding are both being done as
we'd like, then having both be controlled on the same
side of the TLS connections seems more robust to me.

Cheers,
S.