Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
Extracted elements (18)
Base64 encoding is used for the presentation format of the "ech" SvcParam to simplify integration with TLS server software. The prohibition on escape sequences enables simpler parsing.
The SVCB-optional fallback behavior is explicitly prohibited when all endpoints advertise ECH, because allowing fallback to a non-ECH connection would negate the privacy benefits that ECH provides.
HTTP clients implementing both HTTP Alt-Svc and HTTPS records can use them together, provided connection attempts are "consistent" with both parameter sets. A connection using ECH is considered consistent with an Alt-Svc field value that does not mention ECH, as no ECH parameter is defined for Alt-Svc.
As a latency optimization, clients MAY prefetch DNS records that will only be used if the "ech" parameter is not present (i.e., only in SVCB-optional mode), prior to retrieving the SVCB records.
Clients that support ECH MUST NOT issue any TLS ClientHello until after SVCB resolution has completed, because the "ech" SvcParam alters the contents of the TLS ClientHello if present.
ECH-capable, SVCB-optional clients MUST switch to SVCB-reliant connection establishment if SVCB resolution succeeded and all alternative endpoints have an "ech" SvcParam. SVCB fallback to a direct connection would negate ECH's privacy benefits.
If all HTTPS records for an alt-authority contain "ech" SvcParams, the client MUST adopt SVCB-reliant behavior for that RRSet, which precludes the use of certain connections that Alt-Svc would otherwise allow.
Origins that publish an "ech" SvcParam in their HTTPS record SHOULD also publish an HTTPS record with the "ech" SvcParam for every alt-authority offered in Alt-Svc field values. Otherwise, clients might reveal the server name in an unencrypted ClientHello to an alt-authority.
Servers that publish an "ech" parameter SHOULD support a protocol version compatible with ECH (TLS 1.3, DTLS 1.3, or QUIC version 1). If not, each connection attempt will require a retry, delaying connections and wasting resources.
When publishing a record containing an "ech" parameter, the publisher MUST ensure that all IP addresses of TargetName correspond to servers that have access to the corresponding private key or are authoritative for the public name. Otherwise, connections will fail entirely.
The "ech" SvcParamKey conveys the ECH configuration of an alternative endpoint. It is applicable to all schemes that use TLS-based protocols, including DTLS and QUIC version 1, unless otherwise specified.
When ECH is in use, the TLS ClientHello is divided into an unencrypted "outer" and an encrypted "inner" ClientHello. SVCB parameters such as ALPN identifiers and SNI apply only to the inner ClientHello, which is used for establishing a connection to the service.
IANA has updated the entry for "ech" (number 5) in the "DNS SVCB Service Parameter Keys (SvcParamKeys)" registry, assigning it the meaning "TLS Encrypted ClientHello Config" with IETF as change controller and RFC 9848 as the reference.
A SVCB RRSet containing some RRs with "ech" and some without is vulnerable to a downgrade attack: a network intermediary can block connections to ECH-capable endpoints, forcing fallback to non-ECH endpoints. This mixed configuration is NOT RECOMMENDED; when unavoidable, ECH-capable RRs SHOULD have lower SvcPriority values.
An attacker who can prevent SVCB resolution can deny clients any associated security benefits, including ECH. Network intermediaries can prevent resolution even when DNSSEC and secure transport are used; clients SHOULD abandon the connection when such a downgrade attack is detected.
ECH protects the SNI within TLS, but the same hostname information is present in DNS queries used to resolve the server. This specification does not conceal the server name from the DNS resolver; attackers on the path between client and resolver, or who can link clients to resolver-to-authority queries, can learn the destination server name.
ECH's SNI protection is limited to an anonymity set of all ECH-enabled server domains sharing a given ECH configuration. An attacker enumerating this set can guess the encrypted SNI with probability at least 1/K, and may achieve greater accuracy via traffic analysis, popularity weighting, and similar techniques.
In wire format, the "ech" SvcParam value is an ECHConfigList (including the redundant length prefix). In presentation format, the value is the ECHConfigList encoded in Base64 (RFC 4648). This SvcParam MUST NOT contain escape sequences.