While we're at it: what prevents, say, a cartel of the world's transit providers to cut China off from the Internet until they don't censor it any more? And why haven't they done so? After all, there are only two outcomes: the Chinese government goes fully intranet, but their economy tanks as a result or the Chinese government backs down, with their economy (and civil rights) profiting. Same goes for Russia or Iran.
It's about time that Western companies take a stance when it comes to civil rights. So much technical and social progress is kept back out of the fear the censorship creates, it must be profitable by now to simply force their hands.
Oh, and while we're at it, why are there still companies doing business with our very own guilty parties in espionage terms? Why do they have bank accounts? Why is anyone renting them office spaces, selling computers and whatever else?
The same companies from USA, Germany, Israel and I believe also Italy do not only supply our own governments (which is bad enough in itself) but also dictators who use these tools to repress their own citizens.
So we're making snooping by ISPs more difficult by using a technique that only works well precisely because so much of the modern internet is centralized behind a few hosting service providers.
Encrypted SNI will be at best a lateral move. Much time will be spent (especially by small-time providers and open source stack authors) trying to keep up with the privacy enhancements offered by the big hosting providers just so they can lay claim to the dubious benefit of enhanced privacy.
More likely, these enhancements will be leveraged to centralize hosting even further. The more complex the protocol stack, the more costly it is to avoid using centralized providers.
And much like with browser fingerprinting, whatever marginal benefits exist will be quickly erased once the existing tracking systems build and maintain databases that map IPs to likely sites. Nobody has even tried to demonstrate that this isn't feasible with aggregators--everybody just assumes it's not practical. And that ignores the reality that countries like China can force companies like Google, Apple, and others to host services domestically, making encrypted SNI of little value from day 1.
I absolutely oppose encrypted SNI because it adds significant complexity for little benefit over the long term. Worse, it will likely hasten centralization. A proper solution would be to fix TLS so SNI always happens over an encrypted channel. But as with TLS 1.3 0-RTT, in reality performance is allowed to trump security. That's the calculus of the very same organizations pushing encrypted SNI.[1]
As somebody who has written DNS, HTTP, MySQL, RTP, RTSP, SMTP, and even HTML parsing stacks from the ground-up, we need to focus on making these things simpler. We need to shift our efforts to writing implementations using specialized languages and techniques for software verification so we can write provably safe and correct implementations[2] rather than chasing feature after feature.
[1] In fairness, these organizations are diverse and if the encrypted SNI folks had their way they may also have come up with a better solution. But that doesn't justify encrypted SNI on its merits.
[2] Rust doesn't even begin to solve this. As ugly as buffer overflows are, when it comes to tracking and data exfiltration they're hardly the biggest culprit. And in any event Rust only solves a subset of overflows. Techniques for building circular-reference data structures in Rust (i.e. using indirection through array indexes--basically pointers to a specialized heap) can and _will_ result in similar issues. At the end up the day, for core infrastructure software no general purpose language suffices. For core infrastructure, there's no avoiding doing things the hard way. Core infrastructure software needs to be developed in the same way SQLite is developed, but that will never happen as long as these standards are moving targets that rely on many moving pieces.
How do you propose to do that? This is not a rhetorical question, if you have an idea on how to make it work, go ahead and propose it to the TLS working group. Keep in mind the issues raised at https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03.
7.1. Why is cleartext DNS OK?
In comparison to [I-D.kazuho-protected-sni], wherein DNS
Resource Records are signed via a server private key,
ESNIKeys have no authenticity or provenance information.
This means that any attacker which can inject DNS responses
or poison DNS caches, which is a common scenario in client
access networks, can supply clients with fake ESNIKeys (so
that the client encrypts SNI to them) or strip the ESNIKeys
from the response. However, in the face of an attacker that
controls DNS, no SNI encryption scheme can work because the
attacker can replace the IP address, thus blocking client
connections, or substituting a unique IP address which is
1:1 with the DNS name that was looked up (modulo DNS
wildcards). Thus, allowing the ESNIKeys in the clear does
not make the situation significantly worse.
(https://tools.ietf.org/html/draft-rescorla-tls-esni-00#section-7.1)
DANE never gained traction because wedding TLS to DNS was considered intolerable from the perspective of both client-side and server-side implementation complexity. But apparently not intolerable enough when it benefits centralized hosting providers. Indeed, it's not intolerable client-side complexity because unlike DANE they're not going to bother trying to implement DNSSEC browser-side; instead they're going to farm that out to a hosted service. (Remember Mozilla+Cloudflare mentioned several weeks ago? Nominally free, but as with all business strategies, if you're not the customer you're the product.) And server-side they'll just bill directly for the cost of the complexity, because now there's even more incentive for the big hosting providers to maintain your DNS for you. (Of course, in reality they'll just siphon business away from the traditional DNS registrars, so the customer sees "value-add" while the entire internet continues to centralize even further.)
What TLS ESNI is, is the realization that people killed DANE because they let perfect be the enemy of better. (Where better is to just assume DNSSEC is already solved outside the browser, or more generally depending on DNS solving the hard part, and solving it in a way that minimizes browser implementation complexity.) But apparently nobody is yet willing to cop to that reality.
TLDR: The proper solution is a simpler one that achieves the same degree of privacy--fix TLS to setup an ephemerally-keyed channel first, then perform domain authentication by exchanging data within the channel. If you don't have to worry about preventing an active MITM attacker from snooping domain names, then you don't need a committee to draft up a spec. The requirements RFC says we do have to worry about an active MITM attacker, but the actual TLS ESNI doesn't actually prevent that. It just redefines the scope to "solve" the problem away.
[1] You could argue that it's easier to MITM TLS than it is to MITM DNS, but nobody is going to buy that argument.
Too many big players are behind it for ISPs to be able to get away with that strategy. If a battle started then Google, Cloudflare, and others could simply start hosting DNSoHTTPS directly alongside all of their major services. To most customers 90% of "the internet" is the services from these providers.
"So can censors. State actors..." There is never going to be surefire way to subvert a large government that controls the infrastructure you are trying to sneak through. Even if there was the government would still be in control of data at any companies that operate inside the country. It's not "outsmart China or bust".
Rather than dismissing the solution as useless because it doesn't provide the ultimate privacy maybe it's more worthwhile to look at what it can do and how other changes to TLS and other protocols can continue to make things harder to snoop.