Hi, Dennis, > On Oct 6, 2023, at 19:31, Dennis Jackson > <ietf=40dennis-jackson...@dmarc.ietf.org> wrote: > On 06/10/2023 10:45, Raghu Saxena wrote: >> Specifically, I am concerned about the "public name" field in the ECHConfig. >> For services such as cloudflare, they can "hide" everything behind a single >> domain (e.g. "cloudflare-ech.com"). However, for someone who just owns a >> single domain (e.g. "hub.com"), what would the "suggested value" be? >> >> Section 6.1.7 implies it should NOT be an IPv4 address. If I do not wish to >> leak the real domain, is it "acceptable" to use something like >> "fakedomain.com"? > The server needs to be able to answer a TLS connection for the ECH public > name or you risk an outage if the ECHConfigs get out of sync as then clients > will get a TLS error page if they can't get through to the public name.
I think the public name is needed, but should not be required! We do risk an outage if the ECHConfigs get out of sync. However, it's how the DNS works. Image we setup a wrong A/AAAA record accidentally, we have no choice but to wait this wrong record expires. It's an outage. For ECH, we need to rotate it periodically, so we don't want to the risk of outage. So ECH requires a real public name, which will be used to transfer the latest ECHConfigs when the client get the outdated conf. For platform like Cloudflare, this feature is critical, because they cannot afford the outage of their customers. But for indie web services/sites, it is not so big problem. Because this mechanism will introduce another huge risk! If ECH requires the public name, then every web site need to use to domain name, one for their brand, and the other for public name, both of which should be valid domain. If the use service from providers like Cloudfalre, they can only need one domain name, but still depends the providers public domain name. The public name is seldom used, but observed by the sensor, which makes it easy to block web site using ECH. So we should consider to make the public optional. If the server do not afford any outage causing by ECHConfig sync, they could setup the public name, and use it to sync the latest config, but they should take the risk of being blocked by the censor. If the server do not afford the risk of being blocked, they could just ignore the public name, and public the ECHConfigs using some pseudo-domain, which can be changed freely, but they should take the risk of outage caused by ECHConfigs out-sync. All in all, please make the public domain name optional in the specification. >> >> If the public_name leaks domain in anyway, I think it would be quite >> unfortunate, at least for bypassing DPI-blocks. From what I understand, the >> purpose of public_name is only if the server doesn't support ECH, but if a >> client retrieved an ECHConfig, why shouldn't the client just skip this >> field? I fear it will become a situation like the initial SNI extension - >> even when websites do not need it, browsers' TLS stacks send it anyway, >> causing leakage. >> >> For instance, in India, a popular website, let's call it "hub.com", is >> blocked via SNI. However, the website itself does NOT rely on SNI, It is >> possible to open a pure TLS connection to it via IP, it serves the TLS cert >> for "hub.com" so the handshake can be completed, and then the website will >> load as normal. I verified this by manually using "openssl s_client", >> WITHOUT SNI. But since Firefox/Chrome will always send SNI, the ISPs can >> block it. > > If the server can answer with the correct certificate without SNI, then it > must be the only site hosted at that IP. This means that the ISP can also > just block the IP without any collateral damage. The same thing is true if > ECH connections didn't expose an SNI at all, they'd stick out and could be > blocked for that reason. We can change IP freely, but it is hard, if not impossible, to change domain name. For indie web server, they can buy two domains, one for their brand, and the other for ECH. If the public name has been blocked, they have to buy another one. But if we allow the usage of pseudo-domain, this problem will disappear. > > I would describe ECH primarily as a technology for improving privacy. > Unfortunately, I don't think it's any kind of silver bullet for censorship > resistance. Improving privacy imply censorship resistance. Although censorship resistance is not the goal, we should not deliberately design *required* features which will make the censorship easy. BTW, if we public ECHConfig using a domain name which we do not own SSL certificate, it does not make thing worse. Because when the client needs to re-sync the ECHConfig, the SSL handshake will fail due to the invalid certificate. However, I prefer to make this behavior clear in the RFC. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
