draft-ietf-tls-sni-encryption-05.txt   draft-ietf-tls-sni-encryption-06.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Private Octopus Inc. Internet-Draft Private Octopus Inc.
Intended status: Informational E. Rescorla Intended status: Informational E. Rescorla
Expires: February 16, 2020 RTFM, Inc. Expires: March 20, 2020 RTFM, Inc.
August 15, 2019 September 17, 2019
Issues and Requirements for SNI Encryption in TLS Issues and Requirements for SNI Encryption in TLS
draft-ietf-tls-sni-encryption-05 draft-ietf-tls-sni-encryption-06
Abstract Abstract
This draft describes the general problem of encrypting the Server This draft 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. The draft lists known
attacks against SNI encryption, discusses the current "co-tenancy attacks against SNI encryption, discusses the current "co-tenancy
fronting" solution, and presents requirements for future TLS layer fronting" solution, and presents requirements for future TLS layer
solutions. solutions.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 16, 2020. This Internet-Draft will expire on March 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2.3. End-to-end alternatives . . . . . . . . . . . . . . . . . 5 2.3. End-to-end alternatives . . . . . . . . . . . . . . . . . 5
3. Security and Privacy Requirements for SNI Encryption . . . . 5 3. Security and Privacy Requirements for SNI Encryption . . . . 5
3.1. Mitigate Replay Attacks . . . . . . . . . . . . . . . . . 5 3.1. Mitigate Replay Attacks . . . . . . . . . . . . . . . . . 5
3.2. Avoid Widely Shared Secrets . . . . . . . . . . . . . . . 6 3.2. Avoid Widely Shared Secrets . . . . . . . . . . . . . . . 6
3.3. Prevent SNI-based Denial of Service Attacks . . . . . . . 6 3.3. Prevent SNI-based Denial of Service Attacks . . . . . . . 6
3.4. Do not stick out . . . . . . . . . . . . . . . . . . . . 6 3.4. Do not stick out . . . . . . . . . . . . . . . . . . . . 6
3.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 7 3.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 7
3.6. Multi-Party Security Contexts . . . . . . . . . . . . . . 7 3.6. Multi-Party Security Contexts . . . . . . . . . . . . . . 7
3.7. Supporting multiple protocols . . . . . . . . . . . . . . 8 3.7. Supporting multiple protocols . . . . . . . . . . . . . . 8
3.7.1. Hiding the Application Layer Protocol Negotiation . . 8 3.7.1. Hiding the Application Layer Protocol Negotiation . . 8
3.7.2. Support other transports than TCP . . . . . . . . . . 8 3.7.2. Support other transports than TCP . . . . . . . . . . 9
4. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 9 4. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 9
4.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 10 4.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Delegation Control . . . . . . . . . . . . . . . . . . . 10 4.2. Delegation Control . . . . . . . . . . . . . . . . . . . 10
4.3. Related work . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Related work . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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) [RFC5246].
Progressive deployment of solutions like DNS in TLS [RFC7858] and DNS Progressive deployment of solutions like DNS in TLS [RFC7858] and DNS
over HTTPS [RFC8484] mitigates the disclosure of DNS information. 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. However, loosening the relation between IP address and web service. However,
multiplexed servers rely on the Service Name Information (SNI) TLS multiplexed servers rely on the Service Name Information (SNI) TLS
extension to direct connections to the appropriate service extension to direct connections to the appropriate service
implementation. This protocol element is transmitted in clear text. implementation. This protocol element is transmitted in clear text.
As the other methods of monitoring get blocked, monitoring focuses on As the other methods of monitoring get blocked, monitoring focuses on
the clear text SNI. The purpose of SNI encryption and privacy is to the clear text SNI. The purpose of SNI encryption and privacy is to
prevent that. prevent that.
In the past, there have been multiple attempts at defining SNI Replacing clear text SNI transmission by an encrypted variant will
encryption. These attempts have generally floundered, because the improve the privacy and reliability of TLS connections, but the
simple designs fail to mitigate several of the attacks listed in design of proper SNI encryption solutions is difficult. In the past,
Section 3. In the absence of a TLS-level solution, the most popular there have been multiple attempts at defining SNI encryption. These
approach to SNI privacy for web services is HTTP-level fronting, attempts have generally floundered, because the simple designs fail
which we discuss in Section 4. 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 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 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 mutiple web sites the same IP address. A typical example would be multiple web sites
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 clear text in the TLS
"ClientHello" message. "ClientHello" message.
skipping to change at page 3, line 41 skipping to change at page 4, line 4
"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, though the The SNI was defined to facilitate management of servers, though the
developers of middleboxes soon found out that they could take developers of middleboxes soon found out that they could take
advantage of the information. Many examples of such usage are advantage of the information. Many examples of such usage are
reviewed in [RFC8404]. They include: reviewed in [RFC8404]. They include:
o Monitoring and identification of specific sites, o Monitoring and identification of specific sites,
o Content filtering by ISP blocking specific web sites in order to o Content filtering by ISP blocking specific web sites in order to
implement "parental controls", or to prevent access to phishing or implement "parental controls", or to prevent access to phishing or
other fradulent web sites. other fraudulent web sites.
o ISP assigning different QoS profiles to target services, o ISP assigning different QoS profiles to target services,
o Firewalls within enterprise networks blocking web sites not deemed o Firewalls within enterprise networks blocking web sites not deemed
appropriate for work, or appropriate for work, or
o Firewalls within enterprise networks exempting specific web sites o Firewalls within enterprise networks exempting specific web sites
from MITM inspection, such as healthcare or financial sites for from Man-In-The-Middle (MITM) inspection, such as healthcare or
which inspection would intrude with the privacy of employees. financial sites for which inspection would intrude on the privacy
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. metadata by pervasive surveillance actors.
2.2. SNI encryption timeliness 2.2. SNI encryption timeliness
The clear-text transmission of the SNI was not flagged as a problem The clear-text transmission of the SNI was not flagged as a problem
in the security consideration sections of [RFC3546], [RFC4366], or in the security consideration sections of [RFC3546], [RFC4366], or
[RFC6066]. These specifications did not anticipate the alternative [RFC6066]. These specifications did not anticipate the alternative
uses and abuses described in Section 2.1. One reason may be that, uses and abuses described in Section 2.1. One reason may be that,
skipping to change at page 4, line 44 skipping to change at page 5, line 6
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, expose the
same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346], same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346],
and 1.2 [RFC5246], servers send certificates in clear text, ensuring and 1.2 [RFC5246], servers send certificates in clear text, ensuring
that there would be limited benefits in hiding the SNI. However, in that there would be limited benefits in hiding the SNI. However, in
TLS 1.3 [RFC8446], server certificates are encrypted in transit. TLS 1.3 [RFC8446], server certificates are encrypted in transit.
Note that encryption alone is insufficient to protect server Note that encryption alone is insufficient to protect server
certificates; see Section 3.1 for details. 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 certificates transmissions all privacy, and protection of server certificate transmissions all
contribute to user privacy in the face of an [RFC3552]-style contribute to user privacy in the face of an [RFC3552]-style
adversary. Encrypting the SNI now will complete this push for adversary. Encrypting the SNI now will complete this push for
privacy and make it harder to censor or otherwise provide privacy and make it harder to censor or otherwise provide
differential treatment to specific internet services. differential treatment to specific internet services.
2.3. End-to-end alternatives 2.3. End-to-end alternatives
Deploying SNI encryption will help thwarting most of the Deploying SNI encryption will help thwart most of the "unanticipated"
"unanticipated" SNI usages described in Section 2.1, including SNI usages described in Section 2.1, including censorship and
censorship and pervasive surveillance. It will also thwart functions pervasive surveillance. It will also thwart functions that are
that are sometimes described as legitimate. Most of these functions sometimes described as legitimate. Most of these functions can,
can however be realized by other means. For example, some DNS however, be realized by other means. For example, some DNS service
service providers offer customers the provision to "opt in" filtering providers offer customers the provision to "opt in" filtering
services for parental control and phishing protection. Per-stream services for parental control and phishing protection. Per-stream
QoS can be provided by a combination of packet marking and end-to-end QoS can be provided by a combination of packet marking and end-to-end
agreements. As SNI encryption becomes common, we can expect more agreements. As SNI encryption becomes common, we can expect more
deployment of such "end-to-end" solutions. deployment of such "end-to-end" solutions.
At the moment, enterprises have the option of installing a firewall At the moment, enterprises have the option of installing a firewall
performing SNI filtering to prevent connections to certain websites. performing SNI filtering to prevent connections to certain websites.
With SNI encryption this becomes ineffective. Obviously, managers With SNI encryption this becomes ineffective. Obviously, managers
could block usage of SNI encryption in enterprise computers, but this could block usage of SNI encryption in enterprise computers, but this
wide-scale blocking would diminish the privacy protection of traffic wide-scale blocking would diminish the privacy protection of traffic
skipping to change at page 5, line 41 skipping to change at page 5, line 48
promising, though were rejected after security reviews identified promising, though were rejected after security reviews identified
plausible attacks. In this section, we collect a list of these known plausible attacks. In this section, we collect a list of these known
attacks. attacks.
3.1. Mitigate Replay Attacks 3.1. Mitigate Replay Attacks
The simplest SNI encryption designs replace in the initial TLS The simplest SNI encryption designs replace in the initial TLS
exchange the clear text SNI with an encrypted value, using a key exchange the clear text SNI with an encrypted value, using a key
known to the multiplexed server. Regardless of the encryption used, known to the multiplexed server. Regardless of the encryption used,
these designs can be broken by a simple replay attack, which works as these designs can be broken by a simple replay attack, which works as
follow: 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 server,
including in its connection parameters the encrypted SNI copied from including in its connection parameters the encrypted SNI copied from
the observed exchange. the observed exchange.
4- The multiplexed server establishes the connection to the protected 4- The multiplexed server establishes the connection to the protected
service, thus revealing the identity of the service. service, 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 replay
attacks breaks that goal by allowing adversaries to discover that attacks break that goal by allowing adversaries to discover that
service. 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 users 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 attacks by generating random
encrypted SNI values and forcing the multiplexed server to spend encrypted SNI values and forcing the multiplexed server to spend
resources in useless decryption attempts. resources in useless decryption attempts.
skipping to change at page 6, line 46 skipping to change at page 7, line 6
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 Client Hello packets, or specific
values of the clear text SNI parameter. If adversaries can easily values of the clear text 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 was 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 3.5. Forward Secrecy
The general concerns about forward secrecy apply to SNI encryption The general concerns about forward secrecy apply to SNI encryption
just as well as to regular TLS sessions. For example, some proposed 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 designs rely on a public key of the multiplexed server to define the
SNI encryption key. If the corresponding private key was SNI encryption key. If the corresponding private key should be
compromised, the adversaries would be able to process archival compromised, the adversaries would be able to process archival
records of past connections, and retrieve the protected SNI used in records of past connections, and retrieve the protected SNI used in
these connections. These designs failed to maintain forward secrecy these connections. These designs failed to maintain forward secrecy
of SNI encryption. of SNI encryption.
3.6. Multi-Party Security Contexts 3.6. Multi-Party Security Contexts
We can design solutions in which a fronting service act as a relay to We can design solutions in which a fronting service acts as a relay
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 Man-In-The-Middle attack by the fronting
service. Even if the client has some reasonable trust in this service. Even if the client has some reasonable trust in this
service, the possibility of MITM attack is troubling. service, the possibility of 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 a Man-In-The- service. These solutions offer more protection against MITM attack
Middle attack by the fronting service. The downside is the the by the fronting service. The downside is that the client will not
client will not verify the identity of the fronting service with verify the identity of the fronting service, which enables fronting
risks discussed in , but solutions will have to mitigate this risks. server spoofing attacks such as the "honeypot" attack discussed
Overall, end-to-end TLS to the protected service is preferable. 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, 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 MITM is possible, the
adversaries would also be able to pressure the fronting service into adversaries would also be able to pressure the fronting service into
intercepting or spoofing the communications between client and 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
skipping to change at page 8, line 6 skipping to change at page 8, line 14
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. Supporting 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 example Multiple other applications currently use TLS, including, for
SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590]. These applications example, SMTP [RFC5246], DNS [RFC7858], IMAP [RFC2595], and XMPP
too will benefit of SNI encryption. HTTP only methods like those [RFC7590]. These applications, too, will benefit from SNI
described in Section 4.1 would not apply there. In fact, even for encryption. HTTP-only methods like those described in Section 4.1
the HTTPS case, the HTTPS tunneling service described in Section 4.1 would not apply there. In fact, even for the HTTPS case, the HTTPS
is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly tunneling service described in Section 4.1 is compatible with HTTP
with the multiple streams feature of HTTP 2.0 [RFC7540]. This points 1.0 and HTTP 1.1, but interacts awkwardly with the multiple streams
to the need of an application-agnostic solution, that would be feature of HTTP/2 [RFC7540]. This points to the need for an
implemented fully in the TLS layer. application-agnostic 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 clear
text during the initial handshake. While exposing the ALPN does not text during the initial handshake. While exposing the ALPN does not
create the same privacy issues as exposing the SNI, there is still a create the same privacy issues as exposing the SNI, there is still a
risk. For example, some networks may attempt to block applications risk. For example, some networks may attempt to block applications
that they do not understand, or that they wish users would not use. 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 network. 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 was 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. Support 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 with
both DTLS [I-D.ietf-tls-dtls13] and QUIC [I-D.ietf-quic-tls]. The both DTLS [I-D.ietf-tls-dtls13] and QUIC [I-D.ietf-quic-tls]. The
requirement to encrypt the SNI apply just as well for these requirement to encrypt the SNI applies just as well for these
transports as for TLS over TCP. transports as for TLS 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. The TLS connection is established with "HTTP Co-Tenancy" solution. The TLS connection is established with
the fronting server, and HTTP requests are then sent over that the fronting server, and HTTP requests are then sent over that
connection to the hidden service. For example, the TLS SNI could be connection to the hidden service. For example, the TLS SNI could be
set to "fronting.example.com", the fronting server, and HTTP requests set to "fronting.example.com", the fronting server, and HTTP requests
sent over that connection could be directed to "hidden.example.com", sent 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-tenant" of the when the fronting server and the hidden server are "co-tenants" of
same multiplexed server. the same multiplexed server.
The HTTP fronting solution can be deployed without modification to The HTTP fronting solution can be deployed without modification to
the TLS protocol, and does not require using any specific version of the TLS protocol, and does not require using any specific version of
TLS. There are however a few issues regarding discovery, client TLS. There are, however, a few issues regarding discovery, client
implementations, trust, and applicability: implementations, trust, and applicability:
o The client has to discover that the hidden service can be accessed o The client has to discover that the hidden service can be accessed
through the fronting server. through the fronting server.
o The client browser's has to be directed to access the hidden o 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, o 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. The solution does thus not
mitigate the context sharing issues described in Section 3.6. mitigate the context sharing issues described in Section 3.6.
o Since this is an HTTP-level solution, it would not protect non- o Since this is an HTTP-level solution, it would not protect non-
HTTP protocols such as DNS over TLS [RFC7858] or IMAP over TLS HTTP protocols as discussed in Section 3.7.
[RFC2595].
The discovery issue is common to most SNI encryption solutions. The The discovery issue is common to most SNI encryption solutions. The
browser issue may be solved by developing a browser extension that browser issue may be solved by developing a browser extension that
support HTTP Fronting, and manages the list of fronting services support HTTP Fronting, and manages the list of fronting services
associated with the hidden services that the client uses. The multi- associated with the hidden services that the client uses. The multi-
protocol issue can be mitigated by using implementation of other protocol issue can be mitigated by using implementation of other
applications over HTTP, such as for example DNS over HTTPS [RFC8484]. applications over HTTP, such as for example DNS over HTTPS [RFC8484].
The trust issue, however, requires specific developments. The trust issue, however, requires specific developments.
4.1. HTTPS Tunnels 4.1. HTTPS Tunnels
skipping to change at page 10, line 17 skipping to change at page 10, line 21
The HTTP Fronting solution places a lot of trust in the Fronting The HTTP Fronting solution places a lot of trust in the Fronting
Server. This required trust can be reduced by tunnelling HTTPS in Server. This required trust can be reduced by tunnelling HTTPS in
HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. HTTPS, which effectively treats the Fronting Server as an HTTP Proxy.
In this solution, the client establishes a TLS connection to the In this solution, the client establishes a TLS connection to the
Fronting Server, and then issues an HTTP Connect request 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 Hidden Server. This will establish an end-to-end HTTPS over TLS
connection between the client and the Hidden Server, mitigating the connection between the client and the Hidden Server, mitigating the
issues described in Section 3.6. 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 decrypts 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 ferver 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 both similar and different from the "fronting server
spoofing" attack described in Section 3.6. Here, the spoofing would spoofing" attack described in Section 3.6. Here, the spoofing would
be performed by distributing fake advice, such as "to reach example be performed by distributing fake advice, such as "to reach
hidden.example.com, use fake.example.com as a fronting server", when hidden.example.com, use fake.example.com as a fronting server", when
"fake.example.com" is under the control of an adversary. "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 much harder to mitigate when the hidden service has to the attack is much harder to mitigate when the hidden service has to
be accessed through general purpose web browsers. The browsers will be accessed through general purpose web browsers. The browsers will
need a mechanism to obtain the fronting server indication in a secure need a mechanism to obtain the fronting server indication in a secure
way. way.
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 fronting and hidden server, or obtaining the relation between hidden
and fronting service through the DNS, possibly using DNSSEC to avoid and fronting service through the DNS, possibly using DNSSEC to avoid
spoofing. spoofing.
We can observe that content distribution network have a similar We can observe that content distribution networks (CDNs) have a
requirement. They need to convince the client that "www.example.com" similar requirement. They need to convince the client that
can be accessed through the seemingly unrelated "cdn-node- "www.example.com" can be accessed through the seemingly unrelated
xyz.example.net". Most CDNs have deployed DNS-based solutions to "cdn-node-xyz.example.net". Most CDNs have deployed DNS-based
this problem. 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 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 [I-D.ietf-httpbis-http2-secondary-certs] can be used
to manage authentication of hidden server content, or to perform to manage authentication of hidden server content, or to perform
client authentication before accessing hidden content. client authentication before accessing hidden content.
5. Security Considerations 5. Security Considerations
Replacing clear text 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. This
document does not present the design of a solution, but provides
guidelines for evaluating proposed solutions.
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 Section 3, and also in Section 4.2, and presents a list of
requirements to mitigate these attacks. The current HTTP based requirements to mitigate these attacks. Current HTTP-based solutions
solutions described in Section 4 only meet some of these described in Section 4 only meet some of these requirements. In
requirements. In practice, it may well be that no solution can meet practice, it may well be that no solution can meet every requirement,
every requirement, and that practical solutions will have to make and that practical solutions will have to make some compromises.
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
also thwart MITM interferences that are sometimes described as
legitimate. As explained in Section 2.3, alternative solutions will
have to be developed.
6. IANA Considerations 6. IANA Considerations
This draft does not require any IANA action. This draft does not require any IANA action.
7. Acknowledgements 7. Acknowledgements
A large part of this draft originates in discussion of SNI encryption A large part of this draft originates in discussion of SNI encryption
on the TLS WG mailing list, including comments after the tunneling on the TLS WG mailing list, including comments after the tunneling
approach was first proposed in a message to that list: approach was first proposed in a message to that list:
<https://mailarchive.ietf.org/arch/msg/tls/ <https://mailarchive.ietf.org/arch/msg/tls/
tXvdcqnogZgqmdfCugrV8M90Ftw>. tXvdcqnogZgqmdfCugrV8M90Ftw>.
Thanks to Daniel Kahn Gillmor for a pretty detailed review of the Thanks to Daniel Kahn Gillmor for a pretty detailed review of the
initial draft. Thanks to Stephen Farrell, Martin Rex Martin Thomson initial draft. Thanks to Bernard Aboba, Mike Bishop, Stephen
Farrell, Barry Leiba, Martin Rex, Meral Shirazipour, Martin Thomson
and employees of the UK National Cyber Security Centre for their and employees of the UK National Cyber Security Centre for their
reviews. reviews.
8. Informative References 8. Informative References
[I-D.ietf-httpbis-http2-secondary-certs] [I-D.ietf-httpbis-http2-secondary-certs]
Bishop, M., Sullivan, N., and M. Thomson, "Secondary Bishop, M., Sullivan, N., and M. Thomson, "Secondary
Certificate Authentication in HTTP/2", draft-ietf-httpbis- Certificate Authentication in HTTP/2", draft-ietf-httpbis-
http2-secondary-certs-04 (work in progress), April 2019. http2-secondary-certs-04 (work in progress), April 2019.
[I-D.ietf-quic-tls] [I-D.ietf-quic-tls]
Thomson, M. and S. Turner, "Using TLS to Secure QUIC", Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
draft-ietf-quic-tls-22 (work in progress), July 2019. draft-ietf-quic-tls-23 (work in progress), September 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-32 (work in progress), July 1.3", draft-ietf-tls-dtls13-32 (work in progress), July
2019. 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>.
 End of changes. 38 change blocks. 
78 lines changed or deleted 91 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/