draft-ietf-tls-sni-encryption-06.txt   draft-ietf-tls-sni-encryption-07.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: March 20, 2020 RTFM, Inc. Expires: March 26, 2020 RTFM, Inc.
September 17, 2019 September 23, 2019
Issues and Requirements for SNI Encryption in TLS Issues and Requirements for SNI Encryption in TLS
draft-ietf-tls-sni-encryption-06 draft-ietf-tls-sni-encryption-07
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 March 20, 2020. This Internet-Draft will expire on March 26, 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 20 skipping to change at page 2, line 20
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. History of the TLS SNI extension . . . . . . . . . . . . . . 3 2. History of the TLS SNI extension . . . . . . . . . . . . . . 3
2.1. Unanticipated usage of SNI information . . . . . . . . . 3 2.1. Unanticipated usage of SNI information . . . . . . . . . 3
2.2. SNI encryption timeliness . . . . . . . . . . . . . . . . 4 2.2. SNI encryption timeliness . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. Informative References . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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. For
multiplexed servers rely on the Service Name Information (SNI) TLS example, in virtual hosting solutions, multiple services can be
extension to direct connections to the appropriate service 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
Networks (CDNs) solutions, a given platform hosts the services or
servers servers of a lot of organization, and looking up to what
netblock an IP address belongs reveals little. However, multiplexed
servers rely on the Service Name Information (SNI) TLS extension
[RFC6066] 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.
Replacing clear text SNI transmission by an encrypted variant will Replacing clear text 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
skipping to change at page 3, line 43 skipping to change at page 3, line 49
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.
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, but the
developers of middleboxes soon found out that they could take developers of middleboxes found out that they could take advantage of
advantage of the information. Many examples of such usage are the information. Many examples of such usage are reviewed in
reviewed in [RFC8404]. They include:
o Monitoring and identification of specific sites, [RFC8404]. Other examples came out during discussions of this draft.
o Content filtering by ISP blocking specific web sites in order to They include:
implement "parental controls", or to prevent access to phishing or
other fraudulent web sites. o Filtering or censorship of specific services for a variety of
reasons.
o Content filtering by network operators or ISP blocking specific
web sites in order to implement, for example, parental controls,
or to prevent access to phishing or 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 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. metadata by pervasive surveillance actors, for example to 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 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, usage described in Section 2.1. One reason may be that, when these
when these RFCs were written, the SNI information was available RFCs were written, the SNI information was available through a
through a variety of other means. variety of other means, such as tracking IP addresses, DNS names, or
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, content distribution networks (CDN) commonly addresses. However, CDNs commonly serve a large number of services
serve a large number of services through a comparatively small number through a comparatively small number of addresses.
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, 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 certificate 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 completes this push for privacy and
privacy and make it harder to censor or otherwise provide make it harder to censor or otherwise provide differential treatment
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 will help thwart most of the "unanticipated" Deploying SNI encryption helps thwart most of the unanticipated SNI
SNI usages described in Section 2.1, including censorship and usages including censorship and pervasive surveillance, but it also
pervasive surveillance. It will also thwart functions that are will break or reduce the efficacy of the operational practices and
sometimes described as legitimate. Most of these functions can, techniques implemented in middle-boxes as described in Section 2.1.
however, be realized by other means. For example, some DNS service Most of these functions can, however, be realized by other means.
providers offer customers the provision to "opt in" filtering For example, some DNS service providers offer customers the provision
services for parental control and phishing protection. Per-stream to "opt in" filtering services for parental control and phishing
QoS can be provided by a combination of packet marking and end-to-end protection. Per-stream QoS could be provided by a combination of
agreements. As SNI encryption becomes common, we can expect more packet marking and end-to-end agreements. As SNI encryption becomes
deployment of such "end-to-end" solutions. common, we can expect more deployment of such "end-to-end" solutions.
At the moment, enterprises have the option of installing a firewall At the time of this writing, enterprises have the option of
performing SNI filtering to prevent connections to certain websites. installing a firewall performing SNI filtering to prevent connections
With SNI encryption this becomes ineffective. Obviously, managers to certain websites. With SNI encryption this becomes ineffective.
could block usage of SNI encryption in enterprise computers, but this Obviously, managers could block usage of SNI encryption in enterprise
wide-scale blocking would diminish the privacy protection of traffic computers, but this wide-scale blocking would diminish the privacy
leaving the enterprise, which may not be desirable. Enterprise protection of traffic leaving the enterprise, which may not be
managers could rely instead on filtering software and management desirable. Enterprise managers could rely instead on filtering
software deployed on the enterprise's computers. software and management software deployed on the enterprise's
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. Many of these proposals appeared encryption option in TLS. A review of the TLS mailing list archives
promising, though were rejected after security reviews identified shows that many of these proposals appeared promising but were
plausible attacks. In this section, we collect a list of these known rejected after security reviews identified plausible attacks. In
attacks. this section, we collect a list of these known 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
follows: follows:
1- The user starts a TLS connection to the multiplexed server, 1- The user starts a TLS connection to the multiplexed server,
skipping to change at page 6, line 35 skipping to change at page 6, line 46
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.
It may be argued that this is not an important DOS avenue, as regular It may be argued that this is not an important Denial of Service
TLS connection attempts also require the server to perform a number Attacks (DoS) avenue, as regular TLS connection attempts also require
of cryptographic operations. However, in many cases, the SNI the server to perform a number of cryptographic operations. However,
decryption will have to be performed by a front-end component with in many cases, the SNI decryption will have to be performed by a
limited resources, while the TLS operations are performed by the front-end component with limited resources, while the TLS operations
component dedicated to their respective services. SNI-based DOS are performed by the component dedicated to their respective
attacks could target the front-end component. services. SNI-based DoS attacks could target the front-end
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 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.
skipping to change at page 8, line 21 skipping to change at page 8, line 34
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 Multiple other applications currently use TLS, including, for
example, SMTP [RFC5246], DNS [RFC7858], IMAP [RFC2595], and XMPP example, SMTP [RFC5246], DNS [RFC7858], IMAP [RFC8314], and XMPP
[RFC7590]. These applications, too, will benefit from SNI [RFC7590]. These applications, too, will benefit from SNI
encryption. HTTP-only methods like those described in Section 4.1 encryption. HTTP-only methods like those described in Section 4.1
would not apply there. In fact, even for the HTTPS case, the HTTPS would not apply there. In fact, even for the HTTPS case, the HTTPS
tunneling service described in Section 4.1 is compatible with HTTP tunneling service described in Section 4.1 is compatible with HTTP
1.0 and HTTP 1.1, but interacts awkwardly with the multiple streams 1.0 and HTTP 1.1, but interacts awkwardly with the multiple streams
feature of HTTP/2 [RFC7540]. This points to the need for an feature of HTTP/2 [RFC7540]. This points to the need for an
application-agnostic solution, which would be implemented fully in application-agnostic solution, which would be implemented fully in
the TLS layer. the TLS layer.
3.7.1. Hiding the Application Layer Protocol Negotiation 3.7.1. Hiding the Application Layer Protocol Negotiation
skipping to change at page 9, line 21 skipping to change at page 9, line 35
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 applies 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, often refered to as Domain Fronting
the fronting server, and HTTP requests are then sent over that [domfront]. The TLS connection is established with the fronting
connection to the hidden service. For example, the TLS SNI could be server, and HTTP requests are then sent over that connection to the
set to "fronting.example.com", the fronting server, and HTTP requests hidden service. For example, the TLS SNI could be set to
sent over that connection could be directed to "hidden.example.com", "fronting.example.com", the fronting server, and HTTP requests sent
over that connection could be directed to "hidden.example.com",
accessing the hidden service. This solution works well in practice 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 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's browser 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 does not protect non-HTTP
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 may be solved by developing a browser extension that browser issue was solved in [domfront] by implementing domain
support HTTP Fronting, and manages the list of fronting services fronting as a pluggable transport for the Tor browser. 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
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
skipping to change at page 10, line 42 skipping to change at page 11, line 8
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 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 harder to mitigate when the hidden service has to be
be accessed through general purpose web browsers. The browsers will accessed through general purpose web browsers.
need a mechanism to obtain the fronting server indication in a secure
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. The experiment described in [domfront] solved the issue by
integrating with the Lantern Internet circumvention circumvention
tool.
We can observe that content distribution networks (CDNs) have a We can observe that CDNs have a similar requirement. They need to
similar requirement. They need to convince the client that convince the client that "www.example.com" can be accessed through
"www.example.com" can be accessed through the seemingly unrelated the seemingly unrelated "cdn-node-xyz.example.net". Most CDNs have
"cdn-node-xyz.example.net". Most CDNs have deployed DNS-based deployed DNS-based solutions to this problem. However, the CDN often
solutions to this problem. However, the CDN often holds the holds the authoritative certificate of the origin. There is
authoritative certificate of the origin. There is simultaneously simultaneously verification of a relationship between the origin and
verification of a relationship between the origin and the CDN, the CDN, through the certificate, and a risk that the CDN can spoof
through the certificate, and a risk that the CDN can spoof the the content from the origin.
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
skipping to change at page 12, line 13 skipping to change at page 12, line 25
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 Bernard Aboba, Mike Bishop, Stephen initial draft. Thanks to Bernard Aboba, Mike Bishop, Stephen
Farrell, Barry Leiba, Martin Rex, Meral Shirazipour, Martin Thomson 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
[domfront]
Fifield, D., Lan, C., Hynes, R., Wegmann, P., and V.
Paxson, "Blocking-resistant communication through domain
fronting", DOI 10.1515/popets-2015-0009, 2015,
<https://www.bamsoftware.com/papers/fronting/>.
[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-23 (work in progress), September 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>.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, DOI 10.17487/RFC2595, June 1999,
<https://www.rfc-editor.org/info/rfc2595>.
[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>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
skipping to change at page 13, line 35 skipping to change at page 14, line 5
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
Security (TLS) in the Extensible Messaging and Presence Security (TLS) in the Extensible Messaging and Presence
Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
2015, <https://www.rfc-editor.org/info/rfc7590>. 2015, <https://www.rfc-editor.org/info/rfc7590>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
Use of Transport Layer Security (TLS) for Email Submission
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
<https://www.rfc-editor.org/info/rfc8314>.
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
RFC 8336, DOI 10.17487/RFC8336, March 2018, RFC 8336, DOI 10.17487/RFC8336, March 2018,
<https://www.rfc-editor.org/info/rfc8336>. <https://www.rfc-editor.org/info/rfc8336>.
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
Pervasive Encryption on Operators", RFC 8404, Pervasive Encryption on Operators", RFC 8404,
DOI 10.17487/RFC8404, July 2018, DOI 10.17487/RFC8404, July 2018,
<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
 End of changes. 27 change blocks. 
87 lines changed or deleted 106 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/