| Internet-Draft | Authenticated ECH Update | September 2025 |
| Sullivan, et al. | Expires 29 March 2026 | [Page] |
Encrypted ClientHello (ECH) requires clients to have the server's ECH configuration before connecting. Currently, when ECH fails, servers can send updated configurations but clients cannot authenticate them without a certificate for the public name, limiting deployment flexibility.¶
This document specifies an authenticated ECH configuration update mechanism. Servers can deliver signed ECH configurations during the TLS handshake, allowing clients to authenticate and immediately use them for retry. The mechanism decouples ECH key distribution from transport, enabling the same signed configuration to work via DNS or TLS delivery.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sullivan-tls-signed-ech-updates/.¶
Source for this draft and an issue tracker can be found at https://github.com/grittygrease/draft-sullivan-tls-signed-ech-updates.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 March 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Deployment of TLS Encrypted ClientHello (ECH) requires that clients obtain the server's current ECH configuration (ECHConfig) before initiating a connection. Current mechanisms distribute ECHConfig data via DNS HTTPS resource records [RFC9460] or HTTPS well-known URIs [I-D.ietf-tls-wkech], allowing servers to publish their ECHConfigList prior to connection establishment.¶
While ECH includes a retry mechanism where servers can send updated ECHConfigList values during the handshake (via HelloRetryRequest or EncryptedExtensions), the base ECH specification instructs clients not to cache these configurations [I-D.ietf-tls-esni]. Instead, servers must authenticate the outer handshake using a certificate for the public name, and clients must obtain updated configurations through out-of-band mechanisms for future connections.¶
This approach limits ECH deployment in two key ways. First, it restricts the usable public names to those for which operators can obtain certificates, reducing the potential anonymity set. Second, it creates delays in key rotation recovery, as clients cannot immediately use updated configurations received during the handshake.¶
This document introduces an Authenticated ECH Config Update mechanism to securely deliver and rotate ECHConfig data in-band, during a TLS handshake. The goal is to allow servers to frequently update ECH keys (for example, to limit the lifetime of keys or respond to compromise). This mechanism does not prescribe or rely on fallback to cleartext; when ECH fails with this mechanism, the connection is terminated and retried with updated configurations rather than exposing the protected name.¶
The mechanism supports three authentication methods through the ech_auth ECHConfig extension:¶
Raw Public Key (RPK) - SPKI pinning established from initial authenticated configuration¶
PKIX - Certificate-based signing with a dedicated Extended Key Usage¶
DNSSEC - Authentication via DNS Security Extensions¶
Each ECHConfig carries at most one signature using the specified method. By authenticating ECH configs independently, the mechanism makes ECH key distribution orthogonal to transport. The same signed ECHConfig artifact can be conveyed via DNS, HTTPS, or the TLS handshake itself. The client will accept it only if the accompanying signature or proof is valid under one of its trust modes.¶
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶
This document assumes familiarity with TLS 1.3 [RFC8446] and the ECH specification [I-D.ietf-tls-esni], referred to here as simply "ECH".¶
The following acronyms are used throughout this document:¶
RPK: Raw Public Key - A public key used directly without a certificate wrapper¶
PKIX: Public Key Infrastructure using X.509 - The standard certificate-based PKI used on the web¶
SPKI: SubjectPublicKeyInfo - The ASN.1 structure containing a public key and its algorithm identifier¶
EKU: Extended Key Usage - An X.509 certificate extension that defines allowed uses¶
ZSK: Zone Signing Key - A DNSSEC key used to sign DNS records within a zone¶
KSK: Key Signing Key - A DNSSEC key used to sign other DNSSEC keys¶
HPKE: Hybrid Public Key Encryption - The encryption scheme used by ECH as defined in [RFC9180]¶
DER: Distinguished Encoding Rules - A binary encoding format for ASN.1 structures¶
OCSP: Online Certificate Status Protocol - A method for checking certificate revocation status¶
CRL: Certificate Revocation List - A list of revoked certificates published by a Certificate Authority¶
CA: Certificate Authority - An entity that issues digital certificates¶
An individual ECH configuration structure as defined in [I-D.ietf-tls-esni], which includes fields such as public_name, public_key (HPKE key), and extensions.¶
A sequence of one or more ECHConfig structures as defined in ECH (a byte string that starts with a 16-bit length and may contain multiple concatenated ECHConfig values).¶
The serialized ECHConfig structure with the ech_auth extension, but with the signature field within ech_auth set to zero-length. This includes all ECHConfig fields and the ech_auth extension's method and trusted_keys fields.¶
An ECHConfig that contains an ech_auth extension with a valid signature in the signature field, allowing clients to verify its authenticity.¶
The value of the public_name field in the ECHConfig, i.e., the authoritative DNS name for updates and validation associated with that configuration. This name is not required to be the ClientHelloOuter SNI, though deployments sometimes choose to align them.¶
The ECHConfigList sent by a server in HelloRetryRequest or EncryptedExtensions when ECH is rejected, as defined in [I-D.ietf-tls-esni].¶
The Server Name Indication value sent in the outer (unencrypted) ClientHello when ECH is used. This is typically the ECHConfig's public_name or another name that preserves client privacy.¶
The reader should recall that in TLS 1.3, the server's EncryptedExtensions message is encrypted and integrity-protected with handshake keys [I-D.ietf-tls-esni]. New extensions defined as part of EncryptedExtensions are not visible to network attackers and cannot be modified by an attacker without detection. Additionally, "certificate verification" refers to the standard X.509 validation process (chain building, signature and expiration checking, name matching, etc.) unless otherwise specified.¶
This specification defines three methods for authenticating ECH configuration updates:¶
The ECHConfig is "pinned" to one or more public keys designated by the server for future updates. The ech_auth extension lists SPKI hashes (trusted_keys) when the RPK method is selected. The server possesses the corresponding private key(s) and uses one to sign updates.¶
Clients that have seen and stored these SPKI fingerprints will accept a new ECHConfigList only if it carries a valid digital signature made with one of the pinned keys. This provides a continuity-of-trust model: the initial SPKI pin is conveyed by the first ECHConfig the client obtains, after which updates can be authenticated by the pinned key without further external validation.¶
No key identifier is used in the update object – clients simply try the candidate public keys from the pin list until one produces a valid signature. The update signature object includes a validity timestamp (not_after), ensuring the configuration has not expired.¶
The ECHConfigList update is signed using a private key for which the server can present a certificate chain. In the update message, the server includes an X.509 certificate (and any intermediates as needed) that chains to a trusted root. The certificate must contain a new Extended Key Usage (EKU) indicating authority to sign ECH configurations.¶
The certificate's subject must cover the ECH public name to prove that the signer is authoritative for that name. A client validates this method by verifying the certificate chain, checking the EKU, confirming the public name in the certificate, and then verifying the signature over the ECHConfigList using the certified public key.¶
This method leverages the existing Web PKI trust model for authentication but uses a dedicated EKU to constrain the certificate's usage to ECH key management.¶
The ECHConfigList is authenticated using the Domain Name System Security Extensions. In this method, the authenticator contains the DNSKEY record with the Zone Signing Key (ZSK) public key for the zone containing the ECHConfig's public_name, and the signature is computed directly by the corresponding ZSK private key.¶
For example, if the public_name is ech.example.net, the authenticator would contain the DNSKEY for the example.net zone (or potentially ech.example.net if it is a delegated zone). The client validates that the DNSKEY is acceptable (e.g., matches a parent DS record or a locally trusted anchor) and verifies the signature using the ZSK public key. The not_after timestamp provides freshness guarantees.¶
This method bootstraps trust in ECH keys from the global DNSSEC hierarchy rather than the Web PKI or a pinned key. It aligns with the existing DNS-based ECH bootstrap mechanism while delivering the proof in-band to the client.¶
By treating ECH configurations as signed objects, this mechanism decouples trust in ECH keys from the TLS handshake's certificate validation of the origin. This enables several important capabilities:¶
A server can use many different public hostnames (even per-client, per-connection unique ones) to maximize the anonymity set or for other operational reasons [I-D.ietf-tls-esni], without having to obtain certificates for each. The RPK method (with SPKI pinning) allows the client to authenticate the server's ability to update ECH keys for those public names via a pinned key, rather than via a CA-issued certificate. This was not possible under the original ECH design, which required a valid certificate for any public name used [I-D.ietf-tls-esni]. Now, the public name authentication can be achieved by proving possession of the pinned key. Section Public Name Authentication (Section 5.2.5) describes how this applies to ECH retry handshakes.¶
The server can proactively push a new ECHConfig to clients shortly before rotating keys, ensuring clients receive it immediately. The update objects include an expiration timestamp (not_after), allowing servers to bound the lifetime of configurations to coordinate key rollover. Clients will reject expired configurations.¶
Because the same authentication methods are defined for in-band and out-of-band, an ECHConfig obtained via DNS can carry the same signature that a TLS in-band update would, allowing clients to verify it even if their DNS channel is not fully trusted. For instance, a client might obtain an ECHConfig via DNS without DNSSEC; if that ECHConfig has an RPK pin, subsequent updates via TLS will be signed by that key, protecting against any earlier undetected DNS tampering. Similarly, a client that does not validate DNSSEC itself could still receive a DNSSEC-signed ECHConfig in the TLS handshake and validate it with the included DNSSEC proof, thus leveraging DNSSEC without requiring a local validating resolver.¶
This design attempts to minimize complexity. It does not use explicit key identifiers or complicated pin rotation metadata. For the RPK method, the pinning model is kept simple (a list of allowed signing keys established from an authenticated initial configuration); pin revocation or addition is handled by simply signing a new update that changes the list (clients trust the new list if it is signed by a currently trusted key). There is no "next update time" field that requires clients to preemptively fetch updates; instead, updates are fetched when provided by the server or when the client next connects. The mechanism is agnostic to the transport by which the client obtained the initial ECHConfig – whether via DNS SVCB/HTTPS RR (as in [I-D.ietf-tls-svcb-ech]), via a well-known HTTPS endpoint [I-D.ietf-tls-wkech], or via some provisioning protocol, the subsequent updates use the same verification process.¶
This section specifies the new extensions and data structures in detail. All multi-byte values are in network byte order (big-endian). The syntax uses the TLS presentation language from [RFC8446].¶
ech_auth)
The ech_auth information is carried as an ECHConfig extension inside the ECHConfig structure and is used both when distributed via DNS and when delivered in TLS (HRR/EE) as part of retry_configs. This single extension conveys policy (which signature methods and pins are supported) and, when present, a signed authenticator that allows clients to verify and install the ECHConfig immediately.¶
The ech_auth extension MUST be the last extension in the ECHConfig's extension list. This ensures that the signature in the extension covers all other extensions in the ECHConfigTBS. Implementations MUST place this extension last when constructing an ECHConfig, and MUST reject ECHConfigs where ech_auth is not the last extension.¶
The ech_auth extension has the following structure:¶
enum {
none(0),
rpk(1),
pkix(2),
dnssec(3),
(255)
} ECHAuthMethod;
// We reuse the TLS HashAlgorithm registry values (though TLS 1.3 itself
// doesn't use this enum directly, the registry still exists)
// For now, implementations MUST use sha256(4). Future specs may allow others.
opaque SPKIHash<32..32>; // SHA-256 hash of DER-encoded SPKI
struct {
ECHAuthMethod method; // Single authentication method
SPKIHash trusted_keys<0..2^16-1>; // RPK-only; SHA-256 hashes per IANA TLS
// HashAlgorithm registry value 4;
// zero-length if method != rpk
// Optional signed authenticator. Present when the sender wishes
// to provide a signed ECHConfig (e.g., in TLS retry_configs, or
// pre-signed in DNS).
struct {
opaque authenticator<1..2^16-1>; // method-specific material (see below)
uint64 not_after; // Unix timestamp; used by RPK and DNSSEC;
// MUST be 0 for PKIX
SignatureScheme algorithm;
opaque signature<1..2^16-1>;
} signature; // Optional; zero-length if not present
} ECHAuth;
¶
The signature is computed over the concatenation:¶
context_label = "TLS-ECH-AUTH-v1" // ASCII, no NUL to_be_signed = context_label || ECHConfigTBS¶
where:¶
ECHConfigTBS (To-Be-Signed) is the serialized ECHConfig structure including
the ech_auth extension, but with the signature field within ech_auth
set to zero-length. This means it includes:¶
The signature is computed over this entire structure, avoiding circular dependency by zeroing out only the signature bytes themselves¶
All multi-byte values use network byte order (big-endian)¶
The serialization follows TLS 1.3 presentation language rules from RFC 8446¶
Including a fixed, scheme-specific context label prevents cross-protocol reuse; covering the to-be-signed ECHConfig and all ech_auth fields (except the signature itself) ensures integrity of parameters and pins. The not_after timestamp provides freshness by bounding the configuration's validity period.¶
Method-specific authenticator:¶
RPK (method=1): the DER-encoded SubjectPublicKeyInfo (SPKI) of the signing key. The client MUST compute the SHA-256 hash of the SPKI, verify that it matches one of the hashes in trusted_keys, check that the current time is before the not_after timestamp, and then verify the signature with this key.¶
PKIX (method=2): a CertificateEntry vector (leaf + optional intermediates) as in TLS 1.3 Certificate; the leaf MUST include the ECH-config-signing EKU and be valid for the ECHConfig public_name. The client validates the chain (which provides its own validity/lifetime bounds) and then verifies the signature with the leaf key.¶
DNSSEC (method=3): the DNSKEY record containing the Zone Signing Key (ZSK) public key material for the zone containing the ECHConfig's public_name. The authenticator SHOULD include the DNSKEY (ZSK) for that zone and MAY include DS records from the parent zone to enable chain validation. The client validates that the DNSKEY corresponds to the correct zone for the public_name, verifies it matches any provided DS records or locally trusted anchors, checks that the current time is before the not_after timestamp, and then verifies the signature using the ZSK public key. This binds the ECHConfig to the domain via the DNSSEC key without requiring an RRSIG over an RRset in this channel.¶
Notes:¶
trusted_keys is only used by RPK; clients MUST ignore it for PKIX and DNSSEC.¶
If method is rpk(1), trusted_keys MUST contain at least one SPKI hash; otherwise it MUST be zero-length.¶
A server publishing multiple ECHConfigs MAY use different methods for each to maximize client compatibility.¶
Context-specific requirements:¶
When carried in TLS (HelloRetryRequest or EncryptedExtensions), an ech_auth extension in each delivered ECHConfig MUST include a signed authenticator in signature, and the client MUST verify the authenticator before installing the ECHConfig.¶
When carried in DNS, an ech_auth extension MAY omit the signature field (unsigned), in which case it conveys only policy (method, trusted_keys). Clients MAY use such information to attempt ECH and to bootstrap trust, but MUST NOT treat it as an authenticated update. If signature is present in DNS, clients SHOULD verify it per the indicated method and MAY treat the ECHConfig as authenticated upon successful verification.¶
The SPKI hash uses SHA-256 (value 4 in the IANA TLS HashAlgorithm registry). The rationale for using a hash rather than the full SPKI is to keep the extension compact in DNS and on the wire, and to avoid exposing full public keys in the clear. SHA-256 is universally supported and provides sufficient security. The drawback is that hash collisions or second-preimage attacks could undermine the pin – this is considered cryptographically infeasible for SHA-256 at the time of writing.¶
Note: While TLS 1.3 moved to SignatureScheme and doesn't directly use the HashAlgorithm enum, we reference the IANA registry value for clarity. Future versions of this specification could add a hash algorithm field using the TLS HashAlgorithm registry if algorithm agility becomes necessary.¶
Client behavior: When a client obtains an ECHConfig that contains an ech_auth extension, it SHOULD store this information along with the configuration. If the client subsequently uses this ECHConfig to initiate a connection, it relies on delivery of signed ECHConfigs in HRR/EE for in-band updates.¶
If an ECHConfig does not include ech_auth, the in-band update mechanism defined here is not used for that configuration.¶
Server behavior: A server that wishes to allow in-band updates MUST include ech_auth in the ECHConfig it publishes via DNS or other means. The server MUST set the method field to the authentication method it will use for this configuration. The server MUST ensure that it actually has the capability to perform the indicated method:¶
If method is rpk(1), the server needs a signing key whose SPKI hash is in trusted_keys. (It may have multiple keys for rotation; all keys that might sign an update before the next ECHConfig change should be listed. Pins can be added or removed by generating a new ECHConfig with an updated list and distributing it out-of-band or via an update.)¶
If method is pkix(2), the server must have a valid certificate (and chain) for the public name with the ECH configuration signing EKU (Section IANA Considerations (Section 9) defines the EKU) available at runtime to use for signing. The certificate's public key algorithm dictates what signature algorithms are possible.¶
If method is dnssec(3), the server must have access to DNSSEC signing infrastructure for the zone (or a way to obtain fresh DNS records). In practice, the server might simply fetch its own DNS record and include the proof if it knows the zone is signed and it has the ability to get the RRSIG and DNSKEY; or an operator might provision a service to provide the needed DNSSEC blobs. The specifics are out of scope of this document, but the server should only use this method if it can produce a timely proof. (Including stale or incorrect DNSSEC data in an update will cause clients to ignore the update.)¶
This specification reuses the ECH retry_configs delivery mechanism: the server sends an ECHConfigList where each ECHConfig contains the ech_auth extension with a signed authenticator. The server MAY include multiple ECHConfigs with different authentication methods (e.g., one with PKIX and one with RPK) to maximize client compatibility. There is no separate TLS extension for negotiation.¶
When a server receives a ClientHello with the encrypted_client_hello extension, it processes ECH per [I-D.ietf-tls-esni]. If the server has an updated ECHConfigList to distribute:¶
ECH Accepted: If the server successfully decrypts the ClientHelloInner, it completes the handshake using the inner ClientHello. The server MAY include authenticated ECHConfigs in EncryptedExtensions if an update is available.¶
ECH Rejected: If the server cannot decrypt the ClientHelloInner, it SHOULD proceed with the outer handshake and include authenticated ECHConfigs in EncryptedExtensions. This allows the client to immediately retry with the correct configuration.¶
The server prepares authenticated updates by:¶
Using the authentication method specified in the ECHConfig's ech_auth.method¶
Creating the appropriate authenticator (RPK signature, PKIX certificate chain, or DNSSEC proof)¶
Including the authenticator in the ECHConfig's ech_auth.signature field¶
Sending the ECHConfigList via the existing retry_configs mechanism¶
When a client retrieves an ECHConfig (e.g., from DNS), it examines the ech_auth extension and records:¶
The authentication method (RPK, PKIX, or DNSSEC)¶
Any trusted_keys for RPK validation¶
Any pre-distributed signature for immediate validation¶
During the TLS handshake, upon receiving an ECHConfigList in HRR or EE:¶
Validation: The client validates the authenticator according to its method:¶
RPK: Computes the SHA-256 hash of the provided SPKI, verifies it matches one in trusted_keys, then verifies the signature¶
PKIX: Validates the certificate chain, verifies the leaf certificate covers the ECHConfig's public_name, checks for the ECH signing EKU, then verifies the signature¶
DNSSEC: Validates that the DNSKEY corresponds to the public_name's zone, validates the DNSSEC chain, then verifies the signature¶
Validity Checking: The client checks temporal validity:¶
Installation and Retry (see Appendix A for state diagram):¶
If validation succeeds and this was an ECH rejection (outer handshake):¶
The client treats the retry_configs as authentic per [I-D.ietf-tls-esni], Section 6.1.6¶
The client MUST terminate the connection and retry with the new ECHConfig¶
The retry does not consider the server's TLS certificate for the public name¶
If validation succeeds and this was an ECH acceptance:¶
The client caches the new ECHConfig for future connections¶
If validation fails:¶
Note: Regardless of validation outcome in an ECH rejection, the client will terminate the current connection. The difference is whether it retries with the new configs (validation success) or treats it as a certificate validation failure (validation failure). Implementers should refer to the state diagram in Appendix A for the complete retry logic flow.¶
Clients that do not implement this specification continue to process retry_configs as defined in [I-D.ietf-tls-esni], ignoring the authentication extensions. Servers that do not implement this specification send unauthenticated retry_configs as usual.¶
When a server rejects ECH and continues with the outer handshake, it normally must present a certificate valid for the public name. This specification allows the use of pinned keys as an alternative to CA-issued certificates.¶
If the ECHConfig's ech_auth.method is RPK and trusted_keys contains SPKI hashes:¶
The server MAY present a certificate whose public key's SPKI hash matches one in trusted_keys¶
The client computes the SPKI hash of the leaf certificate and checks for a match¶
If matched and the handshake completes (proving possession via CertificateVerify), the client MAY accept the server's identity for the public name¶
The client MUST still treat the connection as not authenticated for the inner origin¶
The connection is used solely to deliver the authenticated ECHConfig for retry¶
Consider api.example.com as a service protected by ECH with public name ech.example.net. The operator publishes an ECHConfig via DNS HTTPS RR with the ech_auth extension containing:¶
This section analyzes security properties by threat model.¶
This mechanism preserves ECH's protection against passive observation. ECHConfig updates are delivered within encrypted TLS messages (HelloRetryRequest or EncryptedExtensions), preventing passive observers from learning about configuration changes. The mechanism ensures that even during retry scenarios, the client's intended server name is never exposed in cleartext.¶
The security of this mechanism fundamentally depends on the authenticity of the initial ECHConfig. If an attacker can inject a malicious initial configuration, they may be able to pin their own keys in the trusted_keys field, enabling persistent interception.¶
When ECHConfigs are obtained via DNS without DNSSEC validation, an on-path attacker could provide a fake ECHConfig with the attacker's key in trusted_keys. While the attacker cannot decrypt ECH-protected connections, they could cause ECH to fail and then present their own certificate during fallback, potentially tricking the client into accepting and caching a compromised configuration. Clients SHOULD prefer authenticated bootstrap mechanisms when available.¶
DNSSEC-validated DNS records provide strong initial trust, as an attacker cannot forge configurations without compromising the DNSSEC infrastructure. Similarly, ECHConfigs obtained via HTTPS from a well-known URI benefit from Web PKI authentication. Pre-configured ECHConfigs in applications derive their trust from the application's distribution channel.¶
Signed ECHConfigs delivered via HelloRetryRequest or EncryptedExtensions are protected by TLS 1.3's handshake encryption and integrity mechanisms. The Finished message ensures that any modification by an attacker would be detected.¶
A man-in-the-middle attacker without the server's handshake keys cannot modify the EncryptedExtensions message containing the ECHConfig update. The TLS 1.3 handshake itself provides replay protection through its use of fresh random values and the Finished message authentication.¶
Clients MUST correctly implement signature verification for each authentication method. For RPK, servers and clients SHOULD use cryptographically strong signature schemes from the TLS 1.3 SignatureScheme registry, such as Ed25519, ECDSA, or RSA-PSS. Weak schemes like RSA PKCS#1 v1.5 SHOULD NOT be used.¶
The inclusion of not_after timestamps (for RPK and DNSSEC) or certificate validity periods (for PKIX) ensures configuration freshness. These temporal bounds prevent clients from accepting stale configurations that might use compromised keys or outdated parameters. Clients MUST verify these temporal constraints and reject expired configurations. Note that these mechanisms depend on reasonably synchronized clocks (within 5 minutes of actual time is RECOMMENDED).¶
Note that signed ECHConfigs themselves are replayable - an attacker could capture and resend a valid signed configuration. However, this is not a security concern as the configuration is public data intended for distribution. The freshness guarantees ensure that old configurations eventually expire, limiting the window during which outdated keys remain acceptable.¶
Servers MUST protect their ECH update signing keys. If an RPK signing key is compromised, the server SHOULD remove its hash from trusted_keys in subsequent updates, signing the transition with a different trusted key. Servers SHOULD consider including multiple keys in trusted_keys to facilitate key rotation and recovery from compromise.¶
For PKIX-based updates, normal certificate lifecycle management applies. Servers SHOULD obtain new certificates before existing ones expire and MAY include the new certificate's key hash in trusted_keys to enable smooth transitions.¶
For PKIX authentication, this specification leverages existing CA infrastructure including revocation mechanisms. A compromised ECH signing certificate could be used to sign malicious updates, but this risk is mitigated by the certificate's constraints (specific EKU and name binding) and standard revocation mechanisms (OCSP/CRL). Clients SHOULD apply the same revocation checks to ECH signing certificates as they do for TLS server certificates.¶
When ECHConfig update verification fails, clients MUST NOT compromise the security or privacy guarantees of ECH. If ECH was accepted but the update verification failed, the connection proceeds normally without caching the new configuration. This represents a safe failure mode where connectivity is maintained but key rotation is delayed.¶
If ECH was rejected and the update verification also fails, the client lacks a valid configuration for retry. In this case, the client SHOULD NOT proceed with the connection using the outer SNI for application data, as this would violate ECH's privacy goals. The client MAY attempt to obtain a valid configuration through other means (such as DNS with DNSSEC) or treat the connection as failed.¶
Servers MAY include multiple ECHConfigs with different authentication methods to maximize the probability of successful verification. Clients SHOULD process these in order and use the first configuration that successfully verifies.¶
In distributed deployments, only servers with access to the appropriate signing keys can generate valid ECHConfig updates. This prevents unauthorized intermediaries (such as CDN nodes) from injecting malicious configurations. If a server sends an update that cannot be verified, the client simply ignores it and continues with its existing configuration. While this could potentially lead to the use of outdated configurations, it prevents compromise of the ECH mechanism itself.¶
DNSSEC authentication relies on the security of the DNS hierarchy. Implementations MUST properly validate the entire DNSSEC chain from the ECHConfig's zone to a trusted anchor. If the validation chain cannot be completed, the update MUST be rejected.¶
Algorithm agility is provided through the TLS SignatureScheme registry for RPK, standard PKIX certificate algorithms, and DNSSEC's algorithm negotiation mechanisms. Implementations SHOULD support commonly deployed algorithms and MUST be able to handle algorithm transitions.¶
Signature verification introduces computational costs, particularly for DNSSEC validation. However, these operations occur only during ECH configuration updates, not on every connection. The additional data in EncryptedExtensions (certificates or DNSSEC records) may increase message sizes, potentially causing fragmentation in some scenarios. Implementations SHOULD be aware of message size limits, particularly in QUIC deployments.¶
Attackers cannot force servers to send signed ECHConfigs without establishing TLS connections. Standard TLS denial-of-service mitigations (rate limiting, stateless cookies) apply equally to this mechanism.¶
This mechanism preserves and potentially enhances ECH's privacy properties. By enabling the use of diverse public names through RPK authentication, servers can increase the anonymity set beyond what is possible with certificate-based authentication alone.¶
The ECHConfig updates themselves are delivered within encrypted TLS messages (HelloRetryRequest or EncryptedExtensions), preventing passive observers from learning about configuration changes. The mechanism ensures that even during retry scenarios, the client's intended server name is never exposed in cleartext.¶
A potential privacy consideration is that failed ECH attempts followed by successful retries create a distinctive connection pattern. However, this pattern only reveals that ECH was used with a particular public name, not the intended destination behind that name.¶
The use of DNSSEC authentication may trigger additional DNS queries for validation, but these queries reveal no more information than the initial ECH configuration fetch. Clients using validating resolvers avoid additional on-wire queries entirely.¶
This specification introduces no new tracking mechanisms or identifiers beyond those already present in TLS and DNS.¶
IANA is requested to add the following entry to the "ECH Configuration Extension Type Values" registry:¶
IANA is requested to allocate a new OID in the "SMI Security for PKIX Extended Key Purpose" registry:¶
OID: 1.3.6.1.5.5.7.3.TBD2¶
Description: id-kp-echConfigSigning¶
Purpose: ECH Configuration Signing¶
Reference: This document¶
Certificates containing this EKU are authorized to sign ECH configuration updates for the names in the certificate's SAN field.¶
IANA is requested to establish a new registry called "ECH Authentication Methods" with the following initial values:¶
| Value | Method | Description | Reference |
|---|---|---|---|
| 0 | Reserved | Not used | This document |
| 1 | RPK | Raw Public Key (pinned key) | This document |
| 2 | PKIX | X.509 Certificate | This document |
| 3 | DNSSEC | DNSSEC Authentication | This document |
| 4 | Reserved | Reserved for future use | This document |
| 5-255 | Unassigned | Available for future assignment | - |
New values are assigned via IETF Review.¶
Operators SHOULD support at least one widely implemented method. PKIX provides broad compatibility with existing PKI infrastructure. DNSSEC leverages DNS security. RPK offers operational independence but requires careful pin lifecycle management.¶
When sending authenticated ECHConfigs in HelloRetryRequest, servers should be mindful of message size to avoid fragmentation or exceeding anti-amplification limits. RPK signatures are typically more compact than PKIX certificate chains or DNSSEC proofs.¶
Publish updates well in advance of key retirement. Include appropriate validity periods for each method. Consider overlapping validity windows to allow graceful client migration.¶
For RPK deployments:¶
If sending updates in both HRR and EncryptedExtensions, ensure consistency to avoid client confusion. When possible, send updates in only one location per handshake.¶