Movatterモバイル変換

---title: TLS Encrypted Client Helloabbrev: TLS Encrypted Client Hellodocname: draft-ietf-tls-esni-25category: stdnumber: 9849ipr: trust200902submissiontype: IETFupdates:obsoletes:date:consensus: truev: 3area: SECworkgroup: tlskeyword:stand_alone: yespi: [toc, sortrefs, symrefs]author: -     name: Eric Rescorla       ins: E. Rescorla       org: Independent       email: ekr@rtfm.com - Kazuho Oku       org: Fastly       email: kazuhooku@gmail.com -     name: Nick Sullivan       ins: N. Sullivan       org: Cryptography Consulting LLC       email: nicholas.sullivan+ietf@gmail.com -     name: Christopher A. Wood       ins: C. A. Wood       org:       email: caw@heapingbits.netnormative:  RFC2119:  RFC7918:  RFCYYY1:    title: >      Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings    target: https://www.rfc-editor.org/info/rfcYYY1    seriesinfo:      RFC: YYY1      DOI: 10.17487/RFCYYY1    date: 2025    author:      -        ins: B. Schwartz        surname: Schwartz        fullname: Benjamin M. Schwartz      -        ins: M. Bishop        surname: Bishop        fullname: Mike Bishop      -        ins: E. Nygren        surname: Nygren        fullname: Erik Nygren  WHATWG-IPV4:   author:   -     org: WHATWG   title: "URL - IPv4 Parser"   target: https://url.spec.whatwg.org/#concept-ipv4-parser   date: May 2021   refcontent:     "WHATWG Living Standard"  ECH-Analysis:    title: "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello"    target: https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf    date: November 2022    seriesinfo:      DOI: 10.1145/3548606.3559360    refcontent:      "CCS '22: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pp. 365-379"    author:      -        ins: K. Bhargavan        org: Inria      -        ins: V. Cheval        org: Inria      -        ins: C. Wood        org: Cloudflare  RFC9499:     display: DNS-TERMS  I-D.kazuho-protected-sni:     display: PROTECTED-SNI--- abstract<!-- [rfced] Referencesa) Regarding [WHATWG-IPV4], this reference's date is May 2021.The URL provided resolves to a page with "Last Updated 12 May 2025".Note that WHATWG provides "commit snapshots" of their living standards andthere are several commit snapshots from May 2021 with the latest being from 20May 2021. For example: 20 May 2021(https://url.spec.whatwg.org/commit-snapshots/1b8b8c55eb4bed9f139c9a439fb1c1bf5566b619/#concept-ipv4-parser)We recommend updating this reference to the most current version of the WHATWGLiving Standard, replacing the URL with the more general URL to the standard(https://url.spec.whatwg.org/), and adding a "commit snapshot" URL to thereference.Current:[WHATWG-IPV4]           WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May           2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>.d) FYI, RFCYYY1 (draft-ietf-tls-svcb-ech) will be updated during the XML stage.--><!-- [rfced] Please insert any keywords (beyond those that appear inthe title) for use on https://www.rfc-editor.org/search. -->This document describes a mechanism in Transport Layer Security (TLS) forencrypting a message under a server public key.--- middle# Introduction {#intro}Although TLS 1.3 {{!RFC8446}} encrypts most of the handshake, including theserver certificate, there are several ways in which an on-path attacker canlearn private information about the connection. The plaintext Server NameIndication (SNI) extension in messages, which leaks the targetdomain for a given connection, is perhaps the most sensitive informationleft unencrypted in TLS 1.3.This document specifies a new TLS extension called Encrypted ClientHello (ECH) that allows clients to encrypt their to theTLS server.  This protects the SNI and other potentially sensitivefields, such as the Application-Layer Protocol Negotiation (ALPN) list{{?RFC7301}}. Co-located servers with consistent externally visibleTLS configurations and behavior, including supported versions and cipher suites andhow they respond to incoming client connections, form an anonymity set. (Notethat implementation-specific choices, such as extension ordering within TLSmessages or division of data into record-layer boundaries, can result indifferent externally visible behavior, even for servers with consistent TLSconfigurations.) Usage of this mechanism reveals that a client is connectingto a particular service provider, but does not reveal which server from theanonymity set terminates the connection. Deployment implications of thisfeature are discussed in {{deployment}}.ECH is not in itself sufficient to protect the identity of the server.The target domain may also be visible through other channels, such asplaintext client DNS queries or visible server IP addresses. However,encrypted DNS mechanisms such asDNS over HTTPS {{?RFC8484}}, DNS over TLS/DTLS {{?RFC7858}} {{?RFC8094}}, andDNS over QUIC {{?RFC9250}}provide mechanisms for clients to concealDNS lookups from network inspection, and many TLS servers host multiple domainson the same IP address. Private origins may also be deployed behind a commonprovider, such as a reverse proxy. In such environments, the SNI remains theprimary explicit signal available to observers to determine theserver's identity.ECH is supported in TLS 1.3 {{!RFC8446}}, DTLS 1.3 {{!RFC9147}}, andnewer versions of the TLS and DTLS protocols.# Conventions and DefinitionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD","SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in thisdocument are to be interpreted as described in BCP 14 {{RFC2119}} {{!RFC8174}}when, and only when, they appear in all capitals, as shown here. All TLSnotation comes from {{RFC8446, Section 3}}.# OverviewThis protocol is designed to operate in one of two topologies illustrated below,which we call "Shared Mode" and "Split Mode". These modes are described in thefollowing section.## Topologies                +---------------------+                |                     |                |   2001:DB8::1111    |                |                     |Client <----->  | private.example.org |                |                     |                | public.example.com  |                |                     |                +---------------------+                        Server          (Client-Facing and Backend Combined){: #shared-mode title="Shared Mode Topology"}In the provider is the origin server for all the domains whose DNSrecords point to it. In this mode, the TLS connection is terminated by theprovider.           +--------------------+     +---------------------+           |                    |     |                     |           |   2001:DB8::1111   |     |   2001:DB8::EEEE    |Client <----------------------------->|                     |           | public.example.com |     | private.example.org |           |                    |     |                     |           +--------------------+     +---------------------+            Client-Facing Server            Backend Server{: #split-mode title="Split Mode Topology"}In the provider is not the origin server for private domains.Rather, the DNS records for private domains point to the provider, and theprovider's server relays the connection back to the origin server, whoterminates the TLS connection with the client. Importantly, the service providerdoes not have access to the plaintext of the connection beyond the unencryptedportions of the handshake.In the remainder of this document, we will refer to the ECH-service provider asthe "client-facing server" and the TLS terminator as the "backend server".These are the same entity in but in the client-facingand backend servers are physically separated.See {{security-considerations}} for more discussion about the ECH threat modeland how it relates to the client, client-facing server, and backend server.## Encrypted ClientHello (ECH)A client-facing server enables ECH by publishing an ECH configuration, whichis an encryption public key and associated metadata. Domains which wish touse ECH must publish this configuration, using the key associatedwith the client-facing server. This documentdefines the ECH configuration's format, but delegates DNS publication detailsto {{!RFC9460}}. See{{RFCYYY1}} for specifics about how ECH configurationsare advertised in SVCB and HTTPS records. Other delivery mechanisms arealso possible. For example, the client may have the ECH configurationpreconfigured.When a client wants to establish a TLS session with some backend server, itconstructs a private referred to as theThe client then constructs a public referred to as the The contains innocuous values forsensitive extensions and an "encrypted_client_hello" extension({{encrypted-client-hello}}), which carries the encryptedFinally, the client sends to the server.The server takes one of the following actions:1. If it does not support ECH or cannot decrypt the extension, it completes   the handshake with This is referred to as rejecting ECH.1. If it successfully decrypts the extension, it forwards the   to the backend server, which completes the handshake. This is referred to   as accepting ECH.Upon receiving the server's response, the client determines whether or not ECHwas accepted ({{determining-ech-acceptance}}) and proceeds with the handshakeaccordingly. When ECH is rejected, the resulting connection is not usable bythe client for application data. Instead, ECH rejection allows the client toretry with up-to-date configuration ({{rejected-ech}}).The primary goal of ECH is to ensure that connections to servers in the sameanonymity set are indistinguishable from one another. Moreover, it shouldachieve this goal without affecting any existing security properties of TLS 1.3.See {{goals}} for more details about the ECH security and privacy goals.# Encrypted ClientHello Configuration {#ech-configuration}ECH uses Hybrid Public Key Encryption (HPKE) for public key encryption {{RFC9180}}.The ECH configuration is defined by the following `ECHConfig` structure.    opaque HpkePublicKey<1..2^16-1>;    uint16 HpkeKemId;              // Defined in RFC 9180    uint16 HpkeKdfId;              // Defined in RFC 9180    uint16 HpkeAeadId;             // Defined in RFC 9180    uint16 ECHConfigExtensionType; // Defined in Section 11.3    struct {        HpkeKdfId kdf_id;        HpkeAeadId aead_id;    } HpkeSymmetricCipherSuite;    struct {        uint8 config_id;        HpkeKemId kem_id;        HpkePublicKey public_key;        HpkeSymmetricCipherSuite cipher_suites<4..2^16-4>;    } HpkeKeyConfig;    struct {        ECHConfigExtensionType type;        opaque data<0..2^16-1>;    } ECHConfigExtension;    struct {        HpkeKeyConfig key_config;        uint8 maximum_name_length;        opaque public_name<1..255>;        ECHConfigExtension extensions<0..2^16-1>;    } ECHConfigContents;    struct {        uint16 version;        uint16 length;        select (ECHConfig.version) {          case 0xfe0d: ECHConfigContents contents;        }    } ECHConfig;The structure contains the following fields:version:: The version of ECH for which this configuration is used. The versionis the same as the code point for the"encrypted_client_hello" extension. Clients MUST ignore any `ECHConfig`structure with a version they do not support.length:: The length, in bytes, of the next field. This length field allowsimplementations to skip over the elements in such a list where they cannotparse the specific version ofcontents:: An opaque byte string whose contents depend on the version. For thisspecification, the contents are an `ECHConfigContents` structure.The `ECHConfigContents` structure contains the following fields:key_config:: A `HpkeKeyConfig` structure carrying the configuration informationassociated with the HPKE public key (an "ECH key"). Note that thisstructure contains the `config_id` field, which applies to the entire: The longest name of a backend server, if known. If not known, this value canbe set to zero. It is used to compute padding ({{padding}}) and does notconstrain server name lengths. Names may exceed this length if, e.g.,the server uses wildcard names or added new names to the anonymity set.public_name:: The DNS name of the client-facing server, i.e., the entity trustedto update the ECH configuration. This is used to correct misconfigured clients,as described in {{rejected-ech}}.: See {{auth-public-name}} for how the client interprets and validates thepublic_name.extensions:: A list of ECHConfigExtension values that the client must take intoconsideration when generating a message. Each ECHConfigExtensionhas a 2-octet type and opaque data value, where the data value is encodedwith a 2-octet integer representing the length of the data, in network byteorder. ECHConfigExtension values are described below ({{config-extensions}}).The `HpkeKeyConfig` structure contains the following fields:: A one-byte identifier for the given HPKE key configuration. This is used byclients to indicate the key used for encryption. {{config-ids}}describes how client-facing servers allocate this value.kem_id:: The HPKE Key Encapsulation Mechanism (KEM) identifier correspondingto `public_key`. Clients MUST ignore any `ECHConfig` structure with akey using a KEM they do not support.: The HPKE public key used by the client to encryptcipher_suites:: The list of HPKE Key Derivation Function (KDF) and Authenticated Encryption with Associated Data (AEAD) identifier pairs clients can use for encrypting See {{real-ech}} for how clients choose from this list.The client-facing server advertises a sequence of ECH configurations to clients,serialized as follows.    ECHConfig ECHConfigList<4..2^16-1>;The `ECHConfigList` structure contains one or more `ECHConfig` structures indecreasing order of preference. This allows a server to support multipleversions of ECH and multiple sets of ECH parameters.## Configuration Identifiers {#config-ids}A client-facing server has a set of known values with correspondingprivate keys. This set SHOULD contain the currently published values, as well asprevious values that may still be in use, since clients may cache DNS recordsup to a TTL or longer.{{client-facing-server}} describes a trial decryption process for decrypting the This can impact performance when the client-facing server maintainsmany known values. To avoid this, the client-facing server SHOULDallocate distinct `config_id` values for each in its known set. TheRECOMMENDED strategy is via rejection sampling, i.e., to randomly select`config_id` repeatedly until it does not match any knownIt is not necessary for `config_id` values across different client-facingservers to be distinct. A backend server may be hosted behind two differentclient-facing servers with colliding `config_id` values without any performanceimpact. Values may also be reused if the previous is no longer in theknown set.## Configuration Extensions {#config-extensions}ECH configuration extensions are used to provide room for additionalfunctionality as needed. The format is as defined in{{ech-configuration}} and mirrors {{Section 4.2 of RFC8446}}. However,ECH configuration extension types are maintained by IANA as describedin {{config-extensions-iana}}.  ECH configuration extensions followthe same interpretation rules as TLS extensions: extensions MAY appearin any order, but there MUST NOT be more than one extension of thesame type in the extensions block. Unlike TLS extensions, an extensioncan be tagged as mandatory by using an extension type codepoint withthe high order bit set to 1.Clients MUST parse the extension list and check for unsupported mandatoryextensions. If an unsupported mandatory extension is present, clients MUSTignore the `ECHConfig`.Any future information or hints that influence SHOULD bespecified as extensions. This is primarily because the outer exists only in support of ECH. Namely, it is both an envelope forthe encrypted inner and an enabler for authenticated key mismatchsignals (see {{server-behavior}}). In contrast, the inner is thetrue used upon ECH negotiation.# The "encrypted_client_hello" Extension {#encrypted-client-hello}To offer ECH, the client sends an "encrypted_client_hello" extension in the When it does, it MUST also send the extension in    enum {       encrypted_client_hello(0xfe0d), (65535)    } ExtensionType;The payload of the extension has the following structure:    enum { outer(0), inner(1) } ECHClientHelloType;    struct {       ECHClientHelloType type;       select (ECHClientHello.type) {           case outer:               HpkeSymmetricCipherSuite cipher_suite;               uint8 config_id;               opaque enc<0..2^16-1>;               opaque payload<1..2^16-1>;           case inner:               Empty;       };    } ECHClientHello;The outer extension uses the `outer` variant and the inner extension uses the`inner` variant. The inner extension has an empty payload, which is includedbecause TLS servers are not allowed to provide extensions in ServerHellowhich were not included in The outer extension has the followingfields:: The for the chosen: The cipher suite used to encrypt This MUST match a valueprovided in the corresponding `ECHConfigContents.cipher_suites` list.enc:: The HPKE encapsulated key used by servers to decrypt the corresponding`payload` field. This field is empty in a sent in response toHelloRetryRequest.payload:: The serialized and encrypted structure, encryptedusing HPKE as described in {{real-ech}}.When a client offers the `outer` version of an "encrypted_client_hello"extension, the server MAY include an "encrypted_client_hello" extension in itsEncryptedExtensions message, as described in {{client-facing-server}}, with thefollowing payload:    struct {       ECHConfigList retry_configs;    } ECHEncryptedExtensions;The response is valid only when the server used the If theserver sent this extension in response to the `inner` variant, then the clientMUST abort with an "unsupported_extension" alert.retry_configs:: An structure containing one or more structures, indecreasing order of preference, to be used by the client as described in{{rejected-ech}}. These are known as the server's "retry configurations".Finally, when the client offers the "encrypted_client_hello", if the payload isthe `inner` variant and the server responds with HelloRetryRequest, it MUSTinclude an "encrypted_client_hello" extension with the following payload:    struct {       opaque confirmation[8];    } ECHHelloRetryRequest;The value of ECHHelloRetryRequest.confirmation is set to`hrr_accept_confirmation` as described in {{backend-server-hrr}}.This document also defines the "ech_required" alert, which the client MUST sendwhen it offered an "encrypted_client_hello" extension that was not accepted bythe server. (See {{alerts}}.)## Encoding the ClientHelloInner {#encoding-inner}Before encrypting, the client pads and optionally compressesinto an structure, defined below:    struct {        ClientHello client_hello;        uint8 zeros[length_of_padding];    } EncodedClientHelloInner;The `client_hello` field is computed by first making a copy ofand setting the `legacy_session_id` field to the empty string. In TLS, thisfield uses the structure defined in {{Section 4.1.2 of RFC8446}}.In DTLS, it uses the defined in{{Section 5.3 of RFC9147}}. This does not include Handshake structure'sfour-byte header in TLS, nor twelve-byte header in DTLS. The `zeros` field MUSTbe all zeroes of length `length_of_padding` (see {{padding}}).Repeating large extensions, such as "key_share" with post-quantum algorithms,between and can lead to excessive size. Toreduce the size impact, the client MAY substitute extensions which it knowswill be duplicated in It does so by removing and replacingextensions from with a single "ech_outer_extensions"extension, defined as follows:    enum {       ech_outer_extensions(0xfd00), (65535)    } ExtensionType;    ExtensionType OuterExtensions<2..254>;OuterExtensions contains the removed ExtensionType values. Each value referencesthe matching extension in The values MUST be orderedcontiguously in and the "ech_outer_extensions" extension MUSTbe inserted in the corresponding position inAdditionally, the extensions MUST appear in in the samerelative order. However, there is no requirement that they be contiguous. Forexample, OuterExtensions may contain extensions A, B, and C, whilecontains extensions A, D, B, C, E, and F.The "ech_outer_extensions" extension can only be included in and MUST NOT appear in either orFinally, the client pads the message by setting the `zeros` field to a bytestring whose contents are all zeros and whose length is the amount of paddingto add. {{padding}} describes a recommended padding scheme.The client-facing server computes by reversing this process.First, it parses interpreting all bytes after`client_hello` as padding. If any padding byte is non-zero, the server MUSTabort the connection with an "illegal_parameter" alert.Next, it makes a copy of the `client_hello` field and copies the`legacy_session_id` field from It then looks for an"ech_outer_extensions" extension. If found, it replaces the extension with thecorresponding sequence of extensions in the The server MUSTabort the connection with an "illegal_parameter" alert if any of the followingare true:* Any referenced extension is missing in* Any extension is referenced in OuterExtensions more than once.* "encrypted_client_hello" is referenced in OuterExtensions.* The extensions in corresponding to those in OuterExtensions  do not occur in the same order.These requirements prevent an attacker from performing a packet amplificationattack by crafting a which decompresses to a much larger This is discussed further in {{decompression-amp}}.Implementations SHOULD construct the in lineartime. Quadratic time implementations (such as may happen via naivecopying) create a denial-of-service risk.{{linear-outer-extensions}} describes a linear-time procedure that may be usedfor this purpose.## Authenticating the ClientHelloOuter {#authenticating-outer}To prevent a network attacker from modifying the `ClientHelloOuter`while keeping the same encrypted `ClientHelloInner`(see {{flow-clienthello-malleability}}), ECH authenticatesby passing as the associated data for HPKE sealingand opening operations. The is a serialized structure, defined in {{Section 4.1.2 of RFC8446}} for TLS and{{Section 5.3 of RFC9147}} for DTLS, which matches the exceptthat the `payload` field of the "encrypted_client_hello" is replaced with a bytestring of the same length but whose contents are zeros. This value does notinclude Handshake structure's four-byte header in TLS nor twelve-byte header inDTLS.# Client BehaviorClients that implement the ECH extension behave in one of two ways: either theyoffer a real ECH extension, as described in {{real-ech}}, or they send aGenerate Random Extensions And Sustain Extensibility (GREASE) {{?RFC8701}}ECH extension, as described in {{grease-ech}}. Clients of the latter type do notnegotiate ECH. Instead, they generate a dummy ECH extension that is ignored bythe server. (See {{dont-stick-out}} for an explanation.) The client offers ECHif it is in possession of a compatible ECH configuration and sends GREASE ECH(see {{grease-ech}}) otherwise.## Offering ECH {#real-ech}To offer ECH, the client first chooses a suitable from the server's To determine if a given `ECHConfig` is suitable, it checks thatit supports the KEM algorithm identified by `ECHConfig.contents.kem_id`, atleast one KDF/AEAD algorithm identified by `ECHConfig.contents.cipher_suites`,and the version of ECH indicated by Once asuitable configuration is found, the client selects the cipher suite it willuse for encryption. It MUST NOT choose a cipher suite or version not advertisedby the configuration. If no compatible configuration is found, then the clientSHOULD proceed as described in {{grease-ech}}.Next, the client constructs the message just as it does astandard with the exception of the following rules:1. It MUST NOT offer to negotiate TLS 1.2 or below. This is necessary to ensure   the backend server does not negotiate a TLS version that is incompatible with   ECH.1. It MUST NOT offer to resume any session for TLS 1.2 and below.1. If it intends to compress any extensions (see {{encoding-inner}}), it MUST   order those extensions consecutively.1. It MUST include the "encrypted_client_hello" extension of type `inner` as   described in {{encrypted-client-hello}}. (This requirement is not applicable   when the "encrypted_client_hello" extension is generated as described in   {{grease-ech}}.)The client then constructs as described in{{encoding-inner}}. It also computes an HPKE encryption context and `enc` valueas:    pkR = DeserializePublicKey(ECHConfig.contents.public_key)    enc, context = SetupBaseS(pkR,                              "tls ech" || 0x00 || ECHConfig)Next, it constructs a partial as it does a standard with the exception of the following rules:1. It MUST offer to negotiate TLS 1.3 or above.1. If it compressed any extensions in it MUST copy the   corresponding extensions from The copied extensions   additionally MUST be in the same relative order as in1. It MUST copy the legacy\_session\_id field from This   allows the server to echo the correct session ID for TLS 1.3's compatibility   mode (see {{Appendix D.4 of RFC8446}}) when ECH is negotiated. Note that   compatibility mode is not used in DTLS 1.3, but following this rule will   produce the correct results for both TLS 1.3 and DTLS 1.3.1. It MAY copy any other field from the except Instead, MUST generate a fresh using a secure random number generator. (See   {{flow-client-reaction}}.)1. It SHOULD place the value of `ECHConfig.contents.public_name` in the   "server_name" extension. Clients that do not follow this step, or place a   different value in the "server_name" extension, risk breaking the retry   mechanism described in {{rejected-ech}} or failing to interoperate with   servers that require this step to be done; see {{client-facing-server}}.1. When the client offers the "pre_shared_key" extension in it   SHOULD also include a GREASE "pre_shared_key" extension in   generated in the manner described in {{grease-psk}}. The client MUST NOT use   this extension to advertise a to the client-facing server. (See   {{flow-clienthello-malleability}}.) When the client includes a GREASE   "pre_shared_key" extension, it MUST also copy the "psk_key_exchange_modes"   from the into the1. When the client offers the "early_data" extension in it   MUST also include the "early_data" extension in This   allows servers that reject ECH and use to safely ignore any   early data sent by the client per {{RFC8446, Section 4.2.10}}.The client might duplicate non-sensitive extensions in both messages. However,implementations need to take care to ensure that sensitive extensions are notoffered in the See {{outer-clienthello}} for additionalguidance.Finally, the client encrypts the with the above values,as described in {{encrypting-clienthello}}, to construct a Itsends this to the server and processes the response as described in{{determining-ech-acceptance}}.### Encrypting the ClientHello {#encrypting-clienthello}Given an an HPKE encryption context and `enc` value,and a partial the client constructs a asfollows.First, the client determines the length L of encryptingwith the selected HPKE AEAD. This is typically the sum of the plaintext lengthand the AEAD tag length. The client then completes the withan "encrypted_client_hello" extension. This extension value contains the outervariant of with the following fields:- `config_id`, the identifier corresponding to the chosen structure;- `cipher_suite`, the client's chosen cipher suite;- `enc`, as given above; and- `payload`, a placeholder byte string containing L zeros.If configuration identifiers (see {{ignored-configs}}) are to beignored, `config_id` SHOULD be set to a randomly generated byte in thefirst and, in the event of a HelloRetryRequest (HRR),MUST be left unchanged for the secondThe client serializes this structure to construct theIt then computes the final payload as:    final_payload = context.Seal(ClientHelloOuterAAD,                                 EncodedClientHelloInner)Including `ClientHelloOuterAAD` as the HPKE AAD binds the `ClientHelloOuter`to the `ClientHelloInner`, thus preventing attackers from modifying`ClientHelloOuter` while keeping the same `ClientHelloInner`, as described in{{flow-clienthello-malleability}}.Finally, the client replaces `payload` with `final_payload` to obtain The two values have the same length, so it is not necessaryto recompute length prefixes in the serialized structure.Note this construction requires the "encrypted_client_hello" be computed afterall other extensions. This is possible because the"pre_shared_key" extension is either omitted or uses a random binder({{grease-psk}}).### GREASE PSK {#grease-psk}When offering ECH, the client is not permitted to advertise PSK identities inthe However, the client can send a "pre_shared_key" extensionin the In this case, when resuming a session with the client,the backend server sends a "pre_shared_key" extension in its ServerHello. Thiswould appear to a network observer as if the server were sending thisextension without solicitation, which would violate the extension rulesdescribed in {{RFC8446}}. When offering a PSK inclients SHOULD send a GREASE "pre_shared_key" extension in the to make it appear to the network as if the extension werenegotiated properly.The client generates the extension payload by constructing an `OfferedPsks`structure (see {{RFC8446, Section 4.2.11}}) as follows. For each PSK identityadvertised in the the client generates a random PSK identitywith the same length. It also generates a random, 32-bit, unsigned integer touse as the `obfuscated_ticket_age`. Likewise, for each inner PSK binder, theclient generates a random string of the same length.Per the rules of {{real-ech}}, the server is not permitted to resume aconnection in the outer handshake. If ECH is rejected and the client-facingserver replies with a "pre_shared_key" extension in its ServerHello, then theclient MUST abort the handshake with an "illegal_parameter" alert.### Recommended Padding Scheme {#padding}If the is encrypted without padding, then the length ofthe `ClientHelloOuter.payload` can leak information about `ClientHelloInner`.In order to prevent this, the `EncodedClientHelloInner` structurehas a padding field. This section describes a deterministic mechanism forcomputing the required amount of padding based on the followingobservation: individual extensions can reveal sensitive information throughtheir length. Thus, each extension in the inner may requiredifferent amounts of padding. This padding may be fully determined by theclient's configuration or may require server input.By way of example, clients typically support a small number of applicationprofiles. For instance, a browser might support HTTP with ALPN values["http/1.1", "h2"] and WebRTC media with ALPNs ["webrtc", "c-webrtc"]. ClientsSHOULD pad this extension by rounding up to the total size of the longest ALPNextension across all application profiles. The target padding length of most extensions can be computed in this way.In contrast, clients do not know the longest SNI value in the client-facingserver's anonymity set without server input. Clients SHOULD use the`maximum_name_length` field as follows, where is the `maximum_name_length`value.1. If the contained a "server_name" extension with a name of   length D, add max(0, - D) bytes of padding.2. If the did not contain a "server_name" extension (e.g., if   the client is connecting to an IP address), add + 9 bytes of padding. This   is the length of a "server_name" extension with an name.Finally, the client SHOULD pad the entire message as follows:1. Let L be the length of the with all the padding   computed so far.2. Let N = 31 - ((L - 1) % 32) and add N bytes of padding.This rounds the length of up to a multiple of 32 bytes,reducing the set of possible lengths across all clients.In addition to padding clients and servers will also need topad all other handshake messages that have sensitive-length fields. For example,if a client proposes ALPN values in the server-selected valuewill be returned in an EncryptedExtension, so that handshake message also needsto be padded using TLS record layer padding.### Determining ECH Acceptance {#determining-ech-acceptance}As described in {{server-behavior}}, the server may either accept ECH and use or reject it and use This is determined bythe server's initial message.If the message does not negotiate TLS 1.3 or higher, the server has rejectedECH. Otherwise, it is either a ServerHello or HelloRetryRequest.If the message is a ServerHello, the client computes `accept_confirmation` asdescribed in {{backend-server}}. If this value matches the last 8 bytes of`ServerHello.random`, the server has accepted ECH. Otherwise, it has rejectedECH.If the message is a HelloRetryRequest, the client checks for the"encrypted_client_hello" extension. If none is found, the server has rejectedECH. Otherwise, if it has a length other than 8, the client aborts the handshakewith a "decode_error" alert. Otherwise, the client computes`hrr_accept_confirmation` as described in {{backend-server-hrr}}. If this valuematches the extension payload, the server has accepted ECH. Otherwise, it hasrejected ECH.If the server accepts ECH, the client handshakes with asdescribed in {{accepted-ech}}. Otherwise, the client handshakes with as described in {{rejected-ech}}.<!-- [rfced] In the following sentence, does "length other than 8" refer tobytes? If yes, may we update as follows?Current:Otherwise, if it has a length other than 8, the client aborts thehandshake with a "decode_error" alert.Perhaps:Otherwise, if it has a length other than 8 bytes, the client abortsthe handshake with a "decode_error" alert.  -->### Handshaking with ClientHelloInner {#accepted-ech}If the server accepts ECH, the client proceeds with the connection as in{{RFC8446}}, with the following modifications:The client behaves as if it had sent as the Thatis, it evaluates the handshake using the preferences, and,when computing the transcript hash ({{Section 4.4.1 of RFC8446}}), it uses as the firstIf the server responds with a HelloRetryRequest, the client computes the updated message as follows:1. It computes a second based on the first as   in {{Section 4.1.4 of RFC8446}}. The   "encrypted_client_hello" extension is left unmodified.1. It constructs as described in {{encoding-inner}}.1. It constructs a second partial message. This message MUST   be syntactically valid. The extensions MAY be copied from the original unmodified or omitted. If not sensitive, the client MAY   copy updated extensions from the second for compression.1. It encrypts as described in   {{encrypting-clienthello}}, using the second partial to   obtain a second It reuses the original HPKE encryption   context computed in {{real-ech}} and uses the empty string for `enc`.   The HPKE context maintains a sequence number, so this operation internally   uses a fresh nonce for each AEAD operation. Reusing the HPKE context avoids   an attack described in {{flow-hrr-hijack}}.The client then sends the second to the server. However, asabove, it uses the second for preferences, and both the messages for the transcript hash. Additionally, it checks theresulting ServerHello for ECH acceptance as in {{determining-ech-acceptance}}.If the ServerHello does not also indicate ECH acceptance, the client MUSTterminate the connection with an "illegal_parameter" alert.### Handshaking with ClientHelloOuter {#rejected-ech}If the server rejects ECH, the client proceeds with the handshake,authenticating for as described in{{auth-public-name}}. If authentication or the handshake fails, the client MUSTreturn a failure to the calling application. It MUST NOT use the retryconfigurations. It MUST NOT treat this as a secure signal todisable ECH.If the server supplied an "encrypted_client_hello" extension in itsEncryptedExtensions message, the client MUST check that it is syntacticallyvalid and the client MUST abort the connection with a "decode_error" alertotherwise. If an earlier TLS version was negotiated, the client MUST NOT enablethe False Start optimization {{RFC7918}} for this handshake. If bothauthentication and the handshake complete successfully, the client MUST performthe processing described below and then abort the connection with an "ech_required"alert before sending any application data to the server.If the server provided "retry_configs" and if at least one of thevalues contains a version supported by the client, the client canregard the ECH configuration as securely replaced by the server. ItSHOULD retry the handshake with a new transport connection using theretry configurations supplied by the server.Clients can implement a new transport connection in a way that bestsuits their deployment. For example, clients can reuse the same serverIP address when establishing the new transport connection or they canchoose to use a different IP address if provided with options fromDNS. ECH does not mandate any specific implementation choices whenestablishing this new connection.The retry configurations are meant to be used for retried connections. Furtheruse of retry configurations could yield a tracking vector. In settings wherethe client will otherwise already let the server track the client, e.g.,because the client will send cookies to the server in parallel connections,using the retry configurations for these parallel connections does notintroduce a new tracking vector.If none of the values provided in "retry_configs" contains a supportedversion, the server did not supply an "encrypted_client_hello"extension in its EncryptedExtensions message, or an earlier TLSversion was negotiated, the client can regard ECH as securely disabledby the server, and it SHOULD retry the handshake with a new transportconnection and ECH disabled.Clients SHOULD NOT accept "retry_config" in response to a connectioninitiated in response to a "retry_config".  Sending a "retry_config"in this situation is a signal that the server is misconfigured, e.g.,the server might have multiple inconsistent configurations so that theclient reached a node with configuration A in the first connection anda node with configuration B in the second. Note that this guidancedoes not apply to the cases in the previous paragraph where the serverhas securely disabled ECH.If a client does not retry, it MUST report an error to the callingapplication.### Authenticating for the Public Name {#auth-public-name}When the server rejects ECH, it continues with the handshake using the plaintext"server_name" extension instead (see {{server-behavior}}). that offerECH authenticate the connection with the public name as follows:- The client MUST verify that the certificate is valid for If invalid, it MUST abort the connection with  the appropriate alert.- If the server requests a client certificate, the client MUST respond with an  empty Certificate message, denoting no client certificate.In verifying the client-facing server certificate, the client MUSTinterpret the public name as a DNS-based reference identity Clients that incorporate DNS names and IP addresses intothe same syntax (e.g. {{Section 7.4 of ?RFC3986}} and {{WHATWG-IPV4}})MUST reject names that would be interpreted as IPv4 addresses.Clients that enforce this by checkingdo not need to repeat the check when processing ECH rejection.Note that authenticating a connection for the public name does not authenticateit for the origin. The TLS implementation MUST NOT report such connections assuccessful to the application. It additionally MUST ignore all session ticketsand session IDs presented by the server. These connections are only used totrigger retries, as described in {{rejected-ech}}. This may be implemented, forinstance, by reporting a failed connection with a dedicated error code.Prior to attempting a connection, a client SHOULD validate the `ECHConfig`.Clients SHOULD ignore any`ECHConfig` structure with a public_name that is not a valid host name inpreferred name syntax (see {{Section 2 of RFC9499}}).  That is, to bevalid, the public_name needs to be a dot-separated sequence of LDH labels, asdefined in {{Section 2.3.1 of !RFC5890}}, where:* the sequence does not begin or end with an ASCII dot, and* all labels are at most 63 octets.Clients additionally SHOULD ignore the structure if the final LDHlabel either consists of all ASCII digits (i.e., '0' through '9') or is"0x" or "0X" followed by some, possibly empty, sequence of ASCIIhexadecimal digits (i.e., '0' through '9', 'a' through 'f', and 'A'through 'F'). This avoids public_name values that may be interpretedas IPv4 literals.### Impact of Retry on Future ConnectionsClients MAY use information learned from a rejected ECH for futureconnections to avoid repeatedly connecting to the same server andbeing forced to retry. However, they MUST handle ECH rejection forthose connections as if it were a fresh connection, rather thanenforcing the single retry limit from {{rejected-ech}}. The reasonfor this requirement is that if the server sends a "retry_config"and then immediately rejects the resulting connection, it ismost likely misconfigured. However, if the server sends a "retry_config"and then the client tries to use that to connect some timelater, it is possible that the server has changedits configuration again and is now trying to recover.Any persisted information MUST be associated with the sourceused to bootstrap the connection, such as a DNS SVCB ServiceMode record{{RFCYYY1}}. Clients MUST limit any sharing of persisted ECH-relatedstate to connections that use the same source. Otherwise, itmight become possible for the client to have the wrong public name forthe server, making recovery impossible.ECHConfigs learned from ECH rejection can be used as a trackingvector. Clients SHOULD impose the same lifetime and scope restrictionsthat they apply to other server-basedtracking vectors such as PSKs.In general, the safest way for clients to minimize ECH retries is tocomply with any freshness rules (e.g., DNS TTLs) imposed by the ECHconfiguration.## GREASE ECH {#grease-ech}The GREASE ECH mechanism allows a connection between an ECH-capable clientand a non-ECH server to appear to use ECH, thus reducing the extent towhich ECH connections stick out (see {{dont-stick-out}}).### Client GreasingIf the client attempts to connect to a server and does not have anstructure available for the server, it SHOULD send a GREASE {{?RFC8701}}"encrypted_client_hello" extension in the first as follows:- Set the `config_id` field to a random byte.- Set the `cipher_suite` field to a supported HpkeSymmetricCipherSuite. The  selection SHOULD vary to exercise all supported configurations, but MAY be  held constant for successive connections to the same server in the same  session.- Set the `enc` field to a randomly generated valid encapsulated public key  output by the HPKE KEM.- Set the `payload` field to a randomly generated string of L+C bytes, where C  is the ciphertext expansion of the selected AEAD scheme and L is the size of  the the client would compute when offering ECH, padded  according to {{padding}}.If sending a second in response to a HelloRetryRequest, theclient copies the entire "encrypted_client_hello" extension from the first The identical value will reveal to an observer that the value of"encrypted_client_hello" was fake, but this only occurs if there is aHelloRetryRequest.If the server sends an "encrypted_client_hello" extension in eitherHelloRetryRequest or EncryptedExtensions, the client MUST check the extensionsyntactically and abort the connection with a "decode_error" alert if it isinvalid. It otherwise ignores the extension. It MUST NOT save the"retry_configs" value in EncryptedExtensions.Offering a GREASE extension is not considered offering an encryptedfor purposes of requirements in {{real-ech}}. In particular, the clientMAY offer to resume sessions established without ECH.<!-- [rfced] It seems that "client" was intended to be "clients" (plural) inthe sentence below and updated as follows. Please let us know if that is notaccurate.Original:Correctly-implemented client will ignore those extensions.Current:Correctly implemented clients will ignore those extensions.-->### Server Greasing{{config-extensions-iana}} describes a set of Reserved extensionswhich will never be registered. These can be used by servers to"grease" the contents of the ECH configuration, as inspired by{{?RFC8701}}. This helps ensure clients process ECH extensionscorrectly. When constructing ECH configurations, servers SHOULDrandomly select from reserved values with the high-order bitclear. Correctly implemented clients will ignore those extensions.The reserved values with the high-order bit set are mandatory, asdefined in {{config-extensions}}. Servers SHOULD randomly select fromthese values and include them in extraneous ECH configurations.Correctly implemented clients will ignore these configurations becausethey do not recognize the mandatory extension.  Servers SHOULD ensurethat any client using these configurations encounters a warning or errormessage.  This can be accomplished in several ways, including:* By giving the extraneous configurations distinctive config IDs or  public names, and rejecting the TLS connection or inserting an  application-level warning message when these are observed.* By giving the extraneous configurations an invalid public  key and a public name not associated with the server so that  the initial will not be decryptable and  the server cannot perform the recovery flow described  in {{rejected-ech}}.# Server Behavior {#server-behavior}As described in {{topologies}}, servers can play two roles, either asthe client-facing server or as the server.Depending on the server role, the `ECHClientHello` will be different:* A client-facing server expects an `ECHClientHello.type` of `outer`, and  proceeds as described in {{client-facing-server}} to extract a if available.* A backend server expects an `ECHClientHello.type` of `inner`, and  proceeds as described in {{backend-server}}.In split mode, a client-facing server which receives a `ClientHello`with `ECHClientHello.type` of `inner` MUST abort with an"illegal_parameter" alert. Similarly, in split mode, a backend serverwhich receives a `ClientHello` with `ECHClientHello.type` of `outer`MUST abort with an "illegal_parameter" alert.In shared mode, a server plays both roles, first decrypting the`ClientHelloOuter` and then using the contents of the`ClientHelloInner`.  A shared mode server which receives a`ClientHello` with `ECHClientHello.type` of `inner` MUST abort with an"illegal_parameter" alert, because such a `ClientHello` should neverbe received directly from the network.If `ECHClientHello.type` is not a valid `ECHClientHelloType`, thenthe server MUST abort with an "illegal_parameter" alert.If the "encrypted_client_hello" is not present, then the server completes thehandshake normally, as described in {{RFC8446}}.## Client-Facing Server {#client-facing-server}Upon receiving an "encrypted_client_hello" extension in an initial the client-facing server determines if it will accept ECH priorto negotiating any other TLS parameters. Note that successfully decrypting theextension will result in a new to process, so even the client's TLSversion preferences may have changed.First, the server collects a set of candidate values. This list isdetermined by one of the two following methods:1. Compare against identifiers of each known   and select the ones that match, if any, as candidates.2. Collect all known values as candidates, with trial decryption   below determining the final selection.Some uses of ECH, such as local discovery mode, may randomize the since it can be used as a tracking vector. In suchcases, the second method SHOULD be used for matching the to aknown See {{ignored-configs}}. Unless specified by the applicationprofile or otherwise externally configured, implementations MUST use the firstmethod.The server then iterates over the candidate values, attempting todecrypt the "encrypted_client_hello" extension as follows.The server verifies that the supports the cipher suite indicated bythe and that the version of ECH indicated by theclient matches the If not, the server continues to the nextcandidateNext, the server decrypts using the private key skRcorresponding to as follows:    context = SetupBaseR(ECHClientHello.enc, skR,                         "tls ech" || 0x00 || ECHConfig)    EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,                                           ECHClientHello.payload) is computed from as described in{{authenticating-outer}}. The `info` parameter to SetupBaseR is theconcatenation "tls ech", a zero byte, and the serialized Ifdecryption fails, the server continues to the next candidateOtherwise, the server reconstructs from as described in {{encoding-inner}}. It then stopsiterating over the candidate values.Once the server has chosen the correct it MAY verify that the valuein the "server_name" extension matches the value of and abort with an "illegal_parameter" alert ifthese do not match. This optional check allows the server to limit ECHconnections to only use the public SNI values advertised in its ECHConfigs.The server MUST be careful not to unnecessarily reject connections if the same id or keypair is used in multiple ECHConfigs with distinct publicnames.Upon determining the the client-facing server checks that themessage includes a well-formed "encrypted_client_hello" extension of type`inner` and that it does not offer TLS 1.2 or below. If either of these checksfails, the client-facing server MUST abort with an "illegal_parameter" alert.If these checks succeed, the client-facing server then forwards the to the appropriate backend server, which proceeds as in{{backend-server}}. If the backend server responds with a HelloRetryRequest, theclient-facing server forwards it, decrypts the client's secondusing the procedure in {{client-facing-server-hrr}}, and forwards the resultingsecond The client-facing server forwards all other TLSmessages between the client and backend server unmodified.Otherwise, if all candidate values fail to decrypt the extension, theclient-facing server MUST ignore the extension and proceed with the connectionusing with the following modifications:* If sending a HelloRetryRequest, the server MAY include an  "encrypted_client_hello" extension with a payload of 8 random bytes; see  {{dont-stick-out}} for details.* If the server is configured with any ECHConfigs, it MUST include the  "encrypted_client_hello" extension in its EncryptedExtensions with the  "retry_configs" field set to one or more structures with up-to-date  keys. Servers MAY supply multiple values of different versions.  This allows a server to support multiple versions at once.Note that decryption failure could indicate a GREASE ECH extension (see{{grease-ech}}), so it is necessary for servers to proceed with the connectionand rely on the client to abort if ECH was required. In particular, theunrecognized value alone does not indicate a misconfigured ECH advertisement({{misconfiguration}}). Instead, servers can measure occurrences of the"ech_required" alert to detect this case.### Sending HelloRetryRequest {#client-facing-server-hrr}After sending or forwarding a HelloRetryRequest, the client-facing server doesnot repeat the steps in {{client-facing-server}} with the second Instead, it continues with the selection from thefirst as follows:If the client-facing server accepted ECH, it checks that the secondalso contains the "encrypted_client_hello" extension. If not, it MUST abort thehandshake with a "missing_extension" alert. Otherwise, it checks that and are unchanged, and that is empty. If not, it MUST abort the handshake with an"illegal_parameter" alert.Finally, it decrypts the new as a second message with theprevious HPKE context:    EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,                                           ECHClientHello.payload) is computed as described in {{authenticating-outer}}, butusing the second If decryption fails, the client-facingserver MUST abort the handshake with a "decrypt_error" alert. Otherwise, itreconstructs the second from the newas described in {{encoding-inner}}, using the second forany referenced extensions.The client-facing server then forwards the resulting to thebackend server. It forwards all subsequent TLS messages between the client andbackend server unmodified.If the client-facing server rejected ECH, or if the first did notinclude an "encrypted_client_hello" extension, the client-facing serverproceeds with the connection as usual. The server does not decrypt thesecond value, if there is one.Moreover, if the server is configured with any ECHConfigs, it MUST include the"encrypted_client_hello" extension in its EncryptedExtensions with the"retry_configs" field set to one or more structures with up-to-datekeys, as described in {{client-facing-server}}.Note that a client-facing server that forwards the first cannotinclude its own "cookie" extension if the backend server sends aHelloRetryRequest.  This means that the client-facing server either needs tomaintain state for such a connection or it needs to coordinate with the backendserver to include any information it requires to process the second<!-- [rfced] May we rephrase the following text for an improved sentence flow?Original:The backend server embeds in a string derived fromthe inner handshake.Perhaps:A string derived from the inner handshake is embedded into by the backend server.  -->## Backend Server {#backend-server}Upon receipt of an "encrypted_client_hello" extension of type `inner` in a if the backend server negotiates TLS 1.3 or higher, then it MUSTconfirm ECH acceptance to the client by computing its ServerHello as describedhere.The backend server embeds in a string derived from the innerhandshake. It begins by computing its ServerHello as usual, except the last 8bytes of are set to zero. It then computes the transcripthash for up to and including the modified ServerHello, asdescribed in {{RFC8446, Section 4.4.1}}. Let transcript_ech_conf denote theoutput. Finally, the backend server overwrites the last 8 bytes of the with the following string:   accept_confirmation = HKDF-Expand-Label(      HKDF-Extract(0, ClientHelloInner.random),      "ech accept confirmation",      transcript_ech_conf,      8)where HKDF-Expand-Label is defined in {{RFC8446, Section 7.1}}, "0" indicates astring of Hash.length bytes set to zero, and Hash is the hash function used tocompute the transcript hash. In DTLS, the modified version of HKDF-Expand-Labeldefined in {{RFC9147, Section 5.9}} is used instead.The backend server MUST NOT perform this operation if it negotiated TLS 1.2 orbelow. Note that doing so would overwrite the downgrade signal for TLS 1.3 (see{{RFC8446, Section 4.1.3}}).### Sending HelloRetryRequest {#backend-server-hrr}When the backend server sends HelloRetryRequest in response to theit similarly confirms ECH acceptance by adding a confirmation signal to itsHelloRetryRequest. But instead of embedding the signal in theHelloRetryRequest.random (the value of which is specified by {{RFC8446}}), itsends the signal in an extension.The backend server begins by computing HelloRetryRequest as usual, except thatit also contains an "encrypted_client_hello" extension with a payload of 8 zerobytes. It then computes the transcript hash for the firstdenoted ClientHelloInner1, up to and including the modified HelloRetryRequest.Let transcript_hrr_ech_conf denote the output. Finally, the backend serveroverwrites the payload of the "encrypted_client_hello" extension with thefollowing string:   hrr_accept_confirmation = HKDF-Expand-Label(      HKDF-Extract(0, ClientHelloInner1.random),      "hrr ech accept confirmation",      transcript_hrr_ech_conf,      8)In the subsequent ServerHello message, the backend server sends the value as described in {{backend-server}}.# Deployment Considerations {#deployment}The design of ECH as specified in this document necessarily requires changesto client, client-facing server, and backend server. Coordination betweenclient-facing and backend server requires care, as deployment mistakescan lead to compatibility issues. These are discussed in {{compat-issues}}.Beyond coordination difficulties, ECH deployments may also induce challengesfor use cases of information that ECH protects. In particular,use cases which depend on this unencrypted information may no longer workas desired. This is elaborated upon in {{no-sni}}.## Compatibility Issues {#compat-issues}Unlike most TLS extensions, placing the SNI value in an ECH extension is notinteroperable with existing servers, which expect the value in the existingplaintext extension. Thus, server operators SHOULD ensure servers understand agiven set of ECH keys before advertising them. Additionally, servers SHOULDretain support for any previously advertised keys for the duration of theirvalidity.However, in more complex deployment scenarios, this may be difficult to fullyguarantee. Thus, this protocol was designed to be robust in case ofinconsistencies between systems that advertise ECH keys and servers, at the costof extra round-trips due to a retry. Two specific scenarios are detailed below.### Misconfiguration and Deployment Concerns {#misconfiguration}It is possible for ECH advertisements and servers to become inconsistent. Thismay occur, for instance, from DNS misconfiguration, caching issues, or anincomplete rollout in a multi-server deployment. This may also occur if a serverloses its ECH keys, or if a deployment of ECH must be rolled back on the server.The retry mechanism repairs inconsistencies, provided the TLS serverhas a certificate for the public name. If server and advertised keysmismatch, the server will reject ECH and respond with"retry_configs". If the server doesnot understand the "encrypted_client_hello" extension at all, it will ignore itas required by {{Section 4.1.2 of RFC8446}}. Provided the server can present a certificatevalid for the public name, the client can safely retry with updated settings,as described in {{rejected-ech}}.Unless ECH is disabled as a result of successfully establishing a connection tothe public name, the client MUST NOT fall back to using unencryptedClientHellos, as this allows a network attacker to disclose the contents of this including the SNI. It MAY attempt to use another server from theDNS results, if one is provided.In order to ensure that the retry mechanism works successfully, serversSHOULD ensure that every endpoint which might receive a TLS connectionis provisioned with an appropriate certificate for the public name.This is especially important during periods of server reconfigurationwhen different endpoints might have different configurations.### Middleboxes<!--[rfced] How may we update this sentence to make it clear whetherall the requirements or only some of the requirements requireproxies to act as conforming TLS client and server?For background, in general, the RPC recommends using nonrestrictive "which"and restrictive "that". (More details are onhttps://www.rfc-editor.org/styleguide/tips/) However, edits to thatusage have not been made in this document. In this specific sentence,we are asking about the usage because it can affect the understandingof the statement.Original:  The requirements in [RFC8446], Section 9.3 which require proxies to  act as conforming TLS client and server provide interoperability with  TLS-terminating proxies even in cases where the server supports ECH  but the proxy does not, as detailed below.Option A (all requirements require it):  The requirements in [RFC8446], Section 9.3, which require proxies to  act as conforming TLS client and server, provide interoperability with  TLS-terminating proxies even in cases where the server supports ECH  but the proxy does not, as detailed below.Option B (some requirements require it):  The requirements in [RFC8446], Section 9.3 that require proxies to  act as conforming TLS client and server provide interoperability with  TLS-terminating proxies even in cases where the server supports ECH  but the proxy does not, as detailed below.-->The requirements in {{RFC8446, Section 9.3}} which require proxies toact as conforming TLS client and server provide interoperabilitywith TLS-terminating proxies even in cases where the server supportsECH but the proxy does not, as detailed below.The proxy must ignore unknown parameters andgenerate its own containing only parameters it understands. Thus,when presenting a certificate to the client or sending a to theserver, the proxy will act as if connecting to theserver_name, which SHOULD match the public name (see {{real-ech}}) withoutechoing the "encrypted_client_hello" extension.Depending on whether the client is configured to accept the proxy's certificateas authoritative for the public name, this may trigger the retry logic describedin {{rejected-ech}} or result in a connection failure. A proxy which is notauthoritative for the public name cannot forge a signal to disable ECH.## Deployment Impact {#no-sni}Some use cases which depend on information ECH encrypts may break with thedeployment of ECH. The extent of breakage depends on a number of externalfactors, including, for example, whether ECH can be disabled, whether or notthe party disabling ECH is trusted to do so, and whether or not clientimplementations will fall back to TLS without ECH in the event of disablement.Depending on implementation details and deployment settings, use caseswhich depend on plaintext TLS information may require fundamentally differentapproaches to continue working. For example, in managed enterprise settings,one approach may be to disable ECH entirely via group policy and forclient implementations to honor this action. Server deployments whichdepend on SNI -- e.g., for load balancing -- may no longer function properlywithout updates; the nature of those updates is out of scope of thisspecification.In the context of {{rejected-ech}}, another approach may be tointercept and decrypt client TLS connections. The feasibility of alternativesolutions is specific to individual deployments.# Compliance Requirements {#compliance}In the absence of an application profile standard specifying otherwise,a compliant ECH application MUST implement the following HPKE cipher suite:- KEM: DHKEM(X25519, HKDF-SHA256) (see {{Section 7.1 of RFC9180}})- KDF: HKDF-SHA256 (see {{Section 7.2 of RFC9180}})- AEAD: AES-128-GCM (see {{Section 7.3 of RFC9180}})# Security ConsiderationsThis section contains security considerations for ECH.## Security and Privacy Goals {#goals}ECH considers two types of attackers: passive and active. Passive attackers canread packets from the network, but they cannot perform any sort of activebehavior such as probing servers or querying DNS. A middlebox that filters basedon plaintext packet contents is one example of a passive attacker. In contrast,active attackers can also write packets into the network for malicious purposes,such as interfering with existing connections, probing servers, and queryingDNS. In short, an active attacker corresponds to the conventional threat model{{?RFC3552}} for TLS 1.3 {{RFC8446}}.Passive and active attackers can exist anywhere in the network, includingbetween the client and client-facing server, as well as between theclient-facing and backend servers when running ECH in However,for in particular, ECH makes two additional assumptions:1. The channel between each client-facing and each backend server isauthenticated such that the backend server only accepts messages from trustedclient-facing servers. The exact mechanism for establishing this authenticatedchannel is out of scope for this document.1. The attacker cannot correlate messages between a client and client-facingserver with messages between client-facing and backend server. Such correlationcould allow an attacker to link information unique to a backend server, such astheir server name or IP address, with a client's encryptedCorrelation could occur through timing analysis of messages across theclient-facing server, or via examining the contents of messages sent betweenclient-facing and backend servers. The exact mechanism for preventing this sortof correlation is out of scope for this document.Given this threat model, the primary goals of ECH are as follows.1. Security preservation. Use of ECH does not weaken the security properties of   TLS without ECH.1. Handshake privacy. TLS connection establishment to a server name   within an anonymity set is indistinguishable from a connection to   any other server name within the anonymity set. (The anonymity set   is defined in {{intro}}.)1. Downgrade resistance. An attacker cannot downgrade a connection that   attempts to use ECH to one that does not use ECH.These properties were formally proven in {{ECH-Analysis}}.With regards to handshake privacy, client-facing server configurationdetermines the size of the anonymity set. For example, if aclient-facing server uses distinct values for each servername, then each anonymity set has size k = 1. Client-facing serversSHOULD deploy ECH in such a way so as to maximize the size of theanonymity set where possible. This means client-facing servers shoulduse the same for as many server names as possible. Anattacker can distinguish two server names that have different values based on the value.This also means public information in a TLS handshake should beconsistent across server names. For example, if a client-facing serverservices many backend origin server names, only one of which supports somecipher suite, it may be possible to identify that server name based on thecontents of the unencrypted handshake message. Similarly, if a backendorigin reuses KeyShare values, then that provides a unique identifierfor that server.Beyond these primary security and privacy goals, ECH also aims to hide, to someextent, the fact that it is being used at all. Specifically, the GREASE ECHextension described in {{grease-ech}} does not change the security properties ofthe TLS handshake at all. Its goal is to provide "cover" for the real ECHprotocol ({{real-ech}}), as a means of addressing the "do not stick out"requirements of {{?RFC8744}}. See {{dont-stick-out}} for details.## Unauthenticated and Plaintext DNS {#plaintext-dns}ECH supports delivery of configurations through the DNS using SVCB or HTTPSrecords without requiring any verifiable authenticity or provenanceinformation {{RFCYYY1}}. This means that any attacker which can injectDNS responses or poison DNS caches, which is a common scenario inclient access networks, can supply clients with fake ECH configurations (sothat the client encrypts data to them) or strip the ECH configurations fromthe response. However, in the face of an attacker that controls DNS,no encryption scheme can work because the attacker can replace the IPaddress, thus blocking client connections, or substitute a unique IPaddress for each DNS name that was looked up.  Thus, using DNS recordswithout additional authentication does not make the situation significantlyworse.Clearly, DNSSEC (if the client validates and hard fails) is a defenseagainst this form of attack, but encrypted DNS transport is also adefense against DNS attacks by attackers on the local network, whichis a common case where and SNI encryption aredesired. Moreover, as noted in the introduction, SNI encryption isless useful without encryption of DNS queries in transit.## Client TrackingA malicious client-facing server could distribute unique, per-clientstructures as a way of tracking clients across subsequent connections. On-pathadversaries which know about these unique keys could also track clients in thisway by observing TLS connection attempts.The cost of this type of attack scales linearly with the desired number oftarget clients. Moreover, DNS caching behavior makes targeting individual usersfor extended periods of time, e.g., using per-client structuresdelivered via HTTPS RRs with high TTLs, challenging. Clients can help mitigatethis problem by flushing any DNS or state upon changing networks(this may not be possible if clients use the operating system resolverrather than doing their own resolution). rotation rate is also an issue for non-malicious servers,which may want to rotate keys frequently to limit exposure if the keyis compromised. Rotating too frequently limits the client anonymityset. In practice, servers which service many server names and thushave high loads are the best candidates to be client-facing serversand so anonymity sets will typically involve many connections evenwith fairly fast rotation intervals.## Ignored Configuration Identifiers and Trial Decryption {#ignored-configs}Ignoring configuration identifiers may be useful in scenarios where clients andclient-facing servers do not want to reveal information about the client-facingserver in the "encrypted_client_hello" extension. In such settings, clients senda randomly generated in the Servers in these settingsmust perform trial decryption since they cannot identify the client's chosen ECHkey using the value. As a result, ignoring configurationidentifiers may exacerbate DoS attacks. Specifically, an adversary may sendmalicious messages, i.e., those which will not decrypt with anyknown ECH key, in order to force wasteful decryption. Servers that support thisfeature should, for example, implement some form of rate limiting mechanism tolimit the potential damage caused by such attacks.Unless specified by the application using (D)TLS or externally configured,implementations MUST NOT use this mode.## Outer ClientHello {#outer-clienthello}Any information that the client includes in the is visible topassive observers. The client SHOULD NOT send values in thewhich would reveal a sensitive property, such as the trueserver name. It MAY send values associated with the public name in theIn particular, some extensions require the client send a server-name-specificvalue in the These values may reveal information about thetrue server name. For example, the "cached_info" extension{{?RFC7924}} can contain the hash of a previously observed server certificate.The client SHOULD NOT send values associated with the true server name in the It MAY send such values in theA client may also use different preferences in different contexts. For example,it may send different ALPN lists to different servers or in differentapplication contexts. A client that treats this context as sensitive SHOULD NOTsend context-specific values inValues which are independent of the true server name, or other information theclient wishes to protect, MAY be included in If they matchthe corresponding they MAY be compressed as described in{{encoding-inner}}. However, note that the payload length reveals informationabout which extensions are compressed, so inner extensions which only sometimesmatch the corresponding outer extension SHOULD NOT be compressed.Clients MAY include additional extensions in to avoidsignaling unusual behavior to passive observers, provided the choice of valueand value itself are not sensitive. See {{dont-stick-out}}.## Inner ClientHello {#inner-clienthello}Values which depend on the contents of such as thetrue server name, can influence how client-facing servers process this message.In particular, timing side channels can reveal information about the contentsof Implementations should take such side channels intoconsideration when reasoning about the privacy properties that ECH provides.## Related Privacy LeaksECH requires encrypted DNS to be an effective privacy protection mechanism.However, verifying the server's identity from the Certificate message,particularly when using the X509 CertificateType, may result in additionalnetwork traffic that may reveal the server identity. Examples of this trafficmay include requests for revocation information, such as Online Certificate Status Protocol (OCSP) or Certificate Revocation List (CRL) traffic, or requests for repository information, such as authorityInformationAccess. It may also include implementation-specific traffic for additional information sources as part of verification.Implementations SHOULD avoid leaking information that may identify the server.Even when sent over an encrypted transport, such requests may result in indirectexposure of the server's identity, such as indicating a specific CA or servicebeing used. To mitigate this risk, servers SHOULD deliver such informationin-band when possible, such as through the use of OCSP stapling, and clientsSHOULD take steps to minimize or protect such requests during certificatevalidation.Attacks that rely on non-ECH traffic to infer server identity in an ECHconnection are out of scope for this document. For example, a client thatconnects to a particular host prior to ECH deployment may later resume aconnection to that same host after ECH deployment. An adversary that observesthis can deduce that the ECH-enabled connection was made to a host that theclient previously connected to and which is within the same anonymity set.## Cookies{{Section 4.2.2 of RFC8446}} defines a cookie value that servers may send inHelloRetryRequest for clients to echo in the second While ECHencrypts the cookie in the second the backend server'sHelloRetryRequest is means differences in cookies betweenbackend servers, such as lengths or cleartext components, may leak informationabout the server identity.Backend servers in an anonymity set SHOULD NOT reveal information in the cookiewhich identifies the server. This may be done by handling HelloRetryRequeststatefully, thus not sending cookies, or by using the same cookie constructionfor all backend servers.Note that, if the cookie includes a key name, analogous to {{Section 4 of?RFC5077}}, this may leak information if different backend servers issuecookies with different key names at the time of the connection. In particular,if the deployment operates in the backend servers may not sharecookie encryption keys. Backend servers may mitigate this either by handlingkey rotation with trial decryption or by coordinating to match key names.## Attacks Exploiting Acceptance ConfirmationTo signal acceptance, the backend server overwrites 8 bytes of its with a value derived from the (See{{backend-server}} for details.) This behavior increases the likelihood of the colliding with the of a previous session,potentially reducing the overall security of the protocol. However, theremaining 24 bytes provide enough entropy to ensure this is not a practicalavenue of attack.On the other hand, the probability that two 8-byte strings are the same isnon-negligible. This poses a modest operational risk. Suppose the client-facingserver terminates the connection (i.e., ECH is rejected or bypassed): if thelast 8 bytes of its coincide with the confirmation signal,then the client will incorrectly presume acceptance and proceed as if thebackend server terminated the connection. However, the probability of a falsepositive occurring for a given connection is only 1 in 2^64. This value issmaller than the probability of network connection failures in practice.Note that the same bytes of the are used to implementdowngrade protection for TLS 1.3 (see {{RFC8446, Section 4.1.3}}). Thesemechanisms do not interfere because the backend server only signals ECHacceptance in TLS 1.3 or higher.## Comparison Against Criteria{{?RFC8744}} lists several requirements for SNI encryption.In this section, we reiterate these requirements and assess the ECH designagainst them.### Mitigate Cut-and-Paste AttacksSince servers process either or and because is encrypted, it is not possible for an attacker to "cutand paste" the ECH value in a different Client Hello and learn information from### Avoid Widely Shared SecretsThis design depends upon DNS as a vehicle for semi-static public keydistribution. Server operators may partition their private keyshowever they see fit provided each server behind an IP address has thecorresponding private key to decrypt a key. Thus, when one ECH key isprovided, sharing is optimally bound by the number of hosts that sharean IP address. Server operators may further limit sharing of privatekeys by publishing different DNS records containing valueswith different public keys using a short TTL.### SNI-Based Denial-of-Service AttacksThis design requires servers to decrypt messages withextensions carrying valid digests. Thus, it is possible for an attacker to forcedecryption operations on the server. This attack is bound by the number of validtransport connections an attacker can open.### Do Not Stick Out {#dont-stick-out}As a means of reducing the impact of network ossification, {{?RFC8744}}recommends SNI-protection mechanisms be designed in such a way that networkoperators do not differentiate connections using the mechanism from connectionsnot using the mechanism. To that end, ECH is designed to resemble a standardTLS handshake as much as possible. The most obvious difference is the extensionitself: as long as middleboxes ignore it, as required by {{!RFC8446}}, the restof the handshake is designed to look very much as usual.The GREASE ECH protocol described in {{grease-ech}} provides a low-risk way toevaluate the deployability of ECH. It is designed to mimic the real ECH protocol({{real-ech}}) without changing the security properties of the handshake. Theunderlying theory is that if GREASE ECH is deployable without triggeringmiddlebox misbehavior, and real ECH looks enough like GREASE ECH, then ECHshould be deployable as well. Thus, the strategy for mitigating networkossification is to deploy GREASE ECH widely enough to disincentivizedifferential treatment of the real ECH protocol by the network.Ensuring that networks do not differentiate between real ECH and GREASE ECH maynot be feasible for all implementations. While most middleboxes will not treatthem differently, some operators may wish to block real ECH usage but allowGREASE ECH. This specification aims to provide a baseline security level thatmost deployments can achieve easily while providing implementations enoughflexibility to achieve stronger security where possible. Minimally, real ECH isdesigned to be indifferentiable from GREASE ECH for passive adversaries withfollowing capabilities:1. The attacker does not know the used by the server.1. The attacker keeps per-connection state only. In particular, it does not   track endpoints across connections.Moreover, real ECH and GREASE ECH are designed so that the following featuresdo not noticeably vary to the attacker, i.e., they are not distinguishers:1. the code points of extensions negotiated in the clear, and their order;1. the length of messages; and1. the values of plaintext alert messages.This leaves a variety of practical differentiators out-of-scope. including,though not limited to, the following:1. the value of the configuration identifier;1. the value of the outer SNI;1. the TLS version negotiated, which may depend on ECH acceptance;1. client authentication, which may depend on ECH acceptance; and1. HRR issuance, which may depend on ECH acceptance.These can be addressed with more sophisticated implementations, but somemitigations require coordination between the client and server, and evenacross different client and server implementations. These mitigations areout-of-scope for this specification.### Maintain Forward SecrecyThis design does not provide forward secrecy for the innerbecause the server's ECH key is static.  However, the window ofexposure is bound by the key lifetime. It is RECOMMENDED that serversrotate keys regularly.### Enable Multi-party Security ContextsThis design permits servers operating in to forward connectionsdirectly to backend origin servers. The client authenticates the identity ofthe backend origin server, thereby allowing the backend origin serverto hide behind the client-facing server without the client-facingserver decrypting and reencrypting the connection.Conversely, if the DNS records used for configuration areauthenticated, e.g., via DNSSEC,spoofing a client-facing server operating in is notpossible. See {{plaintext-dns}} for more details regarding plaintextDNS.Authenticating the structure naturally authenticates the includedpublic name. This also authenticates any retry signals from the client-facingserver because the client validates the server certificate against the publicname before retrying.### Support Multiple ProtocolsThis design has no impact on application layer protocol negotiation. It mayaffect connection routing, server certificate selection, and client certificateverification. Thus, it is compatible with multiple application and transportprotocols. By encrypting the entire this design additionallysupports encrypting the ALPN extension.## Padding PolicyVariations in the length of the ciphertext could leakinformation about the corresponding plaintext. {{padding}} describes aRECOMMENDED padding mechanism for clients aimed at reducing potentialinformation leakage.## Active Attack MitigationsThis section describes the rationale for ECH properties and mechanics asdefenses against active attacks. In all the attacks below, the attacker ison-path between the target client and server. The goal of the attacker is tolearn private information about the inner such as the true SNIvalue.### Client Reaction Attack Mitigation {#flow-client-reaction}This attack uses the client's reaction to an incorrect certificate as an oracle.The attacker intercepts a legitimate and replies with a ServerHello,Certificate, CertificateVerify, and Finished messages, wherein the Certificatemessage contains a "test" certificate for the domain name it wishes to query. Ifthe client decrypted the Certificate and failed verification (or leakedinformation about its verification process by a timing side channel), theattacker learns that its test certificate name was incorrect. As an example,suppose the client's SNI value in its inner is "example.com," andthe attacker replied with a Certificate for "test.com". If the client produces averification failure alert because of the mismatch faster than it would due tothe Certificate signature validation, information about the name leaks. Notethat the attacker can also withhold the CertificateVerify message. In thatscenario, a client which first verifies the Certificate would then respondsimilarly and leak the same information. Client                         Attacker               Server   ClientHello   + key_share   + ech         ------>      (intercept)     -----> X (drop)                             ServerHello                             + key_share                   {EncryptedExtensions}                   {CertificateRequest*}                          {Certificate*}                    {CertificateVerify*}                 <------   Alert                 ------>{: #flow-diagram-client-reaction title="Client Reaction Attack"} prevents this attack. In particular, since the attackerdoes not have access to this value, it cannot produce the right transcript andhandshake keys needed for encrypting the Certificate message. Thus, the clientwill fail to decrypt the Certificate and abort the connection.### HelloRetryRequest Hijack Mitigation {#flow-hrr-hijack}This attack aims to exploit server HRR state management to recover informationabout a legitimate using its own attacker-controlledTo begin, the attacker intercepts and forwards a legitimate with an"encrypted_client_hello" (ech) extension to the server, which triggers alegitimate HelloRetryRequest in return. Rather than forward the retry to theclient, the attacker attempts to generate its own in response basedon the contents of the first and HelloRetryRequest exchange with theresult that the server encrypts the Certificate to the attacker. If the serverused the SNI from the first and the key share from the second(attacker-controlled) the Certificate produced would leak theclient's chosen SNI to the attacker. Client                         Attacker                   Server   ClientHello   + key_share   + ech         ------>       (forward)        ------->                                              HelloRetryRequest                                                    + key_share                              (intercept)       <-------                              ClientHello                              + key_share'                              + ech'           ------->                                                    ServerHello                                                    + key_share                                          {EncryptedExtensions}                                          {CertificateRequest*}                                                 {Certificate*}                                           {CertificateVerify*}                                                     {Finished}                                                <-------                         (process server flight){: #flow-diagram-hrr-hijack title="HelloRetryRequest Hijack Attack"}This attack is mitigated by using the same HPKE context for bothmessages. The attacker does not possess the context's keys, so it cannotgenerate a valid encryption of the second innerIf the attacker could manipulate the second it might be possiblefor the server to act as an oracle if it required parameters from the first to match that of the second For example, imagine theclient's original SNI value in the inner is "example.com", and theattacker's hijacked SNI value in its inner is "test.com". A serverwhich checks these for equality and changes behavior based on the result can beused as an oracle to learn the client's SNI.### ClientHello Malleability Mitigation {#flow-clienthello-malleability}This attack aims to leak information about secret parts of the encrypted by adding attacker-controlled parameters and observing the server'sresponse. In particular, the compression mechanism described in{{encoding-inner}} references parts of a potentially attacker-controlled to construct or a buggy server mayincorrectly apply parameters from to the handshake.To begin, the attacker first interacts with a server to obtain a resumptionticket for a given test domain, such as "example.com". Later, upon receipt of a it modifies it such that the server will process theresumption ticket with If the server only accepts resumptionPSKs that match the server name, it will fail the PSK binder check with analert when is for "example.com" but silently ignore the PSKand continue when is for any other name. This introduces anoracle for testing encrypted SNI values.      Client              Attacker                       Server                                    handshake and ticket                                       for "example.com"                                       <-------->      ClientHello      + key_share      + ech         + ech_outer_extensions(pre_shared_key)      + pre_shared_key                  -------->                        (intercept)                        ClientHello                        + key_share                        + ech                           + ech_outer_extensions(pre_shared_key)                        + pre_shared_key'                                          -------->                                                         Alert                                                         -or-                                                   ServerHello                                                            ...                                                      Finished                                          <--------{: #tls-clienthello-malleability title="Message Flow for Malleable ClientHello"}This attack may be generalized to any parameter which the server varies byserver name, such as ALPN preferences.ECH mitigates this attack by only negotiating TLS parameters from and authenticating all inputs to the and with the HPKE AEAD. See{{authenticating-outer}}. The decompression process in {{encoding-inner}}forbids "encrypted_client_hello" in OuterExtensions. This ensures theunauthenticated portion of is not incorporated into An earlier iteration of this specification onlyencrypted and authenticated the "server_name" extension, which left the overall vulnerable to an analogue of this attack.### ClientHelloInner Packet Amplification Mitigation {#decompression-amp}Client-facing servers must decompress EncodedClientHelloInners. A maliciousattacker may craft a packet which takes excessive resources to decompressor may be much larger than the incoming packet:* If looking up a extension takes time linear in the number of  extensions, the overall decoding process would take O(M\*N) time, where  M is the number of extensions in and N is the  size of OuterExtensions.* If the same extension can be copied multiple times,  an attacker could cause the client-facing server to construct a large by including a large extension in  of length L and an OuterExtensions list 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 the client. In an  O(N\*L)-sized packet would then be transmitted to the  backend server.ECH mitigates this attack by requiring that OuterExtensions be referenced inorder, that duplicate references be rejected, and by recommending thatclient-facing servers use a linear scan to perform decompression. Theserequirements are detailed in {{encoding-inner}}.# IANA Considerations## Update of the TLS ExtensionType RegistryIANA has created the following entries in the existing"TLS ExtensionType Values" registry (defined in {{!RFC8446}}):1. encrypted_client_hello (0xfe0d), with "TLS 1.3" column values set to   "CH, HRR, EE", "DTLS-Only" column set to "N", and "Recommended" column set   to "Y".1. ech_outer_extensions (0xfd00), with the "TLS 1.3" column values set to "CH",   "DTLS-Only" column set to "N", "Recommended" column set to "Y", and the   "Comment" column set to "Only appears in inner CH."## Update of the TLS Alert Registry {#alerts}IANA has created an entry, ech_required (121) in the existing "TLSAlerts" registry (defined in {{!RFC8446}}), with the "DTLS-OK" columnset to "Y".## ECH Configuration Extension Registry {#config-extensions-iana}IANA has created a new "TLS ECHConfig Extension" registry in a new"TLS Encrypted Client Hello (ECH) Configuration Extensions" registry group. Newregistrations will list the following attributes:Value:: The two-byte identifier for the ECHConfigExtension, i.e., theECHConfigExtensionTypeExtension Name:: Name of the ECHConfigExtensionRecommended:: A "Y" or "N" value indicating if the TLS recommends that theextension be supported. This column is assigned a value of "N" unlessexplicitly requested. Adding a value of "Y" requires StandardsAction {{RFC8126}}.Reference:: The specification where the ECHConfigExtension is definedNotes:: Any notes associated with the entry{: spacing="compact"}New entries in the "TLS ECHConfig Extension" registry are subject to theSpecification Required registration policy ({{!RFC8126, Section4.6}}), with the policies described in {{!RFC8447, Section 17}}. IANAhas added the following note to the "TLS ECHConfig Extension"registry:   Note:  The role of the designated expert is described in RFC 8447.      The designated expert [RFC8126] ensures that the specification is      publicly available.  It is sufficient to have an Internet-Draft      (that is posted and never published as an RFC) or a document from      another standards body, industry consortium, university site, etc.      The expert may provide more in-depth reviews, but their approval      should not be taken as an endorsement of the extension.This document defines several Reserved values for ECH configuration extensionsto be used for "greasing" as described in {{server-greasing}}.The initial contents for this registry consists of multiple reserved valueswith the following attributes, which are repeated for each registration:Value:: 0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0x8A8A,0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, 0xFAFAExtension Name:: RESERVEDRecommended:: YReference:: RFC 9849Notes:: entries{: spacing="compact"}--- back# Linear-Time Outer Extension Processing {#linear-outer-extensions}The following procedure processes the "ech_outer_extensions" extension (see{{encoding-inner}}) in linear time, ensuring that each referenced extensionin the is included at most once:1. Let I be initialized to zero and N be set to the number of extensionsin1. For each extension type, E, in OuterExtensions:   * If E is "encrypted_client_hello", abort the connection with an     "illegal_parameter" alert and terminate this procedure.   * While I is less than N and the I-th extension of does not have type E, increment I.   * If I is equal to N, abort the connection with an "illegal_parameter"     alert and terminate this procedure.   * Otherwise, the I-th extension of has type E. Copy     it to the and increment I.# Acknowledgements{:numbered="false"}This document draws extensively from ideas in {{?I-D.kazuho-protected-sni}}, butis a much more limited mechanism because it depends on the DNS for theprotection of the ECH key. {{{Richard Barnes}}}, {{{Christian Huitema}}}, {{{Patrick McManus}}},{{{Matthew Prince}}}, {{{Nick Sullivan}}}, {{{Martin Thomson}}}, and {{{David Benjamin}}} also providedimportant ideas and contributions.