idnits 2.17.1 draft-ietf-tls-esni-04.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 are 9 instances of too long lines in the document, the longest one being 36 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the server sends a HelloRetryRequest in response to the ClientHello and the client can send a second updated ClientHello per the rules in [RFC8446], the "encrypted_server_name" extension values which do not depend on the (possibly updated) KeyShareClientHello, i.e,, ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share, and ClientEncryptedSNI.record_digest, MUST NOT change across ClientHello messages. Moreover, ClientESNIInner MUST not change across ClientHello messages. Informally, the values of all unencrypted extension information, as well as the inner extension plaintext, must be consistent between the first and second ClientHello messages. -- The document date (July 08, 2019) is 1748 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 382 -- Looks like a reference, but probably isn't: '16' on line 562 == Unused Reference: 'RFC6234' is defined on line 1151, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-09 ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-04) exists of draft-ietf-tls-grease-02 == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-04 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Experimental K. Oku 5 Expires: January 9, 2020 Fastly 6 N. Sullivan 7 Cloudflare 8 C. Wood 9 Apple, Inc. 10 July 08, 2019 12 Encrypted Server Name Indication for TLS 1.3 13 draft-ietf-tls-esni-04 15 Abstract 17 This document defines a simple mechanism for encrypting the Server 18 Name Indication for TLS 1.3. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 9, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. SNI Encryption . . . . . . . . . . . . . . . . . . . . . 5 59 4. Publishing the SNI Encryption Key in the DNS . . . . . . . . 5 60 4.1. Encrypted SNI Record . . . . . . . . . . . . . . . . . . 6 61 4.2. Encrypted SNI DNS Resolution . . . . . . . . . . . . . . 8 62 4.2.1. Address Set Extension . . . . . . . . . . . . . . . . 8 63 4.2.2. Resolution Algorithm . . . . . . . . . . . . . . . . 9 64 5. The "encrypted_server_name" extension . . . . . . . . . . . . 10 65 5.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 11 66 5.1.1. Sending an encrypted SNI . . . . . . . . . . . . . . 11 67 5.1.2. Handling the server response . . . . . . . . . . . . 14 68 5.1.3. Authenticating for the public name . . . . . . . . . 15 69 5.1.4. GREASE extensions . . . . . . . . . . . . . . . . . . 16 70 5.2. Client-Facing Server Behavior . . . . . . . . . . . . . . 17 71 5.3. Shared Mode Server Behavior . . . . . . . . . . . . . . . 19 72 5.4. Split Mode Server Behavior . . . . . . . . . . . . . . . 19 73 6. Compatibility Issues . . . . . . . . . . . . . . . . . . . . 20 74 6.1. Misconfiguration and Deployment Concerns . . . . . . . . 20 75 6.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 20 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 77 7.1. Why is cleartext DNS OK? . . . . . . . . . . . . . . . . 21 78 7.2. Optional Record Digests and Trial Decryption . . . . . . 21 79 7.3. Encrypting other Extensions . . . . . . . . . . . . . . . 22 80 7.4. Related Privacy Leaks . . . . . . . . . . . . . . . . . . 22 81 7.5. Comparison Against Criteria . . . . . . . . . . . . . . . 22 82 7.5.1. Mitigate against replay attacks . . . . . . . . . . . 22 83 7.5.2. Avoid widely-deployed shared secrets . . . . . . . . 23 84 7.5.3. Prevent SNI-based DoS attacks . . . . . . . . . . . . 23 85 7.5.4. Do not stick out . . . . . . . . . . . . . . . . . . 23 86 7.5.5. Forward secrecy . . . . . . . . . . . . . . . . . . . 23 87 7.5.6. Proper security context . . . . . . . . . . . . . . . 23 88 7.5.7. Split server spoofing . . . . . . . . . . . . . . . . 24 89 7.5.8. Supporting multiple protocols . . . . . . . . . . . . 24 90 7.6. Misrouting . . . . . . . . . . . . . . . . . . . . . . . 24 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 8.1. Update of the TLS ExtensionType Registry . . . . . . . . 24 93 8.2. Update of the TLS Alert Registry . . . . . . . . . . . . 24 94 8.3. Update of the Resource Record (RR) TYPEs Registry . . . . 25 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 97 9.2. Informative References . . . . . . . . . . . . . . . . . 26 98 Appendix A. Communicating SNI and Nonce to Backend Server . . . 27 99 Appendix B. Alternative SNI Protection Designs . . . . . . . . . 27 100 B.1. TLS-layer . . . . . . . . . . . . . . . . . . . . . . . . 27 101 B.1.1. TLS in Early Data . . . . . . . . . . . . . . . . . . 27 102 B.1.2. Combined Tickets . . . . . . . . . . . . . . . . . . 28 103 B.2. Application-layer . . . . . . . . . . . . . . . . . . . . 28 104 B.2.1. HTTP/2 CERTIFICATE Frames . . . . . . . . . . . . . . 28 105 Appendix C. Total Client Hello Encryption . . . . . . . . . . . 28 106 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 29 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 other channels that allow 117 an on-path attacker to determine the domain name the client is trying 118 to connect to, including: 120 o Cleartext client DNS queries. 122 o Visible server IP addresses, assuming the the server is not doing 123 domain-based virtual hosting. 125 o Cleartext Server Name Indication (SNI) [RFC6066] in ClientHello 126 messages. 128 DoH [I-D.ietf-doh-dns-over-https] and DPRIVE [RFC7858] [RFC8094] 129 provide mechanisms for clients to conceal DNS lookups from network 130 inspection, and many TLS servers host multiple domains on the same IP 131 address. In such environments, SNI is an explicit signal used to 132 determine the server's identity. Indirect mechanisms such as traffic 133 analysis also exist. 135 The TLS WG has extensively studied the problem of protecting SNI, but 136 has been unable to develop a completely generic solution. 137 [I-D.ietf-tls-sni-encryption] provides a description of the problem 138 space and some of the proposed techniques. One of the more difficult 139 problems is "Do not stick out" ([I-D.ietf-tls-sni-encryption]; 140 Section 3.4): if only sensitive/private services use SNI encryption, 141 then SNI encryption is a signal that a client is going to such a 142 service. For this reason, much recent work has focused on concealing 143 the fact that SNI is being protected. Unfortunately, the result 144 often has undesirable performance consequences, incomplete coverage, 145 or both. 147 The design in this document takes a different approach: it assumes 148 that private origins will co-locate with or hide behind a provider 149 (CDN, app server, etc.) which is able to activate encrypted SNI 150 (ESNI) for all of the domains it hosts. Thus, the use of encrypted 151 SNI does not indicate that the client is attempting to reach a 152 private origin, but only that it is going to a particular service 153 provider, which the observer could already tell from the IP address. 155 2. Conventions and Definitions 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119] [RFC8174] when, and only when, they appear in all 161 capitals, as shown here. All TLS notation comes from [RFC8446]; 162 Section 3. 164 3. Overview 166 This document is designed to operate in one of two primary topologies 167 shown below, which we call "Shared Mode" and "Split Mode" 169 3.1. Topologies 171 +---------------------+ 172 | | 173 | 2001:DB8::1111 | 174 | | 175 Client <-----> | private.example.org | 176 | | 177 | public.example.com | 178 | | 179 +---------------------+ 180 Server 182 Figure 1: Shared Mode Topology 184 In Shared Mode, the provider is the origin server for all the domains 185 whose DNS records point to it and clients form a TLS connection 186 directly to that provider, which has access to the plaintext of the 187 connection. 189 +--------------------+ +---------------------+ 190 | | | | 191 | 2001:DB8::1111 | | 2001:DB8::EEEE | 192 Client <------------------------------------>| | 193 | public.example.com | | private.example.com | 194 | | | | 195 +--------------------+ +---------------------+ 196 Client-Facing Server Backend Server 198 Figure 2: Split Mode Topology 200 In Split Mode, the provider is _not_ the origin server for private 201 domains. Rather the DNS records for private domains point to the 202 provider, but the provider's server just relays the connection back 203 to the backend server, which is the true origin server. The provider 204 does not have access to the plaintext of the connection. In 205 principle, the provider might not be the origin for any domains, but 206 as a practical matter, it is probably the origin for a large set of 207 innocuous domains, but is also providing protection for some private 208 domains. Note that the backend server can be an unmodified TLS 1.3 209 server. 211 3.2. SNI Encryption 213 First, the provider publishes a public key and metadata which is used 214 for SNI encryption for all the domains for which it serves directly 215 or indirectly (via Split Mode). This document defines a publication 216 mechanism using DNS, but other mechanisms are also possible. In 217 particular, if some of the clients of a private server are 218 applications rather than Web browsers, those applications might have 219 the public key and metadata preconfigured. 221 When a client wants to form a TLS connection to any of the domains 222 served by an ESNI-supporting provider, it sends an 223 "encrypted_server_name" extension, which contains the true extension 224 encrypted under the provider's public key. The provider can then 225 decrypt the extension and either terminate the connection (in Shared 226 Mode) or forward it to the backend server (in Split Mode). 228 4. Publishing the SNI Encryption Key in the DNS 230 Publishing ESNI keys in the DNS requires care to ensure correct 231 behavior. There are deployment environments in which a domain is 232 served by multiple server operators who do not manage the ESNI keys. 233 Because ESNI and A/AAAA lookups are independent, it is therefore 234 possible to obtain an ESNI record which does not match the A/AAAA 235 records. (That is, the host to which an A or AAAA record refers is 236 not in possession of the ESNI keys.) The design of the system must 237 therefore allow clients to detect and recover from this situation 238 (see Section 4.2 for more details). 240 Content providers operating in Split Mode SHOULD ensure that the A 241 and AAAA records for ESNI-enabled server names do not allow 242 identifying the server name from the IP address. This can for 243 example be achieved by always returning the same records for all 244 ESNI-enabled names, or by having the function that picks addresses 245 from a pool not depend on the server name. This yields an anonymity 246 set of cardinality equal to the number of ESNI-enabled server domains 247 supported by a given client-facing server. Thus, even with SNI 248 encryption, an attacker which can enumerate the set of ESNI-enabled 249 domains supported by a client-facing server can guess the correct SNI 250 with probability at least 1/K, where K is the size of this ESNI- 251 enabled server anonymity set. This probability may be increased via 252 traffic analysis or other mechanisms. 254 The following sections describe a DNS record format that achieve 255 these goals. 257 4.1. Encrypted SNI Record 259 SNI Encryption keys can be published using the following ESNIRecord 260 structure. 262 // Copied from TLS 1.3 263 struct { 264 NamedGroup group; 265 opaque key_exchange<1..2^16-1>; 266 } KeyShareEntry; 268 struct { 269 uint16 version; 270 opaque public_name<1..2^16-1>; 271 KeyShareEntry keys<4..2^16-1>; 272 CipherSuite cipher_suites<2..2^16-2>; 273 uint16 padded_length; 274 Extension extensions<0..2^16-1>; 275 } ESNIKeys; 277 struct { 278 ESNIKeys esni_keys; 279 Extension dns_extensions<0..2^16-1>; 280 } ESNIRecord; 282 The outermost ESNIRecord structure contains the following fields: 284 esni_keys An ESNIKeys structure that contains the actual keys used 285 to encrypt the SNI as well as some metadata related to those keys. 287 dns_extensions A list of extensions that the client can take into 288 consideration when resolving the target DNS name. The format is 289 defined in [RFC8446]; Section 4.2. The purpose of the field is to 290 provide room for additional features in the future. An extension 291 may be tagged as mandatory by using an extension type codepoint 292 with the high order bit set to 1. A client which receives a 293 mandatory extension they do not understand must reject the 294 ESNIRecord values. 296 The ESNIKeys structure contains the following fields: 298 version The version of the structure. For this specification, that 299 value SHALL be 0xff03. Clients MUST ignore any ESNIKeys structure 300 with a version they do not understand. [[NOTE: This means that 301 the RFC will presumably have a nonzero value.]] 303 public_name The non-empty name of the entity trusted to update these 304 encryption keys. This is used to repair misconfigurations, as 305 described in Section 5.1.2. 307 keys The list of keys which can be used by the client to encrypt the 308 SNI. Every key being listed MUST belong to a different group. 310 padded_length The length to pad the ServerNameList value to prior to 311 encryption. This value SHOULD be set to the largest ServerNameList 312 the server expects to support rounded up the nearest multiple of 16. 313 If the server supports arbitrary wildcard names, it SHOULD set this 314 value to 260. Clients SHOULD reject ESNIKeys as invalid if 315 padded_length is greater than 260. 317 extensions A list of extensions that the client can take into 318 consideration when generating a Client Hello message. The format 319 is defined in [RFC8446]; Section 4.2. The purpose of the field is 320 to provide room for additional features in the future. An 321 extension may be tagged as mandatory by using an extension type 322 codepoint with the high order bit set to 1. A client which 323 receives a mandatory extension they do not understand must reject 324 the ESNIRecord value. 326 Any of the listed keys in the ESNIKeys value may be used to encrypt 327 the SNI for the associated domain name. The cipher suite list is 328 orthogonal to the list of keys, so each key may be used with any 329 cipher suite. Clients MUST parse the extension list and check for 330 unsupported mandatory extensions. If an unsupported mandatory 331 extension is present, clients MUST reject the ESNIRecord value. 333 The ESNIRecord structure is placed in the RRData section of an ESNI 334 record as-is. Servers MAY supply multiple ESNIRecord values, with 335 ESNIKeys either of the same or of different versions. This allows a 336 server to support multiple versions at once. If the server does not 337 supply any ESNIRecord values with an ESNIKeys version known to the 338 client, then the client MUST behave as if no ESNI records were found. 340 The name of each ESNI record MUST match the query domain name or the 341 query domain name's canonicalized form. That is, if a client queries 342 example.com, the ESNI Resource Record might be: 344 example.com. 60S IN ESNI "..." "..." 346 In the event that ESNIKeys is corrupt in transit or otherwise 347 invalid, servers will initiate the retry mechanism described in 348 Section 5.2 and deliver valid ESNIKeys to clients. 350 Note that the length of the ESNIRecord structure MUST NOT exceed 2^16 351 - 1, as the RDLENGTH is only 16 bits [RFC1035]. 353 4.2. Encrypted SNI DNS Resolution 355 This section describes a client ESNI resolution algorithm using an 356 "address_set" extension for the ESNIRecord structure. Future 357 specifications may introduce new ESNIRecord extensions and 358 corresponding resolution algorithms. 360 4.2.1. Address Set Extension 362 ESNIRecord values MAY indicate one or more IP addresses for the 363 host(s) in possession of the private key corresponding to one of the 364 keys provided in the ESNIKeys structure, via the following mandatory 365 "address_set" extension: 367 enum { 368 address_set(0x1001), (65535) 369 } ExtensionType; 371 The body of this extension is encoded using the following structure. 373 enum { 374 address_v4(4), 375 address_v6(6), 376 } AddressType; 378 struct { 379 AddressType address_type; 380 select (address_type) { 381 case address_v4: { 382 opaque ipv4Address[4]; 383 } 384 case address_v6: { 385 opaque ipv6Address[16]; 386 } 387 } 388 } Address; 390 struct { 391 Address address_set<1..2^16-1>; 392 } AddressSet; 394 address_set A set of Address structures containing IPv4 or IPv6 395 addresses to hosts which have the corresponding private ESNI key. 397 This extension MUST NOT be placed in the ESNIKeys extensions field, 398 but only in the ESNIRecord dns_extensions field. 400 4.2.2. Resolution Algorithm 402 Clients obtain ESNI records by querying the DNS for ESNI-enabled 403 server domains. In cases where the domain of the A or AAAA records 404 being resolved do not match the SNI Server Name, such as when 405 [RFC7838] is being used, the alternate domain should be used for 406 querying the ESNI record. (See Section 2.3 of [RFC7838] for more 407 details.) 409 Clients SHOULD initiate ESNI queries in parallel alongside normal A 410 or AAAA queries to obtain address information in a timely manner in 411 the event that ESNI is available. The following algorithm describes 412 a procedure by which clients can process ESNI responses as they 413 arrive to produce addresses for ESNI-capable hosts. 415 1. If an ESNI response containing an ESNIRecord value with an "address_set" extension arrives before an A or 416 AAAA response, clients SHOULD initiate TLS with ESNI to the provided address(es). 418 2. If an A or AAAA response arrives before the ESNI response, clients SHOULD wait up 419 to CD milliseconds before initiating TLS to either address. (Clients may begin 420 TCP connections in this time. QUIC connections should wait.) If an ESNI 421 response with an "address_set" extension arrives in this time, clients SHOULD 422 initiate TLS with ESNI to the provided address(es). If an ESNI response 423 without an "address_set" extension arrives in this time, clients MAY initiate 424 TLS with ESNI to the address(es) in the A or AAAA response. If no ESNI response 425 arrives in this time, clients SHOULD initiate TLS without ESNI to the available address(es). 427 CD (Connection Delay) is a configurable parameter. The recommended 428 value is 50 milliseconds, as per the guidance in [RFC8305]. 430 5. The "encrypted_server_name" extension 432 The encrypted SNI is carried in an "encrypted_server_name" extension, 433 defined as follows: 435 enum { 436 encrypted_server_name(0xffce), (65535) 437 } ExtensionType; 439 For clients (in ClientHello), this extension contains the following 440 ClientEncryptedSNI structure: 442 struct { 443 CipherSuite suite; 444 KeyShareEntry key_share; 445 opaque record_digest<0..2^16-1>; 446 opaque encrypted_sni<0..2^16-1>; 447 } ClientEncryptedSNI; 449 suite The cipher suite used to encrypt the SNI. 451 key_share The KeyShareEntry carrying the client's public ephemeral 452 key shared used to derive the ESNI key. 454 record_digest A cryptographic hash of the ESNIKeys structure from 455 which the ESNI key was obtained, i.e., from the first byte of 456 "version" to the end of the structure. This hash is computed 457 using the hash function associated with "suite". 459 encrypted_sni The ClientESNIInner structure, AEAD-encrypted using 460 cipher suite "suite" and the key generated as described below. 462 For servers (in EncryptedExtensions), this extension contains the 463 following structure: 465 enum { 466 esni_accept(0), 467 esni_retry_request(1), 468 } ServerESNIResponseType; 470 struct { 471 ServerESNIResponseType response_type; 472 select (response_type) { 473 case esni_accept: uint8 nonce[16]; 474 case esni_retry_request: ESNIKeys retry_keys<1..2^16-1>; 475 } 476 } ServerEncryptedSNI; 478 response_type Indicates whether the server processed the client ESNI 479 extension. (See Section 5.1.2 and Section 5.2.} 481 nonce The contents of ClientESNIInner.nonce. (See Section 5.1.) 483 retry_keys One or more ESNIKeys structures containing the keys that 484 the client should use on subsequent connections to encrypt the 485 ClientESNIInner structure. 487 This protocol also defines the "esni_required" alert, which is sent 488 by the client when it offered an "encrypted_server_name" extension 489 which was not accepted by the server. 491 enum { 492 esni_required(121), 493 } AlertDescription; 495 Finally, requirements in Section 5.1 and Section 5.2 require 496 implementations to track, alongside each PSK established by a 497 previous connection, whether the connection negotiated this extension 498 with the "esni_accept" response type. If so, this is referred to as 499 an "ESNI PSK". Otherwise, it is a "non-ESNI PSK". This may be 500 implemented by adding a new field to client and server session 501 states. 503 5.1. Client Behavior 505 5.1.1. Sending an encrypted SNI 507 In order to send an encrypted SNI, the client MUST first select one 508 of the server ESNIKeyShareEntry values and generate an (EC)DHE share 509 in the matching group. This share will then be sent to the server in 510 the "encrypted_sni" extension and used to derive the SNI encryption 511 key. It does not affect the (EC)DHE shared secret used in the TLS 512 key schedule. It MUST also select an appropriate cipher suite from 513 the list of suites offered by the server. If the client is unable to 514 select an appropriate group or suite it SHOULD ignore that ESNIKeys 515 value and MAY attempt to use another value provided by the server. 516 (Recall that servers might provide multiple ESNIRecord values in 517 response to a ESNI record query, each containing an ESNIKeys value.) 518 The client MUST NOT send encrypted SNI using groups or cipher suites 519 not advertised by the server. 521 When offering an encrypted SNI, the client MUST NOT offer to resume 522 any non-ESNI PSKs. It additionally MUST NOT offer to resume any 523 sessions for TLS 1.2 or below. 525 Let Z be the DH shared secret derived from a key share in ESNIKeys 526 and the corresponding client share in ClientEncryptedSNI.key_share. 527 The SNI encryption key is computed from Z as follows: 529 Zx = HKDF-Extract(0, Z) 530 key = HKDF-Expand-Label(Zx, KeyLabel, Hash(ESNIContents), key_length) 531 iv = HKDF-Expand-Label(Zx, IVLabel, Hash(ESNIContents), iv_length) 533 where ESNIContents is as specified below and Hash is the hash 534 function associated with the HKDF instantiation. The salt argument 535 for HKDF-Extract is a string consisting of Hash.length bytes set to 536 zeros. For a client's first ClientHello, KeyLabel = "esni key" and 537 IVLabel = "esni iv", whereas for a client's second ClientHello, sent 538 in response to a HelloRetryRequest, KeyLabel = "hrr esni key" and 539 IVLabel = "hrr esni iv". (This label variance is done to prevent 540 nonce re-use since the client's ESNI key share, and thus the value of 541 Zx, does not change across ClientHello retries.) 543 [[TODO: label swapping fixes a bug in the spec, though this may not 544 be the best way to deal with HRR. See https://github.com/tlswg/ 545 draft-ietf-tls-esni/issues/121 and https://github.com/tlswg/draft- 546 ietf-tls-esni/pull/170 for more details.]] 548 struct { 549 opaque record_digest<0..2^16-1>; 550 KeyShareEntry esni_key_share; 551 Random client_hello_random; 552 } ESNIContents; 554 The client then creates a ClientESNIInner structure: 556 struct { 557 opaque dns_name<1..2^16-1>; 558 opaque zeros[ESNIKeys.padded_length - length(sni)]; 559 } PaddedServerNameList; 561 struct { 562 uint8 nonce[16]; 563 PaddedServerNameList realSNI; 564 } ClientESNIInner; 566 nonce A random 16-octet value to be echoed by the server in the 567 "encrypted_server_name" extension. 569 dns_name The true SNI DNS name, that is, the HostName value that 570 would have been sent in the plaintext "server_name" extension. 571 (NameType values other than "host_name" are unsupported since SNI 572 extensibility failed [SNIExtensibilityFailed]). 574 zeros Zero padding whose length makes the serialized 575 PaddedServerNameList struct have a length equal to 576 ESNIKeys.padded_length. 578 This value consists of the serialized ServerNameList from the 579 "server_name" extension, padded with enough zeroes to make the total 580 structure ESNIKeys.padded_length bytes long. The purpose of the 581 padding is to prevent attackers from using the length of the 582 "encrypted_server_name" extension to determine the true SNI. If the 583 serialized ServerNameList is longer than ESNIKeys.padded_length, the 584 client MUST NOT use the "encrypted_server_name" extension. 586 The ClientEncryptedSNI.encrypted_sni value is then computed using the 587 usual TLS 1.3 AEAD: 589 encrypted_sni = AEAD-Encrypt(key, iv, KeyShareClientHello, ClientESNIInner) 591 Where KeyShareClientHello is the "extension_data" field of the 592 "key_share" extension in a Client Hello (Section 4.2.8 of 593 [RFC8446])). Including KeyShareClientHello in the AAD of AEAD- 594 Encrypt binds the ClientEncryptedSNI value to the ClientHello and 595 prevents cut-and-paste attacks. 597 Note: future extensions may end up reusing the server's 598 ESNIKeyShareEntry for other purposes within the same message (e.g., 599 encrypting other values). Those usages MUST have their own HKDF 600 labels to avoid reuse. 602 [[OPEN ISSUE: If in the future you were to reuse these keys for 0-RTT 603 priming, then you would have to worry about potentially expanding 604 twice of Z_extracted. We should think about how to harmonize these 605 to make sure that we maintain key separation.]] 607 This value is placed in an "encrypted_server_name" extension. 609 The client MUST place the value of ESNIKeys.public_name in the 610 "server_name" extension. (This is required for technical conformance 611 with [RFC7540]; Section 9.2.) The client MUST NOT send a 612 "cached_info" extension [RFC7924] with a CachedObject entry whose 613 CachedInformationType is "cert". 615 5.1.2. Handling the server response 617 If the server negotiates TLS 1.3 or above and provides an 618 "encrypted_server_name" extension in EncryptedExtensions, the client 619 then processes the extension's "response_type" field: 621 o If the value is "esni_accept", the client MUST check that the 622 extension's "nonce" field matches ClientESNIInner.nonce and 623 otherwise abort the connection with an "illegal_parameter" alert. 624 The client then proceeds with the connection as usual, 625 authenticating the connection for the origin server. 627 o If the value is "esni_retry_request", the client proceeds with the 628 handshake, authenticating for ESNIKeys.public_name as described in 629 Section 5.1.3. If authentication or the handshake fails, the 630 client MUST return a failure to the calling application. It MUST 631 NOT use the retry keys. 633 Otherwise, when the handshake completes successfully with the 634 public name authenticated, the client MUST abort the connection 635 with an "esni_required" alert. It then processes the "retry_keys" 636 field from the server's "encrypted_server_name" extension. 638 If one of the values contains a version supported by the client, 639 it can regard the ESNI keys as securely replaced by the server. 640 It SHOULD retry the handshake with a new transport connection, 641 using that value to encrypt the SNI. The value may only be 642 applied to the retry connection. The client MUST continue to use 643 the previously-advertised keys for subsequent connections. This 644 avoids introducing pinning concerns or a tracking vector, should a 645 malicious server present client-specific retry keys to identify 646 clients. 648 If none of the values provided in "retry_keys" contains a 649 supported version, the client can regard ESNI as securely disabled 650 by the server. As below, it SHOULD then retry the handshake with 651 a new transport connection and ESNI disabled. 653 o If the field contains any other value, the client MUST abort the 654 connection with an "illegal_parameter" alert. 656 If the server negotiates an earlier version of TLS, or if it does not 657 provide an "encrypted_server_name" extension in EncryptedExtensions, 658 the client proceeds with the handshake, authenticating for 659 ESNIKeys.public_name as described in Section 5.1.3. If an earlier 660 version was negotiated, the client MUST NOT enable the False Start 661 optimization [RFC7918] for this handshake. If authentication or the 662 handshake fails, the client MUST return a failure to the calling 663 application. It MUST NOT treat this as a secure signal to disable 664 ESNI. 666 Otherwise, when the handshake completes successfully with the public 667 name authenticated, the client MUST abort the connection with an 668 "esni_required" alert. The client can then regard ESNI as securely 669 disabled by the server. It SHOULD retry the handshake with a new 670 transport connection and ESNI disabled. 672 [[TODO: Key replacement is significantly less scary than saying that 673 ESNI-naive servers bounce ESNI off. Is it worth defining a strict 674 mode toggle in the ESNI keys, for a deployment to indicate it is 675 ready for that? ]] 677 Clients SHOULD implement a limit on retries caused by 678 "esni_retry_request" or servers which do not acknowledge the 679 "encrypted_server_name" extension. If the client does not retry in 680 either scenario, it MUST report an error to the calling application. 682 If the server sends a HelloRetryRequest in response to the 683 ClientHello and the client can send a second updated ClientHello per 684 the rules in [RFC8446], the "encrypted_server_name" extension values 685 which do not depend on the (possibly updated) KeyShareClientHello, 686 i.e,, ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share, and 687 ClientEncryptedSNI.record_digest, MUST NOT change across ClientHello 688 messages. Moreover, ClientESNIInner MUST not change across 689 ClientHello messages. Informally, the values of all unencrypted 690 extension information, as well as the inner extension plaintext, must 691 be consistent between the first and second ClientHello messages. 693 5.1.3. Authenticating for the public name 695 When the server cannot decrypt or does not process the 696 "encrypted_server_name" extension, it continues with the handshake 697 using the cleartext "server_name" extension instead (see 698 Section 5.2). Clients that offer ESNI then authenticate the 699 connection with the public name, as follows: 701 o If the server resumed a session or negotiated a session that did 702 not use a certificate for authentication, the client MUST abort 703 the connection with an "illegal_parameter" alert. This case is 704 invalid because Section 5.1.1 requires the client to only offer 705 ESNI-established sessions, and Section 5.2 requires the server to 706 decline ESNI-established sessions if it did not accept ESNI. 708 o The client MUST verify that the certificate is valid for 709 ESNIKeys.public_name. If invalid, it MUST abort the connection 710 with the appropriate alert. 712 o If the server requests a client certificate, the client MUST 713 respond with an empty Certificate message, denoting no client 714 certificate. 716 Note that authenticating a connection for the public name does not 717 authenticate it for the origin. The TLS implementation MUST NOT 718 report such connections as successful to the application. It 719 additionally MUST ignore all session tickets and session IDs 720 presented by the server. These connections are only used to trigger 721 retries, as described in Section 5.1.2. This may be implemented, for 722 instance, by reporting a failed connection with a dedicated error 723 code. 725 5.1.4. GREASE extensions 727 If the client attempts to connect to a server and does not have an 728 ESNIKeys structure available for the server, it SHOULD send a GREASE 729 [I-D.ietf-tls-grease] "encrypted_server_name" extension as follows: 731 o Select a supported cipher suite, named group, and padded_length 732 value. The padded_length value SHOULD be 260 or a multiple of 16 733 less than 735 1. Set the "suite" field to the selected cipher suite. These 736 selections SHOULD vary to exercise all supported 737 configurations, but MAY be held constant for successive 738 connections to the same server in the same session. 740 o Set the "key_share" field to a randomly-generated valid public key 741 for the named group. 743 o Set the "record_digest" field to a randomly-generated string of 744 hash_length bytes, where hash_length is the length of the hash 745 function associated with the chosen cipher suite. 747 o Set the "encrypted_sni" field to a randomly-generated string of 16 748 + padded_length + tag_length bytes, where tag_length is the tag 749 length of the chosen cipher suite's associated AEAD. 751 If the server sends an "encrypted_server_name" extension, the client 752 MUST check the extension syntactically and abort the connection with 753 a "decode_error" alert if it is invalid. If the "response_type" 754 field contains "esni_retry_requested", the client MUST ignore the 755 extension and proceed with the handshake. If it contains 756 "esni_accept" or any other value, the client MUST abort the 757 connection with an "illegal_parameter" alert. 759 Offering a GREASE extension is not considered offering an encrypted 760 SNI for purposes of requirements in Section 5.1. In particular, the 761 client MAY offer to resume sessions established without ESNI. 763 5.2. Client-Facing Server Behavior 765 Upon receiving an "encrypted_server_name" extension, the client- 766 facing server MUST check that it is able to negotiate TLS 1.3 or 767 greater. If not, it MUST abort the connection with a 768 "handshake_failure" alert. 770 The ClientEncryptedSNI value is said to match a known ESNIKeys if 771 there exists an ESNIKeys that can be used to successfully decrypt 772 ClientEncryptedSNI.encrypted_sni. This matching procedure should be 773 done using one of the following two checks: 775 1. Compare ClientEncryptedSNI.record_digest against cryptographic 776 hashes of known ESNIKeys and choose the one that matches. 778 2. Use trial decryption of ClientEncryptedSNI.encrypted_sni with 779 known ESNIKeys and choose the one that succeeds. 781 Some uses of ESNI, such as local discovery mode, may omit the 782 ClientEncryptedSNI.record_digest since it can be used as a tracking 783 vector. In such cases, trial decryption should be used for matching 784 ClientEncryptedSNI to known ESNIKeys. Unless specified by the 785 application using (D)TLS or externally configured on both sides, 786 implementations MUST use the first method. 788 If the ClientEncryptedSNI value does not match any known ESNIKeys 789 structure, it MUST ignore the extension and proceed with the 790 connection, with the following added behavior: 792 o It MUST include the "encrypted_server_name" extension in 793 EncryptedExtensions message with the "response_type" field set to 794 "esni_retry_requested" and the "retry_keys" field set to one or 795 more ESNIKeys structures with up-to-date keys. Servers MAY supply 796 multiple ESNIKeys values of different versions. This allows a 797 server to support multiple versions at once. 799 o The server MUST ignore all PSK identities in the ClientHello which 800 correspond to ESNI PSKs. ESNI PSKs offered by the client are 801 associated with the ESNI name. The server was unable to decrypt 802 then ESNI name, so it should not resume them when using the 803 cleartext SNI name. This restriction allows a client to reject 804 resumptions in Section 5.1.3. 806 Note that an unrecognized ClientEncryptedSNI.record_digest value may 807 be a GREASE ESNI extension (see Section 5.1.4), so it is necessary 808 for servers to proceed with the connection and rely on the client to 809 abort if ESNI was required. In particular, the unrecognized value 810 alone does not indicate a misconfigured ESNI advertisement 811 (Section 6.1). Instead, servers can measure occurrences of the 812 "esni_required" alert to detect this case. 814 If the ClientEncryptedSNI value does match a known ESNIKeys, the 815 server performs the following checks: 817 o If the ClientEncryptedSNI.key_share group does not match one in 818 the ESNIKeys.keys, it MUST abort the connection with an 819 "illegal_parameter" alert. 821 o If the length of the "encrypted_server_name" extension is 822 inconsistent with the advertised padding length (plus AEAD 823 expansion) the server MAY abort the connection with an 824 "illegal_parameter" alert without attempting to decrypt. 826 Assuming these checks succeed, the server then computes K_sni and 827 decrypts the ServerName value. If decryption fails, the server MUST 828 abort the connection with a "decrypt_error" alert. 830 If the decrypted value's length is different from the advertised 831 ESNIKeys.padded_length or the padding consists of any value other 832 than 0, then the server MUST abort the connection with an 833 "illegal_parameter" alert. Otherwise, the server uses the 834 PaddedServerNameList.sni value as if it were the "server_name" 835 extension. Any actual "server_name" extension is ignored, which also 836 means the server MUST NOT send the "server_name" extension to the 837 client. 839 Upon determining the true SNI, the client-facing server then either 840 serves the connection directly (if in Shared Mode), in which case it 841 executes the steps in the following section, or forwards the TLS 842 connection to the backend server (if in Split Mode). In the latter 843 case, it does not make any changes to the TLS messages, but just 844 blindly forwards them. 846 If the ClientHello is the result of a HelloRetryRequest, servers MUST 847 abort the connection with an "illegal_parameter" alert if any of the 848 ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share, 849 ClientEncryptedSNI.record_digest, or decrypted ClientESNIInner values 850 from the second ClientHello do not match that of the first 851 ClientHello. 853 5.3. Shared Mode Server Behavior 855 A server operating in Shared Mode uses PaddedServerNameList.sni as if 856 it were the "server_name" extension to finish the handshake. It 857 SHOULD pad the Certificate message, via padding at the record layer, 858 such that its length equals the size of the largest possible 859 Certificate (message) covered by the same ESNI key. Moreover, the 860 server MUST include the "encrypted_server_name" extension in 861 EncryptedExtensions with the "response_type" field set to 862 "esni_accept" and the "nonce" field set to the decrypted 863 PaddedServerNameList.nonce value from the client 864 "encrypted_server_name" extension. 866 If the server sends a NewSessionTicket message, the corresponding 867 ESNI PSK MUST be ignored by all other servers in the deployment when 868 not negotiating ESNI, including servers which do not implement this 869 specification. 871 This restriction provides robustness for rollbacks (see Section 6.1). 873 5.4. Split Mode Server Behavior 875 In Split Mode, the backend server must know 876 PaddedServerNameList.nonce to echo it back in EncryptedExtensions and 877 complete the handshake. Appendix A describes one mechanism for 878 sending both PaddedServerNameList.sni and ClientESNIInner.nonce to 879 the backend server. Thus, backend servers function the same as 880 servers operating in Shared Mode. 882 As in Shared Mode, if the backend server sends a NewSessionTicket 883 message, the corresponding ESNI PSK MUST be ignored by other servers 884 in the deployment when not negotiating ESNI, including servers which 885 do not implement this specification. 887 6. Compatibility Issues 889 Unlike most TLS extensions, placing the SNI value in an ESNI 890 extension is not interoperable with existing servers, which expect 891 the value in the existing cleartext extension. Thus server operators 892 SHOULD ensure servers understand a given set of ESNI keys before 893 advertising them. Additionally, servers SHOULD retain support for 894 any previously-advertised keys for the duration of their validity. 896 However, in more complex deployment scenarios, this may be difficult 897 to fully guarantee. Thus this protocol was designed to be robust in 898 case of inconsistencies between systems that advertise ESNI keys and 899 servers, at the cost of extra round-trips due to a retry. Two 900 specific scenarios are detailed below. 902 6.1. Misconfiguration and Deployment Concerns 904 It is possible for ESNI advertisements and servers to become 905 inconsistent. This may occur, for instance, from DNS 906 misconfiguration, caching issues, or an incomplete rollout in a 907 multi-server deployment. This may also occur if a server loses its 908 ESNI keys, or if a deployment of ESNI must be rolled back on the 909 server. 911 The retry mechanism repairs inconsistencies, provided the server is 912 authoritative for the public name. If server and advertised keys 913 mismatch, the server will respond with esni_retry_requested. If the 914 server does not understand the "encrypted_server_name" extension at 915 all, it will ignore it as required by [RFC8446]; Section 4.1.2. 916 Provided the server can present a certificate valid for the public 917 name, the client can safely retry with updated settings, as described 918 in Section 5.1.2. 920 Unless ESNI is disabled as a result of successfully establishing a 921 connection to the public name, the client MUST NOT fall back to 922 cleartext SNI, as this allows a network attacker to disclose the SNI. 923 It MAY attempt to use another server from the DNS results, if one is 924 provided. 926 6.2. Middleboxes 928 A more serious problem is MITM proxies which do not support this 929 extension. [RFC8446]; Section 9.3 requires that such proxies remove 930 any extensions they do not understand. The handshake will then 931 present a certificate based on the public name, without echoing the 932 "encrypted_server_name" extension to the client. 934 Depending on whether the client is configured to accept the proxy's 935 certificate as authoritative for the public name, this may trigger 936 the retry logic described in Section 5.1.2 or result in a connection 937 failure. A proxy which is not authoritative for the public name 938 cannot forge a signal to disable ESNI. 940 A non-conformant MITM proxy which instead forwards the ESNI 941 extension, substituting its own KeyShare value, will result in the 942 client-facing server recognizing the key, but failing to decrypt the 943 SNI. This causes a hard failure. Clients SHOULD NOT attempt to 944 repair the connection in this case. 946 7. Security Considerations 948 7.1. Why is cleartext DNS OK? 950 In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource 951 Records are signed via a server private key, ESNI records have no 952 authenticity or provenance information. This means that any attacker 953 which can inject DNS responses or poison DNS caches, which is a 954 common scenario in client access networks, can supply clients with 955 fake ESNI records (so that the client encrypts SNI to them) or strip 956 the ESNI record from the response. However, in the face of an 957 attacker that controls DNS, no SNI encryption scheme can work because 958 the attacker can replace the IP address, thus blocking client 959 connections, or substituting a unique IP address which is 1:1 with 960 the DNS name that was looked up (modulo DNS wildcards). Thus, 961 allowing the ESNI records in the clear does not make the situation 962 significantly worse. 964 Clearly, DNSSEC (if the client validates and hard fails) is a defense 965 against this form of attack, but DoH/DPRIVE are also defenses against 966 DNS attacks by attackers on the local network, which is a common case 967 where SNI is desired. Moreover, as noted in the introduction, SNI 968 encryption is less useful without encryption of DNS queries in 969 transit via DoH or DPRIVE mechanisms. 971 7.2. Optional Record Digests and Trial Decryption 973 Supporting optional record digests and trial decryption opens oneself 974 up to DoS attacks. Specifically, an adversary may send malicious 975 ClientHello messages, i.e., those which will not decrypt with any 976 known ESNI key, in order to force decryption. Servers that support 977 this feature should, for example, implement some form of rate 978 limiting mechanism to limit the damage caused by such attacks. 980 7.3. Encrypting other Extensions 982 ESNI protects only the SNI in transit. Other ClientHello extensions, 983 such as ALPN, might also reveal privacy-sensitive information to the 984 network. As such, it might be desirable to encrypt other extensions 985 alongside the SNI. However, the SNI extension is unique in that non- 986 TLS-terminating servers or load balancers may act on its contents. 987 Thus, using keys specifically for SNI encryption promotes key 988 separation between client-facing servers and endpoints party to TLS 989 connections. Moreover, the ESNI design described herein does not 990 preclude a mechanism for generic ClientHello extension encryption. 992 7.4. Related Privacy Leaks 994 ESNI requires encrypted DNS to be an effective privacy protection 995 mechanism. However, verifying the server's identity from the 996 Certificate message, particularly when using the X509 997 CertificateType, may result in additional network traffic that may 998 reveal the server identity. Examples of this traffic may include 999 requests for revocation information, such as OCSP or CRL traffic, or 1000 requests for repository information, such as 1001 authorityInformationAccess. It may also include implementation- 1002 specific traffic for additional information sources as part of 1003 verification. 1005 Implementations SHOULD avoid leaking information that may identify 1006 the server. Even when sent over an encrypted transport, such 1007 requests may result in indirect exposure of the server's identity, 1008 such as indicating a specific CA or service being used. To mitigate 1009 this risk, servers SHOULD deliver such information in-band when 1010 possible, such as through the use of OCSP stapling, and clients 1011 SHOULD take steps to minimize or protect such requests during 1012 certificate validation. 1014 7.5. Comparison Against Criteria 1016 [I-D.ietf-tls-sni-encryption] lists several requirements for SNI 1017 encryption. In this section, we re-iterate these requirements and 1018 assess the ESNI design against them. 1020 7.5.1. Mitigate against replay attacks 1022 Since the SNI encryption key is derived from a (EC)DH operation 1023 between the client's ephemeral and server's semi-static ESNI key, the 1024 ESNI encryption is bound to the Client Hello. It is not possible for 1025 an attacker to "cut and paste" the ESNI value in a different Client 1026 Hello, with a different ephemeral key share, as the terminating 1027 server will fail to decrypt and verify the ESNI value. 1029 7.5.2. Avoid widely-deployed shared secrets 1031 This design depends upon DNS as a vehicle for semi-static public key 1032 distribution. Server operators may partition their private keys 1033 however they see fit provided each server behind an IP address has 1034 the corresponding private key to decrypt a key. Thus, when one ESNI 1035 key is provided, sharing is optimally bound by the number of hosts 1036 that share an IP address. Server operators may further limit sharing 1037 by sending different Resource Records containing ESNIRecord and 1038 ESNIKeys values with different keys using a short TTL. 1040 7.5.3. Prevent SNI-based DoS attacks 1042 This design requires servers to decrypt ClientHello messages with 1043 ClientEncryptedSNI extensions carrying valid digests. Thus, it is 1044 possible for an attacker to force decryption operations on the 1045 server. This attack is bound by the number of valid TCP connections 1046 an attacker can open. 1048 7.5.4. Do not stick out 1050 As more clients enable ESNI support, e.g., as normal part of Web 1051 browser functionality, with keys supplied by shared hosting 1052 providers, the presence of ESNI extensions becomes less suspicious 1053 and part of common or predictable client behavior. In other words, 1054 if all Web browsers start using ESNI, the presence of this value does 1055 not signal suspicious behavior to passive eavesdroppers. 1057 Additionally, this specification allows for clients to send GREASE 1058 ESNI extensions (see Section 5.1.4), which helps ensure the ecosystem 1059 handles the values correctly. 1061 7.5.5. Forward secrecy 1063 This design is not forward secret because the server's ESNI key is 1064 static. However, the window of exposure is bound by the key 1065 lifetime. It is RECOMMENDED that servers rotate keys frequently. 1067 7.5.6. Proper security context 1069 This design permits servers operating in Split Mode to forward 1070 connections directly to backend origin servers, thereby avoiding 1071 unnecessary MiTM attacks. 1073 7.5.7. Split server spoofing 1075 Assuming ESNI records retrieved from DNS are validated, e.g., via 1076 DNSSEC or fetched from a trusted Recursive Resolver, spoofing a 1077 server operating in Split Mode is not possible. See Section 7.1 for 1078 more details regarding cleartext DNS. 1080 Validating the ESNIKeys structure additionally validates the public 1081 name. This validates any retry signals from the server because the 1082 client validates the server certificate against the public name 1083 before retrying. 1085 7.5.8. Supporting multiple protocols 1087 This design has no impact on application layer protocol negotiation. 1088 It may affect connection routing, server certificate selection, and 1089 client certificate verification. Thus, it is compatible with 1090 multiple protocols. 1092 7.6. Misrouting 1094 Note that the backend server has no way of knowing what the SNI was, 1095 but that does not lead to additional privacy exposure because the 1096 backend server also only has one identity. This does, however, 1097 change the situation slightly in that the backend server might 1098 previously have checked SNI and now cannot (and an attacker can route 1099 a connection with an encrypted SNI to any backend server and the TLS 1100 connection will still complete). However, the client is still 1101 responsible for verifying the server's identity in its certificate. 1103 [[TODO: Some more analysis needed in this case, as it is a little 1104 odd, and probably some precise rules about handling ESNI and no SNI 1105 uniformly?]] 1107 8. IANA Considerations 1109 8.1. Update of the TLS ExtensionType Registry 1111 IANA is requested to create an entry, encrypted_server_name(0xffce), 1112 in the existing registry for ExtensionType (defined in [RFC8446]), 1113 with "TLS 1.3" column values being set to "CH, EE", and "Recommended" 1114 column being set to "Yes". 1116 8.2. Update of the TLS Alert Registry 1118 IANA is requested to create an entry, esni_required(121) in the 1119 existing registry for Alerts (defined in [RFC8446]), with the "DTLS- 1120 OK" column being set to "Y". 1122 8.3. Update of the Resource Record (RR) TYPEs Registry 1124 IANA is requested to create an entry, ESNI(0xff9f), in the existing 1125 registry for Resource Record (RR) TYPEs (defined in [RFC6895]) with 1126 "Meaning" column value being set to "Encrypted SNI". 1128 9. References 1130 9.1. Normative References 1132 [I-D.ietf-tls-exported-authenticator] 1133 Sullivan, N., "Exported Authenticators in TLS", draft- 1134 ietf-tls-exported-authenticator-09 (work in progress), May 1135 2019. 1137 [RFC1035] Mockapetris, P., "Domain names - implementation and 1138 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1139 November 1987, . 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, 1143 DOI 10.17487/RFC2119, March 1997, 1144 . 1146 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1147 Extensions: Extension Definitions", RFC 6066, 1148 DOI 10.17487/RFC6066, January 2011, 1149 . 1151 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1152 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1153 DOI 10.17487/RFC6234, May 2011, 1154 . 1156 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1157 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1158 April 2013, . 1160 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1161 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1162 DOI 10.17487/RFC7540, May 2015, 1163 . 1165 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1166 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1167 April 2016, . 1169 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 1170 Layer Security (TLS) False Start", RFC 7918, 1171 DOI 10.17487/RFC7918, August 2016, 1172 . 1174 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1175 (TLS) Cached Information Extension", RFC 7924, 1176 DOI 10.17487/RFC7924, July 2016, 1177 . 1179 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1180 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1181 May 2017, . 1183 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1184 Better Connectivity Using Concurrency", RFC 8305, 1185 DOI 10.17487/RFC8305, December 2017, 1186 . 1188 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1189 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1190 . 1192 9.2. Informative References 1194 [I-D.ietf-doh-dns-over-https] 1195 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1196 (DoH)", draft-ietf-doh-dns-over-https-14 (work in 1197 progress), August 2018. 1199 [I-D.ietf-tls-grease] 1200 Benjamin, D., "Applying GREASE to TLS Extensibility", 1201 draft-ietf-tls-grease-02 (work in progress), January 2019. 1203 [I-D.ietf-tls-sni-encryption] 1204 Huitema, C. and E. Rescorla, "Issues and Requirements for 1205 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-04 1206 (work in progress), November 2018. 1208 [I-D.kazuho-protected-sni] 1209 Oku, K., "TLS Extensions for Protecting SNI", draft- 1210 kazuho-protected-sni-00 (work in progress), July 2017. 1212 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1213 and P. Hoffman, "Specification for DNS over Transport 1214 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1215 2016, . 1217 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1218 Transport Layer Security (DTLS)", RFC 8094, 1219 DOI 10.17487/RFC8094, February 2017, 1220 . 1222 [SNIExtensibilityFailed] 1223 "Accepting that other SNI name types will never work", 1224 n.d., . 1227 Appendix A. Communicating SNI and Nonce to Backend Server 1229 When operating in Split Mode, backend servers will not have access to 1230 PaddedServerNameList.sni or ClientESNIInner.nonce without access to 1231 the ESNI keys or a way to decrypt ClientEncryptedSNI.encrypted_sni. 1233 One way to address this for a single connection, at the cost of 1234 having communication not be unmodified TLS 1.3, is as follows. 1235 Assume there is a shared (symmetric) key between the client-facing 1236 server and the backend server and use it to AEAD-encrypt Z and send 1237 the encrypted blob at the beginning of the connection before the 1238 ClientHello. The backend server can then decrypt ESNI to recover the 1239 true SNI and nonce. 1241 Another way for backend servers to access the true SNI and nonce is 1242 by the client-facing server sharing the ESNI keys. 1244 Appendix B. Alternative SNI Protection Designs 1246 Alternative approaches to encrypted SNI may be implemented at the TLS 1247 or application layer. In this section we describe several 1248 alternatives and discuss drawbacks in comparison to the design in 1249 this document. 1251 B.1. TLS-layer 1253 B.1.1. TLS in Early Data 1255 In this variant, TLS Client Hellos are tunneled within early data 1256 payloads belonging to outer TLS connections established with the 1257 client-facing server. This requires clients to have established a 1258 previous session --- and obtained PSKs --- with the server. The 1259 client-facing server decrypts early data payloads to uncover Client 1260 Hellos destined for the backend server, and forwards them onwards as 1261 necessary. Afterwards, all records to and from backend servers are 1262 forwarded by the client-facing server - unmodified. This avoids 1263 double encryption of TLS records. 1265 Problems with this approach are: (1) servers may not always be able 1266 to distinguish inner Client Hellos from legitimate application data, 1267 (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may 1268 not be supported - especially under DoS - leading to availability 1269 concerns, and (4) clients must bootstrap tunnels (sessions), costing 1270 an additional round trip and potentially revealing the SNI during the 1271 initial connection. In contrast, encrypted SNI protects the SNI in a 1272 distinct Client Hello extension and neither abuses early data nor 1273 requires a bootstrapping connection. 1275 B.1.2. Combined Tickets 1277 In this variant, client-facing and backend servers coordinate to 1278 produce "combined tickets" that are consumable by both. Clients 1279 offer combined tickets to client-facing servers. The latter parse 1280 them to determine the correct backend server to which the Client 1281 Hello should be forwarded. This approach is problematic due to non- 1282 trivial coordination between client-facing and backend servers for 1283 ticket construction and consumption. Moreover, it requires a 1284 bootstrapping step similar to that of the previous variant. In 1285 contrast, encrypted SNI requires no such coordination. 1287 B.2. Application-layer 1289 B.2.1. HTTP/2 CERTIFICATE Frames 1291 In this variant, clients request secondary certificates with 1292 CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. 1293 In response, servers supply certificates via TLS exported 1294 authenticators [I-D.ietf-tls-exported-authenticator] in CERTIFICATE 1295 frames. Clients use a generic SNI for the underlying client-facing 1296 server TLS connection. Problems with this approach include: (1) one 1297 additional round trip before peer authentication, (2) non-trivial 1298 application-layer dependencies and interaction, and (3) obtaining the 1299 generic SNI to bootstrap the connection. In contrast, encrypted SNI 1300 induces no additional round trip and operates below the application 1301 layer. 1303 Appendix C. Total Client Hello Encryption 1305 The design described here only provides encryption for the SNI, but 1306 not for other extensions, such as ALPN. Another potential design 1307 would be to encrypt all of the extensions using the same basic 1308 structure as we use here for ESNI. That design has the following 1309 advantages: 1311 o It protects all the extensions from ordinary eavesdroppers 1312 o If the encrypted block has its own KeyShare, it does not 1313 necessarily require the client to use a single KeyShare, because 1314 the client's share is bound to the SNI by the AEAD (analysis 1315 needed). 1317 It also has the following disadvantages: 1319 o The client-facing server can still see the other extensions. By 1320 contrast we could introduce another EncryptedExtensions block that 1321 was encrypted to the backend server and not the client-facing 1322 server. 1324 o It requires a mechanism for the client-facing server to provide 1325 the extension-encryption key to the backend server (as in 1326 Appendix A and thus cannot be used with an unmodified backend 1327 server. 1329 o A conformant middlebox will strip every extension, which might 1330 result in a ClientHello which is just unacceptable to the server 1331 (more analysis needed). 1333 Appendix D. Acknowledgements 1335 This document draws extensively from ideas in 1336 [I-D.kazuho-protected-sni], but is a much more limited mechanism 1337 because it depends on the DNS for the protection of the ESNI key. 1338 Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, 1339 Nick Sullivan, Martin Thomson, and David Benjamin also provided 1340 important ideas and contributions. 1342 Authors' Addresses 1344 Eric Rescorla 1345 RTFM, Inc. 1347 Email: ekr@rtfm.com 1349 Kazuho Oku 1350 Fastly 1352 Email: kazuhooku@gmail.com 1354 Nick Sullivan 1355 Cloudflare 1357 Email: nick@cloudflare.com 1358 Christopher A. Wood 1359 Apple, Inc. 1361 Email: cawood@apple.com