idnits 2.17.1 draft-ietf-tls-esni-02.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 2 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2014 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 236 -- Looks like a reference, but probably isn't: '16' on line 428 == Outdated reference: A later version (-16) exists of draft-ietf-dnsop-attrleaf-14 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-08 ** Obsolete normative reference: RFC 4408 (Obsoleted by RFC 7208) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-03 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Experimental K. Oku 5 Expires: April 25, 2019 Fastly 6 N. Sullivan 7 Cloudflare 8 C. Wood 9 Apple, Inc. 10 October 22, 2018 12 Encrypted Server Name Indication for TLS 1.3 13 draft-ietf-tls-esni-02 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 http://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 April 25, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 (http://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 . . . . . . . . . . . . . . 5 60 5. The "encrypted_server_name" extension . . . . . . . . . . . . 8 61 5.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 9 62 5.2. Client-Facing Server Behavior . . . . . . . . . . . . . . 11 63 5.3. Shared Mode Server Behavior . . . . . . . . . . . . . . . 12 64 5.4. Split Mode Server Behavior . . . . . . . . . . . . . . . 12 65 6. Compatibility Issues . . . . . . . . . . . . . . . . . . . . 12 66 6.1. Misconfiguration . . . . . . . . . . . . . . . . . . . . 12 67 6.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 13 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 7.1. Why is cleartext DNS OK? . . . . . . . . . . . . . . . . 13 70 7.2. Comparison Against Criteria . . . . . . . . . . . . . . . 14 71 7.2.1. Mitigate against replay attacks . . . . . . . . . . . 14 72 7.2.2. Avoid widely-deployed shared secrets . . . . . . . . 14 73 7.2.3. Prevent SNI-based DoS attacks . . . . . . . . . . . . 14 74 7.2.4. Do not stick out . . . . . . . . . . . . . . . . . . 14 75 7.2.5. Forward secrecy . . . . . . . . . . . . . . . . . . . 15 76 7.2.6. Proper security context . . . . . . . . . . . . . . . 15 77 7.2.7. Split server spoofing . . . . . . . . . . . . . . . . 15 78 7.2.8. Supporting multiple protocols . . . . . . . . . . . . 15 79 7.3. Misrouting . . . . . . . . . . . . . . . . . . . . . . . 15 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 8.1. Update of the TLS ExtensionType Registry . . . . . . . . 15 82 8.2. Update of the DNS Underscore Global Scoped Entry Registry 16 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 9.2. Informative References . . . . . . . . . . . . . . . . . 17 86 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 87 A.1. Since draft-ietf-tls-esni-01 . . . . . . . . . . . . . . 18 88 A.2. Since draft-ietf-tls-esni-00 . . . . . . . . . . . . . . 18 89 A.3. Since draft-rescorla-tls-esni-00 . . . . . . . . . . . . 18 90 Appendix B. Communicating SNI and Nonce to Backend Server . . . 18 91 Appendix C. Alternative SNI Protection Designs . . . . . . . . . 19 92 C.1. TLS-layer . . . . . . . . . . . . . . . . . . . . . . . . 19 93 C.1.1. TLS in Early Data . . . . . . . . . . . . . . . . . . 19 94 C.1.2. Combined Tickets . . . . . . . . . . . . . . . . . . 19 95 C.2. Application-layer . . . . . . . . . . . . . . . . . . . . 19 96 C.2.1. HTTP/2 CERTIFICATE Frames . . . . . . . . . . . . . . 20 98 Appendix D. Total Client Hello Encryption . . . . . . . . . . . 20 99 Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 21 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 102 1. Introduction 104 DISCLAIMER: This is very early a work-in-progress design and has not 105 yet seen significant (or really any) security analysis. It should 106 not be used as a basis for building production systems. 108 Although TLS 1.3 [RFC8446] encrypts most of the handshake, including 109 the server certificate, there are several other channels that allow 110 an on-path attacker to determine the domain name the client is trying 111 to connect to, including: 113 o Cleartext client DNS queries. 115 o Visible server IP addresses, assuming the the server is not doing 116 domain-based virtual hosting. 118 o Cleartext Server Name Indication (SNI) [RFC6066] in ClientHello 119 messages. 121 DoH [I-D.ietf-doh-dns-over-https] and DPRIVE [RFC7858] [RFC8094] 122 provide mechanisms for clients to conceal DNS lookups from network 123 inspection, and many TLS servers host multiple domains on the same IP 124 address. In such environments, SNI is an explicit signal used to 125 determine the server's identity. Indirect mechanisms such as traffic 126 analysis also exist. 128 The TLS WG has extensively studied the problem of protecting SNI, but 129 has been unable to develop a completely generic solution. 130 [I-D.ietf-tls-sni-encryption] provides a description of the problem 131 space and some of the proposed techniques. One of the more difficult 132 problems is "Do not stick out" ([I-D.ietf-tls-sni-encryption]; 133 Section 3.4): if only sensitive/private services use SNI encryption, 134 then SNI encryption is a signal that a client is going to such a 135 service. For this reason, much recent work has focused on concealing 136 the fact that SNI is being protected. Unfortunately, the result 137 often has undesirable performance consequences, incomplete coverage, 138 or both. 140 The design in this document takes a different approach: it assumes 141 that private origins will co-locate with or hide behind a provider 142 (CDN, app server, etc.) which is able to activate encrypted SNI 143 (ESNI) for all of the domains it hosts. Thus, the use of encrypted 144 SNI does not indicate that the client is attempting to reach a 145 private origin, but only that it is going to a particular service 146 provider, which the observer could already tell from the IP address. 148 2. Conventions and Definitions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 3. Overview 158 This document is designed to operate in one of two primary topologies 159 shown below, which we call "Shared Mode" and "Split Mode" 161 3.1. Topologies 163 +---------------------+ 164 | | 165 | 2001:DB8::1111 | 166 | | 167 Client <-----> | private.example.org | 168 | | 169 | public.example.com | 170 | | 171 +---------------------+ 172 Server 174 Figure 1: Shared Mode Topology 176 In Shared Mode, the provider is the origin server for all the domains 177 whose DNS records point to it and clients form a TLS connection 178 directly to that provider, which has access to the plaintext of the 179 connection. 181 +--------------------+ +---------------------+ 182 | | | | 183 | 2001:DB8::1111 | | 2001:DB8::EEEE | 184 Client <------------------------------------>| | 185 | public.example.com | | private.example.com | 186 | | | | 187 +--------------------+ +---------------------+ 188 Client-Facing Server Backend Server 190 Figure 2: Split Mode Topology 192 In Split Mode, the provider is _not_ the origin server for private 193 domains. Rather the DNS records for private domains point to the 194 provider, but the provider's server just relays the connection back 195 to the backend server, which is the true origin server. The provider 196 does not have access to the plaintext of the connection. In 197 principle, the provider might not be the origin for any domains, but 198 as a practical matter, it is probably the origin for a large set of 199 innocuous domains, but is also providing protection for some private 200 domains. Note that the backend server can be an unmodified TLS 1.3 201 server. 203 3.2. SNI Encryption 205 The protocol designed in this document is quite straightforward. 207 First, the provider publishes a public key which is used for SNI 208 encryption for all the domains for which it serves directly or 209 indirectly (via Split mode). This document defines a publication 210 mechanism using DNS, but other mechanisms are also possible. In 211 particular, if some of the clients of a private server are 212 applications rather than Web browsers, those applications might have 213 the public key preconfigured. 215 When a client wants to form a TLS connection to any of the domains 216 served by an ESNI-supporting provider, it replaces the "server_name" 217 extension in the ClientHello with an "encrypted_server_name" 218 extension, which contains the true extension encrypted under the 219 provider's public key. The provider can then decrypt the extension 220 and either terminate the connection (in Shared Mode) or forward it to 221 the backend server (in Split Mode). 223 4. Publishing the SNI Encryption Key 225 SNI Encryption keys can be published in the DNS using the ESNIKeys 226 structure, defined below. 228 // Copied from TLS 1.3 229 struct { 230 NamedGroup group; 231 opaque key_exchange<1..2^16-1>; 232 } KeyShareEntry; 234 struct { 235 uint16 version; 236 uint8 checksum[4]; 237 KeyShareEntry keys<4..2^16-1>; 238 CipherSuite cipher_suites<2..2^16-2>; 239 uint16 padded_length; 240 uint64 not_before; 241 uint64 not_after; 242 Extension extensions<0..2^16-1>; 243 } ESNIKeys; 245 version The version of the structure. For this specification, that 246 value SHALL be 0xff01. Clients MUST ignore any ESNIKeys structure 247 with a version they do not understand. [[NOTE: This means that 248 the RFC will presumably have a nonzero value.]] 250 checksum The first four (4) octets of the SHA-256 message digest 251 [RFC6234] of the ESNIKeys structure. For the purpose of computing 252 the checksum, the value of the "checksum" field MUST be set to 253 zero. 255 keys The list of keys which can be used by the client to encrypt the 256 SNI. Every key being listed MUST belong to a different group. 258 padded_length : The length to pad the ServerNameList value to prior 259 to encryption. This value SHOULD be set to the largest 260 ServerNameList the server expects to support rounded up the nearest 261 multiple of 16. If the server supports wildcard names, it SHOULD set 262 this value to 260. 264 not_before The moment when the keys become valid for use. The value 265 is represented as seconds from 00:00:00 UTC on Jan 1 1970, not 266 including leap seconds. 268 not_after The moment when the keys become invalid. Uses the same 269 unit as not_before. 271 extensions A list of extensions that the client can take into 272 consideration when generating a Client Hello message. The format 273 is defined in [RFC8446]; Section 4.2. The purpose of the field is 274 to provide room for additional features in the future; this 275 document does not define any extension. 277 The semantics of this structure are simple: any of the listed keys 278 may be used to encrypt the SNI for the associated domain name. The 279 cipher suite list is orthogonal to the list of keys, so each key may 280 be used with any cipher suite. 282 This structure is placed in the RRData section of a TXT record as a 283 base64-encoded string. If this encoding exceeds the 255 octet limit 284 of TXT strings, it must be split across multiple concatenated strings 285 as per Section 3.1.3 of [RFC4408]. Servers MAY supply multiple 286 ESNIKeys values, either of the same or of different versions. This 287 allows a server to support multiple versions at once. If the server 288 does not supply any ESNIKeys values with a version known to the 289 client, then the client MUST behave as if no ESNIKeys were found. 291 The name of each TXT record MUST match the name composed of _esni and 292 the query domain name. That is, if a client queries example.com, the 293 ESNI TXT Resource Record might be: 295 _esni.example.com. 60S IN TXT "..." "..." 297 Servers MUST ensure that if multiple A or AAAA records are returned 298 for a domain with ESNI support, all the servers pointed to by those 299 records are able to handle the keys returned as part of a ESNI TXT 300 record for that domain. 302 Clients obtain these records by querying DNS for ESNI-enabled server 303 domains. Clients may initiate these queries in parallel alongside 304 normal A or AAAA queries, and SHOULD block TLS handshakes until they 305 complete, perhaps by timing out. 307 In cases where the domain of the A or AAAA records being resolved do 308 not match the SNI Server Name, such as when [RFC7838] is being used, 309 the SNI domain should be used for querying the ESNI TXT record. 311 Servers operating in Split Mode SHOULD have DNS configured to return 312 the same A (or AAAA) record for all ESNI-enabled servers they 313 service. This yields an anonymity set of cardinality equal to the 314 number of ESNI-enabled server domains supported by a given client- 315 facing server. Thus, even with SNI encryption, an attacker which can 316 enumerate the set of ESNI-enabled domains supported by a client- 317 facing server can guess the correct SNI with probability at least 1/ 318 K, where K is the size of this ESNI-enabled server anonymity set. 319 This probability may be increased via traffic analysis or other 320 mechanisms. 322 The "checksum" field provides protection against transmission errors, 323 including those caused by intermediaries such as a DNS proxy running 324 on a home router. 326 "not_before" and "not_after" fields represent the validity period of 327 the published ESNI keys. Clients MUST NOT use ESNI keys that was 328 covered by an invalid checksum or beyond the published period. If 329 none of the ESNI keys values are acceptable, the client SHOULD behave 330 as if no ESNIKeys were found. 332 Servers SHOULD set the Resource Record TTL small enough so that the 333 record gets discarded by the cache before the ESNI keys reach the end 334 of their validity period. Note that servers MAY need to retain the 335 decryption key for some time after "not_after", and will need to 336 consider clock skew, internal caches and the like, when selecting the 337 "not_before" and "not_after" values. 339 Client MAY cache the ESNIKeys for a particular domain based on the 340 TTL of the Resource Record, but SHOULD NOT cache it based on the 341 not_after value, to allow servers to rotate the keys often and 342 improve forward secrecy. 344 Note that the length of this structure MUST NOT exceed 2^16 - 1, as 345 the RDLENGTH is only 16 bits [RFC1035]. 347 5. The "encrypted_server_name" extension 349 The encrypted SNI is carried in an "encrypted_server_name" extension, 350 defined as follows: 352 enum { 353 encrypted_server_name(0xffce), (65535) 354 } ExtensionType; 356 For clients (in ClientHello), this extension contains the following 357 ClientEncryptedSNI structure: 359 struct { 360 CipherSuite suite; 361 KeyShareEntry key_share; 362 opaque record_digest<0..2^16-1>; 363 opaque encrypted_sni<0..2^16-1>; 364 } ClientEncryptedSNI; 366 suite The cipher suite used to encrypt the SNI. 368 key_share The KeyShareEntry carrying the client's public ephemeral 369 key shared used to derive the ESNI key. 371 record_digest A cryptographic hash of the ESNIKeys structure from 372 which the ESNI key was obtained, i.e., from the first byte of 373 "checksum" to the end of the structure. This hash is computed 374 using the hash function associated with "suite". 376 encrypted_sni The ClientESNIInner structure, AEAD-encrypted using 377 cipher suite "suite" and the key generated as described below. 379 For servers (in EncryptedExtensions), this extension contains the 380 following structure: 382 struct { 383 uint8 nonce[16]; 384 } ServerEncryptedSNI; 386 nonce The contents of ClientESNIInner.nonce. (See Section 5.1.) 388 5.1. Client Behavior 390 In order to send an encrypted SNI, the client MUST first select one 391 of the server ESNIKeyShareEntry values and generate an (EC)DHE share 392 in the matching group. This share will then be sent to the server in 393 the "encrypted_server_name" extension and used to derive the SNI 394 encryption key. It does not affect the (EC)DHE shared secret used in 395 the TLS key schedule. It MUST also select an appropriate cipher 396 suite from the list of suites offered by the server. If the client 397 is unable to select an appropriate group or suite it SHOULD ignore 398 that ESNIKeys value and MAY attempt to use another value provided by 399 the server (recall that servers might provide multiple ESNIKeys in 400 response to a ESNI TXT query). The client MUST NOT send encrypted 401 SNI using groups or cipher suites not advertised by the server. 403 Let Z be the DH shared secret derived from a key share in ESNIKeys 404 and the corresponding client share in ClientEncryptedSNI.key_share. 405 The SNI encryption key is computed from Z as follows: 407 Zx = HKDF-Extract(0, Z) 408 key = HKDF-Expand-Label(Zx, "esni key", Hash(ESNIContents), key_length) 409 iv = HKDF-Expand-Label(Zx, "esni iv", Hash(ESNIContents), iv_length) 411 where ESNIContents is as specified below and Hash is the hash 412 function associated with the HKDF instantiation. 414 struct { 415 opaque record_digest<0..2^16-1>; 416 KeyShareEntry esni_key_share; 417 Random client_hello_random; 418 } ESNIContents; 420 The client then creates a ClientESNIInner structure: 422 struct { 423 ServerNameList sni; 424 opaque zeros[ESNIKeys.padded_length - length(sni)]; 425 } PaddedServerNameList; 427 struct { 428 uint8 nonce[16]; 429 PaddedServerNameList realSNI; 430 } ClientESNIInner; 432 nonce A random 16-octet value to be echoed by the server in the 433 "encrypted_server_name" extension. 435 sni The true SNI, that is, the ServerNameList that would have been 436 sent in the plaintext "server_name" extension. 438 zeros Zero padding whose length makes the serialized 439 PaddedServerNameList struct have a length equal to 440 ESNIKeys.padded_length. 442 This value consists of the serialized ServerNameList from the 443 "server_name" extension, padded with enough zeroes to make the total 444 structure ESNIKeys.padded_length bytes long. The purpose of the 445 padding is to prevent attackers from using the length of the 446 "encrypted_server_name" extension to determine the true SNI. If the 447 serialized ServerNameList is longer than ESNIKeys.padded_length, the 448 client MUST NOT use the "encrypted_server_name" extension. 450 The ClientEncryptedSNI.encrypted_sni value is then computed using the 451 usual TLS 1.3 AEAD: 453 encrypted_sni = AEAD-Encrypt(key, iv, ClientHello.KeyShareClientHello, ClientESNIInner) 455 Where ClientHello.KeyShareClientHello is the body of the extension 456 but not including the extension header. Including 457 ClientHello.KeyShareClientHello in the AAD of AEAD-Encrypt binds the 458 ClientEncryptedSNI value to the ClientHello and prevents cut-and- 459 paste attacks. 461 Note: future extensions may end up reusing the server's 462 ESNIKeyShareEntry for other purposes within the same message (e.g., 463 encrypting other values). Those usages MUST have their own HKDF 464 labels to avoid reuse. 466 [[OPEN ISSUE: If in the future you were to reuse these keys for 0-RTT 467 priming, then you would have to worry about potentially expanding 468 twice of Z_extracted. We should think about how to harmonize these 469 to make sure that we maintain key separation.]] 470 This value is placed in an "encrypted_server_name" extension. 472 The client MAY either omit the "server_name" extension or provide an 473 innocuous dummy one (this is required for technical conformance with 474 [RFC7540]; Section 9.2.) 476 If the server does not negotiate TLS 1.3 or above, then the client 477 MUST abort the connection with an "unsupported_version" alert. If 478 the server does not provide an "encrypted_server_name" extension in 479 EncryptedExtensions, the client MUST abort the connection with an 480 "illegal_parameter" alert. Moreover, it MUST check that 481 ClientESNIInner.nonce matches the value of the 482 "encrypted_server_name" extension provided by the server, and 483 otherwise abort the connection with an "illegal_parameter" alert. 485 5.2. Client-Facing Server Behavior 487 Upon receiving an "encrypted_server_name" extension, the client- 488 facing server MUST first perform the following checks: 490 o If it is unable to negotiate TLS 1.3 or greater, it MUST abort the 491 connection with a "handshake_failure" alert. 493 o If the ClientEncryptedSNI.record_digest value does not match the 494 cryptographic hash of any known ENSIKeys structure, it MUST abort 495 the connection with an "illegal_parameter" alert. This is 496 necessary to prevent downgrade attacks. [[OPEN ISSUE: We looked 497 at ignoring the extension but concluded this was better.]] 499 o If the ClientEncryptedSNI.key_share group does not match one in 500 the ESNIKeys.keys, it MUST abort the connection with an 501 "illegal_parameter" alert. 503 o If the length of the "encrypted_server_name" extension is 504 inconsistent with the advertised padding length (plus AEAD 505 expansion) the server MAY abort the connection with an 506 "illegal_parameter" alert without attempting to decrypt. 508 Assuming these checks succeed, the server then computes K_sni and 509 decrypts the ServerName value. If decryption fails, the server MUST 510 abort the connection with a "decrypt_error" alert. 512 If the decrypted value's length is different from the advertised 513 ESNIKeys.padded_length or the padding consists of any value other 514 than 0, then the server MUST abort the connection with an 515 illegal_parameter alert. Otherwise, the server uses the 516 PaddedServerNameList.sni value as if it were the "server_name" 517 extension. Any actual "server_name" extension is ignored, which also 518 means the server MUST NOT send the "server_name" extension to the 519 client. 521 Upon determining the true SNI, the client-facing server then either 522 serves the connection directly (if in Shared Mode), in which case it 523 executes the steps in the following section, or forwards the TLS 524 connection to the backend server (if in Split Mode). In the latter 525 case, it does not make any changes to the TLS messages, but just 526 blindly forwards them. 528 5.3. Shared Mode Server Behavior 530 A server operating in Shared Mode uses PaddedServerNameList.sni as if 531 it were the "server_name" extension to finish the handshake. It 532 SHOULD pad the Certificate message, via padding at the record layer, 533 such that its length equals the size of the largest possible 534 Certificate (message) covered by the same ESNI key. Moreover, the 535 server MUST include the "encrypted_server_name" extension in 536 EncryptedExtensions, and the value of this extension MUST match 537 PaddedServerNameList.nonce. 539 5.4. Split Mode Server Behavior 541 In Split Mode, the backend server must know 542 PaddedServerNameList.nonce to echo it back in EncryptedExtensions and 543 complete the handshake. Appendix B describes one mechanism for 544 sending both PaddedServerNameList.sni and ClientESNIInner.nonce to 545 the backend server. Thus, backend servers function the same as 546 servers operating in Shared mode. 548 6. Compatibility Issues 550 In general, this mechanism is designed only to be used with servers 551 which have opted in, thus minimizing compatibility issues. However, 552 there are two scenarios where that does not apply, as detailed below. 554 6.1. Misconfiguration 556 If DNS is misconfigured so that a client receives ESNI keys for a 557 server which is not prepared to receive ESNI, then the server will 558 ignore the "encrypted_server_name" extension, as required by 559 [RFC8446]; Section 4.1.2. If the servers does not require SNI, it 560 will complete the handshake with its default certificate. Most 561 likely, this will cause a certificate name mismatch and thus 562 handshake failure. Clients SHOULD NOT fall back to cleartext SNI, 563 because that allows a network attacker to disclose the SNI. They MAY 564 attempt to use another server from the DNS results, if one is 565 provided. 567 6.2. Middleboxes 569 A more serious problem is MITM proxies which do not support this 570 extension. [RFC8446]; Section 9.3 requires that such proxies remove 571 any extensions they do not understand. This will have one of two 572 results when connecting to the client-facing server: 574 1. The handshake will fail if the client-facing server requires SNI. 576 2. The handshake will succeed with the client-facing server's 577 default certificate. 579 A Web client client can securely detect case (2) because it will 580 result in a connection which has an invalid identity (most likely) 581 but which is signed by a certificate which does not chain to a 582 publicly known trust anchor. The client can detect this case and 583 disable ESNI while in that network configuration. 585 In order to enable this mechanism, client-facing servers SHOULD NOT 586 require SNI, but rather respond with some default certificate. 588 A non-conformant MITM proxy will forward the ESNI extension, 589 substituting its own KeyShare value, with the result that the client- 590 facing server will not be able to decrypt the SNI. This causes a 591 hard failure. Detecting this case is difficult, but clients might 592 opt to attempt captive portal detection to see if they are in the 593 presence of a MITM proxy, and if so disable ESNI. Hopefully, the TLS 594 1.3 deployment experience has cleaned out most such proxies. 596 7. Security Considerations 598 7.1. Why is cleartext DNS OK? 600 In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource 601 Records are signed via a server private key, ESNIKeys have no 602 authenticity or provenance information. This means that any attacker 603 which can inject DNS responses or poison DNS caches, which is a 604 common scenario in client access networks, can supply clients with 605 fake ESNIKeys (so that the client encrypts SNI to them) or strip the 606 ESNIKeys from the response. However, in the face of an attacker that 607 controls DNS, no SNI encryption scheme can work because the attacker 608 can replace the IP address, thus blocking client connections, or 609 substituting a unique IP address which is 1:1 with the DNS name that 610 was looked up (modulo DNS wildcards). Thus, allowing the ESNIKeys in 611 the clear does not make the situation significantly worse. 613 Clearly, DNSSEC (if the client validates and hard fails) is a defense 614 against this form of attack, but DoH/DPRIVE are also defenses against 615 DNS attacks by attackers on the local network, which is a common case 616 where SNI. Moreover, as noted in the introduction, SNI encryption is 617 less useful without encryption of DNS queries in transit via DoH or 618 DPRIVE mechanisms. 620 7.2. Comparison Against Criteria 622 [I-D.ietf-tls-sni-encryption] lists several requirements for SNI 623 encryption. In this section, we re-iterate these requirements and 624 assess the ESNI design against them. 626 7.2.1. Mitigate against replay attacks 628 Since the SNI encryption key is derived from a (EC)DH operation 629 between the client's ephemeral and server's semi-static ESNI key, the 630 ESNI encryption is bound to the Client Hello. It is not possible for 631 an attacker to "cut and paste" the ESNI value in a different Client 632 Hello, with a different ephemeral key share, as the terminating 633 server will fail to decrypt and verify the ESNI value. 635 7.2.2. Avoid widely-deployed shared secrets 637 This design depends upon DNS as a vehicle for semi-static public key 638 distribution. Server operators may partition their private keys 639 however they see fit provided each server behind an IP address has 640 the corresponding private key to decrypt a key. Thus, when one ESNI 641 key is provided, sharing is optimally bound by the number of hosts 642 that share an IP address. Server operators may further limit sharing 643 by sending different Resource Records containing ESNIKeys with 644 different keys using a short TTL. 646 7.2.3. Prevent SNI-based DoS attacks 648 This design requires servers to decrypt ClientHello messages with 649 ClientEncryptedSNI extensions carrying valid digests. Thus, it is 650 possible for an attacker to force decryption operations on the 651 server. This attack is bound by the number of valid TCP connections 652 an attacker can open. 654 7.2.4. Do not stick out 656 As more clients enable ESNI support, e.g., as normal part of Web 657 browser functionality, with keys supplied by shared hosting 658 providers, the presence of ESNI extensions becomes less suspicious 659 and part of common or predictable client behavior. In other words, 660 if all Web browsers start using ESNI, the presence of this value does 661 not signal suspicious behavior to passive eavesdroppers. 663 7.2.5. Forward secrecy 665 This design is not forward secret because the server's ESNI key is 666 static. However, the window of exposure is bound by the key 667 lifetime. It is RECOMMEMDED that servers rotate keys frequently. 669 7.2.6. Proper security context 671 This design permits servers operating in Split Mode to forward 672 connections directly to backend origin servers, thereby avoiding 673 unnecessary MiTM attacks. 675 7.2.7. Split server spoofing 677 Assuming ESNIKeys retrieved from DNS are validated, e.g., via DNSSEC 678 or fetched from a trusted Recursive Resolver, spoofing a server 679 operating in Split Mode is not possible. See Section 7.1 for more 680 details regarding cleartext DNS. 682 7.2.8. Supporting multiple protocols 684 This design has no impact on application layer protocol negotiation. 685 It may affect connection routing, server certificate selection, and 686 client certificate verification. Thus, it is compatible with 687 multiple protocols. 689 7.3. Misrouting 691 Note that the backend server has no way of knowing what the SNI was, 692 but that does not lead to additional privacy exposure because the 693 backend server also only has one identity. This does, however, 694 change the situation slightly in that the backend server might 695 previously have checked SNI and now cannot (and an attacker can route 696 a connection with an encrypted SNI to any backend server and the TLS 697 connection will still complete). However, the client is still 698 responsible for verifying the server's identity in its certificate. 700 [[TODO: Some more analysis needed in this case, as it is a little 701 odd, and probably some precise rules about handling ESNI and no SNI 702 uniformly?]] 704 8. IANA Considerations 706 8.1. Update of the TLS ExtensionType Registry 708 IANA is requested to Create an entry, encrypted_server_name(0xffce), 709 in the existing registry for ExtensionType (defined in [RFC8446]), 710 with "TLS 1.3" column values being set to "CH, EE", and "Recommended" 711 column being set to "Yes". 713 8.2. Update of the DNS Underscore Global Scoped Entry Registry 715 IANA is requested to create an entry in the DNS Underscore Global 716 Scoped Entry Registry (defined in [I-D.ietf-dnsop-attrleaf]) with the 717 "RR Type" column value being set to "TXT", the "_NODE NAME" column 718 value being set to "_esni", and the "Reference" column value being 719 set to this document. 721 9. References 723 9.1. Normative References 725 [I-D.ietf-dnsop-attrleaf] 726 Crocker, D., "DNS Scoped Data Through "Underscore" Naming 727 of Attribute Leaves", draft-ietf-dnsop-attrleaf-14 (work 728 in progress), October 2018. 730 [I-D.ietf-tls-exported-authenticator] 731 Sullivan, N., "Exported Authenticators in TLS", draft- 732 ietf-tls-exported-authenticator-08 (work in progress), 733 October 2018. 735 [RFC1035] Mockapetris, P., "Domain names - implementation and 736 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 737 November 1987, . 739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 740 Requirement Levels", BCP 14, RFC 2119, 741 DOI 10.17487/RFC2119, March 1997, . 744 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 745 for Authorizing Use of Domains in E-Mail, Version 1", 746 RFC 4408, DOI 10.17487/RFC4408, April 2006, 747 . 749 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 750 Extensions: Extension Definitions", RFC 6066, 751 DOI 10.17487/RFC6066, January 2011, . 754 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 755 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 756 DOI 10.17487/RFC6234, May 2011, . 759 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 760 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 761 DOI 10.17487/RFC7540, May 2015, . 764 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 765 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 766 April 2016, . 768 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 769 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 770 May 2017, . 772 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 773 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 774 . 776 9.2. Informative References 778 [I-D.ietf-doh-dns-over-https] 779 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 780 (DoH)", draft-ietf-doh-dns-over-https-14 (work in 781 progress), August 2018. 783 [I-D.ietf-tls-sni-encryption] 784 Huitema, C. and E. Rescorla, "Issues and Requirements for 785 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-03 786 (work in progress), May 2018. 788 [I-D.kazuho-protected-sni] 789 Oku, K., "TLS Extensions for Protecting SNI", draft- 790 kazuho-protected-sni-00 (work in progress), July 2017. 792 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 793 and P. Hoffman, "Specification for DNS over Transport 794 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 795 2016, . 797 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 798 Transport Layer Security (DTLS)", RFC 8094, 799 DOI 10.17487/RFC8094, February 2017, . 802 Appendix A. Change Log 804 *RFC Editor's Note:* Please remove this section prior to 805 publication of a final version of this document. 807 GitHub PRs before draft-ietf-tls-esni-02 are associated with the 808 repository located at https://github.com/ekr/draft-rescorla-tls-esni. 810 A.1. Since draft-ietf-tls-esni-01 812 o Clarify TXT record query name (#61). 814 o Ensure clients abort if TLS 1.2 is negotiated (#101). 816 o Clarify that clients should soft fail if ESNI cannot be negotiated 817 (#102). 819 A.2. Since draft-ietf-tls-esni-00 821 o Add version field to ESNIKeys structure fixed to 0xff01 for 822 experiments, and allow servers to publish multiple ESNIKeys 823 structures (#96, #90). 825 A.3. Since draft-rescorla-tls-esni-00 827 o Use separate key share entry for ESNI, and add 828 ClientHello.KeyShareClientHello to the ESNI key derivation to 829 prevent ESNI ciphertext malleability (#87). 831 o Add encrypted nonce to ESNI that is echoed by servers in 832 "encrypted_server_name" extension (#89). 834 Appendix B. Communicating SNI and Nonce to Backend Server 836 When operating in Split mode, backend servers will not have access to 837 PaddedServerNameList.sni or ClientESNIInner.nonce without access to 838 the ESNI keys or a way to decrypt ClientEncryptedSNI.encrypted_sni. 840 One way to address this for a single connection, at the cost of 841 having communication not be unmodified TLS 1.3, is as follows. 842 Assume there is a shared (symmetric) key between the client-facing 843 server and the backend server and use it to AEAD-encrypt Z and send 844 the encrypted blob at the beginning of the connection before the 845 ClientHello. The backend server can then decrypt ESNI to recover the 846 true SNI and nonce. 848 Another way for backend servers to access the true SNI and nonce is 849 by the client-facing server sharing the ESNI keys. 851 Appendix C. Alternative SNI Protection Designs 853 Alternative approaches to encrypted SNI may be implemented at the TLS 854 or application layer. In this section we describe several 855 alternatives and discuss drawbacks in comparison to the design in 856 this document. 858 C.1. TLS-layer 860 C.1.1. TLS in Early Data 862 In this variant, TLS Client Hellos are tunneled within early data 863 payloads belonging to outer TLS connections established with the 864 client-facing server. This requires clients to have established a 865 previous session --- and obtained PSKs --- with the server. The 866 client-facing server decrypts early data payloads to uncover Client 867 Hellos destined for the backend server, and forwards them onwards as 868 necessary. Afterwards, all records to and from backend servers are 869 forwarded by the client-facing server - unmodified. This avoids 870 double encryption of TLS records. 872 Problems with this approach are: (1) servers may not always be able 873 to distinguish inner Client Hellos from legitimate application data, 874 (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may 875 not be supported - especially under DoS - leading to availability 876 concerns, and (4) clients must bootstrap tunnels (sessions), costing 877 an additional round trip and potentially revealing the SNI during the 878 initial connection. In contrast, encrypted SNI protects the SNI in a 879 distinct Client Hello extension and neither abuses early data nor 880 requires a bootstrapping connection. 882 C.1.2. Combined Tickets 884 In this variant, client-facing and backend servers coordinate to 885 produce "combined tickets" that are consumable by both. Clients 886 offer combined tickets to client-facing servers. The latter parse 887 them to determine the correct backend server to which the Client 888 Hello should be forwarded. This approach is problematic due to non- 889 trivial coordination between client-facing and backend servers for 890 ticket construction and consumption. Moreover, it requires a 891 bootstrapping step similar to that of the previous variant. In 892 contrast, encrypted SNI requires no such coordination. 894 C.2. Application-layer 895 C.2.1. HTTP/2 CERTIFICATE Frames 897 In this variant, clients request secondary certificates with 898 CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. 899 In response, servers supply certificates via TLS exported 900 authenticators [I-D.ietf-tls-exported-authenticator] in CERTIFICATE 901 frames. Clients use a generic SNI for the underlying client-facing 902 server TLS connection. Problems with this approach include: (1) one 903 additional round trip before peer authentication, (2) non-trivial 904 application-layer dependencies and interaction, and (3) obtaining the 905 generic SNI to bootstrap the connection. In contrast, encrypted SNI 906 induces no additional round trip and operates below the application 907 layer. 909 Appendix D. Total Client Hello Encryption 911 The design described here only provides encryption for the SNI, but 912 not for other extensions, such as ALPN. Another potential design 913 would be to encrypt all of the extensions using the same basic 914 structure as we use here for ESNI. That design has the following 915 advantages: 917 o It protects all the extensions from ordinary eavesdroppers 919 o If the encrypted block has its own KeyShare, it does not 920 necessarily require the client to use a single KeyShare, because 921 the client's share is bound to the SNI by the AEAD (analysis 922 needed). 924 It also has the following disadvantages: 926 o The client-facing server can still see the other extensions. By 927 contrast we could introduce another EncryptedExtensions block that 928 was encrypted to the backend server and not the client-facing 929 server. 931 o It requires a mechanism for the client-facing server to provide 932 the extension-encryption key to the backend server (as in 933 Appendix B and thus cannot be used with an unmodified backend 934 server. 936 o A conformant middlebox will strip every extension, which might 937 result in a ClientHello which is just unacceptable to the server 938 (more analysis needed). 940 Appendix E. Acknowledgments 942 This document draws extensively from ideas in 943 [I-D.kazuho-protected-sni], but is a much more limited mechanism 944 because it depends on the DNS for the protection of the ESNI key. 945 Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, 946 Nick Sullivan, Martin Thomson, and Chris Wood also provided important 947 ideas. 949 Authors' Addresses 951 Eric Rescorla 952 RTFM, Inc. 954 Email: ekr@rtfm.com 956 Kazuho Oku 957 Fastly 959 Email: kazuhooku@gmail.com 961 Nick Sullivan 962 Cloudflare 964 Email: nick@cloudflare.com 966 Christopher A. Wood 967 Apple, Inc. 969 Email: cawood@apple.com