diff options
Diffstat (limited to 'doc/rfc/rfc8744.txt')
| -rw-r--r-- | doc/rfc/rfc8744.txt | 664 |
1 files changed, 664 insertions, 0 deletions
diff --git a/doc/rfc/rfc8744.txt b/doc/rfc/rfc8744.txt new file mode 100644 index 0000000..8540e4c --- /dev/null +++ b/doc/rfc/rfc8744.txt @@ -0,0 +1,664 @@ + + + + +Internet Engineering Task Force (IETF) C. Huitema +Request for Comments: 8744 Private Octopus Inc. +Category: Informational July 2020 +ISSN: 2070-1721 + + +Issues and Requirements for Server Name Identification (SNI) Encryption + in TLS + +Abstract + + This document describes the general problem of encrypting the Server + Name Identification (SNI) TLS parameter. The proposed solutions hide + a hidden service behind a fronting service, only disclosing the SNI + of the fronting service to external observers. This document lists + known attacks against SNI encryption, discusses the current "HTTP co- + tenancy" solution, and presents requirements for future TLS-layer + solutions. + + In practice, it may well be that no solution can meet every + requirement and that practical solutions will have to make some + compromises. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8744. + +Copyright Notice + + Copyright (c) 2020 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 + (https://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 + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. History of the TLS SNI Extension + 2.1. Unanticipated Usage of SNI Information + 2.2. SNI Encryption Timeliness + 2.3. End-to-End Alternatives + 3. Security and Privacy Requirements for SNI Encryption + 3.1. Mitigate Cut-and-Paste Attacks + 3.2. Avoid Widely Shared Secrets + 3.3. Prevent SNI-Based Denial-of-Service Attacks + 3.4. Do Not Stick Out + 3.5. Maintain Forward Secrecy + 3.6. Enable Multi-party Security Contexts + 3.7. Support Multiple Protocols + 3.7.1. Hiding the Application-Layer Protocol Negotiation + 3.7.2. Supporting Other Transports than TCP + 4. HTTP Co-tenancy Fronting + 4.1. HTTPS Tunnels + 4.2. Delegation Control + 4.3. Related Work + 5. Security Considerations + 6. IANA Considerations + 7. Informative References + Acknowledgements + Author's Address + +1. Introduction + + Historically, adversaries have been able to monitor the use of web + services through three primary channels: looking at DNS requests, + looking at IP addresses in packet headers, and looking at the data + stream between user and services. These channels are getting + progressively closed. A growing fraction of Internet communication + is encrypted, mostly using Transport Layer Security (TLS) [RFC8446]. + Progressive deployment of solutions like DNS over TLS [RFC7858] and + DNS over HTTPS [RFC8484] mitigates the disclosure of DNS information. + More and more services are colocated on multiplexed servers, + loosening the relation between IP address and web service. For + example, in virtual hosting solutions, multiple services can be + hosted as co-tenants on the same server, and the IP address and port + do not uniquely identify a service. In cloud or Content Delivery + Network (CDN) solutions, a given platform hosts the services or + servers of a lot of organizations, and looking up what netblock an IP + address belongs to reveals little. However, multiplexed servers rely + on the Server Name Information (SNI) TLS extension [RFC6066] to + direct connections to the appropriate service implementation. This + protocol element is transmitted in cleartext. As the other methods + of monitoring get blocked, monitoring focuses on the cleartext SNI. + The purpose of SNI encryption is to prevent that and aid privacy. + + Replacing cleartext SNI transmission by an encrypted variant will + improve the privacy and reliability of TLS connections, but the + design of proper SNI encryption solutions is difficult. In the past, + there have been multiple attempts at defining SNI encryption. These + attempts have generally floundered, because the simple designs fail + to mitigate several of the attacks listed in Section 3. In the + absence of a TLS-level solution, the most popular approach to SNI + privacy for web services is HTTP-level fronting, which we discuss in + Section 4. + + This document does not present the design of a solution but provides + guidelines for evaluating proposed solutions. (The review of HTTP- + level solutions in Section 4 is not an endorsement of these + solutions.) The need for related work on the encryption of the + Application-Layer Protocol Negotiation (ALPN) parameters of TLS is + discussed in Section 3.7.1. + +2. History of the TLS SNI Extension + + The SNI extension was specified in 2003 in [RFC3546] to facilitate + management of "colocation servers", in which multiple services shared + the same IP address. A typical example would be multiple websites + served by the same web server. The SNI extension carries the name of + a specific server, enabling the TLS connection to be established with + the desired server context. The current SNI extension specification + can be found in [RFC6066]. + + The SNI specification allowed for different types of server names, + though only the "hostname" variant was specified and deployed. In + that variant, the SNI extension carries the domain name of the target + server. The SNI extension is carried in cleartext in the TLS + "ClientHello" message. + +2.1. Unanticipated Usage of SNI Information + + The SNI was defined to facilitate management of servers, but the + developers of middleboxes found out that they could take advantage of + the information. Many examples of such usage are reviewed in + [RFC8404]. Other examples came out during discussions of this + document. They include: + + * Filtering or censoring specific services for a variety of reasons + + * Content filtering by network operators or ISPs blocking specific + websites, for example, to implement parental controls or to + prevent access to phishing or other fraudulent websites + + * ISP assigning different QoS profiles to target services + + * Firewalls within enterprise networks blocking websites not deemed + appropriate for work + + * Firewalls within enterprise networks exempting specific websites + from man-in-the-middle (MITM) inspection, such as healthcare or + financial sites for which inspection would intrude on the privacy + of employees + + The SNI is probably also included in the general collection of + metadata by pervasive surveillance actors [RFC7258], for example, to + identify services used by surveillance targets. + +2.2. SNI Encryption Timeliness + + The cleartext transmission of the SNI was not flagged as a problem in + the Security Considerations sections of [RFC3546], [RFC4366], or + [RFC6066]. These specifications did not anticipate the alternative + usage described in Section 2.1. One reason may be that, when these + RFCs were written, the SNI information was available through a + variety of other means, such as tracking IP addresses, DNS names, or + server certificates. + + Many deployments still allocate different IP addresses to different + services, so that different services can be identified by their IP + addresses. However, CDNs commonly serve a large number of services + through a comparatively small number of addresses. + + The SNI carries the domain name of the server, which is also sent as + part of the DNS queries. Most of the SNI usage described in + Section 2.1 could also be implemented by monitoring DNS traffic or + controlling DNS usage. But this is changing with the advent of DNS + resolvers providing services like DNS over TLS [RFC7858] or DNS over + HTTPS [RFC8484]. + + The subjectAltName extension of type dNSName of the server + certificate (or in its absence, the common name component) exposes + the same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 + [RFC4346], and 1.2 [RFC5246], servers send certificates in cleartext, + ensuring that there would be limited benefits in hiding the SNI. + However, in TLS 1.3 [RFC8446], server certificates are encrypted in + transit. Note that encryption alone is insufficient to protect + server certificates; see Section 3.1 for details. + + The decoupling of IP addresses and server names, deployment of DNS + privacy, and protection of server certificate transmissions all + contribute to user privacy in the face of an RFC 7258-style adversary + [RFC7258]. Encrypting the SNI complements this push for privacy and + makes it harder to censor or otherwise provide differential treatment + to specific Internet services. + +2.3. End-to-End Alternatives + + Deploying SNI encryption helps thwart most of the unanticipated SNI + usages, including censorship and pervasive surveillance, but it also + will break or reduce the efficacy of the operational practices and + techniques implemented in middleboxes, as described in Section 2.1. + Most of these functions can, however, be realized by other means. + For example, some DNS service providers offer customers the provision + to "opt in" to filtering services for parental control and phishing + protection. Per-stream QoS could be provided by a combination of + packet marking and end-to-end agreements. As SNI encryption becomes + common, we can expect more deployment of such "end-to-end" solutions. + + At the time of this writing, enterprises have the option of + installing a firewall performing SNI filtering to prevent connections + to certain websites. With SNI encryption, this becomes ineffective. + Obviously, managers could block usage of SNI encryption in enterprise + computers, but this wide-scale blocking would diminish the privacy + protection of traffic leaving the enterprise, which may not be + desirable. Enterprise managers could rely instead on filtering + software and management software deployed on the enterprise's + computers. + +3. Security and Privacy Requirements for SNI Encryption + + Over the past years, there have been multiple proposals to add an SNI + encryption option in TLS. A review of the TLS mailing list archives + shows that many of these proposals appeared promising but were + rejected after security reviews identified plausible attacks. In + this section, we collect a list of these known attacks. + +3.1. Mitigate Cut-and-Paste Attacks + + The simplest SNI encryption designs replace the cleartext SNI in the + initial TLS exchange with an encrypted value, using a key known to + the multiplexed server. Regardless of the encryption used, these + designs can be broken by a simple cut-and-paste attack, which works + as follows: + + 1. The user starts a TLS connection to the multiplexed server, + including an encrypted SNI value. + + 2. The adversary observes the exchange and copies the encrypted SNI + parameter. + + 3. The adversary starts its own connection to the multiplexed + server, including in its connection parameters the encrypted SNI + copied from the observed exchange. + + 4. The multiplexed server establishes the connection to the + protected service, which sends its certificate, thus revealing + the identity of the service. + + One of the goals of SNI encryption is to prevent adversaries from + knowing which hidden service the client is using. Successful cut- + and-paste attacks break that goal by allowing adversaries to discover + that service. + +3.2. Avoid Widely Shared Secrets + + It is easy to think of simple schemes in which the SNI is encrypted + or hashed using a shared secret. This symmetric key must be known by + the multiplexed server and by every user of the protected services. + Such schemes are thus very fragile, since the compromise of a single + user would compromise the entire set of users and protected services. + +3.3. Prevent SNI-Based Denial-of-Service Attacks + + Encrypting the SNI may create extra load for the multiplexed server. + Adversaries may mount denial-of-service (DoS) attacks by generating + random encrypted SNI values and forcing the multiplexed server to + spend resources in useless decryption attempts. + + It may be argued that this is not an important avenue for DoS + attacks, as regular TLS connection attempts also require the server + to perform a number of cryptographic operations. However, in many + cases, the SNI decryption will have to be performed by a front-end + component with limited resources, while the TLS operations are + performed by the component dedicated to their respective services. + SNI-based DoS attacks could target the front-end component. + +3.4. Do Not Stick Out + + In some designs, handshakes using SNI encryption can be easily + differentiated from "regular" handshakes. For example, some designs + require specific extensions in the ClientHello packets or specific + values of the cleartext SNI parameter. If adversaries can easily + detect the use of SNI encryption, they could block it, or they could + flag the users of SNI encryption for special treatment. + + In the future, it might be possible to assume that a large fraction + of TLS handshakes use SNI encryption. If that were the case, the + detection of SNI encryption would be a lesser concern. However, we + have to assume that, in the near future, only a small fraction of TLS + connections will use SNI encryption. + + This requirement to not stick out may be difficult to meet in + practice, as noted in Section 5. + +3.5. Maintain Forward Secrecy + + TLS 1.3 [RFC8446] is designed to provide forward secrecy, so that + (for example) keys used in past sessions will not be compromised even + if the private key of the server is compromised. The general + concerns about forward secrecy apply to SNI encryption as well. For + example, some proposed designs rely on a public key of the + multiplexed server to define the SNI encryption key. If the + corresponding private key should be compromised, the adversaries + would be able to process archival records of past connections and + retrieve the protected SNI used in these connections. These designs + fail to maintain forward secrecy of SNI encryption. + +3.6. Enable Multi-party Security Contexts + + We can design solutions in which a fronting service acts as a relay + to reach the protected service. Some of those solutions involve just + one TLS handshake between the client and the fronting service. The + master secret is verified by verifying a certificate provided by the + fronting service but not by the protected service. These solutions + expose the client to a MITM attack by the fronting service. Even if + the client has some reasonable trust in this service, the possibility + of a MITM attack is troubling. + + There are other classes of solutions in which the master secret is + verified by verifying a certificate provided by the protected + service. These solutions offer more protection against a MITM attack + by the fronting service. The downside is that the client will not + verify the identity of the fronting service, which enables fronting + server spoofing attacks, such as the "honeypot" attack discussed + below. Overall, end-to-end TLS to the protected service is + preferable, but it is important to also provide a way to authenticate + the fronting service. + + The fronting service could be pressured by adversaries. By design, + it could be forced to deny access to the protected service or to + divulge which client accessed it. But if a MITM attack is possible, + the adversaries would also be able to pressure the fronting service + into intercepting or spoofing the communications between client and + protected service. + + Adversaries could also mount an attack by spoofing the fronting + service. A spoofed fronting service could act as a "honeypot" for + users of hidden services. At a minimum, the fake server could record + the IP addresses of these users. If the SNI encryption solution + places too much trust on the fronting server, the fake server could + also serve fake content of its own choosing, including various forms + of malware. + + There are two main channels by which adversaries can conduct this + attack. Adversaries can simply try to mislead users into believing + that the honeypot is a valid fronting server, especially if that + information is carried by word of mouth or in unprotected DNS + records. Adversaries can also attempt to hijack the traffic to the + regular fronting server, using, for example, spoofed DNS responses or + spoofed IP-level routing, combined with a spoofed certificate. + +3.7. Support Multiple Protocols + + The SNI encryption requirement does not stop with HTTP over TLS. + Multiple other applications currently use TLS, including, for + example, SMTP [RFC3207], DNS [RFC7858], IMAP [RFC8314], and the + Extensible Messaging and Presence Protocol (XMPP) [RFC7590]. These + applications, too, will benefit from SNI encryption. HTTP-only + methods, like those described in Section 4.1, would not apply there. + In fact, even for the HTTPS case, the HTTPS tunneling service + described in Section 4.1 is compatible with HTTP 1.0 and HTTP 1.1 but + interacts awkwardly with the multiple streams feature of HTTP/2 + [RFC7540]. This points to the need for an application-agnostic + solution, which would be implemented fully in the TLS layer. + +3.7.1. Hiding the Application-Layer Protocol Negotiation + + The Application-Layer Protocol Negotiation (ALPN) parameters of TLS + allow implementations to negotiate the application-layer protocol + used on a given connection. TLS provides the ALPN values in + cleartext during the initial handshake. While exposing the ALPN does + not create the same privacy issues as exposing the SNI, there is + still a risk. For example, some networks may attempt to block + applications that they do not understand or that they wish users + would not use. + + In a sense, ALPN filtering could be very similar to the filtering of + specific port numbers exposed in some networks. This filtering by + ports has given rise to evasion tactics in which various protocols + are tunneled over HTTP in order to use open ports 80 or 443. + Filtering by ALPN would probably beget the same responses, in which + the applications just move over HTTP and only the HTTP ALPN values + are used. Applications would not need to do that if the ALPN were + hidden in the same way as the SNI. + + In addition to hiding the SNI, it is thus desirable to also hide the + ALPN. Of course, this implies engineering trade-offs. Using the + same technique for hiding the ALPN and encrypting the SNI may result + in excess complexity. It might be preferable to encrypt these + independently. + +3.7.2. Supporting Other Transports than TCP + + The TLS handshake is also used over other transports, such as UDP + with both DTLS [DTLS-1.3] and QUIC [QUIC]. The requirement to + encrypt the SNI applies just as well for these transports as for TLS + over TCP. + + This points to a requirement for SNI encryption mechanisms to also be + applicable to non-TCP transports such as DTLS or QUIC. + +4. HTTP Co-tenancy Fronting + + In the absence of TLS-level SNI encryption, many sites rely on an + "HTTP co-tenancy" solution, often referred to as "domain fronting" + [DOMFRONT]. The TLS connection is established with the fronting + server, and HTTP requests are then sent over that connection to the + hidden service. For example, the TLS SNI could be set to + "fronting.example.com" (the fronting server), and HTTP requests sent + over that connection could be directed to "hidden.example.com" + (accessing the hidden service). This solution works well in practice + when the fronting server and the hidden server are "co-tenants" of + the same multiplexed server. + + The HTTP domain fronting solution can be deployed without + modification to the TLS protocol and does not require using any + specific version of TLS. There are, however, a few issues regarding + discovery, client implementations, trust, and applicability: + + * The client has to discover that the hidden service can be accessed + through the fronting server. + + * The client's browser has to be directed to access the hidden + service through the fronting service. + + * Since the TLS connection is established with the fronting service, + the client has no cryptographic proof that the content does, in + fact, come from the hidden service. Thus, the solution does not + mitigate the context sharing issues described in Section 3.6. + Note that this is already the case for co-tenanted sites. + + * Since this is an HTTP-level solution, it does not protect non-HTTP + protocols, as discussed in Section 3.7. + + The discovery issue is common to most SNI encryption solutions. The + browser issue was solved in [DOMFRONT] by implementing domain + fronting as a pluggable transport for the Tor browser. The multi- + protocol issue can be mitigated by implementing other applications + over HTTP, for example, DNS over HTTPS [RFC8484]. The trust issue, + however, requires specific developments. + +4.1. HTTPS Tunnels + + The HTTP domain fronting solution places a lot of trust in the + fronting server. This required trust can be reduced by tunneling + HTTPS in HTTPS, which effectively treats the fronting server as an + HTTP proxy. In this solution, the client establishes a TLS + connection to the fronting server and then issues an HTTP connect + request to the hidden server. This will establish an end-to-end + HTTPS-over-TLS connection between the client and the hidden server, + mitigating the issues described in Section 3.6. + + The HTTPS-in-HTTPS solution requires double encryption of every + packet. It also requires that the fronting server decrypt and relay + messages to the hidden server. Both of these requirements make the + implementation onerous. + +4.2. Delegation Control + + Clients would see their privacy compromised if they contacted the + wrong fronting server to access the hidden service, since this wrong + server could disclose their access to adversaries. This requires a + controlled way to indicate which fronting server is acceptable by the + hidden service. + + This problem is similar to the "word of mouth" variant of the + "fronting server spoofing" attack described in Section 3.6. The + spoofing would be performed by distributing fake advice, such as "to + reach hidden.example.com, use fake.example.com as a fronting server", + when "fake.example.com" is under the control of an adversary. + + In practice, this attack is well mitigated when the hidden service is + accessed through a specialized application. The name of the fronting + server can then be programmed in the code of the application. But + the attack is harder to mitigate when the hidden service has to be + accessed through general-purpose web browsers. + + There are several proposed solutions to this problem, such as + creating a special form of certificate to codify the relation between + the fronting and hidden server or obtaining the relation between the + hidden and fronting service through the DNS, possibly using DNSSEC, + to avoid spoofing. The experiment described in [DOMFRONT] solved the + issue by integrating with the Lantern Internet circumvention tool. + + We can observe that CDNs have a similar requirement. They need to + convince the client that "www.example.com" can be accessed through + the seemingly unrelated "cdn-node-xyz.example.net". Most CDNs have + deployed DNS-based solutions to this problem. However, the CDN often + holds the authoritative certificate of the origin. There is, + simultaneously, verification of a relationship between the origin and + the CDN (through the certificate) and a risk that the CDN can spoof + the content from the origin. + +4.3. Related Work + + The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag + content provided by the hidden server. Secondary certificate + authentication [HTTP2-SEC-CERTS] can be used to manage authentication + of hidden server content or to perform client authentication before + accessing hidden content. + +5. Security Considerations + + This document lists a number of attacks against SNI encryption in + Sections 3 and 4.2 and presents a list of requirements to mitigate + these attacks. Current HTTP-based solutions described in Section 4 + only meet some of these requirements. In practice, it may well be + that no solution can meet every requirement and that practical + solutions will have to make some compromises. + + In particular, the requirement to not stick out, presented in + Section 3.4, may have to be lifted, especially for proposed solutions + that could quickly reach large-scale deployments. + + Replacing cleartext SNI transmission by an encrypted variant will + break or reduce the efficacy of the operational practices and + techniques implemented in middleboxes, as described in Section 2.1. + As explained in Section 2.3, alternative solutions will have to be + developed. + +6. IANA Considerations + + This document has no IANA actions. + +7. Informative References + + [DOMFRONT] Fifield, D., Lan, C., Hynes, R., Wegmann, P., and V. + Paxson, "Blocking-resistant communication through domain + fronting", DOI 10.1515/popets-2015-0009, 2015, + <https://www.bamsoftware.com/papers/fronting/>. + + [DTLS-1.3] Rescorla, E., Tschofenig, H., and N. Modadugu, "The + Datagram Transport Layer Security (DTLS) Protocol Version + 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- + dtls13-38, 29 May 2020, + <https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>. + + [HTTP2-SEC-CERTS] + Bishop, M., Sullivan, N., and M. Thomson, "Secondary + Certificate Authentication in HTTP/2", Work in Progress, + Internet-Draft, draft-ietf-httpbis-http2-secondary-certs- + 06, 14 May 2020, <https://tools.ietf.org/html/draft-ietf- + httpbis-http2-secondary-certs-06>. + + [QUIC] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", + Work in Progress, Internet-Draft, draft-ietf-quic-tls-29, + 9 June 2020, + <https://tools.ietf.org/html/draft-ietf-quic-tls-29>. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, DOI 10.17487/RFC2246, January 1999, + <https://www.rfc-editor.org/info/rfc2246>. + + [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over + Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, + February 2002, <https://www.rfc-editor.org/info/rfc3207>. + + [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, + <https://www.rfc-editor.org/info/rfc3546>. + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, + DOI 10.17487/RFC4346, April 2006, + <https://www.rfc-editor.org/info/rfc4346>. + + [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, + <https://www.rfc-editor.org/info/rfc4366>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <https://www.rfc-editor.org/info/rfc5246>. + + [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) + Extensions: Extension Definitions", RFC 6066, + DOI 10.17487/RFC6066, January 2011, + <https://www.rfc-editor.org/info/rfc6066>. + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, <https://www.rfc-editor.org/info/rfc7258>. + + [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext + Transfer Protocol Version 2 (HTTP/2)", RFC 7540, + DOI 10.17487/RFC7540, May 2015, + <https://www.rfc-editor.org/info/rfc7540>. + + [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer + Security (TLS) in the Extensible Messaging and Presence + Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June + 2015, <https://www.rfc-editor.org/info/rfc7590>. + + [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., + and P. Hoffman, "Specification for DNS over Transport + Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May + 2016, <https://www.rfc-editor.org/info/rfc7858>. + + [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: + Use of Transport Layer Security (TLS) for Email Submission + and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, + <https://www.rfc-editor.org/info/rfc8314>. + + [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", + RFC 8336, DOI 10.17487/RFC8336, March 2018, + <https://www.rfc-editor.org/info/rfc8336>. + + [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of + Pervasive Encryption on Operators", RFC 8404, + DOI 10.17487/RFC8404, July 2018, + <https://www.rfc-editor.org/info/rfc8404>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS + (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, + <https://www.rfc-editor.org/info/rfc8484>. + +Acknowledgements + + A large part of this document originated in discussion of SNI + encryption on the TLS WG mailing list, including comments after the + tunneling approach was first proposed in a message to that list: + <https://mailarchive.ietf.org/arch/msg/tls/ + tXvdcqnogZgqmdfCugrV8M90Ftw>. + + Thanks to Eric Rescorla for his multiple suggestions, reviews, and + edits to the successive draft versions of this document. + + Thanks to Daniel Kahn Gillmor for a pretty detailed review of the + initial draft of this document. Thanks to Bernard Aboba, Mike + Bishop, Alissa Cooper, Roman Danyliw, Stephen Farrell, Warren Kumari, + Mirja Kuelewind, Barry Leiba, Martin Rex, Adam Roach, Meral + Shirazipour, Martin Thomson, Eric Vyncke, and employees of the UK + National Cyber Security Centre for their reviews. Thanks to Chris + Wood, Ben Kaduk, and Sean Turner for helping move this document + toward publication. + +Author's Address + + Christian Huitema + Private Octopus Inc. + Friday Harbor, WA 98250 + United States of America + + Email: huitema@huitema.net |