Re: [TLS] ESNI robustness and GREASE PRs - client tracking concerns?

[David Fifield <[e-mail]>]

On Mon, Dec 17, 2018 at 05:17:37PM -0600, David Benjamin wrote:
> We[*] wrote up some proposed changes for draft-ietf-tls-esni that we'd like the
> group's thoughts on. The goal is to make ESNI more robust and eliminate a bunch
> of deployment risks. The PRs are linked below:
> 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/124

Under this design, the ESNIKeys structure in DNS gains a public_name
field, which is the name against which the client is supposed to verify
handshake, in the event that the server cannot descript the ESNI and
returns a esni_retry_request response. The esni_retry_request structure
contains alternative ESNIKeys for the client to use in its next
connection attempt.

I started to think: what if the alternative ESNIKeys were a standard TLS
extension on their own? The server could tell the client, on each
connection, what ESNIKeys to use for its next connection. The client
would not have to consult the DNS for ESNIKeys for any connection but
the first, as long as the connections were frequent enough that the
ESNIKeys didn't expire.

But then I reflected: this would enable precise tracking of clients. The
server could give different keys to every client--effectively a
cookie--and thereby link past and future connections.

I think similar tracking concerns apply to the public_name design. A TLS
server could publish one global ESNIKeys in DNS. This one, because it is
used by all clients, would not help tracking (within the anonymity set
of ESNI-using clients). But the server could, whenever it receives an
encrypted_server_name extension encrypted with the global ESNIKeys,
pretend that it is unable to decrypt and reply with esni_retry_request
and a unique "cookie" ESNIKeys, which that client, and no other, would
use for future connections.

A unique ESNIKeys per client may not be feasible, if the server has to
do trial decryption using the private component of all the ESNIKeys
cookies it has handed out. There may be a more clever way to do it than
trial description. But anyway a server could define some budget, say,
256 trial decryptions per connection, and instead of a unique ESNIKeys
per client, choose one randomly from a pool of 256. Clients would then
be partitioned into 256 buckets for the lifetime of the ESNIKeys--which
other tracking technique could of course refine further.

I suppose something like this is possible even in the current draft as
written, if the TLS server and DNS server collude. The DNS server could
give different ESNIKeys to different clients, enabling not only the
linking of a DNS request and TLS connection, but the linking of several
TLS connections together.