IETF Publishes Encrypted Client Hello as a Standard to Encrypt SNI, With Caveats

An on-path monitor keeps almost everything and loses the one field most egress policy is written against. ECH encrypts the ClientHello under a server public key, and the SNI and the ALPN list travel inside it ^[2]. What stays visible is the server IP address and, unless the client uses encrypted DNS, the lookup that preceded the connection ^[7]. RFC 9849 says so plainly, then explains in the same passage why neither substitutes for the name: many TLS servers host multiple domains on one address, private origins sit behind a common provider such as a reverse proxy, and in those deployments SNI remains the primary explicit signal available to observers ^[8]. The other signal closes on its own schedule. The RFC lists DNS over HTTPS, DNS over TLS or DTLS, and DNS over QUIC as the mechanisms clients use to conceal lookups from network inspection ^[9].

The duty handed to server operators is stated as a limitation. The design provides no forward secrecy for the inner ClientHello, because the server's ECH key is static, and the window of exposure is bound by the key lifetime ^[5]. Servers are RECOMMENDED to rotate keys regularly ^[6]. Put a common interval through that bound: hold one ECH key for 90 days, and an attacker who later obtains the private key recovers the inner ClientHello, SNI included, from every handshake recorded across those 90 days ^[15]. That is a capture-now, decrypt-later exposure applied to the metadata the whole privacy claim rests on.

Which party carries the rotation schedule depends on topology. In shared mode the provider is the origin server for all the domains whose DNS records point to it and terminates the TLS connection ^[12], so the provider's rotation cadence is the tenant's exposure window. In split mode the provider is not the origin server for private domains ^[13], which means the operator answering for the origin and the operator answering for the ECH key need not be the same.

The anonymity set is softer than the mechanism suggests. Co-located servers with consistent externally visible TLS configurations and behavior form the set, and ECH reveals only that a client reached a particular service provider ^[4]. The RFC then concedes that implementation-specific choices, extension ordering or how data is divided into record-layer boundaries, can produce different externally visible behavior even among servers with consistent configurations ^[10]. Fingerprinting survives ECH in both directions: it erodes the client's privacy and leaves defenders with classification rather than domain policy. Scope runs past web browsing, since ECH is defined for TLS 1.3, DTLS 1.3, and newer versions ^[11]. Status is the part worth logging: Standards Track, IETF consensus, IESG approved ^[1], published with a 2026 IETF Trust copyright ^[14]. The one number an operator controls here is the rotation interval, and the RFC asks only that it be regular ^[6].