Nick Sullivan@grittygrease
Every lock needs a key. The hard part is not always designing the lock. Sometimes it is getting the key to the person who needs it.
That is the problem I address in the third post of my CDT series on Encrypted Client Hello. ECH is designed to close one of the last major metadata leaks in HTTPS: the exposure of the website name in the TLS ClientHello. But before a browser can encrypt that part of the handshake, it needs the server’s ECH configuration. In today’s deployment model, that usually comes from DNS.
This creates a very practical bootstrapping problem. DNS is not just a lookup mechanism here. It is the path by which the client learns the information needed to make ECH work. In normal network conditions, that is a clean design. In censorship environments, it is an obvious pressure point.
China is the clearest example. The Great Firewall has a long history of DNS injection and poisoning. Encrypted DNS changes the mechanics, but not the basic incentive. DNS-over-TLS can be blocked outright. DNS-over-HTTPS is harder to block cleanly because it runs over HTTPS, but it can be identified and degraded. The result is not always a crisp failure. It can be something more frustrating and more effective: temporary blacklisting, flakiness, and enough unreliability that users give up.
That matters for ECH because a censor does not need to break the TLS handshake if it can prevent the client from obtaining the ECH configuration in the first place. The failure occurs before the privacy property is enabled.
This is one of the recurring lessons of Internet security. Cryptography is necessary, but it is not the whole system. Discovery, distribution, caching, fallback behavior, and downgrade resistance are part of the security architecture too. Censors often attack those seams because they are cheaper to exploit than the cryptography itself.
The natural question is whether ECH configurations need to be tied so tightly to DNS. DNS currently handles both distribution and authentication. If those functions can be separated, ECH configs could be distributed via other paths while still being cryptographically authenticated. Well-known endpoints, cached configurations, CDN distribution, key transparency mechanisms, and signed ECH configurations are all part of that design space.
ECH is still one of the most important privacy improvements happening in the web platform. But if we want it to work for the people most likely to face network interference, we have to treat configuration delivery as a first-class part of the problem.
The next step is not just deploying ECH. It is making sure ECH can actually start.
cdt.org/insights/distr…
