idnits 2.17.1 draft-ietf-tls-esni-10.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 (8 March 2021) is 1144 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-02 == 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-07 ** 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 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: 9 September 2021 Fastly 6 N. Sullivan 7 C.A. Wood 8 Cloudflare 9 8 March 2021 11 TLS Encrypted Client Hello 12 draft-ietf-tls-esni-10 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 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 9 September 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Encrypted ClientHello (ECH) . . . . . . . . . . . . . . . 6 57 4. Encrypted ClientHello Configuration . . . . . . . . . . . . . 7 58 4.1. Configuration Extensions . . . . . . . . . . . . . . . . 9 59 5. The "encrypted_client_hello" Extension . . . . . . . . . . . 9 60 5.1. Encoding the ClientHelloInner . . . . . . . . . . . . . . 10 61 5.2. Authenticating the ClientHelloOuter . . . . . . . . . . . 12 62 6. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 63 6.1. Offering ECH . . . . . . . . . . . . . . . . . . . . . . 13 64 6.1.1. ClientHelloInner Indication Extension . . . . . . . . 15 65 6.1.2. Recommended Padding Scheme . . . . . . . . . . . . . 16 66 6.1.3. Handling the Server Response . . . . . . . . . . . . 16 67 6.1.4. Handling HelloRetryRequest . . . . . . . . . . . . . 18 68 6.2. GREASE ECH . . . . . . . . . . . . . . . . . . . . . . . 20 69 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 70 7.1. Client-Facing Server . . . . . . . . . . . . . . . . . . 21 71 7.1.1. Handling HelloRetryRequest . . . . . . . . . . . . . 23 72 7.2. Backend Server . . . . . . . . . . . . . . . . . . . . . 24 73 8. Compatibility Issues . . . . . . . . . . . . . . . . . . . . 25 74 8.1. Misconfiguration and Deployment Concerns . . . . . . . . 25 75 8.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 25 76 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 26 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 78 10.1. Security and Privacy Goals . . . . . . . . . . . . . . . 26 79 10.2. Unauthenticated and Plaintext DNS . . . . . . . . . . . 28 80 10.3. Client Tracking . . . . . . . . . . . . . . . . . . . . 28 81 10.4. Optional Configuration Identifiers and Trial 82 Decryption . . . . . . . . . . . . . . . . . . . . . . 28 83 10.5. Outer ClientHello . . . . . . . . . . . . . . . . . . . 29 84 10.6. Related Privacy Leaks . . . . . . . . . . . . . . . . . 30 85 10.7. Attacks Exploiting Acceptance Confirmation . . . . . . . 30 86 10.8. Comparison Against Criteria . . . . . . . . . . . . . . 31 87 10.8.1. Mitigate Cut-and-Paste Attacks . . . . . . . . . . . 31 88 10.8.2. Avoid Widely Shared Secrets . . . . . . . . . . . . 31 89 10.8.3. Prevent SNI-Based Denial-of-Service Attacks . . . . 31 90 10.8.4. Do Not Stick Out . . . . . . . . . . . . . . . . . . 32 91 10.8.5. Maintain Forward Secrecy . . . . . . . . . . . . . . 32 92 10.8.6. Enable Multi-party Security Contexts . . . . . . . . 32 93 10.8.7. Support Multiple Protocols . . . . . . . . . . . . . 32 94 10.9. Padding Policy . . . . . . . . . . . . . . . . . . . . . 33 95 10.10. Active Attack Mitigations . . . . . . . . . . . . . . . 33 96 10.10.1. Client Reaction Attack Mitigation . . . . . . . . . 33 97 10.10.2. HelloRetryRequest Hijack Mitigation . . . . . . . . 34 98 10.10.3. ClientHello Malleability Mitigation . . . . . . . . 35 99 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 100 11.1. Update of the TLS ExtensionType Registry . . . . . . . . 36 101 11.2. Update of the TLS Alert Registry . . . . . . . . . . . . 37 102 12. ECHConfig Extension Guidance . . . . . . . . . . . . . . . . 37 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 104 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 105 13.2. Informative References . . . . . . . . . . . . . . . . . 38 106 Appendix A. Alternative SNI Protection Designs . . . . . . . . . 39 107 A.1. TLS-layer . . . . . . . . . . . . . . . . . . . . . . . . 39 108 A.1.1. TLS in Early Data . . . . . . . . . . . . . . . . . . 39 109 A.1.2. Combined Tickets . . . . . . . . . . . . . . . . . . 40 110 A.2. Application-layer . . . . . . . . . . . . . . . . . . . . 40 111 A.2.1. HTTP/2 CERTIFICATE Frames . . . . . . . . . . . . . . 40 112 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 40 113 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 41 114 C.1. Since draft-ietf-tls-esni-09 . . . . . . . . . . . . . . 41 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 117 1. Introduction 119 DISCLAIMER: This draft is work-in-progress and has not yet seen 120 significant (or really any) security analysis. It should not be used 121 as a basis for building production systems. 123 Although TLS 1.3 [RFC8446] encrypts most of the handshake, including 124 the server certificate, there are several ways in which an on-path 125 attacker can learn private information about the connection. The 126 plaintext Server Name Indication (SNI) extension in ClientHello 127 messages, which leaks the target domain for a given connection, is 128 perhaps the most sensitive, unencrypted information in TLS 1.3. 130 The target domain may also be visible through other channels, such as 131 plaintext client DNS queries, visible server IP addresses (assuming 132 the server does not use domain-based virtual hosting), or other 133 indirect mechanisms such as traffic analysis. DoH [RFC8484] and 134 DPRIVE [RFC7858] [RFC8094] provide mechanisms for clients to conceal 135 DNS lookups from network inspection, and many TLS servers host 136 multiple domains on the same IP address. In such environments, the 137 SNI remains the primary explicit signal used to determine the 138 server's identity. 140 The TLS Working Group has studied the problem of protecting the SNI, 141 but has been unable to develop a completely generic solution. 142 [RFC8744] provides a description of the problem space and some of the 143 proposed techniques. One of the more difficult problems is "Do not 144 stick out" ([RFC8744], Section 3.4): if only sensitive or private 145 services use SNI encryption, then SNI encryption is a signal that a 146 client is going to such a service. For this reason, much recent work 147 has focused on concealing the fact that the SNI is being protected. 148 Unfortunately, the result often has undesirable performance 149 consequences, incomplete coverage, or both. 151 The protocol specified by this document takes a different approach. 152 It assumes that private origins will co-locate with or hide behind a 153 provider (reverse proxy, application server, etc.) that protects 154 sensitive ClientHello parameters, including the SNI, for all of the 155 domains it hosts. These co-located servers form an anonymity set 156 wherein all elements have a consistent configuration, e.g., the set 157 of supported application protocols, ciphersuites, TLS versions, and 158 so on. Usage of this mechanism reveals that a client is connecting 159 to a particular service provider, but does not reveal which server 160 from the anonymity set terminates the connection. Thus, it leaks no 161 more than what is already visible from the server IP address. 163 This document specifies a new TLS extension, called Encrypted Client 164 Hello (ECH), that allows clients to encrypt their ClientHello to a 165 supporting server. This protects the SNI and other potentially 166 sensitive fields, such as the ALPN list [RFC7301]. This extension is 167 only supported with (D)TLS 1.3 [RFC8446] and newer versions of the 168 protocol. 170 2. Conventions and Definitions 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. All TLS notation comes from [RFC8446], 177 Section 3. 179 3. Overview 181 This protocol is designed to operate in one of two topologies 182 illustrated below, which we call "Shared Mode" and "Split Mode". 184 3.1. Topologies 185 +---------------------+ 186 | | 187 | 2001:DB8::1111 | 188 | | 189 Client <-----> | private.example.org | 190 | | 191 | public.example.com | 192 | | 193 +---------------------+ 194 Server 196 Figure 1: Shared Mode Topology 198 In Shared Mode, the provider is the origin server for all the domains 199 whose DNS records point to it. In this mode, the TLS connection is 200 terminated by the provider. 202 +--------------------+ +---------------------+ 203 | | | | 204 | 2001:DB8::1111 | | 2001:DB8::EEEE | 205 Client <----------------------------->| | 206 | public.example.com | | private.example.com | 207 | | | | 208 +--------------------+ +---------------------+ 209 Client-Facing Server Backend Server 211 Figure 2: Split Mode Topology 213 In Split Mode, the provider is not the origin server for private 214 domains. Rather, the DNS records for private domains point to the 215 provider, and the provider's server relays the connection back to the 216 origin server, who terminates the TLS connection with the client. 217 Importantly, service provider does not have access to the plaintext 218 of the connection. 220 In the remainder of this document, we will refer to the ECH-service 221 provider as the "client-facing server" and to the TLS terminator as 222 the "backend server". These are the same entity in Shared Mode, but 223 in Split Mode, the client-facing and backend servers are physically 224 separated. 226 3.2. Encrypted ClientHello (ECH) 228 ECH allows the client to encrypt sensitive ClientHello extensions, 229 e.g., SNI, ALPN, etc., under the public key of the client-facing 230 server. This requires the client-facing server to publish the public 231 key and metadata it uses for ECH for all the domains for which it 232 serves directly or indirectly (via Split Mode). This document 233 defines the format of the ECH encryption public key and metadata, 234 referred to as an ECH configuration, and delegates DNS publication 235 details to [HTTPS-RR], though other delivery mechanisms are possible. 236 In particular, if some of the clients of a private server are 237 applications rather than Web browsers, those applications might have 238 the public key and metadata preconfigured. 240 When a client wants to establish a TLS session with the backend 241 server, it constructs its ClientHello as indicated in Section 6.1. 242 We will refer to this as the ClientHelloInner message. The client 243 encrypts this message using the public key of the ECH configuration. 244 It then constructs a new ClientHello, the ClientHelloOuter, with 245 innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and 246 with an "encrypted_client_hello" extension, which this document 247 defines (Section 5). The extension's payload carries the encrypted 248 ClientHelloInner and specifies the ECH configuration used for 249 encryption. Finally, it sends ClientHelloOuter to the server. 251 Upon receiving the ClientHelloOuter, a TLS server takes one of the 252 following actions: 254 1. If it does not support ECH, it ignores the 255 "encrypted_client_hello" extension and proceeds with the 256 handshake as usual, per [RFC8446], Section 4.1.2. 258 2. If it is a client-facing server for the ECH protocol, but cannot 259 decrypt the extension, then it terminates the handshake using the 260 ClientHelloOuter. This is referred to as "ECH rejection". When 261 ECH is rejected, the client-facing server sends an acceptable ECH 262 configuration in its EncryptedExtensions message. 264 3. If it supports ECH and decrypts the extension, it forwards the 265 ClientHelloInner to the backend server, who terminates the 266 connection. This is referred to as "ECH acceptance". 268 Upon receiving the server's response, the client determines whether 269 or not ECH was accepted and proceeds with the handshake accordingly. 270 (See Section 6 for details.) 271 The primary goal of ECH is to ensure that connections to servers in 272 the same anonymity set are indistinguishable from one another. 273 Moreover, it should achieve this goal without affecting any existing 274 security properties of TLS 1.3. See Section 10.1 for more details 275 about the ECH security and privacy goals. 277 4. Encrypted ClientHello Configuration 279 ECH uses draft-08 of HPKE for public key encryption 280 [I-D.irtf-cfrg-hpke]. The ECH configuration is defined by the 281 following "ECHConfig" structure. 283 opaque HpkePublicKey<1..2^16-1>; 284 uint16 HpkeKemId; // Defined in I-D.irtf-cfrg-hpke 285 uint16 HpkeKdfId; // Defined in I-D.irtf-cfrg-hpke 286 uint16 HpkeAeadId; // Defined in I-D.irtf-cfrg-hpke 288 struct { 289 HpkeKdfId kdf_id; 290 HpkeAeadId aead_id; 291 } HpkeSymmetricCipherSuite; 293 struct { 294 uint8 config_id; 295 HpkeKemId kem_id; 296 HpkePublicKey public_key; 297 HpkeSymmetricCipherSuite cipher_suites<4..2^16-4>; 298 } HpkeKeyConfig; 300 struct { 301 HpkeKeyConfig key_config; 302 uint16 maximum_name_length; 303 opaque public_name<1..2^16-1>; 304 Extension extensions<0..2^16-1>; 305 } ECHConfigContents; 307 struct { 308 uint16 version; 309 uint16 length; 310 select (ECHConfig.version) { 311 case 0xfe0a: ECHConfigContents contents; 312 } 313 } ECHConfig; 315 The structure contains the following fields: 317 version The version of ECH for which this configuration is used. 319 Beginning with draft-08, the version is the same as the code point 320 for the "encrypted_client_hello" extension. Clients MUST ignore 321 any "ECHConfig" structure with a version they do not support. 323 length The length, in bytes, of the next field. 325 contents An opaque byte string whose contents depend on the version. 326 For this specification, the contents are an "ECHConfigContents" 327 structure. 329 The "ECHConfigContents" structure contains the following fields: 331 key_config A "HpkeKeyConfig" structure carrying the configuration 332 information associated with the HPKE public key. Note that this 333 structure contains the "config_id" field, which applies to the 334 entire ECHConfigContents. Sites MUST NOT publish two different 335 "ECHConfigContents" values with the same "HpkeKeyConfig" value. 336 The RECOMMENDED technique for choosing "config_id" is to choose a 337 random byte. This process is repeated if this config_id matches 338 that of any valid ECHConfig, which could include any ECHConfig 339 that has been recently removed from active use. 341 maximum_name_length The longest name of a backend server, if known. 342 If this value is not known it can be set to zero, in which case 343 clients SHOULD use the inner ClientHello padding scheme described 344 below. That could happen if wildcard names are in use, or if 345 names can be added or removed from the anonymity set during the 346 lifetime of a particular ECH configuration. 348 public_name The non-empty name of the client-facing server, i.e., 349 the entity trusted to update the ECH configuration. This is used 350 to correct misconfigured clients, as described in Section 6.1.3. 352 extensions A list of extensions that the client must take into 353 consideration when generating a ClientHello message. These are 354 described below (Section 4.1). 356 The "HpkeKeyConfig" structure contains the following fields: 358 config_id A one-byte identifier for the given HPKE key 359 configuration. This is used by clients to indicate the key used 360 for ClientHello encryption. 362 kem_id The HPKE KEM identifier corresponding to "public_key". 363 Clients MUST ignore any "ECHConfig" structure with a key using a 364 KEM they do not support. 366 public_key The HPKE public key used by the client to encrypt 367 ClientHelloInner. 369 cipher_suites The list of HPKE KDF and AEAD identifier pairs clients 370 can use for encrypting ClientHelloInner. 372 The client-facing server advertises a sequence of ECH configurations 373 to clients, serialized as follows. 375 ECHConfig ECHConfigList<1..2^16-1>; 377 The "ECHConfigList" structure contains one or more "ECHConfig" 378 structures in decreasing order of preference. This allows a server 379 to support multiple versions of ECH and multiple sets of ECH 380 parameters. 382 4.1. Configuration Extensions 384 ECH configuration extensions are used to provide room for additional 385 functionality as needed. See Section 12 for guidance on which types 386 of extensions are appropriate for this structure. 388 The format is as defined in [RFC8446], Section 4.2. The same 389 interpretation rules apply: extensions MAY appear in any order, but 390 there MUST NOT be more than one extension of the same type in the 391 extensions block. An extension can be tagged as mandatory by using 392 an extension type codepoint with the high order bit set to 1. A 393 client that receives a mandatory extension they do not understand 394 MUST reject the "ECHConfig" content. 396 Clients MUST parse the extension list and check for unsupported 397 mandatory extensions. If an unsupported mandatory extension is 398 present, clients MUST ignore the "ECHConfig". 400 5. The "encrypted_client_hello" Extension 402 The encrypted ClientHelloInner is carried in an 403 "encrypted_client_hello" extension, defined as follows: 405 enum { 406 encrypted_client_hello(0xfe0a), (65535) 407 } ExtensionType; 409 When offered by the client, the extension appears only in the 410 ClientHelloOuter. The payload MUST have the following structure: 412 struct { 413 HpkeSymmetricCipherSuite cipher_suite; 414 uint8 config_id; 415 opaque enc<1..2^16-1>; 416 opaque payload<1..2^16-1>; 417 } ClientECH; 419 config_id The ECHConfigContents.key_config.config_id for the chosen 420 ECHConfig. 422 cipher_suite The cipher suite used to encrypt ClientHelloInner. 423 This MUST match a value provided in the corresponding 424 "ECHConfigContents.cipher_suites" list. 426 enc The HPKE encapsulated key, used by servers to decrypt the 427 corresponding "payload" field. 429 payload The serialized and encrypted ClientHelloInner structure, 430 encrypted using HPKE as described in Section 6.1. 432 When the client offers the "encrypted_client_hello" extension, the 433 server MAY include an "encrypted_client_hello" extension in its 434 EncryptedExtensions message with the following payload: 436 struct { 437 ECHConfigList retry_configs; 438 } ServerECH; 440 retry_configs An ECHConfigList structure containing one or more 441 ECHConfig structures, in decreasing order of preference, to be 442 used by the client in subsequent connection attempts. These are 443 known as the server's "retry configurations". 445 This document also defines the "ech_required" alert, which the client 446 MUST send when it offered an "encrypted_client_hello" extension that 447 was not accepted by the server. (See Section 11.2.) 449 5.1. Encoding the ClientHelloInner 451 Some TLS 1.3 extensions can be quite large, thus repeating them in 452 the ClientHelloInner and ClientHelloOuter can lead to an excessive 453 overall size. One pathological example is "key_share" with post- 454 quantum algorithms. To reduce the impact of duplicated extensions, 455 the client may use the "ech_outer_extensions" extension. 457 enum { 458 ech_outer_extensions(0xfd00), (65535) 459 } ExtensionType; 461 ExtensionType OuterExtensions<2..254>; 463 OuterExtensions consists of one or more ExtensionType values, each of 464 which reference an extension in ClientHelloOuter. 466 When sending ClientHello, the client first computes ClientHelloInner, 467 including any PSK binders. It then computes a new value, the 468 EncodedClientHelloInner, by first making a copy of ClientHelloInner. 469 It then replaces the legacy_session_id field with an empty string. 471 The client then MAY substitute extensions which it knows will be 472 duplicated in ClientHelloOuter. To do so, the client removes and 473 replaces extensions from EncodedClientHelloInner with a single 474 "ech_outer_extensions" extension. Removed extensions MUST be ordered 475 consecutively in ClientHelloInner. The list of outer extensions, 476 OuterExtensions, includes those which were removed from 477 EncodedClientHelloInner, in the order in which they were removed. 479 Finally, EncodedClientHelloInner is serialized as a ClientHello 480 structure, defined in Section 4.1.2 of [RFC8446]. Note this does not 481 include the four-byte header included in the Handshake structure. 483 The client-facing server computes ClientHelloInner by reversing this 484 process. First it makes a copy of EncodedClientHelloInner and copies 485 the legacy_session_id field from ClientHelloOuter. It then looks for 486 an "ech_outer_extensions" extension. If found, it replaces the 487 extension with the corresponding sequence of extensions in the 488 ClientHelloOuter. If any referenced extensions are missing or if 489 "encrypted_client_hello" appears in the list, the server MUST abort 490 the connection with an "illegal_parameter" alert. 492 The "ech_outer_extensions" extension is only used for compressing the 493 ClientHelloInner. It MUST NOT be sent in either ClientHelloOuter or 494 ClientHelloInner. 496 Note that it is possible to implement decoding of the 497 EncodedClientHelloInner in a way that creates a denial-of-service 498 vulnerability. Specifically, the server needs to check that each 499 extension in the OuterExtensions list appears in the 500 ClientHelloOuter. The naive strategy would require O(N*M) time, 501 where N is the number of extensions in the ClientHelloOuter and M is 502 the number of extensions in the OuterExtensions list. Malicious 503 clients could exploit this behavior in order to cause excessive work 504 for the server, possibly making it unavailable. This problem can be 505 mitigated by representing OuterExtensions in a way that allows it to 506 be searched more quickly. For example, the runtime can be improved 507 to O(N*log(M)) by sorting the OuterExtensions and using binary search 508 to access it. 510 5.2. Authenticating the ClientHelloOuter 512 To prevent a network attacker from modifying the reconstructed 513 ClientHelloInner (see Section 10.10.3), ECH authenticates 514 ClientHelloOuter by computing ClientHelloOuterAAD as described below 515 and passing it in as the associated data for HPKE sealing and opening 516 operations. ClientHelloOuterAAD has the following structure: 518 struct { 519 HpkeSymmetricCipherSuite cipher_suite; 520 uint8 config_id; 521 opaque enc<1..2^16-1>; 522 opaque outer_hello<1..2^24-1>; 523 } ClientHelloOuterAAD; 525 The first three parameters are equal to, respectively, the 526 "ClientECH.cipher_suite", "ClientECH.config_id", and "ClientECH.enc" 527 fields of the payload of the "encrypted_client_hello" extension. The 528 last parameter, "outer_hello", is computed by serializing 529 ClientHelloOuter with the "encrypted_client_hello" extension removed. 530 Note this does not include the four-byte header included in the 531 Handshake structure. 533 Note the decompression process in Section 5.1 forbids 534 "encrypted_client_hello" in OuterExtensions. This ensures the 535 unauthenticated portion of ClientHelloOuter is not incorporated into 536 ClientHelloInner. 538 6. Client Behavior 540 Clients that implement the ECH extension behave in one of two ways: 541 either they offer a real ECH extension, as described in Section 6.1; 542 or they send a GREASE ECH extension, as described in Section 6.2. 543 Clients of the latter type do not negotiate ECH. Instead, they 544 generate a dummy ECH extension that is ignored by the server. (See 545 Section 10.8.4 for an explanation.) The client offers ECH if it is 546 in possession of a compatible ECH configuration and sends GREASE ECH 547 otherwise. 549 6.1. Offering ECH 551 To offer ECH, the client first chooses a suitable ECHConfig from the 552 server's ECHConfigList. To determine if a given "ECHConfig" is 553 suitable, it checks that it supports the KEM algorithm identified by 554 "ECHConfig.contents.kem_id", at least one KDF/AEAD algorithm 555 identified by "ECHConfig.contents.cipher_suites", and the version of 556 ECH indicated by "ECHConfig.contents.version". Once a suitable 557 configuration is found, the client selects the cipher suite it will 558 use for encryption. It MUST NOT choose a cipher suite or version not 559 advertised by the configuration. If no compatible configuration is 560 found, then the client SHOULD proceed as described in Section 6.2. 562 Next, the client constructs the ClientHelloInner message just as it 563 does a standard ClientHello, with the exception of the following 564 rules: 566 1. It MUST NOT offer to negotiate TLS 1.2 or below. This is 567 necessary to ensure the backend server does not negotiate a TLS 568 version that is incompatible with ECH. 570 2. It MUST NOT offer to resume any session for TLS 1.2 and below. 572 3. It SHOULD contain TLS padding [RFC7685] as described in 573 Section 6.1.2. 575 4. If it intends to compress any extensions (see Section 5.1), it 576 MUST order those extensions consecutively. 578 5. It MUST include the "ech_is_inner" extension as defined in 579 Section 6.1.1. (This requirement is not applicable when the 580 "encrypted_client_hello" extension is generated as described in 581 Section 6.2.) 583 The client then constructs EncodedClientHelloInner as described in 584 Section 5.1. Finally, it constructs the ClientHelloOuter message 585 just as it does a standard ClientHello, with the exception of the 586 following rules: 588 1. It MUST offer to negotiate TLS 1.3 or above. 590 2. If it compressed any extensions in EncodedClientHelloInner, it 591 MUST copy the corresponding extensions from ClientHelloInner. 593 3. It MUST ensure that all extensions or parameters in 594 ClientHelloInner that might change in response to receiving 595 HelloRetryRequest match that in ClientHelloOuter. See 596 Section 6.1.4 for more information. 598 4. It MUST copy the legacy_session_id field from ClientHelloInner. 599 This allows the server to echo the correct session ID for TLS 600 1.3's compatibility mode (see Appendix D.4 of [RFC8446]) when ECH 601 is negotiated. 603 5. It MAY copy any other field from the ClientHelloInner except 604 ClientHelloInner.random. Instead, It MUST generate a fresh 605 ClientHelloOuter.random using a secure random number generator. 606 (See Section 10.10.1.) 608 6. It MUST include an "encrypted_client_hello" extension with a 609 payload constructed as described below. 611 7. The value of "ECHConfig.contents.public_name" MUST be placed in 612 the "server_name" extension. 614 8. It MUST NOT include the "pre_shared_key" extension. (See 615 Section 10.10.3.) 617 [[OPEN ISSUE: We currently require HRR-sensitive parameters to match 618 in ClientHelloInner and ClientHelloOuter in order to simplify client- 619 side logic in the event of HRR. See https://github.com/tlswg/draft- 620 ietf-tls-esni/pull/316 for more information. We might also solve 621 this by including an explicit signal in HRR noting ECH acceptance. 622 We need to decide if inner/outer variance is important for HRR- 623 sensitive parameters, and if so, how to best deal with it without 624 complicated client logic.]] 626 The client might duplicate non-sensitive extensions in both messages. 627 However, implementations need to take care to ensure that sensitive 628 extensions are not offered in the ClientHelloOuter. See Section 10.5 629 for additional guidance. 631 To encrypt EncodedClientHelloInner, the client first computes 632 ClientHelloOuterAAD as described in Section 5.2. Note this requires 633 the "encrypted_client_hello" be computed after all other extensions. 634 In particular, this is possible because the "pre_shared_key" 635 extension is forbidden in ClientHelloOuter. 637 The client then generates the HPKE encryption context and computes 638 the encapsulated key, context, and payload as: 640 pkR = Deserialize(ECHConfig.contents.public_key) 641 enc, context = SetupBaseS(pkR, 642 "tls ech" || 0x00 || ECHConfig) 643 payload = context.Seal(ClientHelloOuterAAD, 644 EncodedClientHelloInner) 646 Note that the HPKE functions Deserialize and SetupBaseS are those 647 which match "ECHConfig.contents.kem_id" and the AEAD/KDF used with 648 "context" are those which match the client's chosen preference from 649 "ECHConfig.contents.cipher_suites". The "info" parameter to 650 SetupBaseS is the concatenation of "tls ech", a zero byte, and the 651 serialized ECHConfig. 653 The value of the "encrypted_client_hello" extension in the 654 ClientHelloOuter is a "ClientECH" with the following values: 656 * "config_id", the identifier corresponding to the chosen ECHConfig 657 structure; 659 * "cipher_suite", the client's chosen cipher suite; 661 * "enc", as computed above; and 663 * "payload", as computed above. 665 If optional configuration identifiers (see Section 10.4)) are used, 666 "config_id" SHOULD be set to a randomly generated byte. Unless 667 specified by the application using (D)TLS or externally configured on 668 both sides, implementations MUST set the field as specified in 669 Section 5. 671 6.1.1. ClientHelloInner Indication Extension 673 If, in a ClientHello, the "encrypted_client_hello" extension is not 674 present and an "ech_is_inner" extension is present, the ClientHello 675 is a ClientHelloInner. This extension MUST only be sent in the 676 ClientHello message. 678 enum { 679 ech_is_inner(0xda09), (65535) 680 } ExtensionType; 682 The "extension_data" field of the "ech_is_inner" extension is zero 683 length. 685 Backend servers (as described in Section 7) MUST support the 686 "ech_is_inner" extension. 688 6.1.2. Recommended Padding Scheme 690 This section describes a deterministic padding mechanism based on the 691 following observation: individual extensions can reveal sensitive 692 information through their length. Thus, each extension in the inner 693 ClientHello may require different amounts of padding. This padding 694 may be fully determined by the client's configuration or may require 695 server input. 697 By way of example, clients typically support a small number of 698 application profiles. For instance, a browser might support HTTP 699 with ALPN values ["http/1.1, "h2"] and WebRTC media with ALPNs 700 ["webrtc", "c-webrtc"]. Clients SHOULD pad this extension by 701 rounding up to the total size of the longest ALPN extension across 702 all application profiles. The target padding length of most 703 ClientHello extensions can be computed in this way. 705 In contrast, clients do not know the longest SNI value in the client- 706 facing server's anonymity set without server input. For the 707 "server_name" extension with length D, clients SHOULD use the 708 server's length hint L (ECHConfig.contents.maximum_name_length) when 709 computing the padding as follows: 711 1. If L >= D, add L - D bytes of padding. This rounds to the 712 server's advertised hint, i.e., 713 ECHConfig.contents.maximum_name_length. 715 2. Otherwise, let P = 31 - ((D - 1) % 32), and add P bytes of 716 padding, plus an additional 32 bytes if D + P < L + 32. This 717 rounds D up to the nearest multiple of 32 bytes that permits at 718 least 32 bytes of length ambiguity. 720 In addition to padding ClientHelloInner, clients and servers will 721 also need to pad all other handshake messages that have sensitive- 722 length fields. For example, if a client proposes ALPN values in 723 ClientHelloInner, the server-selected value will be returned in an 724 EncryptedExtension, so that handshake message also needs to be padded 725 using TLS record layer padding. 727 6.1.3. Handling the Server Response 729 As described in Section 7, the server MAY either accept ECH and use 730 ClientHelloInner or reject it and use ClientHelloOuter. In handling 731 the server's response, the client's first step is to determine which 732 value was used. The client presumes acceptance if the last 8 bytes 733 of ServerHello.random are equal to the first 8 bytes of 734 "accept_confirmation" as defined in Section 7.2. Otherwise, it 735 presumes rejection. 737 6.1.3.1. Accepted ECH 739 If the server used ClientHelloInner, the client proceeds with the 740 connection as usual, authenticating the connection for the true 741 server name. 743 6.1.3.2. Rejected ECH 745 If the server used ClientHelloOuter, the client proceeds with the 746 handshake, authenticating for ECHConfig.contents.public_name as 747 described in Section 6.1.3.3. If authentication or the handshake 748 fails, the client MUST return a failure to the calling application. 749 It MUST NOT use the retry configurations. 751 Otherwise, if both authentication and the handshake complete 752 successfully, the client MUST abort the connection with an 753 "ech_required" alert. It then processes the "retry_configs" field 754 from the server's "encrypted_client_hello" extension. 756 If at least one of the values contains a version supported by the 757 client, it can regard the ECH keys as securely replaced by the 758 server. It SHOULD retry the handshake with a new transport 759 connection, using the retry configurations supplied by the server. 760 The retry configurations may only be applied to the retry connection. 761 The client MUST continue to use the previously-advertised 762 configurations for subsequent connections. This avoids introducing 763 pinning concerns or a tracking vector, should a malicious server 764 present client-specific retry configurations in order to identify the 765 client in a subsequent ECH handshake. 767 If none of the values provided in "retry_configs" contains a 768 supported version, the client can regard ECH as securely disabled by 769 the server. As below, it SHOULD then retry the handshake with a new 770 transport connection and ECH disabled. 772 If the field contains any other value, the client MUST abort the 773 connection with an "illegal_parameter" alert. 775 If the server negotiates an earlier version of TLS, or if it does not 776 provide an "encrypted_client_hello" extension in EncryptedExtensions, 777 the client proceeds with the handshake, authenticating for 778 ECHConfig.contents.public_name as described in Section 6.1.3.3. If 779 an earlier version was negotiated, the client MUST NOT enable the 780 False Start optimization [RFC7918] for this handshake. If 781 authentication or the handshake fails, the client MUST return a 782 failure to the calling application. It MUST NOT treat this as a 783 secure signal to disable ECH. 785 Otherwise, when the handshake completes successfully with the public 786 name authenticated, the client MUST abort the connection with an 787 "ech_required" alert. The client can then regard ECH as securely 788 disabled by the server. It SHOULD retry the handshake with a new 789 transport connection and ECH disabled. 791 Clients SHOULD implement a limit on retries caused by 792 "ech_retry_request" or servers which do not acknowledge the 793 "encrypted_client_hello" extension. If the client does not retry in 794 either scenario, it MUST report an error to the calling application. 796 6.1.3.3. Authenticating for the Public Name 798 When the server rejects ECH or otherwise ignores 799 "encrypted_client_hello" extension, it continues with the handshake 800 using the plaintext "server_name" extension instead (see Section 7). 801 Clients that offer ECH then authenticate the connection with the 802 public name, as follows: 804 * The client MUST verify that the certificate is valid for 805 ECHConfig.contents.public_name. If invalid, it MUST abort the 806 connection with the appropriate alert. 808 * If the server requests a client certificate, the client MUST 809 respond with an empty Certificate message, denoting no client 810 certificate. 812 Note that authenticating a connection for the public name does not 813 authenticate it for the origin. The TLS implementation MUST NOT 814 report such connections as successful to the application. It 815 additionally MUST ignore all session tickets and session IDs 816 presented by the server. These connections are only used to trigger 817 retries, as described in Section 6.1.3. This may be implemented, for 818 instance, by reporting a failed connection with a dedicated error 819 code. 821 6.1.4. Handling HelloRetryRequest 823 As required in Section 6.1, clients offering ECH MUST ensure that all 824 extensions or parameters that might change in response to receiving a 825 HelloRetryRequest have the same values in ClientHelloInner and 826 ClientHelloOuter. That is, if a HelloRetryRequest causes a parameter 827 to be changed, the same change is applied to both ClientHelloInner 828 and ClientHelloOuter. Applicable parameters include: 830 1. TLS 1.3 [RFC8446] ciphersuites in the ClientHello.cipher_suites 831 list. 833 2. The "key_share" and "supported_groups" extensions [RFC8446]. 834 (These extensions may be copied from ClientHelloOuter into 835 ClientHelloInner as described in Section 6.1.) 837 3. Versions in the "supported_versions" extension, excluding TLS 1.2 838 and earlier. Note the ClientHelloOuter MAY include these older 839 versions, while the ClientHelloInner MUST omit them. 841 Future extensions that might change across first and second 842 ClientHello messages in response to a HelloRetryRequest MUST have the 843 same value. 845 If the server sends a HelloRetryRequest in response to the 846 ClientHello, the client sends a second updated ClientHello per the 847 rules in [RFC8446]. However, at this point, the client does not know 848 whether the server processed ClientHelloOuter or ClientHelloInner, 849 and MUST regenerate both values to be acceptable. Note: if 850 ClientHelloOuter and ClientHelloInner use different groups for their 851 key shares or differ in some other way, then the HelloRetryRequest 852 may actually be invalid for one or the other ClientHello, in which 853 case a fresh ClientHello MUST be generated, ignoring the instructions 854 in HelloRetryRequest. Otherwise, the usual rules for 855 HelloRetryRequest processing apply. 857 The client encodes the second ClientHelloInner as in Section 5.1, 858 using the second ClientHelloOuter for any referenced extensions. It 859 then encrypts the new EncodedClientHelloInner value as a second 860 message with the previous HPKE context: 862 payload = context.Seal(ClientHelloOuterAAD, 863 EncodedClientHelloInner) 865 ClientHelloOuterAAD is computed as described in Section 5.2, but 866 again using the second ClientHelloOuter. Note that the HPKE context 867 maintains a sequence number, so this operation internally uses a 868 fresh nonce for each AEAD operation. Reusing the HPKE context avoids 869 an attack described in Section 10.10.2. 871 The client then modifies the "encrypted_client_hello" extension in 872 ClientHelloOuter as follows: 874 * "config_id" is unchanged and contains the "config_id" 875 corresponding to the client's chosen ECHConfig. 877 * "cipher_suite" is unchanged and contains the client's chosen HPKE 878 cipher suite. 880 * "enc" is replaced with the empty string. 882 * "payload" is replaced with the value computed above. 884 If the client offered ECH in the first ClientHello, then it MUST 885 offer ECH in the second. Likewise, if the client did not offer ECH 886 in the first ClientHello, then it MUST NOT not offer ECH in the 887 second. 889 6.2. GREASE ECH 891 If the client attempts to connect to a server and does not have an 892 ECHConfig structure available for the server, it SHOULD send a GREASE 893 [RFC8701] "encrypted_client_hello" extension in the first ClientHello 894 as follows: 896 * Set the "config_id" field to a random byte. 898 * Set the "cipher_suite" field to a supported 899 HpkeSymmetricCipherSuite. The selection SHOULD vary to exercise 900 all supported configurations, but MAY be held constant for 901 successive connections to the same server in the same session. 903 * Set the "enc" field to a randomly-generated valid encapsulated 904 public key output by the HPKE KEM. 906 * Set the "payload" field to a randomly-generated string of L+C 907 bytes, where C is the ciphertext expansion of the selected AEAD 908 scheme and L is the size of the EncodedClientHelloInner the client 909 would compute when offering ECH, padded according to 910 Section 6.1.2. 912 When sending a second ClientHello in response to a HelloRetryRequest, 913 the client copies the entire "encrypted_client_hello" extension from 914 the first ClientHello. 916 [[OPEN ISSUE: The above doesn't match HRR handling for either ECH 917 acceptance or rejection. See issue https://github.com/tlswg/draft- 918 ietf-tls-esni/issues/358.]] 920 If the server sends an "encrypted_client_hello" extension, the client 921 MUST check the extension syntactically and abort the connection with 922 a "decode_error" alert if it is invalid. It otherwise ignores the 923 extension and MUST NOT use the retry keys. 925 [[OPEN ISSUE: if the client sends a GREASE "encrypted_client_hello" 926 extension, should it also send a GREASE "pre_shared_key" extension? 927 If not, GREASE+ticket is a trivial distinguisher.]] 928 Offering a GREASE extension is not considered offering an encrypted 929 ClientHello for purposes of requirements in Section 6. In 930 particular, the client MAY offer to resume sessions established 931 without ECH. 933 7. Server Behavior 935 Servers that support ECH play one of two roles, depending on which of 936 the "ech_is_inner" (Section 6.1.1) and "encrypted_client_hello" 937 (Section 5) extensions are present in the ClientHello: 939 * If both the "ech_is_inner" and "encrypted_client_hello" extensions 940 are present in the ClientHello, the backend server MUST abort with 941 an "illegal_parameter" alert. 943 * If only the "encrypted_client_hello" extension is present, the 944 server acts as a client-facing server and proceeds as described in 945 Section 7.1 to extract a ClientHelloInner, if available. 947 * If only the "ech_is_inner" extension is present and the 948 "encrypted_client_hello" extension is not present, the server acts 949 as a backend server and proceeds as described in Section 7.2. 951 * If neither extension is present, the server completes the 952 handshake normally, as described in [RFC8446]. 954 7.1. Client-Facing Server 956 Upon receiving an "encrypted_client_hello" extension in an initial 957 ClientHello, the client-facing server determines if it will accept 958 ECH, prior to negotiating any other TLS parameters. Note that 959 successfully decrypting the extension will result in a new 960 ClientHello to process, so even the client's TLS version preferences 961 may have changed. 963 If the client offers the "ech_is_inner" extension (Section 6.1.1) in 964 addition to the "encrypted_client_hello" extension, the server MUST 965 abort with an "illegal_parameter" alert. 967 First, the server collects a set of candidate ECHConfig values. This 968 list is determined by one of the two following methods: 970 1. Compare ClientECH.config_id against identifiers of each known 971 ECHConfig and select the ones that match, if any, as candidates. 973 2. Collect all known ECHConfig values as candidates, with trial 974 decryption below determining the final selection. 976 Some uses of ECH, such as local discovery mode, may randomize the 977 ClientECH.config_id since it can be used as a tracking vector. In 978 such cases, the second method should be used for matching ClientECH 979 to known ECHConfig. See Section 10.4. Unless specified by the 980 application using (D)TLS or externally configured on both sides, 981 implementations MUST use the first method. 983 The server then iterates over the candidate ECHConfig values, 984 attempting to decrypt the "encrypted_client_hello" extension: 986 The server verifies that the ECHConfig supports the cipher suite 987 indicated by the ClientECH.cipher_suite and that the version of ECH 988 indicated by the client matches the ECHConfig.version. If not, the 989 server continues to the next candidate ECHConfig. 991 Next, the server decrypts ClientECH.payload, using the private key 992 skR corresponding to ECHConfig, as follows: 994 context = SetupBaseR(ClientECH.enc, skR, 995 "tls ech" || 0x00 || ECHConfig) 996 EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, 997 ClientECH.payload) 999 ClientHelloOuterAAD is computed from ClientHelloOuter as described in 1000 Section 5.2. The "info" parameter to SetupBaseS is the concatenation 1001 "tls ech", a zero byte, and the serialized ECHConfig. If decryption 1002 fails, the server continues to the next candidate ECHConfig. 1003 Otherwise, the server reconstructs ClientHelloInner from 1004 EncodedClientHelloInner, as described in Section 5.1. It then stops 1005 iterating over the candidate ECHConfig values. 1007 Upon determining the ClientHelloInner, the client-facing server then 1008 forwards the ClientHelloInner to the appropriate backend server, 1009 which proceeds as in Section 7.2. If the backend server responds 1010 with a HelloRetryRequest, the client-facing server forwards it, 1011 decrypts the client's second ClientHelloOuter using the procedure in 1012 Section 7.1.1, and forwards the resulting second ClientHelloInner. 1013 The client-facing server forwards all other TLS messages between the 1014 client and backend server unmodified. 1016 Otherwise, if all candidate ECHConfig values fail to decrypt the 1017 extension, the client-facing server MUST ignore the extension and 1018 proceed with the connection using ClientHelloOuter. This connection 1019 proceeds as usual, except the server MUST include the 1020 "encrypted_client_hello" extension in its EncryptedExtensions with 1021 the "retry_configs" field set to one or more ECHConfig structures 1022 with up-to-date keys. Servers MAY supply multiple ECHConfig values 1023 of different versions. This allows a server to support multiple 1024 versions at once. 1026 Note that decryption failure could indicate a GREASE ECH extension 1027 (see Section 6.2), so it is necessary for servers to proceed with the 1028 connection and rely on the client to abort if ECH was required. In 1029 particular, the unrecognized value alone does not indicate a 1030 misconfigured ECH advertisement (Section 8.1). Instead, servers can 1031 measure occurrences of the "ech_required" alert to detect this case. 1033 7.1.1. Handling HelloRetryRequest 1035 After sending or forwarding a HelloRetryRequest, the client-facing 1036 server does not repeat the steps in Section 7.1 with the second 1037 ClientHelloOuter. Instead, it continues with the ECHConfig selection 1038 from the first ClientHelloOuter as follows: 1040 If the client-facing server accepted ECH, it checks the second 1041 ClientHelloOuter also contains the "encrypted_client_hello" 1042 extension. If not, it MUST abort the handshake with a 1043 "missing_extension" alert. Otherwise, it checks that 1044 ClientECH.cipher_suite and ClientECH.config_id are unchanged, and 1045 that ClientECH.enc is empty. If not, it MUST abort the handshake 1046 with an "illegal_parameter" alert. 1048 Finally, it decrypts the new ClientECH.payload as a second message 1049 with the previous HPKE context: 1051 EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, 1052 ClientECH.payload) 1054 ClientHelloOuterAAD is computed as described in Section 5.2, but 1055 using the second ClientHelloOuter. If decryption fails, the client- 1056 facing server MUST abort the handshake with a "decrypt_error" alert. 1057 Otherwise, it reconstructs the second ClientHelloInner from the new 1058 EncodedClientHelloInner as described in Section 5.1, using the second 1059 ClientHelloOuter for any referenced extensions. 1061 The client-facing server then forwards the resulting ClientHelloInner 1062 to the backend server. It forwards all subsequent TLS messages 1063 between the client and backend server unmodified. 1065 If the client-facing server rejected ECH, or if the first ClientHello 1066 did not include an "encrypted_client_hello" extension, the client- 1067 facing server proceeds with the connection as usual. The server does 1068 not decrypt the second ClientHello's ClientECH.payload value, if 1069 there is one. 1071 [[OPEN ISSUE: If the client-facing server implements stateless HRR, 1072 it has no way to send a cookie, short of as-yet-unspecified 1073 integration with the backend server. Stateful HRR on the client- 1074 facing server works fine, however. See issue 1075 https://github.com/tlswg/draft-ietf-tls-esni/issues/333.]] 1077 7.2. Backend Server 1079 Upon receipt of an "ech_is_inner" extension in a ClientHello, if the 1080 backend server negotiates TLS 1.3 or higher, then it MUST confirm ECH 1081 acceptance to the client by computing its ServerHello as described 1082 here. 1084 The backend server begins by generating a message ServerHelloECHConf, 1085 which is identical in content to a ServerHello message with the 1086 exception that ServerHelloECHConf.random is equal to 24 random bytes 1087 followed by 8 zero bytes. It then computes a string 1089 accept_confirmation = 1090 Derive-Secret(Handshake Secret, 1091 "ech accept confirmation", 1092 ClientHelloInner...ServerHelloECHConf) 1094 where Derive-Secret and Handshake Secret are as specified in 1095 [RFC8446], Section 7.1, and ClientHelloInner...ServerHelloECHConf 1096 refers to the sequence of handshake messages beginning with the first 1097 ClientHello and ending with ServerHelloECHConf. Finally, the backend 1098 server constructs its ServerHello message so that it is equal to 1099 ServerHelloECHConf but with the last 8 bytes of ServerHello.random 1100 set to the first 8 bytes of accept_confirmation. 1102 The backend server MUST NOT perform this operation if it negotiated 1103 TLS 1.2 or below. Note that doing so would overwrite the downgrade 1104 signal for TLS 1.3 (see [RFC8446], Section 4.1.3). 1106 The "ech_is_inner" is expected to have an empty payload. If the 1107 payload is non-empty (i.e., the length of the "extension_data" field 1108 is non-zero) then the backend server MUST abort the handshake with an 1109 "illegal_parameter" alert. 1111 8. Compatibility Issues 1113 Unlike most TLS extensions, placing the SNI value in an ECH extension 1114 is not interoperable with existing servers, which expect the value in 1115 the existing plaintext extension. Thus server operators SHOULD 1116 ensure servers understand a given set of ECH keys before advertising 1117 them. Additionally, servers SHOULD retain support for any 1118 previously-advertised keys for the duration of their validity 1120 However, in more complex deployment scenarios, this may be difficult 1121 to fully guarantee. Thus this protocol was designed to be robust in 1122 case of inconsistencies between systems that advertise ECH keys and 1123 servers, at the cost of extra round-trips due to a retry. Two 1124 specific scenarios are detailed below. 1126 8.1. Misconfiguration and Deployment Concerns 1128 It is possible for ECH advertisements and servers to become 1129 inconsistent. This may occur, for instance, from DNS 1130 misconfiguration, caching issues, or an incomplete rollout in a 1131 multi-server deployment. This may also occur if a server loses its 1132 ECH keys, or if a deployment of ECH must be rolled back on the 1133 server. 1135 The retry mechanism repairs inconsistencies, provided the server is 1136 authoritative for the public name. If server and advertised keys 1137 mismatch, the server will respond with ech_retry_requested. If the 1138 server does not understand the "encrypted_client_hello" extension at 1139 all, it will ignore it as required by [RFC8446]; Section 4.1.2. 1140 Provided the server can present a certificate valid for the public 1141 name, the client can safely retry with updated settings, as described 1142 in Section 6.1.3. 1144 Unless ECH is disabled as a result of successfully establishing a 1145 connection to the public name, the client MUST NOT fall back to using 1146 unencrypted ClientHellos, as this allows a network attacker to 1147 disclose the contents of this ClientHello, including the SNI. It MAY 1148 attempt to use another server from the DNS results, if one is 1149 provided. 1151 8.2. Middleboxes 1153 A more serious problem is MITM proxies which do not support this 1154 extension. [RFC8446], Section 9.3 requires that such proxies remove 1155 any extensions they do not understand. The handshake will then 1156 present a certificate based on the public name, without echoing the 1157 "encrypted_client_hello" extension to the client. 1159 Depending on whether the client is configured to accept the proxy's 1160 certificate as authoritative for the public name, this may trigger 1161 the retry logic described in Section 6.1.3 or result in a connection 1162 failure. A proxy which is not authoritative for the public name 1163 cannot forge a signal to disable ECH. 1165 A non-conformant MITM proxy which instead forwards the ECH extension, 1166 substituting its own KeyShare value, will result in the client-facing 1167 server recognizing the key, but failing to decrypt the SNI. This 1168 causes a hard failure. Clients SHOULD NOT attempt to repair the 1169 connection in this case. 1171 9. Compliance Requirements 1173 In the absence of an application profile standard specifying 1174 otherwise, a compliant ECH application MUST implement the following 1175 HPKE cipher suite: 1177 * KEM: DHKEM(X25519, HKDF-SHA256) (see [I-D.irtf-cfrg-hpke], 1178 Section 7.1) 1180 * KDF: HKDF-SHA256 (see [I-D.irtf-cfrg-hpke], Section 7.2) 1182 * AEAD: AES-128-GCM (see [I-D.irtf-cfrg-hpke], Section 7.3) 1184 10. Security Considerations 1186 10.1. Security and Privacy Goals 1188 ECH considers two types of attackers: passive and active. Passive 1189 attackers can read packets from the network. They cannot perform any 1190 sort of active behavior such as probing servers or querying DNS. A 1191 middlebox that filters based on plaintext packet contents is one 1192 example of a passive attacker. In contrast, active attackers can 1193 write packets into the network for malicious purposes, such as 1194 interfering with existing connections, probing servers, and querying 1195 DNS. In short, an active attacker corresponds to the conventional 1196 threat model for TLS 1.3 [RFC8446]. 1198 Given these types of attackers, the primary goals of ECH are as 1199 follows. 1201 1. Use of ECH does not weaken the security properties of TLS without 1202 ECH. 1204 2. TLS connection establishment to a host with a specific ECHConfig 1205 and TLS configuration is indistinguishable from a connection to 1206 any other host with the same ECHConfig and TLS configuration. 1207 (The set of hosts which share the same ECHConfig and TLS 1208 configuration is referred to as the anonymity set.) 1210 Client-facing server configuration determines the size of the 1211 anonymity set. For example, if a client-facing server uses distinct 1212 ECHConfig values for each host, then each anonymity set has size k = 1213 1. Client-facing servers SHOULD deploy ECH in such a way so as to 1214 maximize the size of the anonymity set where possible. This means 1215 client-facing servers should use the same ECHConfig for as many hosts 1216 as possible. An attacker can distinguish two hosts that have 1217 different ECHConfig values based on the ClientECH.config_id value. 1218 This also means public information in a TLS handshake is also 1219 consistent across hosts. For example, if a client-facing server 1220 services many backend origin hosts, only one of which supports some 1221 cipher suite, it may be possible to identify that host based on the 1222 contents of unencrypted handshake messages. 1224 Beyond these primary security and privacy goals, ECH also aims to 1225 hide, to some extent, (a) whether or not a specific server supports 1226 ECH and (b) whether or not ECH was accepted for a particular 1227 connection. ECH aims to achieve both properties, assuming the 1228 attacker is passive and does not know the set of ECH configurations 1229 offered by the client-facing server. It does not achieve these 1230 properties for active attackers. More specifically: 1232 * Passive attackers with a known ECH configuration can distinguish 1233 between a connection that negotiates ECH with that configuration 1234 and one which does not, because the latter used a GREASE 1235 "encrypted_client_hello" extension (as specified in Section 6.2) 1236 or a different ECH configuration. 1238 * Passive attackers without the ECH configuration cannot distinguish 1239 between a connection that negotiates ECH and one which uses a 1240 GREASE "encrypted_client_hello" extension. 1242 * Active attackers can distinguish between a connection that 1243 negotiates ECH and one which uses a GREASE 1244 "encrypted_client_hello" extension. 1246 See Section 10.8.4 for more discussion about the "do not stick out" 1247 criteria from [RFC8744]. 1249 10.2. Unauthenticated and Plaintext DNS 1251 In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource 1252 Records are signed via a server private key, ECH records have no 1253 authenticity or provenance information. This means that any attacker 1254 which can inject DNS responses or poison DNS caches, which is a 1255 common scenario in client access networks, can supply clients with 1256 fake ECH records (so that the client encrypts data to them) or strip 1257 the ECH record from the response. However, in the face of an 1258 attacker that controls DNS, no encryption scheme can work because the 1259 attacker can replace the IP address, thus blocking client 1260 connections, or substituting a unique IP address which is 1:1 with 1261 the DNS name that was looked up (modulo DNS wildcards). Thus, 1262 allowing the ECH records in the clear does not make the situation 1263 significantly worse. 1265 Clearly, DNSSEC (if the client validates and hard fails) is a defense 1266 against this form of attack, but DoH/DPRIVE are also defenses against 1267 DNS attacks by attackers on the local network, which is a common case 1268 where ClientHello and SNI encryption are desired. Moreover, as noted 1269 in the introduction, SNI encryption is less useful without encryption 1270 of DNS queries in transit via DoH or DPRIVE mechanisms. 1272 10.3. Client Tracking 1274 A malicious client-facing server could distribute unique, per-client 1275 ECHConfig structures as a way of tracking clients across subsequent 1276 connections. On-path adversaries which know about these unique keys 1277 could also track clients in this way by observing TLS connection 1278 attempts. 1280 The cost of this type of attack scales linearly with the desired 1281 number of target clients. Moreover, DNS caching behavior makes 1282 targeting individual users for extended periods of time, e.g., using 1283 per-client ECHConfig structures delivered via HTTPS RRs with high 1284 TTLs, challenging. Clients can help mitigate this problem by 1285 flushing any DNS or ECHConfig state upon changing networks. 1287 10.4. Optional Configuration Identifiers and Trial Decryption 1289 Optional configuration identifiers may be useful in scenarios where 1290 clients and client-facing servers do not want to reveal information 1291 about the client-facing server in the "encrypted_client_hello" 1292 extension. In such settings, clients send a randomly generated 1293 config_id in the ClientECH. Servers in these settings must perform 1294 trial decryption since they cannot identify the client's chosen ECH 1295 key using the config_id value. As a result, support for optional 1296 configuration identifiers may exacerbate DoS attacks. Specifically, 1297 an adversary may send malicious ClientHello messages, i.e., those 1298 which will not decrypt with any known ECH key, in order to force 1299 wasteful decryption. Servers that support this feature should, for 1300 example, implement some form of rate limiting mechanism to limit the 1301 damage caused by such attacks. 1303 10.5. Outer ClientHello 1305 Any information that the client includes in the ClientHelloOuter is 1306 visible to passive observers. The client SHOULD NOT send values in 1307 the ClientHelloOuter which would reveal a sensitive ClientHelloInner 1308 property, such as the true server name. It MAY send values 1309 associated with the public name in the ClientHelloOuter. 1311 In particular, some extensions require the client send a server-name- 1312 specific value in the ClientHello. These values may reveal 1313 information about the true server name. For example, the 1314 "cached_info" ClientHello extension [RFC7924] can contain the hash of 1315 a previously observed server certificate. The client SHOULD NOT send 1316 values associated with the true server name in the ClientHelloOuter. 1317 It MAY send such values in the ClientHelloInner. 1319 A client may also use different preferences in different contexts. 1320 For example, it may send a different ALPN lists to different servers 1321 or in different application contexts. A client that treats this 1322 context as sensitive SHOULD NOT send context-specific values in 1323 ClientHelloOuter. 1325 Values which are independent of the true server name, or other 1326 information the client wishes to protect, MAY be included in 1327 ClientHelloOuter. If they match the corresponding ClientHelloInner, 1328 they MAY be compressed as described in Section 5.1. However, note 1329 the payload length reveals information about which extensions are 1330 compressed, so inner extensions which only sometimes match the 1331 corresponding outer extension SHOULD NOT be compressed. 1333 Clients MAY include additional extensions in ClientHelloOuter to 1334 avoid signaling unusual behavior to passive observers, provided the 1335 choice of value and value itself are not sensitive. See 1336 Section 10.8.4. 1338 10.6. Related Privacy Leaks 1340 ECH requires encrypted DNS to be an effective privacy protection 1341 mechanism. However, verifying the server's identity from the 1342 Certificate message, particularly when using the X509 1343 CertificateType, may result in additional network traffic that may 1344 reveal the server identity. Examples of this traffic may include 1345 requests for revocation information, such as OCSP or CRL traffic, or 1346 requests for repository information, such as 1347 authorityInformationAccess. It may also include implementation- 1348 specific traffic for additional information sources as part of 1349 verification. 1351 Implementations SHOULD avoid leaking information that may identify 1352 the server. Even when sent over an encrypted transport, such 1353 requests may result in indirect exposure of the server's identity, 1354 such as indicating a specific CA or service being used. To mitigate 1355 this risk, servers SHOULD deliver such information in-band when 1356 possible, such as through the use of OCSP stapling, and clients 1357 SHOULD take steps to minimize or protect such requests during 1358 certificate validation. 1360 Attacks that rely on non-ECH traffic to infer server identity in an 1361 ECH connection are out of scope for this document. For example, a 1362 client that connects to a particular host prior to ECH deployment may 1363 later resume a connection to that same host after ECH deployment. An 1364 adversary that observes this can deduce that the ECH-enabled 1365 connection was made to a host that the client previously connected to 1366 and which is within the same anonymity set. 1368 10.7. Attacks Exploiting Acceptance Confirmation 1370 To signal acceptance, the backend server overwrites 8 bytes of its 1371 ServerHello.random with a value derived from the 1372 ClientHelloInner.random. (See Section 7.2 for details.) This 1373 behavior increases the likelihood of the ServerHello.random colliding 1374 with the ServerHello.random of a previous session, potentially 1375 reducing the overall security of the protocol. However, the 1376 remaining 24 bytes provide enough entropy to ensure this is not a 1377 practical avenue of attack. 1379 On the other hand, the probability that two 8-byte strings are the 1380 same is non-negligible. This poses a modest operational risk. 1381 Suppose the client-facing server terminates the connection (i.e., ECH 1382 is rejected or bypassed): if the last 8 bytes of its 1383 ServerHello.random coincide with the confirmation signal, then the 1384 client will incorrectly presume acceptance and proceed as if the 1385 backend server terminated the connection. However, the probability 1386 of a false positive occurring for a given connection is only 1 in 1387 2^64. This value is smaller than the probability of network 1388 connection failures in practice. 1390 Note that the same bytes of the ServerHello.random are used to 1391 implement downgrade protection for TLS 1.3 (see [RFC8446], 1392 Section 4.1.3). These mechanisms do not interfere because the 1393 backend server only signals ECH acceptance in TLS 1.3 or higher. 1395 10.8. Comparison Against Criteria 1397 [RFC8744] lists several requirements for SNI encryption. In this 1398 section, we re-iterate these requirements and assess the ECH design 1399 against them. 1401 10.8.1. Mitigate Cut-and-Paste Attacks 1403 Since servers process either ClientHelloInner or ClientHelloOuter, 1404 and because ClientHelloInner.random is encrypted, it is not possible 1405 for an attacker to "cut and paste" the ECH value in a different 1406 Client Hello and learn information from ClientHelloInner. 1408 10.8.2. Avoid Widely Shared Secrets 1410 This design depends upon DNS as a vehicle for semi-static public key 1411 distribution. Server operators may partition their private keys 1412 however they see fit provided each server behind an IP address has 1413 the corresponding private key to decrypt a key. Thus, when one ECH 1414 key is provided, sharing is optimally bound by the number of hosts 1415 that share an IP address. Server operators may further limit sharing 1416 by publishing different DNS records containing ECHConfig values with 1417 different keys using a short TTL. 1419 10.8.3. Prevent SNI-Based Denial-of-Service Attacks 1421 This design requires servers to decrypt ClientHello messages with 1422 ClientECH extensions carrying valid digests. Thus, it is possible 1423 for an attacker to force decryption operations on the server. This 1424 attack is bound by the number of valid TCP connections an attacker 1425 can open. 1427 10.8.4. Do Not Stick Out 1429 The only explicit signal indicating possible use of ECH is the 1430 ClientHello "encrypted_client_hello" extension. Server handshake 1431 messages do not contain any signal indicating use or negotiation of 1432 ECH. Clients MAY GREASE the "encrypted_client_hello" extension, as 1433 described in Section 6.2, which helps ensure the ecosystem handles 1434 ECH correctly. Moreover, as more clients enable ECH support, e.g., 1435 as normal part of Web browser functionality, with keys supplied by 1436 shared hosting providers, the presence of ECH extensions becomes less 1437 unusual and part of typical client behavior. In other words, if all 1438 Web browsers start using ECH, the presence of this value will not 1439 signal unusual behavior to passive eavesdroppers. 1441 10.8.5. Maintain Forward Secrecy 1443 This design is not forward secret because the server's ECH key is 1444 static. However, the window of exposure is bound by the key 1445 lifetime. It is RECOMMENDED that servers rotate keys frequently. 1447 10.8.6. Enable Multi-party Security Contexts 1449 This design permits servers operating in Split Mode to forward 1450 connections directly to backend origin servers. The client 1451 authenticates the identity of the backend origin server, thereby 1452 avoiding unnecessary MiTM attacks. 1454 Conversely, assuming ECH records retrieved from DNS are 1455 authenticated, e.g., via DNSSEC or fetched from a trusted Recursive 1456 Resolver, spoofing a client-facing server operating in Split Mode is 1457 not possible. See Section 10.2 for more details regarding plaintext 1458 DNS. 1460 Authenticating the ECHConfig structure naturally authenticates the 1461 included public name. This also authenticates any retry signals from 1462 the client-facing server because the client validates the server 1463 certificate against the public name before retrying. 1465 10.8.7. Support Multiple Protocols 1467 This design has no impact on application layer protocol negotiation. 1468 It may affect connection routing, server certificate selection, and 1469 client certificate verification. Thus, it is compatible with 1470 multiple application and transport protocols. By encrypting the 1471 entire ClientHello, this design additionally supports encrypting the 1472 ALPN extension. 1474 10.9. Padding Policy 1476 Variations in the length of the ClientHelloInner ciphertext could 1477 leak information about the corresponding plaintext. Section 6.1.2 1478 describes a RECOMMENDED padding mechanism for clients aimed at 1479 reducing potential information leakage. 1481 10.10. Active Attack Mitigations 1483 This section describes the rationale for ECH properties and mechanics 1484 as defenses against active attacks. In all the attacks below, the 1485 attacker is on-path between the target client and server. The goal 1486 of the attacker is to learn private information about the inner 1487 ClientHello, such as the true SNI value. 1489 10.10.1. Client Reaction Attack Mitigation 1491 This attack uses the client's reaction to an incorrect certificate as 1492 an oracle. The attacker intercepts a legitimate ClientHello and 1493 replies with a ServerHello, Certificate, CertificateVerify, and 1494 Finished messages, wherein the Certificate message contains a "test" 1495 certificate for the domain name it wishes to query. If the client 1496 decrypted the Certificate and failed verification (or leaked 1497 information about its verification process by a timing side channel), 1498 the attacker learns that its test certificate name was incorrect. As 1499 an example, suppose the client's SNI value in its inner ClientHello 1500 is "example.com," and the attacker replied with a Certificate for 1501 "test.com". If the client produces a verification failure alert 1502 because of the mismatch faster than it would due to the Certificate 1503 signature validation, information about the name leaks. Note that 1504 the attacker can also withhold the CertificateVerify message. In 1505 that scenario, a client which first verifies the Certificate would 1506 then respond similarly and leak the same information. 1508 Client Attacker Server 1509 ClientHello 1510 + key_share 1511 + ech ------> (intercept) -----> X (drop) 1513 ServerHello 1514 + key_share 1515 {EncryptedExtensions} 1516 {CertificateRequest*} 1517 {Certificate*} 1518 {CertificateVerify*} 1519 <------ 1520 Alert 1521 ------> 1522 Figure 3: Client reaction attack 1524 ClientHelloInner.random prevents this attack. In particular, since 1525 the attacker does not have access to this value, it cannot produce 1526 the right transcript and handshake keys needed for encrypting the 1527 Certificate message. Thus, the client will fail to decrypt the 1528 Certificate and abort the connection. 1530 10.10.2. HelloRetryRequest Hijack Mitigation 1532 This attack aims to exploit server HRR state management to recover 1533 information about a legitimate ClientHello using its own attacker- 1534 controlled ClientHello. To begin, the attacker intercepts and 1535 forwards a legitimate ClientHello with an "encrypted_client_hello" 1536 (ech) extension to the server, which triggers a legitimate 1537 HelloRetryRequest in return. Rather than forward the retry to the 1538 client, the attacker, attempts to generate its own ClientHello in 1539 response based on the contents of the first ClientHello and 1540 HelloRetryRequest exchange with the result that the server encrypts 1541 the Certificate to the attacker. If the server used the SNI from the 1542 first ClientHello and the key share from the second (attacker- 1543 controlled) ClientHello, the Certificate produced would leak the 1544 client's chosen SNI to the attacker. 1546 Client Attacker Server 1547 ClientHello 1548 + key_share 1549 + ech ------> (forward) -------> 1550 HelloRetryRequest 1551 + key_share 1552 (intercept) <------- 1554 ClientHello 1555 + key_share' 1556 + ech' -------> 1557 ServerHello 1558 + key_share 1559 {EncryptedExtensions} 1560 {CertificateRequest*} 1561 {Certificate*} 1562 {CertificateVerify*} 1563 {Finished} 1564 <------- 1565 (process server flight) 1567 Figure 4: HelloRetryRequest hijack attack 1569 This attack is mitigated by using the same HPKE context for both 1570 ClientHello messages. The attacker does not possess the context's 1571 keys, so it cannot generate a valid encryption of the second inner 1572 ClientHello. 1574 If the attacker could manipulate the second ClientHello, it might be 1575 possible for the server to act as an oracle if it required parameters 1576 from the first ClientHello to match that of the second ClientHello. 1577 For example, imagine the client's original SNI value in the inner 1578 ClientHello is "example.com", and the attacker's hijacked SNI value 1579 in its inner ClientHello is "test.com". A server which checks these 1580 for equality and changes behavior based on the result can be used as 1581 an oracle to learn the client's SNI. 1583 10.10.3. ClientHello Malleability Mitigation 1585 This attack aims to leak information about secret parts of the 1586 encrypted ClientHello by adding attacker-controlled parameters and 1587 observing the server's response. In particular, the compression 1588 mechanism described in Section 5.1 references parts of a potentially 1589 attacker-controlled ClientHelloOuter to construct ClientHelloInner, 1590 or a buggy server may incorrectly apply parameters from 1591 ClientHelloOuter to the handshake. 1593 To begin, the attacker first interacts with a server to obtain a 1594 resumption ticket for a given test domain, such as "example.com". 1595 Later, upon receipt of a ClientHelloOuter, it modifies it such that 1596 the server will process the resumption ticket with ClientHelloInner. 1597 If the server only accepts resumption PSKs that match the server 1598 name, it will fail the PSK binder check with an alert when 1599 ClientHelloInner is for "example.com" but silently ignore the PSK and 1600 continue when ClientHelloInner is for any other name. This 1601 introduces an oracle for testing encrypted SNI values. 1603 Client Attacker Server 1605 handshake and ticket 1606 for "example.com" 1607 <--------> 1609 ClientHello 1610 + key_share 1611 + ech 1612 + ech_outer_extensions(pre_shared_key) 1613 + pre_shared_key 1614 --------> 1615 (intercept) 1616 ClientHello 1617 + key_share 1618 + ech 1619 + ech_outer_extensions(pre_shared_key) 1620 + pre_shared_key' 1621 --------> 1622 Alert 1623 -or- 1624 ServerHello 1625 ... 1626 Finished 1627 <-------- 1629 Figure 5: Message flow for malleable ClientHello 1631 This attack may be generalized to any parameter which the server 1632 varies by server name, such as ALPN preferences. 1634 ECH mitigates this attack by only negotiating TLS parameters from 1635 ClientHelloInner and authenticating all inputs to the 1636 ClientHelloInner (EncodedClientHelloInner and ClientHelloOuter) with 1637 the HPKE AEAD. See Section 5.2. An earlier iteration of this 1638 specification only encrypted and authenticated the "server_name" 1639 extension, which left the overall ClientHello vulnerable to an 1640 analogue of this attack. 1642 11. IANA Considerations 1644 11.1. Update of the TLS ExtensionType Registry 1646 IANA is requested to create the following three entries in the 1647 existing registry for ExtensionType (defined in [RFC8446]): 1649 1. encrypted_client_hello(0xfe0a), with "TLS 1.3" column values set 1650 to "CH, EE", and "Recommended" column set to "Yes". 1652 2. ech_is_inner (0xda09), with "TLS 1.3" column values set to "CH", 1653 and "Recommended" column set to "Yes". 1655 3. ech_outer_extensions(0xfd00), with the "TLS 1.3" column values 1656 set to "", and "Recommended" column set to "Yes". 1658 11.2. Update of the TLS Alert Registry 1660 IANA is requested to create an entry, ech_required(121) in the 1661 existing registry for Alerts (defined in [RFC8446]), with the "DTLS- 1662 OK" column set to "Y". 1664 12. ECHConfig Extension Guidance 1666 Any future information or hints that influence ClientHelloOuter 1667 SHOULD be specified as ECHConfig extensions. This is primarily 1668 because the outer ClientHello exists only in support of ECH. Namely, 1669 it is both an envelope for the encrypted inner ClientHello and 1670 enabler for authenticated key mismatch signals (see Section 7). In 1671 contrast, the inner ClientHello is the true ClientHello used upon ECH 1672 negotiation. 1674 13. References 1676 13.1. Normative References 1678 [HTTPS-RR] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 1679 and parameter specification via the DNS (DNS SVCB and 1680 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 1681 dnsop-svcb-https-02, 2 November 2020, 1682 . 1685 [I-D.ietf-tls-exported-authenticator] 1686 Sullivan, N., "Exported Authenticators in TLS", Work in 1687 Progress, Internet-Draft, draft-ietf-tls-exported- 1688 authenticator-14, 25 January 2021, . 1692 [I-D.irtf-cfrg-hpke] 1693 Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid 1694 Public Key Encryption", Work in Progress, Internet-Draft, 1695 draft-irtf-cfrg-hpke-07, 16 December 2020, 1696 . 1699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1700 Requirement Levels", BCP 14, RFC 2119, 1701 DOI 10.17487/RFC2119, March 1997, 1702 . 1704 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 1705 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 1706 October 2015, . 1708 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 1709 Layer Security (TLS) False Start", RFC 7918, 1710 DOI 10.17487/RFC7918, August 2016, 1711 . 1713 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1714 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1715 May 2017, . 1717 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1718 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1719 . 1721 13.2. Informative References 1723 [I-D.kazuho-protected-sni] 1724 Oku, K., "TLS Extensions for Protecting SNI", Work in 1725 Progress, Internet-Draft, draft-kazuho-protected-sni-00, 1726 18 July 2017, . 1729 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1730 "Transport Layer Security (TLS) Application-Layer Protocol 1731 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1732 July 2014, . 1734 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1735 and P. Hoffman, "Specification for DNS over Transport 1736 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1737 2016, . 1739 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1740 (TLS) Cached Information Extension", RFC 7924, 1741 DOI 10.17487/RFC7924, July 2016, 1742 . 1744 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1745 Transport Layer Security (DTLS)", RFC 8094, 1746 DOI 10.17487/RFC8094, February 2017, 1747 . 1749 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1750 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1751 . 1753 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 1754 Sustain Extensibility (GREASE) to TLS Extensibility", 1755 RFC 8701, DOI 10.17487/RFC8701, January 2020, 1756 . 1758 [RFC8744] Huitema, C., "Issues and Requirements for Server Name 1759 Identification (SNI) Encryption in TLS", RFC 8744, 1760 DOI 10.17487/RFC8744, July 2020, 1761 . 1763 Appendix A. Alternative SNI Protection Designs 1765 Alternative approaches to encrypted SNI may be implemented at the TLS 1766 or application layer. In this section we describe several 1767 alternatives and discuss drawbacks in comparison to the design in 1768 this document. 1770 A.1. TLS-layer 1772 A.1.1. TLS in Early Data 1774 In this variant, TLS Client Hellos are tunneled within early data 1775 payloads belonging to outer TLS connections established with the 1776 client-facing server. This requires clients to have established a 1777 previous session --- and obtained PSKs --- with the server. The 1778 client-facing server decrypts early data payloads to uncover Client 1779 Hellos destined for the backend server, and forwards them onwards as 1780 necessary. Afterwards, all records to and from backend servers are 1781 forwarded by the client-facing server - unmodified. This avoids 1782 double encryption of TLS records. 1784 Problems with this approach are: (1) servers may not always be able 1785 to distinguish inner Client Hellos from legitimate application data, 1786 (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may 1787 not be supported - especially under DoS - leading to availability 1788 concerns, and (4) clients must bootstrap tunnels (sessions), costing 1789 an additional round trip and potentially revealing the SNI during the 1790 initial connection. In contrast, encrypted SNI protects the SNI in a 1791 distinct Client Hello extension and neither abuses early data nor 1792 requires a bootstrapping connection. 1794 A.1.2. Combined Tickets 1796 In this variant, client-facing and backend servers coordinate to 1797 produce "combined tickets" that are consumable by both. Clients 1798 offer combined tickets to client-facing servers. The latter parse 1799 them to determine the correct backend server to which the Client 1800 Hello should be forwarded. This approach is problematic due to non- 1801 trivial coordination between client-facing and backend servers for 1802 ticket construction and consumption. Moreover, it requires a 1803 bootstrapping step similar to that of the previous variant. In 1804 contrast, encrypted SNI requires no such coordination. 1806 A.2. Application-layer 1808 A.2.1. HTTP/2 CERTIFICATE Frames 1810 In this variant, clients request secondary certificates with 1811 CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. 1812 In response, servers supply certificates via TLS exported 1813 authenticators [I-D.ietf-tls-exported-authenticator] in CERTIFICATE 1814 frames. Clients use a generic SNI for the underlying client-facing 1815 server TLS connection. Problems with this approach include: (1) one 1816 additional round trip before peer authentication, (2) non-trivial 1817 application-layer dependencies and interaction, and (3) obtaining the 1818 generic SNI to bootstrap the connection. In contrast, encrypted SNI 1819 induces no additional round trip and operates below the application 1820 layer. 1822 Appendix B. Acknowledgements 1824 This document draws extensively from ideas in 1825 [I-D.kazuho-protected-sni], but is a much more limited mechanism 1826 because it depends on the DNS for the protection of the ECH key. 1827 Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, 1828 Nick Sullivan, Martin Thomson, and David Benjamin also provided 1829 important ideas and contributions. 1831 Appendix C. Change Log 1833 *RFC Editor's Note:* Please remove this section prior to 1834 publication of a final version of this document. 1836 Issue and pull request numbers are listed with a leading octothorp. 1838 C.1. Since draft-ietf-tls-esni-09 1840 * Finalize HPKE dependency (#390) 1842 * Move from client-computed to server-chosen, one-byte config 1843 identifier (#376, #381) 1845 * Rename ECHConfigs to ECHConfigList (#391) 1847 * Clarify some security and privacy properties (#385, #383) 1849 Authors' Addresses 1851 Eric Rescorla 1852 RTFM, Inc. 1854 Email: ekr@rtfm.com 1856 Kazuho Oku 1857 Fastly 1859 Email: kazuhooku@gmail.com 1861 Nick Sullivan 1862 Cloudflare 1864 Email: nick@cloudflare.com 1866 Christopher A. Wood 1867 Cloudflare 1869 Email: caw@heapingbits.net