Encrypted Client Hello (ECH)

• Encrypted Client Hello (ECH) is an IETF TLS 1.3 extension that encrypts handshake metadata, including SNI and ALPN, using HPKE and DNS-discovered keys.
• ECH employs a dual ClientHello design where an inner encrypted message carries sensitive data, enhancing protection against passive traffic analysis.
• ECH leverages DNS SVCB/HTTPS records for configuration, enabling robust, low-overhead encryption of the handshake while ensuring privacy integrity.

Encrypted Client Hello (ECH) is an IETF-proposed extension to TLS 1.3 designed to encrypt privacy-sensitive handshake metadata, particularly the Server Name Indication (SNI) and protocol negotiation parameters such as ALPN, within the ClientHello message. ECH addresses fundamental privacy weaknesses of earlier TLS versions, where SNI and ALPN are transmitted in cleartext, and provides a standardized cryptographic mechanism for their protection. ECH achieves this by encapsulating an “inner” ClientHello with the true SNI within an “outer” ClientHello with innocuous parameters, encrypting the inner payload under a public key obtained via DNS SVCB or HTTPS resource records. This architecture aims to eliminate passive SNI-based traffic analysis, strengthen privacy against network observers, and enable a more robust delivery of privacy guarantees by leveraging broad DNS and TLS infrastructure support (Zirngibl et al., 2023, Khandkar et al., 2022).

1. Protocol Structure and Cryptographic Mechanisms

ECH modifies the TLS 1.3 handshake by splitting the ClientHello into two layers. The outer ClientHello contains non-sensitive parameters such as a “dummy” SNI and minimal ALPN options, and introduces a new encrypted_client_hello extension. This extension’s payload is constructed by encrypting the true, full-featured inner ClientHello using Hybrid Public Key Encryption (HPKE, RFC 9180), with a public key discovered through DNS. The typical cryptographic workflow is as follows:

• The client fetches SVCB or HTTPS DNS records for the target domain, parsing out the ECHConfigList, which encodes one or more ECHConfig structures containing the HPKE public key and cryptographic suite information.
• The client chooses an ephemeral HPKE keypair, computes $$(\mathrm{enc}, \mathrm{shared\_secret}) \gets \mathrm{HPKE.Encap}(PK_\mathrm{ech}, pk_\mathrm{ecdh})$$.
• Using HKDF, the client derives symmetric AEAD keys and nonces for payload encryption:
  • $$\mathrm{secret}_0 = \mathrm{HKDF\text{-}Extract}(0, \mathrm{shared\_secret})$$
  • $$\mathrm{secret}_1 = \mathrm{HKDF\text{-}Expand}(\mathrm{secret}_0, "tls13~ech~key", L_1)$$
  • $$\mathrm{secret}_2 = \mathrm{HKDF\text{-}Expand}(\mathrm{secret}_1, "tls13~ech~nonce", L_2)$$
• The inner ClientHello is encrypted with AEAD under $(\mathrm{secret}_1, \mathrm{secret}_2)$, with additional data derived from the outer ClientHello. The result (enc, ciphertext) is placed as the ECH extension.
• The fronting server, which possesses the private key $sk_\mathrm{ech}$, decapsulates the shared secret, reverses the HKDF chain, and decrypts the inner ClientHello, resuming a standard TLS 1.3 handshake (Khandkar et al., 2022).

This multiplexing of true and decoy ClientHello messages provides indistinguishability of connections within an “anonymity set”, ensuring that only legitimate endpoints recover handshake metadata.

2. ECH Discovery and Configuration via DNS SVCB/HTTPS Records

Implementation of ECH is closely tied to the development of DNS SVCB (type 64) and HTTPS (type 65) resource records as standardized in draft-ietf-dnsop-svcb-https-12. In service mode (priority > 0), these records convey endpoint metadata and SvcParams, a set of extensible key–value pairs encoding service properties.

• ECH configuration is identified by SvcParamKey 0x0008 (“ech”), which holds a base64-encoded ECHConfigList following the TLS ECH draft specification (draft-ietf-tls-esni-16). The presentation syntax is:

  <domain> HTTPS 1 IN SVCB 0 ech="<base64(ECHConfigList)>" alpn="h3,h2"

• The ECHConfigList’s wire format—$$(2\,\mathrm{bytes}\,\mathrm{length}) || \text{ECHConfig}_1 || \text{ECHConfig}_2 \ldots$$—includes cryptographic parameters such as KEM, KDF, AEAD algorithm identifiers, public keys, maximum name length, and extension blocks. The ech SvcParam carries binary data, base64-encoded for DNS transport and parsing consistency.

The client’s TLS stack consumes the DNS-resolved ECHConfig for key derivation and selects the appropriate ECHConfig by matching protocol version and cryptographic capabilities (Zirngibl et al., 2023).

3. Deployment and Empirical Observations

Large-scale Internet scans performed by Johannes Zirngibl et al. in February–March 2023 revealed the status of ECH and related SVCB/HTTPS deployments:

Record Type	Domains with Record	Ech SvcParam Present	Operator (ech records)
SVCB (type 64)	~3.96K	0	-
HTTPS (type 65)	~10.56K	20	Cloudflare (AS13335/209242)

• Only 20 HTTPS-mode records (0.02%) were observed to carry the ech SvcParam, all hosted by Cloudflare’s authoritative nameservers. No other operators advertised ECH in SVCB/HTTPS records as of March 2023 (Zirngibl et al., 2023).
• The IETF DNSOP draft temporarily removed the ech parameter to permit finalization of the SVCB/HTTPS RFC, with the intent to reintroduce it upon ECH’s stabilization as an RFC.
• The vast majority of SVCB/HTTPS records in the wild at the time encoded ALPN and IP address hints, signifying an early deployment phase for advanced privacy features.

This suggests that active ECH configuration delivery through DNS remains nascent but likely to accelerate as service providers update their infrastructure and DNS records.

4. Privacy, Threat Model, and Limitations

ECH was explicitly designed to prevent leakage of handshake metadata to passive observers, such as ISPs or censorship middleboxes, by encrypting the SNI and ALPN in transit. ECH’s security goals include:

• Confidentiality: Hiding all handshake parameters inside the ClientHello from any eavesdropper lacking the server’s ECH private key.
• Indistinguishability: ECH connections within an anonymity set are externally indistinguishable based on handshake characteristics.
• Robustness: Building on TLS 1.3’s downgrade prevention and message authentication mechanisms, including MAC-based integrity checks for decryption failures (Khandkar et al., 2022).

However, ECH’s protections are limited when ancillary “side-channel” connections—e.g., for ads, metrics, control APIs—use legacy TLS (e.g., 1.2). In real deployments, as many major services use TLS 1.3 + ECH only on primary channels, but side-channels remain on TLS 1.2, an observer can correlate side-channel SNI to re-identify the main ECH-protected flow and thus defeat endpoint privacy. The effectiveness of ECH depends on consistency across all service channels (Khandkar et al., 2022).

5. Operational Considerations and Best Practices

Domain operators seeking to deploy ECH should adhere to recommendations to maximize privacy assurance and compatibility:

• Deploy SVCB/HTTPS in service mode (priority > 0) to fully advertise all relevant parameters (ALPN, IP hints, port), and verify advertised metadata against live server configurations.
• Upon ECH standardization, repopulate SvcParam 0x0008 with a correct, base64-encoded ECHConfigList, offering one ECHConfig per active public key to support rotations.
• Use the “mandatory” SvcParam judiciously; enforcing strict ECH parameter requirements causes handshake failures for legacy clients.
• Prefer DNS authorities and hosting services (Cloudflare, NS1, Akamai, etc.) that support SVCB/HTTPS RRs, and monitor application-layer behavior via automated scans to ensure correct alignment of DNS and endpoint properties.

A significant empirical finding: in a cluster of ~23 Cloudflare-hosted domains with HTTP/3 claims, QUIC handshake timeouts were found due to “I’m Under Attack” mode, highlighting the need for end-to-end validation of DNS metadata and service behavior (Zirngibl et al., 2023).

6. Performance, Compatibility, and Outstanding Research Problems

While ECH introduces additional computational steps—particularly HPKE encapsulation and AEAD encryption—these are estimated to add no more than microseconds of processing overhead per handshake on modern CPUs. DNS lookup latency for the SVCB/HTTPS record may be amortized via caching. Overall, this performance cost is minimal relative to the privacy benefit. TLS 1.3’s reduced handshake round-trips (compared to TLS 1.2) further mitigate total connection setup time (Khandkar et al., 2022).

Compatibility barriers persist:

• ECH requires both client and server to implement HPKE and the ECH ClientHello extension.
• Partial deployment, especially when side-channels use TLS 1.2, undermines privacy goals.
• Retrofitting ECH onto legacy TLS (1.2 and earlier) without two-phase handshakes is an open challenge, as is the coordination of unified PKI and key-distribution strategies across fronting infrastructures and CDNs.

Open research directions include:

• Mechanisms for extending ECH protection to legacy protocols.
• Automated key distribution and configuration through DNS, with resolver cooperation.
• Assessing real-world ECH performance under mobile and resource-constrained environments.
• Developing validation and analytics tools that do not themselves reintroduce SNI exposure (Khandkar et al., 2022).

In summary, while ECH and DNS-integrated configuration via SVCB/HTTPS RRs demonstrate a promising path toward end-to-end privacy for Internet services, the realization of uniform handshake metadata confidentiality requires ubiquitous deployment across all application and supporting channels, rigorous configuration validation, and continued innovation in TLS protocol design and deployment methodologies (Zirngibl et al., 2023, Khandkar et al., 2022).