Re: [TLS] ESNI and padding

[Ben Schwartz <[e-mail]>]

On Wed, Jun 19, 2019 at 6:34 PM Stephen Farrell <[e-mail]>
wrote:
...

> What I'd suggest instead:
>
> - delete the padded_length field from ESNIKeys, so nobody needs
>   to configure anything for padding
> - clients MUST pad to a multiple of N octets where N is in the
>   spec (I'd suggest N=32, but any number that's longer than
>   nearly all real TLS server names would be good)
> - we RECOMMEND clients randomly add an additional N octets of
>   padding with probability X%, perhaps with X=10 (btw - am I
>   right in thinking that if X% is greater than the percentage
>   of real names that are longer than N, then we're good?)
> - we STRONGLY RECOMMEND that servers choose names shorter than
>   N octets for hidden web sites


As you are clearly aware, this approach provides essentially no privacy
protection in the case where a user is repeatedly connecting to a very long
domain on a server whose other domains are reasonably short.

Rather than make a privacy-vs-efficiency tradeoff in the spec, the current
text leaves this option to the implementer.  For example, within the
current protocol (albeit bending the recommendations slightly), an
implementer could easily bucket names by length, and offer separate
ESNIKeys for each length bucket.  I think this is preferable; only the
server operator knows their own privacy and efficiency goals.  In my view,
setting N=32 for the first bucket would reproduce most of the benefits of
this proposal without altering the current protocol.