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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
