Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt

[Christian Huitema <[e-mail]>]

On 6/2/2020 11:44 AM, Salz, Rich wrote:

> Trial description scares me.  Perhaps that's not a rationale fear -- one of the points of CDN support is a large anonymity set -- but I worry about the DoS possibilities. Especially if QUIC picks this up (now trivial to fake "client IP") and if some large mobile manufacturers move to use this as the default as I've heard they are considering.

I am looking at a very specific use case: mobile servers. Suppose that
you use TLS to connect from a mobile client to a mobile server using an
untrusted network, such as a Wi-Fi network in an airport. Neither the
client not the server want to reveal their identity when using the
network. When using TLS, they will use ECH to hide finger-printable data
such as SNI, ALPN, or QUIC initial parameters. But the record digest in
the ECH blob is also an unique identifier of the server. Sending that in
the clear will disclose the identity of the server if the ECHConfigis
public. Even if server and authorized clients keep the structure
private, the unique record digest still allows for tracking the server's
movements. In practice, server privacy pretty much requires trial
decryption -- any hint at server identity or key identity can be used to
track the server.

Of course, this is a specialized use case. This kind of behavior is not
required at all if the client-facing server is public, such as in the
CDN case. Servers will have to explicitly allow the feature, and yes
this is a trade-off between privacy and exposure to DDOS. The point of
section 10.3 is precisely to outline that trade-off.

-- Christian Huitema