Hi, Christopher, > On Aug 24, 2022, at 11:19, Christopher Patton <cpat...@cloudflare.com> wrote: > > It's true that reverse proxies, like Cloudflare, terminate TLS for a large > number of names and therefore have the potential to provide a higher degree > of privacy. But I don't think it's fair to say that smaller TLS servers don't > benefit from ECH.
I never say the smaller TLS servers don't benefit from ECH. Every one does. What I said is those standalone small VPS server, working in share mode, will prepare to different domain for inter and outer SNI. As there is no common proxy, all the domains are bounded to on site. This makes protecting the inner domain useless, because the outer one has a one-to-one responding to the inner one. The current design works well for occasion using the intermediary proxy. But we could make it one step further to support the occasion without intermediary proxy. > As others have said: Ultimately, your anonymity set is no larger than the set > of names for which you have TLS certificates. What ECH allows you to do is > make all traffic to any of those names look the same. All you have to do is > issue a certificate for a special name, the "public_name", that you would > only use in case of ECH rejection. This is why we should not depend some common outer SNI. If we want to make all traffic look the same, we may fill the outer SNI field with random ECHConfig ID, which should not be treat as some other domain name. > Yet there are other benefits to ECH that get less attention: Namely, > protection of ALPN and other privacy-sensitive extensions that get > transmitted in the ClientHello. I think of ECH as a way to render more of the > TCP packets unintelligible to an observer. This clearly has a net benefit. > > I don't think this doesn't actually make the traffic to your names any more > anonymous. The fact that the public name might share something in common with > one of your names (e.g., "public-facing-name.example.com > <http://public-facing-name.example.com/>" vs "real-name.example.com > <http://real-name.example.com/>") doesn't really change anything: I can still > look up the IP address for "real-name.example.com > <http://real-name.example.com/>" with a standard DNS query and learn the > exact same information. So we cannot share the same base domain for both outer SNI and inner. If we really want to make ECH works, we have to deploy website behind some common intermediary proxy, which use it's own common share public_name to protect the inner one. If we do not like the common intermediary proxy, it's hard to make ECH work. Because we have to choose a different name for the outer SNI. As there is no other website sharing this name, the name used in outer SNI is almost equal to the inner one, even though the inner one is not exposed. You mentioned anonymous. The real IP do be exposed by DNS lookup, but this issue is beyond the scope of ECH. It should be addressed by something like DoH/DoT/DNSSEC. > ECH was designed for everyone, not just the big players. However, there is > only so much we can do in a client-server protocol like TLS. It might make > sense for you to start thinking beyond a single server. Thanks so much. But the current do require the server choose a "common" public_name to update ECHConfig. It is not a issue for the big player, it will hurt the indie player. > > Something worth exploring: There is an alternative deployment model for ECH > called "Split-Mode", which allows the client-facing server to be > organizationally separated from the backend servers. The client-facing server > would do ECH decryption, then proxy the rest of the handshake to the > appropriate backend. In this setting, the client-facing server would only > terminate TLS for the client-facing server. (See the spec for details.) Actually even "Split-Mode" cannot address my concern. The key problem is the indie server without a common proxy have to choose another "unique" domain as the public_name. As this public_name can not be shared with other indie server, this public_name is just another id of the protected inner name. > In theory, a coalition of "small servers" could set themselves up behind a > client-facing server, whose only job is to handle ECH. This entity need not > be a full-blown reverse proxy. Why not let these "small servers" handle ECH themselves? What about hosting a simple website in a home-hosted server? Thanks.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
