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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/