RFC 9849. TLS Encrypted Client Hello

Load Balancers, Split-DNS, and Operational Pain

  • Load balancers can either support ECH (including “split mode” where only SNI is exposed) or force a downgrade; if they can downgrade, attackers with valid certs potentially can too.
  • Consensus: if infrastructure doesn’t support ECH, it shouldn’t advertise it.
  • Real-world complaint: ECH on by default (e.g. via some CDNs) plus split-DNS “intranets” causes flaky failures and confusing browser behavior. Split-DNS itself is described as brittle.

DNS, Downgrade Resistance, and Threat Models

  • Proposed browser-side cache/preload (HSTS-style) for “ECH-using” domains to refuse non‑ECH, making downgrade harder.
  • Debate: some say DNSSEC is crucial for record integrity; others argue for DoH/DoT to trusted resolvers as sufficient for ECH’s ISP/on‑path threat model.
  • Agreement that plaintext DNS greatly weakens ECH’s value.

Censorship, Domain Fronting, and Public Names

  • ECH can mimic domain fronting: outer “public_name” can be a benign or unrelated hostname while inner SNI is the real site.
  • Specs allow servers not to validate public_name, enabling circumvention of SNI-based blocking and “approved” hostnames that route to blocked content.
  • Concerns: this encourages governments to push for IP blocking, CDN cooperation, or legal controls; CDNs could selectively disable ECH by country or hostname.
  • Some note IP-based blocking is collateral-damage heavy, hence less attractive for ISPs.

Parental Controls, Age Verification, and Control Models

  • One side: hiding SNI makes network-level family filtering harder, driving demand for legal/age-verification regimes and device-level control.
  • Others counter: parents can still use client-side filtering/MDM; network-wide dragnet filtering is overused and harms privacy.
  • Broader worry that locked-down devices and mandatory verification will erode user control.

Bot Detection and TLS Fingerprinting

  • ECH hides ClientHello from passive observers, weakening JA3/JA4 fingerprinting for third parties.
  • Clarified that servers/CDNs terminating ECH can still decrypt and fingerprint the inner ClientHello.
  • Some speculate sophisticated bots behind CDNs may blend in more easily; naive bots likely won’t implement ECH soon.

Small Servers, IP Certificates, and Scope

  • Confusion over spec language about “DNS-based reference identities” and rejection of IP-like names; unclear to some whether IP-based certs are effectively excluded.
  • View that ECH mostly benefits multi-tenant/CDN scenarios; single-IP small sites still stand out and can be IP-blocked.
  • Workaround suggested: small servers can advertise a generic public_name unrelated to their actual domains.

ESNI vs ECH and Deployment Reality

  • ESNI was widely trialed (notably via big CDNs), then aggressively blocked (e.g. by national firewalls) and ultimately abandoned.
  • Mozilla-linked rationale: encrypting only SNI was incomplete and had interoperability issues; ECH generalizes this.
  • Several note a long period with no practical replacement, leaving plaintext SNI ubiquitous and undercutting “encrypted DNS” claims.

Implementations, Tooling, and Corporate MITM

  • Some HTTP servers already support ECH and even automate DNS HTTPS/SVCB records and key rotation; others support it more manually.
  • Tools like test suites and visual explainers are referenced.
  • DNS automation is hampered by weak, coarse-grained DNS provider APIs.
  • Corporate MITM systems can block or strip ECH unless browsers enforce a no‑downgrade policy; expectation is many enterprises will simply disable ECH on their networks.

Overall Sentiment

  • Strong enthusiasm for ECH as a privacy and anti-censorship improvement.
  • Equally strong skepticism that technology alone can resist determined governments, corporate controls, and operational inertia.