This is wrong. The ClientHello message is not encrypted in TLS 1.3, so, the client has to announce any extensions in plaintext. Thus the Great Firewall blocks connections which say they want to do encrypted SNI.
TLS 1.3 works fine in China, but if you use TLS 1.3 with the earlier proposed encrypted SNI draft it is blocked. The Great Firewall can't tell which name you actually wanted, but it can tell you're encrypting the SNI and block that.
With the currently proposed Encrypted Client Hello with a GREASE-style dummy ECH on all connections (so the "real" Hello is sometimes in an encrypted block and sometimes that encrypted block was just noise), China would still be able to choose to block all ECH-enabled connections since their presence is detectable. This would break everything, but China can choose to do that. What happens next is a policy question.
If you want to sneak past nation state snooping you need something else, that's not what TLS is for. The TOR project does not directly offer this either, but they can help you find out how to connect to TOR in a sneaky way if that's necessary for you.
If they block ESNI, it's likely all ESNI requests would be blocked, because they can't tell if its a blocked site or not. (it'd be possible they only apply ESNI-blocking against IPs associated with blocked sites, but that seems unlikely)
Agreed and since TLS 1.3 is still work in progress the chances are slim that you will find a blocked website that meets your criteria. Great article, very accessible. Thanks!
That RFC is marked as "PROPOSED STANDARD" which is why I saw it as work in progress but you're right, that seems to be the end of the road for RFC's (for example RFC 6455 December 2011 (websockets) is also marked as proposed standard but this is what everyone has implemented)
The IETF deliberately has no power whatsoever. Whether an IETF standards track proposal in fact becomes a standard everybody implements is entirely up to the implementers. This is in contrast to many standards development organisations (and indeed whether the IETF is even an organisation is open to doubt) which are government functions and can produce de jure standards you're obliged to implement or in the worst case force may be exercised against you by those with a monopoly on its use.
As a result IETF standards are only proposed and that is as you say "the end of the road".
> As a result IETF standards are only proposed and that is as you say "the end of the road".
Not really, after PROPOSED STANDARD there's INTERNET STANDARD, the STD series. For instance, IPv4/ICMPv4 (RFC 791/792) is STD 5, UDP (RFC 768) is STD 6, TCP (RFC 793) is STD 7, DNS is STD 13, and so on (STD 1 has the full list).
However, an IETF standard only reaches that level after it's been in use for a while; according to RFC 2026 (BCP 9), "A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community."
IMO the only way to do that would be to either (i) block the IP (high collateral blocking) or (ii) block TLS 1.3 itself (GFC does this).
A major blocker in answering this is finding a potentially blocked website that also supports TLS 1.3