idnits 2.17.1 draft-ietf-tls-esni-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 February 2022) is 803 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 496 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-08 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-14 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'I-D.irtf-cfrg-hpke') ** Downref: Normative reference to an Informational RFC: RFC 7918 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Standards Track K. Oku 5 Expires: 17 August 2022 Fastly 6 N. Sullivan 7 C.A. Wood 8 Cloudflare 9 13 February 2022 11 TLS Encrypted Client Hello 12 draft-ietf-tls-esni-14 14 Abstract 16 This document describes a mechanism in Transport Layer Security (TLS) 17 for encrypting a ClientHello message under a server public key. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Source for this draft and an issue tracker can be found at 24 https://github.com/tlswg/draft-ietf-tls-esni 25 (https://github.com/tlswg/draft-ietf-tls-esni). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 17 August 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Encrypted ClientHello (ECH) . . . . . . . . . . . . . . . 6 65 4. Encrypted ClientHello Configuration . . . . . . . . . . . . . 6 66 4.1. Configuration Identifiers . . . . . . . . . . . . . . . . 9 67 4.2. Configuration Extensions . . . . . . . . . . . . . . . . 9 68 5. The "encrypted_client_hello" Extension . . . . . . . . . . . 10 69 5.1. Encoding the ClientHelloInner . . . . . . . . . . . . . . 11 70 5.2. Authenticating the ClientHelloOuter . . . . . . . . . . . 13 71 6. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 72 6.1. Offering ECH . . . . . . . . . . . . . . . . . . . . . . 14 73 6.1.1. Encrypting the ClientHello . . . . . . . . . . . . . 16 74 6.1.2. GREASE PSK . . . . . . . . . . . . . . . . . . . . . 17 75 6.1.3. Recommended Padding Scheme . . . . . . . . . . . . . 17 76 6.1.4. Determining ECH Acceptance . . . . . . . . . . . . . 18 77 6.1.5. Handshaking with ClientHelloInner . . . . . . . . . . 19 78 6.1.6. Handshaking with ClientHelloOuter . . . . . . . . . . 20 79 6.1.7. Authenticating for the Public Name . . . . . . . . . 21 80 6.2. GREASE ECH . . . . . . . . . . . . . . . . . . . . . . . 22 81 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 23 82 7.1. Client-Facing Server . . . . . . . . . . . . . . . . . . 23 83 7.1.1. Sending HelloRetryRequest . . . . . . . . . . . . . . 25 84 7.2. Backend Server . . . . . . . . . . . . . . . . . . . . . 26 85 7.2.1. Sending HelloRetryRequest . . . . . . . . . . . . . . 27 86 8. Compatibility Issues . . . . . . . . . . . . . . . . . . . . 27 87 8.1. Misconfiguration and Deployment Concerns . . . . . . . . 28 88 8.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 28 89 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 28 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 91 10.1. Security and Privacy Goals . . . . . . . . . . . . . . . 29 92 10.2. Unauthenticated and Plaintext DNS . . . . . . . . . . . 30 93 10.3. Client Tracking . . . . . . . . . . . . . . . . . . . . 30 94 10.4. Ignored Configuration Identifiers and Trial 95 Decryption . . . . . . . . . . . . . . . . . . . . . . 31 96 10.5. Outer ClientHello . . . . . . . . . . . . . . . . . . . 31 97 10.6. Related Privacy Leaks . . . . . . . . . . . . . . . . . 32 98 10.7. Cookies . . . . . . . . . . . . . . . . . . . . . . . . 32 99 10.8. Attacks Exploiting Acceptance Confirmation . . . . . . . 33 100 10.9. Comparison Against Criteria . . . . . . . . . . . . . . 33 101 10.9.1. Mitigate Cut-and-Paste Attacks . . . . . . . . . . . 34 102 10.9.2. Avoid Widely Shared Secrets . . . . . . . . . . . . 34 103 10.9.3. Prevent SNI-Based Denial-of-Service Attacks . . . . 34 104 10.9.4. Do Not Stick Out . . . . . . . . . . . . . . . . . . 34 105 10.9.5. Maintain Forward Secrecy . . . . . . . . . . . . . . 35 106 10.9.6. Enable Multi-party Security Contexts . . . . . . . . 36 107 10.9.7. Support Multiple Protocols . . . . . . . . . . . . . 36 108 10.10. Padding Policy . . . . . . . . . . . . . . . . . . . . . 36 109 10.11. Active Attack Mitigations . . . . . . . . . . . . . . . 36 110 10.11.1. Client Reaction Attack Mitigation . . . . . . . . . 37 111 10.11.2. HelloRetryRequest Hijack Mitigation . . . . . . . . 38 112 10.11.3. ClientHello Malleability Mitigation . . . . . . . . 39 113 10.11.4. ClientHelloInner Packet Amplification Mitigation . 40 114 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 115 11.1. Update of the TLS ExtensionType Registry . . . . . . . . 41 116 11.2. Update of the TLS Alert Registry . . . . . . . . . . . . 41 117 12. ECHConfig Extension Guidance . . . . . . . . . . . . . . . . 41 118 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 119 13.1. Normative References . . . . . . . . . . . . . . . . . . 42 120 13.2. Informative References . . . . . . . . . . . . . . . . . 43 121 Appendix A. Alternative SNI Protection Designs . . . . . . . . . 44 122 A.1. TLS-layer . . . . . . . . . . . . . . . . . . . . . . . . 44 123 A.1.1. TLS in Early Data . . . . . . . . . . . . . . . . . . 44 124 A.1.2. Combined Tickets . . . . . . . . . . . . . . . . . . 44 125 A.2. Application-layer . . . . . . . . . . . . . . . . . . . . 45 126 A.2.1. HTTP/2 CERTIFICATE Frames . . . . . . . . . . . . . . 45 127 Appendix B. Linear-time Outer Extension Processing . . . . . . . 45 128 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 46 129 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 46 130 D.1. Since draft-ietf-tls-esni-12 . . . . . . . . . . . . . . 46 131 D.2. Since draft-ietf-tls-esni-11 . . . . . . . . . . . . . . 46 132 D.3. Since draft-ietf-tls-esni-10 . . . . . . . . . . . . . . 46 133 D.4. Since draft-ietf-tls-esni-09 . . . . . . . . . . . . . . 47 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 136 1. Introduction 138 DISCLAIMER: This draft is work-in-progress and has not yet seen 139 significant (or really any) security analysis. It should not be used 140 as a basis for building production systems. This published version 141 of the draft has been designated an "implementation draft" for 142 testing and interop purposes. 144 Although TLS 1.3 [RFC8446] encrypts most of the handshake, including 145 the server certificate, there are several ways in which an on-path 146 attacker can learn private information about the connection. The 147 plaintext Server Name Indication (SNI) extension in ClientHello 148 messages, which leaks the target domain for a given connection, is 149 perhaps the most sensitive, unencrypted information in TLS 1.3. 151 The target domain may also be visible through other channels, such as 152 plaintext client DNS queries or visible server IP addresses. 153 However, DoH [RFC8484] and DPRIVE [RFC7858] [RFC8094] provide 154 mechanisms for clients to conceal DNS lookups from network 155 inspection, and many TLS servers host multiple domains on the same IP 156 address. Private origins may also be deployed behind a common 157 provider, such as a reverse proxy. In such environments, the SNI 158 remains the primary explicit signal used to determine the server's 159 identity. 161 This document specifies a new TLS extension, called Encrypted Client 162 Hello (ECH), that allows clients to encrypt their ClientHello to such 163 a deployment. This protects the SNI and other potentially sensitive 164 fields, such as the ALPN list [RFC7301]. Co-located servers with 165 consistent externally visible TLS configurations, including supported 166 versions and cipher suites, form an anonymity set. Usage of this 167 mechanism reveals that a client is connecting to a particular service 168 provider, but does not reveal which server from the anonymity set 169 terminates the connection. 171 ECH is only supported with (D)TLS 1.3 [RFC8446] and newer versions of 172 the protocol. 174 2. Conventions and Definitions 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in BCP 179 14 [RFC2119] [RFC8174] when, and only when, they appear in all 180 capitals, as shown here. All TLS notation comes from [RFC8446], 181 Section 3. 183 3. Overview 185 This protocol is designed to operate in one of two topologies 186 illustrated below, which we call "Shared Mode" and "Split Mode". 188 3.1. Topologies 189 +---------------------+ 190 | | 191 | 2001:DB8::1111 | 192 | | 193 Client <-----> | private.example.org | 194 | | 195 | public.example.com | 196 | | 197 +---------------------+ 198 Server 199 (Client-Facing and Backend Combined) 201 Figure 1: Shared Mode Topology 203 In Shared Mode, the provider is the origin server for all the domains 204 whose DNS records point to it. In this mode, the TLS connection is 205 terminated by the provider. 207 +--------------------+ +---------------------+ 208 | | | | 209 | 2001:DB8::1111 | | 2001:DB8::EEEE | 210 Client <----------------------------->| | 211 | public.example.com | | private.example.com | 212 | | | | 213 +--------------------+ +---------------------+ 214 Client-Facing Server Backend Server 216 Figure 2: Split Mode Topology 218 In Split Mode, the provider is not the origin server for private 219 domains. Rather, the DNS records for private domains point to the 220 provider, and the provider's server relays the connection back to the 221 origin server, who terminates the TLS connection with the client. 222 Importantly, the service provider does not have access to the 223 plaintext of the connection beyond the unencrypted portions of the 224 handshake. 226 In the remainder of this document, we will refer to the ECH-service 227 provider as the "client-facing server" and to the TLS terminator as 228 the "backend server". These are the same entity in Shared Mode, but 229 in Split Mode, the client-facing and backend servers are physically 230 separated. 232 3.2. Encrypted ClientHello (ECH) 234 A client-facing server enables ECH by publishing an ECH 235 configuration, which is an encryption public key and associated 236 metadata. The server must publish this for all the domains it serves 237 via Shared or Split Mode. This document defines the ECH 238 configuration's format, but delegates DNS publication details to 239 [HTTPS-RR]. Other delivery mechanisms are also possible. For 240 example, the client may have the ECH configuration preconfigured. 242 When a client wants to establish a TLS session with some backend 243 server, it constructs a private ClientHello, referred to as the 244 ClientHelloInner. The client then constructs a public ClientHello, 245 referred to as the ClientHelloOuter. The ClientHelloOuter contains 246 innocuous values for sensitive extensions and an 247 "encrypted_client_hello" extension (Section 5), which carries the 248 encrypted ClientHelloInner. Finally, the client sends 249 ClientHelloOuter to the server. 251 The server takes one of the following actions: 253 1. If it does not support ECH or cannot decrypt the extension, it 254 completes the handshake with ClientHelloOuter. This is referred 255 to as rejecting ECH. 257 2. If it successfully decrypts the extension, it forwards the 258 ClientHelloInner to the backend server, which completes the 259 handshake. This is referred to as accepting ECH. 261 Upon receiving the server's response, the client determines whether 262 or not ECH was accepted (Section 6.1.4) and proceeds with the 263 handshake accordingly. When ECH is rejected, the resulting 264 connection is not usable by the client for application data. 265 Instead, ECH rejection allows the client to retry with up-to-date 266 configuration (Section 6.1.6). 268 The primary goal of ECH is to ensure that connections to servers in 269 the same anonymity set are indistinguishable from one another. 270 Moreover, it should achieve this goal without affecting any existing 271 security properties of TLS 1.3. See Section 10.1 for more details 272 about the ECH security and privacy goals. 274 4. Encrypted ClientHello Configuration 276 ECH uses HPKE for public key encryption [I-D.irtf-cfrg-hpke]. The 277 ECH configuration is defined by the following ECHConfig structure. 279 opaque HpkePublicKey<1..2^16-1>; 280 uint16 HpkeKemId; // Defined in I-D.irtf-cfrg-hpke 281 uint16 HpkeKdfId; // Defined in I-D.irtf-cfrg-hpke 282 uint16 HpkeAeadId; // Defined in I-D.irtf-cfrg-hpke 284 struct { 285 HpkeKdfId kdf_id; 286 HpkeAeadId aead_id; 287 } HpkeSymmetricCipherSuite; 289 struct { 290 uint8 config_id; 291 HpkeKemId kem_id; 292 HpkePublicKey public_key; 293 HpkeSymmetricCipherSuite cipher_suites<4..2^16-4>; 294 } HpkeKeyConfig; 296 struct { 297 HpkeKeyConfig key_config; 298 uint8 maximum_name_length; 299 opaque public_name<1..255>; 300 Extension extensions<0..2^16-1>; 301 } ECHConfigContents; 303 struct { 304 uint16 version; 305 uint16 length; 306 select (ECHConfig.version) { 307 case 0xfe0d: ECHConfigContents contents; 308 } 309 } ECHConfig; 311 The structure contains the following fields: 313 version The version of ECH for which this configuration is used. 314 Beginning with draft-08, the version is the same as the code point 315 for the "encrypted_client_hello" extension. Clients MUST ignore 316 any ECHConfig structure with a version they do not support. 318 length The length, in bytes, of the next field. This length field 319 allows implementations to skip over the elements in such a list 320 where they cannot parse the specific version of ECHConfig. 322 contents An opaque byte string whose contents depend on the version. 323 For this specification, the contents are an ECHConfigContents 324 structure. 326 The ECHConfigContents structure contains the following fields: 328 key_config A HpkeKeyConfig structure carrying the configuration 329 information associated with the HPKE public key. Note that this 330 structure contains the config_id field, which applies to the 331 entire ECHConfigContents. 333 maximum_name_length The longest name of a backend server, if known. 334 If not known, this value can be set to zero. It is used to 335 compute padding (Section 6.1.3) and does not constrain server name 336 lengths. Names may exceed this length if, e.g., the server uses 337 wildcard names or added new names to the anonymity set. 339 public_name The DNS name of the client-facing server, i.e., the 340 entity trusted to update the ECH configuration. This is used to 341 correct misconfigured clients, as described in Section 6.1.6. 343 Clients MUST ignore any ECHConfig structure whose public_name is 344 not parsable as a dot-separated sequence of LDH labels, as defined 345 in [RFC5890], Section 2.3.1 or which begins or end with an ASCII 346 dot. 348 Clients SHOULD ignore the ECHConfig if it contains an encoded IPv4 349 address. To determine if a public_name value is an IPv4 address, 350 clients can invoke the IPv4 parser algorithm in [WHATWG-IPV4]. It 351 returns a value when the input is an IPv4 address. 353 See Section 6.1.7 for how the client interprets and validates the 354 public_name. 356 extensions A list of extensions that the client must take into 357 consideration when generating a ClientHello message. These are 358 described below (Section 4.2). 360 [[OPEN ISSUE: determine if clients should enforce a 63-octet label 361 limit for public_name]] [[OPEN ISSUE: fix reference to WHATWG-IPV4]] 363 The HpkeKeyConfig structure contains the following fields: 365 config_id A one-byte identifier for the given HPKE key 366 configuration. This is used by clients to indicate the key used 367 for ClientHello encryption. Section 4.1 describes how client- 368 facing servers allocate this value. 370 kem_id The HPKE KEM identifier corresponding to public_key. Clients 371 MUST ignore any ECHConfig structure with a key using a KEM they do 372 not support. 374 public_key The HPKE public key used by the client to encrypt 375 ClientHelloInner. 377 cipher_suites The list of HPKE KDF and AEAD identifier pairs clients 378 can use for encrypting ClientHelloInner. See Section 6.1 for how 379 clients choose from this list. 381 The client-facing server advertises a sequence of ECH configurations 382 to clients, serialized as follows. 384 ECHConfig ECHConfigList<1..2^16-1>; 386 The ECHConfigList structure contains one or more ECHConfig structures 387 in decreasing order of preference. This allows a server to support 388 multiple versions of ECH and multiple sets of ECH parameters. 390 4.1. Configuration Identifiers 392 A client-facing server has a set of known ECHConfig values, with 393 corresponding private keys. This set SHOULD contain the currently 394 published values, as well as previous values that may still be in 395 use, since clients may cache DNS records up to a TTL or longer. 397 Section 7.1 describes a trial decryption process for decrypting the 398 ClientHello. This can impact performance when the client-facing 399 server maintains many known ECHConfig values. To avoid this, the 400 client-facing server SHOULD allocate distinct config_id values for 401 each ECHConfig in its known set. The RECOMMENDED strategy is via 402 rejection sampling, i.e., to randomly select config_id repeatedly 403 until it does not match any known ECHConfig. 405 It is not necessary for config_id values across different client- 406 facing servers to be distinct. A backend server may be hosted behind 407 two different client-facing servers with colliding config_id values 408 without any performance impact. Values may also be reused if the 409 previous ECHConfig is no longer in the known set. 411 4.2. Configuration Extensions 413 ECH configuration extensions are used to provide room for additional 414 functionality as needed. See Section 12 for guidance on which types 415 of extensions are appropriate for this structure. 417 The format is as defined in [RFC8446], Section 4.2. The same 418 interpretation rules apply: extensions MAY appear in any order, but 419 there MUST NOT be more than one extension of the same type in the 420 extensions block. An extension can be tagged as mandatory by using 421 an extension type codepoint with the high order bit set to 1. 423 Clients MUST parse the extension list and check for unsupported 424 mandatory extensions. If an unsupported mandatory extension is 425 present, clients MUST ignore the ECHConfig. 427 5. The "encrypted_client_hello" Extension 429 To offer ECH, the client sends an "encrypted_client_hello" extension 430 in the ClientHelloOuter. When it does, it MUST also send the 431 extension in ClientHelloInner. 433 enum { 434 encrypted_client_hello(0xfe0d), (65535) 435 } ExtensionType; 437 The payload of the extension has the following structure: 439 enum { outer(0), inner(1) } ECHClientHelloType; 441 struct { 442 ECHClientHelloType type; 443 select (ECHClientHello.type) { 444 case outer: 445 HpkeSymmetricCipherSuite cipher_suite; 446 uint8 config_id; 447 opaque enc<0..2^16-1>; 448 opaque payload<1..2^16-1>; 449 case inner: 450 Empty; 451 }; 452 } ECHClientHello; 454 The outer extension uses the outer variant and the inner extension 455 uses the inner variant. The inner extension has an empty payload. 456 The outer extension has the following fields: 458 config_id The ECHConfigContents.key_config.config_id for the chosen 459 ECHConfig. 461 cipher_suite The cipher suite used to encrypt ClientHelloInner. 462 This MUST match a value provided in the corresponding 463 ECHConfigContents.cipher_suites list. 465 enc The HPKE encapsulated key, used by servers to decrypt the 466 corresponding payload field. This field is empty in a 467 ClientHelloOuter sent in response to HelloRetryRequest. 469 payload The serialized and encrypted ClientHelloInner structure, 470 encrypted using HPKE as described in Section 6.1. 472 When a client offers the outer version of an "encrypted_client_hello" 473 extension, the server MAY include an "encrypted_client_hello" 474 extension in its EncryptedExtensions message, as described in 475 Section 7.1, with the following payload: 477 struct { 478 ECHConfigList retry_configs; 479 } ECHEncryptedExtensions; 481 The response is valid only when the server used the ClientHelloOuter. 482 If the server sent this extension in response to the inner variant, 483 then the client MUST abort with an "unsupported_extension" alert. 485 retry_configs An ECHConfigList structure containing one or more 486 ECHConfig structures, in decreasing order of preference, to be 487 used by the client as described in Section 6.1.6. These are known 488 as the server's "retry configurations". 490 Finally, when the client offers the "encrypted_client_hello", if the 491 payload is the inner variant and the server responds with 492 HelloRetryRequest, it MUST include an "encrypted_client_hello" 493 extension with the following payload: 495 struct { 496 opaque confirmation[8]; 497 } ECHHelloRetryRequest; 499 The value of ECHHelloRetryRequest.confirmation is set to 500 hrr_accept_confirmation as described in Section 7.2.1. 502 This document also defines the "ech_required" alert, which the client 503 MUST send when it offered an "encrypted_client_hello" extension that 504 was not accepted by the server. (See Section 11.2.) 506 5.1. Encoding the ClientHelloInner 508 Before encrypting, the client pads and optionally compresses 509 ClientHelloInner into a EncodedClientHelloInner structure, defined 510 below: 512 struct { 513 ClientHello client_hello; 514 uint8 zeros[length_of_padding]; 515 } EncodedClientHelloInner; 517 The client_hello field is computed by first making a copy of 518 ClientHelloInner and setting the legacy_session_id field to the empty 519 string. Note this field uses the ClientHello structure, defined in 520 Section 4.1.2 of [RFC8446] which does not include the Handshake 521 structure's four byte header. The zeros field MUST be all zeroes. 523 Repeating large extensions, such as "key_share" with post-quantum 524 algorithms, between ClientHelloInner and ClientHelloOuter can lead to 525 excessive size. To reduce the size impact, the client MAY substitute 526 extensions which it knows will be duplicated in ClientHelloOuter. It 527 does so by removing and replacing extensions from 528 EncodedClientHelloInner with a single "ech_outer_extensions" 529 extension, defined as follows: 531 enum { 532 ech_outer_extensions(0xfd00), (65535) 533 } ExtensionType; 535 ExtensionType OuterExtensions<2..254>; 537 OuterExtensions contains the removed ExtensionType values. Each 538 value references the matching extension in ClientHelloOuter. The 539 values MUST be ordered contiguously in ClientHelloInner, and the 540 "ech_outer_extensions" extension MUST be inserted in the 541 corresponding position in EncodedClientHelloInner. Additionally, the 542 extensions MUST appear in ClientHelloOuter in the same relative 543 order. However, there is no requirement that they be contiguous. 544 For example, OuterExtensions may contain extensions A, B, C, while 545 ClientHelloOuter contains extensions A, D, B, C, E, F. 547 The "ech_outer_extensions" extension can only be included in 548 EncodedClientHelloInner, and MUST NOT appear in either 549 ClientHelloOuter or ClientHelloInner. 551 Finally, the client pads the message by setting the zeros field to a 552 byte string whose contents are all zeros and whose length is the 553 amount of padding to add. Section 6.1.3 describes a recommended 554 padding scheme. 556 The client-facing server computes ClientHelloInner by reversing this 557 process. First it parses EncodedClientHelloInner, interpreting all 558 bytes after client_hello as padding. If any padding byte is non- 559 zero, the server MUST abort the connection with an 560 "illegal_parameter" alert. 562 Next it makes a copy of the client_hello field and copies the 563 legacy_session_id field from ClientHelloOuter. It then looks for an 564 "ech_outer_extensions" extension. If found, it replaces the 565 extension with the corresponding sequence of extensions in the 566 ClientHelloOuter. The server MUST abort the connection with an 567 "illegal_parameter" alert if any of the following are true: 569 * Any referenced extension is missing in ClientHelloOuter. 571 * Any extension is referenced in OuterExtensions more than once. 573 * "encrypted_client_hello" is referenced in OuterExtensions. 575 * The extensions in ClientHelloOuter corresponding to those in 576 OuterExtensions do not occur in the same order. 578 These requirements prevent an attacker from performing a packet 579 amplification attack, by crafting a ClientHelloOuter which 580 decompresses to a much larger ClientHelloInner. This is discussed 581 further in Section 10.11.4. 583 Implementations SHOULD bound the time to compute a ClientHelloInner 584 proportionally to the ClientHelloOuter size. If the cost is 585 disproportionately large, a malicious client could exploit this in a 586 denial of service attack. Appendix B describes a linear-time 587 procedure that may be used for this purpose. 589 5.2. Authenticating the ClientHelloOuter 591 To prevent a network attacker from modifying the reconstructed 592 ClientHelloInner (see Section 10.11.3), ECH authenticates 593 ClientHelloOuter by passing ClientHelloOuterAAD as the associated 594 data for HPKE sealing and opening operations. The 595 ClientHelloOuterAAD is a serialized ClientHello structure, defined in 596 Section 4.1.2 of [RFC8446], which matches the ClientHelloOuter except 597 the payload field of the "encrypted_client_hello" is replaced with a 598 byte string of the same length but whose contents are zeros. This 599 value does not include the four-byte header from the Handshake 600 structure. 602 The client follows the procedure in Section 6.1.1 to first construct 603 ClientHelloOuterAAD with a placeholder payload field, then replace 604 the field with the encrypted value to compute ClientHelloOuter. 606 The server then receives ClientHelloOuter and computes 607 ClientHelloOuterAAD by making a copy and replacing the portion 608 corresponding to the payload field with zeros. 610 The payload and the placeholder strings have the same length, so it 611 is not necessary for either side to recompute length prefixes when 612 applying the above transformations. 614 The decompression process in Section 5.1 forbids 615 "encrypted_client_hello" in OuterExtensions. This ensures the 616 unauthenticated portion of ClientHelloOuter is not incorporated into 617 ClientHelloInner. 619 6. Client Behavior 621 Clients that implement the ECH extension behave in one of two ways: 622 either they offer a real ECH extension, as described in Section 6.1; 623 or they send a GREASE ECH extension, as described in Section 6.2. 624 Clients of the latter type do not negotiate ECH. Instead, they 625 generate a dummy ECH extension that is ignored by the server. (See 626 Section 10.9.4 for an explanation.) The client offers ECH if it is 627 in possession of a compatible ECH configuration and sends GREASE ECH 628 otherwise. 630 6.1. Offering ECH 632 To offer ECH, the client first chooses a suitable ECHConfig from the 633 server's ECHConfigList. To determine if a given ECHConfig is 634 suitable, it checks that it supports the KEM algorithm identified by 635 ECHConfig.contents.kem_id, at least one KDF/AEAD algorithm identified 636 by ECHConfig.contents.cipher_suites, and the version of ECH indicated 637 by ECHConfig.contents.version. Once a suitable configuration is 638 found, the client selects the cipher suite it will use for 639 encryption. It MUST NOT choose a cipher suite or version not 640 advertised by the configuration. If no compatible configuration is 641 found, then the client SHOULD proceed as described in Section 6.2. 643 Next, the client constructs the ClientHelloInner message just as it 644 does a standard ClientHello, with the exception of the following 645 rules: 647 1. It MUST NOT offer to negotiate TLS 1.2 or below. This is 648 necessary to ensure the backend server does not negotiate a TLS 649 version that is incompatible with ECH. 651 2. It MUST NOT offer to resume any session for TLS 1.2 and below. 653 3. If it intends to compress any extensions (see Section 5.1), it 654 MUST order those extensions consecutively. 656 4. It MUST include the "encrypted_client_hello" extension of type 657 inner as described in Section 5. (This requirement is not 658 applicable when the "encrypted_client_hello" extension is 659 generated as described in Section 6.2.) 661 The client then constructs EncodedClientHelloInner as described in 662 Section 5.1. It also computes an HPKE encryption context and enc 663 value as: 665 pkR = DeserializePublicKey(ECHConfig.contents.public_key) 666 enc, context = SetupBaseS(pkR, 667 "tls ech" || 0x00 || ECHConfig) 669 Next, it constructs a partial ClientHelloOuterAAD as it does a 670 standard ClientHello, with the exception of the following rules: 672 1. It MUST offer to negotiate TLS 1.3 or above. 674 2. If it compressed any extensions in EncodedClientHelloInner, it 675 MUST copy the corresponding extensions from ClientHelloInner. 676 The copied extensions additionally MUST be in the same relative 677 order as in ClientHelloInner. 679 3. It MUST copy the legacy_session_id field from ClientHelloInner. 680 This allows the server to echo the correct session ID for TLS 681 1.3's compatibility mode (see Appendix D.4 of [RFC8446]) when ECH 682 is negotiated. 684 4. It MAY copy any other field from the ClientHelloInner except 685 ClientHelloInner.random. Instead, It MUST generate a fresh 686 ClientHelloOuter.random using a secure random number generator. 687 (See Section 10.11.1.) 689 5. The value of ECHConfig.contents.public_name MUST be placed in the 690 "server_name" extension. 692 6. When the client offers the "pre_shared_key" extension in 693 ClientHelloInner, it SHOULD also include a GREASE 694 "pre_shared_key" extension in ClientHelloOuter, generated in the 695 manner described in Section 6.1.2. The client MUST NOT use this 696 extension to advertise a PSK to the client-facing server. (See 697 Section 10.11.3.) When the client includes a GREASE 698 "pre_shared_key" extension, it MUST also copy the 699 "psk_key_exchange_modes" from the ClientHelloInner into the 700 ClientHelloOuter. 702 7. When the client offers the "early_data" extension in 703 ClientHelloInner, it MUST also include the "early_data" extension 704 in ClientHelloOuter. This allows servers that reject ECH and use 705 ClientHelloOuter to safely ignore any early data sent by the 706 client per [RFC8446], Section 4.2.10. 708 Note that these rules may change in the presence of an application 709 profile specifying otherwise. 711 The client might duplicate non-sensitive extensions in both messages. 712 However, implementations need to take care to ensure that sensitive 713 extensions are not offered in the ClientHelloOuter. See Section 10.5 714 for additional guidance. 716 Finally, the client encrypts the EncodedClientHelloInner with the 717 above values, as described in Section 6.1.1, to construct a 718 ClientHelloOuter. It sends this to the server, and processes the 719 response as described in Section 6.1.4. 721 6.1.1. Encrypting the ClientHello 723 Given an EncodedClientHelloInner, an HPKE encryption context and enc 724 value, and a partial ClientHelloOuterAAD, the client constructs a 725 ClientHelloOuter as follows. 727 First, the client determines the length L of encrypting 728 EncodedClientHelloInner with the selected HPKE AEAD. This is 729 typically the sum of the plaintext length and the AEAD tag length. 730 The client then completes the ClientHelloOuterAAD with an 731 "encrypted_client_hello" extension. This extension value contains 732 the outer variant of ECHClientHello with the following fields: 734 * config_id, the identifier corresponding to the chosen ECHConfig 735 structure; 737 * cipher_suite, the client's chosen cipher suite; 739 * enc, as given above; and 741 * payload, a placeholder byte string containing L zeros. 743 If configuration identifiers (see Section 10.4) are to be ignored, 744 config_id SHOULD be set to a randomly generated byte in the first 745 ClientHelloOuter and, in the event of HRR, MUST be left unchanged for 746 the second ClientHelloOuter. 748 The client serializes this structure to construct the 749 ClientHelloOuterAAD. It then computes the final payload as: 751 final_payload = context.Seal(ClientHelloOuterAAD, 752 EncodedClientHelloInner) 754 Finally, the client replaces payload with final_payload to obtain 755 ClientHelloOuter. The two values have the same length, so it is not 756 necessary to recompute length prefixes in the serialized structure. 758 Note this construction requires the "encrypted_client_hello" be 759 computed after all other extensions. This is possible because the 760 ClientHelloOuter's "pre_shared_key" extension is either omitted, or 761 uses a random binder (Section 6.1.2). 763 6.1.2. GREASE PSK 765 When offering ECH, the client is not permitted to advertise PSK 766 identities in the ClientHelloOuter. However, the client can send a 767 "pre_shared_key" extension in the ClientHelloInner. In this case, 768 when resuming a session with the client, the backend server sends a 769 "pre_shared_key" extension in its ServerHello. This would appear to 770 a network observer as if the the server were sending this extension 771 without solicitation, which would violate the extension rules 772 described in [RFC8446]. Sending a GREASE "pre_shared_key" extension 773 in the ClientHelloOuter makes it appear to the network as if the 774 extension were negotiated properly. 776 The client generates the extension payload by constructing an 777 OfferedPsks structure (see [RFC8446], Section 4.2.11) as follows. 778 For each PSK identity advertised in the ClientHelloInner, the client 779 generates a random PSK identity with the same length. It also 780 generates a random, 32-bit, unsigned integer to use as the 781 obfuscated_ticket_age. Likewise, for each inner PSK binder, the 782 client generates a random string of the same length. 784 Per the rules of Section 6.1, the server is not permitted to resume a 785 connection in the outer handshake. If ECH is rejected and the 786 client-facing server replies with a "pre_shared_key" extension in its 787 ServerHello, then the client MUST abort the handshake with an 788 "illegal_parameter" alert. 790 6.1.3. Recommended Padding Scheme 792 This section describes a deterministic padding mechanism based on the 793 following observation: individual extensions can reveal sensitive 794 information through their length. Thus, each extension in the inner 795 ClientHello may require different amounts of padding. This padding 796 may be fully determined by the client's configuration or may require 797 server input. 799 By way of example, clients typically support a small number of 800 application profiles. For instance, a browser might support HTTP 801 with ALPN values ["http/1.1", "h2"] and WebRTC media with ALPNs 803 ["webrtc", "c-webrtc"]. Clients SHOULD pad this extension by 804 rounding up to the total size of the longest ALPN extension across 805 all application profiles. The target padding length of most 806 ClientHello extensions can be computed in this way. 808 In contrast, clients do not know the longest SNI value in the client- 809 facing server's anonymity set without server input. Clients SHOULD 810 use the ECHConfig's maximum_name_length field as follows, where L is 811 the maximum_name_length value. 813 1. If the ClientHelloInner contained a "server_name" extension with 814 a name of length D, add max(0, L - D) bytes of padding. 816 2. If the ClientHelloInner did not contain a "server_name" extension 817 (e.g., if the client is connecting to an IP address), add L + 9 818 bytes of padding. This is the length of a "server_name" 819 extension with an L-byte name. 821 Finally, the client SHOULD pad the entire message as follows: 823 1. Let L be the length of the EncodedClientHelloInner with all the 824 padding computed so far. 826 2. Let N = 31 - ((L - 1) % 32) and add N bytes of padding. 828 This rounds the length of EncodedClientHelloInner up to a multiple of 829 32 bytes, reducing the set of possible lengths across all clients. 831 In addition to padding ClientHelloInner, clients and servers will 832 also need to pad all other handshake messages that have sensitive- 833 length fields. For example, if a client proposes ALPN values in 834 ClientHelloInner, the server-selected value will be returned in an 835 EncryptedExtension, so that handshake message also needs to be padded 836 using TLS record layer padding. 838 6.1.4. Determining ECH Acceptance 840 As described in Section 7, the server may either accept ECH and use 841 ClientHelloInner or reject it and use ClientHelloOuter. This is 842 determined by the server's initial message. 844 If the message does not negotiate TLS 1.3 or higher, the server has 845 rejected ECH. Otherwise, it is either a ServerHello or 846 HelloRetryRequest. 848 If the message is a ServerHello, the client computes 849 accept_confirmation as described in Section 7.2. If this value 850 matches the last 8 bytes of ServerHello.random, the server has 851 accepted ECH. Otherwise, it has rejected ECH. 853 If the message is a HelloRetryRequest, the client checks for the 854 "encrypted_client_hello" extension. If none is found, the server has 855 rejected ECH. Otherwise, if it has a length other than 8, the client 856 aborts the handshake with a "decode_error" alert. Otherwise, the 857 client computes hrr_accept_confirmation as described in 858 Section 7.2.1. If this value matches the extension payload, the 859 server has accepted ECH. Otherwise, it has rejected ECH. 861 [[OPEN ISSUE: Depending on what we do for issue#450, it may be 862 appropriate to change the client behavior if the HRR extension is 863 present but with the wrong value.]] 865 If the server accepts ECH, the client handshakes with 866 ClientHelloInner as described in Section 6.1.5. Otherwise, the 867 client handshakes with ClientHelloOuter as described in 868 Section 6.1.6. 870 6.1.5. Handshaking with ClientHelloInner 872 If the server accepts ECH, the client proceeds with the connection as 873 in [RFC8446], with the following modifications: 875 The client behaves as if it had sent ClientHelloInner as the 876 ClientHello. That is, it evaluates the handshake using the 877 ClientHelloInner's preferences, and, when computing the transcript 878 hash (Section 4.4.1 of [RFC8446]), it uses ClientHelloInner as the 879 first ClientHello. 881 If the server responds with a HelloRetryRequest, the client computes 882 the updated ClientHello message as follows: 884 1. It computes a second ClientHelloInner based on the first 885 ClientHelloInner, as in Section 4.1.4 of [RFC8446]. The 886 ClientHelloInner's "encrypted_client_hello" extension is left 887 unmodified. 889 2. It constructs EncodedClientHelloInner as described in 890 Section 5.1. 892 3. It constructs a second partial ClientHelloOuterAAD message. This 893 message MUST be syntactically valid. The extensions MAY be 894 copied from the original ClientHelloOuter unmodified, or omitted. 895 If not sensitive, the client MAY copy updated extensions from the 896 second ClientHelloInner for compression. 898 4. It encrypts EncodedClientHelloInner as described in 899 Section 6.1.1, using the second partial ClientHelloOuterAAD, to 900 obtain a second ClientHelloOuter. It reuses the original HPKE 901 encryption context computed in Section 6.1 and uses the empty 902 string for enc. 904 The HPKE context maintains a sequence number, so this operation 905 internally uses a fresh nonce for each AEAD operation. Reusing 906 the HPKE context avoids an attack described in Section 10.11.2. 908 The client then sends the second ClientHelloOuter to the server. 909 However, as above, it uses the second ClientHelloInner for 910 preferences, and both the ClientHelloInner messages for the 911 transcript hash. Additionally, it checks the resulting ServerHello 912 for ECH acceptance as in Section 6.1.4. If the ServerHello does not 913 also indicate ECH acceptance, the client MUST terminate the 914 connection with an "illegal_parameter" alert. 916 6.1.6. Handshaking with ClientHelloOuter 918 If the server rejects ECH, the client proceeds with the handshake, 919 authenticating for ECHConfig.contents.public_name as described in 920 Section 6.1.7. If authentication or the handshake fails, the client 921 MUST return a failure to the calling application. It MUST NOT use 922 the retry configurations. It MUST NOT treat this as a secure signal 923 to disable ECH. 925 If the server supplied an "encrypted_client_hello" extension in its 926 EncryptedExtensions message, the client MUST check that it is 927 syntactically valid and the client MUST abort the connection with a 928 "decode_error" alert otherwise. If an earlier TLS version was 929 negotiated, the client MUST NOT enable the False Start optimization 930 [RFC7918] for this handshake. If both authentication and the 931 handshake complete successfully, the client MUST perform the 932 processing described below then abort the connection with an 933 "ech_required" alert before sending any application data to the 934 server. 936 If the server provided "retry_configs" and if at least one of the 937 values contains a version supported by the client, the client can 938 regard the ECH keys as securely replaced by the server. It SHOULD 939 retry the handshake with a new transport connection, using the retry 940 configurations supplied by the server. The retry configurations may 941 only be applied to the retry connection. The client MUST NOT use 942 retry configurations for connections beyond the retry. This avoids 943 introducing pinning concerns or a tracking vector, should a malicious 944 server present client-specific retry configurations in order to 945 identify the client in a subsequent ECH handshake. 947 If none of the values provided in "retry_configs" contains a 948 supported version, or an earlier TLS version was negotiated, the 949 client can regard ECH as securely disabled by the server, and it 950 SHOULD retry the handshake with a new transport connection and ECH 951 disabled. 953 Clients SHOULD implement a limit on retries caused by receipt of 954 "retry_configs" or servers which do not acknowledge the 955 "encrypted_client_hello" extension. If the client does not retry in 956 either scenario, it MUST report an error to the calling application. 958 6.1.7. Authenticating for the Public Name 960 When the server rejects ECH, it continues with the handshake using 961 the plaintext "server_name" extension instead (see Section 7). 962 Clients that offer ECH then authenticate the connection with the 963 public name, as follows: 965 * The client MUST verify that the certificate is valid for 966 ECHConfig.contents.public_name. If invalid, it MUST abort the 967 connection with the appropriate alert. 969 * If the server requests a client certificate, the client MUST 970 respond with an empty Certificate message, denoting no client 971 certificate. 973 In verifying the client-facing server certificate, the client MUST 974 interpret the public name as a DNS-based reference identity. Clients 975 that incorporate DNS names and IP addresses into the same syntax 976 (e.g. [RFC3986], Section 7.4 and [WHATWG-IPV4]) MUST reject names 977 that would be interpreted as IPv4 addresses. Clients that enforce 978 this by checking and rejecting encoded IPv4 addresses in 979 ECHConfig.contents.public_name do not need to repeat the check at 980 this layer. 982 Note that authenticating a connection for the public name does not 983 authenticate it for the origin. The TLS implementation MUST NOT 984 report such connections as successful to the application. It 985 additionally MUST ignore all session tickets and session IDs 986 presented by the server. These connections are only used to trigger 987 retries, as described in Section 6.1.6. This may be implemented, for 988 instance, by reporting a failed connection with a dedicated error 989 code. 991 6.2. GREASE ECH 993 If the client attempts to connect to a server and does not have an 994 ECHConfig structure available for the server, it SHOULD send a GREASE 995 [RFC8701] "encrypted_client_hello" extension in the first ClientHello 996 as follows: 998 * Set the config_id field to a random byte. 1000 * Set the cipher_suite field to a supported 1001 HpkeSymmetricCipherSuite. The selection SHOULD vary to exercise 1002 all supported configurations, but MAY be held constant for 1003 successive connections to the same server in the same session. 1005 * Set the enc field to a randomly-generated valid encapsulated 1006 public key output by the HPKE KEM. 1008 * Set the payload field to a randomly-generated string of L+C bytes, 1009 where C is the ciphertext expansion of the selected AEAD scheme 1010 and L is the size of the EncodedClientHelloInner the client would 1011 compute when offering ECH, padded according to Section 6.1.3. 1013 If sending a second ClientHello in response to a HelloRetryRequest, 1014 the client copies the entire "encrypted_client_hello" extension from 1015 the first ClientHello. The identical value will reveal to an 1016 observer that the value of "encrypted_client_hello" was fake, but 1017 this only occurs if there is a HelloRetryRequest. 1019 If the server sends an "encrypted_client_hello" extension in either 1020 HelloRetryRequest or EncryptedExtensions, the client MUST check the 1021 extension syntactically and abort the connection with a 1022 "decode_error" alert if it is invalid. It otherwise ignores the 1023 extension. It MUST NOT save the "retry_config" value in 1024 EncryptedExtensions. 1026 Offering a GREASE extension is not considered offering an encrypted 1027 ClientHello for purposes of requirements in Section 6.1. In 1028 particular, the client MAY offer to resume sessions established 1029 without ECH. 1031 7. Server Behavior 1033 Servers that support ECH play one of two roles, depending on the 1034 payload of the "encrypted_client_hello" extension in the initial 1035 ClientHello: 1037 * If ECHClientHello.type is outer, then the server acts as a client- 1038 facing server and proceeds as described in Section 7.1 to extract 1039 a ClientHelloInner, if available. 1041 * If ECHClientHello.type is inner, then the server acts as a backend 1042 server and proceeds as described in Section 7.2. 1044 * Otherwise, if ECHClientHello.type is not a valid 1045 ECHClientHelloType, then the server MUST abort with an 1046 "illegal_parameter" alert. 1048 If the "encrypted_client_hello" is not present, then the server 1049 completes the handshake normally, as described in [RFC8446]. 1051 7.1. Client-Facing Server 1053 Upon receiving an "encrypted_client_hello" extension in an initial 1054 ClientHello, the client-facing server determines if it will accept 1055 ECH, prior to negotiating any other TLS parameters. Note that 1056 successfully decrypting the extension will result in a new 1057 ClientHello to process, so even the client's TLS version preferences 1058 may have changed. 1060 First, the server collects a set of candidate ECHConfig values. This 1061 list is determined by one of the two following methods: 1063 1. Compare ECHClientHello.config_id against identifiers of each 1064 known ECHConfig and select the ones that match, if any, as 1065 candidates. 1067 2. Collect all known ECHConfig values as candidates, with trial 1068 decryption below determining the final selection. 1070 Some uses of ECH, such as local discovery mode, may randomize the 1071 ECHClientHello.config_id since it can be used as a tracking vector. 1072 In such cases, the second method should be used for matching the 1073 ECHClientHello to a known ECHConfig. See Section 10.4. Unless 1074 specified by the application profile or otherwise externally 1075 configured, implementations MUST use the first method. 1077 The server then iterates over the candidate ECHConfig values, 1078 attempting to decrypt the "encrypted_client_hello" extension: 1080 The server verifies that the ECHConfig supports the cipher suite 1081 indicated by the ECHClientHello.cipher_suite and that the version of 1082 ECH indicated by the client matches the ECHConfig.version. If not, 1083 the server continues to the next candidate ECHConfig. 1085 Next, the server decrypts ECHClientHello.payload, using the private 1086 key skR corresponding to ECHConfig, as follows: 1088 context = SetupBaseR(ECHClientHello.enc, skR, 1089 "tls ech" || 0x00 || ECHConfig) 1090 EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, 1091 ECHClientHello.payload) 1093 ClientHelloOuterAAD is computed from ClientHelloOuter as described in 1094 Section 5.2. The info parameter to SetupBaseR is the concatenation 1095 "tls ech", a zero byte, and the serialized ECHConfig. If decryption 1096 fails, the server continues to the next candidate ECHConfig. 1097 Otherwise, the server reconstructs ClientHelloInner from 1098 EncodedClientHelloInner, as described in Section 5.1. It then stops 1099 iterating over the candidate ECHConfig values. 1101 Upon determining the ClientHelloInner, the client-facing server 1102 checks that the message includes a well-formed 1103 "encrypted_client_hello" extension of type inner and that it does not 1104 offer TLS 1.2 or below. If either of these checks fails, the client- 1105 facing server MUST abort with an "illegal_parameter" alert. 1107 If these checks succeed, the client-facing server then forwards the 1108 ClientHelloInner to the appropriate backend server, which proceeds as 1109 in Section 7.2. If the backend server responds with a 1110 HelloRetryRequest, the client-facing server forwards it, decrypts the 1111 client's second ClientHelloOuter using the procedure in 1112 Section 7.1.1, and forwards the resulting second ClientHelloInner. 1113 The client-facing server forwards all other TLS messages between the 1114 client and backend server unmodified. 1116 Otherwise, if all candidate ECHConfig values fail to decrypt the 1117 extension, the client-facing server MUST ignore the extension and 1118 proceed with the connection using ClientHelloOuter, with the 1119 following modifications: 1121 * If sending a HelloRetryRequest, the server MAY include an 1122 "encrypted_client_hello" extension with a payload of 8 random 1123 bytes; see Section 10.9.4 for details. 1125 * If the server is configured with any ECHConfigs, it MUST include 1126 the "encrypted_client_hello" extension in its EncryptedExtensions 1127 with the "retry_configs" field set to one or more ECHConfig 1128 structures with up-to-date keys. Servers MAY supply multiple 1129 ECHConfig values of different versions. This allows a server to 1130 support multiple versions at once. 1132 Note that decryption failure could indicate a GREASE ECH extension 1133 (see Section 6.2), so it is necessary for servers to proceed with the 1134 connection and rely on the client to abort if ECH was required. In 1135 particular, the unrecognized value alone does not indicate a 1136 misconfigured ECH advertisement (Section 8.1). Instead, servers can 1137 measure occurrences of the "ech_required" alert to detect this case. 1139 7.1.1. Sending HelloRetryRequest 1141 After sending or forwarding a HelloRetryRequest, the client-facing 1142 server does not repeat the steps in Section 7.1 with the second 1143 ClientHelloOuter. Instead, it continues with the ECHConfig selection 1144 from the first ClientHelloOuter as follows: 1146 If the client-facing server accepted ECH, it checks the second 1147 ClientHelloOuter also contains the "encrypted_client_hello" 1148 extension. If not, it MUST abort the handshake with a 1149 "missing_extension" alert. Otherwise, it checks that 1150 ECHClientHello.cipher_suite and ECHClientHello.config_id are 1151 unchanged, and that ECHClientHello.enc is empty. If not, it MUST 1152 abort the handshake with an "illegal_parameter" alert. 1154 Finally, it decrypts the new ECHClientHello.payload as a second 1155 message with the previous HPKE context: 1157 EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, 1158 ECHClientHello.payload) 1160 ClientHelloOuterAAD is computed as described in Section 5.2, but 1161 using the second ClientHelloOuter. If decryption fails, the client- 1162 facing server MUST abort the handshake with a "decrypt_error" alert. 1163 Otherwise, it reconstructs the second ClientHelloInner from the new 1164 EncodedClientHelloInner as described in Section 5.1, using the second 1165 ClientHelloOuter for any referenced extensions. 1167 The client-facing server then forwards the resulting ClientHelloInner 1168 to the backend server. It forwards all subsequent TLS messages 1169 between the client and backend server unmodified. 1171 If the client-facing server rejected ECH, or if the first ClientHello 1172 did not include an "encrypted_client_hello" extension, the client- 1173 facing server proceeds with the connection as usual. The server does 1174 not decrypt the second ClientHello's ECHClientHello.payload value, if 1175 there is one. Moreover, if the server is configured with any 1176 ECHConfigs, it MUST include the "encrypted_client_hello" extension in 1177 its EncryptedExtensions with the "retry_configs" field set to one or 1178 more ECHConfig structures with up-to-date keys, as described in 1179 Section 7.1. 1181 Note that a client-facing server that forwards the first ClientHello 1182 cannot include its own "cookie" extension if the backend server sends 1183 a HelloRetryRequest. This means that the client-facing server either 1184 needs to maintain state for such a connection or it needs to 1185 coordinate with the backend server to include any information it 1186 requires to process the second ClientHello. 1188 7.2. Backend Server 1190 Upon receipt of an "encrypted_client_hello" extension of type inner 1191 in a ClientHello, if the backend server negotiates TLS 1.3 or higher, 1192 then it MUST confirm ECH acceptance to the client by computing its 1193 ServerHello as described here. 1195 The backend server embeds in ServerHello.random a string derived from 1196 the inner handshake. It begins by computing its ServerHello as 1197 usual, except the last 8 bytes of ServerHello.random are set to zero. 1198 It then computes the transcript hash for ClientHelloInner up to and 1199 including the modified ServerHello, as described in [RFC8446], 1200 Section 4.4.1. Let transcript_ech_conf denote the output. Finally, 1201 the backend server overwrites the last 8 bytes of the 1202 ServerHello.random with the following string: 1204 accept_confirmation = HKDF-Expand-Label( 1205 HKDF-Extract(0, ClientHelloInner.random), 1206 "ech accept confirmation", 1207 transcript_ech_conf, 1208 8) 1210 where HKDF-Expand-Label is defined in [RFC8446], Section 7.1, "0" 1211 indicates a string of Hash.length bytes set to zero, and Hash is the 1212 hash function used to compute the transcript hash. 1214 The backend server MUST NOT perform this operation if it negotiated 1215 TLS 1.2 or below. Note that doing so would overwrite the downgrade 1216 signal for TLS 1.3 (see [RFC8446], Section 4.1.3). 1218 7.2.1. Sending HelloRetryRequest 1220 When the backend server sends HelloRetryRequest in response to the 1221 ClientHello, it similarly confirms ECH acceptance by adding a 1222 confirmation signal to its HelloRetryRequest. But instead of 1223 embedding the signal in the HelloRetryRequest.random (the value of 1224 which is specified by [RFC8446]), it sends the signal in an 1225 extension. 1227 The backend server begins by computing HelloRetryRequest as usual, 1228 except that it also contains an "encrypted_client_hello" extension 1229 with a payload of 8 zero bytes. It then computes the transcript hash 1230 for the first ClientHelloInner, denoted ClientHelloInner1, up to and 1231 including the modified HelloRetryRequest. Let 1232 transcript_hrr_ech_conf denote the output. Finally, the backend 1233 server overwrites the payload of the "encrypted_client_hello" 1234 extension with the following string: 1236 hrr_accept_confirmation = HKDF-Expand-Label( 1237 HKDF-Extract(0, ClientHelloInner1.random), 1238 "hrr ech accept confirmation", 1239 transcript_hrr_ech_conf, 1240 8) 1242 In the subsequent ServerHello message, the backend server sends the 1243 accept_confirmation value as described in Section 7.2. 1245 8. Compatibility Issues 1247 Unlike most TLS extensions, placing the SNI value in an ECH extension 1248 is not interoperable with existing servers, which expect the value in 1249 the existing plaintext extension. Thus server operators SHOULD 1250 ensure servers understand a given set of ECH keys before advertising 1251 them. Additionally, servers SHOULD retain support for any 1252 previously-advertised keys for the duration of their validity. 1254 However, in more complex deployment scenarios, this may be difficult 1255 to fully guarantee. Thus this protocol was designed to be robust in 1256 case of inconsistencies between systems that advertise ECH keys and 1257 servers, at the cost of extra round-trips due to a retry. Two 1258 specific scenarios are detailed below. 1260 8.1. Misconfiguration and Deployment Concerns 1262 It is possible for ECH advertisements and servers to become 1263 inconsistent. This may occur, for instance, from DNS 1264 misconfiguration, caching issues, or an incomplete rollout in a 1265 multi-server deployment. This may also occur if a server loses its 1266 ECH keys, or if a deployment of ECH must be rolled back on the 1267 server. 1269 The retry mechanism repairs inconsistencies, provided the server is 1270 authoritative for the public name. If server and advertised keys 1271 mismatch, the server will reject ECH and respond with 1272 "retry_configs". If the server does not understand the 1273 "encrypted_client_hello" extension at all, it will ignore it as 1274 required by Section 4.1.2 of [RFC8446]. Provided the server can 1275 present a certificate valid for the public name, the client can 1276 safely retry with updated settings, as described in Section 6.1.6. 1278 Unless ECH is disabled as a result of successfully establishing a 1279 connection to the public name, the client MUST NOT fall back to using 1280 unencrypted ClientHellos, as this allows a network attacker to 1281 disclose the contents of this ClientHello, including the SNI. It MAY 1282 attempt to use another server from the DNS results, if one is 1283 provided. 1285 8.2. Middleboxes 1287 When connecting through a TLS-terminating proxy that does not support 1288 this extension, [RFC8446], Section 9.3 requires the proxy still act 1289 as a conforming TLS client and server. The proxy must ignore unknown 1290 parameters, and generate its own ClientHello containing only 1291 parameters it understands. Thus, when presenting a certificate to 1292 the client or sending a ClientHello to the server, the proxy will act 1293 as if connecting to the public name, without echoing the 1294 "encrypted_client_hello" extension. 1296 Depending on whether the client is configured to accept the proxy's 1297 certificate as authoritative for the public name, this may trigger 1298 the retry logic described in Section 6.1.6 or result in a connection 1299 failure. A proxy which is not authoritative for the public name 1300 cannot forge a signal to disable ECH. 1302 9. Compliance Requirements 1304 In the absence of an application profile standard specifying 1305 otherwise, a compliant ECH application MUST implement the following 1306 HPKE cipher suite: 1308 * KEM: DHKEM(X25519, HKDF-SHA256) (see [I-D.irtf-cfrg-hpke], 1309 Section 7.1) 1311 * KDF: HKDF-SHA256 (see [I-D.irtf-cfrg-hpke], Section 7.2) 1313 * AEAD: AES-128-GCM (see [I-D.irtf-cfrg-hpke], Section 7.3) 1315 10. Security Considerations 1317 10.1. Security and Privacy Goals 1319 ECH considers two types of attackers: passive and active. Passive 1320 attackers can read packets from the network, but they cannot perform 1321 any sort of active behavior such as probing servers or querying DNS. 1322 A middlebox that filters based on plaintext packet contents is one 1323 example of a passive attacker. In contrast, active attackers can 1324 also write packets into the network for malicious purposes, such as 1325 interfering with existing connections, probing servers, and querying 1326 DNS. In short, an active attacker corresponds to the conventional 1327 threat model for TLS 1.3 [RFC8446]. 1329 Given these types of attackers, the primary goals of ECH are as 1330 follows. 1332 1. Use of ECH does not weaken the security properties of TLS without 1333 ECH. 1335 2. TLS connection establishment to a host with a specific ECHConfig 1336 and TLS configuration is indistinguishable from a connection to 1337 any other host with the same ECHConfig and TLS configuration. 1338 (The set of hosts which share the same ECHConfig and TLS 1339 configuration is referred to as the anonymity set.) 1341 Client-facing server configuration determines the size of the 1342 anonymity set. For example, if a client-facing server uses distinct 1343 ECHConfig values for each host, then each anonymity set has size k = 1344 1. Client-facing servers SHOULD deploy ECH in such a way so as to 1345 maximize the size of the anonymity set where possible. This means 1346 client-facing servers should use the same ECHConfig for as many hosts 1347 as possible. An attacker can distinguish two hosts that have 1348 different ECHConfig values based on the ECHClientHello.config_id 1349 value. This also means public information in a TLS handshake should 1350 be consistent across hosts. For example, if a client-facing server 1351 services many backend origin hosts, only one of which supports some 1352 cipher suite, it may be possible to identify that host based on the 1353 contents of unencrypted handshake messages. 1355 Beyond these primary security and privacy goals, ECH also aims to 1356 hide, to some extent, the fact that it is being used at all. 1357 Specifically, the GREASE ECH extension described in Section 6.2 does 1358 not change the security properties of the TLS handshake at all. Its 1359 goal is to provide "cover" for the real ECH protocol (Section 6.1), 1360 as a means of addressing the "do not stick out" requirements of 1361 [RFC8744]. See Section 10.9.4 for details. 1363 10.2. Unauthenticated and Plaintext DNS 1365 In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource 1366 Records are signed via a server private key, ECH records have no 1367 authenticity or provenance information. This means that any attacker 1368 which can inject DNS responses or poison DNS caches, which is a 1369 common scenario in client access networks, can supply clients with 1370 fake ECH records (so that the client encrypts data to them) or strip 1371 the ECH record from the response. However, in the face of an 1372 attacker that controls DNS, no encryption scheme can work because the 1373 attacker can replace the IP address, thus blocking client 1374 connections, or substitute a unique IP address which is 1:1 with the 1375 DNS name that was looked up (modulo DNS wildcards). Thus, allowing 1376 the ECH records in the clear does not make the situation 1377 significantly worse. 1379 Clearly, DNSSEC (if the client validates and hard fails) is a defense 1380 against this form of attack, but DoH/DPRIVE are also defenses against 1381 DNS attacks by attackers on the local network, which is a common case 1382 where ClientHello and SNI encryption are desired. Moreover, as noted 1383 in the introduction, SNI encryption is less useful without encryption 1384 of DNS queries in transit via DoH or DPRIVE mechanisms. 1386 10.3. Client Tracking 1388 A malicious client-facing server could distribute unique, per-client 1389 ECHConfig structures as a way of tracking clients across subsequent 1390 connections. On-path adversaries which know about these unique keys 1391 could also track clients in this way by observing TLS connection 1392 attempts. 1394 The cost of this type of attack scales linearly with the desired 1395 number of target clients. Moreover, DNS caching behavior makes 1396 targeting individual users for extended periods of time, e.g., using 1397 per-client ECHConfig structures delivered via HTTPS RRs with high 1398 TTLs, challenging. Clients can help mitigate this problem by 1399 flushing any DNS or ECHConfig state upon changing networks. 1401 10.4. Ignored Configuration Identifiers and Trial Decryption 1403 Ignoring configuration identifiers may be useful in scenarios where 1404 clients and client-facing servers do not want to reveal information 1405 about the client-facing server in the "encrypted_client_hello" 1406 extension. In such settings, clients send a randomly generated 1407 config_id in the ECHClientHello. Servers in these settings must 1408 perform trial decryption since they cannot identify the client's 1409 chosen ECH key using the config_id value. As a result, ignoring 1410 configuration identifiers may exacerbate DoS attacks. Specifically, 1411 an adversary may send malicious ClientHello messages, i.e., those 1412 which will not decrypt with any known ECH key, in order to force 1413 wasteful decryption. Servers that support this feature should, for 1414 example, implement some form of rate limiting mechanism to limit the 1415 potential damage caused by such attacks. 1417 Unless specified by the application using (D)TLS or externally 1418 configured, implementations MUST NOT use this mode. 1420 10.5. Outer ClientHello 1422 Any information that the client includes in the ClientHelloOuter is 1423 visible to passive observers. The client SHOULD NOT send values in 1424 the ClientHelloOuter which would reveal a sensitive ClientHelloInner 1425 property, such as the true server name. It MAY send values 1426 associated with the public name in the ClientHelloOuter. 1428 In particular, some extensions require the client send a server-name- 1429 specific value in the ClientHello. These values may reveal 1430 information about the true server name. For example, the 1431 "cached_info" ClientHello extension [RFC7924] can contain the hash of 1432 a previously observed server certificate. The client SHOULD NOT send 1433 values associated with the true server name in the ClientHelloOuter. 1434 It MAY send such values in the ClientHelloInner. 1436 A client may also use different preferences in different contexts. 1437 For example, it may send a different ALPN lists to different servers 1438 or in different application contexts. A client that treats this 1439 context as sensitive SHOULD NOT send context-specific values in 1440 ClientHelloOuter. 1442 Values which are independent of the true server name, or other 1443 information the client wishes to protect, MAY be included in 1444 ClientHelloOuter. If they match the corresponding ClientHelloInner, 1445 they MAY be compressed as described in Section 5.1. However, note 1446 the payload length reveals information about which extensions are 1447 compressed, so inner extensions which only sometimes match the 1448 corresponding outer extension SHOULD NOT be compressed. 1450 Clients MAY include additional extensions in ClientHelloOuter to 1451 avoid signaling unusual behavior to passive observers, provided the 1452 choice of value and value itself are not sensitive. See 1453 Section 10.9.4. 1455 10.6. Related Privacy Leaks 1457 ECH requires encrypted DNS to be an effective privacy protection 1458 mechanism. However, verifying the server's identity from the 1459 Certificate message, particularly when using the X509 1460 CertificateType, may result in additional network traffic that may 1461 reveal the server identity. Examples of this traffic may include 1462 requests for revocation information, such as OCSP or CRL traffic, or 1463 requests for repository information, such as 1464 authorityInformationAccess. It may also include implementation- 1465 specific traffic for additional information sources as part of 1466 verification. 1468 Implementations SHOULD avoid leaking information that may identify 1469 the server. Even when sent over an encrypted transport, such 1470 requests may result in indirect exposure of the server's identity, 1471 such as indicating a specific CA or service being used. To mitigate 1472 this risk, servers SHOULD deliver such information in-band when 1473 possible, such as through the use of OCSP stapling, and clients 1474 SHOULD take steps to minimize or protect such requests during 1475 certificate validation. 1477 Attacks that rely on non-ECH traffic to infer server identity in an 1478 ECH connection are out of scope for this document. For example, a 1479 client that connects to a particular host prior to ECH deployment may 1480 later resume a connection to that same host after ECH deployment. An 1481 adversary that observes this can deduce that the ECH-enabled 1482 connection was made to a host that the client previously connected to 1483 and which is within the same anonymity set. 1485 10.7. Cookies 1487 Section 4.2.2 of [RFC8446] defines a cookie value that servers may 1488 send in HelloRetryRequest for clients to echo in the second 1489 ClientHello. While ECH encrypts the cookie in the second 1490 ClientHelloInner, the backend server's HelloRetryRequest is 1491 unencrypted.This means differences in cookies between backend 1492 servers, such as lengths or cleartext components, may leak 1493 information about the server identity. 1495 Backend servers in an anonymity set SHOULD NOT reveal information in 1496 the cookie which identifies the server. This may be done by handling 1497 HelloRetryRequest statefully, thus not sending cookies, or by using 1498 the same cookie construction for all backend servers. 1500 Note that, if the cookie includes a key name, analogous to Section 4 1501 of [RFC5077], this may leak information if different backend servers 1502 issue cookies with different key names at the time of the connection. 1503 In particular, if the deployment operates in Split Mode, the backend 1504 servers may not share cookie encryption keys. Backend servers may 1505 mitigate this by either handling key rotation with trial decryption, 1506 or coordinating to match key names. 1508 10.8. Attacks Exploiting Acceptance Confirmation 1510 To signal acceptance, the backend server overwrites 8 bytes of its 1511 ServerHello.random with a value derived from the 1512 ClientHelloInner.random. (See Section 7.2 for details.) This 1513 behavior increases the likelihood of the ServerHello.random colliding 1514 with the ServerHello.random of a previous session, potentially 1515 reducing the overall security of the protocol. However, the 1516 remaining 24 bytes provide enough entropy to ensure this is not a 1517 practical avenue of attack. 1519 On the other hand, the probability that two 8-byte strings are the 1520 same is non-negligible. This poses a modest operational risk. 1521 Suppose the client-facing server terminates the connection (i.e., ECH 1522 is rejected or bypassed): if the last 8 bytes of its 1523 ServerHello.random coincide with the confirmation signal, then the 1524 client will incorrectly presume acceptance and proceed as if the 1525 backend server terminated the connection. However, the probability 1526 of a false positive occurring for a given connection is only 1 in 1527 2^64. This value is smaller than the probability of network 1528 connection failures in practice. 1530 Note that the same bytes of the ServerHello.random are used to 1531 implement downgrade protection for TLS 1.3 (see [RFC8446], 1532 Section 4.1.3). These mechanisms do not interfere because the 1533 backend server only signals ECH acceptance in TLS 1.3 or higher. 1535 10.9. Comparison Against Criteria 1537 [RFC8744] lists several requirements for SNI encryption. In this 1538 section, we re-iterate these requirements and assess the ECH design 1539 against them. 1541 10.9.1. Mitigate Cut-and-Paste Attacks 1543 Since servers process either ClientHelloInner or ClientHelloOuter, 1544 and because ClientHelloInner.random is encrypted, it is not possible 1545 for an attacker to "cut and paste" the ECH value in a different 1546 Client Hello and learn information from ClientHelloInner. 1548 10.9.2. Avoid Widely Shared Secrets 1550 This design depends upon DNS as a vehicle for semi-static public key 1551 distribution. Server operators may partition their private keys 1552 however they see fit provided each server behind an IP address has 1553 the corresponding private key to decrypt a key. Thus, when one ECH 1554 key is provided, sharing is optimally bound by the number of hosts 1555 that share an IP address. Server operators may further limit sharing 1556 by publishing different DNS records containing ECHConfig values with 1557 different keys using a short TTL. 1559 10.9.3. Prevent SNI-Based Denial-of-Service Attacks 1561 This design requires servers to decrypt ClientHello messages with 1562 ECHClientHello extensions carrying valid digests. Thus, it is 1563 possible for an attacker to force decryption operations on the 1564 server. This attack is bound by the number of valid TCP connections 1565 an attacker can open. 1567 10.9.4. Do Not Stick Out 1569 As a means of reducing the impact of network ossification, [RFC8744] 1570 recommends SNI-protection mechanisms be designed in such a way that 1571 network operators do not differentiate connections using the 1572 mechanism from connections not using the mechanism. To that end, ECH 1573 is designed to resemble a standard TLS handshake as much as possible. 1574 The most obvious difference is the extension itself: as long as 1575 middleboxes ignore it, as required by [RFC8446], the rest of the 1576 handshake is designed to look very much as usual. 1578 The GREASE ECH protocol described in Section 6.2 provides a low-risk 1579 way to evaluate the deployability of ECH. It is designed to mimic 1580 the real ECH protocol (Section 6.1) without changing the security 1581 properties of the handshake. The underlying theory is that if GREASE 1582 ECH is deployable without triggering middlebox misbehavior, and real 1583 ECH looks enough like GREASE ECH, then ECH should be deployable as 1584 well. Thus, our strategy for mitigating network ossification is to 1585 deploy GREASE ECH widely enough to disincentivize differential 1586 treatment of the real ECH protocol by the network. 1588 Ensuring that networks do not differentiate between real ECH and 1589 GREASE ECH may not be feasible for all implementations. While most 1590 middleboxes will not treat them differently, some operators may wish 1591 to block real ECH usage but allow GREASE ECH. This specification 1592 aims to provide a baseline security level that most deployments can 1593 achieve easily, while providing implementations enough flexibility to 1594 achieve stronger security where possible. Minimally, real ECH is 1595 designed to be indifferentiable from GREASE ECH for passive 1596 adversaries with following capabilities: 1598 1. The attacker does not know the ECHConfigList used by the server. 1600 2. The attacker keeps per-connection state only. In particular, it 1601 does not track endpoints across connections. 1603 3. ECH and GREASE ECH are designed so that the following features do 1604 not vary: the code points of extensions negotiated in the clear; 1605 the length of messages; and the values of plaintext alert 1606 messages. 1608 This leaves a variety of practical differentiators out-of-scope. 1609 including, though not limited to, the following: 1611 1. the value of the configuration identifier; 1613 2. the value of the outer SNI; 1615 3. the TLS version negotiated, which may depend on ECH acceptance; 1617 4. client authentication, which may depend on ECH acceptance; and 1619 5. HRR issuance, which may depend on ECH acceptance. 1621 These can be addressed with more sophisticated implementations, but 1622 some mitigations require coordination between the client and server. 1623 These mitigations are out-of-scope for this specification. 1625 10.9.5. Maintain Forward Secrecy 1627 This design is not forward secret because the server's ECH key is 1628 static. However, the window of exposure is bound by the key 1629 lifetime. It is RECOMMENDED that servers rotate keys frequently. 1631 10.9.6. Enable Multi-party Security Contexts 1633 This design permits servers operating in Split Mode to forward 1634 connections directly to backend origin servers. The client 1635 authenticates the identity of the backend origin server, thereby 1636 avoiding unnecessary MiTM attacks. 1638 Conversely, assuming ECH records retrieved from DNS are 1639 authenticated, e.g., via DNSSEC or fetched from a trusted Recursive 1640 Resolver, spoofing a client-facing server operating in Split Mode is 1641 not possible. See Section 10.2 for more details regarding plaintext 1642 DNS. 1644 Authenticating the ECHConfig structure naturally authenticates the 1645 included public name. This also authenticates any retry signals from 1646 the client-facing server because the client validates the server 1647 certificate against the public name before retrying. 1649 10.9.7. Support Multiple Protocols 1651 This design has no impact on application layer protocol negotiation. 1652 It may affect connection routing, server certificate selection, and 1653 client certificate verification. Thus, it is compatible with 1654 multiple application and transport protocols. By encrypting the 1655 entire ClientHello, this design additionally supports encrypting the 1656 ALPN extension. 1658 10.10. Padding Policy 1660 Variations in the length of the ClientHelloInner ciphertext could 1661 leak information about the corresponding plaintext. Section 6.1.3 1662 describes a RECOMMENDED padding mechanism for clients aimed at 1663 reducing potential information leakage. 1665 10.11. Active Attack Mitigations 1667 This section describes the rationale for ECH properties and mechanics 1668 as defenses against active attacks. In all the attacks below, the 1669 attacker is on-path between the target client and server. The goal 1670 of the attacker is to learn private information about the inner 1671 ClientHello, such as the true SNI value. 1673 10.11.1. Client Reaction Attack Mitigation 1675 This attack uses the client's reaction to an incorrect certificate as 1676 an oracle. The attacker intercepts a legitimate ClientHello and 1677 replies with a ServerHello, Certificate, CertificateVerify, and 1678 Finished messages, wherein the Certificate message contains a "test" 1679 certificate for the domain name it wishes to query. If the client 1680 decrypted the Certificate and failed verification (or leaked 1681 information about its verification process by a timing side channel), 1682 the attacker learns that its test certificate name was incorrect. As 1683 an example, suppose the client's SNI value in its inner ClientHello 1684 is "example.com," and the attacker replied with a Certificate for 1685 "test.com". If the client produces a verification failure alert 1686 because of the mismatch faster than it would due to the Certificate 1687 signature validation, information about the name leaks. Note that 1688 the attacker can also withhold the CertificateVerify message. In 1689 that scenario, a client which first verifies the Certificate would 1690 then respond similarly and leak the same information. 1692 Client Attacker Server 1693 ClientHello 1694 + key_share 1695 + ech ------> (intercept) -----> X (drop) 1697 ServerHello 1698 + key_share 1699 {EncryptedExtensions} 1700 {CertificateRequest*} 1701 {Certificate*} 1702 {CertificateVerify*} 1703 <------ 1704 Alert 1705 ------> 1707 Figure 3: Client reaction attack 1709 ClientHelloInner.random prevents this attack. In particular, since 1710 the attacker does not have access to this value, it cannot produce 1711 the right transcript and handshake keys needed for encrypting the 1712 Certificate message. Thus, the client will fail to decrypt the 1713 Certificate and abort the connection. 1715 10.11.2. HelloRetryRequest Hijack Mitigation 1717 This attack aims to exploit server HRR state management to recover 1718 information about a legitimate ClientHello using its own attacker- 1719 controlled ClientHello. To begin, the attacker intercepts and 1720 forwards a legitimate ClientHello with an "encrypted_client_hello" 1721 (ech) extension to the server, which triggers a legitimate 1722 HelloRetryRequest in return. Rather than forward the retry to the 1723 client, the attacker attempts to generate its own ClientHello in 1724 response based on the contents of the first ClientHello and 1725 HelloRetryRequest exchange with the result that the server encrypts 1726 the Certificate to the attacker. If the server used the SNI from the 1727 first ClientHello and the key share from the second (attacker- 1728 controlled) ClientHello, the Certificate produced would leak the 1729 client's chosen SNI to the attacker. 1731 Client Attacker Server 1732 ClientHello 1733 + key_share 1734 + ech ------> (forward) -------> 1735 HelloRetryRequest 1736 + key_share 1737 (intercept) <------- 1739 ClientHello 1740 + key_share' 1741 + ech' -------> 1742 ServerHello 1743 + key_share 1744 {EncryptedExtensions} 1745 {CertificateRequest*} 1746 {Certificate*} 1747 {CertificateVerify*} 1748 {Finished} 1749 <------- 1750 (process server flight) 1752 Figure 4: HelloRetryRequest hijack attack 1754 This attack is mitigated by using the same HPKE context for both 1755 ClientHello messages. The attacker does not possess the context's 1756 keys, so it cannot generate a valid encryption of the second inner 1757 ClientHello. 1759 If the attacker could manipulate the second ClientHello, it might be 1760 possible for the server to act as an oracle if it required parameters 1761 from the first ClientHello to match that of the second ClientHello. 1762 For example, imagine the client's original SNI value in the inner 1763 ClientHello is "example.com", and the attacker's hijacked SNI value 1764 in its inner ClientHello is "test.com". A server which checks these 1765 for equality and changes behavior based on the result can be used as 1766 an oracle to learn the client's SNI. 1768 10.11.3. ClientHello Malleability Mitigation 1770 This attack aims to leak information about secret parts of the 1771 encrypted ClientHello by adding attacker-controlled parameters and 1772 observing the server's response. In particular, the compression 1773 mechanism described in Section 5.1 references parts of a potentially 1774 attacker-controlled ClientHelloOuter to construct ClientHelloInner, 1775 or a buggy server may incorrectly apply parameters from 1776 ClientHelloOuter to the handshake. 1778 To begin, the attacker first interacts with a server to obtain a 1779 resumption ticket for a given test domain, such as "example.com". 1780 Later, upon receipt of a ClientHelloOuter, it modifies it such that 1781 the server will process the resumption ticket with ClientHelloInner. 1782 If the server only accepts resumption PSKs that match the server 1783 name, it will fail the PSK binder check with an alert when 1784 ClientHelloInner is for "example.com" but silently ignore the PSK and 1785 continue when ClientHelloInner is for any other name. This 1786 introduces an oracle for testing encrypted SNI values. 1788 Client Attacker Server 1790 handshake and ticket 1791 for "example.com" 1792 <--------> 1794 ClientHello 1795 + key_share 1796 + ech 1797 + ech_outer_extensions(pre_shared_key) 1798 + pre_shared_key 1799 --------> 1800 (intercept) 1801 ClientHello 1802 + key_share 1803 + ech 1804 + ech_outer_extensions(pre_shared_key) 1805 + pre_shared_key' 1806 --------> 1807 Alert 1808 -or- 1809 ServerHello 1810 ... 1811 Finished 1812 <-------- 1814 Figure 5: Message flow for malleable ClientHello 1816 This attack may be generalized to any parameter which the server 1817 varies by server name, such as ALPN preferences. 1819 ECH mitigates this attack by only negotiating TLS parameters from 1820 ClientHelloInner and authenticating all inputs to the 1821 ClientHelloInner (EncodedClientHelloInner and ClientHelloOuter) with 1822 the HPKE AEAD. See Section 5.2. An earlier iteration of this 1823 specification only encrypted and authenticated the "server_name" 1824 extension, which left the overall ClientHello vulnerable to an 1825 analogue of this attack. 1827 10.11.4. ClientHelloInner Packet Amplification Mitigation 1829 Client-facing servers must decompress EncodedClientHelloInners. A 1830 malicious attacker may craft a packet which takes excessive resources 1831 to decompress or may be much larger than the incoming packet: 1833 * If looking up a ClientHelloOuter extension takes time linear in 1834 the number of extensions, the overall decoding process would take 1835 O(M*N) time, where M is the number of extensions in 1836 ClientHelloOuter and N is the size of OuterExtensions. 1838 * If the same ClientHelloOuter extension can be copied multiple 1839 times, an attacker could cause the client-facing server to 1840 construct a large ClientHelloInner by including a large extension 1841 in ClientHelloOuter, of length L, and an OuterExtensions list 1842 referencing N copies of that extension. The client-facing server 1843 would then use O(N*L) memory in response to O(N+L) bandwidth from 1844 the client. In split-mode, an O(N*L) sized packet would then be 1845 transmitted to the backend server. 1847 ECH mitigates this attack by requiring that OuterExtensions be 1848 referenced in order, that duplicate references be rejected, and by 1849 recommending that client-facing servers use a linear scan to perform 1850 decompression. These requirements are detailed in Section 5.1. 1852 11. IANA Considerations 1854 11.1. Update of the TLS ExtensionType Registry 1856 IANA is requested to create the following entries in the existing 1857 registry for ExtensionType (defined in [RFC8446]): 1859 1. encrypted_client_hello(0xfe0d), with "TLS 1.3" column values set 1860 to "CH, HRR, EE", and "Recommended" column set to "Yes". 1862 2. ech_outer_extensions(0xfd00), with the "TLS 1.3" column values 1863 set to "", and "Recommended" column set to "Yes". 1865 11.2. Update of the TLS Alert Registry 1867 IANA is requested to create an entry, ech_required(121) in the 1868 existing registry for Alerts (defined in [RFC8446]), with the "DTLS- 1869 OK" column set to "Y". 1871 12. ECHConfig Extension Guidance 1873 Any future information or hints that influence ClientHelloOuter 1874 SHOULD be specified as ECHConfig extensions. This is primarily 1875 because the outer ClientHello exists only in support of ECH. Namely, 1876 it is both an envelope for the encrypted inner ClientHello and 1877 enabler for authenticated key mismatch signals (see Section 7). In 1878 contrast, the inner ClientHello is the true ClientHello used upon ECH 1879 negotiation. 1881 13. References 1883 13.1. Normative References 1885 [HTTPS-RR] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 1886 and parameter specification via the DNS (DNS SVCB and 1887 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 1888 dnsop-svcb-https-08, 12 October 2021, 1889 . 1892 [I-D.ietf-tls-exported-authenticator] 1893 Sullivan, N., "Exported Authenticators in TLS", Work in 1894 Progress, Internet-Draft, draft-ietf-tls-exported- 1895 authenticator-14, 25 January 2021, 1896 . 1899 [I-D.irtf-cfrg-hpke] 1900 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 1901 "Hybrid Public Key Encryption", Work in Progress, 1902 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 1903 . 1906 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1907 Requirement Levels", BCP 14, RFC 2119, 1908 DOI 10.17487/RFC2119, March 1997, 1909 . 1911 [RFC5890] Klensin, J., "Internationalized Domain Names for 1912 Applications (IDNA): Definitions and Document Framework", 1913 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1914 . 1916 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 1917 Layer Security (TLS) False Start", RFC 7918, 1918 DOI 10.17487/RFC7918, August 2016, 1919 . 1921 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1922 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1923 May 2017, . 1925 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1926 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1927 . 1929 13.2. Informative References 1931 [I-D.kazuho-protected-sni] 1932 Oku, K., "TLS Extensions for Protecting SNI", Work in 1933 Progress, Internet-Draft, draft-kazuho-protected-sni-00, 1934 18 July 2017, . 1937 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1938 Resource Identifier (URI): Generic Syntax", STD 66, 1939 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1940 . 1942 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1943 "Transport Layer Security (TLS) Session Resumption without 1944 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1945 January 2008, . 1947 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1948 "Transport Layer Security (TLS) Application-Layer Protocol 1949 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1950 July 2014, . 1952 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1953 and P. Hoffman, "Specification for DNS over Transport 1954 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1955 2016, . 1957 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1958 (TLS) Cached Information Extension", RFC 7924, 1959 DOI 10.17487/RFC7924, July 2016, 1960 . 1962 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1963 Transport Layer Security (DTLS)", RFC 8094, 1964 DOI 10.17487/RFC8094, February 2017, 1965 . 1967 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1968 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1969 . 1971 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 1972 Sustain Extensibility (GREASE) to TLS Extensibility", 1973 RFC 8701, DOI 10.17487/RFC8701, January 2020, 1974 . 1976 [RFC8744] Huitema, C., "Issues and Requirements for Server Name 1977 Identification (SNI) Encryption in TLS", RFC 8744, 1978 DOI 10.17487/RFC8744, July 2020, 1979 . 1981 [WHATWG-IPV4] 1982 "URL Living Standard - IPv4 Parser", May 2021, 1983 . 1985 Appendix A. Alternative SNI Protection Designs 1987 Alternative approaches to encrypted SNI may be implemented at the TLS 1988 or application layer. In this section we describe several 1989 alternatives and discuss drawbacks in comparison to the design in 1990 this document. 1992 A.1. TLS-layer 1994 A.1.1. TLS in Early Data 1996 In this variant, TLS Client Hellos are tunneled within early data 1997 payloads belonging to outer TLS connections established with the 1998 client-facing server. This requires clients to have established a 1999 previous session --- and obtained PSKs --- with the server. The 2000 client-facing server decrypts early data payloads to uncover Client 2001 Hellos destined for the backend server, and forwards them onwards as 2002 necessary. Afterwards, all records to and from backend servers are 2003 forwarded by the client-facing server -- unmodified. This avoids 2004 double encryption of TLS records. 2006 Problems with this approach are: (1) servers may not always be able 2007 to distinguish inner Client Hellos from legitimate application data, 2008 (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may 2009 not be supported -- especially under DoS -- leading to availability 2010 concerns, and (4) clients must bootstrap tunnels (sessions), costing 2011 an additional round trip and potentially revealing the SNI during the 2012 initial connection. In contrast, encrypted SNI protects the SNI in a 2013 distinct Client Hello extension and neither abuses early data nor 2014 requires a bootstrapping connection. 2016 A.1.2. Combined Tickets 2018 In this variant, client-facing and backend servers coordinate to 2019 produce "combined tickets" that are consumable by both. Clients 2020 offer combined tickets to client-facing servers. The latter parse 2021 them to determine the correct backend server to which the Client 2022 Hello should be forwarded. This approach is problematic due to non- 2023 trivial coordination between client-facing and backend servers for 2024 ticket construction and consumption. Moreover, it requires a 2025 bootstrapping step similar to that of the previous variant. In 2026 contrast, encrypted SNI requires no such coordination. 2028 A.2. Application-layer 2030 A.2.1. HTTP/2 CERTIFICATE Frames 2032 In this variant, clients request secondary certificates with 2033 CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. 2034 In response, servers supply certificates via TLS exported 2035 authenticators [I-D.ietf-tls-exported-authenticator] in CERTIFICATE 2036 frames. Clients use a generic SNI for the underlying client-facing 2037 server TLS connection. Problems with this approach include: (1) one 2038 additional round trip before peer authentication, (2) non-trivial 2039 application-layer dependencies and interaction, and (3) obtaining the 2040 generic SNI to bootstrap the connection. In contrast, encrypted SNI 2041 induces no additional round trip and operates below the application 2042 layer. 2044 Appendix B. Linear-time Outer Extension Processing 2046 The following procedure processes the "ech_outer_extensions" 2047 extension (see Section 5.1) in linear time, ensuring that each 2048 referenced extension in the ClientHelloOuter is included at most 2049 once: 2051 1. Let I be zero and N be the number of extensions in 2052 ClientHelloOuter. 2054 2. For each extension type, E, in OuterExtensions: 2056 * If E is "encrypted_client_hello", abort the connection with an 2057 "illegal_parameter" alert and terminate this procedure. 2059 * While I is less than N and the I-th extension of 2060 ClientHelloOuter does not have type E, increment I. 2062 * If I is equal to N, abort the connection with an 2063 "illegal_parameter" alert and terminate this procedure. 2065 * Otherwise, the I-th extension of ClientHelloOuter has type E. 2066 Copy it to the EncodedClientHelloInner and increment I. 2068 Appendix C. Acknowledgements 2070 This document draws extensively from ideas in 2071 [I-D.kazuho-protected-sni], but is a much more limited mechanism 2072 because it depends on the DNS for the protection of the ECH key. 2073 Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, 2074 Nick Sullivan, Martin Thomson, and David Benjamin also provided 2075 important ideas and contributions. 2077 Appendix D. Change Log 2079 *RFC Editor's Note:* Please remove this section prior to 2080 publication of a final version of this document. 2082 Issue and pull request numbers are listed with a leading octothorp. 2084 D.1. Since draft-ietf-tls-esni-12 2086 * Abort on duplicate OuterExtensions (#514) 2088 * Improve EncodedClientHelloInner definition (#503) 2090 * Clarify retry configuration usage (#498) 2092 * Expand on config_id generation implications (#491) 2094 * Server-side acceptance signal extension GREASE (#481) 2096 * Refactor overview, client implementation, and middlebox sections 2097 (#480, #478, #475, #508) 2099 * Editorial iprovements (#485, #488, #490, #495, #496, #499, #500, 2100 #501, #504, #505, #507, #510, #511) 2102 D.2. Since draft-ietf-tls-esni-11 2104 * Move ClientHello padding to the encoding (#443) 2106 * Align codepoints (#464) 2108 * Relax OuterExtensions checks for alignment with RFC8446 (#467) 2110 * Clarify HRR acceptance and rejection logic (#470) 2112 * Editorial improvements (#468, #465, #462, #461) 2114 D.3. Since draft-ietf-tls-esni-10 2115 * Make HRR confirmation and ECH acceptance explicit (#422, #423) 2117 * Relax computation of the acceptance signal (#420, #449) 2119 * Simplify ClientHelloOuterAAD generation (#438, #442) 2121 * Allow empty enc in ECHClientHello (#444) 2123 * Authenticate ECHClientHello extensions position in 2124 ClientHelloOuterAAD (#410) 2126 * Allow clients to send a dummy PSK and early_data in 2127 ClientHelloOuter when applicable (#414, #415) 2129 * Compress ECHConfigContents (#409) 2131 * Validate ECHConfig.contents.public_name (#413, #456) 2133 * Validate ClientHelloInner contents (#411) 2135 * Note split-mode challenges for HRR (#418) 2137 * Editorial improvements (#428, #432, #439, #445, #458, #455) 2139 D.4. Since draft-ietf-tls-esni-09 2141 * Finalize HPKE dependency (#390) 2143 * Move from client-computed to server-chosen, one-byte config 2144 identifier (#376, #381) 2146 * Rename ECHConfigs to ECHConfigList (#391) 2148 * Clarify some security and privacy properties (#385, #383) 2150 Authors' Addresses 2152 Eric Rescorla 2153 RTFM, Inc. 2155 Email: ekr@rtfm.com 2157 Kazuho Oku 2158 Fastly 2160 Email: kazuhooku@gmail.com 2161 Nick Sullivan 2162 Cloudflare 2164 Email: nick@cloudflare.com 2166 Christopher A. Wood 2167 Cloudflare 2169 Email: caw@heapingbits.net