idnits 2.17.1 draft-ietf-tls-esni-01.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 (September 18, 2018) is 2018 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 231 -- Looks like a reference, but probably isn't: '16' on line 408 == 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 22, 2019 Fastly 6 N. Sullivan 7 Cloudflare 8 C. Wood 9 Apple, Inc. 10 September 18, 2018 12 Encrypted Server Name Indication for TLS 1.3 13 draft-ietf-tls-esni-01 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 March 22, 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 (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 . . . . . . . . . . . . . . 5 60 5. The "encrypted_server_name" extension . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . 12 66 6.1. Misconfiguration . . . . . . . . . . . . . . . . . . . . 12 67 6.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 12 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 7.1. Why is cleartext DNS OK? . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . 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 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 uint16 version; 231 uint8 checksum[4]; 232 KeyShareEntry keys<4..2^16-1>; 233 CipherSuite cipher_suites<2..2^16-2>; 234 uint16 padded_length; 235 uint64 not_before; 236 uint64 not_after; 237 Extension extensions<0..2^16-1>; 238 } ESNIKeys; 240 version The version of the structure. For this specification, that 241 value SHALL be 0xff01. Clients MUST ignore any ESNIKeys structure 242 with a version they do not understand. [[NOTE: This means that 243 the RFC will presumably have a nonzero value.]] 245 checksum The first four (4) octets of the SHA-256 message digest 246 [RFC6234] of the ESNIKeys structure. For the purpose of computing 247 the checksum, the value of the "checksum" field MUST be set to 248 zero. 250 keys The list of keys which can be used by the client to encrypt the 251 SNI. Every key being listed MUST belong to a different group. 253 padded_length : The length to pad the ServerNameList value to prior 254 to encryption. This value SHOULD be set to the largest 255 ServerNameList the server expects to support rounded up the nearest 256 multiple of 16. If the server supports wildcard names, it SHOULD set 257 this value to 260. 259 not_before The moment when the keys become valid for use. The value 260 is represented as seconds from 00:00:00 UTC on Jan 1 1970, not 261 including leap seconds. 263 not_after The moment when the keys become invalid. Uses the same 264 unit as not_before. 266 extensions A list of extensions that the client can take into 267 consideration when generating a Client Hello message. The format 268 is defined in [RFC8446]; Section 4.2. The purpose of the field is 269 to provide room for additional features in the future; this 270 document does not define any extension. 272 The semantics of this structure are simple: any of the listed keys 273 may be used to encrypt the SNI for the associated domain name. The 274 cipher suite list is orthogonal to the list of keys, so each key may 275 be used with any cipher suite. 277 This structure is placed in the RRData section of a TXT record as a 278 base64-encoded string. If this encoding exceeds the 255 octet limit 279 of TXT strings, it must be split across multiple concatenated strings 280 as per Section 3.1.3 of [RFC4408]. Servers MAY supply multiple 281 ESNIKeys values, either of the same or of different versions. This 282 allows a server to support multiple versions at once. 284 The name of each TXT record MUST match the name composed of _esni and 285 the query domain name. That is, if a client queries example.com, the 286 ESNI TXT Resource Record might be: 288 _esni.example.com. 60S IN TXT "..." "..." 290 Servers MUST ensure that if multiple A or AAAA records are returned 291 for a domain with ESNI support, all the servers pointed to by those 292 records are able to handle the keys returned as part of a ESNI TXT 293 record for that domain. 295 Clients obtain these records by querying DNS for ESNI-enabled server 296 domains. Clients may initiate these queries in parallel alongside 297 normal A or AAAA queries, and SHOULD block TLS handshakes until they 298 complete, perhaps by timing out. 300 Servers operating in Split Mode SHOULD have DNS configured to return 301 the same A (or AAAA) record for all ESNI-enabled servers they 302 service. This yields an anonymity set of cardinality equal to the 303 number of ESNI-enabled server domains supported by a given client- 304 facing server. Thus, even with SNI encryption, an attacker which can 305 enumerate the set of ESNI-enabled domains supported by a client- 306 facing server can guess the correct SNI with probability at least 1/ 307 K, where K is the size of this ESNI-enabled server anonymity set. 308 This probability may be increased via traffic analysis or other 309 mechanisms. 311 The "checksum" field provides protection against transmission errors, 312 including those caused by intermediaries such as a DNS proxy running 313 on a home router. 315 "not_before" and "not_after" fields represent the validity period of 316 the published ESNI keys. Clients MUST NOT use ESNI keys that was 317 covered by an invalid checksum or beyond the published period. 318 Servers SHOULD set the Resource Record TTL small enough so that the 319 record gets discarded by the cache before the ESNI keys reach the end 320 of their validity period. Note that servers MAY need to retain the 321 decryption key for some time after "not_after", and will need to 322 consider clock skew, internal caches and the like, when selecting the 323 "not_before" and "not_after" values. 325 Client MAY cache the ESNIKeys for a particular domain based on the 326 TTL of the Resource Record, but SHOULD NOT cache it based on the 327 not_after value, to allow servers to rotate the keys often and 328 improve forward secrecy. 330 Note that the length of this structure MUST NOT exceed 2^16 - 1, as 331 the RDLENGTH is only 16 bits [RFC1035]. 333 5. The "encrypted_server_name" extension 335 The encrypted SNI is carried in an "encrypted_server_name" extension, 336 defined as follows: 338 enum { 339 encrypted_server_name(0xffce), (65535) 340 } ExtensionType; 342 For clients (in ClientHello), this extension contains the following 343 ClientEncryptedSNI structure: 345 struct { 346 CipherSuite suite; 347 KeyShareEntry key_share; 348 opaque record_digest<0..2^16-1>; 349 opaque encrypted_sni<0..2^16-1>; 350 } ClientEncryptedSNI; 352 suite The cipher suite used to encrypt the SNI. 354 key_share The KeyShareEntry carrying the client's public ephemeral 355 key shared used to derive the ESNI key. 357 record_digest A cryptographic hash of the ESNIKeys structure from 358 which the ESNI key was obtained, i.e., from the first byte of 359 "checksum" to the end of the structure. This hash is computed 360 using the hash function associated with "suite". 362 encrypted_sni The ClientESNIInner structure, AEAD-encrypted using 363 cipher suite "suite" and the key generated as described below. 365 For servers (in EncryptedExtensions), this extension contains the 366 following structure: 368 struct { 369 uint8 nonce[16]; 370 } ServerEncryptedSNI; 372 nonce The contents of ClientESNIInner.nonce. (See Section 5.1.) 374 5.1. Client Behavior 376 In order to send an encrypted SNI, the client MUST first select one 377 of the server ESNIKeyShareEntry values and generate an (EC)DHE share 378 in the matching group. This share will then be sent to the server in 379 the "encrypted_sni" extension and used to derive the SNI encryption 380 key. It does not affect the (EC)DHE shared secret used in the TLS 381 key schedule. 383 Let Z be the DH shared secret derived from a key share in ESNIKeys 384 and the corresponding client share in ClientEncryptedSNI.key_share. 385 The SNI encryption key is computed from Z as follows: 387 Zx = HKDF-Extract(0, Z) 388 key = HKDF-Expand-Label(Zx, "esni key", Hash(ESNIContents), key_length) 389 iv = HKDF-Expand-Label(Zx, "esni iv", Hash(ESNIContents), iv_length) 391 where ESNIContents is as specified below and Hash is the hash 392 function associated with the HKDF instantiation. 394 struct { 395 opaque record_digest<0..2^16-1>; 396 KeyShareEntry esni_key_share; 397 Random client_hello_random; 398 } ESNIContents; 400 The client then creates a ClientESNIInner structure: 402 struct { 403 ServerNameList sni; 404 opaque zeros[ESNIKeys.padded_length - length(sni)]; 405 } PaddedServerNameList; 407 struct { 408 uint8 nonce[16]; 409 PaddedServerNameList realSNI; 410 } ClientESNIInner; 412 nonce A random 16-octet value to be echoed by the server in the 413 "encrypted_server_name" extension. 415 sni The true SNI, that is, the ServerNameList that would have been 416 sent in the plaintext "server_name" extension. 418 zeros Zero padding whose length makes the serialized 419 PaddedServerNameList struct have a length equal to 420 ESNIKeys.padded_length. 422 This value consists of the serialized ServerNameList from the 423 "server_name" extension, padded with enough zeroes to make the total 424 structure ESNIKeys.padded_length bytes long. The purpose of the 425 padding is to prevent attackers from using the length of the 426 "encrypted_server_name" extension to determine the true SNI. If the 427 serialized ServerNameList is longer than ESNIKeys.padded_length, the 428 client MUST NOT use the "encrypted_server_name" extension. 430 The ClientEncryptedSNI.encrypted_sni value is then computed using the 431 usual TLS 1.3 AEAD: 433 encrypted_sni = AEAD-Encrypt(key, iv, ClientHello.KeyShareClientHello, ClientESNIInner) 435 Where ClientHello.KeyShareClientHello is the body of the extension 436 but not including the extension header. Including 437 ClientHello.KeyShareClientHello in the AAD of AEAD-Encrypt binds the 438 ClientEncryptedSNI value to the ClientHello and prevents cut-and- 439 paste attacks. 441 Note: future extensions may end up reusing the server's 442 ESNIKeyShareEntry for other purposes within the same message (e.g., 443 encrypting other values). Those usages MUST have their own HKDF 444 labels to avoid reuse. 446 [[OPEN ISSUE: If in the future you were to reuse these keys for 0-RTT 447 priming, then you would have to worry about potentially expanding 448 twice of Z_extracted. We should think about how to harmonize these 449 to make sure that we maintain key separation.]] 451 This value is placed in an "encrypted_server_name" extension. 453 The client MAY either omit the "server_name" extension or provide an 454 innocuous dummy one (this is required for technical conformance with 455 [RFC7540]; Section 9.2.) 457 If the server does not provide an "encrypted_server_name" extension 458 in EncryptedExtensions, the client MUST abort the connection with an 459 "illegal_parameter" alert. Moreover, it MUST check that 460 ClientESNIInner.nonce matches the value of the 461 "encrypted_server_name" extension provided by the server, and 462 otherwise abort the connection with an "illegal_parameter" alert. 464 5.2. Client-Facing Server Behavior 466 Upon receiving an "encrypted_server_name" extension, the client- 467 facing server MUST first perform the following checks: 469 o If it is unable to negotiate TLS 1.3 or greater, it MUST abort the 470 connection with a "handshake_failure" alert. 472 o If the ClientEncryptedSNI.record_digest value does not match the 473 cryptographic hash of any known ENSIKeys structure, it MUST abort 474 the connection with an "illegal_parameter" alert. This is 475 necessary to prevent downgrade attacks. [[OPEN ISSUE: We looked 476 at ignoring the extension but concluded this was better.]] 478 o If the ClientEncryptedSNI.key_share group does not match one in 479 the ESNIKeys.keys, it MUST abort the connection with an 480 "illegal_parameter" alert. 482 o If the length of the "encrypted_server_name" extension is 483 inconsistent with the advertised padding length (plus AEAD 484 expansion) the server MAY abort the connection with an 485 "illegal_parameter" alert without attempting to decrypt. 487 Assuming these checks succeed, the server then computes K_sni and 488 decrypts the ServerName value. If decryption fails, the server MUST 489 abort the connection with a "decrypt_error" alert. 491 If the decrypted value's length is different from the advertised 492 ESNIKeys.padded_length or the padding consists of any value other 493 than 0, then the server MUST abort the connection with an 494 illegal_parameter alert. Otherwise, the server uses the 495 PaddedServerNameList.sni value as if it were the "server_name" 496 extension. Any actual "server_name" extension is ignored. 498 Upon determining the true SNI, the client-facing server then either 499 serves the connection directly (if in Shared Mode), in which case it 500 executes the steps in the following section, or forwards the TLS 501 connection to the backend server (if in Split Mode). In the latter 502 case, it does not make any changes to the TLS messages, but just 503 blindly forwards them. 505 5.3. Shared Mode Server Behavior 507 A server operating in Shared Mode uses PaddedServerNameList.sni as if 508 it were the "server_name" extension to finish the handshake. It 509 SHOULD pad the Certificate message, via padding at the record layer, 510 such that its length equals the size of the largest possible 511 Certificate (message) covered by the same ESNI key. Moreover, the 512 server MUST include the "encrypted_server_name" extension in 513 EncryptedExtensions, and the value of this extension MUST match 514 PaddedServerNameList.nonce. 516 5.4. Split Mode Server Behavior 518 In Split Mode, the backend server must know 519 PaddedServerNameList.nonce to echo it back in EncryptedExtensions and 520 complete the handshake. Appendix A describes one mechanism for 521 sending both PaddedServerNameList.sni and ClientESNIInner.nonce to 522 the backend server. Thus, backend servers function the same as 523 servers operating in Shared mode. 525 6. Compatibility Issues 527 In general, this mechanism is designed only to be used with servers 528 which have opted in, thus minimizing compatibility issues. However, 529 there are two scenarios where that does not apply, as detailed below. 531 6.1. Misconfiguration 533 If DNS is misconfigured so that a client receives ESNI keys for a 534 server which is not prepared to receive ESNI, then the server will 535 ignore the "encrypted_server_name" extension, as required by 536 [RFC8446]; Section 4.1.2. If the servers does not require SNI, it 537 will complete the handshake with its default certificate. Most 538 likely, this will cause a certificate name mismatch and thus 539 handshake failure. Clients SHOULD NOT fall back to cleartext SNI, 540 because that allows a network attacker to disclose the SNI. They MAY 541 attempt to use another server from the DNS results, if one is 542 provided. 544 6.2. Middleboxes 546 A more serious problem is MITM proxies which do not support this 547 extension. [RFC8446]; Section 9.3 requires that such proxies remove 548 any extensions they do not understand. This will have one of two 549 results when connecting to the client-facing server: 551 1. The handshake will fail if the client-facing server requires SNI. 553 2. The handshake will succeed with the client-facing server's 554 default certificate. 556 A Web client client can securely detect case (2) because it will 557 result in a connection which has an invalid identity (most likely) 558 but which is signed by a certificate which does not chain to a 559 publicly known trust anchor. The client can detect this case and 560 disable ESNI while in that network configuration. 562 In order to enable this mechanism, client-facing servers SHOULD NOT 563 require SNI, but rather respond with some default certificate. 565 A non-conformant MITM proxy will forward the ESNI extension, 566 substituting its own KeyShare value, with the result that the client- 567 facing server will not be able to decrypt the SNI. This causes a 568 hard failure. Detecting this case is difficult, but clients might 569 opt to attempt captive portal detection to see if they are in the 570 presence of a MITM proxy, and if so disable ESNI. Hopefully, the TLS 571 1.3 deployment experience has cleaned out most such proxies. 573 7. Security Considerations 575 7.1. Why is cleartext DNS OK? 577 In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource 578 Records are signed via a server private key, ESNIKeys have no 579 authenticity or provenance information. This means that any attacker 580 which can inject DNS responses or poison DNS caches, which is a 581 common scenario in client access networks, can supply clients with 582 fake ESNIKeys (so that the client encrypts SNI to them) or strip the 583 ESNIKeys from the response. However, in the face of an attacker that 584 controls DNS, no SNI encryption scheme can work because the attacker 585 can replace the IP address, thus blocking client connections, or 586 substituting a unique IP address which is 1:1 with the DNS name that 587 was looked up (modulo DNS wildcards). Thus, allowing the ESNIKeys in 588 the clear does not make the situation significantly worse. 590 Clearly, DNSSEC (if the client validates and hard fails) is a defense 591 against this form of attack, but DoH/DPRIVE are also defenses against 592 DNS attacks by attackers on the local network, which is a common case 593 where SNI. Moreover, as noted in the introduction, SNI encryption is 594 less useful without encryption of DNS queries in transit via DoH or 595 DPRIVE mechanisms. 597 7.2. Comparison Against Criteria 599 [I-D.ietf-tls-sni-encryption] lists several requirements for SNI 600 encryption. In this section, we re-iterate these requirements and 601 assess the ESNI design against them. 603 7.2.1. Mitigate against replay attacks 605 Since the SNI encryption key is derived from a (EC)DH operation 606 between the client's ephemeral and server's semi-static ESNI key, the 607 ESNI encryption is bound to the Client Hello. It is not possible for 608 an attacker to "cut and paste" the ESNI value in a different Client 609 Hello, with a different ephemeral key share, as the terminating 610 server will fail to decrypt and verify the ESNI value. 612 7.2.2. Avoid widely-deployed shared secrets 614 This design depends upon DNS as a vehicle for semi-static public key 615 distribution. Server operators may partition their private keys 616 however they see fit provided each server behind an IP address has 617 the corresponding private key to decrypt a key. Thus, when one ESNI 618 key is provided, sharing is optimally bound by the number of hosts 619 that share an IP address. Server operators may further limit sharing 620 by sending different Resource Records containing ESNIKeys with 621 different keys using a short TTL. 623 7.2.3. Prevent SNI-based DoS attacks 625 This design requires servers to decrypt ClientHello messages with 626 ClientEncryptedSNI extensions carrying valid digests. Thus, it is 627 possible for an attacker to force decryption operations on the 628 server. This attack is bound by the number of valid TCP connections 629 an attacker can open. 631 7.2.4. Do not stick out 633 As more clients enable ESNI support, e.g., as normal part of Web 634 browser functionality, with keys supplied by shared hosting 635 providers, the presence of ESNI extensions becomes less suspicious 636 and part of common or predictable client behavior. In other words, 637 if all Web browsers start using ESNI, the presence of this value does 638 not signal suspicious behavior to passive eavesdroppers. 640 7.2.5. Forward secrecy 642 This design is not forward secret because the server's ESNI key is 643 static. However, the window of exposure is bound by the key 644 lifetime. It is RECOMMEMDED that servers rotate keys frequently. 646 7.2.6. Proper security context 648 This design permits servers operating in Split Mode to forward 649 connections directly to backend origin servers, thereby avoiding 650 unnecessary MiTM attacks. 652 7.2.7. Split server spoofing 654 Assuming ESNIKeys retrieved from DNS are validated, e.g., via DNSSEC 655 or fetched from a trusted Recursive Resolver, spoofing a server 656 operating in Split Mode is not possible. See Section 7.1 for more 657 details regarding cleartext DNS. 659 7.2.8. Supporting multiple protocols 661 This design has no impact on application layer protocol negotiation. 662 It may affect connection routing, server certificate selection, and 663 client certificate verification. Thus, it is compatible with 664 multiple protocols. 666 7.3. Misrouting 668 Note that the backend server has no way of knowing what the SNI was, 669 but that does not lead to additional privacy exposure because the 670 backend server also only has one identity. This does, however, 671 change the situation slightly in that the backend server might 672 previously have checked SNI and now cannot (and an attacker can route 673 a connection with an encrypted SNI to any backend server and the TLS 674 connection will still complete). However, the client is still 675 responsible for verifying the server's identity in its certificate. 677 [[TODO: Some more analysis needed in this case, as it is a little 678 odd, and probably some precise rules about handling ESNI and no SNI 679 uniformly?]] 681 8. IANA Considerations 683 8.1. Update of the TLS ExtensionType Registry 685 IANA is requested to Create an entry, encrypted_server_name(0xffce), 686 in the existing registry for ExtensionType (defined in [RFC8446]), 687 with "TLS 1.3" column values being set to "CH, EE", and "Recommended" 688 column being set to "Yes". 690 8.2. Update of the DNS Underscore Global Scoped Entry Registry 692 IANA is requested to create an entry in the DNS Underscore Global 693 Scoped Entry Registry (defined in [I-D.ietf-dnsop-attrleaf]) with the 694 "RR Type" column value being set to "TXT", the "_NODE NAME" column 695 value being set to "_esni", and the "Reference" column value being 696 set to this document. 698 9. References 700 9.1. Normative References 702 [I-D.ietf-dnsop-attrleaf] 703 Crocker, D., "DNS Scoped Data Through "Underscore" Naming 704 of Attribute Leaves", draft-ietf-dnsop-attrleaf-13 (work 705 in progress), August 2018. 707 [I-D.ietf-tls-exported-authenticator] 708 Sullivan, N., "Exported Authenticators in TLS", draft- 709 ietf-tls-exported-authenticator-07 (work in progress), 710 June 2018. 712 [RFC1035] Mockapetris, P., "Domain names - implementation and 713 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 714 November 1987, . 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, 718 DOI 10.17487/RFC2119, March 1997, 719 . 721 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 722 for Authorizing Use of Domains in E-Mail, Version 1", 723 RFC 4408, DOI 10.17487/RFC4408, April 2006, 724 . 726 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 727 Extensions: Extension Definitions", RFC 6066, 728 DOI 10.17487/RFC6066, January 2011, 729 . 731 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 732 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 733 DOI 10.17487/RFC6234, May 2011, 734 . 736 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 737 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 738 DOI 10.17487/RFC7540, May 2015, 739 . 741 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 742 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 743 May 2017, . 745 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 746 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 747 . 749 9.2. Informative References 751 [I-D.ietf-doh-dns-over-https] 752 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 753 (DoH)", draft-ietf-doh-dns-over-https-14 (work in 754 progress), August 2018. 756 [I-D.ietf-tls-sni-encryption] 757 Huitema, C. and E. Rescorla, "Issues and Requirements for 758 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-03 759 (work in progress), May 2018. 761 [I-D.kazuho-protected-sni] 762 Oku, K., "TLS Extensions for Protecting SNI", draft- 763 kazuho-protected-sni-00 (work in progress), July 2017. 765 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 766 and P. Hoffman, "Specification for DNS over Transport 767 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 768 2016, . 770 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 771 Transport Layer Security (DTLS)", RFC 8094, 772 DOI 10.17487/RFC8094, February 2017, 773 . 775 Appendix A. Communicating SNI and Nonce to Backend Server 777 When operating in Split mode, backend servers will not have access to 778 PaddedServerNameList.sni or ClientESNIInner.nonce without access to 779 the ESNI keys or a way to decrypt ClientEncryptedSNI.encrypted_sni. 781 One way to address this for a single connection, at the cost of 782 having communication not be unmodified TLS 1.3, is as follows. 783 Assume there is a shared (symmetric) key between the client-facing 784 server and the backend server and use it to AEAD-encrypt Z and send 785 the encrypted blob at the beginning of the connection before the 786 ClientHello. The backend server can then decrypt ESNI to recover the 787 true SNI and nonce. 789 Another way for backend servers to access the true SNI and nonce is 790 by the client-facing server sharing the ESNI keys. 792 Appendix B. Alternative SNI Protection Designs 794 Alternative approaches to encrypted SNI may be implemented at the TLS 795 or application layer. In this section we describe several 796 alternatives and discuss drawbacks in comparison to the design in 797 this document. 799 B.1. TLS-layer 801 B.1.1. TLS in Early Data 803 In this variant, TLS Client Hellos are tunneled within early data 804 payloads belonging to outer TLS connections established with the 805 client-facing server. This requires clients to have established a 806 previous session --- and obtained PSKs --- with the server. The 807 client-facing server decrypts early data payloads to uncover Client 808 Hellos destined for the backend server, and forwards them onwards as 809 necessary. Afterwards, all records to and from backend servers are 810 forwarded by the client-facing server - unmodified. This avoids 811 double encryption of TLS records. 813 Problems with this approach are: (1) servers may not always be able 814 to distinguish inner Client Hellos from legitimate application data, 815 (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may 816 not be supported - especially under DoS - leading to availability 817 concerns, and (4) clients must bootstrap tunnels (sessions), costing 818 an additional round trip and potentially revealing the SNI during the 819 initial connection. In contrast, encrypted SNI protects the SNI in a 820 distinct Client Hello extension and neither abuses early data nor 821 requires a bootstrapping connection. 823 B.1.2. Combined Tickets 825 In this variant, client-facing and backend servers coordinate to 826 produce "combined tickets" that are consumable by both. Clients 827 offer combined tickets to client-facing servers. The latter parse 828 them to determine the correct backend server to which the Client 829 Hello should be forwarded. This approach is problematic due to non- 830 trivial coordination between client-facing and backend servers for 831 ticket construction and consumption. Moreover, it requires a 832 bootstrapping step similar to that of the previous variant. In 833 contrast, encrypted SNI requires no such coordination. 835 B.2. Application-layer 837 B.2.1. HTTP/2 CERTIFICATE Frames 839 In this variant, clients request secondary certificates with 840 CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. 841 In response, servers supply certificates via TLS exported 842 authenticators [I-D.ietf-tls-exported-authenticator] in CERTIFICATE 843 frames. Clients use a generic SNI for the underlying client-facing 844 server TLS connection. Problems with this approach include: (1) one 845 additional round trip before peer authentication, (2) non-trivial 846 application-layer dependencies and interaction, and (3) obtaining the 847 generic SNI to bootstrap the connection. In contrast, encrypted SNI 848 induces no additional round trip and operates below the application 849 layer. 851 Appendix C. Total Client Hello Encryption 853 The design described here only provides encryption for the SNI, but 854 not for other extensions, such as ALPN. Another potential design 855 would be to encrypt all of the extensions using the same basic 856 structure as we use here for ESNI. That design has the following 857 advantages: 859 o It protects all the extensions from ordinary eavesdroppers 861 o If the encrypted block has its own KeyShare, it does not 862 necessarily require the client to use a single KeyShare, because 863 the client's share is bound to the SNI by the AEAD (analysis 864 needed). 866 It also has the following disadvantages: 868 o The client-facing server can still see the other extensions. By 869 contrast we could introduce another EncryptedExtensions block that 870 was encrypted to the backend server and not the client-facing 871 server. 873 o It requires a mechanism for the client-facing server to provide 874 the extension-encryption key to the backend server (as in 875 Appendix A and thus cannot be used with an unmodified backend 876 server. 878 o A conformant middlebox will strip every extension, which might 879 result in a ClientHello which is just unacceptable to the server 880 (more analysis needed). 882 Appendix D. Acknowledgments 884 This document draws extensively from ideas in 885 [I-D.kazuho-protected-sni], but is a much more limited mechanism 886 because it depends on the DNS for the protection of the ESNI key. 887 Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, 888 Nick Sullivan, Martin Thomson, and Chris Wood also provided important 889 ideas. 891 Authors' Addresses 893 Eric Rescorla 894 RTFM, Inc. 896 Email: ekr@rtfm.com 898 Kazuho Oku 899 Fastly 901 Email: kazuhooku@gmail.com 902 Nick Sullivan 903 Cloudflare 905 Email: nick@cloudflare.com 907 Christopher A. Wood 908 Apple, Inc. 910 Email: cawood@apple.com