idnits 2.17.1 draft-ietf-tls-esni-07.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (1 June 2020) is 1396 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '16' on line 399 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-12 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Experimental K. Oku 5 Expires: 3 December 2020 Fastly 6 N. Sullivan 7 C.A. Wood 8 Cloudflare 9 1 June 2020 11 TLS Encrypted Client Hello 12 draft-ietf-tls-esni-07 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 3 December 2020. 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) . . . . . . . . . . . . . . . 5 57 4. Encrypted ClientHello Configuration . . . . . . . . . . . . . 6 58 5. The "encrypted_client_hello" extension . . . . . . . . . . . 7 59 6. The "ech_nonce" extension . . . . . . . . . . . . . . . . . . 9 60 6.1. Incorporating Outer Extensions . . . . . . . . . . . . . 9 61 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 62 7.1. Sending an encrypted ClientHello . . . . . . . . . . . . 10 63 7.2. Recommended Padding Scheme . . . . . . . . . . . . . . . 12 64 7.3. Handling the server response . . . . . . . . . . . . . . 12 65 7.3.1. Accepted ECH . . . . . . . . . . . . . . . . . . . . 13 66 7.3.2. Rejected ECH . . . . . . . . . . . . . . . . . . . . 13 67 7.3.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . 14 68 7.4. GREASE extensions . . . . . . . . . . . . . . . . . . . . 15 69 8. Client-Facing Server Behavior . . . . . . . . . . . . . . . . 16 70 9. Compatibility Issues . . . . . . . . . . . . . . . . . . . . 18 71 9.1. Misconfiguration and Deployment Concerns . . . . . . . . 18 72 9.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 19 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 10.1. Why is cleartext DNS OK? . . . . . . . . . . . . . . . . 19 75 10.2. Client Tracking . . . . . . . . . . . . . . . . . . . . 20 76 10.3. Optional Record Digests and Trial Decryption . . . . . . 20 77 10.4. Related Privacy Leaks . . . . . . . . . . . . . . . . . 20 78 10.5. Comparison Against Criteria . . . . . . . . . . . . . . 21 79 10.5.1. Mitigate against replay attacks . . . . . . . . . . 21 80 10.5.2. Avoid widely-deployed shared secrets . . . . . . . . 21 81 10.5.3. Prevent SNI-based DoS attacks . . . . . . . . . . . 21 82 10.5.4. Do not stick out . . . . . . . . . . . . . . . . . . 21 83 10.5.5. Forward secrecy . . . . . . . . . . . . . . . . . . 22 84 10.5.6. Proper security context . . . . . . . . . . . . . . 22 85 10.5.7. Split server spoofing . . . . . . . . . . . . . . . 22 86 10.5.8. Supporting multiple protocols . . . . . . . . . . . 22 87 10.6. Padding Policy . . . . . . . . . . . . . . . . . . . . . 22 88 10.7. Active Attack Mitigations . . . . . . . . . . . . . . . 22 89 10.7.1. Client Reaction Attack Mitigation . . . . . . . . . 23 90 10.7.2. HelloRetryRequest Hijack Mitigation . . . . . . . . 24 91 10.7.3. Resumption PSK Oracle Mitigation . . . . . . . . . . 25 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 93 11.1. Update of the TLS ExtensionType Registry . . . . . . . . 26 94 11.2. Update of the TLS Alert Registry . . . . . . . . . . . . 26 95 12. ECHConfig Extension Guidance . . . . . . . . . . . . . . . . 26 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 98 13.2. Informative References . . . . . . . . . . . . . . . . . 27 99 Appendix A. Alternative SNI Protection Designs . . . . . . . . . 28 100 A.1. TLS-layer . . . . . . . . . . . . . . . . . . . . . . . . 28 101 A.1.1. TLS in Early Data . . . . . . . . . . . . . . . . . . 28 102 A.1.2. Combined Tickets . . . . . . . . . . . . . . . . . . 29 103 A.2. Application-layer . . . . . . . . . . . . . . . . . . . . 29 104 A.2.1. HTTP/2 CERTIFICATE Frames . . . . . . . . . . . . . . 29 105 Appendix B. Total Client Hello Encryption . . . . . . . . . . . 29 106 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 30 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 109 1. Introduction 111 DISCLAIMER: This is very early a work-in-progress design and has not 112 yet seen significant (or really any) security analysis. It should 113 not be used as a basis for building production systems. 115 Although TLS 1.3 [RFC8446] encrypts most of the handshake, including 116 the server certificate, there are several ways in which an on-path 117 attacker can learn private information about the connection. The 118 cleartext Server Name Indication (SNI) extension in ClientHello 119 messages, which leaks the target domain for a given connection, is 120 perhaps the most sensitive information unencrypted in TLS 1.3. 122 The target domain may also be visible through other channels, such as 123 cleartext client DNS queries, visible server IP addresses (assuming 124 the server does not use domain-based virtual hosting), or other 125 indirect mechanisms such as traffic analysis. DoH 126 [I-D.ietf-doh-dns-over-https] and DPRIVE [RFC7858] [RFC8094] provide 127 mechanisms for clients to conceal DNS lookups from network 128 inspection, and many TLS servers host multiple domains on the same IP 129 address. In such environments, the SNI remains the primary explicit 130 signal used to determine the server's identity. 132 The TLS WG has extensively studied the problem of protecting the SNI, 133 but has been unable to develop a completely generic solution. 134 [I-D.ietf-tls-sni-encryption] provides a description of the problem 135 space and some of the proposed techniques. One of the more difficult 136 problems is "Do not stick out" ([I-D.ietf-tls-sni-encryption], 137 Section 3.4): if only sensitive or private services use SNI 138 encryption, then SNI encryption is a signal that a client is going to 139 such a service. For this reason, much recent work has focused on 140 concealing the fact that the SNI is being protected. Unfortunately, 141 the result often has undesirable performance consequences, incomplete 142 coverage, or both. 144 The design in this document takes a different approach: it assumes 145 that private origins will co-locate with or hide behind a provider 146 (CDN, application server, etc.) which can protect SNIs for all of the 147 domains it hosts. As a result, SNI protection does not indicate that 148 the client is attempting to reach a private origin, but only that it 149 is going to a particular service provider, which the observer could 150 already tell from the visible IP address. 152 The design in this document introduces a new extension, called 153 Encrypted Client Hello (ECH), which allows clients to encrypt the 154 entirety of their ClientHello to a supporting server. This protects 155 the SNI and other potentially sensitive fields, such as the ALPN 156 list. This extension is only supported with (D)TLS 1.3 [RFC8446] and 157 newer versions of the protocol. 159 2. Conventions and Definitions 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. All TLS notation comes from [RFC8446], 166 Section 3. 168 3. Overview 170 This document is designed to operate in one of two primary topologies 171 shown below, which we call "Shared Mode" and "Split Mode" 173 3.1. Topologies 175 +---------------------+ 176 | | 177 | 2001:DB8::1111 | 178 | | 179 Client <-----> | private.example.org | 180 | | 181 | public.example.com | 182 | | 183 +---------------------+ 184 Server 186 Figure 1: Shared Mode Topology 188 In Shared Mode, the provider is the origin server for all the domains 189 whose DNS records point to it and clients form a TLS connection 190 directly to that provider, which has access to the plaintext of the 191 connection. 193 +--------------------+ +---------------------+ 194 | | | | 195 | 2001:DB8::1111 | | 2001:DB8::EEEE | 196 Client <------------------------------------>| | 197 | public.example.com | | private.example.com | 198 | | | | 199 +--------------------+ +---------------------+ 200 Client-Facing Server Backend Server 202 Figure 2: Split Mode Topology 204 In Split Mode, the provider is _not_ the origin server for private 205 domains. Rather the DNS records for private domains point to the 206 provider, and the provider's server relays the connection back to the 207 backend server, which is the true origin server. The provider does 208 not have access to the plaintext of the connection. 210 3.2. Encrypted ClientHello (ECH) 212 ECH works by encrypting the entire ClientHello, including the SNI and 213 any additional extensions such as ALPN. This requires that each 214 provider publish a public key and metadata which is used for 215 ClientHello encryption for all the domains for which it serves 216 directly or indirectly (via Split Mode). This document defines the 217 format of the SNI encryption public key and metadata, referred to as 218 an ECH configuration, and delegates DNS publication details to 219 [HTTPSSVC], though other delivery mechanisms are possible. In 220 particular, if some of the clients of a private server are 221 applications rather than Web browsers, those applications might have 222 the public key and metadata preconfigured. 224 When a client wants to form a TLS connection to any of the domains 225 served by an ECH-supporting provider, it constructs a ClientHello in 226 the regular fashion containing the true SNI value (ClientHelloInner) 227 and then encrypts it using the public key for the provider. It then 228 constructs a new ClientHello (ClientHelloOuter) with an innocuous SNI 229 (and potentially innocuous versions of other extensions such as ALPN 230 [RFC7301]) and containing the encrypted ClientHelloInner as an 231 extension. It sends ClientHelloOuter to the server. 233 Upon receiving ClientHelloOuter, the server can then decrypt 234 ClientHelloInner and either terminate the connection (in Shared Mode) 235 or forward it to the backend server (in Split Mode). 237 Note that both ClientHelloInner and ClientHelloOuter are both valid, 238 complete ClientHello messages. ClientHelloOuter carries an encrypted 239 representation of ClientHelloInner in a "encrypted_client_hello" 240 extension, defined in Section 5. 242 4. Encrypted ClientHello Configuration 244 ClientHello encryption configuration information is conveyed with the 245 following ECHConfigs structure. 247 opaque HpkePublicKey<1..2^16-1>; 248 uint16 HkpeKemId; // Defined in I-D.irtf-cfrg-hpke 249 uint16 HkpeKdfId; // Defined in I-D.irtf-cfrg-hpke 250 uint16 HkpeAeadId; // Defined in I-D.irtf-cfrg-hpke 252 struct { 253 HkpeKdfId kdf_id; 254 HkpeAeadId aead_id; 255 } HpkeCipherSuite; 257 struct { 258 opaque public_name<1..2^16-1>; 260 HpkePublicKey public_key; 261 HkpeKemId kem_id; 262 HpkeCipherSuite cipher_suites<4..2^16-2>; 264 uint16 maximum_name_length; 265 Extension extensions<0..2^16-1>; 266 } ECHConfigContents; 268 struct { 269 uint16 version; 270 uint16 length; 271 select (ECHConfig.version) { 272 case 0xff07: ECHConfigContents; 273 } 274 } ECHConfig; 276 ECHConfig ECHConfigs<1..2^16-1>; 278 The ECHConfigs structure contains one or more ECHConfig structures in 279 decreasing order of preference. This allows a server to support 280 multiple versions of ECH and multiple sets of ECH parameters. 282 The ECHConfig structure contains the following fields: 284 version The version of the structure. For this specification, that 285 value SHALL be 0xff07. Clients MUST ignore any ECHConfig 286 structure with a version they do not understand. 288 contents An opaque byte string whose contents depend on the version 289 of the structure. For this specification, the contents are an 290 ECHConfigContents structure. 292 The ECHConfigContents structure contains the following fields: 294 public_name The non-empty name of the entity trusted to update these 295 encryption keys. This is used to repair misconfigurations, as 296 described in Section 7.3. 298 public_key The HPKE [I-D.irtf-cfrg-hpke] public key which can be 299 used by the client to encrypt the ClientHello. 301 kem_id The HPKE [I-D.irtf-cfrg-hpke] KEM identifier corresponding to 302 public_key. Clients MUST ignore any ECHConfig structure with a 303 key using a KEM they do not support. 305 cipher_suites The list of HPKE [I-D.irtf-cfrg-hpke] AEAD and KDF 306 identifier pairs clients can use for encrypting the ClientHello. 308 maximum_name_length The largest name the server expects to support, 309 if known. If this value is not known it can be set to zero, in 310 which case clients SHOULD use the inner ClientHello padding scheme 311 described below. That could happen if wildcard names are in use, 312 or if names can be added or removed from the anonymity set during 313 the lifetime of a particular resource record value. 315 extensions A list of extensions that the client can take into 316 consideration when generating a ClientHello message. The purpose 317 of the field is to provide room for additional functionality in 318 the future. See Section 12 for guidance on what type of 319 extensions are appropriate for this structure. 321 The format is defined in [RFC8446], Section 4.2. The same 322 interpretation rules apply: extensions MAY appear in any order, but 323 there MUST NOT be more than one extension of the same type in the 324 extensions block. An extension can be tagged as mandatory by using 325 an extension type codepoint with the high order bit set to 1. A 326 client which receives a mandatory extension they do not understand 327 MUST reject the ECHConfig content. 329 Clients MUST parse the extension list and check for unsupported 330 mandatory extensions. If an unsupported mandatory extension is 331 present, clients MUST reject the ECHConfig value. 333 5. The "encrypted_client_hello" extension 335 The encrypted ClientHelloInner is carried in an 336 "encrypted_client_hello" extension, defined as follows: 338 enum { 339 encrypted_client_hello(0xff02), (65535) 340 } ExtensionType; 342 For clients (in ClientHello), this extension contains the following 343 ClientEncryptedCH structure: 345 struct { 346 HpkeCipherSuite suite; 347 opaque record_digest<0..2^16-1>; 348 opaque enc<1..2^16-1>; 349 opaque encrypted_ch<1..2^16-1>; 350 } ClientEncryptedCH; 352 suite The HpkeCipherSuite cipher suite used to encrypt 353 ClientHelloInner. This MUST match a value provided in the 354 corresponding ECHConfig.cipher_suites list. 356 record_digest A cryptographic hash of the ECHConfig structure from 357 which the ECH key was obtained, i.e., from the first byte of 358 "version" to the end of the structure. This hash is computed 359 using the hash function associated with "suite", i.e., the 360 corresponding HPKE KDF algorithm hash. 362 enc The HPKE encapsulated key, used by servers to decrypt the 363 corresponding encrypted_ch field. 365 encrypted_ch The serialized and encrypted ClientHelloInner 366 structure, AEAD-encrypted using HPKE with the selected KEM, KDF, 367 and AEAD algorithm and key generated as described below. 369 If the server accepts ECH, it does not send this extension. If it 370 rejects ECH, then it sends the following structure in 371 EncryptedExtensions: 373 struct { 374 ECHConfigs retry_configs; 375 } ServerEncryptedCH; 377 retry_configs An ECHConfigs structure containing one or more 378 ECHConfig structures in decreasing order of preference that the 379 client should use on subsequent connections to encrypt the 380 ClientHelloInner structure. 382 This protocol also defines the "ech_required" alert, which is sent by 383 the client when it offered an "encrypted_client_hello" extension 384 which was not accepted by the server. 386 6. The "ech_nonce" extension 388 When using ECH, the client MUST also add an extension of type 389 "ech_nonce" to the ClientHelloInner (but not to the outer 390 ClientHello). This nonce ensures that the server's encrypted 391 Certificate can only be read by the entity which sent this 392 ClientHello. This extension is defined as follows: 394 enum { 395 ech_nonce(0xff03), (65535) 396 } ExtensionType; 398 struct { 399 uint8 nonce[16]; 400 } ECHNonce; 402 nonce A 16-byte nonce exported from the HPKE encryption context. 403 See Section 7.1 for details about its computation. 405 Finally, requirements in Section 7 and Section 8 require 406 implementations to track, alongside each PSK established by a 407 previous connection, whether the connection negotiated this extension 408 with the "ech_accept" response type. If so, this is referred to as 409 an "ECH PSK". Otherwise, it is a "non-ECH PSK". This may be 410 implemented by adding a new field to client and server session 411 states. 413 6.1. Incorporating Outer Extensions 415 Some TLS 1.3 extensions can be quite large and having them both in 416 the inner and outer ClientHello will lead to a very large overall 417 size. One particularly pathological example is "key_share" with 418 post-quantum algorithms. In order to reduce the impact of duplicated 419 extensions, the client may use the "outer_extensions" extension. 421 enum { 422 outer_extension(0xff04), (65535) 423 } ExtensionType; 425 struct { 426 ExtensionType outer_extensions<2..254>; 427 uint8 hash<32..255>; 428 } OuterExtensions; 430 OuterExtensions MUST only be used in ClientHelloInner. It consists 431 of one or more ExtensionType values, each of which reference an 432 extension in ClientHelloOuter, and a digest of the complete 433 ClientHelloInner. 435 When sending ClientHello, the client first computes ClientHelloInner, 436 including any PSK binders, and then MAY substitute extensions which 437 it knows will be duplicated in ClientHelloOuter. To do so, the 438 client computes a hash H of the entire ClientHelloInner message with 439 the same hash as for the KDF used to encrypt ClienHelloInner. Then, 440 the client removes and and replaces extensions from ClientHelloInner 441 with a single "outer_extensions" extension. The list of 442 outer_extensions include those which were removed from 443 ClientHelloInner, in the order in which they were removed. The hash 444 contains the full ClientHelloInner hash H computed above. 446 This process is reversed by client-facing servers upon receipt. 447 Specifically, the server replaces the "outer_extensions" with 448 extensions contained in ClientHelloOuter. The server then computes a 449 hash H' of the reconstructed ClientHelloInner. If H' does not equal 450 OuterExtensions.hash, the server aborts the connection with an 451 "illegal_parameter" alert. 453 Clients SHOULD only use this mechanism for extensions which are 454 large. All other extensions SHOULD appear in both ClientHelloInner 455 and ClientHelloOuter even if they have identical values. 457 7. Client Behavior 459 7.1. Sending an encrypted ClientHello 461 In order to send an encrypted ClientHello, the client first 462 determines if it supports the server's chosen KEM, as identified by 463 ECHConfig.kem_id. If one is supported, the client MUST select an 464 appropriate HpkeCipherSuite from the list of suites offered by the 465 server. If the client does not support the corresponding KEM or is 466 unable to select an appropriate group or HpkeCipherSuite, it SHOULD 467 ignore that ECHConfig value and MAY attempt to use another value 468 provided by the server. The client MUST NOT send ECH using HPKE 469 algorithms not advertised by the server. 471 Given a compatible ECHConfig with fields public_key and kem_id, 472 carrying the HpkePublicKey and KEM identifier corresponding to the 473 server, clients compute an HPKE encryption context as follows: 475 pkR = HPKE.KEM.Unmarshal(ECHConfig.public_key) 476 enc, context = SetupBaseS(pkR, "tls13-ech") 477 ech_nonce_value = context.Export("tls13-ech-nonce", 16) 478 ech_hrr_key = context.Export("tls13-ech-hrr-key", 16) 480 Note that the HPKE algorithm identifiers are those which match the 481 client's chosen preference from ECHConfig.cipher_suites. The client 482 MAY replace any large, duplicated extensions in ClientHelloInner with 483 the corresponding "outer_extensions" extension, as described in 484 Section 6.1. 486 The client then generates a ClientHelloInner value. In addition to 487 the normal values, ClientHelloInner MUST also contain: 489 * an "ech_nonce" extension, containing "ech_nonce_value" derived 490 above 492 * TLS padding [RFC7685] (see Section 7.2) 494 When offering an encrypted ClientHello, the client MUST NOT offer to 495 resume any non-ECH PSKs. It additionally MUST NOT offer to resume 496 any sessions for TLS 1.2 or below. 498 The encrypted ClientHello value is then computed as: 500 encrypted_ch = context.Seal("", ClientHelloInner) 502 Finally, the client MUST generate a ClientHelloOuter message 503 containing the "encrypted_client_hello" extension with the values as 504 indicated above. In particular, 506 * suite contains the client's chosen HpkeCipherSuite; 508 * record_digest contains the digest of the corresponding ECHConfig 509 structure; 511 * enc contains the encapsulated key as output by SetupBaseS; and 513 * encrypted_ch contains the HPKE encapsulated key (enc) and the 514 ClientHelloInner ciphertext (encrypted_ch_inner). 516 The client MUST place the value of ECHConfig.public_name in the 517 ClientHelloOuter "server_name" extension. The ClientHelloOuter MUST 518 NOT contain a "cached_info" extension [RFC7924] with a CachedObject 519 entry whose CachedInformationType is "cert", since this indication 520 would divulge the true server name. The remaining contents of the 521 ClientHelloOuter MAY be identical to those in ClientHelloInner but 522 MAY also differ. 524 7.2. Recommended Padding Scheme 526 This section describes a deterministic padding mechanism based on the 527 following observation: individual extensions can reveal sensitive 528 information through their length. Thus, each extension in the inner 529 ClientHello may require different amounts of padding. This padding 530 may be fully determined by the client's configuration or may require 531 server input. 533 By way of example, clients typically support a small number of 534 application profiles. For instance, a browser might support HTTP 535 with ALPN values ["http/1.1, "h2"] and WebRTC media with ALPNs 536 ["webrtc", "c-webrtc"]. Clients SHOULD pad this extension by 537 rounding up to the total size of the longest ALPN extension across 538 all application profiles. The target padding length of most 539 ClientHello extensions can be computed in this way. 541 In contrast, clients do not know the longest SNI value in the client- 542 facing server's anonymity set without server input. For the 543 "server_name" extension with length D, clients SHOULD use the 544 server's length hint L (ECHCOnfig.maximum_name_length) when computing 545 the padding as follows: 547 1. If L > D, add L - D bytes of padding. This rounds to the 548 server's advertised hint, i.e., ECHConfig.maximum_name_length. 550 2. Otherwise, add 32 - (D % 32) bytes of padding. This rounds D up 551 to the nearest multiple of 32 bytes. 553 In addition to padding ClientHelloInner, clients and servers will 554 also need to pad all other handshake messages that have sensitive- 555 length fields. For example, if a client proposes ALPN values in 556 ClientHelloInner, the server-selected value will be returned in an 557 EncryptedExtension, so that handshake message also needs to be padded 558 using TLS record layer padding. 560 7.3. Handling the server response 562 As described in Section 8, the server MAY either accept ECH and use 563 ClientHelloInner or reject it and use ClientHelloOuter. However, 564 there is no indication in ServerHello of which one the server has 565 done and the client must therefore use trial decryption in order to 566 determine this. 568 7.3.1. Accepted ECH 570 If the server used ClientHelloInner, the client proceeds with the 571 connection as usual, authenticating the connection for the origin 572 server. 574 7.3.2. Rejected ECH 576 If the server used ClientHelloOuter, the client proceeds with the 577 handshake, authenticating for ECHConfig.public_name as described in 578 Section 7.3.2.1. If authentication or the handshake fails, the 579 client MUST return a failure to the calling application. It MUST NOT 580 use the retry keys. 582 Otherwise, when the handshake completes successfully with the public 583 name authenticated, the client MUST abort the connection with an 584 "ech_required" alert. It then processes the "retry_keys" field from 585 the server's "encrypted_client_hello" extension. 587 If one of the values contains a version supported by the client, it 588 can regard the ECH keys as securely replaced by the server. It 589 SHOULD retry the handshake with a new transport connection, using 590 that value to encrypt the ClientHello. The value may only be applied 591 to the retry connection. The client MUST continue to use the 592 previously-advertised keys for subsequent connections. This avoids 593 introducing pinning concerns or a tracking vector, should a malicious 594 server present client-specific retry keys to identify clients. 596 If none of the values provided in "retry_keys" contains a supported 597 version, the client can regard ECH as securely disabled by the 598 server. As below, it SHOULD then retry the handshake with a new 599 transport connection and ECH disabled. 601 If the field contains any other value, the client MUST abort the 602 connection with an "illegal_parameter" alert. 604 If the server negotiates an earlier version of TLS, or if it does not 605 provide an "encrypted_client_hello" extension in EncryptedExtensions, 606 the client proceeds with the handshake, authenticating for 607 ECHConfigContents.public_name as described in Section 7.3.2.1. If an 608 earlier version was negotiated, the client MUST NOT enable the False 609 Start optimization [RFC7918] for this handshake. If authentication 610 or the handshake fails, the client MUST return a failure to the 611 calling application. It MUST NOT treat this as a secure signal to 612 disable ECH. 614 Otherwise, when the handshake completes successfully with the public 615 name authenticated, the client MUST abort the connection with an 616 "ech_required" alert. The client can then regard ECH as securely 617 disabled by the server. It SHOULD retry the handshake with a new 618 transport connection and ECH disabled. 620 Clients SHOULD implement a limit on retries caused by 621 "ech_retry_request" or servers which do not acknowledge the 622 "encrypted_client_hello" extension. If the client does not retry in 623 either scenario, it MUST report an error to the calling application. 625 7.3.2.1. Authenticating for the public name 627 When the server cannot decrypt or does not process the 628 "encrypted_client_hello" extension, it continues with the handshake 629 using the cleartext "server_name" extension instead (see Section 8). 630 Clients that offer ECH then authenticate the connection with the 631 public name, as follows: 633 * If the server resumed a session or negotiated a session that did 634 not use a certificate for authentication, the client MUST abort 635 the connection with an "illegal_parameter" alert. This case is 636 invalid because Section 7.1 requires the client to only offer ECH- 637 established sessions, and Section 8 requires the server to decline 638 ECH-established sessions if it did not accept ECH. 640 * The client MUST verify that the certificate is valid for 641 ECHConfigContents.public_name. If invalid, it MUST abort the 642 connection with the appropriate alert. 644 * If the server requests a client certificate, the client MUST 645 respond with an empty Certificate message, denoting no client 646 certificate. 648 Note that authenticating a connection for the public name does not 649 authenticate it for the origin. The TLS implementation MUST NOT 650 report such connections as successful to the application. It 651 additionally MUST ignore all session tickets and session IDs 652 presented by the server. These connections are only used to trigger 653 retries, as described in Section 7.3. This may be implemented, for 654 instance, by reporting a failed connection with a dedicated error 655 code. 657 7.3.3. HelloRetryRequest 659 If the server sends a HelloRetryRequest in response to the 660 ClientHello, the client sends a second updated ClientHello per the 661 rules in [RFC8446]. However, at this point, the client does not know 662 whether the server processed ClientHelloOuter or ClientHelloInner, 663 and MUST regenerate both values to be acceptable. Note: if the inner 664 and outer ClientHellos use different groups for their key shares or 665 differ in some other way, then the HelloRetryRequest may actually be 666 invalid for one or the other ClientHello, in which case a fresh 667 ClientHello MUST be generated, ignoring the instructions in 668 HelloRetryRequest. Otherwise, the usual rules for HelloRetryRequest 669 processing apply. 671 Clients bind encryption of the second ClientHelloInner to encryption 672 of the first ClientHelloInner via the derived ech_hrr_key by 673 modifying HPKE setup as follows: 675 pkR = HPKE.KEM.Unmarshal(ECHConfig.public_key) 676 enc, context = SetupPSKS(pkR, "tls13-ech-hrr", ech_hrr_key, "") 677 ech_nonce_value = context.Export("tls13-ech-hrr-nonce", 16) 679 Clients then encrypt the second ClientHelloInner using this new HPKE 680 context. In doing so, the encrypted value is also authenticated by 681 ech_hrr_key. The rationale for this is described in Section 10.7.2. 683 Client-facing servers perform the corresponding process when 684 decrypting second ClientHelloInner messages. In particular, upon 685 receipt of a second ClientHello message with a ClientEncryptedCH 686 value, servers setup their HPKE context and decrypt ClientEncryptedCH 687 as follows: 689 context = SetupPSKR(ClientEncryptedCH.enc, skR, "tls13-ech-hrr", ech_hrr_key, "") 690 ClientHelloInner = context.Open("", ClientEncryptedCH.encrypted_ch) 691 ech_nonce_value = context.Export("tls13-ech-hrr-nonce", 16) 693 [[OPEN ISSUE: Should we be using the PSK input or the info input? On 694 the one hand, the requirements on info seem weaker, but maybe 695 actually this needs to be secret? Analysis needed.]] 697 7.4. GREASE extensions 699 If the client attempts to connect to a server and does not have an 700 ECHConfig structure available for the server, it SHOULD send a GREASE 701 [RFC8701] "encrypted_client_hello" extension as follows: 703 * Set the "suite" field to a supported HpkeCipherSuite. The 704 selection SHOULD vary to exercise all supported configurations, 705 but MAY be held constant for successive connections to the same 706 server in the same session. 708 * Set the "record_digest" field to a randomly-generated string of 709 hash_length bytes, where hash_length is the length of the hash 710 function associated with the chosen HpkeCipherSuite. 712 * Set the "enc" field to a randomly-generated valid encapsulated 713 public key output by the HPKE KEM. 715 * Set the "encrypted_ch" field to a randomly-generated string of L 716 bytes, where L is the size of the ClientHelloInner message the 717 client would use given an ECHConfig structure, padded according to 718 Section 7.2. 720 If the server sends an "encrypted_client_hello" extension, the client 721 MUST check the extension syntactically and abort the connection with 722 a "decode_error" alert if it is invalid. 724 Offering a GREASE extension is not considered offering an encrypted 725 ClientHello for purposes of requirements in Section 7. In 726 particular, the client MAY offer to resume sessions established 727 without ECH. 729 8. Client-Facing Server Behavior 731 Upon receiving an "encrypted_client_hello" extension, the client- 732 facing server MUST check that it is able to negotiate TLS 1.3 or 733 greater. If not, it MUST abort the connection with a 734 "handshake_failure" alert. 736 The ClientEncryptedCH value is said to match a known ECHConfig if 737 there exists an ECHConfig that can be used to successfully decrypt 738 ClientEncryptedCH.encrypted_ch. This matching procedure should be 739 done using one of the following two checks: 741 1. Compare ClientEncryptedCH.record_digest against cryptographic 742 hashes of known ECHConfig and choose the one that matches. 744 2. Use trial decryption of ClientEncryptedCH.encrypted_ch with known 745 ECHConfig and choose the one that succeeds. 747 Some uses of ECH, such as local discovery mode, may omit the 748 ClientEncryptedCH.record_digest since it can be used as a tracking 749 vector. In such cases, trial decryption should be used for matching 750 ClientEncryptedCH to known ECHConfig. Unless specified by the 751 application using (D)TLS or externally configured on both sides, 752 implementations MUST use the first method. 754 If the ClientEncryptedCH value does not match any known ECHConfig 755 structure, it MUST ignore the extension and proceed with the 756 connection, with the following added behavior: 758 * It MUST include the "encrypted_client_hello" extension with the 759 "retry_keys" field set to one or more ECHConfig structures with 760 up-to-date keys. Servers MAY supply multiple ECHConfig values of 761 different versions. This allows a server to support multiple 762 versions at once. 764 * The server MUST ignore all PSK identities in the ClientHello which 765 correspond to ECH PSKs. ECH PSKs offered by the client are 766 associated with the ECH name. The server was unable to decrypt 767 then ECH name, so it should not resume them when using the 768 cleartext SNI name. This restriction allows a client to reject 769 resumptions in Section 7.3.2.1. 771 Note that an unrecognized ClientEncryptedCH.record_digest value may 772 be a GREASE ECH extension (see Section 7.4), so it is necessary for 773 servers to proceed with the connection and rely on the client to 774 abort if ECH was required. In particular, the unrecognized value 775 alone does not indicate a misconfigured ECH advertisement 776 (Section 9.1). Instead, servers can measure occurrences of the 777 "ech_required" alert to detect this case. 779 If the ClientEncryptedCH value matches a known ECHConfig, the server 780 then decrypts ClientEncryptedCH.encrypted_ch, using the private key 781 skR corresponding to ECHConfig, as follows: 783 context = SetupBaseR(ClientEncryptedCH.enc, skR, "tls13-ech") 784 ClientHelloInner = context.Open("", ClientEncryptedCH.encrypted_ch) 785 ech_nonce_value = context.Export("tls13-ech-nonce", 16) 786 ech_hrr_key = context.Export("tls13-ech-hrr-key", 16) 788 If decryption fails, the server MUST abort the connection with a 789 "decrypt_error" alert. Moreover, if there is no "ech_nonce" 790 extension, or if its value does not match the derived ech_nonce, the 791 server MUST abort the connection with a "decrypt_error" alert. Next, 792 the server MUST scan ClientHelloInner for any "outer_extension" 793 extensions and substitute their values with the values in 794 ClientHelloOuter. It MUST first verify that the hash found in the 795 extension matches the hash of the extension to be interpolated in and 796 if it does not, abort the connections with a "decrypt_error" alert. 798 Upon determining the true SNI, the client-facing server then either 799 serves the connection directly (if in Shared Mode), in which case it 800 executes the steps in the following section, or forwards the TLS 801 connection to the backend server (if in Split Mode). In the latter 802 case, it does not make any changes to the TLS messages, but just 803 blindly forwards them. 805 If the server sends a NewSessionTicket message, the corresponding ECH 806 PSK MUST be ignored by all other servers in the deployment when not 807 negotiating ECH, including servers which do not implement this 808 specification. 810 9. Compatibility Issues 812 Unlike most TLS extensions, placing the SNI value in an ECH extension 813 is not interoperable with existing servers, which expect the value in 814 the existing cleartext extension. Thus server operators SHOULD 815 ensure servers understand a given set of ECH keys before advertising 816 them. Additionally, servers SHOULD retain support for any 817 previously-advertised keys for the duration of their validity 819 However, in more complex deployment scenarios, this may be difficult 820 to fully guarantee. Thus this protocol was designed to be robust in 821 case of inconsistencies between systems that advertise ECH keys and 822 servers, at the cost of extra round-trips due to a retry. Two 823 specific scenarios are detailed below. 825 9.1. Misconfiguration and Deployment Concerns 827 It is possible for ECH advertisements and servers to become 828 inconsistent. This may occur, for instance, from DNS 829 misconfiguration, caching issues, or an incomplete rollout in a 830 multi-server deployment. This may also occur if a server loses its 831 ECH keys, or if a deployment of ECH must be rolled back on the 832 server. 834 The retry mechanism repairs inconsistencies, provided the server is 835 authoritative for the public name. If server and advertised keys 836 mismatch, the server will respond with ech_retry_requested. If the 837 server does not understand the "encrypted_client_hello" extension at 838 all, it will ignore it as required by [RFC8446]; Section 4.1.2. 839 Provided the server can present a certificate valid for the public 840 name, the client can safely retry with updated settings, as described 841 in Section 7.3. 843 Unless ECH is disabled as a result of successfully establishing a 844 connection to the public name, the client MUST NOT fall back to using 845 unencrypted ClientHellos, as this allows a network attacker to 846 disclose the contents of this ClientHello, including the SNI. It MAY 847 attempt to use another server from the DNS results, if one is 848 provided. 850 Client-facing servers with non-uniform cryptographic configurations 851 across backend origin servers segment the ECH anonymity set based on 852 these configurations. For example, if a client-facing server hosts k 853 backend origin servers, and exactly one of those backend origin 854 servers supports a different set of cryptographic algorithms than the 855 other (k - 1) servers, it may be possible to identify this single 856 server based on the contents of the ServerHello as this message is 857 not encrypted. 859 9.2. Middleboxes 861 A more serious problem is MITM proxies which do not support this 862 extension. [RFC8446], Section 9.3 requires that such proxies remove 863 any extensions they do not understand. The handshake will then 864 present a certificate based on the public name, without eching the 865 "encrypted_client_hello" extension to the client. 867 Depending on whether the client is configured to accept the proxy's 868 certificate as authoritative for the public name, this may trigger 869 the retry logic described in Section 7.3 or result in a connection 870 failure. A proxy which is not authoritative for the public name 871 cannot forge a signal to disable ECH. 873 A non-conformant MITM proxy which instead forwards the ECH extension, 874 substituting its own KeyShare value, will result in the client-facing 875 server recognizing the key, but failing to decrypt the SNI. This 876 causes a hard failure. Clients SHOULD NOT attempt to repair the 877 connection in this case. 879 10. Security Considerations 881 10.1. Why is cleartext DNS OK? 883 In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource 884 Records are signed via a server private key, ECH records have no 885 authenticity or provenance information. This means that any attacker 886 which can inject DNS responses or poison DNS caches, which is a 887 common scenario in client access networks, can supply clients with 888 fake ECH records (so that the client encrypts data to them) or strip 889 the ECH record from the response. However, in the face of an 890 attacker that controls DNS, no encryption scheme can work because the 891 attacker can replace the IP address, thus blocking client 892 connections, or substituting a unique IP address which is 1:1 with 893 the DNS name that was looked up (modulo DNS wildcards). Thus, 894 allowing the ECH records in the clear does not make the situation 895 significantly worse. 897 Clearly, DNSSEC (if the client validates and hard fails) is a defense 898 against this form of attack, but DoH/DPRIVE are also defenses against 899 DNS attacks by attackers on the local network, which is a common case 900 where ClientHello and SNI encryption are desired. Moreover, as noted 901 in the introduction, SNI encryption is less useful without encryption 902 of DNS queries in transit via DoH or DPRIVE mechanisms. 904 10.2. Client Tracking 906 A malicious client-facing server could distribute unique, per-client 907 ECHConfig structures as a way of tracking clients across subsequent 908 connections. On-path adversaries which know about these unique keys 909 could also track clients in this way by observing TLS connection 910 attempts. 912 The cost of this type of attack scales linearly with the desired 913 number of target clients. Moreover, DNS caching behavior makes 914 targeting individual users for extended periods of time, e.g., using 915 per-client ECHConfig structures delivered via HTTPSSVC RRs with high 916 TTLs, challenging. Clients can help mitigate this problem by 917 flushing any DNS or ECHConfig state upon changing networks. 919 10.3. Optional Record Digests and Trial Decryption 921 Optional record digests may be useful in scenarios where clients and 922 client-facing servers do not want to reveal information about the 923 client-facing server in the "encrypted_client_hello" extension. In 924 such settings, servers must perform trial decrypt upon receipt of an 925 empty record digest, which may exacerbate DoS attacks. Specifically, 926 an adversary may send malicious ClientHello messages, i.e., those 927 which will not decrypt with any known ECH key, in order to force 928 wasteful decryption. Servers that support this feature should, for 929 example, implement some form of rate limiting mechanism to limit the 930 damage caused by such attacks. 932 10.4. Related Privacy Leaks 934 ECH requires encrypted DNS to be an effective privacy protection 935 mechanism. However, verifying the server's identity from the 936 Certificate message, particularly when using the X509 937 CertificateType, may result in additional network traffic that may 938 reveal the server identity. Examples of this traffic may include 939 requests for revocation information, such as OCSP or CRL traffic, or 940 requests for repository information, such as 941 authorityInformationAccess. It may also include implementation- 942 specific traffic for additional information sources as part of 943 verification. 945 Implementations SHOULD avoid leaking information that may identify 946 the server. Even when sent over an encrypted transport, such 947 requests may result in indirect exposure of the server's identity, 948 such as indicating a specific CA or service being used. To mitigate 949 this risk, servers SHOULD deliver such information in-band when 950 possible, such as through the use of OCSP stapling, and clients 951 SHOULD take steps to minimize or protect such requests during 952 certificate validation. 954 10.5. Comparison Against Criteria 956 [I-D.ietf-tls-sni-encryption] lists several requirements for SNI 957 encryption. In this section, we re-iterate these requirements and 958 assess the ECH design against them. 960 10.5.1. Mitigate against replay attacks 962 Since servers process either ClientHelloInner or ClientHelloOuter, 963 and ClientHelloInner contains an HPKE-derived nonce, it is not 964 possible for an attacker to "cut and paste" the ECH value in a 965 different Client Hello and learn information from ClientHelloInner. 966 This is because the attacker lacks access to the HPKE-derived nonce 967 used to derive the handshake secrets. 969 10.5.2. Avoid widely-deployed shared secrets 971 This design depends upon DNS as a vehicle for semi-static public key 972 distribution. Server operators may partition their private keys 973 however they see fit provided each server behind an IP address has 974 the corresponding private key to decrypt a key. Thus, when one ECH 975 key is provided, sharing is optimally bound by the number of hosts 976 that share an IP address. Server operators may further limit sharing 977 by publishing different DNS records containing ECHConfig values with 978 different keys using a short TTL. 980 10.5.3. Prevent SNI-based DoS attacks 982 This design requires servers to decrypt ClientHello messages with 983 ClientEncryptedCH extensions carrying valid digests. Thus, it is 984 possible for an attacker to force decryption operations on the 985 server. This attack is bound by the number of valid TCP connections 986 an attacker can open. 988 10.5.4. Do not stick out 990 The only explicit signal indicating possible use of ECH is the 991 ClientHello "encrypted_client_hello" extension. Server handshake 992 messages do not contain any signal indicating use or negotiation of 993 ECH. Clients MAY GREASE the "encrypted_client_hello" extension, as 994 described in Section 7.4, which helps ensure the ecosystem handles 995 ECH correctly. Moreover, as more clients enable ECH support, e.g., 996 as normal part of Web browser functionality, with keys supplied by 997 shared hosting providers, the presence of ECH extensions becomes less 998 unusual and part of typical client behavior. In other words, if all 999 Web browsers start using ECH, the presence of this value will not 1000 signal unusual behavior to passive eavesdroppers. 1002 10.5.5. Forward secrecy 1004 This design is not forward secret because the server's ECH key is 1005 static. However, the window of exposure is bound by the key 1006 lifetime. It is RECOMMENDED that servers rotate keys frequently. 1008 10.5.6. Proper security context 1010 This design permits servers operating in Split Mode to forward 1011 connections directly to backend origin servers, thereby avoiding 1012 unnecessary MiTM attacks. 1014 10.5.7. Split server spoofing 1016 Assuming ECH records retrieved from DNS are authenticated, e.g., via 1017 DNSSEC or fetched from a trusted Recursive Resolver, spoofing a 1018 server operating in Split Mode is not possible. See Section 10.1 for 1019 more details regarding cleartext DNS. 1021 Authenticating the ECHConfigs structure naturally authenticates the 1022 included public name. This also authenticates any retry signals from 1023 the server because the client validates the server certificate 1024 against the public name before retrying. 1026 10.5.8. Supporting multiple protocols 1028 This design has no impact on application layer protocol negotiation. 1029 It may affect connection routing, server certificate selection, and 1030 client certificate verification. Thus, it is compatible with 1031 multiple protocols. 1033 10.6. Padding Policy 1035 Variations in the length of the ClientHelloInner ciphertext could 1036 leak information about the corresponding plaintext. Section 7.2 1037 describes a RECOMMENDED padding mechanism for clients aimed at 1038 reducing potential information leakage. 1040 10.7. Active Attack Mitigations 1042 This section describes the rationale for ECH properties and mechanics 1043 as defenses against active attacks. In all the attacks below, the 1044 attacker is on-path between the target client and server. The goal 1045 of the attacker is to learn private information about the inner 1046 ClientHello, such as the true SNI value. 1048 10.7.1. Client Reaction Attack Mitigation 1050 This attack uses the client's reaction to an incorrect certificate as 1051 an oracle. The attacker intercepts a legitimate ClientHello and 1052 replies with a ServerHello, Certificate, CertificateVerify, and 1053 Finished messages, wherein the Certificate message contains a "test" 1054 certificate for the domain name it wishes to query. If the client 1055 decrypted the Certificate and failed verification (or leaked 1056 information about its verification process by a timing side channel), 1057 the attacker learns that its test certificate name was incorrect. As 1058 an example, suppose the client's SNI value in its inner ClientHello 1059 is "example.com," and the attacker replied with a Certificate for 1060 "test.com". If the client produces a verification failure alert 1061 because of the mismatch faster than it would due to the Certificate 1062 signature validation, information about the name leaks. Note that 1063 the attacker can also withhold the CertificateVerify message. In 1064 that scenario, a client which first verifies the Certificate would 1065 then respond similarly and leak the same information. 1067 Client Attacker Server 1068 ClientHello 1069 + key_share 1070 + ech ------> (intercept) -----> X (drop) 1072 ServerHello 1073 + key_share 1074 {EncryptedExtensions} 1075 {CertificateRequest*} 1076 {Certificate*} 1077 {CertificateVerify*} 1078 <------ 1079 Alert 1080 ------> 1082 Figure 3: Client reaction attack 1084 The "ech_nonce" extension in the inner ClientHello prevents this 1085 attack. In particular, since the attacker does not have access to 1086 this value, it cannot produce the right transcript and handshake keys 1087 needed for encrypting the Certificate message. Thus, the client will 1088 fail to decrypt the Certificate and abort the connection. 1090 10.7.2. HelloRetryRequest Hijack Mitigation 1092 This attack aims to exploit server HRR state management to recover 1093 information about a legitimate ClientHello using its own attacker- 1094 controlled ClientHello. To begin, the attacker intercepts and 1095 forwards a legitimate ClientHello with an "encrypted_client_hello" 1096 (ech) extension to the server, which triggers a legitimate 1097 HelloRetryRequest in return. Rather than forward the retry to the 1098 client, the attacker, attempts to generate its own ClientHello in 1099 response based on the contents of the first ClientHello and 1100 HelloRetryRequest exchange with the result that the server encrypts 1101 the Certificate to the attacker. If the server used the SNI from the 1102 first ClientHello and the key share from the second (attacker- 1103 controlled) ClientHello, the Certificate produced would leak the 1104 client's chosen SNI to the attacker. 1106 Client Attacker Server 1107 ClientHello 1108 + key_share 1109 + ech ------> (forward) -------> 1110 HelloRetryRequest 1111 + key_share 1112 (intercept) <------- 1114 ClientHello 1115 + key_share' 1116 + ech' -------> 1117 ServerHello 1118 + key_share 1119 {EncryptedExtensions} 1120 {CertificateRequest*} 1121 {Certificate*} 1122 {CertificateVerify*} 1123 {Finished} 1124 <------- 1125 (process server flight) 1127 Figure 4: HelloRetryRequest hijack attack 1129 This attack is mitigated by binding the first and second ClientHello 1130 messages together. In particular, since the attacker does not 1131 possess the ech_hrr_key, it cannot generate a valid encryption of the 1132 second inner ClientHello. The server will attempt decryption using 1133 ech_hrr_key, detect failure, and fail the connection. 1135 If the second ClientHello were not bound to the first, it might be 1136 possible for the server to act as an oracle if it required parameters 1137 from the first ClientHello to match that of the second ClientHello. 1139 For example, imagine the client's original SNI value in the inner 1140 ClientHello is "example.com", and the attacker's hijacked SNI value 1141 in its inner ClientHello is "test.com". A server which checks these 1142 for equality and changes behavior based on the result can be used as 1143 an oracle to learn the client's SNI. 1145 10.7.3. Resumption PSK Oracle Mitigation 1147 This attack uses resumption PSKs as an oracle for dictionary attacks 1148 against a given ClientHello's true SNI. To begin, the attacker first 1149 interacts with a server to obtain a resumption ticket for a given 1150 test domain, such as "test.com". Later, upon receipt of a legitimate 1151 ClientHello without a PSK binder, it computes a PSK binder using its 1152 own ticket and forwards the resulting ClientHello. Assume the server 1153 then validates the PSK binder on the outer ClientHello and chooses 1154 connection parameters based on the inner ClientHello. A server which 1155 then validates information in the outer ClientHello ticket against 1156 information in the inner ClientHello, such as the SNI, introduces an 1157 oracle that can be used to test the encrypted SNI value of specific 1158 ClientHello messages. 1160 Client Attacker Server 1162 handshake and ticket 1163 for "test.com" 1164 <--------> 1166 ClientHello 1167 + key_share 1168 + ech --------> (intercept) 1169 ClientHello 1170 + key_share 1171 + ech 1172 + pre_shared_key 1173 --------> 1174 Alert 1175 <-------- 1177 Figure 5: Message flow for resumption and PSK 1179 ECH mitigates against this attack by requiring servers not mix-and- 1180 match information from the inner and outer ClientHello. For example, 1181 if the server accepts the inner ClientHello, it does not validate 1182 binders in the outer ClientHello. This means that ECH PSKs are used 1183 within the HPKE encryption envelope. 1185 11. IANA Considerations 1186 11.1. Update of the TLS ExtensionType Registry 1188 IANA is requested to create the following two entries in the existing 1189 registry for ExtensionType (defined in [RFC8446]): 1191 1. encrypted_client_hello(0xff02), with "TLS 1.3" column values 1192 being set to "CH, EE", and "Recommended" column being set to 1193 "Yes". 1195 2. ech_nonce(0xff03), with the "TLS 1.3" column values being set to 1196 "CH", and "Recommended" column being set to "Yes". 1198 3. outer_extension(0xff04), with the "TLS 1.3" column values being 1199 set to "CH", and "Recommended" column being set to "Yes". 1201 11.2. Update of the TLS Alert Registry 1203 IANA is requested to create an entry, ech_required(121) in the 1204 existing registry for Alerts (defined in [RFC8446]), with the "DTLS- 1205 OK" column being set to "Y". 1207 12. ECHConfig Extension Guidance 1209 Any future information or hints that influence the outer ClientHello 1210 SHOULD be specified as ECHConfig extensions, or in an entirely new 1211 version of ECHConfig. This is primarily because the outer 1212 ClientHello exists only in support of ECH. Namely, it is both an 1213 envelope for the encrypted inner ClientHello and enabler for 1214 authenticated key mismatch signals (see Section 8). In contrast, the 1215 inner ClientHello is the true ClientHello used upon ECH negotiation. 1217 13. References 1219 13.1. Normative References 1221 [HTTPSSVC] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 1222 and parameter specification via the DNS (DNS SVCB and 1223 HTTPSSVC)", Work in Progress, Internet-Draft, draft- 1224 nygren-dnsop-svcb-httpssvc-00, 23 September 2019, 1225 . 1228 [I-D.ietf-tls-exported-authenticator] 1229 Sullivan, N., "Exported Authenticators in TLS", Work in 1230 Progress, Internet-Draft, draft-ietf-tls-exported- 1231 authenticator-12, 15 May 2020, . 1235 [I-D.irtf-cfrg-hpke] 1236 Barnes, R., Bhargavan, K., and C. Wood, "Hybrid Public Key 1237 Encryption", Work in Progress, Internet-Draft, draft-irtf- 1238 cfrg-hpke-04, 8 May 2020, . 1241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1242 Requirement Levels", BCP 14, RFC 2119, 1243 DOI 10.17487/RFC2119, March 1997, 1244 . 1246 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 1247 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 1248 October 2015, . 1250 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 1251 Layer Security (TLS) False Start", RFC 7918, 1252 DOI 10.17487/RFC7918, August 2016, 1253 . 1255 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1256 (TLS) Cached Information Extension", RFC 7924, 1257 DOI 10.17487/RFC7924, July 2016, 1258 . 1260 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1261 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1262 May 2017, . 1264 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1265 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1266 . 1268 13.2. Informative References 1270 [I-D.ietf-doh-dns-over-https] 1271 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1272 (DoH)", Work in Progress, Internet-Draft, draft-ietf-doh- 1273 dns-over-https-14, 16 August 2018, . 1276 [I-D.ietf-tls-sni-encryption] 1277 Huitema, C. and E. Rescorla, "Issues and Requirements for 1278 SNI Encryption in TLS", Work in Progress, Internet-Draft, 1279 draft-ietf-tls-sni-encryption-09, 28 October 2019, 1280 . 1283 [I-D.kazuho-protected-sni] 1284 Oku, K., "TLS Extensions for Protecting SNI", Work in 1285 Progress, Internet-Draft, draft-kazuho-protected-sni-00, 1286 18 July 2017, . 1289 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1290 "Transport Layer Security (TLS) Application-Layer Protocol 1291 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1292 July 2014, . 1294 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1295 and P. Hoffman, "Specification for DNS over Transport 1296 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1297 2016, . 1299 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1300 Transport Layer Security (DTLS)", RFC 8094, 1301 DOI 10.17487/RFC8094, February 2017, 1302 . 1304 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 1305 Sustain Extensibility (GREASE) to TLS Extensibility", 1306 RFC 8701, DOI 10.17487/RFC8701, January 2020, 1307 . 1309 Appendix A. Alternative SNI Protection Designs 1311 Alternative approaches to encrypted SNI may be implemented at the TLS 1312 or application layer. In this section we describe several 1313 alternatives and discuss drawbacks in comparison to the design in 1314 this document. 1316 A.1. TLS-layer 1318 A.1.1. TLS in Early Data 1320 In this variant, TLS Client Hellos are tunneled within early data 1321 payloads belonging to outer TLS connections established with the 1322 client-facing server. This requires clients to have established a 1323 previous session --- and obtained PSKs --- with the server. The 1324 client-facing server decrypts early data payloads to uncover Client 1325 Hellos destined for the backend server, and forwards them onwards as 1326 necessary. Afterwards, all records to and from backend servers are 1327 forwarded by the client-facing server - unmodified. This avoids 1328 double encryption of TLS records. 1330 Problems with this approach are: (1) servers may not always be able 1331 to distinguish inner Client Hellos from legitimate application data, 1332 (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may 1333 not be supported - especially under DoS - leading to availability 1334 concerns, and (4) clients must bootstrap tunnels (sessions), costing 1335 an additional round trip and potentially revealing the SNI during the 1336 initial connection. In contrast, encrypted SNI protects the SNI in a 1337 distinct Client Hello extension and neither abuses early data nor 1338 requires a bootstrapping connection. 1340 A.1.2. Combined Tickets 1342 In this variant, client-facing and backend servers coordinate to 1343 produce "combined tickets" that are consumable by both. Clients 1344 offer combined tickets to client-facing servers. The latter parse 1345 them to determine the correct backend server to which the Client 1346 Hello should be forwarded. This approach is problematic due to non- 1347 trivial coordination between client-facing and backend servers for 1348 ticket construction and consumption. Moreover, it requires a 1349 bootstrapping step similar to that of the previous variant. In 1350 contrast, encrypted SNI requires no such coordination. 1352 A.2. Application-layer 1354 A.2.1. HTTP/2 CERTIFICATE Frames 1356 In this variant, clients request secondary certificates with 1357 CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. 1358 In response, servers supply certificates via TLS exported 1359 authenticators [I-D.ietf-tls-exported-authenticator] in CERTIFICATE 1360 frames. Clients use a generic SNI for the underlying client-facing 1361 server TLS connection. Problems with this approach include: (1) one 1362 additional round trip before peer authentication, (2) non-trivial 1363 application-layer dependencies and interaction, and (3) obtaining the 1364 generic SNI to bootstrap the connection. In contrast, encrypted SNI 1365 induces no additional round trip and operates below the application 1366 layer. 1368 Appendix B. Total Client Hello Encryption 1370 The design described here only provides encryption for the SNI, but 1371 not for other extensions, such as ALPN. Another potential design 1372 would be to encrypt all of the extensions using the same basic 1373 structure as we use here for ECH. That design has the following 1374 advantages: 1376 * It protects all the extensions from ordinary eavesdroppers 1377 * If the encrypted block has its own KeyShare, it does not 1378 necessarily require the client to use a single KeyShare, because 1379 the client's share is bound to the SNI by the AEAD (analysis 1380 needed). 1382 It also has the following disadvantages: 1384 * The client-facing server can still see the other extensions. By 1385 contrast we could introduce another EncryptedExtensions block that 1386 was encrypted to the backend server and not the client-facing 1387 server. 1389 * It requires a mechanism for the client-facing server to provide 1390 the extension-encryption key to the backend server and thus cannot 1391 be used with an unmodified backend server. 1393 * A conforming middlebox will strip every extension, which might 1394 result in a ClientHello which is just unacceptable to the server 1395 (more analysis needed). 1397 Appendix C. Acknowledgements 1399 This document draws extensively from ideas in 1400 [I-D.kazuho-protected-sni], but is a much more limited mechanism 1401 because it depends on the DNS for the protection of the ECH key. 1402 Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, 1403 Nick Sullivan, Martin Thomson, and David Benjamin also provided 1404 important ideas and contributions. 1406 Authors' Addresses 1408 Eric Rescorla 1409 RTFM, Inc. 1411 Email: ekr@rtfm.com 1413 Kazuho Oku 1414 Fastly 1416 Email: kazuhooku@gmail.com 1418 Nick Sullivan 1419 Cloudflare 1421 Email: nick@cloudflare.com 1422 Christopher A. Wood 1423 Cloudflare 1425 Email: caw@heapingbits.net