Security1 distinct publisher3 min readPublished
RFC 9849 encrypts the ClientHello, so the domain field that SNI allowlists and passive TLS logs depend on stops appearing on the wire. In return, operators inherit a key rotation duty; the spec sets no fixed interval.
The Watch · Security desk

Compiled by The WatchSomething wrong?How this is made
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].
Ranked by verification strength, evidence, and original report placement.
RFC 9849, "TLS Encrypted Client Hello", is an Internet Standards Track document, a product of the IETF representing the consensus of the IETF community, and approved for publication by the IESG.
RFC 9849 specifies a TLS extension called Encrypted Client Hello (ECH) that allows clients to encrypt their ClientHello to the TLS server under a server public key, protecting the SNI and other potentially sensitive fields such as the ALPN list.
Although TLS 1.3 encrypts most of the handshake, including the server certificate, the RFC states the plaintext SNI extension in ClientHello messages, which leaks the target domain, is perhaps the most sensitive information left unencrypted in TLS 1.3.
Co-located servers with consistent externally visible TLS configurations and behavior form an anonymity set; use of ECH reveals that a client is connecting to a particular service provider but does not reveal which server from the set terminates the connection.
The design does not provide forward secrecy for the inner ClientHello because the server's ECH key is static; the window of exposure is bound by the key lifetime.
RFC 9849 states it is RECOMMENDED that servers rotate keys regularly, without naming an interval in the cited text.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 30, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Hybrid Post-Quantum TLS: Same Protocol, a 1,216-Byte Key Share1 distinct publisher
security
Encrypted DNS in Russia is now a reachability problem, not a privacy win3 distinct publishers
build
JDK 27's nine JEPs are frozen, and two of them change your defaults1 distinct publisher
build
Signed receipts on MCP tool calls: 20 lines buys you evidence, not trust1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
The normative text, quoted rather than summarized
This rests entirely on RFC 9849 as published by the RFC Editor — the document itself, not somebody's read of it. The load it carries is quoted: the plaintext SNI as the most sensitive field left in TLS 1.3, the admission that the ECH key is static, the RECOMMENDED rotation with no cadence attached. What holds it short of full marks is the nature of the source: a standards document is definitive about its own design and silent about the world it lands in.
Approval is not uptake
IESG sign-off tells you the specification is finished, not that anything speaks it. Nothing in this reporting says which browsers enable ECH by default, which providers publish ECH configurations, or how many domains carry the HTTPS records that advertise them — and an RFC has no reason to say. We are not going to manufacture a number from a document that counts nothing.
The caveats come from the issuer
Usually the limits arrive from a critic; here they are in the announcement. The same pages that introduce ClientHello encryption say there is no forward secrecy, that exposure lasts as long as the key does, and that ECH by itself does not hide the server while DNS queries and IP addresses still point at it. Measured against the shorthand a reader carries away — "SNI is encrypted now" — this reporting is if anything more restrained than the facts require, which is why it reads as slightly understated rather than merely aligned.
A publisher with nothing to upsell
The RFC Editor is distributing consensus text, not shipping a product; there is no pricing, no vendor, and no launch claim to defend. The residual pull is structural rather than commercial: working-group output naturally describes the deployment it envisages, and the parties who lose an SNI-shaped signal — the ones running allowlists, per-domain logging, and network policy — are not the ones holding the pen.
Firm on the spec, blank on the aftermath
One source, but the right one, and its normative wording leaves little room to argue about what ECH does. The softer part is the reading we supplied: the ninety-day illustration is arithmetic on the IETF's own no-forward-secrecy admission, not a cadence the document endorses — it deliberately names none. Beyond the text, we know nothing, and that ceiling is what keeps this in the seventies.