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.