idnits 2.17.1 draft-ietf-tls-esni-00.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 24 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 (September 12, 2018) is 2053 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 230 -- Looks like a reference, but probably isn't: '16' on line 397 == Outdated reference: A later version (-16) exists of draft-ietf-dnsop-attrleaf-13 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-07 ** 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: March 16, 2019 Fastly 6 N. Sullivan 7 Cloudflare 8 C. Wood 9 Apple, Inc. 10 September 12, 2018 12 Encrypted Server Name Indication for TLS 1.3 13 draft-ietf-tls-esni-00 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 March 16, 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 . . . . . . . . . . . . 7 61 5.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 8 62 5.2. Client-Facing Server Behavior . . . . . . . . . . . . . . 10 63 5.3. Shared Mode Server Behavior . . . . . . . . . . . . . . . 11 64 5.4. Split Mode Server Behavior . . . . . . . . . . . . . . . 11 65 6. Compatibility Issues . . . . . . . . . . . . . . . . . . . . 11 66 6.1. Misconfiguration . . . . . . . . . . . . . . . . . . . . 11 67 6.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 12 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 7.1. Why is cleartext DNS OK? . . . . . . . . . . . . . . . . 12 70 7.2. Comparison Against Criteria . . . . . . . . . . . . . . . 13 71 7.2.1. Mitigate against replay attacks . . . . . . . . . . . 13 72 7.2.2. Avoid widely-deployed shared secrets . . . . . . . . 13 73 7.2.3. Prevent SNI-based DoS attacks . . . . . . . . . . . . 13 74 7.2.4. Do not stick out . . . . . . . . . . . . . . . . . . 14 75 7.2.5. Forward secrecy . . . . . . . . . . . . . . . . . . . 14 76 7.2.6. Proper security context . . . . . . . . . . . . . . . 14 77 7.2.7. Split server spoofing . . . . . . . . . . . . . . . . 14 78 7.2.8. Supporting multiple protocols . . . . . . . . . . . . 14 79 7.3. Misrouting . . . . . . . . . . . . . . . . . . . . . . . 14 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 15 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 85 9.2. Informative References . . . . . . . . . . . . . . . . . 16 86 Appendix A. Communicating SNI and Nonce to Backend Server . . . 17 87 Appendix B. Alternative SNI Protection Designs . . . . . . . . . 17 88 B.1. TLS-layer . . . . . . . . . . . . . . . . . . . . . . . . 17 89 B.1.1. TLS in Early Data . . . . . . . . . . . . . . . . . . 17 90 B.1.2. Combined Tickets . . . . . . . . . . . . . . . . . . 18 91 B.2. Application-layer . . . . . . . . . . . . . . . . . . . . 18 92 B.2.1. HTTP/2 CERTIFICATE Frames . . . . . . . . . . . . . . 18 93 Appendix C. Total Client Hello Encryption . . . . . . . . . . . 18 94 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 DISCLAIMER: This is very early a work-in-progress design and has not 100 yet seen significant (or really any) security analysis. It should 101 not be used as a basis for building production systems. 103 Although TLS 1.3 [RFC8446] encrypts most of the handshake, including 104 the server certificate, there are several other channels that allow 105 an on-path attacker to determine the domain name the client is trying 106 to connect to, including: 108 o Cleartext client DNS queries. 110 o Visible server IP addresses, assuming the the server is not doing 111 domain-based virtual hosting. 113 o Cleartext Server Name Indication (SNI) [RFC6066] in ClientHello 114 messages. 116 DoH [I-D.ietf-doh-dns-over-https] and DPRIVE [RFC7858] [RFC8094] 117 provide mechanisms for clients to conceal DNS lookups from network 118 inspection, and many TLS servers host multiple domains on the same IP 119 address. In such environments, SNI is an explicit signal used to 120 determine the server's identity. Indirect mechanisms such as traffic 121 analysis also exist. 123 The TLS WG has extensively studied the problem of protecting SNI, but 124 has been unable to develop a completely generic solution. 125 [I-D.ietf-tls-sni-encryption] provides a description of the problem 126 space and some of the proposed techniques. One of the more difficult 127 problems is "Do not stick out" ([I-D.ietf-tls-sni-encryption]; 128 Section 3.4): if only sensitive/private services use SNI encryption, 129 then SNI encryption is a signal that a client is going to such a 130 service. For this reason, much recent work has focused on concealing 131 the fact that SNI is being protected. Unfortunately, the result 132 often has undesirable performance consequences, incomplete coverage, 133 or both. 135 The design in this document takes a different approach: it assumes 136 that private origins will co-locate with or hide behind a provider 137 (CDN, app server, etc.) which is able to activate encrypted SNI 138 (ESNI) for all of the domains it hosts. Thus, the use of encrypted 139 SNI does not indicate that the client is attempting to reach a 140 private origin, but only that it is going to a particular service 141 provider, which the observer could already tell from the IP address. 143 2. Conventions and Definitions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 3. Overview 153 This document is designed to operate in one of two primary topologies 154 shown below, which we call "Shared Mode" and "Split Mode" 156 3.1. Topologies 158 +---------------------+ 159 | | 160 | 2001:DB8::1111 | 161 | | 162 Client <-----> | private.example.org | 163 | | 164 | public.example.com | 165 | | 166 +---------------------+ 167 Server 169 Figure 1: Shared Mode Topology 171 In Shared Mode, the provider is the origin server for all the domains 172 whose DNS records point to it and clients form a TLS connection 173 directly to that provider, which has access to the plaintext of the 174 connection. 176 +--------------------+ +---------------------+ 177 | | | | 178 | 2001:DB8::1111 | | 2001:DB8::EEEE | 179 Client <------------------------------------>| | 180 | public.example.com | | private.example.com | 181 | | | | 182 +--------------------+ +---------------------+ 183 Client-Facing Server Backend Server 185 Figure 2: Split Mode Topology 187 In Split Mode, the provider is _not_ the origin server for private 188 domains. Rather the DNS records for private domains point to the 189 provider, but the provider's server just relays the connection back 190 to the backend server, which is the true origin server. The provider 191 does not have access to the plaintext of the connection. In 192 principle, the provider might not be the origin for any domains, but 193 as a practical matter, it is probably the origin for a large set of 194 innocuous domains, but is also providing protection for some private 195 domains. Note that the backend server can be an unmodified TLS 1.3 196 server. 198 3.2. SNI Encryption 200 The protocol designed in this document is quite straightforward. 202 First, the provider publishes a public key which is used for SNI 203 encryption for all the domains for which it serves directly or 204 indirectly (via Split mode). This document defines a publication 205 mechanism using DNS, but other mechanisms are also possible. In 206 particular, if some of the clients of a private server are 207 applications rather than Web browsers, those applications might have 208 the public key preconfigured. 210 When a client wants to form a TLS connection to any of the domains 211 served by an ESNI-supporting provider, it replaces the "server_name" 212 extension in the ClientHello with an "encrypted_server_name" 213 extension, which contains the true extension encrypted under the 214 provider's public key. The provider can then decrypt the extension 215 and either terminate the connection (in Shared Mode) or forward it to 216 the backend server (in Split Mode). 218 4. Publishing the SNI Encryption Key 220 SNI Encryption keys can be published in the DNS using the ESNIKeys 221 structure, defined below. 223 // Copied from TLS 1.3 224 struct { 225 NamedGroup group; 226 opaque key_exchange<1..2^16-1>; 227 } KeyShareEntry; 229 struct { 230 uint8 checksum[4]; 231 KeyShareEntry keys<4..2^16-1>; 232 CipherSuite cipher_suites<2..2^16-2>; 233 uint16 padded_length; 234 uint64 not_before; 235 uint64 not_after; 236 Extension extensions<0..2^16-1>; 237 } ESNIKeys; 239 checksum The first four (4) octets of the SHA-256 message digest 240 [RFC6234] of the ESNIKeys structure starting from the first octet 241 of "keys" to the end of the structure. 243 keys The list of keys which can be used by the client to encrypt the 244 SNI. Every key being listed MUST belong to a different group. 246 padded_length : The length to pad the ServerNameList value to prior 247 to encryption. This value SHOULD be set to the largest 248 ServerNameList the server expects to support rounded up the nearest 249 multiple of 16. If the server supports wildcard names, it SHOULD set 250 this value to 260. 252 not_before The moment when the keys become valid for use. The value 253 is represented as seconds from 00:00:00 UTC on Jan 1 1970, not 254 including leap seconds. 256 not_after The moment when the keys become invalid. Uses the same 257 unit as not_before. 259 extensions A list of extensions that the client can take into 260 consideration when generating a Client Hello message. The format 261 is defined in [RFC8446]; Section 4.2. The purpose of the field is 262 to provide room for additional features in the future; this 263 document does not define any extension. 265 The semantics of this structure are simple: any of the listed keys 266 may be used to encrypt the SNI for the associated domain name. The 267 cipher suite list is orthogonal to the list of keys, so each key may 268 be used with any cipher suite. 270 This structure is placed in the RRData section of a TXT record as a 271 base64-encoded string. If this encoding exceeds the 255 octet limit 272 of TXT strings, it must be split across multiple concatenated strings 273 as per Section 3.1.3 of [RFC4408]. 275 The name of each TXT record MUST match the name composed of _esni and 276 the query domain name. That is, if a client queries example.com, the 277 ESNI TXT Resource Record might be: 279 _esni.example.com. 60S IN TXT "..." "..." 281 Servers MUST ensure that if multiple A or AAAA records are returned 282 for a domain with ESNI support, all the servers pointed to by those 283 records are able to handle the keys returned as part of a ESNI TXT 284 record for that domain. 286 Clients obtain these records by querying DNS for ESNI-enabled server 287 domains. Clients may initiate these queries in parallel alongside 288 normal A or AAAA queries, and SHOULD block TLS handshakes until they 289 complete, perhaps by timing out. 291 Servers operating in Split Mode SHOULD have DNS configured to return 292 the same A (or AAAA) record for all ESNI-enabled servers they 293 service. This yields an anonymity set of cardinality equal to the 294 number of ESNI-enabled server domains supported by a given client- 295 facing server. Thus, even with SNI encryption, an attacker which can 296 enumerate the set of ESNI-enabled domains supported by a client- 297 facing server can guess the correct SNI with probability at least 1/ 298 K, where K is the size of this ESNI-enabled server anonymity set. 299 This probability may be increased via traffic analysis or other 300 mechanisms. 302 The "checksum" field provides protection against transmission errors, 303 including those caused by intermediaries such as a DNS proxy running 304 on a home router. 306 "not_before" and "not_after" fields represent the validity period of 307 the published ESNI keys. Clients MUST NOT use ESNI keys that was 308 covered by an invalid checksum or beyond the published period. 309 Servers SHOULD set the Resource Record TTL small enough so that the 310 record gets discarded by the cache before the ESNI keys reach the end 311 of their validity period. Note that servers MAY need to retain the 312 decryption key for some time after "not_after", and will need to 313 consider clock skew, internal caches and the like, when selecting the 314 "not_before" and "not_after" values. 316 Client MAY cache the ESNIKeys for a particular domain based on the 317 TTL of the Resource Record, but SHOULD NOT cache it based on the 318 not_after value, to allow servers to rotate the keys often and 319 improve forward secrecy. 321 Note that the length of this structure MUST NOT exceed 2^16 - 1, as 322 the RDLENGTH is only 16 bits [RFC1035]. 324 5. The "encrypted_server_name" extension 326 The encrypted SNI is carried in an "encrypted_server_name" extension, 327 defined as follows: 329 enum { 330 encrypted_server_name(0xffce), (65535) 331 } ExtensionType; 333 For clients (in ClientHello), this extension contains the following 334 EncryptedSNI structure: 336 struct { 337 CipherSuite suite; 338 KeyShareEntry key_share; 339 opaque record_digest<0..2^16-1>; 340 opaque encrypted_sni<0..2^16-1>; 341 } EncryptedSNI; 343 suite The cipher suite used to encrypt the SNI. 345 key_share The KeyShareEntry carrying the client's public ephemeral 346 key shared used to derive the ESNI key. 348 record_digest A cryptographic hash of the ESNIKeys structure from 349 which the ESNI key was obtained, i.e., from the first byte of 350 "checksum" to the end of the structure. This hash is computed 351 using the hash function associated with "suite". 353 encrypted_sni The original ServerNameList from the "server_name" 354 extension, padded and AEAD-encrypted using cipher suite "suite" 355 and with the key generated as described below. 357 For servers (in EncryptedExtensions), this extension contains the 358 following structure: 360 struct { 361 uint8 nonce[16]; 362 } EncryptedSNI; 364 nonce The contents of PaddedServerNameList.nonce. (See 365 Section 5.1.) 367 5.1. Client Behavior 369 In order to send an encrypted SNI, the client MUST first select one 370 of the server ESNIKeyShareEntry values and generate an (EC)DHE share 371 in the matching group. This share will then be sent to the server in 372 the EncryptedSNI extension and used to derive the SNI encryption key. 373 It does not affect the (EC)DHE shared secret used in the TLS key 374 schedule. 376 Let Z be the DH shared secret derived from a key share in ESNIKeys 377 and the corresponding client share in EncryptedSNI.key_share. The 378 SNI encryption key is computed from Z as follows: 380 Zx = HKDF-Extract(0, Z) 381 key = HKDF-Expand-Label(Zx, "esni key", Hash(ESNIContents), key_length) 382 iv = HKDF-Expand-Label(Zx, "esni iv", Hash(ESNIContents), iv_length) 384 where ESNIContents is as specified below and Hash is the hash 385 function associated with the HKDF instantiation. 387 struct { 388 opaque record_digest<0..2^16-1>; 389 KeyShareEntry esni_key_share; 390 Random client_hello_random; 391 } ESNIContents; 393 The client then creates a PaddedServerNameList: 395 struct { 396 ServerNameList sni; 397 uint8 nonce[16]; 398 opaque zeros[ESNIKeys.padded_length - length(sni)]; 399 } PaddedServerNameList; 401 sni The true SNI. 403 nonce A random 16-octet value to be echoed by the server in the 404 "encrypted_server_name" extension. 406 zeros Zero padding whose length makes the serialized struct length 407 match ESNIKeys.padded_length. 409 This value consists of the serialized ServerNameList from the 410 "server_name" extension, padded with enough zeroes to make the total 411 structure ESNIKeys.padded_length bytes long. The purpose of the 412 padding is to prevent attackers from using the length of the 413 "encrypted_server_name" extension to determine the true SNI. If the 414 serialized ServerNameList is longer than ESNIKeys.padded_length, the 415 client MUST NOT use the "encrypted_server_name" extension. 417 The EncryptedSNI.encrypted_sni value is then computed using the usual 418 TLS 1.3 AEAD: 420 encrypted_sni = AEAD-Encrypt(key, iv, ClientHello.KeyShareClientHello, PaddedServerNameList) 422 Including ClientHello.KeyShareClientHello in the AAD of AEAD-Encrypt 423 binds the EncryptedSNI value to the ClientHello and prevents cut-and- 424 paste attacks. 426 Note: future extensions may end up reusing the server's 427 ESNIKeyShareEntry for other purposes within the same message (e.g., 428 encrypting other values). Those usages MUST have their own HKDF 429 labels to avoid reuse. 431 [[OPEN ISSUE: If in the future you were to reuse these keys for 0-RTT 432 priming, then you would have to worry about potentially expanding 433 twice of Z_extracted. We should think about how to harmonize these 434 to make sure that we maintain key separation.]] 436 This value is placed in an "encrypted_server_name" extension. 438 The client MAY either omit the "server_name" extension or provide an 439 innocuous dummy one (this is required for technical conformance with 440 [RFC7540]; Section 9.2.) 442 If the server does not provide an "encrypted_server_name" extension 443 in EncryptedExtensions, the client MUST abort the connection with an 444 "illegal_parameter" alert. Moreover, it MUST check that 445 PaddedServerNameList.nonce matches the value of the 446 "encrypted_server_name" extension provided by the server, and 447 otherwise abort the connection with an "illegal_parameter" alert. 449 5.2. Client-Facing Server Behavior 451 Upon receiving an "encrypted_server_name" extension, the client- 452 facing server MUST first perform the following checks: 454 o If it is unable to negotiate TLS 1.3 or greater, it MUST abort the 455 connection with a "handshake_failure" alert. 457 o If the EncryptedSNI.record_digest value does not match the 458 cryptographic hash of any known ENSIKeys structure, it MUST abort 459 the connection with an "illegal_parameter" alert. This is 460 necessary to prevent downgrade attacks. [[OPEN ISSUE: We looked 461 at ignoring the extension but concluded this was better.]] 463 o If the EncryptedSNI.key_share group does not match one in the 464 ESNIKeys.keys, it MUST abort the connection with an 465 "illegal_parameter" alert. 467 o If the length of the "encrypted_server_name" extension is 468 inconsistent with the advertised padding length (plus AEAD 469 expansion) the server MAY abort the connection with an 470 "illegal_parameter" alert without attempting to decrypt. 472 Assuming these checks succeed, the server then computes K_sni and 473 decrypts the ServerName value. If decryption fails, the server MUST 474 abort the connection with a "decrypt_error" alert. 476 If the decrypted value's length is different from the advertised 477 ESNIKeys.padded_length or the padding consists of any value other 478 than 0, then the server MUST abort the connection with an 479 illegal_parameter alert. Otherwise, the server uses the 480 PaddedServerNameList.sni value as if it were the "server_name" 481 extension. Any actual "server_name" extension is ignored. 483 Upon determining the true SNI, the client-facing server then either 484 serves the connection directly (if in Shared Mode), in which case it 485 executes the steps in the following section, or forwards the TLS 486 connection to the backend server (if in Split Mode). In the latter 487 case, it does not make any changes to the TLS messages, but just 488 blindly forwards them. 490 5.3. Shared Mode Server Behavior 492 A server operating in Shared Mode uses PaddedServerNameList.sni as if 493 it were the "server_name" extension to finish the handshake. It 494 SHOULD pad the Certificate message, via padding at the record layer, 495 such that its length equals the size of the largest possible 496 Certificate (message) covered by the same ESNI key. Moreover, the 497 server MUST include the "encrypted_server_name" extension in 498 EncryptedExtensions, and the value of this extension MUST match 499 PaddedServerNameList.nonce. 501 5.4. Split Mode Server Behavior 503 In Split Mode, the backend server must know 504 PaddedServerNameList.nonce to echo it back in EncryptedExtensions and 505 complete the handshake. Appendix A describes one mechanism for 506 sending both PaddedServerNameList.sni and PaddedServerNameList.nonce 507 to the backend server. Thus, backend servers function the same as 508 servers operating in Shared mode. 510 6. Compatibility Issues 512 In general, this mechanism is designed only to be used with servers 513 which have opted in, thus minimizing compatibility issues. However, 514 there are two scenarios where that does not apply, as detailed below. 516 6.1. Misconfiguration 518 If DNS is misconfigured so that a client receives ESNI keys for a 519 server which is not prepared to receive ESNI, then the server will 520 ignore the "encrypted_server_name" extension, as required by 521 [RFC8446]; Section 4.1.2. If the servers does not require SNI, it 522 will complete the handshake with its default certificate. Most 523 likely, this will cause a certificate name mismatch and thus 524 handshake failure. Clients SHOULD NOT fall back to cleartext SNI, 525 because that allows a network attacker to disclose the SNI. They MAY 526 attempt to use another server from the DNS results, if one is 527 provided. 529 6.2. Middleboxes 531 A more serious problem is MITM proxies which do not support this 532 extension. [RFC8446]; Section 9.3 requires that such proxies remove 533 any extensions they do not understand. This will have one of two 534 results when connecting to the client-facing server: 536 1. The handshake will fail if the client-facing server requires SNI. 538 2. The handshake will succeed with the client-facing server's 539 default certificate. 541 A Web client client can securely detect case (2) because it will 542 result in a connection which has an invalid identity (most likely) 543 but which is signed by a certificate which does not chain to a 544 publicly known trust anchor. The client can detect this case and 545 disable ESNI while in that network configuration. 547 In order to enable this mechanism, client-facing servers SHOULD NOT 548 require SNI, but rather respond with some default certificate. 550 A non-conformant MITM proxy will forward the ESNI extension, 551 substituting its own KeyShare value, with the result that the client- 552 facing server will not be able to decrypt the SNI. This causes a 553 hard failure. Detecting this case is difficult, but clients might 554 opt to attempt captive portal detection to see if they are in the 555 presence of a MITM proxy, and if so disable ESNI. Hopefully, the TLS 556 1.3 deployment experience has cleaned out most such proxies. 558 7. Security Considerations 560 7.1. Why is cleartext DNS OK? 562 In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource 563 Records are signed via a server private key, ESNIKeys have no 564 authenticity or provenance information. This means that any attacker 565 which can inject DNS responses or poison DNS caches, which is a 566 common scenario in client access networks, can supply clients with 567 fake ESNIKeys (so that the client encrypts SNI to them) or strip the 568 ESNIKeys from the response. However, in the face of an attacker that 569 controls DNS, no SNI encryption scheme can work because the attacker 570 can replace the IP address, thus blocking client connections, or 571 substituting a unique IP address which is 1:1 with the DNS name that 572 was looked up (modulo DNS wildcards). Thus, allowing the ESNIKeys in 573 the clear does not make the situation significantly worse. 575 Clearly, DNSSEC (if the client validates and hard fails) is a defense 576 against this form of attack, but DoH/DPRIVE are also defenses against 577 DNS attacks by attackers on the local network, which is a common case 578 where SNI. Moreover, as noted in the introduction, SNI encryption is 579 less useful without encryption of DNS queries in transit via DoH or 580 DPRIVE mechanisms. 582 7.2. Comparison Against Criteria 584 [I-D.ietf-tls-sni-encryption] lists several requirements for SNI 585 encryption. In this section, we re-iterate these requirements and 586 assess the ESNI design against them. 588 7.2.1. Mitigate against replay attacks 590 Since the SNI encryption key is derived from a (EC)DH operation 591 between the client's ephemeral and server's semi-static ESNI key, the 592 ESNI encryption is bound to the Client Hello. It is not possible for 593 an attacker to "cut and paste" the ESNI value in a different Client 594 Hello, with a different ephemeral key share, as the terminating 595 server will fail to decrypt and verify the ESNI value. 597 7.2.2. Avoid widely-deployed shared secrets 599 This design depends upon DNS as a vehicle for semi-static public key 600 distribution. Server operators may partition their private keys 601 however they see fit provided each server behind an IP address has 602 the corresponding private key to decrypt a key. Thus, when one ESNI 603 key is provided, sharing is optimally bound by the number of hosts 604 that share an IP address. Server operators may further limit sharing 605 by sending different Resource Records containing ESNIKeys with 606 different keys using a short TTL. 608 7.2.3. Prevent SNI-based DoS attacks 610 This design requires servers to decrypt ClientHello messages with 611 EncryptedSNI extensions carrying valid digests. Thus, it is possible 612 for an attacker to force decryption operations on the server. This 613 attack is bound by the number of valid TCP connections an attacker 614 can open. 616 7.2.4. Do not stick out 618 As more clients enable ESNI support, e.g., as normal part of Web 619 browser functionality, with keys supplied by shared hosting 620 providers, the presence of ESNI extensions becomes less suspicious 621 and part of common or predictable client behavior. In other words, 622 if all Web browsers start using ESNI, the presence of this value does 623 not signal suspicious behavior to passive eavesdroppers. 625 7.2.5. Forward secrecy 627 This design is not forward secret because the server's ESNI key is 628 static. However, the window of exposure is bound by the key 629 lifetime. It is RECOMMEMDED that servers rotate keys frequently. 631 7.2.6. Proper security context 633 This design permits servers operating in Split Mode to forward 634 connections directly to backend origin servers, thereby avoiding 635 unnecessary MiTM attacks. 637 7.2.7. Split server spoofing 639 Assuming ESNIKeys retrieved from DNS are validated, e.g., via DNSSEC 640 or fetched from a trusted Recursive Resolver, spoofing a server 641 operating in Split Mode is not possible. See Section 7.1 for more 642 details regarding cleartext DNS. 644 7.2.8. Supporting multiple protocols 646 This design has no impact on application layer protocol negotiation. 647 It may affect connection routing, server certificate selection, and 648 client certificate verification. Thus, it is compatible with 649 multiple protocols. 651 7.3. Misrouting 653 Note that the backend server has no way of knowing what the SNI was, 654 but that does not lead to additional privacy exposure because the 655 backend server also only has one identity. This does, however, 656 change the situation slightly in that the backend server might 657 previously have checked SNI and now cannot (and an attacker can route 658 a connection with an encrypted SNI to any backend server and the TLS 659 connection will still complete). However, the client is still 660 responsible for verifying the server's identity in its certificate. 662 [[TODO: Some more analysis needed in this case, as it is a little 663 odd, and probably some precise rules about handling ESNI and no SNI 664 uniformly?]] 666 8. IANA Considerations 668 8.1. Update of the TLS ExtensionType Registry 670 IANA is requested to Create an entry, encrypted_server_name(0xffce), 671 in the existing registry for ExtensionType (defined in [RFC8446]), 672 with "TLS 1.3" column values being set to "CH, EE", and "Recommended" 673 column being set to "Yes". 675 8.2. Update of the DNS Underscore Global Scoped Entry Registry 677 IANA is requested to create an entry in the DNS Underscore Global 678 Scoped Entry Registry (defined in [I-D.ietf-dnsop-attrleaf]) with the 679 "RR Type" column value being set to "TXT", the "_NODE NAME" column 680 value being set to "_esni", and the "Reference" column value being 681 set to this document. 683 9. References 685 9.1. Normative References 687 [I-D.ietf-dnsop-attrleaf] 688 Crocker, D., "DNS Scoped Data Through "Underscore" Naming 689 of Attribute Leaves", draft-ietf-dnsop-attrleaf-13 (work 690 in progress), August 2018. 692 [I-D.ietf-tls-exported-authenticator] 693 Sullivan, N., "Exported Authenticators in TLS", draft- 694 ietf-tls-exported-authenticator-07 (work in progress), 695 June 2018. 697 [RFC1035] Mockapetris, P., "Domain names - implementation and 698 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 699 November 1987, . 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, 703 DOI 10.17487/RFC2119, March 1997, . 706 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 707 for Authorizing Use of Domains in E-Mail, Version 1", 708 RFC 4408, DOI 10.17487/RFC4408, April 2006, 709 . 711 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 712 Extensions: Extension Definitions", RFC 6066, 713 DOI 10.17487/RFC6066, January 2011, . 716 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 717 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 718 DOI 10.17487/RFC6234, May 2011, . 721 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 722 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 723 DOI 10.17487/RFC7540, May 2015, . 726 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 727 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 728 May 2017, . 730 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 731 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 732 . 734 9.2. Informative References 736 [I-D.ietf-doh-dns-over-https] 737 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 738 (DoH)", draft-ietf-doh-dns-over-https-14 (work in 739 progress), August 2018. 741 [I-D.ietf-tls-sni-encryption] 742 Huitema, C. and E. Rescorla, "Issues and Requirements for 743 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-03 744 (work in progress), May 2018. 746 [I-D.kazuho-protected-sni] 747 Oku, K., "TLS Extensions for Protecting SNI", draft- 748 kazuho-protected-sni-00 (work in progress), July 2017. 750 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 751 and P. Hoffman, "Specification for DNS over Transport 752 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 753 2016, . 755 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 756 Transport Layer Security (DTLS)", RFC 8094, 757 DOI 10.17487/RFC8094, February 2017, . 760 Appendix A. Communicating SNI and Nonce to Backend Server 762 When operating in Split mode, backend servers will not have access to 763 PaddedServerNameList.sni or PaddedServerNameList.nonce without access 764 to the ESNI keys or a way to decrypt EncryptedSNI.encrypted_sni. 766 One way to address this for a single connection, at the cost of 767 having communication not be unmodified TLS 1.3, is as follows. 768 Assume there is a shared (symmetric) key between the client-facing 769 server and the backend server and use it to AEAD-encrypt Z and send 770 the encrypted blob at the beginning of the connection before the 771 ClientHello. The backend server can then decrypt ESNI to recover the 772 true SNI and nonce. 774 Another way for backend servers to access the true SNI and nonce is 775 by the client-facing server sharing the ESNI keys. 777 Appendix B. Alternative SNI Protection Designs 779 Alternative approaches to encrypted SNI may be implemented at the TLS 780 or application layer. In this section we describe several 781 alternatives and discuss drawbacks in comparison to the design in 782 this document. 784 B.1. TLS-layer 786 B.1.1. TLS in Early Data 788 In this variant, TLS Client Hellos are tunneled within early data 789 payloads belonging to outer TLS connections established with the 790 client-facing server. This requires clients to have established a 791 previous session --- and obtained PSKs --- with the server. The 792 client-facing server decrypts early data payloads to uncover Client 793 Hellos destined for the backend server, and forwards them onwards as 794 necessary. Afterwards, all records to and from backend servers are 795 forwarded by the client-facing server - unmodified. This avoids 796 double encryption of TLS records. 798 Problems with this approach are: (1) servers may not always be able 799 to distinguish inner Client Hellos from legitimate application data, 800 (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may 801 not be supported - especially under DoS - leading to availability 802 concerns, and (4) clients must bootstrap tunnels (sessions), costing 803 an additional round trip and potentially revealing the SNI during the 804 initial connection. In contrast, encrypted SNI protects the SNI in a 805 distinct Client Hello extension and neither abuses early data nor 806 requires a bootstrapping connection. 808 B.1.2. Combined Tickets 810 In this variant, client-facing and backend servers coordinate to 811 produce "combined tickets" that are consumable by both. Clients 812 offer combined tickets to client-facing servers. The latter parse 813 them to determine the correct backend server to which the Client 814 Hello should be forwarded. This approach is problematic due to non- 815 trivial coordination between client-facing and backend servers for 816 ticket construction and consumption. Moreover, it requires a 817 bootstrapping step similar to that of the previous variant. In 818 contrast, encrypted SNI requires no such coordination. 820 B.2. Application-layer 822 B.2.1. HTTP/2 CERTIFICATE Frames 824 In this variant, clients request secondary certificates with 825 CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. 826 In response, servers supply certificates via TLS exported 827 authenticators [I-D.ietf-tls-exported-authenticator] in CERTIFICATE 828 frames. Clients use a generic SNI for the underlying client-facing 829 server TLS connection. Problems with this approach include: (1) one 830 additional round trip before peer authentication, (2) non-trivial 831 application-layer dependencies and interaction, and (3) obtaining the 832 generic SNI to bootstrap the connection. In contrast, encrypted SNI 833 induces no additional round trip and operates below the application 834 layer. 836 Appendix C. Total Client Hello Encryption 838 The design described here only provides encryption for the SNI, but 839 not for other extensions, such as ALPN. Another potential design 840 would be to encrypt all of the extensions using the same basic 841 structure as we use here for ESNI. That design has the following 842 advantages: 844 o It protects all the extensions from ordinary eavesdroppers 846 o If the encrypted block has its own KeyShare, it does not 847 necessarily require the client to use a single KeyShare, because 848 the client's share is bound to the SNI by the AEAD (analysis 849 needed). 851 It also has the following disadvantages: 853 o The client-facing server can still see the other extensions. By 854 contrast we could introduce another EncryptedExtensions block that 855 was encrypted to the backend server and not the client-facing 856 server. 858 o It requires a mechanism for the client-facing server to provide 859 the extension-encryption key to the backend server (as in 860 Appendix A and thus cannot be used with an unmodified backend 861 server. 863 o A conformant middlebox will strip every extension, which might 864 result in a ClientHello which is just unacceptable to the server 865 (more analysis needed). 867 Appendix D. Acknowledgments 869 This document draws extensively from ideas in 870 [I-D.kazuho-protected-sni], but is a much more limited mechanism 871 because it depends on the DNS for the protection of the ESNI key. 872 Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, 873 Nick Sullivan, Martin Thomson, and Chris Wood also provided important 874 ideas. 876 Authors' Addresses 878 Eric Rescorla 879 RTFM, Inc. 881 Email: ekr@rtfm.com 883 Kazuho Oku 884 Fastly 886 Email: kazuhooku@gmail.com 888 Nick Sullivan 889 Cloudflare 891 Email: nick@cloudflare.com 893 Christopher A. Wood 894 Apple, Inc. 896 Email: cawood@apple.com