rfc9849.original   rfc9849.txt 
tls E. Rescorla Internet Engineering Task Force (IETF) E. Rescorla
Internet-Draft Independent Request for Comments: 9849 Independent
Intended status: Standards Track K. Oku Category: Standards Track K. Oku
Expires: 16 December 2025 Fastly ISSN: 2070-1721 Fastly
N. Sullivan N. Sullivan
Cryptography Consulting LLC Cryptography Consulting LLC
C. A. Wood C. A. Wood
Cloudflare Cloudflare
14 June 2025 November 2025
TLS Encrypted Client Hello TLS Encrypted Client Hello
draft-ietf-tls-esni-25
Abstract Abstract
This document describes a mechanism in Transport Layer Security (TLS) This document describes a mechanism in Transport Layer Security (TLS)
for encrypting a ClientHello message under a server public key. for encrypting a ClientHello message under a server public key.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/tlswg/draft-ietf-tls-esni
(https://github.com/tlswg/draft-ietf-tls-esni).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 16 December 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9849.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview
3.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Topologies
3.2. Encrypted ClientHello (ECH) . . . . . . . . . . . . . . . 6 3.2. Encrypted ClientHello (ECH)
4. Encrypted ClientHello Configuration . . . . . . . . . . . . . 7 4. Encrypted ClientHello Configuration
4.1. Configuration Identifiers . . . . . . . . . . . . . . . . 9 4.1. Configuration Identifiers
4.2. Configuration Extensions . . . . . . . . . . . . . . . . 10 4.2. Configuration Extensions
5. The "encrypted_client_hello" Extension . . . . . . . . . . . 10 5. The "encrypted_client_hello" Extension
5.1. Encoding the ClientHelloInner . . . . . . . . . . . . . . 12 5.1. Encoding the ClientHelloInner
5.2. Authenticating the ClientHelloOuter . . . . . . . . . . . 14 5.2. Authenticating the ClientHelloOuter
6. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 6. Client Behavior
6.1. Offering ECH . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Offering ECH
6.1.1. Encrypting the ClientHello . . . . . . . . . . . . . 16 6.1.1. Encrypting the ClientHello
6.1.2. GREASE PSK . . . . . . . . . . . . . . . . . . . . . 18 6.1.2. GREASE PSK
6.1.3. Recommended Padding Scheme . . . . . . . . . . . . . 18 6.1.3. Recommended Padding Scheme
6.1.4. Determining ECH Acceptance . . . . . . . . . . . . . 19 6.1.4. Determining ECH Acceptance
6.1.5. Handshaking with ClientHelloInner . . . . . . . . . . 20 6.1.5. Handshaking with ClientHelloInner
6.1.6. Handshaking with ClientHelloOuter . . . . . . . . . . 21 6.1.6. Handshaking with ClientHelloOuter
6.1.7. Authenticating for the Public Name . . . . . . . . . 22 6.1.7. Authenticating for the Public Name
6.1.8. Impact of Retry on Future Connections . . . . . . . . 23 6.1.8. Impact of Retry on Future Connections
6.2. GREASE ECH . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. GREASE ECH
6.2.1. Client Greasing . . . . . . . . . . . . . . . . . . . 24 6.2.1. Client Greasing
6.2.2. Server Greasing . . . . . . . . . . . . . . . . . . . 25 6.2.2. Server Greasing
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 25 7. Server Behavior
7.1. Client-Facing Server . . . . . . . . . . . . . . . . . . 26 7.1. Client-Facing Server
7.1.1. Sending HelloRetryRequest . . . . . . . . . . . . . . 28 7.1.1. Sending HelloRetryRequest
7.2. Backend Server . . . . . . . . . . . . . . . . . . . . . 29 7.2. Backend Server
7.2.1. Sending HelloRetryRequest . . . . . . . . . . . . . . 30 7.2.1. Sending HelloRetryRequest
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 30 8. Deployment Considerations
8.1. Compatibility Issues . . . . . . . . . . . . . . . . . . 31 8.1. Compatibility Issues
8.1.1. Misconfiguration and Deployment Concerns . . . . . . 31 8.1.1. Misconfiguration and Deployment Concerns
8.1.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . 32 8.1.2. Middleboxes
8.2. Deployment Impact . . . . . . . . . . . . . . . . . . . . 32 8.2. Deployment Impact
9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 33 9. Compliance Requirements
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations
10.1. Security and Privacy Goals . . . . . . . . . . . . . . . 33 10.1. Security and Privacy Goals
10.2. Unauthenticated and Plaintext DNS . . . . . . . . . . . 35 10.2. Unauthenticated and Plaintext DNS
10.3. Client Tracking . . . . . . . . . . . . . . . . . . . . 35 10.3. Client Tracking
10.4. Ignored Configuration Identifiers and Trial 10.4. Ignored Configuration Identifiers and Trial Decryption
Decryption . . . . . . . . . . . . . . . . . . . . . . 36 10.5. Outer ClientHello
10.5. Outer ClientHello . . . . . . . . . . . . . . . . . . . 36 10.6. Inner ClientHello
10.6. Inner ClientHello . . . . . . . . . . . . . . . . . . . 37 10.7. Related Privacy Leaks
10.7. Related Privacy Leaks . . . . . . . . . . . . . . . . . 37 10.8. Cookies
10.8. Cookies . . . . . . . . . . . . . . . . . . . . . . . . 38 10.9. Attacks Exploiting Acceptance Confirmation
10.9. Attacks Exploiting Acceptance Confirmation . . . . . . . 38 10.10. Comparison Against Criteria
10.10. Comparison Against Criteria . . . . . . . . . . . . . . 39 10.10.1. Mitigate Cut-and-Paste Attacks
10.10.1. Mitigate Cut-and-Paste Attacks . . . . . . . . . . 39 10.10.2. Avoid Widely Shared Secrets
10.10.2. Avoid Widely Shared Secrets . . . . . . . . . . . . 39 10.10.3. SNI-Based Denial-of-Service Attacks
10.10.3. SNI-Based Denial-of-Service Attacks . . . . . . . . 39 10.10.4. Do Not Stick Out
10.10.4. Do Not Stick Out . . . . . . . . . . . . . . . . . 39 10.10.5. Maintain Forward Secrecy
10.10.5. Maintain Forward Secrecy . . . . . . . . . . . . . 41 10.10.6. Enable Multi-party Security Contexts
10.10.6. Enable Multi-party Security Contexts . . . . . . . 41 10.10.7. Support Multiple Protocols
10.10.7. Support Multiple Protocols . . . . . . . . . . . . 41 10.11. Padding Policy
10.11. Padding Policy . . . . . . . . . . . . . . . . . . . . . 41 10.12. Active Attack Mitigations
10.12. Active Attack Mitigations . . . . . . . . . . . . . . . 42 10.12.1. Client Reaction Attack Mitigation
10.12.1. Client Reaction Attack Mitigation . . . . . . . . . 42 10.12.2. HelloRetryRequest Hijack Mitigation
10.12.2. HelloRetryRequest Hijack Mitigation . . . . . . . . 43 10.12.3. ClientHello Malleability Mitigation
10.12.3. ClientHello Malleability Mitigation . . . . . . . . 44 10.12.4. ClientHelloInner Packet Amplification Mitigation
10.12.4. ClientHelloInner Packet Amplification Mitigation . 45 11. IANA Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 11.1. Update of the TLS ExtensionType Registry
11.1. Update of the TLS ExtensionType Registry . . . . . . . . 46 11.2. Update of the TLS Alert Registry
11.2. Update of the TLS Alert Registry . . . . . . . . . . . . 46 11.3. ECH Configuration Extension Registry
11.3. ECH Configuration Extension Registry . . . . . . . . . . 46 12. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 12.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 47 12.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 49 Appendix A. Linear-Time Outer Extension Processing
Appendix A. Linear-time Outer Extension Processing . . . . . . . 50 Acknowledgements
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 51 Authors' Addresses
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 51
C.1. Since draft-ietf-tls-esni-16 . . . . . . . . . . . . . . 51
C.2. Since draft-ietf-tls-esni-15 . . . . . . . . . . . . . . 51
C.3. Since draft-ietf-tls-esni-14 . . . . . . . . . . . . . . 51
C.4. Since draft-ietf-tls-esni-13 . . . . . . . . . . . . . . 51
C.5. Since draft-ietf-tls-esni-12 . . . . . . . . . . . . . . 51
C.6. Since draft-ietf-tls-esni-11 . . . . . . . . . . . . . . 52
C.7. Since draft-ietf-tls-esni-10 . . . . . . . . . . . . . . 52
C.8. Since draft-ietf-tls-esni-09 . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
Although TLS 1.3 [RFC8446] encrypts most of the handshake, including Although TLS 1.3 [RFC8446] encrypts most of the handshake, including
the server certificate, there are several ways in which an on-path the server certificate, there are several ways in which an on-path
attacker can learn private information about the connection. The attacker can learn private information about the connection. The
plaintext Server Name Indication (SNI) extension in ClientHello plaintext Server Name Indication (SNI) extension in ClientHello
messages, which leaks the target domain for a given connection, is messages, which leaks the target domain for a given connection, is
perhaps the most sensitive information left unencrypted in TLS 1.3. perhaps the most sensitive information left unencrypted in TLS 1.3.
This document specifies a new TLS extension, called Encrypted Client This document specifies a new TLS extension called Encrypted Client
Hello (ECH), that allows clients to encrypt their ClientHello to the Hello (ECH) that allows clients to encrypt their ClientHello to the
TLS server. This protects the SNI and other potentially sensitive TLS server. This protects the SNI and other potentially sensitive
fields, such as the Application Layer Protocol Negotiation (ALPN) fields, such as the Application-Layer Protocol Negotiation (ALPN)
list [RFC7301]. Co-located servers with consistent externally list [RFC7301]. Co-located servers with consistent externally
visible TLS configurations and behavior, including supported versions visible TLS configurations and behavior, including supported versions
and cipher suites and how they respond to incoming client and cipher suites and how they respond to incoming client
connections, form an anonymity set. (Note that implementation- connections, form an anonymity set. (Note that implementation-
specific choices, such as extension ordering within TLS messages or specific choices, such as extension ordering within TLS messages or
division of data into record-layer boundaries, can result in division of data into record-layer boundaries, can result in
different externally visible behavior, even for servers with different externally visible behavior, even for servers with
consistent TLS configurations.) Usage of this mechanism reveals that consistent TLS configurations.) Usage of this mechanism reveals that
a client is connecting to a particular service provider, but does not a client is connecting to a particular service provider, but does not
reveal which server from the anonymity set terminates the connection. reveal which server from the anonymity set terminates the connection.
skipping to change at page 6, line 6 skipping to change at line 215
In Split Mode, the provider is not the origin server for private In Split Mode, the provider is not the origin server for private
domains. Rather, the DNS records for private domains point to the domains. Rather, the DNS records for private domains point to the
provider, and the provider's server relays the connection back to the provider, and the provider's server relays the connection back to the
origin server, who terminates the TLS connection with the client. origin server, who terminates the TLS connection with the client.
Importantly, the service provider does not have access to the Importantly, the service provider does not have access to the
plaintext of the connection beyond the unencrypted portions of the plaintext of the connection beyond the unencrypted portions of the
handshake. handshake.
In the remainder of this document, we will refer to the ECH-service In the remainder of this document, we will refer to the ECH-service
provider as the "client-facing server" and to the TLS terminator as provider as the "client-facing server" and the TLS terminator as the
the "backend server". These are the same entity in Shared Mode, but "backend server". These are the same entity in Shared Mode, but in
in Split Mode, the client-facing and backend servers are physically Split Mode, the client-facing and backend servers are physically
separated. separated.
See Section 10 for more discussion about the ECH threat model and how See Section 10 for more discussion about the ECH threat model and how
it relates to the client, client-facing server, and backend server. it relates to the client, client-facing server, and backend server.
3.2. Encrypted ClientHello (ECH) 3.2. Encrypted ClientHello (ECH)
A client-facing server enables ECH by publishing an ECH A client-facing server enables ECH by publishing an ECH
configuration, which is an encryption public key and associated configuration, which is an encryption public key and associated
metadata. Domains which wish to use ECH must publish this metadata. Domains which wish to use ECH must publish this
configuration, using the key associated with the client-facing configuration, using the key associated with the client-facing
server. This document defines the ECH configuration's format, but server. This document defines the ECH configuration's format, but
delegates DNS publication details to [RFC9460]. See [ECH-IN-DNS] for delegates DNS publication details to [RFC9460]. See [RFCYYY1] for
specifics about how ECH configurations are advertised in SVCB and specifics about how ECH configurations are advertised in SVCB and
HTTPS records. Other delivery mechanisms are also possible. For HTTPS records. Other delivery mechanisms are also possible. For
example, the client may have the ECH configuration preconfigured. example, the client may have the ECH configuration preconfigured.
When a client wants to establish a TLS session with some backend When a client wants to establish a TLS session with some backend
server, it constructs a private ClientHello, referred to as the server, it constructs a private ClientHello, referred to as the
ClientHelloInner. The client then constructs a public ClientHello, ClientHelloInner. The client then constructs a public ClientHello,
referred to as the ClientHelloOuter. The ClientHelloOuter contains referred to as the ClientHelloOuter. The ClientHelloOuter contains
innocuous values for sensitive extensions and an innocuous values for sensitive extensions and an
"encrypted_client_hello" extension (Section 5), which carries the "encrypted_client_hello" extension (Section 5), which carries the
skipping to change at page 7, line 13 skipping to change at line 269
configuration (Section 6.1.6). configuration (Section 6.1.6).
The primary goal of ECH is to ensure that connections to servers in The primary goal of ECH is to ensure that connections to servers in
the same anonymity set are indistinguishable from one another. the same anonymity set are indistinguishable from one another.
Moreover, it should achieve this goal without affecting any existing Moreover, it should achieve this goal without affecting any existing
security properties of TLS 1.3. See Section 10.1 for more details security properties of TLS 1.3. See Section 10.1 for more details
about the ECH security and privacy goals. about the ECH security and privacy goals.
4. Encrypted ClientHello Configuration 4. Encrypted ClientHello Configuration
ECH uses HPKE for public key encryption [HPKE]. The ECH ECH uses Hybrid Public Key Encryption (HPKE) for public key
configuration is defined by the following ECHConfig structure. encryption [HPKE]. The ECH configuration is defined by the following
ECHConfig structure.
opaque HpkePublicKey<1..2^16-1>; opaque HpkePublicKey<1..2^16-1>;
uint16 HpkeKemId; // Defined in RFC9180 uint16 HpkeKemId; // Defined in RFC 9180
uint16 HpkeKdfId; // Defined in RFC9180 uint16 HpkeKdfId; // Defined in RFC 9180
uint16 HpkeAeadId; // Defined in RFC9180 uint16 HpkeAeadId; // Defined in RFC 9180
uint16 ECHConfigExtensionType; // Defined in Section 11.3 uint16 ECHConfigExtensionType; // Defined in Section 11.3
struct { struct {
HpkeKdfId kdf_id; HpkeKdfId kdf_id;
HpkeAeadId aead_id; HpkeAeadId aead_id;
} HpkeSymmetricCipherSuite; } HpkeSymmetricCipherSuite;
struct { struct {
uint8 config_id; uint8 config_id;
HpkeKemId kem_id; HpkeKemId kem_id;
skipping to change at page 8, line 7 skipping to change at line 313
struct { struct {
uint16 version; uint16 version;
uint16 length; uint16 length;
select (ECHConfig.version) { select (ECHConfig.version) {
case 0xfe0d: ECHConfigContents contents; case 0xfe0d: ECHConfigContents contents;
} }
} ECHConfig; } ECHConfig;
The structure contains the following fields: The structure contains the following fields:
version The version of ECH for which this configuration is used. version: The version of ECH for which this configuration is used.
The version is the same as the code point for the The version is the same as the code point for the
"encrypted_client_hello" extension. Clients MUST ignore any "encrypted_client_hello" extension. Clients MUST ignore any
ECHConfig structure with a version they do not support. ECHConfig structure with a version they do not support.
length The length, in bytes, of the next field. This length field length: The length, in bytes, of the next field. This length field
allows implementations to skip over the elements in such a list allows implementations to skip over the elements in such a list
where they cannot parse the specific version of ECHConfig. where they cannot parse the specific version of ECHConfig.
contents An opaque byte string whose contents depend on the version. contents: An opaque byte string whose contents depend on the
For this specification, the contents are an ECHConfigContents version. For this specification, the contents are an
structure. ECHConfigContents structure.
The ECHConfigContents structure contains the following fields: The ECHConfigContents structure contains the following fields:
key_config A HpkeKeyConfig structure carrying the configuration key_config: A HpkeKeyConfig structure carrying the configuration
information associated with the HPKE public key (an "ECH key"). information associated with the HPKE public key (an "ECH key").
Note that this structure contains the config_id field, which Note that this structure contains the config_id field, which
applies to the entire ECHConfigContents. applies to the entire ECHConfigContents.
maximum_name_length The longest name of a backend server, if known. maximum_name_length: The longest name of a backend server, if known.
If not known, this value can be set to zero. It is used to If not known, this value can be set to zero. It is used to
compute padding (Section 6.1.3) and does not constrain server name compute padding (Section 6.1.3) and does not constrain server name
lengths. Names may exceed this length if, e.g., the server uses lengths. Names may exceed this length if, e.g., the server uses
wildcard names or added new names to the anonymity set. wildcard names or added new names to the anonymity set.
public_name The DNS name of the client-facing server, i.e., the public_name: The DNS name of the client-facing server, i.e., the
entity trusted to update the ECH configuration. This is used to entity trusted to update the ECH configuration. This is used to
correct misconfigured clients, as described in Section 6.1.6. correct misconfigured clients, as described in Section 6.1.6.
See Section 6.1.7 for how the client interprets and validates the See Section 6.1.7 for how the client interprets and validates the
public_name. public_name.
extensions A list of ECHConfigExtension values that the client must extensions: A list of ECHConfigExtension values that the client must
take into consideration when generating a ClientHello message. take into consideration when generating a ClientHello message.
Each ECHConfigExtension has a 2-octet type and opaque data value, Each ECHConfigExtension has a 2-octet type and opaque data value,
where the data value is encoded with a 2-octet integer where the data value is encoded with a 2-octet integer
representing the length of the data, in network byte order. representing the length of the data, in network byte order.
ECHConfigExtension values are described below (Section 4.2). ECHConfigExtension values are described below (Section 4.2).
The HpkeKeyConfig structure contains the following fields: The HpkeKeyConfig structure contains the following fields:
config_id A one-byte identifier for the given HPKE key config_id: A one-byte identifier for the given HPKE key
configuration. This is used by clients to indicate the key used configuration. This is used by clients to indicate the key used
for ClientHello encryption. Section 4.1 describes how client- for ClientHello encryption. Section 4.1 describes how client-
facing servers allocate this value. facing servers allocate this value.
kem_id The HPKE Key Encapsulation Mechanism (KEM) identifier kem_id: The HPKE Key Encapsulation Mechanism (KEM) identifier
corresponding to public_key. Clients MUST ignore any ECHConfig corresponding to public_key. Clients MUST ignore any ECHConfig
structure with a key using a KEM they do not support. structure with a key using a KEM they do not support.
public_key The HPKE public key used by the client to encrypt public_key: The HPKE public key used by the client to encrypt
ClientHelloInner. ClientHelloInner.
cipher_suites The list of HPKE KDF and AEAD identifier pairs clients cipher_suites: The list of HPKE Key Derivation Function (KDF) and
can use for encrypting ClientHelloInner. See Section 6.1 for how Authenticated Encryption with Associated Data (AEAD) identifier
clients choose from this list. pairs clients can use for encrypting ClientHelloInner. See
Section 6.1 for how clients choose from this list.
The client-facing server advertises a sequence of ECH configurations The client-facing server advertises a sequence of ECH configurations
to clients, serialized as follows. to clients, serialized as follows.
ECHConfig ECHConfigList<4..2^16-1>; ECHConfig ECHConfigList<4..2^16-1>;
The ECHConfigList structure contains one or more ECHConfig structures The ECHConfigList structure contains one or more ECHConfig structures
in decreasing order of preference. This allows a server to support in decreasing order of preference. This allows a server to support
multiple versions of ECH and multiple sets of ECH parameters. multiple versions of ECH and multiple sets of ECH parameters.
4.1. Configuration Identifiers 4.1. Configuration Identifiers
A client-facing server has a set of known ECHConfig values, with A client-facing server has a set of known ECHConfig values with
corresponding private keys. This set SHOULD contain the currently corresponding private keys. This set SHOULD contain the currently
published values, as well as previous values that may still be in published values, as well as previous values that may still be in
use, since clients may cache DNS records up to a TTL or longer. use, since clients may cache DNS records up to a TTL or longer.
Section 7.1 describes a trial decryption process for decrypting the Section 7.1 describes a trial decryption process for decrypting the
ClientHello. This can impact performance when the client-facing ClientHello. This can impact performance when the client-facing
server maintains many known ECHConfig values. To avoid this, the server maintains many known ECHConfig values. To avoid this, the
client-facing server SHOULD allocate distinct config_id values for client-facing server SHOULD allocate distinct config_id values for
each ECHConfig in its known set. The RECOMMENDED strategy is via each ECHConfig in its known set. The RECOMMENDED strategy is via
rejection sampling, i.e., to randomly select config_id repeatedly rejection sampling, i.e., to randomly select config_id repeatedly
skipping to change at page 10, line 25 skipping to change at line 422
mandatory by using an extension type codepoint with the high order mandatory by using an extension type codepoint with the high order
bit set to 1. bit set to 1.
Clients MUST parse the extension list and check for unsupported Clients MUST parse the extension list and check for unsupported
mandatory extensions. If an unsupported mandatory extension is mandatory extensions. If an unsupported mandatory extension is
present, clients MUST ignore the ECHConfig. present, clients MUST ignore the ECHConfig.
Any future information or hints that influence ClientHelloOuter Any future information or hints that influence ClientHelloOuter
SHOULD be specified as ECHConfig extensions. This is primarily SHOULD be specified as ECHConfig extensions. This is primarily
because the outer ClientHello exists only in support of ECH. Namely, because the outer ClientHello exists only in support of ECH. Namely,
it is both an envelope for the encrypted inner ClientHello and it is both an envelope for the encrypted inner ClientHello and an
enabler for authenticated key mismatch signals (see Section 7). In enabler for authenticated key mismatch signals (see Section 7). In
contrast, the inner ClientHello is the true ClientHello used upon ECH contrast, the inner ClientHello is the true ClientHello used upon ECH
negotiation. negotiation.
5. The "encrypted_client_hello" Extension 5. The "encrypted_client_hello" Extension
To offer ECH, the client sends an "encrypted_client_hello" extension To offer ECH, the client sends an "encrypted_client_hello" extension
in the ClientHelloOuter. When it does, it MUST also send the in the ClientHelloOuter. When it does, it MUST also send the
extension in ClientHelloInner. extension in ClientHelloInner.
skipping to change at page 11, line 26 skipping to change at line 460
Empty; Empty;
}; };
} ECHClientHello; } ECHClientHello;
The outer extension uses the outer variant and the inner extension The outer extension uses the outer variant and the inner extension
uses the inner variant. The inner extension has an empty payload, uses the inner variant. The inner extension has an empty payload,
which is included because TLS servers are not allowed to provide which is included because TLS servers are not allowed to provide
extensions in ServerHello which were not included in ClientHello. extensions in ServerHello which were not included in ClientHello.
The outer extension has the following fields: The outer extension has the following fields:
config_id The ECHConfigContents.key_config.config_id for the chosen config_id: The ECHConfigContents.key_config.config_id for the chosen
ECHConfig. ECHConfig.
cipher_suite The cipher suite used to encrypt ClientHelloInner. cipher_suite: The cipher suite used to encrypt ClientHelloInner.
This MUST match a value provided in the corresponding This MUST match a value provided in the corresponding
ECHConfigContents.cipher_suites list. ECHConfigContents.cipher_suites list.
enc The HPKE encapsulated key, used by servers to decrypt the enc: The HPKE encapsulated key used by servers to decrypt the
corresponding payload field. This field is empty in a corresponding payload field. This field is empty in a
ClientHelloOuter sent in response to HelloRetryRequest. ClientHelloOuter sent in response to HelloRetryRequest.
payload The serialized and encrypted EncodedClientHelloInner payload: The serialized and encrypted EncodedClientHelloInner
structure, encrypted using HPKE as described in Section 6.1. structure, encrypted using HPKE as described in Section 6.1.
When a client offers the outer version of an "encrypted_client_hello" When a client offers the outer version of an "encrypted_client_hello"
extension, the server MAY include an "encrypted_client_hello" extension, the server MAY include an "encrypted_client_hello"
extension in its EncryptedExtensions message, as described in extension in its EncryptedExtensions message, as described in
Section 7.1, with the following payload: Section 7.1, with the following payload:
struct { struct {
ECHConfigList retry_configs; ECHConfigList retry_configs;
} ECHEncryptedExtensions; } ECHEncryptedExtensions;
The response is valid only when the server used the ClientHelloOuter. The response is valid only when the server used the ClientHelloOuter.
If the server sent this extension in response to the inner variant, If the server sent this extension in response to the inner variant,
then the client MUST abort with an "unsupported_extension" alert. then the client MUST abort with an "unsupported_extension" alert.
retry_configs An ECHConfigList structure containing one or more retry_configs: An ECHConfigList structure containing one or more
ECHConfig structures, in decreasing order of preference, to be ECHConfig structures, in decreasing order of preference, to be
used by the client as described in Section 6.1.6. These are known used by the client as described in Section 6.1.6. These are known
as the server's "retry configurations". as the server's "retry configurations".
Finally, when the client offers the "encrypted_client_hello", if the Finally, when the client offers the "encrypted_client_hello", if the
payload is the inner variant and the server responds with payload is the inner variant and the server responds with
HelloRetryRequest, it MUST include an "encrypted_client_hello" HelloRetryRequest, it MUST include an "encrypted_client_hello"
extension with the following payload: extension with the following payload:
struct { struct {
skipping to change at page 12, line 29 skipping to change at line 511
The value of ECHHelloRetryRequest.confirmation is set to The value of ECHHelloRetryRequest.confirmation is set to
hrr_accept_confirmation as described in Section 7.2.1. hrr_accept_confirmation as described in Section 7.2.1.
This document also defines the "ech_required" alert, which the client This document also defines the "ech_required" alert, which the client
MUST send when it offered an "encrypted_client_hello" extension that MUST send when it offered an "encrypted_client_hello" extension that
was not accepted by the server. (See Section 11.2.) was not accepted by the server. (See Section 11.2.)
5.1. Encoding the ClientHelloInner 5.1. Encoding the ClientHelloInner
Before encrypting, the client pads and optionally compresses Before encrypting, the client pads and optionally compresses
ClientHelloInner into a EncodedClientHelloInner structure, defined ClientHelloInner into an EncodedClientHelloInner structure, defined
below: below:
struct { struct {
ClientHello client_hello; ClientHello client_hello;
uint8 zeros[length_of_padding]; uint8 zeros[length_of_padding];
} EncodedClientHelloInner; } EncodedClientHelloInner;
The client_hello field is computed by first making a copy of The client_hello field is computed by first making a copy of
ClientHelloInner and setting the legacy_session_id field to the empty ClientHelloInner and setting the legacy_session_id field to the empty
string. In TLS, this field uses the ClientHello structure defined in string. In TLS, this field uses the ClientHello structure defined in
skipping to change at page 13, line 18 skipping to change at line 549
ExtensionType OuterExtensions<2..254>; ExtensionType OuterExtensions<2..254>;
OuterExtensions contains the removed ExtensionType values. Each OuterExtensions contains the removed ExtensionType values. Each
value references the matching extension in ClientHelloOuter. The value references the matching extension in ClientHelloOuter. The
values MUST be ordered contiguously in ClientHelloInner, and the values MUST be ordered contiguously in ClientHelloInner, and the
"ech_outer_extensions" extension MUST be inserted in the "ech_outer_extensions" extension MUST be inserted in the
corresponding position in EncodedClientHelloInner. Additionally, the corresponding position in EncodedClientHelloInner. Additionally, the
extensions MUST appear in ClientHelloOuter in the same relative extensions MUST appear in ClientHelloOuter in the same relative
order. However, there is no requirement that they be contiguous. order. However, there is no requirement that they be contiguous.
For example, OuterExtensions may contain extensions A, B, C, while For example, OuterExtensions may contain extensions A, B, and C,
ClientHelloOuter contains extensions A, D, B, C, E, F. while ClientHelloOuter contains extensions A, D, B, C, E, and F.
The "ech_outer_extensions" extension can only be included in The "ech_outer_extensions" extension can only be included in
EncodedClientHelloInner, and MUST NOT appear in either EncodedClientHelloInner and MUST NOT appear in either
ClientHelloOuter or ClientHelloInner. ClientHelloOuter or ClientHelloInner.
Finally, the client pads the message by setting the zeros field to a Finally, the client pads the message by setting the zeros field to a
byte string whose contents are all zeros and whose length is the byte string whose contents are all zeros and whose length is the
amount of padding to add. Section 6.1.3 describes a recommended amount of padding to add. Section 6.1.3 describes a recommended
padding scheme. padding scheme.
The client-facing server computes ClientHelloInner by reversing this The client-facing server computes ClientHelloInner by reversing this
process. First it parses EncodedClientHelloInner, interpreting all process. First, it parses EncodedClientHelloInner, interpreting all
bytes after client_hello as padding. If any padding byte is non- bytes after client_hello as padding. If any padding byte is non-
zero, the server MUST abort the connection with an zero, the server MUST abort the connection with an
"illegal_parameter" alert. "illegal_parameter" alert.
Next it makes a copy of the client_hello field and copies the Next, it makes a copy of the client_hello field and copies the
legacy_session_id field from ClientHelloOuter. It then looks for an legacy_session_id field from ClientHelloOuter. It then looks for an
"ech_outer_extensions" extension. If found, it replaces the "ech_outer_extensions" extension. If found, it replaces the
extension with the corresponding sequence of extensions in the extension with the corresponding sequence of extensions in the
ClientHelloOuter. The server MUST abort the connection with an ClientHelloOuter. The server MUST abort the connection with an
"illegal_parameter" alert if any of the following are true: "illegal_parameter" alert if any of the following are true:
* Any referenced extension is missing in ClientHelloOuter. * Any referenced extension is missing in ClientHelloOuter.
* Any extension is referenced in OuterExtensions more than once. * Any extension is referenced in OuterExtensions more than once.
* "encrypted_client_hello" is referenced in OuterExtensions. * "encrypted_client_hello" is referenced in OuterExtensions.
* The extensions in ClientHelloOuter corresponding to those in * The extensions in ClientHelloOuter corresponding to those in
OuterExtensions do not occur in the same order. OuterExtensions do not occur in the same order.
These requirements prevent an attacker from performing a packet These requirements prevent an attacker from performing a packet
amplification attack, by crafting a ClientHelloOuter which amplification attack by crafting a ClientHelloOuter which
decompresses to a much larger ClientHelloInner. This is discussed decompresses to a much larger ClientHelloInner. This is discussed
further in Section 10.12.4. further in Section 10.12.4.
Implementations SHOULD construct the ClientHelloInner in linear time. Implementations SHOULD construct the ClientHelloInner in linear time.
Quadratic time implementations (such as may happen via naive copying) Quadratic time implementations (such as may happen via naive copying)
create a denial of service risk. Appendix A describes a linear-time create a denial-of-service risk. Appendix A describes a linear-time
procedure that may be used for this purpose. procedure that may be used for this purpose.
5.2. Authenticating the ClientHelloOuter 5.2. Authenticating the ClientHelloOuter
To prevent a network attacker from modifying the ClientHelloOuter To prevent a network attacker from modifying the ClientHelloOuter
while keeping the same encrypted ClientHelloInner (see while keeping the same encrypted ClientHelloInner (see
Section 10.12.3), ECH authenticates ClientHelloOuter by passing Section 10.12.3), ECH authenticates ClientHelloOuter by passing
ClientHelloOuterAAD as the associated data for HPKE sealing and ClientHelloOuterAAD as the associated data for HPKE sealing and
opening operations. The ClientHelloOuterAAD is a serialized opening operations. The ClientHelloOuterAAD is a serialized
ClientHello structure, defined in Section 4.1.2 of [RFC8446] for TLS ClientHello structure, defined in Section 4.1.2 of [RFC8446] for TLS
and Section 5.3 of [RFC9147] for DTLS, which matches the and Section 5.3 of [RFC9147] for DTLS, which matches the
ClientHelloOuter except that the payload field of the ClientHelloOuter except that the payload field of the
"encrypted_client_hello" is replaced with a byte string of the same "encrypted_client_hello" is replaced with a byte string of the same
length but whose contents are zeros. This value does not include length but whose contents are zeros. This value does not include
Handshake structure's four-byte header in TLS nor twelve-byte header Handshake structure's four-byte header in TLS nor twelve-byte header
in DTLS. in DTLS.
6. Client Behavior 6. Client Behavior
Clients that implement the ECH extension behave in one of two ways: Clients that implement the ECH extension behave in one of two ways:
either they offer a real ECH extension, as described in Section 6.1; either they offer a real ECH extension, as described in Section 6.1,
or they send a Generate Random Extensions And Sustain Extensibility or they send a Generate Random Extensions And Sustain Extensibility
(GREASE) [RFC8701] ECH extension, as described in Section 6.2. (GREASE) [RFC8701] ECH extension, as described in Section 6.2.
Clients of the latter type do not negotiate ECH. Instead, they Clients of the latter type do not negotiate ECH. Instead, they
generate a dummy ECH extension that is ignored by the server. (See generate a dummy ECH extension that is ignored by the server. (See
Section 10.10.4 for an explanation.) The client offers ECH if it is Section 10.10.4 for an explanation.) The client offers ECH if it is
in possession of a compatible ECH configuration and sends GREASE ECH in possession of a compatible ECH configuration and sends GREASE ECH
(see Section 6.2) otherwise. (see Section 6.2) otherwise.
6.1. Offering ECH 6.1. Offering ECH
skipping to change at page 16, line 21 skipping to change at line 692
the "server_name" extension. Clients that do not follow this the "server_name" extension. Clients that do not follow this
step, or place a different value in the "server_name" extension, step, or place a different value in the "server_name" extension,
risk breaking the retry mechanism described in Section 6.1.6 or risk breaking the retry mechanism described in Section 6.1.6 or
failing to interoperate with servers that require this step to be failing to interoperate with servers that require this step to be
done; see Section 7.1. done; see Section 7.1.
6. When the client offers the "pre_shared_key" extension in 6. When the client offers the "pre_shared_key" extension in
ClientHelloInner, it SHOULD also include a GREASE ClientHelloInner, it SHOULD also include a GREASE
"pre_shared_key" extension in ClientHelloOuter, generated in the "pre_shared_key" extension in ClientHelloOuter, generated in the
manner described in Section 6.1.2. The client MUST NOT use this manner described in Section 6.1.2. The client MUST NOT use this
extension to advertise a PSK to the client-facing server. (See extension to advertise a Pre-Shared Key (PSK) to the client-
Section 10.12.3.) When the client includes a GREASE facing server. (See Section 10.12.3.) When the client includes
"pre_shared_key" extension, it MUST also copy the a GREASE "pre_shared_key" extension, it MUST also copy the
"psk_key_exchange_modes" from the ClientHelloInner into the "psk_key_exchange_modes" from the ClientHelloInner into the
ClientHelloOuter. ClientHelloOuter.
7. When the client offers the "early_data" extension in 7. When the client offers the "early_data" extension in
ClientHelloInner, it MUST also include the "early_data" extension ClientHelloInner, it MUST also include the "early_data" extension
in ClientHelloOuter. This allows servers that reject ECH and use in ClientHelloOuter. This allows servers that reject ECH and use
ClientHelloOuter to safely ignore any early data sent by the ClientHelloOuter to safely ignore any early data sent by the
client per [RFC8446], Section 4.2.10. client per [RFC8446], Section 4.2.10.
The client might duplicate non-sensitive extensions in both messages. The client might duplicate non-sensitive extensions in both messages.
However, implementations need to take care to ensure that sensitive However, implementations need to take care to ensure that sensitive
extensions are not offered in the ClientHelloOuter. See Section 10.5 extensions are not offered in the ClientHelloOuter. See Section 10.5
for additional guidance. for additional guidance.
Finally, the client encrypts the EncodedClientHelloInner with the Finally, the client encrypts the EncodedClientHelloInner with the
above values, as described in Section 6.1.1, to construct a above values, as described in Section 6.1.1, to construct a
ClientHelloOuter. It sends this to the server, and processes the ClientHelloOuter. It sends this to the server and processes the
response as described in Section 6.1.4. response as described in Section 6.1.4.
6.1.1. Encrypting the ClientHello 6.1.1. Encrypting the ClientHello
Given an EncodedClientHelloInner, an HPKE encryption context and enc Given an EncodedClientHelloInner, an HPKE encryption context and enc
value, and a partial ClientHelloOuterAAD, the client constructs a value, and a partial ClientHelloOuterAAD, the client constructs a
ClientHelloOuter as follows. ClientHelloOuter as follows.
First, the client determines the length L of encrypting First, the client determines the length L of encrypting
EncodedClientHelloInner with the selected HPKE AEAD. This is EncodedClientHelloInner with the selected HPKE AEAD. This is
skipping to change at page 17, line 43 skipping to change at line 758
ClientHelloOuter to the ClientHelloInner, thus preventing attackers ClientHelloOuter to the ClientHelloInner, thus preventing attackers
from modifying ClientHelloOuter while keeping the same from modifying ClientHelloOuter while keeping the same
ClientHelloInner, as described in Section 10.12.3. ClientHelloInner, as described in Section 10.12.3.
Finally, the client replaces payload with final_payload to obtain Finally, the client replaces payload with final_payload to obtain
ClientHelloOuter. The two values have the same length, so it is not ClientHelloOuter. The two values have the same length, so it is not
necessary to recompute length prefixes in the serialized structure. necessary to recompute length prefixes in the serialized structure.
Note this construction requires the "encrypted_client_hello" be Note this construction requires the "encrypted_client_hello" be
computed after all other extensions. This is possible because the computed after all other extensions. This is possible because the
ClientHelloOuter's "pre_shared_key" extension is either omitted, or ClientHelloOuter's "pre_shared_key" extension is either omitted or
uses a random binder (Section 6.1.2). uses a random binder (Section 6.1.2).
6.1.2. GREASE PSK 6.1.2. GREASE PSK
When offering ECH, the client is not permitted to advertise PSK When offering ECH, the client is not permitted to advertise PSK
identities in the ClientHelloOuter. However, the client can send a identities in the ClientHelloOuter. However, the client can send a
"pre_shared_key" extension in the ClientHelloInner. In this case, "pre_shared_key" extension in the ClientHelloInner. In this case,
when resuming a session with the client, the backend server sends a when resuming a session with the client, the backend server sends a
"pre_shared_key" extension in its ServerHello. This would appear to "pre_shared_key" extension in its ServerHello. This would appear to
a network observer as if the server were sending this extension a network observer as if the server were sending this extension
skipping to change at page 18, line 37 skipping to change at line 793
Per the rules of Section 6.1, the server is not permitted to resume a Per the rules of Section 6.1, the server is not permitted to resume a
connection in the outer handshake. If ECH is rejected and the connection in the outer handshake. If ECH is rejected and the
client-facing server replies with a "pre_shared_key" extension in its client-facing server replies with a "pre_shared_key" extension in its
ServerHello, then the client MUST abort the handshake with an ServerHello, then the client MUST abort the handshake with an
"illegal_parameter" alert. "illegal_parameter" alert.
6.1.3. Recommended Padding Scheme 6.1.3. Recommended Padding Scheme
If the ClientHelloInner is encrypted without padding, then the length If the ClientHelloInner is encrypted without padding, then the length
of the ClientHelloOuter.payload can leak information about of the ClientHelloOuter.payload can leak information about
ClientHelloInner. In order to prevent this the ClientHelloInner. In order to prevent this, the
EncodedClientHelloInner structure has a padding field. This section EncodedClientHelloInner structure has a padding field. This section
describes a deterministic mechanism for computing the required amount describes a deterministic mechanism for computing the required amount
of padding based on the following observation: individual extensions of padding based on the following observation: individual extensions
can reveal sensitive information through their length. Thus, each can reveal sensitive information through their length. Thus, each
extension in the inner ClientHello may require different amounts of extension in the inner ClientHello may require different amounts of
padding. This padding may be fully determined by the client's padding. This padding may be fully determined by the client's
configuration or may require server input. configuration or may require server input.
By way of example, clients typically support a small number of By way of example, clients typically support a small number of
application profiles. For instance, a browser might support HTTP application profiles. For instance, a browser might support HTTP
skipping to change at page 20, line 38 skipping to change at line 892
1. It computes a second ClientHelloInner based on the first 1. It computes a second ClientHelloInner based on the first
ClientHelloInner, as in Section 4.1.4 of [RFC8446]. The ClientHelloInner, as in Section 4.1.4 of [RFC8446]. The
ClientHelloInner's "encrypted_client_hello" extension is left ClientHelloInner's "encrypted_client_hello" extension is left
unmodified. unmodified.
2. It constructs EncodedClientHelloInner as described in 2. It constructs EncodedClientHelloInner as described in
Section 5.1. Section 5.1.
3. It constructs a second partial ClientHelloOuterAAD message. This 3. It constructs a second partial ClientHelloOuterAAD message. This
message MUST be syntactically valid. The extensions MAY be message MUST be syntactically valid. The extensions MAY be
copied from the original ClientHelloOuter unmodified, or omitted. copied from the original ClientHelloOuter unmodified or omitted.
If not sensitive, the client MAY copy updated extensions from the If not sensitive, the client MAY copy updated extensions from the
second ClientHelloInner for compression. second ClientHelloInner for compression.
4. It encrypts EncodedClientHelloInner as described in 4. It encrypts EncodedClientHelloInner as described in
Section 6.1.1, using the second partial ClientHelloOuterAAD, to Section 6.1.1, using the second partial ClientHelloOuterAAD, to
obtain a second ClientHelloOuter. It reuses the original HPKE obtain a second ClientHelloOuter. It reuses the original HPKE
encryption context computed in Section 6.1 and uses the empty encryption context computed in Section 6.1 and uses the empty
string for enc. string for enc.
The HPKE context maintains a sequence number, so this operation The HPKE context maintains a sequence number, so this operation
skipping to change at page 21, line 29 skipping to change at line 930
the retry configurations. It MUST NOT treat this as a secure signal the retry configurations. It MUST NOT treat this as a secure signal
to disable ECH. to disable ECH.
If the server supplied an "encrypted_client_hello" extension in its If the server supplied an "encrypted_client_hello" extension in its
EncryptedExtensions message, the client MUST check that it is EncryptedExtensions message, the client MUST check that it is
syntactically valid and the client MUST abort the connection with a syntactically valid and the client MUST abort the connection with a
"decode_error" alert otherwise. If an earlier TLS version was "decode_error" alert otherwise. If an earlier TLS version was
negotiated, the client MUST NOT enable the False Start optimization negotiated, the client MUST NOT enable the False Start optimization
[RFC7918] for this handshake. If both authentication and the [RFC7918] for this handshake. If both authentication and the
handshake complete successfully, the client MUST perform the handshake complete successfully, the client MUST perform the
processing described below then abort the connection with an processing described below and then abort the connection with an
"ech_required" alert before sending any application data to the "ech_required" alert before sending any application data to the
server. server.
If the server provided "retry_configs" and if at least one of the If the server provided "retry_configs" and if at least one of the
values contains a version supported by the client, the client can values contains a version supported by the client, the client can
regard the ECH configuration as securely replaced by the server. It regard the ECH configuration as securely replaced by the server. It
SHOULD retry the handshake with a new transport connection, using the SHOULD retry the handshake with a new transport connection using the
retry configurations supplied by the server. retry configurations supplied by the server.
Clients can implement a new transport connection in a way that best Clients can implement a new transport connection in a way that best
suits their deployment. For example, clients can reuse the same suits their deployment. For example, clients can reuse the same
server IP address when establishing the new transport connection or server IP address when establishing the new transport connection or
they can choose to use a different IP address if provided with they can choose to use a different IP address if provided with
options from DNS. ECH does not mandate any specific implementation options from DNS. ECH does not mandate any specific implementation
choices when establishing this new connection. choices when establishing this new connection.
The retry configurations are meant to be used for retried The retry configurations are meant to be used for retried
skipping to change at page 22, line 27 skipping to change at line 977
connection and a node with configuration B in the second. Note that connection and a node with configuration B in the second. Note that
this guidance does not apply to the cases in the previous paragraph this guidance does not apply to the cases in the previous paragraph
where the server has securely disabled ECH. where the server has securely disabled ECH.
If a client does not retry, it MUST report an error to the calling If a client does not retry, it MUST report an error to the calling
application. application.
6.1.7. Authenticating for the Public Name 6.1.7. Authenticating for the Public Name
When the server rejects ECH, it continues with the handshake using When the server rejects ECH, it continues with the handshake using
the plaintext "server_name" extension instead (see Section 7). the plaintext "server_name" extension instead (see Section 7). Then,
Clients that offer ECH then authenticate the connection with the clients that offer ECH authenticate the connection with the public
public name, as follows: name as follows:
* The client MUST verify that the certificate is valid for * The client MUST verify that the certificate is valid for
ECHConfig.contents.public_name. If invalid, it MUST abort the ECHConfig.contents.public_name. If invalid, it MUST abort the
connection with the appropriate alert. connection with the appropriate alert.
* If the server requests a client certificate, the client MUST * If the server requests a client certificate, the client MUST
respond with an empty Certificate message, denoting no client respond with an empty Certificate message, denoting no client
certificate. certificate.
In verifying the client-facing server certificate, the client MUST In verifying the client-facing server certificate, the client MUST
skipping to change at page 23, line 26 skipping to change at line 1018
public_name that is not a valid host name in preferred name syntax public_name that is not a valid host name in preferred name syntax
(see Section 2 of [DNS-TERMS]). That is, to be valid, the (see Section 2 of [DNS-TERMS]). That is, to be valid, the
public_name needs to be a dot-separated sequence of LDH labels, as public_name needs to be a dot-separated sequence of LDH labels, as
defined in Section 2.3.1 of [RFC5890], where: defined in Section 2.3.1 of [RFC5890], where:
* the sequence does not begin or end with an ASCII dot, and * the sequence does not begin or end with an ASCII dot, and
* all labels are at most 63 octets. * all labels are at most 63 octets.
Clients additionally SHOULD ignore the structure if the final LDH Clients additionally SHOULD ignore the structure if the final LDH
label either consists of all ASCII digits (i.e. '0' through '9') or label either consists of all ASCII digits (i.e., '0' through '9') or
is "0x" or "0X" followed by some, possibly empty, sequence of ASCII is "0x" or "0X" followed by some, possibly empty, sequence of ASCII
hexadecimal digits (i.e. '0' through '9', 'a' through 'f', and 'A' hexadecimal digits (i.e., '0' through '9', 'a' through 'f', and 'A'
through 'F'). This avoids public_name values that may be interpreted through 'F'). This avoids public_name values that may be interpreted
as IPv4 literals. as IPv4 literals.
6.1.8. Impact of Retry on Future Connections 6.1.8. Impact of Retry on Future Connections
Clients MAY use information learned from a rejected ECH for future Clients MAY use information learned from a rejected ECH for future
connections to avoid repeatedly connecting to the same server and connections to avoid repeatedly connecting to the same server and
being forced to retry. However, they MUST handle ECH rejection for being forced to retry. However, they MUST handle ECH rejection for
those connections as if it were a fresh connection, rather than those connections as if it were a fresh connection, rather than
enforcing the single retry limit from Section 6.1.6. The reason for enforcing the single retry limit from Section 6.1.6. The reason for
this requirement is that if the server sends a "retry_config" and this requirement is that if the server sends a "retry_config" and
then immediately rejects the resulting connection, it is most likely then immediately rejects the resulting connection, it is most likely
misconfigured. However, if the server sends a "retry_config" and misconfigured. However, if the server sends a "retry_config" and
then the client tries to use that to connect some time later, it is then the client tries to use that to connect some time later, it is
possible that the server has changed its configuration again and is possible that the server has changed its configuration again and is
now trying to recover. now trying to recover.
Any persisted information MUST be associated with the ECHConfig Any persisted information MUST be associated with the ECHConfig
source used to bootstrap the connection, such as a DNS SVCB source used to bootstrap the connection, such as a DNS SVCB
ServiceMode record [ECH-IN-DNS]. Clients MUST limit any sharing of ServiceMode record [RFCYYY1]. Clients MUST limit any sharing of
persisted ECH-related state to connections that use the same persisted ECH-related state to connections that use the same
ECHConfig source. Otherwise, it might become possible for the client ECHConfig source. Otherwise, it might become possible for the client
to have the wrong public name for the server, making recovery to have the wrong public name for the server, making recovery
impossible. impossible.
ECHConfigs learned from ECH rejection can be used as a tracking ECHConfigs learned from ECH rejection can be used as a tracking
vector. Clients SHOULD impose the same lifetime and scope vector. Clients SHOULD impose the same lifetime and scope
restrictions that they apply to other server-based tracking vectors restrictions that they apply to other server-based tracking vectors
such as PSKs. such as PSKs.
In general, the safest way for clients to minimize ECH retries is to In general, the safest way for clients to minimize ECH retries is to
comply with any freshness rules (e.g., DNS TTLs) imposed by the ECH comply with any freshness rules (e.g., DNS TTLs) imposed by the ECH
configuration. configuration.
6.2. GREASE ECH 6.2. GREASE ECH
The GREASE ECH mechanism allows a connection between and ECH-capable The GREASE ECH mechanism allows a connection between an ECH-capable
client and a non-ECH server to appear to use ECH, thus reducing the client and a non-ECH server to appear to use ECH, thus reducing the
extent to which ECH connections stick out (see Section 10.10.4). extent to which ECH connections stick out (see Section 10.10.4).
6.2.1. Client Greasing 6.2.1. Client Greasing
If the client attempts to connect to a server and does not have an If the client attempts to connect to a server and does not have an
ECHConfig structure available for the server, it SHOULD send a GREASE ECHConfig structure available for the server, it SHOULD send a GREASE
[RFC8701] "encrypted_client_hello" extension in the first ClientHello [RFC8701] "encrypted_client_hello" extension in the first ClientHello
as follows: as follows:
* Set the config_id field to a random byte. * Set the config_id field to a random byte.
* Set the cipher_suite field to a supported * Set the cipher_suite field to a supported
HpkeSymmetricCipherSuite. The selection SHOULD vary to exercise HpkeSymmetricCipherSuite. The selection SHOULD vary to exercise
all supported configurations, but MAY be held constant for all supported configurations, but MAY be held constant for
successive connections to the same server in the same session. successive connections to the same server in the same session.
* Set the enc field to a randomly-generated valid encapsulated * Set the enc field to a randomly generated valid encapsulated
public key output by the HPKE KEM. public key output by the HPKE KEM.
* Set the payload field to a randomly-generated string of L+C bytes, * Set the payload field to a randomly generated string of L+C bytes,
where C is the ciphertext expansion of the selected AEAD scheme where C is the ciphertext expansion of the selected AEAD scheme
and L is the size of the EncodedClientHelloInner the client would and L is the size of the EncodedClientHelloInner the client would
compute when offering ECH, padded according to Section 6.1.3. compute when offering ECH, padded according to Section 6.1.3.
If sending a second ClientHello in response to a HelloRetryRequest, If sending a second ClientHello in response to a HelloRetryRequest,
the client copies the entire "encrypted_client_hello" extension from the client copies the entire "encrypted_client_hello" extension from
the first ClientHello. The identical value will reveal to an the first ClientHello. The identical value will reveal to an
observer that the value of "encrypted_client_hello" was fake, but observer that the value of "encrypted_client_hello" was fake, but
this only occurs if there is a HelloRetryRequest. this only occurs if there is a HelloRetryRequest.
skipping to change at page 25, line 24 skipping to change at line 1108
particular, the client MAY offer to resume sessions established particular, the client MAY offer to resume sessions established
without ECH. without ECH.
6.2.2. Server Greasing 6.2.2. Server Greasing
Section 11.3 describes a set of Reserved extensions which will never Section 11.3 describes a set of Reserved extensions which will never
be registered. These can be used by servers to "grease" the contents be registered. These can be used by servers to "grease" the contents
of the ECH configuration, as inspired by [RFC8701]. This helps of the ECH configuration, as inspired by [RFC8701]. This helps
ensure clients process ECH extensions correctly. When constructing ensure clients process ECH extensions correctly. When constructing
ECH configurations, servers SHOULD randomly select from reserved ECH configurations, servers SHOULD randomly select from reserved
values with the high-order bit clear. Correctly-implemented client values with the high-order bit clear. Correctly implemented clients
will ignore those extensions. will ignore those extensions.
The reserved values with the high-order bit set are mandatory, as The reserved values with the high-order bit set are mandatory, as
defined in Section 4.2. Servers SHOULD randomly select from these defined in Section 4.2. Servers SHOULD randomly select from these
values and include them in extraneous ECH configurations. Correctly- values and include them in extraneous ECH configurations. Correctly
implemented clients will ignore these configurations because they do implemented clients will ignore these configurations because they do
not recognize the mandatory extension. Servers SHOULD ensure that not recognize the mandatory extension. Servers SHOULD ensure that
any client using these configurations encounters a warning or error any client using these configurations encounters a warning or error
message. This can be accomplished in several ways, including: message. This can be accomplished in several ways, including:
* By giving the extraneous configurations distinctive config IDs or * By giving the extraneous configurations distinctive config IDs or
public names, and rejecting the TLS connection or inserting an public names, and rejecting the TLS connection or inserting an
application-level warning message when these are observed. application-level warning message when these are observed.
* By giving the extraneous configurations an invalid public key and * By giving the extraneous configurations an invalid public key and
a public name not associated with the server, so that the initial a public name not associated with the server so that the initial
ClientHelloOuter will not be decryptable and the server cannot ClientHelloOuter will not be decryptable and the server cannot
perform the recovery flow described in Section 6.1.6. perform the recovery flow described in Section 6.1.6.
7. Server Behavior 7. Server Behavior
As described in Section 3.1, servers can play two roles, either as As described in Section 3.1, servers can play two roles, either as
the client-facing server or as the back-end server. Depending on the the client-facing server or as the back-end server. Depending on the
server role, the ECHClientHello will be different: server role, the ECHClientHello will be different:
* A client-facing server expects a ECHClientHello.type of outer, and * A client-facing server expects an ECHClientHello.type of outer,
proceeds as described in Section 7.1 to extract a and proceeds as described in Section 7.1 to extract a
ClientHelloInner, if available. ClientHelloInner, if available.
* A backend server expects a ECHClientHello.type of inner, and * A backend server expects an ECHClientHello.type of inner, and
proceeds as described in Section 7.2. proceeds as described in Section 7.2.
In split mode, a client-facing server which receives a ClientHello In split mode, a client-facing server which receives a ClientHello
with ECHClientHello.type of inner MUST abort with an with ECHClientHello.type of inner MUST abort with an
"illegal_parameter" alert. Similarly, in split mode, a backend "illegal_parameter" alert. Similarly, in split mode, a backend
server which receives a ClientHello with ECHClientHello.type of outer server which receives a ClientHello with ECHClientHello.type of outer
MUST abort with an "illegal_parameter" alert. MUST abort with an "illegal_parameter" alert.
In shared mode, a server plays both roles, first decrypting the In shared mode, a server plays both roles, first decrypting the
ClientHelloOuter and then using the contents of the ClientHelloInner. ClientHelloOuter and then using the contents of the ClientHelloInner.
skipping to change at page 26, line 31 skipping to change at line 1164
If ECHClientHello.type is not a valid ECHClientHelloType, then the If ECHClientHello.type is not a valid ECHClientHelloType, then the
server MUST abort with an "illegal_parameter" alert. server MUST abort with an "illegal_parameter" alert.
If the "encrypted_client_hello" is not present, then the server If the "encrypted_client_hello" is not present, then the server
completes the handshake normally, as described in [RFC8446]. completes the handshake normally, as described in [RFC8446].
7.1. Client-Facing Server 7.1. Client-Facing Server
Upon receiving an "encrypted_client_hello" extension in an initial Upon receiving an "encrypted_client_hello" extension in an initial
ClientHello, the client-facing server determines if it will accept ClientHello, the client-facing server determines if it will accept
ECH, prior to negotiating any other TLS parameters. Note that ECH prior to negotiating any other TLS parameters. Note that
successfully decrypting the extension will result in a new successfully decrypting the extension will result in a new
ClientHello to process, so even the client's TLS version preferences ClientHello to process, so even the client's TLS version preferences
may have changed. may have changed.
First, the server collects a set of candidate ECHConfig values. This First, the server collects a set of candidate ECHConfig values. This
list is determined by one of the two following methods: list is determined by one of the two following methods:
1. Compare ECHClientHello.config_id against identifiers of each 1. Compare ECHClientHello.config_id against identifiers of each
known ECHConfig and select the ones that match, if any, as known ECHConfig and select the ones that match, if any, as
candidates. candidates.
skipping to change at page 27, line 32 skipping to change at line 1213
ClientHelloOuterAAD is computed from ClientHelloOuter as described in ClientHelloOuterAAD is computed from ClientHelloOuter as described in
Section 5.2. The info parameter to SetupBaseR is the concatenation Section 5.2. The info parameter to SetupBaseR is the concatenation
"tls ech", a zero byte, and the serialized ECHConfig. If decryption "tls ech", a zero byte, and the serialized ECHConfig. If decryption
fails, the server continues to the next candidate ECHConfig. fails, the server continues to the next candidate ECHConfig.
Otherwise, the server reconstructs ClientHelloInner from Otherwise, the server reconstructs ClientHelloInner from
EncodedClientHelloInner, as described in Section 5.1. It then stops EncodedClientHelloInner, as described in Section 5.1. It then stops
iterating over the candidate ECHConfig values. iterating over the candidate ECHConfig values.
Once the server has chosen the correct ECHConfig, it MAY verify that Once the server has chosen the correct ECHConfig, it MAY verify that
the value in the ClientHelloOuter "server_name" extension matches the the value in the ClientHelloOuter "server_name" extension matches the
value of ECHConfig.contents.public_name, and abort with an value of ECHConfig.contents.public_name and abort with an
"illegal_parameter" alert if these do not match. This optional check "illegal_parameter" alert if these do not match. This optional check
allows the server to limit ECH connections to only use the public SNI allows the server to limit ECH connections to only use the public SNI
values advertised in its ECHConfigs. The server MUST be careful not values advertised in its ECHConfigs. The server MUST be careful not
to unnecessarily reject connections if the same ECHConfig id or to unnecessarily reject connections if the same ECHConfig id or
keypair is used in multiple ECHConfigs with distinct public names. keypair is used in multiple ECHConfigs with distinct public names.
Upon determining the ClientHelloInner, the client-facing server Upon determining the ClientHelloInner, the client-facing server
checks that the message includes a well-formed checks that the message includes a well-formed
"encrypted_client_hello" extension of type inner and that it does not "encrypted_client_hello" extension of type inner and that it does not
offer TLS 1.2 or below. If either of these checks fails, the client- offer TLS 1.2 or below. If either of these checks fails, the client-
skipping to change at page 28, line 7 skipping to change at line 1237
ClientHelloInner to the appropriate backend server, which proceeds as ClientHelloInner to the appropriate backend server, which proceeds as
in Section 7.2. If the backend server responds with a in Section 7.2. If the backend server responds with a
HelloRetryRequest, the client-facing server forwards it, decrypts the HelloRetryRequest, the client-facing server forwards it, decrypts the
client's second ClientHelloOuter using the procedure in client's second ClientHelloOuter using the procedure in
Section 7.1.1, and forwards the resulting second ClientHelloInner. Section 7.1.1, and forwards the resulting second ClientHelloInner.
The client-facing server forwards all other TLS messages between the The client-facing server forwards all other TLS messages between the
client and backend server unmodified. client and backend server unmodified.
Otherwise, if all candidate ECHConfig values fail to decrypt the Otherwise, if all candidate ECHConfig values fail to decrypt the
extension, the client-facing server MUST ignore the extension and extension, the client-facing server MUST ignore the extension and
proceed with the connection using ClientHelloOuter, with the proceed with the connection using ClientHelloOuter with the following
following modifications: modifications:
* If sending a HelloRetryRequest, the server MAY include an * If sending a HelloRetryRequest, the server MAY include an
"encrypted_client_hello" extension with a payload of 8 random "encrypted_client_hello" extension with a payload of 8 random
bytes; see Section 10.10.4 for details. bytes; see Section 10.10.4 for details.
* If the server is configured with any ECHConfigs, it MUST include * If the server is configured with any ECHConfigs, it MUST include
the "encrypted_client_hello" extension in its EncryptedExtensions the "encrypted_client_hello" extension in its EncryptedExtensions
with the "retry_configs" field set to one or more ECHConfig with the "retry_configs" field set to one or more ECHConfig
structures with up-to-date keys. Servers MAY supply multiple structures with up-to-date keys. Servers MAY supply multiple
ECHConfig values of different versions. This allows a server to ECHConfig values of different versions. This allows a server to
skipping to change at page 28, line 36 skipping to change at line 1266
can measure occurrences of the "ech_required" alert to detect this can measure occurrences of the "ech_required" alert to detect this
case. case.
7.1.1. Sending HelloRetryRequest 7.1.1. Sending HelloRetryRequest
After sending or forwarding a HelloRetryRequest, the client-facing After sending or forwarding a HelloRetryRequest, the client-facing
server does not repeat the steps in Section 7.1 with the second server does not repeat the steps in Section 7.1 with the second
ClientHelloOuter. Instead, it continues with the ECHConfig selection ClientHelloOuter. Instead, it continues with the ECHConfig selection
from the first ClientHelloOuter as follows: from the first ClientHelloOuter as follows:
If the client-facing server accepted ECH, it checks the second If the client-facing server accepted ECH, it checks that the second
ClientHelloOuter also contains the "encrypted_client_hello" ClientHelloOuter also contains the "encrypted_client_hello"
extension. If not, it MUST abort the handshake with a extension. If not, it MUST abort the handshake with a
"missing_extension" alert. Otherwise, it checks that "missing_extension" alert. Otherwise, it checks that
ECHClientHello.cipher_suite and ECHClientHello.config_id are ECHClientHello.cipher_suite and ECHClientHello.config_id are
unchanged, and that ECHClientHello.enc is empty. If not, it MUST unchanged, and that ECHClientHello.enc is empty. If not, it MUST
abort the handshake with an "illegal_parameter" alert. abort the handshake with an "illegal_parameter" alert.
Finally, it decrypts the new ECHClientHello.payload as a second Finally, it decrypts the new ECHClientHello.payload as a second
message with the previous HPKE context: message with the previous HPKE context:
skipping to change at page 31, line 15 skipping to change at line 1385
Beyond coordination difficulties, ECH deployments may also induce Beyond coordination difficulties, ECH deployments may also induce
challenges for use cases of information that ECH protects. In challenges for use cases of information that ECH protects. In
particular, use cases which depend on this unencrypted information particular, use cases which depend on this unencrypted information
may no longer work as desired. This is elaborated upon in may no longer work as desired. This is elaborated upon in
Section 8.2. Section 8.2.
8.1. Compatibility Issues 8.1. Compatibility Issues
Unlike most TLS extensions, placing the SNI value in an ECH extension Unlike most TLS extensions, placing the SNI value in an ECH extension
is not interoperable with existing servers, which expect the value in is not interoperable with existing servers, which expect the value in
the existing plaintext extension. Thus server operators SHOULD the existing plaintext extension. Thus, server operators SHOULD
ensure servers understand a given set of ECH keys before advertising ensure servers understand a given set of ECH keys before advertising
them. Additionally, servers SHOULD retain support for any them. Additionally, servers SHOULD retain support for any previously
previously-advertised keys for the duration of their validity. advertised keys for the duration of their validity.
However, in more complex deployment scenarios, this may be difficult However, in more complex deployment scenarios, this may be difficult
to fully guarantee. Thus this protocol was designed to be robust in to fully guarantee. Thus, this protocol was designed to be robust in
case of inconsistencies between systems that advertise ECH keys and case of inconsistencies between systems that advertise ECH keys and
servers, at the cost of extra round-trips due to a retry. Two servers, at the cost of extra round-trips due to a retry. Two
specific scenarios are detailed below. specific scenarios are detailed below.
8.1.1. Misconfiguration and Deployment Concerns 8.1.1. Misconfiguration and Deployment Concerns
It is possible for ECH advertisements and servers to become It is possible for ECH advertisements and servers to become
inconsistent. This may occur, for instance, from DNS inconsistent. This may occur, for instance, from DNS
misconfiguration, caching issues, or an incomplete rollout in a misconfiguration, caching issues, or an incomplete rollout in a
multi-server deployment. This may also occur if a server loses its multi-server deployment. This may also occur if a server loses its
skipping to change at page 32, line 5 skipping to change at line 1421
present a certificate valid for the public name, the client can present a certificate valid for the public name, the client can
safely retry with updated settings, as described in Section 6.1.6. safely retry with updated settings, as described in Section 6.1.6.
Unless ECH is disabled as a result of successfully establishing a Unless ECH is disabled as a result of successfully establishing a
connection to the public name, the client MUST NOT fall back to using connection to the public name, the client MUST NOT fall back to using
unencrypted ClientHellos, as this allows a network attacker to unencrypted ClientHellos, as this allows a network attacker to
disclose the contents of this ClientHello, including the SNI. It MAY disclose the contents of this ClientHello, including the SNI. It MAY
attempt to use another server from the DNS results, if one is attempt to use another server from the DNS results, if one is
provided. provided.
In order to ensure that the retry mechanism works successfully In order to ensure that the retry mechanism works successfully,
servers SHOULD ensure that every endpoint which might receive a TLS servers SHOULD ensure that every endpoint which might receive a TLS
connection is provisioned with an appropriate certificate for the connection is provisioned with an appropriate certificate for the
public name. This is especially important during periods of server public name. This is especially important during periods of server
reconfiguration when different endpoints might have different reconfiguration when different endpoints might have different
configurations. configurations.
8.1.2. Middleboxes 8.1.2. Middleboxes
The requirements in [RFC8446], Section 9.3 which require proxies to The requirements in [RFC8446], Section 9.3 which require proxies to
act as conforming TLS client and server provide interoperability with act as conforming TLS client and server provide interoperability with
TLS-terminating proxies even in cases where the server supports ECH TLS-terminating proxies even in cases where the server supports ECH
but the proxy does not, as detailed below. but the proxy does not, as detailed below.
The proxy must ignore unknown parameters, and generate its own The proxy must ignore unknown parameters and generate its own
ClientHello containing only parameters it understands. Thus, when ClientHello containing only parameters it understands. Thus, when
presenting a certificate to the client or sending a ClientHello to presenting a certificate to the client or sending a ClientHello to
the server, the proxy will act as if connecting to the the server, the proxy will act as if connecting to the
ClientHelloOuter server_name, which SHOULD match the public name (see ClientHelloOuter server_name, which SHOULD match the public name (see
Section 6.1), without echoing the "encrypted_client_hello" extension. Section 6.1) without echoing the "encrypted_client_hello" extension.
Depending on whether the client is configured to accept the proxy's Depending on whether the client is configured to accept the proxy's
certificate as authoritative for the public name, this may trigger certificate as authoritative for the public name, this may trigger
the retry logic described in Section 6.1.6 or result in a connection the retry logic described in Section 6.1.6 or result in a connection
failure. A proxy which is not authoritative for the public name failure. A proxy which is not authoritative for the public name
cannot forge a signal to disable ECH. cannot forge a signal to disable ECH.
8.2. Deployment Impact 8.2. Deployment Impact
Some use cases which depend on information ECH encrypts may break Some use cases which depend on information ECH encrypts may break
skipping to change at page 34, line 5 skipping to change at line 1510
between the client-facing and backend servers when running ECH in between the client-facing and backend servers when running ECH in
Split Mode. However, for Split Mode in particular, ECH makes two Split Mode. However, for Split Mode in particular, ECH makes two
additional assumptions: additional assumptions:
1. The channel between each client-facing and each backend server is 1. The channel between each client-facing and each backend server is
authenticated such that the backend server only accepts messages authenticated such that the backend server only accepts messages
from trusted client-facing servers. The exact mechanism for from trusted client-facing servers. The exact mechanism for
establishing this authenticated channel is out of scope for this establishing this authenticated channel is out of scope for this
document. document.
2. The attacker cannot correlate messages between client and client- 2. The attacker cannot correlate messages between a client and
facing server with messages between client-facing and backend client-facing server with messages between client-facing and
server. Such correlation could allow an attacker to link backend server. Such correlation could allow an attacker to link
information unique to a backend server, such as their server name information unique to a backend server, such as their server name
or IP address, with a client's encrypted ClientHelloInner. or IP address, with a client's encrypted ClientHelloInner.
Correlation could occur through timing analysis of messages Correlation could occur through timing analysis of messages
across the client-facing server, or via examining the contents of across the client-facing server, or via examining the contents of
messages sent between client-facing and backend servers. The messages sent between client-facing and backend servers. The
exact mechanism for preventing this sort of correlation is out of exact mechanism for preventing this sort of correlation is out of
scope for this document. scope for this document.
Given this threat model, the primary goals of ECH are as follows. Given this threat model, the primary goals of ECH are as follows.
skipping to change at page 34, line 45 skipping to change at line 1550
deploy ECH in such a way so as to maximize the size of the anonymity deploy ECH in such a way so as to maximize the size of the anonymity
set where possible. This means client-facing servers should use the set where possible. This means client-facing servers should use the
same ECHConfig for as many server names as possible. An attacker can same ECHConfig for as many server names as possible. An attacker can
distinguish two server names that have different ECHConfig values distinguish two server names that have different ECHConfig values
based on the ECHClientHello.config_id value. based on the ECHClientHello.config_id value.
This also means public information in a TLS handshake should be This also means public information in a TLS handshake should be
consistent across server names. For example, if a client-facing consistent across server names. For example, if a client-facing
server services many backend origin server names, only one of which server services many backend origin server names, only one of which
supports some cipher suite, it may be possible to identify that supports some cipher suite, it may be possible to identify that
server name based on the contents of unencrypted handshake message. server name based on the contents of the unencrypted handshake
Similarly, if a backend origin reuses KeyShare values, then that message. Similarly, if a backend origin reuses KeyShare values, then
provides a unique identifier for that server. that provides a unique identifier for that server.
Beyond these primary security and privacy goals, ECH also aims to Beyond these primary security and privacy goals, ECH also aims to
hide, to some extent, the fact that it is being used at all. hide, to some extent, the fact that it is being used at all.
Specifically, the GREASE ECH extension described in Section 6.2 does Specifically, the GREASE ECH extension described in Section 6.2 does
not change the security properties of the TLS handshake at all. Its not change the security properties of the TLS handshake at all. Its
goal is to provide "cover" for the real ECH protocol (Section 6.1), goal is to provide "cover" for the real ECH protocol (Section 6.1),
as a means of addressing the "do not stick out" requirements of as a means of addressing the "do not stick out" requirements of
[RFC8744]. See Section 10.10.4 for details. [RFC8744]. See Section 10.10.4 for details.
10.2. Unauthenticated and Plaintext DNS 10.2. Unauthenticated and Plaintext DNS
ECH supports delivery of configurations through the DNS using SVCB or ECH supports delivery of configurations through the DNS using SVCB or
HTTPS records, without requiring any verifiable authenticity or HTTPS records without requiring any verifiable authenticity or
provenance information [ECH-IN-DNS]. This means that any attacker provenance information [RFCYYY1]. This means that any attacker which
which can inject DNS responses or poison DNS caches, which is a can inject DNS responses or poison DNS caches, which is a common
common scenario in client access networks, can supply clients with scenario in client access networks, can supply clients with fake ECH
fake ECH configurations (so that the client encrypts data to them) or configurations (so that the client encrypts data to them) or strip
strip the ECH configurations from the response. However, in the face the ECH configurations from the response. However, in the face of an
of an attacker that controls DNS, no encryption scheme can work attacker that controls DNS, no encryption scheme can work because the
because the attacker can replace the IP address, thus blocking client attacker can replace the IP address, thus blocking client
connections, or substitute a unique IP address for each DNS name that connections, or substitute a unique IP address for each DNS name that
was looked up. Thus, using DNS records without additional was looked up. Thus, using DNS records without additional
authentication does not make the situation significantly worse. authentication does not make the situation significantly worse.
Clearly, DNSSEC (if the client validates and hard fails) is a defense Clearly, DNSSEC (if the client validates and hard fails) is a defense
against this form of attack, but encrypted DNS transport is also a against this form of attack, but encrypted DNS transport is also a
defense against DNS attacks by attackers on the local network, which defense against DNS attacks by attackers on the local network, which
is a common case where ClientHello and SNI encryption are desired. is a common case where ClientHello and SNI encryption are desired.
Moreover, as noted in the introduction, SNI encryption is less useful Moreover, as noted in the introduction, SNI encryption is less useful
without encryption of DNS queries in transit. without encryption of DNS queries in transit.
skipping to change at page 37, line 34 skipping to change at line 1679
should take such side channels into consideration when reasoning should take such side channels into consideration when reasoning
about the privacy properties that ECH provides. about the privacy properties that ECH provides.
10.7. Related Privacy Leaks 10.7. Related Privacy Leaks
ECH requires encrypted DNS to be an effective privacy protection ECH requires encrypted DNS to be an effective privacy protection
mechanism. However, verifying the server's identity from the mechanism. However, verifying the server's identity from the
Certificate message, particularly when using the X509 Certificate message, particularly when using the X509
CertificateType, may result in additional network traffic that may CertificateType, may result in additional network traffic that may
reveal the server identity. Examples of this traffic may include reveal the server identity. Examples of this traffic may include
requests for revocation information, such as OCSP or CRL traffic, or requests for revocation information, such as Online Certificate
requests for repository information, such as Status Protocol (OCSP) or Certificate Revocation List (CRL) traffic,
or requests for repository information, such as
authorityInformationAccess. It may also include implementation- authorityInformationAccess. It may also include implementation-
specific traffic for additional information sources as part of specific traffic for additional information sources as part of
verification. verification.
Implementations SHOULD avoid leaking information that may identify Implementations SHOULD avoid leaking information that may identify
the server. Even when sent over an encrypted transport, such the server. Even when sent over an encrypted transport, such
requests may result in indirect exposure of the server's identity, requests may result in indirect exposure of the server's identity,
such as indicating a specific CA or service being used. To mitigate such as indicating a specific CA or service being used. To mitigate
this risk, servers SHOULD deliver such information in-band when this risk, servers SHOULD deliver such information in-band when
possible, such as through the use of OCSP stapling, and clients possible, such as through the use of OCSP stapling, and clients
skipping to change at page 38, line 28 skipping to change at line 1723
Backend servers in an anonymity set SHOULD NOT reveal information in Backend servers in an anonymity set SHOULD NOT reveal information in
the cookie which identifies the server. This may be done by handling the cookie which identifies the server. This may be done by handling
HelloRetryRequest statefully, thus not sending cookies, or by using HelloRetryRequest statefully, thus not sending cookies, or by using
the same cookie construction for all backend servers. the same cookie construction for all backend servers.
Note that, if the cookie includes a key name, analogous to Section 4 Note that, if the cookie includes a key name, analogous to Section 4
of [RFC5077], this may leak information if different backend servers of [RFC5077], this may leak information if different backend servers
issue cookies with different key names at the time of the connection. issue cookies with different key names at the time of the connection.
In particular, if the deployment operates in Split Mode, the backend In particular, if the deployment operates in Split Mode, the backend
servers may not share cookie encryption keys. Backend servers may servers may not share cookie encryption keys. Backend servers may
mitigate this by either handling key rotation with trial decryption, mitigate this either by handling key rotation with trial decryption
or coordinating to match key names. or by coordinating to match key names.
10.9. Attacks Exploiting Acceptance Confirmation 10.9. Attacks Exploiting Acceptance Confirmation
To signal acceptance, the backend server overwrites 8 bytes of its To signal acceptance, the backend server overwrites 8 bytes of its
ServerHello.random with a value derived from the ServerHello.random with a value derived from the
ClientHelloInner.random. (See Section 7.2 for details.) This ClientHelloInner.random. (See Section 7.2 for details.) This
behavior increases the likelihood of the ServerHello.random colliding behavior increases the likelihood of the ServerHello.random colliding
with the ServerHello.random of a previous session, potentially with the ServerHello.random of a previous session, potentially
reducing the overall security of the protocol. However, the reducing the overall security of the protocol. However, the
remaining 24 bytes provide enough entropy to ensure this is not a remaining 24 bytes provide enough entropy to ensure this is not a
skipping to change at page 39, line 13 skipping to change at line 1756
connection failures in practice. connection failures in practice.
Note that the same bytes of the ServerHello.random are used to Note that the same bytes of the ServerHello.random are used to
implement downgrade protection for TLS 1.3 (see [RFC8446], implement downgrade protection for TLS 1.3 (see [RFC8446],
Section 4.1.3). These mechanisms do not interfere because the Section 4.1.3). These mechanisms do not interfere because the
backend server only signals ECH acceptance in TLS 1.3 or higher. backend server only signals ECH acceptance in TLS 1.3 or higher.
10.10. Comparison Against Criteria 10.10. Comparison Against Criteria
[RFC8744] lists several requirements for SNI encryption. In this [RFC8744] lists several requirements for SNI encryption. In this
section, we re-iterate these requirements and assess the ECH design section, we reiterate these requirements and assess the ECH design
against them. against them.
10.10.1. Mitigate Cut-and-Paste Attacks 10.10.1. Mitigate Cut-and-Paste Attacks
Since servers process either ClientHelloInner or ClientHelloOuter, Since servers process either ClientHelloInner or ClientHelloOuter,
and because ClientHelloInner.random is encrypted, it is not possible and because ClientHelloInner.random is encrypted, it is not possible
for an attacker to "cut and paste" the ECH value in a different for an attacker to "cut and paste" the ECH value in a different
Client Hello and learn information from ClientHelloInner. Client Hello and learn information from ClientHelloInner.
10.10.2. Avoid Widely Shared Secrets 10.10.2. Avoid Widely Shared Secrets
skipping to change at page 40, line 20 skipping to change at line 1811
ECH looks enough like GREASE ECH, then ECH should be deployable as ECH looks enough like GREASE ECH, then ECH should be deployable as
well. Thus, the strategy for mitigating network ossification is to well. Thus, the strategy for mitigating network ossification is to
deploy GREASE ECH widely enough to disincentivize differential deploy GREASE ECH widely enough to disincentivize differential
treatment of the real ECH protocol by the network. treatment of the real ECH protocol by the network.
Ensuring that networks do not differentiate between real ECH and Ensuring that networks do not differentiate between real ECH and
GREASE ECH may not be feasible for all implementations. While most GREASE ECH may not be feasible for all implementations. While most
middleboxes will not treat them differently, some operators may wish middleboxes will not treat them differently, some operators may wish
to block real ECH usage but allow GREASE ECH. This specification to block real ECH usage but allow GREASE ECH. This specification
aims to provide a baseline security level that most deployments can aims to provide a baseline security level that most deployments can
achieve easily, while providing implementations enough flexibility to achieve easily while providing implementations enough flexibility to
achieve stronger security where possible. Minimally, real ECH is achieve stronger security where possible. Minimally, real ECH is
designed to be indifferentiable from GREASE ECH for passive designed to be indifferentiable from GREASE ECH for passive
adversaries with following capabilities: adversaries with following capabilities:
1. The attacker does not know the ECHConfigList used by the server. 1. The attacker does not know the ECHConfigList used by the server.
2. The attacker keeps per-connection state only. In particular, it 2. The attacker keeps per-connection state only. In particular, it
does not track endpoints across connections. does not track endpoints across connections.
Moreover, real ECH and GREASE ECH are designed so that the following Moreover, real ECH and GREASE ECH are designed so that the following
skipping to change at page 42, line 47 skipping to change at line 1934
ServerHello ServerHello
+ key_share + key_share
{EncryptedExtensions} {EncryptedExtensions}
{CertificateRequest*} {CertificateRequest*}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
<------ <------
Alert Alert
------> ------>
Figure 3: Client reaction attack Figure 3: Client Reaction Attack
ClientHelloInner.random prevents this attack. In particular, since ClientHelloInner.random prevents this attack. In particular, since
the attacker does not have access to this value, it cannot produce the attacker does not have access to this value, it cannot produce
the right transcript and handshake keys needed for encrypting the the right transcript and handshake keys needed for encrypting the
Certificate message. Thus, the client will fail to decrypt the Certificate message. Thus, the client will fail to decrypt the
Certificate and abort the connection. Certificate and abort the connection.
10.12.2. HelloRetryRequest Hijack Mitigation 10.12.2. HelloRetryRequest Hijack Mitigation
This attack aims to exploit server HRR state management to recover This attack aims to exploit server HRR state management to recover
skipping to change at page 43, line 48 skipping to change at line 1979
ServerHello ServerHello
+ key_share + key_share
{EncryptedExtensions} {EncryptedExtensions}
{CertificateRequest*} {CertificateRequest*}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} {Finished}
<------- <-------
(process server flight) (process server flight)
Figure 4: HelloRetryRequest hijack attack Figure 4: HelloRetryRequest Hijack Attack
This attack is mitigated by using the same HPKE context for both This attack is mitigated by using the same HPKE context for both
ClientHello messages. The attacker does not possess the context's ClientHello messages. The attacker does not possess the context's
keys, so it cannot generate a valid encryption of the second inner keys, so it cannot generate a valid encryption of the second inner
ClientHello. ClientHello.
If the attacker could manipulate the second ClientHello, it might be If the attacker could manipulate the second ClientHello, it might be
possible for the server to act as an oracle if it required parameters possible for the server to act as an oracle if it required parameters
from the first ClientHello to match that of the second ClientHello. from the first ClientHello to match that of the second ClientHello.
For example, imagine the client's original SNI value in the inner For example, imagine the client's original SNI value in the inner
skipping to change at page 45, line 31 skipping to change at line 2041
+ ech_outer_extensions(pre_shared_key) + ech_outer_extensions(pre_shared_key)
+ pre_shared_key' + pre_shared_key'
--------> -------->
Alert Alert
-or- -or-
ServerHello ServerHello
... ...
Finished Finished
<-------- <--------
Figure 5: Message flow for malleable ClientHello Figure 5: Message Flow for Malleable ClientHello
This attack may be generalized to any parameter which the server This attack may be generalized to any parameter which the server
varies by server name, such as ALPN preferences. varies by server name, such as ALPN preferences.
ECH mitigates this attack by only negotiating TLS parameters from ECH mitigates this attack by only negotiating TLS parameters from
ClientHelloInner and authenticating all inputs to the ClientHelloInner and authenticating all inputs to the
ClientHelloInner (EncodedClientHelloInner and ClientHelloOuter) with ClientHelloInner (EncodedClientHelloInner and ClientHelloOuter) with
the HPKE AEAD. See Section 5.2. The decompression process in the HPKE AEAD. See Section 5.2. The decompression process in
Section 5.1 forbids "encrypted_client_hello" in OuterExtensions. Section 5.1 forbids "encrypted_client_hello" in OuterExtensions.
This ensures the unauthenticated portion of ClientHelloOuter is not This ensures the unauthenticated portion of ClientHelloOuter is not
skipping to change at page 46, line 13 skipping to change at line 2071
to decompress or may be much larger than the incoming packet: to decompress or may be much larger than the incoming packet:
* If looking up a ClientHelloOuter extension takes time linear in * If looking up a ClientHelloOuter extension takes time linear in
the number of extensions, the overall decoding process would take the number of extensions, the overall decoding process would take
O(M*N) time, where M is the number of extensions in O(M*N) time, where M is the number of extensions in
ClientHelloOuter and N is the size of OuterExtensions. ClientHelloOuter and N is the size of OuterExtensions.
* If the same ClientHelloOuter extension can be copied multiple * If the same ClientHelloOuter extension can be copied multiple
times, an attacker could cause the client-facing server to times, an attacker could cause the client-facing server to
construct a large ClientHelloInner by including a large extension construct a large ClientHelloInner by including a large extension
in ClientHelloOuter, of length L, and an OuterExtensions list in ClientHelloOuter of length L and an OuterExtensions list
referencing N copies of that extension. The client-facing server referencing N copies of that extension. The client-facing server
would then use O(N*L) memory in response to O(N+L) bandwidth from would then use O(N*L) memory in response to O(N+L) bandwidth from
the client. In split-mode, an O(N*L) sized packet would then be the client. In split-mode, an O(N*L)-sized packet would then be
transmitted to the backend server. transmitted to the backend server.
ECH mitigates this attack by requiring that OuterExtensions be ECH mitigates this attack by requiring that OuterExtensions be
referenced in order, that duplicate references be rejected, and by referenced in order, that duplicate references be rejected, and by
recommending that client-facing servers use a linear scan to perform recommending that client-facing servers use a linear scan to perform
decompression. These requirements are detailed in Section 5.1. decompression. These requirements are detailed in Section 5.1.
11. IANA Considerations 11. IANA Considerations
11.1. Update of the TLS ExtensionType Registry 11.1. Update of the TLS ExtensionType Registry
IANA is requested to create the following entries in the existing IANA has created the following entries in the existing "TLS
registry for ExtensionType (defined in [RFC8446]): ExtensionType Values" registry (defined in [RFC8446]):
1. encrypted_client_hello(0xfe0d), with "TLS 1.3" column values set 1. encrypted_client_hello (0xfe0d), with "TLS 1.3" column values set
to "CH, HRR, EE", "DTLS-Only" column set to "N", and to "CH, HRR, EE", "DTLS-Only" column set to "N", and
"Recommended" column set to "Yes". "Recommended" column set to "Y".
2. ech_outer_extensions(0xfd00), with the "TLS 1.3" column values 2. ech_outer_extensions (0xfd00), with the "TLS 1.3" column values
set to "CH", "DTLS-Only" column set to "N", "Recommended" column set to "CH", "DTLS-Only" column set to "N", "Recommended" column
set to "Yes", and the "Comment" column set to "Only appears in set to "Y", and the "Comment" column set to "Only appears in
inner CH." inner CH."
11.2. Update of the TLS Alert Registry 11.2. Update of the TLS Alert Registry
IANA is requested to create an entry, ech_required(121) in the IANA has created an entry, ech_required (121) in the existing "TLS
existing registry for Alerts (defined in [RFC8446]), with the "DTLS- Alerts" registry (defined in [RFC8446]), with the "DTLS-OK" column
OK" column set to "Y". set to "Y".
11.3. ECH Configuration Extension Registry 11.3. ECH Configuration Extension Registry
IANA is requested to create a new "ECHConfig Extension" registry in a IANA has created a new "TLS ECHConfig Extension" registry in a new
new "TLS Encrypted Client Hello (ECH) Configuration Extensions" page. "TLS Encrypted Client Hello (ECH) Configuration Extensions" registry
New registrations need to list the following attributes: group. New registrations will list the following attributes:
Value: The two-byte identifier for the ECHConfigExtension, i.e., the Value: The two-byte identifier for the ECHConfigExtension, i.e., the
ECHConfigExtensionType ECHConfigExtensionType
Extension Name: Name of the ECHConfigExtension Extension Name: Name of the ECHConfigExtension
Recommended: A "Y" or "N" value indicating if the extension is TLS Recommended: A "Y" or "N" value indicating if the extension is TLS
WG recommends that the extension be supported. This column is WG recommends that the extension be supported. This column is
assigned a value of "N" unless explicitly requested. Adding a assigned a value of "N" unless explicitly requested. Adding a
value with a value of "Y" requires Standards Action [RFC8126]. value with a value of "Y" requires Standards Action [RFC8126].
Reference: The specification where the ECHConfigExtension is defined Reference: The specification where the ECHConfigExtension is defined
Notes: Any notes associated with the entry Notes: Any notes associated with the entry
New entries in the "ECHConfig Extension" registry are subject to the New entries in the "TLS ECHConfig Extension" registry are subject to
Specification Required registration policy ([RFC8126], Section 4.6), the Specification Required registration policy ([RFC8126],
with the policies described in [RFC8447], Section 17. IANA [shall Section 4.6), with the policies described in [RFC8447], Section 17.
add/has added] the following note to the TLS ECHConfig Extension IANA has added the following note to the "TLS ECHConfig Extension"
registry: registry:
Note: The role of the designated expert is described in RFC 8447. Note: The role of the designated expert is described in RFC 8447.
The designated expert [RFC8126] ensures that the specification is The designated expert [RFC8126] ensures that the specification is
publicly available. It is sufficient to have an Internet-Draft (that publicly available. It is sufficient to have an Internet-Draft (that
is posted and never published as an RFC) or a document from another is posted and never published as an RFC) or a document from another
standards body, industry consortium, university site, etc. The standards body, industry consortium, university site, etc. The
expert may provide more in depth reviews, but their approval should expert may provide more in-depth reviews, but their approval should
not be taken as an endorsement of the extension. not be taken as an endorsement of the extension.
This document defines several Reserved values for ECH configuration This document defines several Reserved values for ECH configuration
extensions to be used for "greasing" as described in Section 6.2.2. extensions to be used for "greasing" as described in Section 6.2.2.
The initial contents for this registry consists of multiple reserved The initial contents for this registry consists of multiple reserved
values, with the following attributes, which are repeated for each values with the following attributes, which are repeated for each
registration: registration:
Value: 0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, Value: 0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A,
0x7A7A, 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, 0x7A7A, 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA,
0xFAFA 0xFAFA
Extension Name: RESERVED Extension Name: RESERVED
Recommended: Y Recommended: Y
Reference: This document Reference: RFC 9849
Notes: Grease entries. Notes: Grease entries
12. References 12. References
12.1. Normative References 12.1. Normative References
[ECH-IN-DNS]
Schwartz, B. M., Bishop, M., and E. Nygren, "Bootstrapping
TLS Encrypted ClientHello with DNS Service Bindings", Work
in Progress, Internet-Draft, draft-ietf-tls-svcb-ech-07,
12 February 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-tls-svcb-ech-07>.
[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid [HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>. February 2022, <https://www.rfc-editor.org/info/rfc9180>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/rfc/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/rfc/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", RFC 7918, Layer Security (TLS) False Start", RFC 7918,
DOI 10.17487/RFC7918, August 2016, DOI 10.17487/RFC7918, August 2016,
<https://www.rfc-editor.org/rfc/rfc7918>. <https://www.rfc-editor.org/info/rfc7918>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/rfc/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/rfc/rfc9147>. <https://www.rfc-editor.org/info/rfc9147>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460, Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>. November 2023, <https://www.rfc-editor.org/info/rfc9460>.
[RFCYYY1] Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping
TLS Encrypted ClientHello with DNS Service Bindings",
RFC YYY1, DOI 10.17487/RFCYYY1, November 2025,
<https://www.rfc-editor.org/info/rfcYYY1>.
12.2. Informative References 12.2. Informative References
[DNS-TERMS] [DNS-TERMS]
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024, RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/rfc/rfc9499>. <https://www.rfc-editor.org/info/rfc9499>.
[ECH-Analysis] [ECH-Analysis]
"A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Bhargavan, K., Cheval, V., and C. Wood, "A Symbolic
Client Hello", November 2022, Analysis of Privacy for TLS 1.3 with Encrypted Client
Hello", CCS '22: Proceedings of the 2022 ACM SIGSAC
Conference on Computer and Communications Security, pp.
365-379, DOI 10.1145/3548606.3559360, November 2022,
<https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW- <https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-
ccs22.pdf>. ccs22.pdf>.
[I-D.kazuho-protected-sni] [PROTECTED-SNI]
Oku, K., "TLS Extensions for Protecting SNI", Work in Oku, K., "TLS Extensions for Protecting SNI", Work in
Progress, Internet-Draft, draft-kazuho-protected-sni-00, Progress, Internet-Draft, draft-kazuho-protected-sni-00,
18 July 2017, <https://datatracker.ietf.org/doc/html/ 18 July 2017, <https://datatracker.ietf.org/doc/html/
draft-kazuho-protected-sni-00>. draft-kazuho-protected-sni-00>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/rfc/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/rfc/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/rfc/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924, (TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016, DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/rfc/rfc7924>. <https://www.rfc-editor.org/info/rfc7924>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/rfc/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC8701] Benjamin, D., "Applying Generate Random Extensions And [RFC8701] Benjamin, D., "Applying Generate Random Extensions And
Sustain Extensibility (GREASE) to TLS Extensibility", Sustain Extensibility (GREASE) to TLS Extensibility",
RFC 8701, DOI 10.17487/RFC8701, January 2020, RFC 8701, DOI 10.17487/RFC8701, January 2020,
<https://www.rfc-editor.org/rfc/rfc8701>. <https://www.rfc-editor.org/info/rfc8701>.
[RFC8744] Huitema, C., "Issues and Requirements for Server Name [RFC8744] Huitema, C., "Issues and Requirements for Server Name
Identification (SNI) Encryption in TLS", RFC 8744, Identification (SNI) Encryption in TLS", RFC 8744,
DOI 10.17487/RFC8744, July 2020, DOI 10.17487/RFC8744, July 2020,
<https://www.rfc-editor.org/rfc/rfc8744>. <https://www.rfc-editor.org/info/rfc8744>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250, Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022, DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/rfc/rfc9250>. <https://www.rfc-editor.org/info/rfc9250>.
[WHATWG-IPV4] [WHATWG-IPV4]
"URL Living Standard - IPv4 Parser", May 2021, WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May
<https://url.spec.whatwg.org/#concept-ipv4-parser>. 2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>.
Appendix A. Linear-time Outer Extension Processing Appendix A. Linear-Time Outer Extension Processing
The following procedure processes the "ech_outer_extensions" The following procedure processes the "ech_outer_extensions"
extension (see Section 5.1) in linear time, ensuring that each extension (see Section 5.1) in linear time, ensuring that each
referenced extension in the ClientHelloOuter is included at most referenced extension in the ClientHelloOuter is included at most
once: once:
1. Let I be initialized to zero and N be set to the number of 1. Let I be initialized to zero and N be set to the number of
extensions in ClientHelloOuter. extensions in ClientHelloOuter.
2. For each extension type, E, in OuterExtensions: 2. For each extension type, E, in OuterExtensions:
skipping to change at page 51, line 14 skipping to change at line 2315
* While I is less than N and the I-th extension of * While I is less than N and the I-th extension of
ClientHelloOuter does not have type E, increment I. ClientHelloOuter does not have type E, increment I.
* If I is equal to N, abort the connection with an * If I is equal to N, abort the connection with an
"illegal_parameter" alert and terminate this procedure. "illegal_parameter" alert and terminate this procedure.
* Otherwise, the I-th extension of ClientHelloOuter has type E. * Otherwise, the I-th extension of ClientHelloOuter has type E.
Copy it to the EncodedClientHelloInner and increment I. Copy it to the EncodedClientHelloInner and increment I.
Appendix B. Acknowledgements Acknowledgements
This document draws extensively from ideas in
[I-D.kazuho-protected-sni], but is a much more limited mechanism
because it depends on the DNS for the protection of the ECH key.
Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince,
Nick Sullivan, Martin Thomson, and David Benjamin also provided
important ideas and contributions.
Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-tls-esni-16
* Keep-alive
C.2. Since draft-ietf-tls-esni-15
* Add CCS2022 reference and summary (#539)
C.3. Since draft-ietf-tls-esni-14
* Keep-alive
C.4. Since draft-ietf-tls-esni-13
* Editorial improvements
C.5. Since draft-ietf-tls-esni-12
* Abort on duplicate OuterExtensions (#514)
* Improve EncodedClientHelloInner definition (#503)
* Clarify retry configuration usage (#498)
* Expand on config_id generation implications (#491)
* Server-side acceptance signal extension GREASE (#481)
* Refactor overview, client implementation, and middlebox sections
(#480, #478, #475, #508)
* Editorial iprovements (#485, #488, #490, #495, #496, #499, #500,
#501, #504, #505, #507, #510, #511)
C.6. Since draft-ietf-tls-esni-11
* Move ClientHello padding to the encoding (#443)
* Align codepoints (#464)
* Relax OuterExtensions checks for alignment with RFC8446 (#467)
* Clarify HRR acceptance and rejection logic (#470)
* Editorial improvements (#468, #465, #462, #461)
C.7. Since draft-ietf-tls-esni-10
* Make HRR confirmation and ECH acceptance explicit (#422, #423)
* Relax computation of the acceptance signal (#420, #449)
* Simplify ClientHelloOuterAAD generation (#438, #442)
* Allow empty enc in ECHClientHello (#444)
* Authenticate ECHClientHello extensions position in
ClientHelloOuterAAD (#410)
* Allow clients to send a dummy PSK and early_data in
ClientHelloOuter when applicable (#414, #415)
* Compress ECHConfigContents (#409)
* Validate ECHConfig.contents.public_name (#413, #456)
* Validate ClientHelloInner contents (#411)
* Note split-mode challenges for HRR (#418)
* Editorial improvements (#428, #432, #439, #445, #458, #455)
C.8. Since draft-ietf-tls-esni-09
* Finalize HPKE dependency (#390)
* Move from client-computed to server-chosen, one-byte config
identifier (#376, #381)
* Rename ECHConfigs to ECHConfigList (#391)
* Clarify some security and privacy properties (#385, #383) This document draws extensively from ideas in [PROTECTED-SNI], but is
a much more limited mechanism because it depends on the DNS for the
protection of the ECH key. Richard Barnes, Christian Huitema,
Patrick McManus, Matthew Prince, Nick Sullivan, Martin Thomson, and
David Benjamin also provided important ideas and contributions.
Authors' Addresses Authors' Addresses
Eric Rescorla Eric Rescorla
Independent Independent
Email: ekr@rtfm.com Email: ekr@rtfm.com
Kazuho Oku Kazuho Oku
Fastly Fastly
Email: kazuhooku@gmail.com Email: kazuhooku@gmail.com
 End of changes. 123 change blocks. 
368 lines changed or deleted 261 lines changed or added

This html diff was produced by rfcdiff 1.48.