Oppressive regimes just drop any connection lacking a plain text SNI. The browser will either retry without ECH, or the user will retry with a browser that does not support ECH.
I think people in the Western world don't exactly understand how internet censorship works. They don't give a shit about blocking large legitimate sites or breaking connectivity for large swaths of users if it helps them avoid losing power.
Uhuh.
> Oppressive regimes just drop any connection lacking a plain text SNI.
All of the connections will have a plain text SNI. Many of them will have ECH. In some of them, at least at first the ECH will just be GREASE, in others it's real. For the server it's apparent which is which, for a snoop it's impossible to know. Indeed that's sort of the point of GREASE.
> They don't give a shit about blocking large legitimate sites or breaking connectivity for large swaths of users if it helps them avoid losing power.
We heard basically the same thing for TLS 1.3. But of course we actually rolled out TLS 1.3 with no major problems, even the anti-downgrade provision which was the part I was most sceptical about delivering. Google's Chrome GREASEs a bunch of TLS 1.3 already.
Encrypted Client Hello is the in-progress work to have even the client's initial contact to an HTTPS server be encrypted. https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
Why would ECH be fine when Domain Fronting isn't? The problem with Domain Fronting is that we get surprised too late with the actual request. We get what appears to be a legitimate request for this-thing.example, so we do all the work to respond to a this-thing.example request and then... swerve, sorry I changed my mind, my request is actually about hidden-service.example.
With ECH we (but not an adversary snooping the connection) know immediately that the request is for hidden-service.example and so we don't waste our time setting up for the wrong work.