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...

cdt.orgDistributing the Keys for Private Access to the WebBreaking the DNS Dependencych-22" class="toc-anchor">ECH’s Catch-22thing-strange-in-the-dns" href="#something-strange-in-the-dns" class="toc-anchor">Something Strange in the DNS use it. That’s the fun...

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.

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 happens before the privacy property turns on.

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.

ECH is 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, configuration delivery has to be treated as a first-class part of the problem.

No replies yet.