Thanks for the comment! The PR did try to touch on this, but perhaps I did a poor job of wording it: https://github.com/tlswg/draft-ietf-tls-esni/pull/124/files#diff-4d2dc9df336bea8e17f5eb4ed7cb1107R511
The intent is you use the retry keys just for that one retry. Subsequent connection attempts revert to the DNS-provided ones. Then the server could correlate the initial connection and the immediately-following retry, but that initial "connection" was discarded. It's like saying the server can correlate the client's ClientHello and Finished. An earlier iteration even placed the retry on the same connection, which makes the analog clearer. (Doing it in the same connection is rather a mess, so we bounce to a new one.) Another possibility might be to require clients treat these like session identifiers w.r.t. scoping and lifetime, reducing to something existing, but that is more complex, so the simple solution seemed a better starting point. Does that address the concern, or have I missed something? David On Mon, Dec 17, 2018 at 10:45 PM David Fifield <da...@bamsoftware.com> wrote: > 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. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
