idnits 2.17.1 draft-ietf-tls-esni-11.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 (14 June 2021) is 1018 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-05 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-14 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-09 ** 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 (~~), 4 warnings (==), 2 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: 16 December 2021 Fastly 6 N. Sullivan 7 C.A. Wood 8 Cloudflare 9 14 June 2021 11 TLS Encrypted Client Hello 12 draft-ietf-tls-esni-11 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 16 December 2021. 44 Copyright Notice 46 Copyright (c) 2021 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 Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Encrypted ClientHello (ECH) . . . . . . . . . . . . . . . 6 65 4. Encrypted ClientHello Configuration . . . . . . . . . . . . . 7 66 4.1. Configuration Extensions . . . . . . . . . . . . . . . . 9 67 5. The "encrypted_client_hello" Extension . . . . . . . . . . . 10 68 5.1. Encoding the ClientHelloInner . . . . . . . . . . . . . . 11 69 5.2. Authenticating the ClientHelloOuter . . . . . . . . . . . 12 70 6. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 71 6.1. Offering ECH . . . . . . . . . . . . . . . . . . . . . . 13 72 6.1.1. Encrypting the ClientHello . . . . . . . . . . . . . 15 73 6.1.2. GREASE PSK . . . . . . . . . . . . . . . . . . . . . 17 74 6.1.3. Recommended Padding Scheme . . . . . . . . . . . . . 17 75 6.1.4. Handling the Server Response . . . . . . . . . . . . 18 76 6.1.5. Handling HelloRetryRequest . . . . . . . . . . . . . 20 77 6.2. GREASE ECH . . . . . . . . . . . . . . . . . . . . . . . 21 78 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 79 7.1. Client-Facing Server . . . . . . . . . . . . . . . . . . 22 80 7.1.1. Sending HelloRetryRequest . . . . . . . . . . . . . . 24 81 7.2. Backend Server . . . . . . . . . . . . . . . . . . . . . 25 82 7.2.1. Sending HelloRetryRequest . . . . . . . . . . . . . . 25 83 8. Compatibility Issues . . . . . . . . . . . . . . . . . . . . 26 84 8.1. Misconfiguration and Deployment Concerns . . . . . . . . 26 85 8.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 27 86 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 27 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 88 10.1. Security and Privacy Goals . . . . . . . . . . . . . . . 28 89 10.2. Unauthenticated and Plaintext DNS . . . . . . . . . . . 29 90 10.3. Client Tracking . . . . . . . . . . . . . . . . . . . . 29 91 10.4. Optional Configuration Identifiers and Trial 92 Decryption . . . . . . . . . . . . . . . . . . . . . . 29 93 10.5. Outer ClientHello . . . . . . . . . . . . . . . . . . . 30 94 10.6. Related Privacy Leaks . . . . . . . . . . . . . . . . . 31 95 10.7. Cookies . . . . . . . . . . . . . . . . . . . . . . . . 31 96 10.8. Attacks Exploiting Acceptance Confirmation . . . . . . . 32 97 10.9. Comparison Against Criteria . . . . . . . . . . . . . . 32 98 10.9.1. Mitigate Cut-and-Paste Attacks . . . . . . . . . . . 32 99 10.9.2. Avoid Widely Shared Secrets . . . . . . . . . . . . 33 100 10.9.3. Prevent SNI-Based Denial-of-Service Attacks . . . . 33 101 10.9.4. Do Not Stick Out . . . . . . . . . . . . . . . . . . 33 102 10.9.5. Maintain Forward Secrecy . . . . . . . . . . . . . . 34 103 10.9.6. Enable Multi-party Security Contexts . . . . . . . . 34 104 10.9.7. Support Multiple Protocols . . . . . . . . . . . . . 35 105 10.10. Padding Policy . . . . . . . . . . . . . . . . . . . . . 35 106 10.11. Active Attack Mitigations . . . . . . . . . . . . . . . 35 107 10.11.1. Client Reaction Attack Mitigation . . . . . . . . . 35 108 10.11.2. HelloRetryRequest Hijack Mitigation . . . . . . . . 36 109 10.11.3. ClientHello Malleability Mitigation . . . . . . . . 37 110 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 111 11.1. Update of the TLS ExtensionType Registry . . . . . . . . 39 112 11.2. Update of the TLS Alert Registry . . . . . . . . . . . . 39 113 12. ECHConfig Extension Guidance . . . . . . . . . . . . . . . . 39 114 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 115 13.1. Normative References . . . . . . . . . . . . . . . . . . 39 116 13.2. Informative References . . . . . . . . . . . . . . . . . 40 117 Appendix A. Alternative SNI Protection Designs . . . . . . . . . 42 118 A.1. TLS-layer . . . . . . . . . . . . . . . . . . . . . . . . 42 119 A.1.1. TLS in Early Data . . . . . . . . . . . . . . . . . . 42 120 A.1.2. Combined Tickets . . . . . . . . . . . . . . . . . . 42 121 A.2. Application-layer . . . . . . . . . . . . . . . . . . . . 42 122 A.2.1. HTTP/2 CERTIFICATE Frames . . . . . . . . . . . . . . 43 123 Appendix B. Linear-time Outer Extension Processing . . . . . . . 43 124 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 43 125 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 43 126 D.1. Since draft-ietf-tls-esni-10 . . . . . . . . . . . . . . 44 127 D.2. Since draft-ietf-tls-esni-09 . . . . . . . . . . . . . . 44 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 130 1. Introduction 132 DISCLAIMER: This draft is work-in-progress and has not yet seen 133 significant (or really any) security analysis. It should not be used 134 as a basis for building production systems. 136 Although TLS 1.3 [RFC8446] encrypts most of the handshake, including 137 the server certificate, there are several ways in which an on-path 138 attacker can learn private information about the connection. The 139 plaintext Server Name Indication (SNI) extension in ClientHello 140 messages, which leaks the target domain for a given connection, is 141 perhaps the most sensitive, unencrypted information in TLS 1.3. 143 The target domain may also be visible through other channels, such as 144 plaintext client DNS queries, visible server IP addresses (assuming 145 the server does not use domain-based virtual hosting), or other 146 indirect mechanisms such as traffic analysis. DoH [RFC8484] and 147 DPRIVE [RFC7858] [RFC8094] provide mechanisms for clients to conceal 148 DNS lookups from network inspection, and many TLS servers host 149 multiple domains on the same IP address. In such environments, the 150 SNI remains the primary explicit signal used to determine the 151 server's identity. 153 The TLS Working Group has studied the problem of protecting the SNI, 154 but has been unable to develop a completely generic solution. 155 [RFC8744] provides a description of the problem space and some of the 156 proposed techniques. One of the more difficult problems is "Do not 157 stick out" ([RFC8744], Section 3.4): if only sensitive or private 158 services use SNI encryption, then SNI encryption is a signal that a 159 client is going to such a service. For this reason, much recent work 160 has focused on concealing the fact that the SNI is being protected. 161 Unfortunately, the result often has undesirable performance 162 consequences, incomplete coverage, or both. 164 The protocol specified by this document takes a different approach. 165 It assumes that private origins will co-locate with or hide behind a 166 provider (reverse proxy, application server, etc.) that protects 167 sensitive ClientHello parameters, including the SNI, for all of the 168 domains it hosts. These co-located servers form an anonymity set 169 wherein all elements have a consistent configuration, e.g., the set 170 of supported application protocols, ciphersuites, TLS versions, and 171 so on. Usage of this mechanism reveals that a client is connecting 172 to a particular service provider, but does not reveal which server 173 from the anonymity set terminates the connection. Thus, it leaks no 174 more than what is already visible from the server IP address. 176 This document specifies a new TLS extension, called Encrypted Client 177 Hello (ECH), that allows clients to encrypt their ClientHello to a 178 supporting server. This protects the SNI and other potentially 179 sensitive fields, such as the ALPN list [RFC7301]. This extension is 180 only supported with (D)TLS 1.3 [RFC8446] and newer versions of the 181 protocol. 183 2. Conventions and Definitions 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 187 "OPTIONAL" in this document are to be interpreted as described in BCP 188 14 [RFC2119] [RFC8174] when, and only when, they appear in all 189 capitals, as shown here. All TLS notation comes from [RFC8446], 190 Section 3. 192 3. Overview 194 This protocol is designed to operate in one of two topologies 195 illustrated below, which we call "Shared Mode" and "Split Mode". 197 3.1. Topologies 199 +---------------------+ 200 | | 201 | 2001:DB8::1111 | 202 | | 203 Client <-----> | private.example.org | 204 | | 205 | public.example.com | 206 | | 207 +---------------------+ 208 Server 210 Figure 1: Shared Mode Topology 212 In Shared Mode, the provider is the origin server for all the domains 213 whose DNS records point to it. In this mode, the TLS connection is 214 terminated by the provider. 216 +--------------------+ +---------------------+ 217 | | | | 218 | 2001:DB8::1111 | | 2001:DB8::EEEE | 219 Client <----------------------------->| | 220 | public.example.com | | private.example.com | 221 | | | | 222 +--------------------+ +---------------------+ 223 Client-Facing Server Backend Server 225 Figure 2: Split Mode Topology 227 In Split Mode, the provider is not the origin server for private 228 domains. Rather, the DNS records for private domains point to the 229 provider, and the provider's server relays the connection back to the 230 origin server, who terminates the TLS connection with the client. 231 Importantly, service provider does not have access to the plaintext 232 of the connection. 234 In the remainder of this document, we will refer to the ECH-service 235 provider as the "client-facing server" and to the TLS terminator as 236 the "backend server". These are the same entity in Shared Mode, but 237 in Split Mode, the client-facing and backend servers are physically 238 separated. 240 3.2. Encrypted ClientHello (ECH) 242 ECH allows the client to encrypt sensitive ClientHello extensions, 243 e.g., SNI, ALPN, etc., under the public key of the client-facing 244 server. This requires the client-facing server to publish the public 245 key and metadata it uses for ECH for all the domains for which it 246 serves directly or indirectly (via Split Mode). This document 247 defines the format of the ECH encryption public key and metadata, 248 referred to as an ECH configuration, and delegates DNS publication 249 details to [HTTPS-RR], though other delivery mechanisms are possible. 250 In particular, if some of the clients of a private server are 251 applications rather than Web browsers, those applications might have 252 the public key and metadata preconfigured. 254 When a client wants to establish a TLS session with the backend 255 server, it constructs its ClientHello as indicated in Section 6.1. 256 We will refer to this as the ClientHelloInner message. The client 257 encrypts this message using the public key of the ECH configuration. 258 It then constructs a new ClientHello, the ClientHelloOuter, with 259 innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and 260 with an "encrypted_client_hello" extension, which this document 261 defines (Section 5). The extension's payload carries the encrypted 262 ClientHelloInner and specifies the ECH configuration used for 263 encryption. Finally, it sends ClientHelloOuter to the server. 265 Upon receiving the ClientHelloOuter, a TLS server takes one of the 266 following actions: 268 1. If it does not support ECH, it ignores the 269 "encrypted_client_hello" extension and proceeds with the 270 handshake as usual, per [RFC8446], Section 4.1.2. 272 2. If it is a client-facing server for the ECH protocol, but cannot 273 decrypt the extension, then it terminates the handshake using the 274 ClientHelloOuter. This is referred to as "ECH rejection". When 275 ECH is rejected, the client-facing server sends an acceptable ECH 276 configuration in its EncryptedExtensions message. 278 3. If it supports ECH and decrypts the extension, it forwards the 279 ClientHelloInner to the backend server, who terminates the 280 connection. This is referred to as "ECH acceptance". 282 Upon receiving the server's response, the client determines whether 283 or not ECH was accepted and proceeds with the handshake accordingly. 284 (See Section 6 for details.) 285 The primary goal of ECH is to ensure that connections to servers in 286 the same anonymity set are indistinguishable from one another. 287 Moreover, it should achieve this goal without affecting any existing 288 security properties of TLS 1.3. See Section 10.1 for more details 289 about the ECH security and privacy goals. 291 4. Encrypted ClientHello Configuration 293 ECH uses draft-08 of HPKE for public key encryption 294 [I-D.irtf-cfrg-hpke]. The ECH configuration is defined by the 295 following "ECHConfig" structure. 297 opaque HpkePublicKey<1..2^16-1>; 298 uint16 HpkeKemId; // Defined in I-D.irtf-cfrg-hpke 299 uint16 HpkeKdfId; // Defined in I-D.irtf-cfrg-hpke 300 uint16 HpkeAeadId; // Defined in I-D.irtf-cfrg-hpke 302 struct { 303 HpkeKdfId kdf_id; 304 HpkeAeadId aead_id; 305 } HpkeSymmetricCipherSuite; 307 struct { 308 uint8 config_id; 309 HpkeKemId kem_id; 310 HpkePublicKey public_key; 311 HpkeSymmetricCipherSuite cipher_suites<4..2^16-4>; 312 } HpkeKeyConfig; 314 struct { 315 HpkeKeyConfig key_config; 316 uint8 maximum_name_length; 317 opaque public_name<1..255>; 318 Extension extensions<0..2^16-1>; 319 } ECHConfigContents; 321 struct { 322 uint16 version; 323 uint16 length; 324 select (ECHConfig.version) { 325 case 0xfe0a: ECHConfigContents contents; 326 } 327 } ECHConfig; 329 The structure contains the following fields: 331 version The version of ECH for which this configuration is used. 333 Beginning with draft-08, the version is the same as the code point 334 for the "encrypted_client_hello" extension. Clients MUST ignore 335 any "ECHConfig" structure with a version they do not support. 337 length The length, in bytes, of the next field. 339 contents An opaque byte string whose contents depend on the version. 340 For this specification, the contents are an "ECHConfigContents" 341 structure. 343 The "ECHConfigContents" structure contains the following fields: 345 key_config A "HpkeKeyConfig" structure carrying the configuration 346 information associated with the HPKE public key. Note that this 347 structure contains the "config_id" field, which applies to the 348 entire ECHConfigContents. Sites MUST NOT publish two different 349 "ECHConfigContents" values with the same "HpkeKeyConfig" value. 350 The RECOMMENDED technique for choosing "config_id" is to choose a 351 random byte. This process is repeated if this config_id matches 352 that of any valid ECHConfig, which could include any ECHConfig 353 that has been recently removed from active use. 355 maximum_name_length The longest name of a backend server, if known. 356 If not known, this value can be set to zero. It is used to 357 compute padding (Section 6.1.3) and does not constrain server name 358 lengths. Names may exceed this length if, e.g., the server uses 359 wildcard names or added new names to the anonymity set. 361 public_name The DNS name of the client-facing server, i.e., the 362 entity trusted to update the ECH configuration. This is used to 363 correct misconfigured clients, as described in Section 6.1.4. 365 Clients MUST ignore any "ECHConfig" structure whose public_name is 366 not parsable as a dot-separated sequence of LDH labels, as defined 367 in [RFC5890], Section 2.3.1 or which begins or end with an ASCII 368 dot. 370 Clients SHOULD ignore the "ECHConfig" if it contains an encoded 371 IPv4 address. To determine if a public_name value is an IPv4 372 address, clients can invoke the IPv4 parser algorithm in 373 [WHATWG-IPV4]. It returns a value when the input is an IPv4 374 address. 376 See Section 6.1.4.3 for how the client interprets and validates 377 the public_name. 379 extensions A list of extensions that the client must take into 380 consideration when generating a ClientHello message. These are 381 described below (Section 4.1). 383 [[OPEN ISSUE: determine if clients should enforce a 63-octet label 384 limit for public_name]] [[OPEN ISSUE: fix reference to WHATWG-IPV4]] 386 The "HpkeKeyConfig" structure contains the following fields: 388 config_id A one-byte identifier for the given HPKE key 389 configuration. This is used by clients to indicate the key used 390 for ClientHello encryption. 392 kem_id The HPKE KEM identifier corresponding to "public_key". 393 Clients MUST ignore any "ECHConfig" structure with a key using a 394 KEM they do not support. 396 public_key The HPKE public key used by the client to encrypt 397 ClientHelloInner. 399 cipher_suites The list of HPKE KDF and AEAD identifier pairs clients 400 can use for encrypting ClientHelloInner. 402 The client-facing server advertises a sequence of ECH configurations 403 to clients, serialized as follows. 405 ECHConfig ECHConfigList<1..2^16-1>; 407 The "ECHConfigList" structure contains one or more "ECHConfig" 408 structures in decreasing order of preference. This allows a server 409 to support multiple versions of ECH and multiple sets of ECH 410 parameters. 412 4.1. Configuration Extensions 414 ECH configuration extensions are used to provide room for additional 415 functionality as needed. See Section 12 for guidance on which types 416 of extensions are appropriate for this structure. 418 The format is as defined in [RFC8446], Section 4.2. The same 419 interpretation rules apply: extensions MAY appear in any order, but 420 there MUST NOT be more than one extension of the same type in the 421 extensions block. An extension can be tagged as mandatory by using 422 an extension type codepoint with the high order bit set to 1. A 423 client that receives a mandatory extension they do not understand 424 MUST reject the "ECHConfig" content. 426 Clients MUST parse the extension list and check for unsupported 427 mandatory extensions. If an unsupported mandatory extension is 428 present, clients MUST ignore the "ECHConfig". 430 5. The "encrypted_client_hello" Extension 432 To offer ECH, the client sends an "encrypted_client_hello" extension 433 in the ClientHelloOuter. When it does, it MUST also send the 434 extension in ClientHelloInner. 436 enum { 437 encrypted_client_hello(0xfe0b), (65535) 438 } ExtensionType; 440 The payload of the extension has the following structure: 442 enum { outer(0), inner(1) } ClientECHType; 444 struct { 445 ClientECHType type; 446 select (ClientECH.type) { 447 case outer: 448 HpkeSymmetricCipherSuite cipher_suite; 449 uint8 config_id; 450 opaque enc<0..2^16-1>; 451 opaque payload<1..2^16-1>; 452 case inner: 453 Empty; 454 }; 455 } ClientECH; 457 The outer extension uses the "outer" variant and the inner extension 458 uses the "inner" variant. The inner extension has an empty payload. 459 The outer extension has the following fields: 461 config_id The ECHConfigContents.key_config.config_id for the chosen 462 ECHConfig. 464 cipher_suite The cipher suite used to encrypt ClientHelloInner. 465 This MUST match a value provided in the corresponding 466 "ECHConfigContents.cipher_suites" list. 468 enc The HPKE encapsulated key, used by servers to decrypt the 469 corresponding "payload" field. This field is empty in 470 ClientHelloOuters sent in response to HelloRetryRequest. 472 payload The serialized and encrypted ClientHelloInner structure, 473 encrypted using HPKE as described in Section 6.1. 475 When the client offers the "encrypted_client_hello" extension, if the 476 payload is the "outer" variant, then the server MAY include an 477 "encrypted_client_hello" extension in its EncryptedExtensions message 478 with the following payload: 480 struct { 481 ECHConfigList retry_configs; 482 } ServerECH; 484 The response is valid only when the server used the ClientHelloOuter. 485 If the server sent this extension in response to the "inner" variant, 486 then the client MUST abort with an "unsupported_extension" alert. 488 retry_configs An ECHConfigList structure containing one or more 489 ECHConfig structures, in decreasing order of preference, to be 490 used by the client in subsequent connection attempts. These are 491 known as the server's "retry configurations". 493 This document also defines the "ech_required" alert, which the client 494 MUST send when it offered an "encrypted_client_hello" extension that 495 was not accepted by the server. (See Section 11.2.) 497 5.1. Encoding the ClientHelloInner 499 Some TLS 1.3 extensions can be quite large, thus repeating them in 500 the ClientHelloInner and ClientHelloOuter can lead to an excessive 501 overall size. One pathological example is "key_share" with post- 502 quantum algorithms. To reduce the impact of duplicated extensions, 503 the client may use the "ech_outer_extensions" extension. 505 enum { 506 ech_outer_extensions(0xfd00), (65535) 507 } ExtensionType; 509 ExtensionType OuterExtensions<2..254>; 511 OuterExtensions consists of one or more ExtensionType values, each of 512 which reference an extension in ClientHelloOuter. The extensions in 513 OuterExtensions MUST appear in ClientHelloOuter in the same relative 514 order, however, there is no requirement that they be continguous. 515 For example, OuterExtensions may contain extensions A, B, C, while 516 ClientHelloOuter contains extensions A, D, B, C, E, F. 518 The "ech_outer_extensions" extension is only used for compressing the 519 ClientHelloInner. It can only be included in 520 EncodedClientHelloInner, and MUST NOT be sent in either 521 ClientHelloOuter or ClientHelloInner. 523 When sending ClientHello, the client first computes ClientHelloInner, 524 including any PSK binders. It then computes a new value, the 525 EncodedClientHelloInner, by first making a copy of ClientHelloInner. 526 It then replaces the legacy_session_id field with an empty string. 528 The client then MAY substitute extensions which it knows will be 529 duplicated in ClientHelloOuter. To do so, the client removes and 530 replaces extensions from EncodedClientHelloInner with a single 531 "ech_outer_extensions" extension. Removed extensions MUST be ordered 532 consecutively in ClientHelloInner. The list of outer extensions, 533 OuterExtensions, includes those which were removed from 534 EncodedClientHelloInner, in the order in which they were removed. 536 Finally, EncodedClientHelloInner is serialized as a ClientHello 537 structure, defined in Section 4.1.2 of [RFC8446]. Note this does not 538 include the four-byte header included in the Handshake structure. 540 The client-facing server computes ClientHelloInner by reversing this 541 process. First it makes a copy of EncodedClientHelloInner and copies 542 the legacy_session_id field from ClientHelloOuter. It then looks for 543 an "ech_outer_extensions" extension. If found, it replaces the 544 extension with the corresponding sequence of extensions in the 545 ClientHelloOuter. The server MUST abort the connection with an 546 "illegal_parameter" alert if any of the following are true: 548 * Any referenced extension is missing in ClientHelloOuter. 550 * "encrypted_client_hello" appears in OuterExtensions. 552 * OuterExtensions contains duplicate values. 554 * The extensions in ClientHelloOuter corresponding to those in 555 OuterExtensions do not occur in the same order. 557 Implementations SHOULD bound the time to compute a ClientHelloInner 558 proportionally to the ClientHelloOuter size. If the cost are 559 disproportionately large, a malicious client could exploit this in a 560 denial of service attack. Appendix B describes a linear-time 561 procedure that may be used for this purpose. 563 5.2. Authenticating the ClientHelloOuter 565 To prevent a network attacker from modifying the reconstructed 566 ClientHelloInner (see Section 10.11.3), ECH authenticates 567 ClientHelloOuter by passing ClientHelloOuterAAD as the associated 568 data for HPKE sealing and opening operations. The 569 ClientHelloOuterAAD is a serialized ClientHello structure, defined in 570 Section 4.1.2 of [RFC8446], which matches the ClientHelloOuter except 571 the "payload" field of the "encrypted_client_hello" is replaced with 572 a byte string of the same length but whose contents are zeros. This 573 value does not include the four-byte header from the Handshake 574 structure. 576 The client follows the procedure in Section 6.1.1 to first construct 577 ClientHelloOuterAAD with a placeholder "payload" field, then replace 578 the field with the encrypted value to compute ClientHelloOuter. 580 The server then receives ClientHelloOuter and computes 581 ClientHelloOuterAAD by making a copy and replacing the portion 582 corresponding to the "payload" field with zeros. 584 The payload and the placeholder strings have the same length, so it 585 is not necessary for either side to recompute length prefixes when 586 applying the above transformations. 588 The decompression process in Section 5.1 forbids 589 "encrypted_client_hello" in OuterExtensions. This ensures the 590 unauthenticated portion of ClientHelloOuter is not incorporated into 591 ClientHelloInner. 593 6. Client Behavior 595 Clients that implement the ECH extension behave in one of two ways: 596 either they offer a real ECH extension, as described in Section 6.1; 597 or they send a GREASE ECH extension, as described in Section 6.2. 598 Clients of the latter type do not negotiate ECH. Instead, they 599 generate a dummy ECH extension that is ignored by the server. (See 600 Section 10.9.4 for an explanation.) The client offers ECH if it is 601 in possession of a compatible ECH configuration and sends GREASE ECH 602 otherwise. 604 6.1. Offering ECH 606 To offer ECH, the client first chooses a suitable ECHConfig from the 607 server's ECHConfigList. To determine if a given "ECHConfig" is 608 suitable, it checks that it supports the KEM algorithm identified by 609 "ECHConfig.contents.kem_id", at least one KDF/AEAD algorithm 610 identified by "ECHConfig.contents.cipher_suites", and the version of 611 ECH indicated by "ECHConfig.contents.version". Once a suitable 612 configuration is found, the client selects the cipher suite it will 613 use for encryption. It MUST NOT choose a cipher suite or version not 614 advertised by the configuration. If no compatible configuration is 615 found, then the client SHOULD proceed as described in Section 6.2. 617 Next, the client constructs the ClientHelloInner message just as it 618 does a standard ClientHello, with the exception of the following 619 rules: 621 1. It MUST NOT offer to negotiate TLS 1.2 or below. This is 622 necessary to ensure the backend server does not negotiate a TLS 623 version that is incompatible with ECH. 625 2. It MUST NOT offer to resume any session for TLS 1.2 and below. 627 3. It SHOULD contain TLS padding [RFC7685] as described in 628 Section 6.1.3. 630 4. If it intends to compress any extensions (see Section 5.1), it 631 MUST order those extensions consecutively. 633 5. It MUST include the "encrypted_client_hello" extension of type 634 "inner" as described in Section 5. (This requirement is not 635 applicable when the "encrypted_client_hello" extension is 636 generated as described in Section 6.2.) 638 The client then constructs EncodedClientHelloInner as described in 639 Section 5.1. Finally, it constructs the ClientHelloOuter message 640 just as it does a standard ClientHello, with the exception of the 641 following rules: 643 1. It MUST offer to negotiate TLS 1.3 or above. 645 2. If it compressed any extensions in EncodedClientHelloInner, it 646 MUST copy the corresponding extensions from ClientHelloInner. 647 The copied extensions additionally MUST be in the same relative 648 order as in ClientHelloInner. 650 3. It MUST copy the legacy_session_id field from ClientHelloInner. 651 This allows the server to echo the correct session ID for TLS 652 1.3's compatibility mode (see Appendix D.4 of [RFC8446]) when ECH 653 is negotiated. 655 4. It MAY copy any other field from the ClientHelloInner except 656 ClientHelloInner.random. Instead, It MUST generate a fresh 657 ClientHelloOuter.random using a secure random number generator. 658 (See Section 10.11.1.) 660 5. The value of "ECHConfig.contents.public_name" MUST be placed in 661 the "server_name" extension. 663 6. When the client offers the "pre_shared_key" extension in 664 ClientHelloInner, it SHOULD also include a GREASE 665 "pre_shared_key" extension in ClientHelloOuter, generated in the 666 manner described in Section 6.1.2. The client MUST NOT use this 667 extension to advertise a PSK to the client-facing server. (See 668 Section 10.11.3.) When the client includes a GREASE 669 "pre_shared_key" extension, it MUST also copy the 670 "psk_key_exchange_modes" from the ClientHelloInner into the 671 ClientHelloOuter. 673 7. When the client offers the "early_data" extension in 674 ClientHelloInner, it MUST also include the "early_data" extension 675 in ClientHelloOuter. This allows servers that reject ECH and use 676 ClientHelloOuter to safely ignore any early data sent by the 677 client per [RFC8446], Section 4.2.10. 679 8. It MUST include an "encrypted_client_hello" extension with a 680 payload constructed as described in Section 6.1.1. 682 Note that these rules may change in the presence of an application 683 profile specifying otherwise. 685 [[OPEN ISSUE: We currently require HRR-sensitive parameters to match 686 in ClientHelloInner and ClientHelloOuter in order to simplify client- 687 side logic in the event of HRR. See https://github.com/tlswg/draft- 688 ietf-tls-esni/pull/316 for more information. We might also solve 689 this by including an explicit signal in HRR noting ECH acceptance. 690 We need to decide if inner/outer variance is important for HRR- 691 sensitive parameters, and if so, how to best deal with it without 692 complicated client logic.]] 694 The client might duplicate non-sensitive extensions in both messages. 695 However, implementations need to take care to ensure that sensitive 696 extensions are not offered in the ClientHelloOuter. See Section 10.5 697 for additional guidance. 699 6.1.1. Encrypting the ClientHello 701 To construct the "encrypted_client_hello", the client first 702 determines the encapsulated key and HPKE encryption context. If 703 constructing the first ClientHelloOuter, it computes them as: 705 pkR = DeserializePublicKey(ECHConfig.contents.public_key) 706 enc, context = SetupBaseS(pkR, 707 "tls ech" || 0x00 || ECHConfig) 709 If constructing the second ClientHelloOuter (Section 6.1.5), it 710 reuses the encryption context computed for the first 711 ClientHelloOuter, and sets "enc" to the empty string. Note that the 712 HPKE context maintains a sequence number, so this operation 713 internally uses a fresh nonce for each AEAD operation. Reusing the 714 HPKE context avoids an attack described in Section 10.11.2. 716 The client then computes ClientHelloOuterAAD (Section 5.2) by 717 constructing a ClientHello with all other extensions determined as in 718 Section 6.1. 720 Next, the client determines the length L of encrypting 721 EncodedClientHelloInner with the selected HPKE AEAD. This is 722 typically the sum of the plaintext length and the AEAD tag length. 723 The client fills in a "encrypted_client_hello" extension with the 724 outer variant of ClientECH with following values: 726 * "config_id", the identifier corresponding to the chosen ECHConfig 727 structure; 729 * "cipher_suite", the client's chosen cipher suite; 731 * "enc", as computed above; and 733 * "payload", a placeholder byte string containing L zeros. 735 If optional configuration identifiers (see Section 10.4) are used, 736 "config_id" SHOULD be set to a randomly generated byte in the first 737 ClientHelloOuter and MUST be left unchanged for the second 738 ClientHelloOuter. 740 The client serializes this structure to construct the 741 ClientHelloOuterAAD. It then computes the payload as: 743 final_payload = context.Seal(ClientHelloOuterAAD, 744 EncodedClientHelloInner) 746 Finally, the client replaces "payload" with "final_payload" to obtain 747 ClientHelloOuter. The two values have the same length, so it is not 748 necessary to recompute length prefixes in the serialized structure. 750 Note this construction requires the "encrypted_client_hello" be 751 computed after all other extensions. This is possible because the 752 ClientHelloOuter's "pre_shared_key" extension is either omitted, or 753 uses a random binder (Section 6.1.2). 755 6.1.2. GREASE PSK 757 When offering ECH, the client is not permitted to advertise PSK 758 identities in the ClientHelloOuter. However, the client can send a 759 "pre_shared_key" extension in the ClientHelloInner. In this case, 760 when resuming a session with the client, the backend server sends a 761 "pre_shared_key" extension in its ServerHello. This would appear to 762 a network observer as if the the server were sending this extension 763 without solicitation, which would violate the extension rules 764 described in [RFC8446]. Sending a GREASE "pre_shared_key" extension 765 in the ClientHelloOuter makes it appear to the network as if the 766 extension were negotiated properly. 768 The client generates the extension payload by constructing an 769 "OfferedPsks" structure (see [RFC8446], Section 4.2.11) as follows. 770 For each PSK identity advertised in the ClientHelloInner, the client 771 generates a random PSK identity with the same length. It also 772 generates a random, 32-bit, unsigned integer to use as the 773 "obfuscated_ticket_age". Likewise, for each inner PSK binder, the 774 client generates random string of the same length. 776 If the server replies with a "pre_shared_key" extension in its 777 ServerHello, then the client MUST abort the handshake with an 778 "illegal_parameter" alert. 780 6.1.3. Recommended Padding Scheme 782 This section describes a deterministic padding mechanism based on the 783 following observation: individual extensions can reveal sensitive 784 information through their length. Thus, each extension in the inner 785 ClientHello may require different amounts of padding. This padding 786 may be fully determined by the client's configuration or may require 787 server input. 789 By way of example, clients typically support a small number of 790 application profiles. For instance, a browser might support HTTP 791 with ALPN values ["http/1.1, "h2"] and WebRTC media with ALPNs 792 ["webrtc", "c-webrtc"]. Clients SHOULD pad this extension by 793 rounding up to the total size of the longest ALPN extension across 794 all application profiles. The target padding length of most 795 ClientHello extensions can be computed in this way. 797 In contrast, clients do not know the longest SNI value in the client- 798 facing server's anonymity set without server input. For the 799 "server_name" extension with length D, clients SHOULD use the 800 server's length hint L (ECHConfig.contents.maximum_name_length) when 801 computing the padding as follows: 803 1. If L >= D, add L - D bytes of padding. This rounds to the 804 server's advertised hint, i.e., 805 ECHConfig.contents.maximum_name_length. 807 2. Otherwise, let P = 31 - ((D - 1) % 32), and add P bytes of 808 padding, plus an additional 32 bytes if D + P < L + 32. This 809 rounds D up to the nearest multiple of 32 bytes that permits at 810 least 32 bytes of length ambiguity. 812 In addition to padding ClientHelloInner, clients and servers will 813 also need to pad all other handshake messages that have sensitive- 814 length fields. For example, if a client proposes ALPN values in 815 ClientHelloInner, the server-selected value will be returned in an 816 EncryptedExtension, so that handshake message also needs to be padded 817 using TLS record layer padding. 819 6.1.4. Handling the Server Response 821 As described in Section 7, the server MAY either accept ECH and use 822 ClientHelloInner or reject it and use ClientHelloOuter. In handling 823 the server's response, the client's first step is to determine which 824 value was used. 826 If the server replied with a HelloRetryRequest, then the client 827 proceeds as described in Section 6.1.5. Otherwise, if the server 828 replied with a ServerHello, then the client checks if the last 8 829 bytes of "ServerHello.random" are equal to "accept_confirmation" as 830 defined in Section 7.2. If so, then it presumes acceptance. 831 Otherwise, the client presumes rejection. 833 6.1.4.1. Accepted ECH 835 If the server used ClientHelloInner, the client proceeds with the 836 connection as usual, authenticating the connection for the true 837 server name. 839 6.1.4.2. Rejected ECH 841 If the server used ClientHelloOuter, the client proceeds with the 842 handshake, authenticating for ECHConfig.contents.public_name as 843 described in Section 6.1.4.3. If authentication or the handshake 844 fails, the client MUST return a failure to the calling application. 845 It MUST NOT use the retry configurations. 847 Otherwise, if both authentication and the handshake complete 848 successfully, the client MUST abort the connection with an 849 "ech_required" alert. It then processes the "retry_configs" field 850 from the server's "encrypted_client_hello" extension. 852 If at least one of the values contains a version supported by the 853 client, it can regard the ECH keys as securely replaced by the 854 server. It SHOULD retry the handshake with a new transport 855 connection, using the retry configurations supplied by the server. 856 The retry configurations may only be applied to the retry connection. 857 The client MUST continue to use the previously-advertised 858 configurations for subsequent connections. This avoids introducing 859 pinning concerns or a tracking vector, should a malicious server 860 present client-specific retry configurations in order to identify the 861 client in a subsequent ECH handshake. 863 If none of the values provided in "retry_configs" contains a 864 supported version, the client can regard ECH as securely disabled by 865 the server. As below, it SHOULD then retry the handshake with a new 866 transport connection and ECH disabled. 868 If the field contains any other value, the client MUST abort the 869 connection with an "illegal_parameter" alert. 871 If the server negotiates an earlier version of TLS, or if it does not 872 provide an "encrypted_client_hello" extension in EncryptedExtensions, 873 the client proceeds with the handshake, authenticating for 874 ECHConfig.contents.public_name as described in Section 6.1.4.3. If 875 an earlier version was negotiated, the client MUST NOT enable the 876 False Start optimization [RFC7918] for this handshake. If 877 authentication or the handshake fails, the client MUST return a 878 failure to the calling application. It MUST NOT treat this as a 879 secure signal to disable ECH. 881 Otherwise, when the handshake completes successfully with the public 882 name authenticated, the client MUST abort the connection with an 883 "ech_required" alert. The client can then regard ECH as securely 884 disabled by the server. It SHOULD retry the handshake with a new 885 transport connection and ECH disabled. 887 Clients SHOULD implement a limit on retries caused by 888 "ech_retry_request" or servers which do not acknowledge the 889 "encrypted_client_hello" extension. If the client does not retry in 890 either scenario, it MUST report an error to the calling application. 892 6.1.4.3. Authenticating for the Public Name 894 When the server rejects ECH or otherwise ignores 895 "encrypted_client_hello" extension, it continues with the handshake 896 using the plaintext "server_name" extension instead (see Section 7). 897 Clients that offer ECH then authenticate the connection with the 898 public name, as follows: 900 * The client MUST verify that the certificate is valid for 901 ECHConfig.contents.public_name. If invalid, it MUST abort the 902 connection with the appropriate alert. 904 * If the server requests a client certificate, the client MUST 905 respond with an empty Certificate message, denoting no client 906 certificate. 908 In verifying the client-facing server certificate, the client MUST 909 interpret the public name as a DNS-based reference identity. Clients 910 that incorporate DNS names and IP addresses into the same syntax 911 (e.g. [RFC3986], Section 7.4 and [WHATWG-IPV4]) MUST reject names 912 that would be interpreted as IPv4 addresses. Clients that enforce 913 this by checking and rejecting encoded IPv4 addresses in 914 ECHConfig.contents.public_name do not need to repeat the check at 915 this layer. 917 Note that authenticating a connection for the public name does not 918 authenticate it for the origin. The TLS implementation MUST NOT 919 report such connections as successful to the application. It 920 additionally MUST ignore all session tickets and session IDs 921 presented by the server. These connections are only used to trigger 922 retries, as described in Section 6.1.4. This may be implemented, for 923 instance, by reporting a failed connection with a dedicated error 924 code. 926 6.1.5. Handling HelloRetryRequest 928 When the server sends a HelloRetryRequest, the client determines if 929 ECH was accepted by checking the message for an 930 "encrypted_client_hello" extension with an 8-byte payload equal to 931 "hrr_accept_confirmation" as defined in Section 7.2. If found, the 932 client presumes acceptance and handles the HelloRetryRequest using 933 ClientHelloInner. Otherwise, it presumes rejection and handles the 934 HelloRetryRequest using ClientHelloOuter. Note that the client- 935 facing server does not send "encrypted_client_hello" in case of 936 rejection. 938 The client encodes the second ClientHelloInner as in Section 5.1, 939 using the second ClientHelloOuter for any referenced extensions. It 940 then encrypts the new EncodedClientHelloInner value as a second 941 message with the previous HPKE context as described in Section 6.1.1. 943 [[OPEN ISSUE: See https://github.com/tlswg/draft-ietf-tls-esni/ 944 issues/450.]] 946 6.2. GREASE ECH 948 If the client attempts to connect to a server and does not have an 949 ECHConfig structure available for the server, it SHOULD send a GREASE 950 [RFC8701] "encrypted_client_hello" extension in the first ClientHello 951 as follows: 953 * Set the "config_id" field to a random byte. 955 * Set the "cipher_suite" field to a supported 956 HpkeSymmetricCipherSuite. The selection SHOULD vary to exercise 957 all supported configurations, but MAY be held constant for 958 successive connections to the same server in the same session. 960 * Set the "enc" field to a randomly-generated valid encapsulated 961 public key output by the HPKE KEM. 963 * Set the "payload" field to a randomly-generated string of L+C 964 bytes, where C is the ciphertext expansion of the selected AEAD 965 scheme and L is the size of the EncodedClientHelloInner the client 966 would compute when offering ECH, padded according to 967 Section 6.1.3. 969 When sending a second ClientHello in response to a HelloRetryRequest, 970 the client copies the entire "encrypted_client_hello" extension from 971 the first ClientHello. 973 [[OPEN ISSUE: The above doesn't match HRR handling for either ECH 974 acceptance or rejection. See issue https://github.com/tlswg/draft- 975 ietf-tls-esni/issues/358.]] 977 If the server sends an "encrypted_client_hello" extension, the client 978 MUST check the extension syntactically and abort the connection with 979 a "decode_error" alert if it is invalid. It otherwise ignores the 980 extension and MUST NOT use the retry keys. 982 [[OPEN ISSUE: if the client sends a GREASE "encrypted_client_hello" 983 extension, should it also send a GREASE "pre_shared_key" extension? 984 If not, GREASE+ticket is a trivial distinguisher. See issue #384.]] 986 Offering a GREASE extension is not considered offering an encrypted 987 ClientHello for purposes of requirements in Section 6. In 988 particular, the client MAY offer to resume sessions established 989 without ECH. 991 7. Server Behavior 993 Servers that support ECH play one of two roles, depending on the 994 payload of the "encrypted_client_hello" extension in the ClientHello: 996 * If "ClientECH.type" is "outer", then the server acts as a client- 997 facing server and proceeds as described in Section 7.1 to extract 998 a ClientHelloInner, if available. 1000 * If "ClientECH.type" is "inner", then the server acts as a backend 1001 server and proceeds as described in Section 7.2. 1003 * Otherwise, if "ClientECH.type" is not a valid "ClientECHType", 1004 then the server MUST abort with an "illegal_parameter" alert. 1006 If the "encrypted_client_hello" is not present, then the server 1007 completes the handshake normally, as described in [RFC8446]. 1009 7.1. Client-Facing Server 1011 Upon receiving an "encrypted_client_hello" extension in an initial 1012 ClientHello, the client-facing server determines if it will accept 1013 ECH, prior to negotiating any other TLS parameters. Note that 1014 successfully decrypting the extension will result in a new 1015 ClientHello to process, so even the client's TLS version preferences 1016 may have changed. 1018 First, the server collects a set of candidate ECHConfig values. This 1019 list is determined by one of the two following methods: 1021 1. Compare ClientECH.config_id against identifiers of each known 1022 ECHConfig and select the ones that match, if any, as candidates. 1024 2. Collect all known ECHConfig values as candidates, with trial 1025 decryption below determining the final selection. 1027 Some uses of ECH, such as local discovery mode, may randomize the 1028 ClientECH.config_id since it can be used as a tracking vector. In 1029 such cases, the second method should be used for matching ClientECH 1030 to known ECHConfig. See Section 10.4. Unless specified by the 1031 application using (D)TLS or externally configured on both sides, 1032 implementations MUST use the first method. 1034 The server then iterates over the candidate ECHConfig values, 1035 attempting to decrypt the "encrypted_client_hello" extension: 1037 The server verifies that the ECHConfig supports the cipher suite 1038 indicated by the ClientECH.cipher_suite and that the version of ECH 1039 indicated by the client matches the ECHConfig.version. If not, the 1040 server continues to the next candidate ECHConfig. 1042 Next, the server decrypts ClientECH.payload, using the private key 1043 skR corresponding to ECHConfig, as follows: 1045 context = SetupBaseR(ClientECH.enc, skR, 1046 "tls ech" || 0x00 || ECHConfig) 1047 EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, 1048 ClientECH.payload) 1050 ClientHelloOuterAAD is computed from ClientHelloOuter as described in 1051 Section 5.2. The "info" parameter to SetupBaseR is the concatenation 1052 "tls ech", a zero byte, and the serialized ECHConfig. If decryption 1053 fails, the server continues to the next candidate ECHConfig. 1054 Otherwise, the server reconstructs ClientHelloInner from 1055 EncodedClientHelloInner, as described in Section 5.1. It then stops 1056 iterating over the candidate ECHConfig values. 1058 Upon determining the ClientHelloInner, the client-facing server 1059 checks that the message includes a well-formed 1060 "encrypted_client_hello" extension of type "inner" and that it does 1061 not offer TLS 1.2 or below. If either of these checks fails, the 1062 client-facing server MUST abort with an "illegal_parameter" alert. 1064 If these checks succeed, the client-facing server then forwards the 1065 ClientHelloInner to the appropriate backend server, which proceeds as 1066 in Section 7.2. If the backend server responds with a 1067 HelloRetryRequest, the client-facing server forwards it, decrypts the 1068 client's second ClientHelloOuter using the procedure in 1069 Section 7.1.1, and forwards the resulting second ClientHelloInner. 1070 The client-facing server forwards all other TLS messages between the 1071 client and backend server unmodified. 1073 Otherwise, if all candidate ECHConfig values fail to decrypt the 1074 extension, the client-facing server MUST ignore the extension and 1075 proceed with the connection using ClientHelloOuter. This connection 1076 proceeds as usual, except the server MUST include the 1077 "encrypted_client_hello" extension in its EncryptedExtensions with 1078 the "retry_configs" field set to one or more ECHConfig structures 1079 with up-to-date keys. Servers MAY supply multiple ECHConfig values 1080 of different versions. This allows a server to support multiple 1081 versions at once. 1083 Note that decryption failure could indicate a GREASE ECH extension 1084 (see Section 6.2), so it is necessary for servers to proceed with the 1085 connection and rely on the client to abort if ECH was required. In 1086 particular, the unrecognized value alone does not indicate a 1087 misconfigured ECH advertisement (Section 8.1). Instead, servers can 1088 measure occurrences of the "ech_required" alert to detect this case. 1090 7.1.1. Sending HelloRetryRequest 1092 After sending or forwarding a HelloRetryRequest, the client-facing 1093 server does not repeat the steps in Section 7.1 with the second 1094 ClientHelloOuter. Instead, it continues with the ECHConfig selection 1095 from the first ClientHelloOuter as follows: 1097 If the client-facing server accepted ECH, it checks the second 1098 ClientHelloOuter also contains the "encrypted_client_hello" 1099 extension. If not, it MUST abort the handshake with a 1100 "missing_extension" alert. Otherwise, it checks that 1101 ClientECH.cipher_suite and ClientECH.config_id are unchanged, and 1102 that ClientECH.enc is empty. If not, it MUST abort the handshake 1103 with an "illegal_parameter" alert. 1105 Finally, it decrypts the new ClientECH.payload as a second message 1106 with the previous HPKE context: 1108 EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, 1109 ClientECH.payload) 1111 ClientHelloOuterAAD is computed as described in Section 5.2, but 1112 using the second ClientHelloOuter. If decryption fails, the client- 1113 facing server MUST abort the handshake with a "decrypt_error" alert. 1114 Otherwise, it reconstructs the second ClientHelloInner from the new 1115 EncodedClientHelloInner as described in Section 5.1, using the second 1116 ClientHelloOuter for any referenced extensions. 1118 The client-facing server then forwards the resulting ClientHelloInner 1119 to the backend server. It forwards all subsequent TLS messages 1120 between the client and backend server unmodified. 1122 If the client-facing server rejected ECH, or if the first ClientHello 1123 did not include an "encrypted_client_hello" extension, the client- 1124 facing server proceeds with the connection as usual. The server does 1125 not decrypt the second ClientHello's ClientECH.payload value, if 1126 there is one. 1128 Note that a client-facing server that forwards the first ClientHello 1129 cannot include its own "cookie" extension if the backend server sends 1130 a HelloRetryRequest. This means that the client-facing server either 1131 needs to maintain state for such a connection or it needs to 1132 coordinate with the backend server to include any information it 1133 requires to process the second ClientHello. 1135 7.2. Backend Server 1137 Upon receipt of an "encrypted_client_hello" extension of type "inner" 1138 in a ClientHello, if the backend server negotiates TLS 1.3 or higher, 1139 then it MUST confirm ECH acceptance to the client by computing its 1140 ServerHello as described here. 1142 The backend server embeds in ServerHello.random a string derived from 1143 the inner handshake. It begins by computing its ServerHello as 1144 usual, except the last 8 bytes of ServerHello.random are set to zero. 1145 It then computes the transcript hash for ClientHelloInner up to and 1146 including the modified ServerHello, as described in [RFC8446], 1147 Section 4.4.1. Let transcript_ech_conf denote the output. Finally, 1148 the backend server overwrites the last 8 bytes of the 1149 ServerHello.random with the following string: 1151 accept_confirmation = HKDF-Expand-Label( 1152 HKDF-Extract(0, ClientHelloInner.random), 1153 "ech accept confirmation", 1154 transcript_ech_conf, 1155 8) 1157 where HKDF-Expand-Label is defined in [RFC8446], Section 7.1, "0" 1158 indicates a string of Hash.length bytes set to zero, and Hash is the 1159 hash function used to compute the transcript hash. 1161 The backend server MUST NOT perform this operation if it negotiated 1162 TLS 1.2 or below. Note that doing so would overwrite the downgrade 1163 signal for TLS 1.3 (see [RFC8446], Section 4.1.3). 1165 7.2.1. Sending HelloRetryRequest 1167 When the backend server sends HelloRetryRequest in response to the 1168 ClientHello, it similarly confirms ECH acceptance by adding a 1169 confirmation signal to its HelloRetryRequest. But instead of 1170 embedding the signal in the HelloRetryRequest.random (the value of 1171 which is specified by [RFC8446]), it sends the signal in an 1172 extension. 1174 The backend server begins by computing HelloRetryRequest as usual, 1175 except that it also contains an "encrypted_client_hello" extension 1176 with a payload of 8 zero bytes. It then computes the transcript hash 1177 for the first ClientHelloInner, denoted ClientHelloInner1, up to and 1178 including the modified HelloRetryRequest. Let 1179 transcript_hrr_ech_conf denote the output. Finally, the backend 1180 server overwrites the payload of the "encrypted_client_hello" 1181 extension with the following string: 1183 accept_confirmation = HKDF-Expand-Label( 1184 HKDF-Extract(0, ClientHelloInner1.random), 1185 "hrr ech accept confirmation", 1186 transcript_hrr_ech_conf, 1187 8) 1189 As above, the payload of "encrypted_client_hello" is expected to be a 1190 "ClientECH" with "ClientECH.type" is "inner". If this is not the 1191 case, the backend server MUST abort the handshake with an 1192 "illegal_parameter" alert. 1194 Note that, in case of HelloRetryRequest, the backend server confirms 1195 ECH acceptance twice: first In HelloRetryRequest, as described here; 1196 and then in the subsequent ServerHello, as described above. 1198 8. Compatibility Issues 1200 Unlike most TLS extensions, placing the SNI value in an ECH extension 1201 is not interoperable with existing servers, which expect the value in 1202 the existing plaintext extension. Thus server operators SHOULD 1203 ensure servers understand a given set of ECH keys before advertising 1204 them. Additionally, servers SHOULD retain support for any 1205 previously-advertised keys for the duration of their validity 1207 However, in more complex deployment scenarios, this may be difficult 1208 to fully guarantee. Thus this protocol was designed to be robust in 1209 case of inconsistencies between systems that advertise ECH keys and 1210 servers, at the cost of extra round-trips due to a retry. Two 1211 specific scenarios are detailed below. 1213 8.1. Misconfiguration and Deployment Concerns 1215 It is possible for ECH advertisements and servers to become 1216 inconsistent. This may occur, for instance, from DNS 1217 misconfiguration, caching issues, or an incomplete rollout in a 1218 multi-server deployment. This may also occur if a server loses its 1219 ECH keys, or if a deployment of ECH must be rolled back on the 1220 server. 1222 The retry mechanism repairs inconsistencies, provided the server is 1223 authoritative for the public name. If server and advertised keys 1224 mismatch, the server will respond with ech_retry_requested. If the 1225 server does not understand the "encrypted_client_hello" extension at 1226 all, it will ignore it as required by Section 4.1.2 of [RFC8446]. 1228 Provided the server can present a certificate valid for the public 1229 name, the client can safely retry with updated settings, as described 1230 in Section 6.1.4. 1232 Unless ECH is disabled as a result of successfully establishing a 1233 connection to the public name, the client MUST NOT fall back to using 1234 unencrypted ClientHellos, as this allows a network attacker to 1235 disclose the contents of this ClientHello, including the SNI. It MAY 1236 attempt to use another server from the DNS results, if one is 1237 provided. 1239 8.2. Middleboxes 1241 A more serious problem is MITM proxies which do not support this 1242 extension. [RFC8446], Section 9.3 requires that such proxies remove 1243 any extensions they do not understand. The handshake will then 1244 present a certificate based on the public name, without echoing the 1245 "encrypted_client_hello" extension to the client. 1247 Depending on whether the client is configured to accept the proxy's 1248 certificate as authoritative for the public name, this may trigger 1249 the retry logic described in Section 6.1.4 or result in a connection 1250 failure. A proxy which is not authoritative for the public name 1251 cannot forge a signal to disable ECH. 1253 A non-conformant MITM proxy which instead forwards the ECH extension, 1254 substituting its own KeyShare value, will result in the client-facing 1255 server recognizing the key, but failing to decrypt the SNI. This 1256 causes a hard failure. Clients SHOULD NOT attempt to repair the 1257 connection in this case. 1259 9. Compliance Requirements 1261 In the absence of an application profile standard specifying 1262 otherwise, a compliant ECH application MUST implement the following 1263 HPKE cipher suite: 1265 * KEM: DHKEM(X25519, HKDF-SHA256) (see [I-D.irtf-cfrg-hpke], 1266 Section 7.1) 1268 * KDF: HKDF-SHA256 (see [I-D.irtf-cfrg-hpke], Section 7.2) 1270 * AEAD: AES-128-GCM (see [I-D.irtf-cfrg-hpke], Section 7.3) 1272 10. Security Considerations 1273 10.1. Security and Privacy Goals 1275 ECH considers two types of attackers: passive and active. Passive 1276 attackers can read packets from the network, but they cannot perform 1277 any sort of active behavior such as probing servers or querying DNS. 1278 A middlebox that filters based on plaintext packet contents is one 1279 example of a passive attacker. In contrast, active attackers can 1280 also write packets into the network for malicious purposes, such as 1281 interfering with existing connections, probing servers, and querying 1282 DNS. In short, an active attacker corresponds to the conventional 1283 threat model for TLS 1.3 [RFC8446]. 1285 Given these types of attackers, the primary goals of ECH are as 1286 follows. 1288 1. Use of ECH does not weaken the security properties of TLS without 1289 ECH. 1291 2. TLS connection establishment to a host with a specific ECHConfig 1292 and TLS configuration is indistinguishable from a connection to 1293 any other host with the same ECHConfig and TLS configuration. 1294 (The set of hosts which share the same ECHConfig and TLS 1295 configuration is referred to as the anonymity set.) 1297 Client-facing server configuration determines the size of the 1298 anonymity set. For example, if a client-facing server uses distinct 1299 ECHConfig values for each host, then each anonymity set has size k = 1300 1. Client-facing servers SHOULD deploy ECH in such a way so as to 1301 maximize the size of the anonymity set where possible. This means 1302 client-facing servers should use the same ECHConfig for as many hosts 1303 as possible. An attacker can distinguish two hosts that have 1304 different ECHConfig values based on the ClientECH.config_id value. 1305 This also means public information in a TLS handshake is also 1306 consistent across hosts. For example, if a client-facing server 1307 services many backend origin hosts, only one of which supports some 1308 cipher suite, it may be possible to identify that host based on the 1309 contents of unencrypted handshake messages. 1311 Beyond these primary security and privacy goals, ECH also aims to 1312 hide, to some extent, the fact that it is being used at all. 1313 Specifically, the GREASE ECH extension described in Section 6.2 does 1314 not change the security properties of the TLS handshake at all. Its 1315 goal is to provide "cover" for the real ECH protocol (Section 6.1), 1316 as a means of addressing the "do not stick out" requirements of 1317 [RFC8744]. See Section 10.9.4 for details. 1319 10.2. Unauthenticated and Plaintext DNS 1321 In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource 1322 Records are signed via a server private key, ECH records have no 1323 authenticity or provenance information. This means that any attacker 1324 which can inject DNS responses or poison DNS caches, which is a 1325 common scenario in client access networks, can supply clients with 1326 fake ECH records (so that the client encrypts data to them) or strip 1327 the ECH record from the response. However, in the face of an 1328 attacker that controls DNS, no encryption scheme can work because the 1329 attacker can replace the IP address, thus blocking client 1330 connections, or substituting a unique IP address which is 1:1 with 1331 the DNS name that was looked up (modulo DNS wildcards). Thus, 1332 allowing the ECH records in the clear does not make the situation 1333 significantly worse. 1335 Clearly, DNSSEC (if the client validates and hard fails) is a defense 1336 against this form of attack, but DoH/DPRIVE are also defenses against 1337 DNS attacks by attackers on the local network, which is a common case 1338 where ClientHello and SNI encryption are desired. Moreover, as noted 1339 in the introduction, SNI encryption is less useful without encryption 1340 of DNS queries in transit via DoH or DPRIVE mechanisms. 1342 10.3. Client Tracking 1344 A malicious client-facing server could distribute unique, per-client 1345 ECHConfig structures as a way of tracking clients across subsequent 1346 connections. On-path adversaries which know about these unique keys 1347 could also track clients in this way by observing TLS connection 1348 attempts. 1350 The cost of this type of attack scales linearly with the desired 1351 number of target clients. Moreover, DNS caching behavior makes 1352 targeting individual users for extended periods of time, e.g., using 1353 per-client ECHConfig structures delivered via HTTPS RRs with high 1354 TTLs, challenging. Clients can help mitigate this problem by 1355 flushing any DNS or ECHConfig state upon changing networks. 1357 10.4. Optional Configuration Identifiers and Trial Decryption 1359 Optional configuration identifiers may be useful in scenarios where 1360 clients and client-facing servers do not want to reveal information 1361 about the client-facing server in the "encrypted_client_hello" 1362 extension. In such settings, clients send a randomly generated 1363 config_id in the ClientECH. Servers in these settings must perform 1364 trial decryption since they cannot identify the client's chosen ECH 1365 key using the config_id value. As a result, support for optional 1366 configuration identifiers may exacerbate DoS attacks. Specifically, 1367 an adversary may send malicious ClientHello messages, i.e., those 1368 which will not decrypt with any known ECH key, in order to force 1369 wasteful decryption. Servers that support this feature should, for 1370 example, implement some form of rate limiting mechanism to limit the 1371 damage caused by such attacks. 1373 Unless specified by the application using (D)TLS or externally 1374 configured on both sides, implementations MUST NOT use this mode. 1376 10.5. Outer ClientHello 1378 Any information that the client includes in the ClientHelloOuter is 1379 visible to passive observers. The client SHOULD NOT send values in 1380 the ClientHelloOuter which would reveal a sensitive ClientHelloInner 1381 property, such as the true server name. It MAY send values 1382 associated with the public name in the ClientHelloOuter. 1384 In particular, some extensions require the client send a server-name- 1385 specific value in the ClientHello. These values may reveal 1386 information about the true server name. For example, the 1387 "cached_info" ClientHello extension [RFC7924] can contain the hash of 1388 a previously observed server certificate. The client SHOULD NOT send 1389 values associated with the true server name in the ClientHelloOuter. 1390 It MAY send such values in the ClientHelloInner. 1392 A client may also use different preferences in different contexts. 1393 For example, it may send a different ALPN lists to different servers 1394 or in different application contexts. A client that treats this 1395 context as sensitive SHOULD NOT send context-specific values in 1396 ClientHelloOuter. 1398 Values which are independent of the true server name, or other 1399 information the client wishes to protect, MAY be included in 1400 ClientHelloOuter. If they match the corresponding ClientHelloInner, 1401 they MAY be compressed as described in Section 5.1. However, note 1402 the payload length reveals information about which extensions are 1403 compressed, so inner extensions which only sometimes match the 1404 corresponding outer extension SHOULD NOT be compressed. 1406 Clients MAY include additional extensions in ClientHelloOuter to 1407 avoid signaling unusual behavior to passive observers, provided the 1408 choice of value and value itself are not sensitive. See 1409 Section 10.9.4. 1411 10.6. Related Privacy Leaks 1413 ECH requires encrypted DNS to be an effective privacy protection 1414 mechanism. However, verifying the server's identity from the 1415 Certificate message, particularly when using the X509 1416 CertificateType, may result in additional network traffic that may 1417 reveal the server identity. Examples of this traffic may include 1418 requests for revocation information, such as OCSP or CRL traffic, or 1419 requests for repository information, such as 1420 authorityInformationAccess. It may also include implementation- 1421 specific traffic for additional information sources as part of 1422 verification. 1424 Implementations SHOULD avoid leaking information that may identify 1425 the server. Even when sent over an encrypted transport, such 1426 requests may result in indirect exposure of the server's identity, 1427 such as indicating a specific CA or service being used. To mitigate 1428 this risk, servers SHOULD deliver such information in-band when 1429 possible, such as through the use of OCSP stapling, and clients 1430 SHOULD take steps to minimize or protect such requests during 1431 certificate validation. 1433 Attacks that rely on non-ECH traffic to infer server identity in an 1434 ECH connection are out of scope for this document. For example, a 1435 client that connects to a particular host prior to ECH deployment may 1436 later resume a connection to that same host after ECH deployment. An 1437 adversary that observes this can deduce that the ECH-enabled 1438 connection was made to a host that the client previously connected to 1439 and which is within the same anonymity set. 1441 10.7. Cookies 1443 Section 4.2.2 of [RFC8446] defines a cookie value that servers may 1444 send in HelloRetryRequest for clients to echo in the second 1445 ClientHello. While ECH encrypts the cookie in the second 1446 ClientHelloInner, the backend server's HelloRetryRequest is 1447 unencrypted.This means differences in cookies between backend 1448 servers, such as lengths or cleartext components, may leak 1449 information about the server identity. 1451 Backend servers in an anonymity set SHOULD NOT reveal information in 1452 the cookie which identifies the server. This may be done by handling 1453 HelloRetryRequest statefully, thus not sending cookies, or by using 1454 the same cookie construction for all backend servers. 1456 Note that, if the cookie includes a key name, analogous to Section 4 1457 of [RFC5077], this may leak information if different backend servers 1458 issue cookies with different key names at the time of the connection. 1460 In particular, if the deployment operates in Split Mode, the backend 1461 servers may not share cookie encryption keys. Backend servers may 1462 mitigate this by either handling key rotation with trial decryption, 1463 or coordinating to match key names. 1465 10.8. Attacks Exploiting Acceptance Confirmation 1467 To signal acceptance, the backend server overwrites 8 bytes of its 1468 ServerHello.random with a value derived from the 1469 ClientHelloInner.random. (See Section 7.2 for details.) This 1470 behavior increases the likelihood of the ServerHello.random colliding 1471 with the ServerHello.random of a previous session, potentially 1472 reducing the overall security of the protocol. However, the 1473 remaining 24 bytes provide enough entropy to ensure this is not a 1474 practical avenue of attack. 1476 On the other hand, the probability that two 8-byte strings are the 1477 same is non-negligible. This poses a modest operational risk. 1478 Suppose the client-facing server terminates the connection (i.e., ECH 1479 is rejected or bypassed): if the last 8 bytes of its 1480 ServerHello.random coincide with the confirmation signal, then the 1481 client will incorrectly presume acceptance and proceed as if the 1482 backend server terminated the connection. However, the probability 1483 of a false positive occurring for a given connection is only 1 in 1484 2^64. This value is smaller than the probability of network 1485 connection failures in practice. 1487 Note that the same bytes of the ServerHello.random are used to 1488 implement downgrade protection for TLS 1.3 (see [RFC8446], 1489 Section 4.1.3). These mechanisms do not interfere because the 1490 backend server only signals ECH acceptance in TLS 1.3 or higher. 1492 10.9. Comparison Against Criteria 1494 [RFC8744] lists several requirements for SNI encryption. In this 1495 section, we re-iterate these requirements and assess the ECH design 1496 against them. 1498 10.9.1. Mitigate Cut-and-Paste Attacks 1500 Since servers process either ClientHelloInner or ClientHelloOuter, 1501 and because ClientHelloInner.random is encrypted, it is not possible 1502 for an attacker to "cut and paste" the ECH value in a different 1503 Client Hello and learn information from ClientHelloInner. 1505 10.9.2. Avoid Widely Shared Secrets 1507 This design depends upon DNS as a vehicle for semi-static public key 1508 distribution. Server operators may partition their private keys 1509 however they see fit provided each server behind an IP address has 1510 the corresponding private key to decrypt a key. Thus, when one ECH 1511 key is provided, sharing is optimally bound by the number of hosts 1512 that share an IP address. Server operators may further limit sharing 1513 by publishing different DNS records containing ECHConfig values with 1514 different keys using a short TTL. 1516 10.9.3. Prevent SNI-Based Denial-of-Service Attacks 1518 This design requires servers to decrypt ClientHello messages with 1519 ClientECH extensions carrying valid digests. Thus, it is possible 1520 for an attacker to force decryption operations on the server. This 1521 attack is bound by the number of valid TCP connections an attacker 1522 can open. 1524 10.9.4. Do Not Stick Out 1526 As a means of reducing the impact of network ossification, [RFC8744] 1527 recommends SNI-protection mechanisms be designed in such a way that 1528 network operators do not differentiate connections using the 1529 mechanism from connections not using the mechanism. To that end, ECH 1530 is designed to resemble a standard TLS handshake as much as possible. 1531 The most obvious difference is the extension itself: as long as 1532 middleboxes ignore it, as required by [RFC8446], the rest of the 1533 handshake is designed to look very much as usual. 1535 The GREASE ECH protocol described in Section 6.2 provides a low-risk 1536 way to evaluate the deployability of ECH. It is designed to mimic 1537 the real ECH protocol (Section 6.1) without changing the security 1538 properties of the handshake. The underlying theory is that if GREASE 1539 ECH is deployable without triggering middlebox misbehavior, and real 1540 ECH looks enough like GREASE ECH, then ECH should be deployable as 1541 well. Thus, our strategy for mitigating network ossification is to 1542 deploy GREASE ECH widely enough to disincentivize differential 1543 treatment of the real ECH protocol by the network. 1545 Ensuring that networks do not differentiate between real ECH and 1546 GREASE ECH may not be feasible for all implementations. While most 1547 middleboxes will not treat them differently, some operators may wish 1548 to block real ECH usage but allow GREASE ECH. This specification 1549 aims to provide a baseline security level that most deployments can 1550 achieve easily, while providing implementations enough flexibility to 1551 achieve stronger security where possible. Minimally, real ECH is 1552 designed to be indifferentiable from GREASE ECH for passive 1553 adversaries with following capabilities: 1. The attacker does not 1554 know the ECHConfigList used by the server. 1. The attacker keeps 1555 per-connection state only. In particular, it does not track 1556 endpoints across connections. 1. ECH and GREASE ECH are designed so 1557 that the following features do not vary: the code points of 1558 extensions negotiated in the clear; the length of messages; and the 1559 values of plaintext alert messages. 1561 This leaves a variety of practical differentiators out-of-scope. 1562 including, though not limited to, the following: 1. the value of the 1563 configuration identifier; 1. the value of the outer SNI; 1. use of 1564 the "pre_shared_key" extension in the ClientHelloOuter, which is 1565 permitted in GREASE ECH but not real ECH; [[TODO: Remove this 1566 differentiator if issue #384 is resolved by a spec change.]] 1. the 1567 TLS version negotiated, which may depend on ECH acceptance; 1. client 1568 authentication, which may depend on ECH acceptance; and 1. HRR 1569 issuance, which may depend on ECH acceptance. 1571 These can be addressed with more sophisticated implementations, but 1572 some mitigations require coordination between the client and server. 1573 These mitigations are out-of-scope for this specification. 1575 10.9.5. Maintain Forward Secrecy 1577 This design is not forward secret because the server's ECH key is 1578 static. However, the window of exposure is bound by the key 1579 lifetime. It is RECOMMENDED that servers rotate keys frequently. 1581 10.9.6. Enable Multi-party Security Contexts 1583 This design permits servers operating in Split Mode to forward 1584 connections directly to backend origin servers. The client 1585 authenticates the identity of the backend origin server, thereby 1586 avoiding unnecessary MiTM attacks. 1588 Conversely, assuming ECH records retrieved from DNS are 1589 authenticated, e.g., via DNSSEC or fetched from a trusted Recursive 1590 Resolver, spoofing a client-facing server operating in Split Mode is 1591 not possible. See Section 10.2 for more details regarding plaintext 1592 DNS. 1594 Authenticating the ECHConfig structure naturally authenticates the 1595 included public name. This also authenticates any retry signals from 1596 the client-facing server because the client validates the server 1597 certificate against the public name before retrying. 1599 10.9.7. Support Multiple Protocols 1601 This design has no impact on application layer protocol negotiation. 1602 It may affect connection routing, server certificate selection, and 1603 client certificate verification. Thus, it is compatible with 1604 multiple application and transport protocols. By encrypting the 1605 entire ClientHello, this design additionally supports encrypting the 1606 ALPN extension. 1608 10.10. Padding Policy 1610 Variations in the length of the ClientHelloInner ciphertext could 1611 leak information about the corresponding plaintext. Section 6.1.3 1612 describes a RECOMMENDED padding mechanism for clients aimed at 1613 reducing potential information leakage. 1615 10.11. Active Attack Mitigations 1617 This section describes the rationale for ECH properties and mechanics 1618 as defenses against active attacks. In all the attacks below, the 1619 attacker is on-path between the target client and server. The goal 1620 of the attacker is to learn private information about the inner 1621 ClientHello, such as the true SNI value. 1623 10.11.1. Client Reaction Attack Mitigation 1625 This attack uses the client's reaction to an incorrect certificate as 1626 an oracle. The attacker intercepts a legitimate ClientHello and 1627 replies with a ServerHello, Certificate, CertificateVerify, and 1628 Finished messages, wherein the Certificate message contains a "test" 1629 certificate for the domain name it wishes to query. If the client 1630 decrypted the Certificate and failed verification (or leaked 1631 information about its verification process by a timing side channel), 1632 the attacker learns that its test certificate name was incorrect. As 1633 an example, suppose the client's SNI value in its inner ClientHello 1634 is "example.com," and the attacker replied with a Certificate for 1635 "test.com". If the client produces a verification failure alert 1636 because of the mismatch faster than it would due to the Certificate 1637 signature validation, information about the name leaks. Note that 1638 the attacker can also withhold the CertificateVerify message. In 1639 that scenario, a client which first verifies the Certificate would 1640 then respond similarly and leak the same information. 1642 Client Attacker Server 1643 ClientHello 1644 + key_share 1645 + ech ------> (intercept) -----> X (drop) 1647 ServerHello 1648 + key_share 1649 {EncryptedExtensions} 1650 {CertificateRequest*} 1651 {Certificate*} 1652 {CertificateVerify*} 1653 <------ 1654 Alert 1655 ------> 1657 Figure 3: Client reaction attack 1659 ClientHelloInner.random prevents this attack. In particular, since 1660 the attacker does not have access to this value, it cannot produce 1661 the right transcript and handshake keys needed for encrypting the 1662 Certificate message. Thus, the client will fail to decrypt the 1663 Certificate and abort the connection. 1665 10.11.2. HelloRetryRequest Hijack Mitigation 1667 This attack aims to exploit server HRR state management to recover 1668 information about a legitimate ClientHello using its own attacker- 1669 controlled ClientHello. To begin, the attacker intercepts and 1670 forwards a legitimate ClientHello with an "encrypted_client_hello" 1671 (ech) extension to the server, which triggers a legitimate 1672 HelloRetryRequest in return. Rather than forward the retry to the 1673 client, the attacker, attempts to generate its own ClientHello in 1674 response based on the contents of the first ClientHello and 1675 HelloRetryRequest exchange with the result that the server encrypts 1676 the Certificate to the attacker. If the server used the SNI from the 1677 first ClientHello and the key share from the second (attacker- 1678 controlled) ClientHello, the Certificate produced would leak the 1679 client's chosen SNI to the attacker. 1681 Client Attacker Server 1682 ClientHello 1683 + key_share 1684 + ech ------> (forward) -------> 1685 HelloRetryRequest 1686 + key_share 1687 (intercept) <------- 1689 ClientHello 1690 + key_share' 1691 + ech' -------> 1692 ServerHello 1693 + key_share 1694 {EncryptedExtensions} 1695 {CertificateRequest*} 1696 {Certificate*} 1697 {CertificateVerify*} 1698 {Finished} 1699 <------- 1700 (process server flight) 1702 Figure 4: HelloRetryRequest hijack attack 1704 This attack is mitigated by using the same HPKE context for both 1705 ClientHello messages. The attacker does not possess the context's 1706 keys, so it cannot generate a valid encryption of the second inner 1707 ClientHello. 1709 If the attacker could manipulate the second ClientHello, it might be 1710 possible for the server to act as an oracle if it required parameters 1711 from the first ClientHello to match that of the second ClientHello. 1712 For example, imagine the client's original SNI value in the inner 1713 ClientHello is "example.com", and the attacker's hijacked SNI value 1714 in its inner ClientHello is "test.com". A server which checks these 1715 for equality and changes behavior based on the result can be used as 1716 an oracle to learn the client's SNI. 1718 10.11.3. ClientHello Malleability Mitigation 1720 This attack aims to leak information about secret parts of the 1721 encrypted ClientHello by adding attacker-controlled parameters and 1722 observing the server's response. In particular, the compression 1723 mechanism described in Section 5.1 references parts of a potentially 1724 attacker-controlled ClientHelloOuter to construct ClientHelloInner, 1725 or a buggy server may incorrectly apply parameters from 1726 ClientHelloOuter to the handshake. 1728 To begin, the attacker first interacts with a server to obtain a 1729 resumption ticket for a given test domain, such as "example.com". 1730 Later, upon receipt of a ClientHelloOuter, it modifies it such that 1731 the server will process the resumption ticket with ClientHelloInner. 1732 If the server only accepts resumption PSKs that match the server 1733 name, it will fail the PSK binder check with an alert when 1734 ClientHelloInner is for "example.com" but silently ignore the PSK and 1735 continue when ClientHelloInner is for any other name. This 1736 introduces an oracle for testing encrypted SNI values. 1738 Client Attacker Server 1740 handshake and ticket 1741 for "example.com" 1742 <--------> 1744 ClientHello 1745 + key_share 1746 + ech 1747 + ech_outer_extensions(pre_shared_key) 1748 + pre_shared_key 1749 --------> 1750 (intercept) 1751 ClientHello 1752 + key_share 1753 + ech 1754 + ech_outer_extensions(pre_shared_key) 1755 + pre_shared_key' 1756 --------> 1757 Alert 1758 -or- 1759 ServerHello 1760 ... 1761 Finished 1762 <-------- 1764 Figure 5: Message flow for malleable ClientHello 1766 This attack may be generalized to any parameter which the server 1767 varies by server name, such as ALPN preferences. 1769 ECH mitigates this attack by only negotiating TLS parameters from 1770 ClientHelloInner and authenticating all inputs to the 1771 ClientHelloInner (EncodedClientHelloInner and ClientHelloOuter) with 1772 the HPKE AEAD. See Section 5.2. An earlier iteration of this 1773 specification only encrypted and authenticated the "server_name" 1774 extension, which left the overall ClientHello vulnerable to an 1775 analogue of this attack. 1777 11. IANA Considerations 1779 11.1. Update of the TLS ExtensionType Registry 1781 IANA is requested to create the following three entries in the 1782 existing registry for ExtensionType (defined in [RFC8446]): 1784 1. encrypted_client_hello(0xfe0b), with "TLS 1.3" column values set 1785 to "CH, HRR, EE", and "Recommended" column set to "Yes". 1787 2. ech_outer_extensions(0xfd00), with the "TLS 1.3" column values 1788 set to "", and "Recommended" column set to "Yes". 1790 11.2. Update of the TLS Alert Registry 1792 IANA is requested to create an entry, ech_required(121) in the 1793 existing registry for Alerts (defined in [RFC8446]), with the "DTLS- 1794 OK" column set to "Y". 1796 12. ECHConfig Extension Guidance 1798 Any future information or hints that influence ClientHelloOuter 1799 SHOULD be specified as ECHConfig extensions. This is primarily 1800 because the outer ClientHello exists only in support of ECH. Namely, 1801 it is both an envelope for the encrypted inner ClientHello and 1802 enabler for authenticated key mismatch signals (see Section 7). In 1803 contrast, the inner ClientHello is the true ClientHello used upon ECH 1804 negotiation. 1806 13. References 1808 13.1. Normative References 1810 [HTTPS-RR] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 1811 and parameter specification via the DNS (DNS SVCB and 1812 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 1813 dnsop-svcb-https-05, 21 April 2021, 1814 . 1817 [I-D.ietf-tls-exported-authenticator] 1818 Sullivan, N., "Exported Authenticators in TLS", Work in 1819 Progress, Internet-Draft, draft-ietf-tls-exported- 1820 authenticator-14, 25 January 2021, 1821 . 1824 [I-D.irtf-cfrg-hpke] 1825 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 1826 "Hybrid Public Key Encryption", Work in Progress, 1827 Internet-Draft, draft-irtf-cfrg-hpke-09, 26 May 2021, 1828 . 1830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1831 Requirement Levels", BCP 14, RFC 2119, 1832 DOI 10.17487/RFC2119, March 1997, 1833 . 1835 [RFC5890] Klensin, J., "Internationalized Domain Names for 1836 Applications (IDNA): Definitions and Document Framework", 1837 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1838 . 1840 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 1841 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 1842 October 2015, . 1844 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 1845 Layer Security (TLS) False Start", RFC 7918, 1846 DOI 10.17487/RFC7918, August 2016, 1847 . 1849 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1850 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1851 May 2017, . 1853 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1854 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1855 . 1857 13.2. Informative References 1859 [I-D.kazuho-protected-sni] 1860 Oku, K., "TLS Extensions for Protecting SNI", Work in 1861 Progress, Internet-Draft, draft-kazuho-protected-sni-00, 1862 18 July 2017, . 1865 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1866 Resource Identifier (URI): Generic Syntax", STD 66, 1867 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1868 . 1870 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1871 "Transport Layer Security (TLS) Session Resumption without 1872 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1873 January 2008, . 1875 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1876 "Transport Layer Security (TLS) Application-Layer Protocol 1877 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1878 July 2014, . 1880 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1881 and P. Hoffman, "Specification for DNS over Transport 1882 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1883 2016, . 1885 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1886 (TLS) Cached Information Extension", RFC 7924, 1887 DOI 10.17487/RFC7924, July 2016, 1888 . 1890 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1891 Transport Layer Security (DTLS)", RFC 8094, 1892 DOI 10.17487/RFC8094, February 2017, 1893 . 1895 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1896 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1897 . 1899 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 1900 Sustain Extensibility (GREASE) to TLS Extensibility", 1901 RFC 8701, DOI 10.17487/RFC8701, January 2020, 1902 . 1904 [RFC8744] Huitema, C., "Issues and Requirements for Server Name 1905 Identification (SNI) Encryption in TLS", RFC 8744, 1906 DOI 10.17487/RFC8744, July 2020, 1907 . 1909 [WHATWG-IPV4] 1910 "URL Living Standard - IPv4 Parser", May 2021, 1911 . 1913 Appendix A. Alternative SNI Protection Designs 1915 Alternative approaches to encrypted SNI may be implemented at the TLS 1916 or application layer. In this section we describe several 1917 alternatives and discuss drawbacks in comparison to the design in 1918 this document. 1920 A.1. TLS-layer 1922 A.1.1. TLS in Early Data 1924 In this variant, TLS Client Hellos are tunneled within early data 1925 payloads belonging to outer TLS connections established with the 1926 client-facing server. This requires clients to have established a 1927 previous session --- and obtained PSKs --- with the server. The 1928 client-facing server decrypts early data payloads to uncover Client 1929 Hellos destined for the backend server, and forwards them onwards as 1930 necessary. Afterwards, all records to and from backend servers are 1931 forwarded by the client-facing server -- unmodified. This avoids 1932 double encryption of TLS records. 1934 Problems with this approach are: (1) servers may not always be able 1935 to distinguish inner Client Hellos from legitimate application data, 1936 (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may 1937 not be supported -- especially under DoS -- leading to availability 1938 concerns, and (4) clients must bootstrap tunnels (sessions), costing 1939 an additional round trip and potentially revealing the SNI during the 1940 initial connection. In contrast, encrypted SNI protects the SNI in a 1941 distinct Client Hello extension and neither abuses early data nor 1942 requires a bootstrapping connection. 1944 A.1.2. Combined Tickets 1946 In this variant, client-facing and backend servers coordinate to 1947 produce "combined tickets" that are consumable by both. Clients 1948 offer combined tickets to client-facing servers. The latter parse 1949 them to determine the correct backend server to which the Client 1950 Hello should be forwarded. This approach is problematic due to non- 1951 trivial coordination between client-facing and backend servers for 1952 ticket construction and consumption. Moreover, it requires a 1953 bootstrapping step similar to that of the previous variant. In 1954 contrast, encrypted SNI requires no such coordination. 1956 A.2. Application-layer 1957 A.2.1. HTTP/2 CERTIFICATE Frames 1959 In this variant, clients request secondary certificates with 1960 CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. 1961 In response, servers supply certificates via TLS exported 1962 authenticators [I-D.ietf-tls-exported-authenticator] in CERTIFICATE 1963 frames. Clients use a generic SNI for the underlying client-facing 1964 server TLS connection. Problems with this approach include: (1) one 1965 additional round trip before peer authentication, (2) non-trivial 1966 application-layer dependencies and interaction, and (3) obtaining the 1967 generic SNI to bootstrap the connection. In contrast, encrypted SNI 1968 induces no additional round trip and operates below the application 1969 layer. 1971 Appendix B. Linear-time Outer Extension Processing 1973 The following procedure processes the "ech_outer_extensions" 1974 extension (see Section 5.1) in linear time: 1976 1. Let I be zero and N be the number of extensions in 1977 ClientHelloOuter. 1979 2. For each extension type, E, in OuterExtensions: 1981 * If E is "encrypted_client_hello", abort the connection with an 1982 "illegal_parameter" alert and terminate this procedure. 1984 * While I is less than N and the I-th extension of 1985 ClientHelloOuter does not have type E, increment I. 1987 * If I is equal to N, abort the connection with an 1988 "illegal_parameter" alert and terminate this procedure. 1990 * Otherwise, the I-th extension of ClientHelloOuter has type E. 1991 Copy it to the EncodedClientHelloInner and increment I. 1993 Appendix C. Acknowledgements 1995 This document draws extensively from ideas in 1996 [I-D.kazuho-protected-sni], but is a much more limited mechanism 1997 because it depends on the DNS for the protection of the ECH key. 1998 Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, 1999 Nick Sullivan, Martin Thomson, and David Benjamin also provided 2000 important ideas and contributions. 2002 Appendix D. Change Log 2003 *RFC Editor's Note:* Please remove this section prior to 2004 publication of a final version of this document. 2006 Issue and pull request numbers are listed with a leading octothorp. 2008 D.1. Since draft-ietf-tls-esni-10 2010 * Make HRR confirmation and ECH acceptance explicit (#422, #423) 2012 * Relax computation of the acceptance signal (#420, #449) 2014 * Simplify ClientHelloOuterAAD generation (#438, #442) 2016 * Allow empty enc in ClientECH (#444) 2018 * Authenticate ClientECH extensions position in ClientHelloOuterAAD 2019 (#410) 2021 * Allow clients to send a dummy PSK and early_data in 2022 ClientHelloOuter when applicable (#414, #415) 2024 * Compress ECHConfigContents (#409) 2026 * Validate ECHConfig.contents.public_name (#413, #456) 2028 * Validate ClientHelloInner contents (#411) 2030 * Note split-mode challenges for HRR (#418) 2032 * Editorial improvements (#428, #432, #439, #445, #458, #455) 2034 D.2. Since draft-ietf-tls-esni-09 2036 * Finalize HPKE dependency (#390) 2038 * Move from client-computed to server-chosen, one-byte config 2039 identifier (#376, #381) 2041 * Rename ECHConfigs to ECHConfigList (#391) 2043 * Clarify some security and privacy properties (#385, #383) 2045 Authors' Addresses 2047 Eric Rescorla 2048 RTFM, Inc. 2050 Email: ekr@rtfm.com 2051 Kazuho Oku 2052 Fastly 2054 Email: kazuhooku@gmail.com 2056 Nick Sullivan 2057 Cloudflare 2059 Email: nick@cloudflare.com 2061 Christopher A. Wood 2062 Cloudflare 2064 Email: caw@heapingbits.net