Internet-Draft Implicit ECH Config February 2025
Sullivan Expires 29 August 2025 [Page]
Workgroup:
tls
Internet-Draft:
draft-sullivan-tls-implicit-ech-00
Updates:
draft-ietf-tls-esni-23 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Author:
N. Sullivan
Cryptography Consulting LLC

Implicit ECH Configuration for TLS 1.3

Abstract

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:

Servers that include implicit_ech in the ECHConfig MUST accommodate flexible config_id usage. This approach removes stable identifiers (a hashed config ID and a known public_name) that can be blocked by censors or fingerprinted by middleboxes. It also increases CPU usage in multi-key deployments, because servers must perform uniform trial decryption to handle ephemeral config_id values.

Status of This Memo

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 August 2025.

▲

Table of Contents

1. Introduction

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 from the ECHConfig and derives config_id by hashing the server’s HPKE public key. Both of these can become stable fingerprints that censors or middleboxes recognize.

In implicit mode, the client can:

  1. Select any outer SNI (rather than the public_name).

  2. Randomize config_id instead of deriving it from the HPKE key.

Servers that publish or accept implicit ECH configurations must adjust key selection (e.g., single-key usage, uniform trial decryption), removing reliance on stable hashed config IDs or well-known public_name. 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 servers supporting implicit ECH to always attempt decryption — ensuring consistent behavior regardless of ECH key validity.

2. Conventions and Definitions

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.

3. Implicit ECH Extension

3.1. Extension Definition and Semantics

A new ECHConfig extension type is defined to indicate implicit mode. If this extension is present in ECHConfigContents.extensions, clients and 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 that the config_id used by the client may be ephemeral, outer SNI need not match public_name, and retry hint verification uses public_name coverage rather than SNI matching.

3.2. Overridden Rules in the Base ECH Specification

When the implicit_ech extension is found in ECHConfigContents.extensions, the following rules in [ECH-DRAFT] are overridden:

• Deterministic config_id derivation (section 4.1 of [ECH-DRAFT]). Instead of hashing the HPKE public key, the client MAY generate config_id as random or arbitrary bytes.

• Outer SNI usage (sections where [ECH-DRAFT] says the client SHOULD set SNI to public_name). In implicit mode, the client MAY choose any valid domain name or random string for the outer SNI.

• Verification of retry hints (sections referencing SNI-based certificate checks). In implicit mode, the client MUST ensure that the server’s certificate covers public_name from the ECHConfig rather than matching the SNI on the wire.

4. Client Behavior

If the client sees the implicit_ech extension in an ECHConfig:

• It MAY select any outer SNI, ignoring public_name as the actual SNI string.

• It MAY produce a random or arbitrary config_id, rather than deriving it from the HPKE key.

• If the server issues an ECH retry hint (for example, in EncryptedExtensions), the client MUST confirm that the server certificate covers the original public_name from the ECHConfig. If coverage is lacking, the client discards the hint.

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.

5. Server Behavior

A 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:

  1. The client was connecting to a domain that does not support ECH

  2. The client used a different ECHConfig from the currently supported one on the server.

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:

  1. A newly issued or updated ECHConfig, possibly including the implicit flag again.

  2. A server certificate that covers the server_name in the supported ECHConfig, 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.

6. Deployment Considerations

Operators who choose this implicit mode remove reliance on stable hashed IDs or a known public name as the outer SNI, improving censorship resistance. However, implicit config_id usage may require additional CPU overhead from trial decryption for GREASE ECH handshakes. A single-key environment simplifies ignoring 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.

7. Security Considerations

7.1. Timing Side-Channels from Unknown IDs

In normal 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.

7.2. Hiding the Known public_name

By not placing public_name in the actual outer SNI, censors or middleboxes 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 cert.

7.3. CPU Overhead

Ephemeral config_id 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.

8. IANA Considerations

This document requests that IANA add the following entry to the "ECHConfig Extension" registry:

9. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.

Acknowledgments

Marwan Fayed provided ideas and contributions to this draft.

Author's Address

Nick Sullivan
Cryptography Consulting LLC