tls E. Rescorla Internet-Draft RTFM, Inc. Intended status: Experimental K. Oku Expires: January 3, 2019 Fastly N. Sullivan Cloudflare C. Wood Apple, Inc. July 02, 2018 Encrypted Server Name Indication for TLS 1.3 draft-rescorla-tls-esni-00 Abstract This document defines a simple mechanism for encrypting the Server Name Indication for TLS 1.3. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 3, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Rescorla, et al. Expires January 3, 2019 [Page 1]

Internet-Draft TLS 1.3 SNI Encryption July 2018 1 . Introduction I-D.ietf-tls-tls13] encrypts most of the handshake, including the server certificate, there are several other channels that allow an on-path attacker to determine the domain name the client is trying to connect to, including: o Cleartext client DNS queries. o Visible server IP addresses, assuming the the server is not doing domain-based virtual hosting. o Cleartext Server Name Indication (SNI) [RFC6066] in ClientHello messages. DoH [I-D.ietf-doh-dns-over-https] and DPRIVE [RFC7858] [RFC8094] provide mechanisms for clients to conceal DNS lookups from network inspection, and many TLS servers host multiple domains on the same IP address. In such environments, SNI is an explicit signal used to determine the server's identity. Indirect mechanisms such as traffic analysis also exist. The TLS WG has extensively studied the problem of protecting SNI, but has been unable to develop a completely generic solution. [I-D.ietf-tls-sni-encryption] provides a description of the problem space and some of the proposed techniques. One of the more difficult problems is "Do not stick out" ([I-D.ietf-tls-sni-encryption]; Section 3.4): if only sensitive/private services use SNI encryption, then SNI encryption is a signal that a client is going to such a service. For this reason, much recent work has focused on concealing the fact that SNI is being protected. Unfortunately, the result often has undesirable performance consequences, incomplete coverage, or both. The design in this document takes a different approach: it assumes that private origins will co-locate with or hide behind a provider (CDN, app server, etc.) which is able to activate encrypted SNI (ESNI) for all of the domains it hosts. Thus, the use of encrypted SNI does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the IP address. Rescorla, et al. Expires January 3, 2019 [Page 3]

Internet-Draft TLS 1.3 SNI Encryption July 2018 2 . Conventions and Definitions BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3 . Overview 3.1 . Topologies Rescorla, et al. Expires January 3, 2019 [Page 4]

Internet-Draft TLS 1.3 SNI Encryption July 2018 does not have access to the plaintext of the connection. In principle, the provider might not be the origin for any domains, but as a practical matter, it is probably the origin for a large set of innocuous domains, but is also providing protection for some private domains. Note that the backend server can be an unmodified TLS 1.3 server. 3.2 . SNI Encryption 4 . Publishing the SNI Encryption Key Rescorla, et al. Expires January 3, 2019 [Page 5]

Internet-Draft TLS 1.3 SNI Encryption July 2018 checksum The first four (4) octets of the SHA-256 message digest [RFC6234] of the ESNIKeys structure starting from the first octet of "keys" to the end of the structure. keys The list of keys which can be used by the client to encrypt the SNI. Every key being listed MUST belong to a different group. padded_length : The length to pad the ServerNameList value to prior to encryption. This value SHOULD be set to the largest ServerNameList the server expects to support rounded up the nearest multiple of 16. If the server supports wildcard names, it SHOULD set this value to 260. not_before The moment when the keys become valid for use. The value is represented as seconds from 00:00:00 UTC on Jan 1 1970, not including leap seconds. not_after The moment when the keys become invalid. Uses the same unit as not_before. extensions A list of extensions that the client can take into consideration when generating a Client Hello message. The format is defined in [I-D.ietf-tls-tls13]; Section 4.2. The purpose of the field is to provide room for additional features in the future; this document does not define any extension. The semantics of this structure are simple: any of the listed keys may be used to encrypt the SNI for the associated domain name. The cipher suite list is orthogonal to the list of keys, so each key may be used with any cipher suite. This structure is placed in the RRData section of a TXT record as a base64-encoded string. If this encoding exceeds the 255 octet limit of TXT strings, it must be split across multiple concatenated strings as per Section 3.1.3 of [RFC4408]. The name of each TXT record MUST match the name composed of _esni and the query domain name. That is, if a client queries example.com, the ESNI TXT Resource Record might be: _esni.example.com. 60S IN TXT "..." "..." Servers MUST ensure that if multiple A or AAAA records are returned for a domain with ESNI support, all the servers pointed to by those records are able to handle the keys returned as part of a ESNI TXT record for that domain. Rescorla, et al. Expires January 3, 2019 [Page 6]

Internet-Draft TLS 1.3 SNI Encryption July 2018 Clients obtain these records by querying DNS for ESNI-enabled server domains. Thus, servers operating in Split Mode SHOULD have DNS configured to return the same A (or AAAA) record for all ESNI-enabled servers they service. This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client-facing server. Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client-facing server can guess the correct SNI with probability at least 1/K, where K is the size of this ESNI-enabled server anonymity set. This probability may be increased via traffic analysis or other mechanisms. The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running on a home router. "not_before" and "not_after" fields represent the validity period of the published ESNI keys. Clients MUST NOT use ESNI keys that was covered by an invalid checksum or beyond the published period. Servers SHOULD set the Resource Record TTL small enough so that the record gets discarded by the cache before the ESNI keys reach the end of their validity period. Note that servers MAY need to retain the decryption key for some time after "not_after", and will need to consider clock skew, internal caches and the like, when selecting the "not_before" and "not_after" values. Client MAY cache the ESNIKeys for a particular domain based on the TTL of the Resource Record, but SHOULD NOT cache it based on the not_after value, to allow servers to rotate the keys often and improve forward secrecy. Note that the length of this structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits [RFC1035]. 5 . The "encrypted_server_name" extension Rescorla, et al. Expires January 3, 2019 [Page 7]

Internet-Draft TLS 1.3 SNI Encryption July 2018 "checksum" to the end of the structure. This hash is computed using the hash function associated with "suite". suite The cipher suite used to encrypt the SNI. encrypted_sni The original ServerNameList from the "server_name" extension, padded and AEAD-encrypted using cipher suite "suite" and with the key generated as described below. 5.1 . Client Behavior Rescorla, et al. Expires January 3, 2019 [Page 8]

Internet-Draft TLS 1.3 SNI Encryption July 2018 encrypted_sni = AEAD-Encrypt(key, iv, "", PaddedServerNameList) Note: future extensions may end up reusing the server's ESNIKeyShareEntry for other purposes within the same message (e.g., encrypting other values). Those usages MUST have their own HKDF labels to avoid reuse. [[OPEN ISSUE: If in future you were to reuse these keys for 0-RTT priming, then you would have to worry about potentially expanding twice of Z_extracted. We should think about how to harmonize these to make sure that we maintain key separation. Similarly, if the server uses the same key for ESNI as it does in ServerKeyShare, this is going to involve re-use of Z in some hard to analyze ways. Of course, this would also involve abandoning PFS.]] This value is placed in an "encrypted_server_name" extension. The client MAY either omit the "server_name" extension or provide an innocuous dummy one (this is required for technical conformance with [RFC7540]; Section 9.2.) 5.2 . Client-Facing Server Behavior Rescorla, et al. Expires January 3, 2019 [Page 9]

Internet-Draft TLS 1.3 SNI Encryption July 2018 If the decrypted value's length is different from the advertised ESNIKeys.padded_length or the padding consists of any value other than 0, then the server MUST abort the connection with an illegal_parameter alert. Otherwise, the server uses the PaddedServerNameList.sni value as if it were the "server_name" extension. Any actual "server_name" extension is ignored. Upon determining the true SNI, the client-facing server then either serves the connection directly (if in Shared Mode), in which case it executes the steps in the following section, or forwards the TLS connection to the backend server (if in Split Mode). In the latter case, it does not make any changes to the TLS messages, but just blindly forwards them. 5.3 . Shared Mode Server Behavior 5.4 . Split Mode Server Behavior Appendix A describes a mechanism for communicating the true SNI to the backend server. Similar to the Shared Mode behavior, the backend server in Split Mode SHOULD pad the Certificate message, via padding at the record layer such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. [[OPEN ISSUE: Do we want "encrypted_server_name" in EE? It's clearer communication, but would make it so you could not operate a current TLS 1.3 server as a backend server.]] 6 . Compatibility Issues Rescorla, et al. Expires January 3, 2019 [Page 10]

Internet-Draft TLS 1.3 SNI Encryption July 2018 6.1 . Misconfiguration I-D.ietf-tls-tls13]; Section 4.1.2. If the servers does not require SNI, it will complete the handshake with its default certificate. Most likely, this will cause a certificate name mismatch and thus handshake failure. Clients SHOULD not fall back to cleartext SNI, because that allows a network attacker to disclose the SNI. They MAY attempt to use another server from the DNS results, if one is provided. 6.2 . Middleboxes I-D.ietf-tls-tls13]; Section 9.3 requires that such proxies remove any extensions they do not understand. This will have one of two results when connecting to the client-facing server: 1. The handshake will fail if the client-facing server requires SNI. 2. The handshake will succeed with the client-facing server's default certificate. A Web client client can securely detect case (2) because it will result in a connection which has an invalid identity (most likely) but which is signed by a certificate which does not chain to a publicly known trust anchor. The client can detect this case and disable ESNI while in that network configuration. In order to enable this mechanism, client-facing servers SHOULD NOT require SNI, but rather respond with some default certificate. A non-conformant MITM proxy will forward the ESNI extension, substituting its own KeyShare value, with the result that the client- facing server will not be able to decrypt the SNI. This causes a hard failure. Detecting this case is difficult, but clients might opt to attempt captive portal detection to see if they are in the presence of a MITM proxy, and if so disable ESNI. Hopefully, the TLS 1.3 deployment experience has cleaned out most such proxies. 7 . Security Considerations Rescorla, et al. Expires January 3, 2019 [Page 11]

Internet-Draft TLS 1.3 SNI Encryption July 2018 7.1 . Why is cleartext DNS OK? I-D.kazuho-protected-sni], wherein DNS Resource Records are signed via a server private key, ESNIKeys have no authenticity or provenance information. This means that any attacker which can inject DNS responses or poison DNS caches, which is a common scenario in client access networks, can supply clients with fake ESNIKeys (so that the client encrypts SNI to them) or strip the ESNIKeys from the response. However, in the face of an attacker that controls DNS, no SNI encryption scheme can work because the attacker can replace the IP address, thus blocking client connections, or substituting a unique IP address which is 1:1 with the DNS name that was looked up (modulo DNS wildcards). Thus, allowing the ESNIKeys in the clear does not make the situation significantly worse. Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but DoH/DPRIVE are also defenses against DNS attacks by attackers on the local network, which is a common case where SNI. Moreover, as noted in the introduction, SNI encryption is less useful without encryption of DNS queries in transit via DoH or DPRIVE mechanisms. 7.2 . Comparison Against Criteria I-D.ietf-tls-sni-encryption] lists several requirements for SNI encryption. In this section, we re-iterate these requirements and assess the ESNI design against them. 7.2.1 . Mitigate against replay attacks 7.2.2 . Avoid widely-deployed shared secrets Rescorla, et al. Expires January 3, 2019 [Page 12]

Internet-Draft TLS 1.3 SNI Encryption July 2018 7.2.3 . Prevent SNI-based DoS attacks 7.2.4 . Do not stick out 7.2.5 . Forward secrecy 7.2.6 . Proper security context 7.2.7 . Split server spoofing Section 7.1 for more details regarding cleartext DNS. 7.2.8 . Supporting multiple protocols Rescorla, et al. Expires January 3, 2019 [Page 13]

Internet-Draft TLS 1.3 SNI Encryption July 2018 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc- editor.org/info/rfc8094>. Appendix A . Communicating SNI to Backend Server Section 5.4, the backend server will generally not know the true SNI in Split Mode. It is possible for the client-facing server to communicate the true SNI to the backend server, but at the cost of having that communication not be unmodified TLS 1.3. The basic idea is to have a shared key between the client-facing server and the backend server (this can be a symmetric key) and use it to AEAD-encrypt Z and send the encrypted blob at the beginning of the connection before the ClientHello. The backend server can then decrypt ESNI to recover the true SNI. An obvious alternative here would be to have the client-facing server forward the true SNI, but that would allow the client-facing server to lie. In this design, the attacker would need to be able to find a Z which would expand into a key that would validly AEAD-encrypt a message of his choice, which should be intractable (Hand-waving alert!). Appendix B . Alternative SNI Protection Designs B.1 . TLS-layer B.1.1 . TLS in Early Data Rescorla, et al. Expires January 3, 2019 [Page 16]

Internet-Draft TLS 1.3 SNI Encryption July 2018 not be supported - especially under DoS - leading to availability concerns, and (4) clients must bootstrap tunnels (sessions), costing an additional round trip and potentially revealing the SNI during the initial connection. In contrast, encrypted SNI protects the SNI in a distinct Client Hello extension and neither abuses early data nor requires a bootstrapping connection. B.1.2 . Combined Tickets B.2 . Application-layer B.2.1 . HTTP/2 CERTIFICATE Frames I-D.ietf-tls-exported-authenticator] in CERTIFICATE frames. Clients use a generic SNI for the underlying client-facing server TLS connection. Problems with this approach include: (1) one additional round trip before peer authentication, (2) non-trivial application-layer dependencies and interaction, and (3) obtaining the generic SNI to bootstrap the connection. In contrast, encrypted SNI induces no additional round trip and operates below the application layer. Appendix C . Total Client Hello Encryption Rescorla, et al. Expires January 3, 2019 [Page 17]

Internet-Draft TLS 1.3 SNI Encryption July 2018 the client's share is bound to the SNI by the AEAD (analysis needed). It also has the following disadvantages: o The client-facing server can still see the other extensions. By contrast we could introduce another EncryptedExtensions block that was encrypted to the backend server and not the client-facing server. o It requires a mechanism for the client-facing server to provide the extension-encryption key to the backend server (as in Appendix A and thus cannot be used with an unmodified backend server. o A conformant middlebox will strip every extension, which might result in a ClientHello which is just unacceptable to the server (more analysis needed). Appendix D . Acknowledgments I-D.kazuho-protected-sni], but is a much more limited mechanism because it depends on the DNS for the protection of the ESNI key. Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, Nick Sullivan, Martin Thomson, and Chris Wood also provided important ideas. Authors' Addresses Eric Rescorla RTFM, Inc. Email: ekr@rtfm.com Kazuho Oku Fastly Email: kazuhooku@gmail.com Nick Sullivan Cloudflare Email: nick@cloudflare.com Rescorla, et al. Expires January 3, 2019 [Page 18]

Internet-Draft TLS 1.3 SNI Encryption July 2018 Christopher A. Wood Apple, Inc. Email: cawood@apple.com Rescorla, et al. Expires January 3, 2019 [Page 19]