Summary

  • RFC 9849 separates an encrypted ClientHelloInner from a public outer envelope and from the client-facing server’s public_name; those are privacy and configuration facts, not a declaration of the private backend’s identity.
  • ECH acceptance, a DNS-delivered configuration, a certificate on the wire and a working application each answer different questions. None can inherit the proof supplied by another layer.

The instinct to read an encrypted handshake as a more trustworthy identity signal is understandable. A visible name has disappeared; a public key has been selected; the peer has returned a response that says it understood the format. That sequence looks deliberate. It is deliberate, but it is not a complete account of who served whom.

RFC 9849 gives the mechanism a narrow purpose. A client constructs a private ClientHelloInner, places non-sensitive values in ClientHelloOuter, encrypts the inner form under an ECH public key and sends the outer form. The outer and inner are cryptographically bound so that an attacker cannot freely alter the outer while retaining the same inner. That is an important integrity property of the envelope. It is not evidence that the public-facing address, DNS record, private backend, commercial operator and application principal are one entity.

The word public_name is where many overclaims begin. In an ECH configuration it is the DNS name of the client-facing server — the party trusted to update the configuration and assist recovery from stale configuration. A client normally puts that name in outer SNI. It is expressly a public routing and recovery surface. It is not the concealed origin’s name, a certificate result for every private name, or an ownership statement for an anonymity set.

RFC 9849 makes the topology visible precisely enough to prevent that confusion. In shared mode, client-facing and backend roles can be combined. In split mode, the client-facing server relays to a backend that terminates TLS; the provider need not see the plaintext connection. The split design assumes an authenticated channel to the backend and assumes an attacker cannot correlate the two legs. The specification leaves the exact anti-correlation mechanism out of scope. An observer who sees ECH has not thereby audited either assumption.

Acceptance is also a bounded event. A server may accept ECH and use ClientHelloInner, or reject it and use ClientHelloOuter. Rejection produces no connection usable for application data by the ECH client and can provide a retry path with fresh configuration. Acceptance means the handshake selected the inner route under the protocol’s conditions. It is not the later evidence that a certificate chain was accepted under the client’s trust store, that the application recognized the intended origin, that a user was authorized, or that a request succeeded.

TLS itself preserves those separations. RFC 8446 negotiates parameters, may authenticate peers and establishes traffic keys; it is application-protocol independent. Certificate validation relies on independently distributed trust anchors and detailed validation remains partly outside TLS. A certificate and CertificateVerify can be necessary evidence for a particular authentication design, but they do not prove an ECH deployment's DNS integrity, backend governance or application effect. Conversely, ECH is not a substitute for certificate validation.

RFC 9460 adds another useful boundary. SVCB and HTTPS records can give clients instructions, including public keys and alternate endpoints. The RFC explicitly allows alternative endpoints with different capabilities or operators. A DNS observation can justify asking what configuration a client received. It cannot identify the server that ultimately terminated the private connection, prove the resolver’s integrity or establish that every connection used that record.

This is the practical reading of a minimum specification. The shared protocol provides a portable envelope; local participants decide how to publish it, cache it, validate identities, arrange relay-to-backend custody and authorize applications. Running code can show that those actors completed compatible steps at a particular time. It cannot turn the first encrypted flight into a universal identity receipt.

An incident or deployment review should retain the evidence in columns: ECHConfig source and TTL; resolver and cache path; outer and inner handshake state; acceptance/rejection; expected identity and local certificate-validation outcome; client-facing/back-end trust-channel records; selected endpoint; and application result. A blank in one column should remain blank rather than being filled with a more dramatic packet trace.

Sources