| Internet-Draft | Implicit ECH Config | February 2025 |
| Sullivan | Expires 30 August 2025 | [Page] |
This document updates the TLS Encrypted ClientHello (ECH) specification
[ECH-DRAFT] to support an implicit mode in
ECH signaled by a new implicit_ech extension in ECHConfigContents.
Clients that detect this extension override certain base ECH rules:¶
They MAY choose any outer SNI instead of public_name.¶
They MAY choose any value for the config_id without an
application profile or being externally configured.¶
They MAY use another value than ECHConfig.contents.public_name in the "server_name" extension (rather than they SHOULD use it)¶
Client-facing servers that include implicit_ech in the ECHConfig MUST accommodate
flexible config_id usage as defined in Section 10.4. of [ECH-DRAFT].
This approach enables the removal of stable identifiers (fixed config ID and
known public_name) that on-path adversaries can use to fingerprint a
connection.¶
This improves upon the "Do Not Stick Out" design goal
from Section 10.10.4 of [ECH-DRAFT] by allowing clients to choose
unpredictable identifiers on the wire in the scenario where the set of
ECH configurations the client encounters is small and therefore
popular public_name or config_id values "stick out".¶
Note that this increases CPU usage in multi-key deployments because
client-facing servers must perform uniform trial decryption to handle arbitrary
config_id values.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Transport Layer Security mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/.¶
Source for this draft and an issue tracker can be found at https://github.com/grittygrease/draft-sullivan-tls-implicit-ech.¶
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 30 August 2025.¶
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.¶
The Encrypted ClientHello (ECH) protocol [ECH-DRAFT] is designed to hide sensitive TLS handshake parameters, including the real SNI, from passive observers. In the base ECH model, the client sets its outer SNI to the public_name and config_id from the ECHConfig. Both of these can become stable fingerprints that on-path adversaries recognize.¶
In implicit mode, the client MAY:¶
Select any outer SNI (rather than the public_name).¶
Select any config_id instead of taking it from the ECH configuration (without an application profile or extenal configuration agreement).¶
Client-facing servers that publish or accept implicit ECH configurations
must adjust key selection (e.g., single-key usage,
uniform trial decryption), removing reliance on stable config IDs or
well-known public_name values. This design helps conceal ECH usage
from on-path adversaries, though deployments may see increased CPU usage.¶
This proposal also addresses a timing side-channel in GREASE vs. real ECH, by requiring client-facing servers supporting implicit ECH always to perform trial decryption as defined in Section 10.4. of [ECH-DRAFT] — ensuring consistent behavior regardless of ECH key validity.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
A new ECHConfig extension type is defined to indicate implicit mode. If this extension is present in ECHConfigContents.extensions, clients and client-facing servers follow the rules described here, overriding certain parts of the base ECH specification.¶
The extension has the following format:¶
enum { implicit_ech(TBD), (65535) } ECHConfigExtensionType;
struct { // No data; presence indicates "implicit" usage } ImplicitECHConfig;
¶
The extension_data is zero-length. The presence of this extension in the ECHConfig signals to the client that the client-facing server is configured for implicit ECH and follows the requirements of this document.¶
When the implicit_ech extension is found in ECHConfigContents.extensions, the following rules in [ECH-DRAFT] are overridden:¶
The requirements for choosing the config_id in the ClientHello (Section 6.1.1. of [ECH-DRAFT]). In implicit mode, the client MAY choose any value for the config_id.¶
Outer SNI usage (Section 6.1 of [ECH-DRAFT] says the client SHOULD set the value of the "server_name" extension to ECHConfig.contents.public_name. In implicit mode, the client MAY choose any valid domain name for the outer SNI.¶
Note that the validation rules in Section 6.1.7 of [ECH-DRAFT] still apply and the client is still expected to validate that the certificate is valid for ECHConfig.contents.public_name (not the "server_name" chosen by the client) when the client-facing server rejects ECH.¶
If the client sees the implicit_ech extension in an ECHConfig:¶
It MAY select any valid DNS name for the "server_name" extension, ignoring public_name.¶
It MAY produce a random or arbitrary config_id, rather than using ECHConfigContents.key_config.config_id¶
Other aspects of the base ECH spec remain unchanged. In particular, the client still picks a cipher suite from key_config.cipher_suites, produces a valid HPKE ephemeral key, and encrypts ClientHelloInner into the payload field.¶
If the client-facing server issues an ECH retry hint (for example, in EncryptedExtensions), the client MUST still confirm that the server certificate is valid for the public_name from the ECHConfig used to establish the connection. Note that this may be a different name than the one sent in the outer SNI.¶
As described in Section 6.1.1 of [ECH-DRAFT], in the event of HRR, the config_id MUST be left unchanged for the second ClientHelloOuter.¶
A client-facing server that supports Implicit ECH on an IP address shared
with non-ECH services or GREASE ECH clients MUST attempt to decrypt the
encrypted ClientHello for every incoming connection that presents an ECH
extension. This requirement applies even if the config_id is not
recognized, so GREASE and valid ECH connections appear indistinguishable
from a timing perspective.¶
If the decryption attempt succeeds, the server proceeds with the handshake using the inner ClientHello and the appropriate certificate chain for the actual (inner) SNI. If the decryption attempt fails, there are two possibilities:¶
The client was connecting to a domain that does not support ECH¶
The client used a different ECHConfig than those currently supported on the client-facing server.¶
After trial decryption, if the server recognizes the outer SNI, has a
certificate that covers it, and supports non-ECH connections for this
domain, then the server proceeds with a standard TLS handshake based
on the indicated SNI. Otherwise, the server MAY send an ECH retry hint
in the ServerHello, accompanied by:¶
A newly issued or updated ECHConfig, possibly including the implicit flag again.¶
A server certificate that is valid for the public_name in one of the supported ECH configurations, ensuring the client can verify it.¶
If multiple ECH keys are in rotation, perform uniform trial decryption
to avoid timing signals that reveal actual vs. unknown config_id usage. The
server SHOULD attempt ECH decryption first to avoid revealing whether
the config_id was recognized.¶
In this model, trial decryption on every connection ensures that GREASE and real ECH connections are handled uniformly, preventing timing side-channels.¶
If the client’s ClientHello does not contain an ECH extension, the server proceeds with a standard TLS handshake based on the indicated SNI. This fallback behavior should remain unchanged from existing TLS handling. The presence or absence of ECH extension data in the ClientHello is the primary trigger for the server’s ECH logic.¶
Implicit config_id usage may require additional CPU overhead from trial decryption for GREASE ECH handshakes. A single-key environment simplifies ignoring the config_id and yields more uniform performance.¶
Supporting implicit ECH configurations limits the number of different ECH keys supported by a server on the same IP address since the outer SNI and config_id can no longer be used to choose the appropriate ECH configuration.¶
In standard ECH, the server might quickly reject unknown hashed IDs. Implicit ECH requires the server to attempt uniform decryption for IDs, reducing the ECH vs. ECH GREASE timing gap.¶
By not placing public_name in the actual outer SNI, on-path adversaries
cannot block a known name. The client uses public_name only to authenticate
ECH retry hints, so an active attacker cannot degrade ECH without a valid
certificate.¶
Randomized config_id and outer SNI usage can lead to increased CPU usage from trial decryption. This cost grows if more than one ECH keys are in use on the same server. Operators should consider minimizing the number of active keys to mitigate this cost.¶
This document requests that IANA add the following entry to the "ECHConfig Extension" registry:¶
Marwan Fayed and Chris Patton provided ideas and contributions to this draft.¶