Summary

  • ECH encrypts a private ClientHelloInner inside a public ClientHelloOuter, protecting SNI and other sensitive handshake fields from ordinary on-path inspection.
  • The privacy result is operational, not merely cryptographic: DNS has to deliver a current configuration, the client-facing server has to manage keys and retries, and many origins have to look sufficiently alike to form a useful anonymity set.
  • ECH does not hide DNS queries, IP addresses or every traffic-analysis signal. The decisive operator test is whether the whole chain works without a silent downgrade, not whether an ech field exists in a zone.

One connection, two introductions

The packet reaches a public TLS front door carrying a plausible outer identity. Inside it sits a second hello with the name the client actually wants. A client-facing server can open that inner message and route it to the correct backend; an observer on the access path sees the public envelope, not the private server name.

That mechanism repairs a disclosure left by the order of the TLS handshake. The server_name extension was designed so a client could select one named service among several sharing infrastructure. It lives in ClientHello, the first TLS message. TLS 1.3 encrypts most of what follows, but the name needed for early routing remained visible. RFC 6066 defines the original extension; RFC 8446 defines the TLS 1.3 handshake that still begins with ClientHello.

RFC 9849, published on the IETF Standards Track in March 2026, changes that introduction. The client builds a ClientHelloInner containing the sensitive values, including the true SNI and potentially the ALPN list. It encrypts the inner message with HPKE under a public key from an ECHConfig. It then sends a ClientHelloOuter with public values and an encrypted_client_hello extension carrying the sealed inner message.

The outer hello is not camouflage painted over an ordinary packet. It is an authenticated part of the construction. The front end either accepts ECH and processes or forwards the inner hello, or rejects ECH and continues with the outer one. The client determines which path occurred. If ECH was offered but rejected, that connection is not used for application data; rejection creates a controlled path to obtain a current configuration and try again.

The front door becomes part of the security design

RFC 9849 supports two topologies. In shared mode, the client-facing server and the TLS terminator are the same system. In split mode, the public front end opens the inner hello and relays it to a separate backend, which terminates the connection. The front end can therefore learn enough to route without becoming the endpoint for the protected application stream.

This split is technically precise and institutionally important. The DNS publisher authorizes a public name and distributes the keying configuration. The client chooses whether to offer ECH. The front end holds the corresponding private key and decides which backend receives the inner hello. The backend confirms acceptance as part of the TLS transcript. Privacy is produced by their agreement; none of them can manufacture the whole result alone.

An ECHConfig carries more than a public key. It also includes a configuration identifier, supported cryptographic parameters, a public name and an input used for padding. The client-facing server is expected to keep current configurations and older ones that may remain in client caches. A rapid key change can reduce the window of exposure if a key is compromised, but it can also create stale-client retries. Maintaining many keys raises trial-decryption work. The RFC provides the mechanism; it does not declare one rotation interval correct for every deployment.

DNS carries the instruction before TLS can protect it

The client needs the configuration before it sends the first TLS message. RFC 9848 therefore defines the ech service parameter for the DNS service-binding system in RFC 9460. SVCB and HTTPS records can tell the client which alternative endpoint to use and which connection parameters apply. The ECH parameter carries the configuration for that endpoint.

This is the protocol’s most consequential handoff. A privacy feature inside TLS now depends on information delivered outside TLS. If an intermediary prevents the client from learning the SVCB or HTTPS answer, the client may never know that ECH was configured. RFC 9848 warns that an RRSet mixing ECH-capable and non-ECH endpoints permits a blocking downgrade: an attacker can make the protected alternatives unreachable and leave the unprotected one.

Secure resolver transport helps against a local observer, and validation can protect data integrity when the client applies it strictly. Neither makes the recursive resolver ignorant of the query. ECH protects the private name in the TLS hello; it does not conceal that name from the resolver that answers the DNS question. Nor does it erase a destination IP address. Those limits are part of the design record, not defects to be filled with optimistic marketing.

Privacy needs a crowd that behaves like a crowd

ECH’s stated handshake-privacy goal is an anonymity set. If many server names share a client-facing server, use a common configuration and present sufficiently consistent public behavior, an observer should not be able to identify which member received a connection merely from the hello. If the provider allocates a different configuration to every name, the set can collapse to one.

The same can happen without changing the key. One backend may expose a distinctive public cipher preference. Another may order extensions differently, divide records differently or return a uniquely shaped retry cookie. A client-facing system may rotate one cluster ahead of another. Encryption can hide the inner value while the deployment identifies it by silhouette.

That makes “ECH enabled” an incomplete status. The useful questions are how many names actually share the configuration, whether their outer handshakes remain comparable, how retry cookies and key identifiers behave, and whether timing across a split front end links the client side to a particular backend. These are measurements of a system, not a check box in a control panel.

Failure must look different from consent to fall back

ECH has to survive the Internet it is trying to change. GREASE ECH lets clients send a realistic-looking extension even when they lack a usable configuration. Its purpose is to expose implementations that mishandle an unfamiliar extension and to stop genuine ECH from becoming the only unusual shape on the wire.

Greasing also complicates diagnosis. A front end that cannot decrypt an offered value cannot assume the zone is broken; it may be looking at GREASE. RFC 9849 instead gives the server current retry configurations and defines an ech_required alert that operators can count. A second incompatible retry is a stronger sign of inconsistent deployment than a single decryption failure.

The distinction matters. A tolerant outer handshake is necessary for interoperability, but the client must not convert failed privacy into an apparently successful protected session. ECH rejection is deliberately visible to the client and unusable for application data. The ordinary connection can still proceed in cases where ECH was never configured or never offered, but that is a different state from “ECH was promised and silently lost.”

What the RFCs prove—and what they leave open

The fixed record proves the message formats, actor roles, retry logic, DNS binding and stated threat model. It proves that RFC 9849 is Standards Track. It does not prove that a given browser offers ECH, that a resolver delivered the parameter, that an access network left it alone, or that a provider created a large anonymity set.

It also does not prove anonymity in the ordinary sense of the word. A network observer may still see the provider’s address. A resolver may still see the query. Traffic correlation, prior connections and public behavior may still narrow the destination. ECH protects a defined handshake disclosure inside a wider observation environment.

Sources