doc: Add RFC documents

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