RFC 8744

Issues and Requirements for Server Name Identification (SNI) Encryption in TLS

📅 published July 2020, from ietf

RFC 8744: Issues and Requirements for Server Name Identification (SNI) Encryption in TLS 🎀

Okay bestie, this RFC is the Internet Engineering Task Force (IETF) doc numbered RFC 8744, and it was written by C. Huitema from Private Octopus Inc. 🐙 It's Informational category (not a Standards Track spec, so it's a "here's what we learned" doc, not a "you MUST do this" doc, lol). It came out in July 2020, and its ISSN is 2070-1721 ✨. The header doesn't list anything it obsoletes or updates, so it just stands on its own 💅

Abstract

okay so the big picture: this doc is about the general problem of encrypting the Server Name Identification (SNI) TLS parameter 🔒 The solutions people have proposed hide a hidden service behind a fronting service, so outside observers only ever see the SNI of the fronting service 👀 The doc lists the known attacks against SNI encryption, talks about the current "HTTP co-tenancy" solution, and lays out requirements for future TLS-layer solutions 🧚

Real talk though: in practice, it may well be that no solution can meet every requirement, so practical solutions will have to make some compromises 💀 Not everything can be perfect, babe 🫶

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 (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 ✨

Okay so historically, adversaries have been able to watch what people do with web services through three main channels 👀: looking at DNS requests, looking at IP addresses in packet headers, and looking at the data stream between the user and the services. Those channels are getting progressively closed 🔐 A growing chunk of Internet traffic is encrypted, mostly with Transport Layer Security (TLS) [RFC8446] 💖

Deployments like DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] are helping to hide DNS info, which is so iconic 🙌 Also, more and more services are colocated on multiplexed servers, which loosens the link between an IP address and a web service 🧩 For example, with virtual hosting, multiple services can be co-tenants on the same server, so the IP address and port don't uniquely identify a service 🏠 In cloud or Content Delivery Network (CDN) setups, one platform hosts the services or servers of tons of organizations, so looking up what netblock an IP address belongs to reveals very little 🤷‍♀️

BUT, multiplexed servers rely on the Server Name Information (SNI) TLS extension [RFC6066] to send connections to the right service implementation 🎯 And this protocol element is sent in cleartext 😭 So as the other monitoring methods get blocked, monitoring focuses on that cleartext SNI. The whole purpose of SNI encryption is to stop that and help privacy 🫶

Replacing cleartext SNI transmission with an encrypted version will improve the privacy and reliability of TLS connections, but designing proper SNI encryption is genuinely hard 🥹 People have tried to define SNI encryption before, multiple times, and these attempts have generally floundered 💀 The simple designs fail to mitigate several of the attacks listed in Section 3. Without 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 doesn't present the design of a solution. Instead, it gives guidelines for evaluating proposed solutions 📝 (The review of HTTP-level solutions in Section 4 is not an endorsement of those solutions, just so we're clear 🙅‍♀️) The need for related work on encrypting 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 help manage "colocation servers", where 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, which lets the TLS connection get set up 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, but only the "hostname" variant was ever 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 🕵️‍♀️

SNI was defined to help manage servers, but middlebox developers figured out they could take advantage of that information 👀 Tons of examples of this are reviewed in [RFC8404]. Other examples came out during discussions of this document too. 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 wasn't flagged as a problem in the Security Considerations sections of [RFC3546], [RFC4366], or [RFC6066] 😅 These specs just didn't anticipate the alternative usage described in Section 2.1. One reason may be that, back when these RFCs were written, the SNI info was available through a bunch of other means, like tracking IP addresses, DNS names, or server certificates 🗂️

Many deployments still give different services different IP addresses, so the services can be identified by their IPs 📍 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 DNS queries. Most of the SNI usage described in Section 2.1 could also be done by monitoring DNS traffic or controlling DNS usage 👀 But this is changing with the rise of DNS resolvers offering services like DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484] 🔄

The subjectAltName extension of type dNSName of the server certificate (or, if that's absent, 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, which means there would be limited benefit 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, the deployment of DNS privacy, and the protection of server certificate transmissions all contribute to user privacy against an RFC 7258-style adversary [RFC7258] 🛡️ Encrypting the SNI complements this push for privacy and makes it harder to censor or otherwise give 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 will also break or reduce the efficacy of the operational practices and techniques implemented in middleboxes, as described in Section 2.1 😬 Most of those functions can, however, be done by other means. For example, some DNS service providers let customers "opt in" to filtering services for parental control and phishing protection 🍼 Per-stream QoS could be provided by a combo of packet marking and end-to-end agreements 📦 As SNI encryption becomes common, we can expect more deployment of these "end-to-end" solutions 💜

At the time of writing, enterprises have the option of installing a firewall that does SNI filtering to prevent connections to certain websites. With SNI encryption, that becomes ineffective 🧱 Obviously, managers could block usage of SNI encryption on 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 instead rely 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 to TLS 📮 A review of the TLS mailing list archives shows that many of these proposals looked 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 💅

okay so the simplest SNI encryption designs swap the cleartext SNI in the initial TLS exchange for an encrypted value, using a key that the multiplexed server knows 🔐. But no matter what encryption you use, these designs can get wrecked by a super simple cut-and-paste attack, and it goes like this:

  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 big goals of SNI encryption is to stop adversaries from knowing which hidden service the client is using 🙈. Successful cut-and-paste attacks wreck that goal, because they let adversaries discover that service anyway.

3.2. Avoid Widely Shared Secrets 🔑

it's so tempting to think of simple schemes where the SNI is encrypted or hashed using a shared secret, but ngl these are super fragile. The symmetric key has to be known by the multiplexed server and by every user of the protected services. So the compromise of a single user would compromise the entire set of users and protected services. Not it 💀.

3.3. Prevent SNI-Based Denial-of-Service Attacks 🛡️

encrypting the SNI may create extra load for the multiplexed server. Adversaries can launch denial-of-service (DoS) attacks by generating random encrypted SNI values and forcing the multiplexed server to burn resources on useless decryption attempts.

You could argue this isn't a big deal, since regular TLS connection attempts also make the server do a bunch of cryptographic operations. But in lots of cases, the SNI decryption has to be done by a front-end component with limited resources, while the TLS operations are handled by the component dedicated to each service. So SNI-based DoS attacks could target that front-end component, and that's the part we need to protect 🫶.

3.4. Do Not Stick Out 🦋

in some designs, handshakes using SNI encryption can be easily told apart 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 happened, detecting 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 won't 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 were compromised, adversaries could process archival records of past connections and retrieve the protected SNI used in those connections. These designs fail to maintain forward secrecy of SNI encryption, and that's a whole mood 😤.

3.6. Enable Multi-party Security Contexts 🎀

we can design solutions where 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 checking 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 where the master secret is verified by checking 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 won't 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's 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, adversaries would also be able to pressure the fronting service into intercepting or spoofing the communications between client and protected service.

Adversaries could also 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 in the fronting server, the fake server could also serve fake content of its own choosing, including various forms of malware 💀.

The honeypot threat is real, so the fronting service has to be authenticated, not just trusted by vibes.

There are two main channels adversaries can use for this attack. They can simply try to mislead users into believing the honeypot is a valid fronting server, especially if that information is carried by word of mouth or in unprotected DNS records. They can also try to hijack 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 doesn't stop with HTTP over TLS. Lots of other applications use TLS too, including, for example, SMTP [RFC3207], DNS [RFC7858], IMAP [RFC8314], and the Extensible Messaging and Presence Protocol (XMPP) [RFC7590]. These applications will benefit from SNI encryption too. HTTP-only methods, like those described in Section 4.1, wouldn't apply there. Even for the HTTPS case, the HTTPS tunneling service described in Section 4.1 works with HTTP 1.0 and HTTP 1.1, but it interacts awkwardly with the multiple streams feature of HTTP/2 [RFC7540]. This points to the need for an application-agnostic solution, one that 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 let implementations negotiate the application-layer protocol used on a given connection. TLS provides the ALPN values in cleartext during the initial handshake. Exposing the ALPN doesn't create the same privacy issues as exposing the SNI, but there's still a risk. For example, some networks may try to block applications they don't understand, or that they'd rather users didn't use.

ALPN filtering could be very similar to the filtering of specific port numbers that some networks do. That port filtering has given rise to evasion tactics, where various protocols get tunneled over HTTP so they can use open ports 80 or 443. Filtering by ALPN would probably beget the same responses, where applications just move over HTTP and only the HTTP ALPN values get used. Applications wouldn't need to do that if the ALPN were hidden in the same way as the SNI 🏃‍♀️.

So in addition to hiding the SNI, it's also desirable to 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, so 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, like UDP with both DTLS [DTLS-1.3] and QUIC [QUIC]. The requirement to encrypt the SNI applies just as well to these transports as it does to 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 ✨

without TLS-level SNI encryption, many sites rely on an "HTTP co-tenancy" solution, often called "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 any modification to the TLS protocol, and it doesn't require using any specific version of TLS. There are, however, a few issues around 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. That 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 establishes an end-to-end HTTPS-over-TLS connection between the client and the hidden server, which mitigates 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 ✨

okay so this one is about trust 🫣 If a client accidentally contacts the wrong fronting server to reach the hidden service, that wrong server could tell adversaries that the client is accessing it. So the hidden service needs a controlled way to say which fronting server is acceptable. 🔐

This is basically the "word of mouth" version of the fronting server spoofing attack from Section 3.6. Imagine someone spreading fake advice like "to reach hidden.example.com, use fake.example.com as a fronting server," when fake.example.com is run by an adversary. Yikes 💀

In practice, this attack is pretty well handled when the hidden service is accessed through a specialized app. The fronting server's name can just be hardcoded into the app's code, so no bad advice is needed 🙌 But it gets way harder when people have to use general-purpose web browsers. Those are the real main character problem here 😭

There are a few proposed fixes. One is a special kind of certificate that spells out the relationship between the fronting server and the hidden server. Another is getting that relationship through DNS, possibly with DNSSEC, so nobody can spoof it. The experiment in [DOMFRONT] solved this by integrating with the Lantern Internet circumvention tool, which is seriously iconic 🧚

CDNs have the same kind of problem, bestie 🌸 They need to convince the client that "www.example.com" can be reached through the seemingly unrelated "cdn-node-xyz.example.net." Most CDNs have rolled out DNS-based solutions for this. The catch is that the CDN often holds the origin's authoritative certificate. So there's a verified relationship between the origin and the CDN (through that certificate), but there's also a risk that the CDN could spoof content from the origin. Tricky, tricky 👀

The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag content provided by the hidden server. Also, Secondary certificate authentication [HTTP2-SEC-CERTS] can be used to manage authentication of hidden server content, or to do client authentication before accessing hidden content. Both are lowkey useful tools to have in your kit 🧰

5. Security Considerations 💖

Okay, this part is really serious, so let's be real 😤 This document lists a number of attacks against SNI encryption in Sections 3 and 4.2, and it presents a list of requirements to mitigate those attacks. The 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. Hard truth, but it's the truth 💅

In particular, the requirement to not stick out, presented in Section 3.4, may have to be lifted. That's especially true for proposed solutions that could quickly reach large-scale deployments. ⚠️

Replacing cleartext SNI transmission with 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. So yes, this is a real trade-off, and we're gonna need new ideas 🔥

6. IANA Considerations 🌈

This document has no IANA actions. Nothing to register here, periodt ✨

7. Informative References 📚

These are the references, bestie. Here's the whole list, exactly as written 🫶

[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 came out of 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.

Huge 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
📦 where this page comes from