draft-ietf-tls-sni-encryption-03.txt   draft-ietf-tls-sni-encryption-04.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: November 21, 2018 RTFM, Inc. Expires: May 26, 2019 RTFM, Inc.
May 20, 2018 November 22, 2018
Issues and Requirements for SNI Encryption in TLS Issues and Requirements for SNI Encryption in TLS
draft-ietf-tls-sni-encryption-03 draft-ietf-tls-sni-encryption-04
Abstract Abstract
This draft describes the general problem of encryption of the Server This draft describes the general problem of encryption of the Server
Name Identification (SNI) parameter. The proposed solutions hide a Name Identification (SNI) parameter. The proposed solutions hide a
Hidden Service behind a Fronting Service, only disclosing the SNI of Hidden Service behind a Fronting Service, only disclosing the SNI of
the Fronting Service to external observers. The draft lists known 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.
In practice, it may well be that no solution can meet every
requirement, and that practical solutions will have to make some
compromises.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 21, 2018. This Internet-Draft will expire on May 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 17 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . 4 2.3. End-to-end alternatives . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 6 3.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 6
3.6. Proper Security Context . . . . . . . . . . . . . . . . . 6 3.6. Proper Security Context . . . . . . . . . . . . . . . . . 7
3.7. Fronting Server Spoofing . . . . . . . . . . . . . . . . 7 3.7. Fronting Server Spoofing . . . . . . . . . . . . . . . . 7
3.8. Supporting multiple protocols . . . . . . . . . . . . . . 7 3.8. Supporting multiple protocols . . . . . . . . . . . . . . 7
3.8.1. Hiding the Application Layer Protocol Negotiation . . 8 3.8.1. Hiding the Application Layer Protocol Negotiation . . 8
3.8.2. Support other transports than HTTP . . . . . . . . . 8 3.8.2. Support other transports than HTTP . . . . . . . . . 8
3.9. Fail to fronting . . . . . . . . . . . . . . . . . . . . 8 4. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 8
4. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 9 4.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 9
4.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Delegation Control . . . . . . . . . . . . . . . . . . . 10 4.2. Delegation Control . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.3. Related work . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Informative References . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 channels: looking at DNS requests, looking at services through three channels: looking at DNS requests, looking at
IP addresses in packet headers, and looking at the data stream IP addresses in packet headers, and looking at the data stream
between user and services. These channels are getting progressively between user and services. These channels are getting progressively
closed. A growing fraction of Internet communication is encrypted, closed. A growing fraction of Internet communication is encrypted,
mostly using Transport Layer Security (TLS) [RFC5246]. Progressive mostly using Transport Layer Security (TLS) [RFC5246]. Progressive
skipping to change at page 3, line 36 skipping to change at page 3, line 38
but only the "hostname" variant was standardized and deployed. In but only the "hostname" variant was standardized 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
"Client Hello" message. "Client Hello" 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
developer of middleboxes soon found out that they could take developer 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 [I-D.mm-wg-effect-encrypt]. They include: reviewed in [RFC8404]. They include:
o Censorship of specific sites by "national firewalls", o Censorship of specific sites by "national firewalls",
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 fraudulent implement "parental controls", or to prevent access to fraudulent
web sites, such as used for phishing, web sites, such as used for phishing,
o ISP assigning different QOS profiles to target services, o ISP assigning different QOS profiles to target services,
o Enterprise firewalls blocking web sites not deemed appropriate for o Enterprise firewalls blocking web sites not deemed appropriate for
work, work, or
o Enterprise firewalls exempting specific web sites from MITM o Enterprise firewalls exempting specific web sites from MITM
inspection, such as healthcare or financial sites for which inspection, such as healthcare or financial sites for which
inspection would intrude with the privacy of employees. inspection would intrude with 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 abuses [RFC6066]. These specifications did not anticipate the alternative
described in Section 2.1. One reason may be that, when these RFCs uses and abuses described in Section 2.1. One reason may be that,
were written, the SNI information was available through a variety of when these RFCs were written, the SNI information was available
other means. through a variety of other means.
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, content distribution networks (CDN) commonly
serve a large number of services through a small number of addresses. serve a large number of services through a 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 [I-D.ietf-doh-dns-over-https]. HTTPS [RFC8484].
The common name component of the server certificate generally exposes The subjectAltName extension of type dNSName of the server
the same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 certificate, or in its absence the common name component, expose the
[RFC4346], and 1.2 [RFC5246], the server send their certificate in same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346],
clear text, ensuring that there would be limited benefits in hiding and 1.2 [RFC5246], the server send their certificate in clear text,
the SNI. But the transmission of the server certificate is protected ensuring that there would be limited benefits in hiding the SNI. But
in TLS 1.3 [I-D.ietf-tls-tls13]. the transmission of the server certificate is protected in TLS 1.3
[RFC8446].
The decoupling of IP addresses and server names, the deployment of The decoupling of IP addresses and server names, the deployment of
DNS privacy, and the protection of server certificates transmissions DNS privacy, and the protection of server certificates transmissions
all contribute to user privacy. Encrypting the SNI now will complete all contribute to user privacy. Encrypting the SNI now will complete
this push for privacy and make it much harder to censor specific this push for privacy and make it harder to censor specific internet
internet services. services.
2.3. End-to-end alternatives 2.3. End-to-end alternatives
Deploying SNI encryption will help thwarting most the "unanticipated" Deploying SNI encryption will help thwarting most of the
SNI usages described in Section 2.1, including censorship and "unanticipated" SNI usages described in Section 2.1, including
pervasive surveillance. It will also thwart functions that are censorship and pervasive surveillance. It will also thwart functions
sometimes described as legitimate. Most of these functions can that are sometimes described as legitimate. Most of these functions
however be realized by other means. For example, some DNS service can however be realized by other means. For example, some DNS
providers offer customers the provision to "opt in" filtering service 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. Enterprises can deploy monitoring software to control agreements. As SNI encryption becomes common, we can expect more
usage of the enterprises computers. 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
performing SNI filtering to prevent connections to certain websites.
With SNI encryption this becomes ineffective. Obviously, managers
could block usage of SNI encryption in enterprise computers, but this
wide scale blocking would diminish the privacy protection of traffic
leaving the enterprise, which may not be desirable. Enterprises
managers could rely instead on filtering software and management
software deployed on enterprises 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. Many of these proposals appeared
promising, but were rejected after security reviews pointed plausible promising, but were rejected after security reviews pointed plausible
attacks. In this section, we collect a list of these known attacks. attacks. In this section, we collect a list of these known attacks.
3.1. Mitigate Replay Attacks 3.1. Mitigate Replay Attacks
skipping to change at page 6, line 48 skipping to change at page 7, line 7
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 was
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. Proper Security Context 3.6. Proper Security Context
We can design solutions in which the multiplexed server or a fronting We can design solutions in which a fronting service act as a relay to
service act as a relay to reach the protected service. Some of those reach the protected service. Some of those solutions involve just
solutions involve just one TLS handshake between the client and the one TLS handshake between the client and the fronting service. The
multiplexed server, or between the client and the fronting service. master secret is verified by verifying a certificate provided by the
fronting service, but not by the protected service. These solutions
The master secret is verified by verifying a certificate provided by expose the client to a Man-In-The-Middle attack by the fronting
either of these entities, but not by the protected service. service. Even if the client has some reasonable trust in this
services, the possibility of MITM attack is troubling.
These solutions expose the client to a Man-In-The-Middle attack by There are other classes of solutions in which the master secret is
the multiplexed server or by the fronting service. Even if the verified by verifying a certificate provided by the protected
client has some reasonable trust in these services, the possibility service. These solutions offer more protection against a Man-In-The-
of MITM attack is troubling. Middle attack by the fronting service.
The multiplexed server or the fronting services could be pressured by The fronting service could be pressured by adversaries. By design,
adversaries. By design, they could be forced to deny access to the it could be forced to deny access to the protected service, or to
protected service, or to divulge which client accessed it. But if divulge which client accessed it. But if MITM is possible, the
MITM is possible, the adversaries would also be able to pressure them adversaries would also be able to pressure the fronting service into
into intercepting or spoofing the communications between client and intercepting or spoofing the communications between client and
protected service. protected service.
3.7. Fronting Server Spoofing 3.7. Fronting Server Spoofing
Adversaries could mount an attack by spoofing the Fronting Service. Adversaries could mount an attack by spoofing the Fronting Service.
A spoofed Fronting Service could act as a "honeypot" for users of A spoofed Fronting Service could act as a "honeypot" for users of
hidden services. At a minimum, the fake server could record the IP hidden services. At a minimum, the fake server could record the IP
addresses of these users. If the SNI encryption solution places too addresses of these users. If the SNI encryption solution places too
much trust on the fronting server, the fake server could also serve much trust on the fronting server, the fake server could also serve
fake content of its own choosing, including various forms of malware. fake content of its own choosing, including various forms of malware.
skipping to change at page 7, line 39 skipping to change at page 7, line 47
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.8. Supporting multiple protocols 3.8. Supporting multiple protocols
The SNI encryption requirement do 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 example
SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590]. These applications SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590]. These applications
too will benefit of SNI encryption. HTTP only methods like those too will benefit of SNI encryption. HTTP only methods like those
described in Section 4.1 would not apply there. In fact, even for described in Section 4.1 would not apply there. In fact, even for
the HTTPS case, the HTTPS tunneling service described in Section 4.1 the HTTPS case, the HTTPS tunneling service described in Section 4.1
is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly
with the multiple streams feature of HTTP 2.0 [RFC7540]. This points with the multiple streams feature of HTTP 2.0 [RFC7540]. This points
to the need of an application agnostic solution, that would be to the need of an application agnostic solution, that would be
implemented fully in the TLS layer. implemented fully in the TLS layer.
skipping to change at page 8, line 24 skipping to change at page 8, line 28
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 network. 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 was
hidden in the same way as the SNI. hidden in the same way as the SNI.
It is thus desirable that SNI Encryption mechanisms be also able hide In addition to hiding the SNI, it is thus desirable to also hide the
the ALPN. ALPN. Of course, this implies engineering trade-offs. Using the
same technique for hiding the ALPN and encrypting the SNI may result
in excess complexity. It might be preferable to encrypt these
independently.
3.8.2. Support other transports than HTTP 3.8.2. Support other transports than HTTP
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 apply 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.
3.9. Fail to fronting
It is easy to imagine designs in which the client sends some client
hello extension that points to a secret shared by client and hidden
server. If that secret is incorporated into the handshake secret,
the exchange will only succeeds if the connection truly ends at the
hidden server. The exchange will fail if the extension is stripped
by an MITM, and the exchange will also fail if an adversary replays
the extension in a Client Hello.
The problem with that approach is clear. Adversaries that replay the
extension can test whether the client truly wanted to access the
fronting server, or was simply using that fronting server as an
access gateway to something else. The adversaries will not know what
hidden service the client was trying to reach, but they can guess.
They can also start directly interrogate the user, or other
unpleasant alternatives.
When designing SNI encryption schemes, we have to take into account
attacks that strip parameters from the Client Hello, or replay
attacks. In both cases, the desired behavior is to fall back to a
connection with the fronting server, so there is no visble difference
between a regular connection to that server and an attempt to reach
the hidden server.
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",
some-content", accessing the hidden service. This solution works accessing the hidden service. This solution works well in practice
well in practice when the fronting server and the hidden server are when the fronting server and the hidden server are "co-tenant" of the
'co-tenant" of the same multiplexed server. 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 browser's 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 proof that the content does in fact come from the client has no proof that the content does in fact come from
the hidden service. The solution does thus not mitigate the the hidden service. The solution does thus not mitigate the
context sharing issues described in Section 3.6. context sharing issues described in Section 3.6.
o Since this is an HTTP level solution, it would not protected 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 such as DNS over TLS [RFC7858] or IMAP over TLS
[RFC2595]. [RFC2595].
The discovery issue is common to pretty much every SNI encryption The discovery issue is common to pretty much every SNI encryption
solution. The browser issue may be solved by developing a browser solution. The browser issue may be solved by developing a browser
extension that support HTTP Fronting, and manages the list of extension that support HTTP Fronting, and manages the list of
fronting services associated with the hidden services that the client fronting services associated with the hidden services that the client
uses. The multi-protocol issue can be mitigated by using uses. The multi-protocol issue can be mitigated by using
implementation of other applications over HTTP, such as for example implementation of other applications over HTTP, such as for example
DNS over HTTPS [I-D.hoffman-dns-over-https]. The trust issue, DNS over HTTPS [RFC8484]. The trust issue, however, requires
however, requires specific developments. 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
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
skipping to change at page 11, line 11 skipping to change at page 10, line 39
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 network have a similar
requirement. They need to convince the client that "www.example.com" requirement. They need to convince the client that "www.example.com"
can be accessed through the seemingly unrelated "cdn-node- can be accessed through the seemingly unrelated "cdn-node-
xyz.example.net". Most CDN have deployed DNS-based solutions to this xyz.example.net". Most CDN have deployed DNS-based solutions to this
problem. problem.
4.3. Related work
The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag
content provided by the hidden server. Secondary certificate
authentication [I-D.ietf-httpbis-http2-secondary-certs] can be used
to manage authentication of hidden server content, or to perform
client authentication before accessing hidden content.
5. Security Considerations 5. Security Considerations
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. This design of proper SNI encryption solutions is difficult. This
document does not present the design of a solution, but provide document does not present the design of a solution, but provide
guidelines for evaluating proposed solutions. 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. The current HTTP based
solutions described in Section 4 only meet some of these solutions described in Section 4 only meet some of these
requirements. In practice, it may well be that no solution can meet requirements. In practice, it may well be that no solution can meet
every requirement, and that practical solutions will have to make every requirement, 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 if for proposed Section 3.4 may have to be lifted, especially for proposed solutions
solutions that could quickly reach large scale deployments. that could quickly reach large scale deployments.
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. initial draft. Thanks to Stephen Farrell, Mark Orchezowski, Martin
Rex and Martin Thomson for their reviews.
8. References
8.1. Normative References
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018.
8.2. Informative References
[I-D.hoffman-dns-over-https] 8. Informative References
Hoffman, P. and P. McManus, "DNS Queries over HTTPS",
draft-hoffman-dns-over-https-01 (work in progress), June
2017.
[I-D.ietf-doh-dns-over-https] [I-D.ietf-httpbis-http2-secondary-certs]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS Bishop, M., Sullivan, N., and M. Thomson, "Secondary
(DOH)", draft-ietf-doh-dns-over-https-08 (work in Certificate Authentication in HTTP/2", draft-ietf-httpbis-
progress), May 2018. http2-secondary-certs-03 (work in progress), October 2018.
[I-D.ietf-quic-tls] [I-D.ietf-quic-tls]
Thomson, M. and S. Turner, "Using Transport Layer Security Thomson, M. and S. Turner, "Using Transport Layer Security
(TLS) to Secure QUIC", draft-ietf-quic-tls-11 (work in (TLS) to Secure QUIC", draft-ietf-quic-tls-16 (work in
progress), April 2018. progress), October 2018.
[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-26 (work in progress), March 1.3", draft-ietf-tls-dtls13-30 (work in progress),
2018. November 2018.
[I-D.mm-wg-effect-encrypt]
Moriarty, K. and A. Morton, "Effects of Pervasive
Encryption on Operators", draft-mm-wg-effect-encrypt-25
(work in progress), March 2018.
[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", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, DOI 10.17487/RFC2595, June 1999, RFC 2595, DOI 10.17487/RFC2595, June 1999,
<https://www.rfc-editor.org/info/rfc2595>. <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.,
skipping to change at page 13, line 40 skipping to change at page 13, 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>.
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
RFC 8336, DOI 10.17487/RFC8336, March 2018,
<https://www.rfc-editor.org/info/rfc8336>.
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
Pervasive Encryption on Operators", RFC 8404,
DOI 10.17487/RFC8404, July 2018,
<https://www.rfc-editor.org/info/rfc8404>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
Authors' Addresses Authors' Addresses
Christian Huitema Christian Huitema
Private Octopus Inc. Private Octopus Inc.
Friday Harbor WA 98250 Friday Harbor WA 98250
U.S.A U.S.A
Email: huitema@huitema.net Email: huitema@huitema.net
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
U.S.A U.S.A
Email: ekr@rtfm.com Email: ekr@rtfm.com
 End of changes. 35 change blocks. 
120 lines changed or deleted 117 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/