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