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