Post

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 look at in the third post in my CDT series on Encrypted Client Hello. cdt.org/insights/dis...

ECH is designed to close one of the last major metadata leaks in HTTPS: the website name exposed in the TLS ClientHello. But before a browser can encrypt that part of the handshake, it needs the server’s ECH configuration.

Today, that configuration usually comes from DNS. 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 to control the discovery path.

DNS-over-TLS can be blocked outright. DNS-over-HTTPS is harder to block cleanly because it runs over HTTPS, but it can still be identified and degraded. The result is often not a crisp failure. It is flakiness, temporary blocking, and users giving up.

This is a recurring lesson 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.

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 through other paths and still verified.

Well-known endpoints, cached configurations, CDN distribution, key transparency mechanisms, and signed ECH configurations are all part of that design space. This is not a reason to give up on ECH. It is a reason to make ECH more deployable under pressure.