rfc8744xml2.original.xml   rfc8744.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc ipr="trust200902" category="info" docName="draft-ietf-tls-sni-encryption-09 <rfc number="8744" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude"
"> ipr="trust200902"
<?rfc toc="yes"?> category="info" docName="draft-ietf-tls-sni-encryption-09" obsoletes=""
<?rfc symrefs="yes"?> updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
<?rfc sortrefs="yes"?> symRefs="true" sortRefs="true" version="3">
<?rfc compact="yes"?> <!-- xml2rfc v2v3 conversion 2.37.3 -->
<?rfc subcompact="no"?> <front>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="TLS-SNI Encryption Requirements">Issues and Requirements for SNI
Encryption in TLS</title>
<author initials="C." surname="Huitema" fullname="Christian Huitema">
<organization>Private Octopus Inc.</organization>
<address>
<postal>
<street></street>
<city>Friday Harbor</city>
<code>WA 98250</code>
<country>U.S.A</country>
<region></region>
</postal>
<phone></phone>
<email>huitema@huitema.net</email>
<uri></uri>
</address>
</author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>RTFM, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country>U.S.A</country>
<region></region>
</postal>
<phone></phone>
<email>ekr@rtfm.com</email>
<uri></uri>
</address>
</author>
<date year="2019" month="October" day="28"/>
<area>Network</area> <title abbrev="TLS-SNI Encryption Requirements">Issues and Requirements
<workgroup></workgroup> for Server Name Identification (SNI) Encryption in TLS</title>
<seriesInfo name="RFC" value="8744"/>
<author initials="C." surname="Huitema" fullname="Christian Huitema">
<organization>Private Octopus Inc.</organization>
<address>
<postal>
<street/>
<city>Friday Harbor</city>
<region>WA</region>
<code>98250</code>
<country>United States of America</country>
</postal>
<phone/>
<email>huitema@huitema.net</email>
<uri/>
</address>
</author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>Mozilla</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country>United States of America</country>
<region/>
</postal>
<phone/>
<email>ekr@rtfm.com</email>
<uri/>
</address>
</author>
<date month="March" year="2020"/>
<area>Network</area>
<workgroup/>
<abstract> <abstract>
<t>This draft describes the general problem of encrypting the <t>This document describes the general problem of encrypting the
Server Name Identification (SNI) TLS parameter. The proposed Server Name Identification (SNI) TLS parameter. The proposed
solutions hide a Hidden Service behind a fronting service, solutions hide a hidden service behind a fronting service,
only disclosing the SNI of the fronting service to external only disclosing the SNI of the fronting service to external
observers. The draft lists known attacks against observers. This document lists known attacks against
SNI encryption, discusses the current &quot;co-tenancy fronting&quot; solution, SNI encryption, discusses the current "HTTP co-tenancy" solution,
and presents requirements for future TLS layer solutions. and presents requirements for future TLS-layer solutions.
</t> </t>
<t>In practice, it may well be that no solution can meet every requirement,
<t>In practice, it may well be that no solution can meet every requirement
and that practical solutions will have to make some compromises. and that practical solutions will have to make some compromises.
</t> </t>
</abstract> </abstract>
</front>
</front> <middle>
<section anchor="introduction" numbered="true" toc="default">
<middle> <name>Introduction</name>
<t>Historically, adversaries have been able to monitor the use of web
<section anchor="introduction" title="Introduction">
<t>Historically, adversaries have been able to monitor the use of web
services through three primary channels: looking at DNS requests, looking services through three primary channels: looking at DNS requests, looking
at IP addresses in packet headers, and looking at the data stream between at IP addresses in packet headers, and looking at the data stream between
user and services. These channels are getting progressively closed. user and services. These channels are getting progressively closed.
A growing fraction of A growing fraction of
Internet communication is encrypted, mostly using Transport Layer Security Internet communication is encrypted, mostly using Transport Layer Security
(TLS) <xref target="RFC5246"/>. (TLS) <xref target="RFC8446" format="default"/>.
Progressive deployment of solutions like DNS in Progressive deployment of solutions like DNS over
TLS <xref target="RFC7858"/> and DNS over HTTPS <xref target="RFC8484"/> TLS <xref target="RFC7858" format="default"/> and DNS over HTTPS <xref
target="RFC8484" format="default"/>
mitigates the disclosure of DNS information. More and mitigates the disclosure of DNS information. More and
more services are colocated on multiplexed servers, loosening the more services are colocated on multiplexed servers, loosening the
relation between IP address and web service. For example, in virtual hosting relation between IP address and web service. For example, in virtual hosting
solutions, multiple services can be hosted as co-tenants on the same server, solutions, multiple services can be hosted as co-tenants on the same server,
and the IP address and port do not uniquely identify a service. In cloud or 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 Content Delivery Network (CDN) solutions, a given platform hosts the services
or servers servers of a lot of organization, and looking up to what netblock or servers of a lot of organizations, and looking up what netblock
an IP address belongs reveals little. However, multiplexed servers an IP address belongs to reveals little. However, multiplexed servers
rely on the Service Name Information (SNI) TLS extension <xref target="RFC6066"/ rely on the Server Name Information (SNI) TLS extension <xref
> to direct connections target="RFC6066" format="default"/> to direct connections
to the appropriate service implementation. This protocol element to the appropriate service implementation. This protocol element
is transmitted in clear text. As the other methods of monitoring get is transmitted in cleartext. As the other methods of monitoring get
blocked, monitoring focuses on the clear text SNI. The purpose blocked, monitoring focuses on the cleartext SNI. The purpose
of SNI encryption is to prevent that and aid privacy. of SNI encryption is to prevent that and aid privacy.
</t> </t>
<t>Replacing clear text SNI transmission by an encrypted variant will <t>Replacing cleartext SNI transmission by an encrypted variant will
improve the privacy and reliability of TLS connections, but the design improve the privacy and reliability of TLS connections, but the design
of proper SNI encryption solutions is difficult. of proper SNI encryption solutions is difficult.
In the past, there have been multiple attempts at defining SNI encryption. In the past, there have been multiple attempts at defining SNI encryption.
These attempts have generally floundered, because the simple designs fail These attempts have generally floundered, because the simple designs fail
to mitigate several of the attacks listed in <xref target="snisecreq"/>. In the to mitigate several of the attacks listed in <xref target="snisecreq"
absence of format="default"/>. In the absence of
a TLS-level solution, the most popular approach to SNI privacy for web a TLS-level solution, the most popular approach to SNI privacy for web
services is HTTP-level fronting, which we discuss in <xref target="httpfronting" services is HTTP-level fronting, which we discuss in <xref
/>. target="httpfronting" format="default"/>.
</t> </t>
<t>This document does not present the design of a solution, but <t>This document does not present the design of a solution but
provides guidelines for evaluating proposed solutions. (The review of provides guidelines for evaluating proposed solutions. (The review of
HTTP-level solutions in <xref target="httpfronting"/> is not an endorsement of t HTTP-level solutions in <xref target="httpfronting" format="default"/> is not
hese an endorsement of these solutions.)
solutions.) The need for related work on the encryption of the Application-Layer
The need for related work on the encryption of the Application Layer
Protocol Negotiation (ALPN) parameters of TLS is discussed in Protocol Negotiation (ALPN) parameters of TLS is discussed in
<xref target="hiding-alpn"/>. <xref target="hiding-alpn" format="default"/>.
</t> </t>
</section> </section>
<section anchor="history-of-the-tls-sni-extension" numbered="true" toc="defa
<section anchor="history-of-the-tls-sni-extension" title="History of the TLS SNI ult">
extension"> <name>History of the TLS SNI Extension</name>
<t>The SNI extension was specified in 2003 in <xref target="RFC3546"/> to facili <t>The SNI extension was specified in 2003 in <xref target="RFC3546"
tate management format="default"/> to facilitate management
of &quot;colocation servers&quot;, in which multiple services shared the same IP of "colocation servers", in which multiple services shared the same IP
address. A typical example would be multiple web sites served by the address. A typical example would be multiple websites served by the
same web server. The SNI extension carries the name of a specific same web server. The SNI extension carries the name of a specific
server, enabling the TLS connection to be established with the desired server, enabling the TLS connection to be established with the desired
server context. The current SNI extension specification can be server context. The current SNI extension specification can be
found in <xref target="RFC6066"/>. found in <xref target="RFC6066" format="default"/>.
</t> </t>
<t>The SNI specification allowed for different types of server names, <t>The SNI specification allowed for different types of server names,
though only the &quot;hostname&quot; variant was specified and deployed. In that though only the "hostname" variant was specified and deployed. In that
variant, the SNI extension carries the domain name of the target variant, the SNI extension carries the domain name of the target
server. The SNI extension is carried in clear text in the TLS &quot;ClientHello& quot; server. The SNI extension is carried in cleartext in the TLS "ClientHello"
message. message.
</t> </t>
<section anchor="snileak" numbered="true" toc="default">
<section anchor="snileak" title="Unanticipated usage of SNI information"> <name>Unanticipated Usage of SNI Information</name>
<t>The SNI was defined to facilitate management of servers, but the <t>The SNI was defined to facilitate management of servers, but the
developers of middleboxes found out that they could take developers of middleboxes 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 <xref target="RFC8404"/>. Other examples came out during discussions reviewed in <xref target="RFC8404" format="default"/>. Other examples came out
of this draft. They include: during discussions of this document. They include:
</t>
<t>
<list style="symbols">
<t>Filtering or censorship of specific services for a variety of reasons.</t>
<t>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.</t>
<t>ISP assigning different QoS profiles to target services,</t>
<t>Firewalls within enterprise networks blocking web sites not deemed
appropriate for work, or</t>
<t>Firewalls within enterprise networks exempting specific web sites from
Man-In-The-Middle (MITM) inspection, such as healthcare or financial
sites for which inspection would intrude on the privacy of employees.</t>
</list>
</t> </t>
<t>The SNI is probably also included in the general collection of metadata <ul spacing="normal">
by pervasive surveillance actors <xref target="RFC7258"/>, for example to identi <li>Filtering or censoring specific services for a variety of reasons<
fy services /li>
<li>Content filtering by network operators or ISPs blocking specific
websites, for example, to implement parental controls or to prevent acc
ess
to phishing or other fraudulent websites</li>
<li>ISP assigning different QoS profiles to target services</li>
<li>Firewalls within enterprise networks blocking websites not deemed
appropriate for work</li>
<li>Firewalls within enterprise networks exempting specific websites f
rom
man-in-the-middle (MITM) inspection, such as healthcare or financial
sites for which inspection would intrude on the privacy of employees</li>
</ul>
<t>The SNI is probably also included in the general collection of metada
ta
by pervasive surveillance actors <xref target="RFC7258" format="default"/>,
for example, to identify services
used by surveillance targets. used by surveillance targets.
</t> </t>
</section> </section>
<section anchor="sniwhyencryptnow" numbered="true" toc="default">
<section anchor="sniwhyencryptnow" title="SNI encryption timeliness"> <name>SNI Encryption Timeliness</name>
<t>The clear-text transmission of the SNI was not flagged as a problem <t>The cleartext transmission of the SNI was not flagged as a problem
in the security consideration sections of <xref target="RFC3546"/>, <xref target in the Security Considerations sections of <xref target="RFC3546"
="RFC4366"/>, or format="default"/>, <xref target="RFC4366" format="default"/>, or
<xref target="RFC6066"/>. These specifications did not anticipate the <xref target="RFC6066" format="default"/>. These specifications did not anticipa
te the
alternative usage described alternative usage described
in <xref target="snileak"/>. One reason may be that, when these RFCs were writte in <xref target="snileak" format="default"/>. One reason may be that, when
n, the these RFCs were written, the
SNI information was available through a variety of other means, SNI information was available through a variety of other means,
such as tracking IP addresses, DNS names, or server certificates. such as tracking IP addresses, DNS names, or server certificates.
</t> </t>
<t>Many deployments still allocate different IP addresses to different <t>Many deployments still allocate different IP addresses to different
services, so that different services can be identified by their IP services, so that different services can be identified by their IP
addresses. However, CDNs commonly addresses. However, CDNs commonly
serve a large number of services through a comparatively small serve a large number of services through a comparatively small
number of addresses. number of addresses.
</t> </t>
<t>The SNI carries the domain name of the server, which is also sent as <t>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 <xref target="snilea part of the DNS queries. Most of the SNI usage described in <xref
k"/> target="snileak" format="default"/>
could also be implemented by monitoring DNS traffic or controlling DNS could also be implemented by monitoring DNS traffic or controlling DNS
usage. But this is changing with the advent of DNS resolvers usage. But this is changing with the advent of DNS resolvers
providing services like DNS over TLS <xref target="RFC7858"/> providing services like DNS over TLS <xref target="RFC7858" format="default"/>
or DNS over HTTPS <xref target="RFC8484"/>. or DNS over HTTPS <xref target="RFC8484" format="default"/>.
</t> </t>
<t>The subjectAltName extension of type dNSName of the server certificate,
or in its absence the common name component, expose <t>The subjectAltName extension of type dNSName of the server certificat
the same name as the SNI. In TLS versions 1.0 <xref target="RFC2246"/>, 1.1 <xre e
f target="RFC4346"/>, (or in its absence, the common name component) exposes
and 1.2 <xref target="RFC5246"/>, servers send certificates in clear text, the same name as the SNI. In TLS versions 1.0 <xref target="RFC2246"
format="default"/>, 1.1 <xref target="RFC4346" format="default"/>,
and 1.2 <xref target="RFC5246" format="default"/>, servers send certificates in
cleartext,
ensuring that there would be limited benefits in hiding the SNI. However, ensuring that there would be limited benefits in hiding the SNI. However,
in TLS 1.3 <xref target="RFC8446"/>, server certificates are encrypted in transi in TLS 1.3 <xref target="RFC8446" format="default"/>, server certificates are
t. encrypted in transit.
Note that encryption alone is insufficient to protect server certificates; Note that encryption alone is insufficient to protect server certificates;
see <xref target="replayattack"/> for details. see <xref target="cutandpasteattack" format="default"/> for details.
</t>
<t>The decoupling of IP addresses and server names, deployment
of DNS privacy, and protection of server certificate transmissions
all contribute to user privacy in the face of an <xref target="RFC7258"/>-style
adversary. Encrypting the SNI complements this push for privacy and
make it harder to censor or otherwise provide differential treatment to
specific internet services.
</t> </t>
</section>
<section anchor="end-to-end" title="End-to-end alternatives"> <t>The decoupling of IP addresses and server names, deployment of DNS
<t>Deploying SNI encryption helps thwart most of the unanticipated SNI usages privacy, and protection of server certificate transmissions all
contribute to user privacy in the face of an RFC 7258-style adversary
<xref target="RFC7258" format="default"/>. Encrypting the SNI
complements this push for privacy and makes it harder to censor or
otherwise provide differential treatment to specific Internet
services.
</t>
</section>
<section anchor="end-to-end" numbered="true" toc="default">
<name>End-to-End Alternatives</name>
<t>Deploying SNI encryption helps thwart most of the unanticipated SNI u
sages,
including censorship and pervasive surveillance, but it also including censorship and pervasive surveillance, but it also
will break or reduce the efficacy of the operational practices and will break or reduce the efficacy of the operational practices and
techniques implemented in middle-boxes as described in <xref target="snileak"/>. techniques implemented in middleboxes, as described in <xref target="snileak"
Most of format="default"/>. Most of
these functions can, however, be realized by other means. For example, some DNS service these functions can, however, be realized by other means. For example, some DNS service
providers offer customers the provision to &quot;opt in&quot; filtering services providers offer customers the provision to "opt in" to filtering services
for parental control and phishing protection. Per-stream QoS could be provided b y for parental control and phishing protection. Per-stream QoS could be provided b y
a combination of packet marking and end-to-end agreements. As a combination of packet marking and end-to-end agreements. As
SNI encryption becomes common, we can expect more deployment of such &quot;end-t o-end&quot; SNI encryption becomes common, we can expect more deployment of such "end-to-end "
solutions. solutions.
</t> </t>
<t>At the time of this writing, enterprises have the option of installing a <t>At the time of this writing, enterprises have the option of installin g a
firewall performing SNI filtering to firewall performing SNI filtering to
prevent connections to certain websites. With SNI encryption this becomes ineffe ctive. prevent connections to certain websites. With SNI encryption, this becomes ineff ective.
Obviously, managers could block usage of SNI encryption in enterprise computers, but Obviously, managers could block usage of SNI encryption in enterprise computers, but
this wide-scale blocking would diminish the privacy protection of traffic leavin g the this wide-scale blocking would diminish the privacy protection of traffic leavin g the
enterprise, which may not be desirable. enterprise, which may not be desirable.
Enterprise managers could rely instead on filtering software and management Enterprise managers could rely instead on filtering software and management
software deployed on the enterprise's computers. software deployed on the enterprise's computers.
</t> </t>
</section> </section>
</section> </section>
<section anchor="snisecreq" numbered="true" toc="default">
<section anchor="snisecreq" title="Security and Privacy Requirements for SNI Enc <name>Security and Privacy Requirements for SNI Encryption</name>
ryption"> <t>Over the past years, there have been multiple proposals to add an SNI e
<t>Over the past years, there have been multiple proposals to add an SNI encrypt ncryption
ion
option in TLS. A review of the TLS mailing list archives shows that option in TLS. A review of the TLS mailing list archives shows that
many of these proposals appeared promising but were rejected many of these proposals appeared promising but were rejected
after security reviews identified plausible attacks. In this section, after security reviews identified plausible attacks. In this section,
we collect a list of these known attacks. we collect a list of these known attacks.
</t> </t>
<section anchor="cutandpasteattack" numbered="true" toc="default">
<section anchor="replayattack" title="Mitigate Replay Attacks"> <name>Mitigate Cut-and-Paste Attacks</name>
<t>The simplest SNI encryption designs replace in the initial TLS <t>The simplest SNI encryption designs
exchange the clear text SNI with replace the cleartext SNI in the initial TLS
exchange with
an encrypted value, using a key known to the multiplexed server. Regardless of t he an encrypted value, using a key known to the multiplexed server. Regardless of t he
encryption used, these designs can be broken by a simple replay attack, which wo rks encryption used, these designs can be broken by a simple cut-and-paste attack, w hich works
as follows: as follows:
</t> </t>
<t>1- The user starts a TLS connection to the multiplexed server, including an e <ol spacing="normal" type="1">
ncrypted <li>The user starts a TLS connection to the multiplexed server, includin
SNI value. g an encrypted
</t> SNI value.</li>
<t>2- The adversary observes the exchange and copies the encrypted SNI parameter <li>The adversary observes the exchange and copies the encrypted SNI par
. ameter.</li>
</t> <li>The adversary starts its own connection to the multiplexed server, i
<t>3- The adversary starts its own connection to the multiplexed server, includi ncluding in its
ng in its connection parameters the encrypted SNI copied from the observed exchange.</l
connection parameters the encrypted SNI copied from the observed exchange. i>
</t> <li>The multiplexed server establishes the connection to the protected s
<t>4- The multiplexed server establishes the connection to the protected service ervice, which sends its certificate, thus revealing the identity of the service.
, thus </li>
revealing the identity of the service. </ol>
</t>
<t>One of the goals of SNI encryption is to prevent adversaries from knowing whi
ch
Hidden Service the client is using. Successful replay attacks break that goal by
allowing adversaries to discover that service.
</t>
</section>
<section anchor="sharedsecrets" title="Avoid Widely Shared Secrets"> <t>One of the goals of SNI encryption is to prevent adversaries from kno
<t>It is easy to think of simple schemes in which the SNI is encrypted or hashed wing which
using a hidden service the client is using. Successful cut-and-paste attacks break that
shared secret. This symmetric key must be known by the multiplexed server, and b goal by
y allowing adversaries to discover that service.</t>
</section>
<section anchor="sharedsecrets" numbered="true" toc="default">
<name>Avoid Widely Shared Secrets</name>
<t>It is easy to think of simple schemes in which the SNI is encrypted o
r hashed using a
shared secret. This symmetric key must be known by the multiplexed server and by
every user of the protected services. Such schemes are thus very fragile, since the every user of the protected services. Such schemes are thus very fragile, since the
compromise of a single user would compromise the entire set of users and protect ed compromise of a single user would compromise the entire set of users and protect ed
services. services.
</t> </t>
</section> </section>
<section anchor="serveroverload" numbered="true" toc="default">
<section anchor="serveroverload" title="Prevent SNI-based Denial of Service Atta <name>Prevent SNI-Based Denial-of-Service Attacks</name>
cks"> <t>Encrypting the SNI may create extra load for the multiplexed server.
<t>Encrypting the SNI may create extra load for the multiplexed server. Adversar Adversaries may mount
ies may mount denial-of-service (DoS) attacks by generating random encrypted SNI values and fo
denial of service attacks by generating random encrypted SNI values and forcing rcing the
the
multiplexed server to spend resources in useless decryption attempts. multiplexed server to spend resources in useless decryption attempts.
</t> </t>
<t>It may be argued that this is not an important Denial of Service Attacks (DoS ) avenue, <t>It may be argued that this is not an important avenue for DoS attacks ,
as regular TLS connection as regular TLS connection
attempts also require the server to perform a number of cryptographic operations . However, attempts also require the server to perform a number of cryptographic operations . However,
in many cases, the SNI decryption will have to be performed by a front-end compo nent in many cases, the SNI decryption will have to be performed by a front-end compo nent
with limited resources, while the TLS operations are performed by the component dedicated with limited resources, while the TLS operations are performed by the component dedicated
to their respective services. SNI-based DoS attacks could target the front-end c omponent. to their respective services. SNI-based DoS attacks could target the front-end c omponent.
</t> </t>
</section> </section>
<section anchor="snireqdontstickout" numbered="true" toc="default">
<section anchor="snireqdontstickout" title="Do not stick out"> <name>Do Not Stick Out</name>
<t>In some designs, handshakes using SNI encryption can be easily differentiated <t>In some designs, handshakes using SNI encryption can be easily differ
from entiated from
&quot;regular&quot; handshakes. For example, some designs require specific exten "regular" handshakes. For example, some designs require specific extensions in
sions in the ClientHello packets or specific values of the cleartext SNI parameter.
the Client Hello packets, or specific values of the clear text SNI parameter.
If adversaries can easily detect the use of SNI encryption, If adversaries can easily detect the use of SNI encryption,
they could block it, or they could flag the users of SNI encryption for they could block it, or they could flag the users of SNI encryption for
special treatment. special treatment.
</t> </t>
<t>In the future, it might be possible to assume that a large fraction of TLS ha ndshakes <t>In the future, it might be possible to assume that a large fraction o f TLS handshakes
use SNI encryption. If that were the case, the detection of SNI encryption would use SNI encryption. If that were the case, the detection of SNI encryption would
be a lesser concern. However, we have to assume that in the near future, only be a lesser concern. However, we have to assume that, in the near future, only
a small fraction of TLS connections will use SNI encryption. a small fraction of TLS connections will use SNI encryption.
</t> </t>
</section> <t>This requirement to not stick out may be difficult to meet in
practice, as noted in <xref target="secusec" format="default"/>.
<section anchor="forward-secrecy" title="Forward Secrecy">
<t>The general concerns about forward secrecy apply to SNI encryption just as we
ll as
to regular TLS sessions. For example, some proposed designs rely on a public key
of
the multiplexed server to define the SNI encryption key. If the corresponding
private key should be compromised, the adversaries would be able to process
archival records of past connections, and retrieve the protected SNI used in
these connections. These designs failed to maintain forward secrecy of SNI
encryption.
</t> </t>
</section>
<section anchor="nocontextsharing" title="Multi-Party Security Contexts"> </section>
<t>We can design solutions in which a fronting <section anchor="forward-secrecy" numbered="true" toc="default">
<name>Maintain Forward Secrecy</name>
<t>TLS 1.3 <xref target="RFC8446"/> is designed to provide forward
secrecy, so that (for example) keys used in past sessions will not be
compromised even if the private key of the server is compromised. The
general concerns about forward secrecy apply to SNI encryption as
well. For example, some proposed designs rely on a public key of the
multiplexed server to define the SNI encryption key. If the
corresponding private key should be compromised, the adversaries would
be able to process archival records of past connections and retrieve
the protected SNI used in these connections. These designs fail to
maintain forward secrecy of SNI encryption.
</t>
</section>
<section anchor="nocontextsharing" numbered="true" toc="default">
<name>Enable Multi-party Security Contexts</name>
<t>We can design solutions in which a fronting
service acts as a relay to reach the protected service. Some of those service acts as a relay to reach the protected service. Some of those
solutions involve just one TLS handshake between the client and the fronting ser vice. solutions involve just one TLS handshake between the client and the fronting ser vice.
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. the fronting service but not by the protected service.
These solutions expose the client to a Man-In-The-Middle attack by These solutions expose the client to a MITM attack by
the fronting service. Even if the client the fronting service. Even if the client
has some reasonable trust in this service, the possibility of has some reasonable trust in this service, the possibility of a
MITM attack is troubling. MITM attack is troubling.
</t> </t>
<t>There are other classes of solutions in which the master secret is verified b y <t>There are other classes of solutions in which the master secret is ve rified by
verifying a certificate provided by the protected service. These solutions offer verifying a certificate provided by the protected service. These solutions offer
more protection against MITM attack by the fronting service. The more protection against a MITM attack by the fronting service.
The
downside is that the client will not verify the identity of the fronting service , downside is that the client will not verify the identity of the fronting service ,
which enables fronting server spoofing attacks such as the &quot;honeypot&quot; attack which enables fronting server spoofing attacks, such as the "honeypot" attack
discussed below. Overall, end-to-end TLS to the protected service is preferable, discussed below. Overall, end-to-end TLS to the protected service is preferable,
but it is important to also provide a way to authenticate the fronting service. but it is important to also provide a way to authenticate the fronting service.
</t> </t>
<t>The fronting service could be pressured by adversaries. <t>The fronting service could be pressured by adversaries.
By design, it could be forced to deny access to By design, it could be forced to deny access to
the protected service, or to divulge which client accessed it. But the protected service or to divulge which client accessed it. But
if MITM is possible, the adversaries would also be able to pressure if a MITM attack is possible, the adversaries would also be able to pressure
the fronting service into intercepting or spoofing the communications between the fronting service into intercepting or spoofing the communications between
client and protected service. client and protected service.
</t> </t>
<t>Adversaries could also mount an attack by spoofing the fronting service. A <t>Adversaries could also mount an attack by spoofing the fronting servi
spoofed fronting service could act as a &quot;honeypot&quot; for users of ce. 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 much trust on the fronting server, the fake server could also
serve fake content of its own choosing, including various forms of serve fake content of its own choosing, including various forms of
malware. malware.
</t> </t>
<t>There are two main channels by which adversaries can conduct this <t>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 regular fronting server, using, for example, spoofed DNS responses
or spoofed IP level routing, combined with a spoofed certificate. or spoofed IP-level routing, combined with a spoofed certificate.
</t> </t>
</section> </section>
<section anchor="multi-protocol" numbered="true" toc="default">
<section anchor="multi-protocol" title="Supporting multiple protocols"> <name>Support Multiple Protocols</name>
<t>The SNI encryption requirement does not stop with HTTP over TLS. Multiple oth <t>The SNI encryption requirement does not stop with HTTP over
er TLS.
applications currently use TLS, including, for example, SMTP <xref target="RFC52 Multiple other
46"/>, applications currently use TLS, including, for example, SMTP <xref
DNS <xref target="RFC7858"/>, IMAP <xref target="RFC8314"/>, target="RFC3207" format="default"/>,
and XMPP <xref target="RFC7590"/>. These applications, too, will benefit from SN DNS <xref target="RFC7858" format="default"/>, IMAP <xref target="RFC8314"
I encryption. format="default"/>,
HTTP-only methods like those described in <xref target="httpfrontingtunnels"/> and the Extensible Messaging and Presence Protocol (XMPP) <xref target="RFC7590"
would not apply there. In fact, even for the HTTPS case, the HTTPS tunneling ser format="default"/>. These applications, too,
vice will benefit from SNI encryption.
described in <xref target="httpfrontingtunnels"/> is compatible with HTTP 1.0 an HTTP-only methods, like those described in <xref target="httpfrontingtunnels"
d HTTP 1.1, format="default"/>,
but interacts awkwardly with the multiple streams feature of HTTP/2 <xref target would not apply there. In fact, even for the HTTPS case, the HTTPS tunneling
="RFC7540"/>. service described in <xref target="httpfrontingtunnels" format="default"/> is
compatible with HTTP 1.0 and HTTP 1.1
but interacts awkwardly with the multiple streams feature of HTTP/2 <xref
target="RFC7540" format="default"/>.
This points to the need for an application-agnostic solution, which would be This points to the need for an application-agnostic solution, which would be
implemented fully in the TLS layer. implemented fully in the TLS layer.
</t> </t>
<section anchor="hiding-alpn" numbered="true" toc="default">
<section anchor="hiding-alpn" title="Hiding the Application Layer Protocol Negot <name>Hiding the Application-Layer Protocol Negotiation</name>
iation"> <t>The Application-Layer Protocol Negotiation (ALPN) parameters of
<t>The Application Layer Protocol Negotiation (ALPN) parameters of TLS TLS allow implementations to negotiate the application-layer
allow implementations to negotiate the application layer protocol used on protocol used on a given connection. TLS provides the ALPN values in
a given connection. TLS provides the ALPN values in clear text during the cleartext during the initial handshake. While exposing the ALPN
initial handshake. While exposing the ALPN does not create the same does not create the same privacy issues as exposing the SNI, there
privacy issues as exposing the SNI, there is still a risk. For example, is still a risk. For example, some networks may attempt to block
some networks may attempt to block applications that they do not applications that they do not understand or that they wish users
understand, or that they wish users would not use. would not use.
</t> </t>
<t>In a sense, ALPN filtering could be very similar to the filtering <t>In a sense, ALPN filtering could be very similar to the filtering
of specific port numbers exposed in some networks. This filtering by ports of specific port numbers exposed in some networks. This filtering by ports
has given rise to evasion tactics in which various protocols are tunneled has given rise to evasion tactics in which various protocols are tunneled
over HTTP in order to use open ports 80 or 443. Filtering by ALPN would over HTTP in order to use open ports 80 or 443. Filtering by ALPN would
probably beget the same responses, in which the applications just move probably beget the same responses, in which the applications just move
over HTTP, and only the HTTP ALPN values are used. Applications would not over HTTP and only the HTTP ALPN values are used.
Applications would not
need to do that if the ALPN were hidden in the same way as the SNI. need to do that if the ALPN were hidden in the same way as the SNI.
</t> </t>
<t>In addition to hiding the SNI, it is thus desirable to also hide the ALPN. <t>In addition to hiding the SNI, it is thus desirable to also hide
Of course, this implies engineering trade-offs. Using the same technique the ALPN. Of course, this implies engineering trade-offs. Using the
for hiding the ALPN and encrypting the SNI may result in excess complexity. same technique for hiding the ALPN and encrypting the SNI may result
It might be preferable to encrypt these independently. in excess complexity. It might be preferable to encrypt these
independently.
</t> </t>
</section> </section>
<section anchor="support-other-transports-than-tcp" numbered="true"
<section anchor="support-other-transports-than-tcp" title="Support other transpo toc="default">
rts than TCP"> <name>Supporting Other Transports than TCP</name>
<t>The TLS handshake is also used over other transports such as UDP <t>The TLS handshake is also used over other transports, such as UDP
with both DTLS <xref target="I-D.ietf-tls-dtls13"/> and with both DTLS <xref target="I-D.ietf-tls-dtls13" format="default"/> and
QUIC <xref target="I-D.ietf-quic-tls"/>. The requirement to encrypt the SNI QUIC <xref target="I-D.ietf-quic-tls" format="default"/>. The requirement to
applies just as well for these transports as for TLS over TCP. encrypt the SNI applies just as well for these transports as for TLS over
TCP.
</t> </t>
<t>This points to a requirement for SNI Encryption mechanisms to also <t>This points to a requirement for SNI encryption mechanisms to also
be applicable to non-TCP transports such as DTLS or QUIC. be applicable to non-TCP transports such as DTLS or QUIC.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="httpfronting" numbered="true" toc="default">
<section anchor="httpfronting" title="HTTP Co-Tenancy Fronting"> <name>HTTP Co-tenancy Fronting</name>
<t>In the absence of TLS-level SNI encryption, many sites rely on an &quot;HTTP <t>In the absence of TLS-level SNI encryption, many sites rely on an
Co-Tenancy&quot; "HTTP co-tenancy" solution, often referred to as "domain fronting" <xref
solution, often refered to as Domain Fronting <xref target="domfront"/>. target="DOMFRONT" format="default"/>. The TLS connection is established
The TLS connection is established with the fronting server, and with the fronting server, and HTTP requests are then sent over that
HTTP requests are then sent over that connection to the hidden service. For connection to the hidden service.
example, the TLS SNI could be set to &quot;fronting.example.com&quot;, the front For example, the TLS SNI could be set
ing to "fronting.example.com" (the fronting server), and HTTP requests sent
server, and HTTP requests sent over that connection could be directed over that connection could be directed to "hidden.example.com"
to &quot;hidden.example.com&quot;, accessing the hidden service. (accessing the hidden service). This solution works well in
This solution works well in
practice when the fronting server and the hidden server practice when the fronting server and the hidden server
are &quot;co-tenants&quot; of the same multiplexed server. are "co-tenants" of the same multiplexed server.
</t>
<t>The HTTP fronting solution can be deployed without modification to the TLS
protocol, and does not require using any specific version of TLS. There are,
however, a few issues regarding discovery, client implementations, trust, and
applicability:
</t>
<t>
<list style="symbols">
<t>The client has to discover that the hidden service can be accessed through
the fronting server.</t>
<t>The client's browser has to be directed to access the hidden service
through the fronting service.</t>
<t>Since the TLS connection is established with the fronting service, the
client has no cryptographic proof that the content does, in fact, come from
the hidden service. The solution does thus not mitigate the context sharing
issues described in <xref target="nocontextsharing"/>.</t>
<t>Since this is an HTTP-level solution, it does not protect non-HTTP
protocols as discussed in <xref target="multi-protocol"/>.</t>
</list>
</t> </t>
<t>The discovery issue is common to most SNI encryption solutions. <t>The HTTP domain fronting solution can be deployed without modification
The browser issue was solved in <xref target="domfront"/> by implementing domain to
fronting the TLS protocol and does not require using any specific version of
as a pluggable transport for the Tor browser. The multi-protocol issue TLS. There are, however, a few issues regarding discovery, client
can be mitigated by using implementation of other applications over HTTP, implementations, trust, and applicability:
such as for example DNS over HTTPS <xref target="RFC8484"/>. The trust
issue, however, requires specific developments.
</t> </t>
<ul spacing="normal">
<li>The client has to discover that the hidden service can be accessed
through the fronting server.</li>
<li>The client's browser has to be directed to access the hidden
service through the fronting service.</li>
<li>Since the TLS connection is established with the fronting service,
the client has no cryptographic proof that the content does, in fact,
come from the hidden service. Thus, the solution does not mitigate the
context sharing issues described in <xref target="nocontextsharing"
format="default"/>. Note that this is already the case for
co-tenanted sites.</li>
<li>Since this is an HTTP-level solution, it does not protect non-HTTP
protocols, as discussed in <xref target="multi-protocol" format="default"/>.</li
>
</ul>
<section anchor="httpfrontingtunnels" title="HTTPS Tunnels"> <t>The discovery issue is common to most SNI encryption solutions.
<t>The HTTP Fronting solution places a lot of trust in the Fronting Server. This The browser issue was solved in <xref target="DOMFRONT" format="default"/> by
required trust can be reduced by tunnelling HTTPS in HTTPS, which effectively implementing domain fronting as a pluggable transport for the Tor browser. The
treats the Fronting Server as an HTTP Proxy. In this solution, the client multi-protocol issue can be mitigated by implementing other
establishes a TLS connection to the Fronting Server, and then issues applications over HTTP, for example, DNS over HTTPS <xref
an HTTP Connect request to the Hidden Server. This will target="RFC8484" format="default"/>. The trust issue, however, requires
establish an end-to-end HTTPS over TLS connection between the client specific developments.
and the Hidden Server, mitigating the issues described in <xref target="nocontex
tsharing"/>.
</t> </t>
<t>The HTTPS in HTTPS solution requires double encryption of every packet. It <section anchor="httpfrontingtunnels" numbered="true" toc="default">
<name>HTTPS Tunnels</name>
<t>The HTTP domain fronting solution places a lot of trust in the fronti
ng
server. This required trust can be reduced by tunneling HTTPS in
HTTPS, which effectively treats the fronting server as an HTTP
proxy. In this solution, the client establishes a TLS connection to
the fronting server and then issues an HTTP connect request to the
hidden server. This will establish an end-to-end HTTPS-over-TLS
connection between the client and the hidden server, mitigating the
issues described in <xref target="nocontextsharing"
format="default"/>.
</t>
<t>The HTTPS-in-HTTPS solution requires double encryption of every packe
t. It
also requires that the fronting server decrypt and relay messages to the also requires that the fronting server decrypt and relay messages to the
hidden server. Both of these requirements make the implementation onerous. hidden server. Both of these requirements make the implementation onerous.
</t> </t>
</section> </section>
<section anchor="delegationtokens" numbered="true" toc="default">
<section anchor="delegationtokens" title="Delegation Control"> <name>Delegation Control</name>
<t>Clients would see their privacy compromised if they contacted the wrong <t>Clients would see their privacy compromised if they contacted the wro
ng
fronting server to access the hidden service, since this wrong server fronting server to access the hidden service, since this wrong server
could disclose their access to adversaries. This requires a controlled could disclose their access to adversaries. This requires a controlled
way to indicate which fronting server is acceptable by the hidden service. way to indicate which fronting server is acceptable by the hidden service.
</t> </t>
<t>This problem is both similar and different from the &quot;fronting server <t>This problem is similar to the "word of mouth" variant
spoofing&quot; attack described in <xref target="nocontextsharing"/>. Here, the of the "fronting server
spoofing spoofing" attack described in <xref target="nocontextsharing"
would be performed by distributing fake advice, such as &quot;to reach format="default"/>. The spoofing
would be performed by distributing fake advice, such as "to reach
hidden.example.com, use fake.example.com as a fronting hidden.example.com, use fake.example.com as a fronting
server&quot;, when &quot;fake.example.com&quot; is under the control of an server", when "fake.example.com" is under the control of an
adversary. adversary.
</t> </t>
<t>In practice, this attack is well mitigated when the hidden service is <t>In practice, this attack is well mitigated when the hidden service
accessed through a specialized application. The name of the fronting server is accessed through a specialized application. The name of the
can then be programmed in the code of the application. But the attack is fronting server can then be programmed in the code of the
harder to mitigate when the hidden service has to be accessed through general application. But the attack is harder to mitigate when the hidden
purpose web browsers. service has to be accessed through general-purpose web browsers.
</t> </t>
<t>There are several proposed solutions to this problem, such as creating
a special form of certificate to codify the relation between fronting and <t>There are several proposed solutions to this problem, such as creatin
hidden server, or obtaining the relation between hidden and fronting service g
through the DNS, possibly using DNSSEC to avoid spoofing. The experiment a special form of certificate to codify the relation between the fronting and
described in <xref target="domfront"/> solved the issue by integrating with the hidden server or obtaining the relation between the hidden and fronting service
Lantern Internet circumvention circumvention tool. through the DNS, possibly using DNSSEC, to avoid spoofing.
The experiment
described in <xref target="DOMFRONT" format="default"/> solved the issue by
integrating with the Lantern Internet circumvention tool.
</t> </t>
<t>We can observe that CDNs have a similar requirement. <t>We can observe that CDNs have a similar requirement.
They need to convince the client that &quot;www.example.com&quot; can be accesse They need to convince the client that "www.example.com" can be accessed
d through the seemingly unrelated "cdn-node-xyz.example.net". Most CDNs have
through the seemingly unrelated &quot;cdn-node-xyz.example.net&quot;. Most CDNs
have
deployed DNS-based solutions to this problem. However, the CDN often deployed DNS-based solutions to this problem. However, the CDN often
holds the authoritative certificate of the origin. There is simultaneously holds the authoritative certificate of the origin. There is, simultaneously,
verification of a relationship between the origin and the CDN, through the certi verification of a relationship between the origin and the CDN (through the
ficate, certificate) and a risk that the CDN can spoof the
and a risk that the CDN can spoof the
content from the origin. content from the origin.
</t> </t>
</section> </section>
<section anchor="related-work" numbered="true" toc="default">
<section anchor="related-work" title="Related work"> <name>Related Work</name>
<t>The ORIGIN frame defined for HTTP/2 <xref target="RFC8336"/> can be used to f <t>The ORIGIN frame defined for HTTP/2 <xref target="RFC8336"
lag content format="default"/> can be used to flag content provided by the hidden
provided by the hidden server. Secondary certificate authentication server. Secondary certificate authentication <xref
<xref target="I-D.ietf-httpbis-http2-secondary-certs"/> can be used to manage target="I-D.ietf-httpbis-http2-secondary-certs" format="default"/> can
authentication of hidden server content, or to perform client be used to manage authentication of hidden server content or to
authentication before accessing hidden content. perform client authentication before accessing hidden content.
</t> </t>
</section> </section>
</section> </section>
<section anchor="secusec" numbered="true" toc="default">
<section anchor="secusec" title="Security Considerations"> <name>Security Considerations</name>
<t>This document lists a number of attacks against SNI encryption in <xref targe <t>This document lists a number of attacks against SNI encryption in Secti
t="snisecreq"/> ons
and also in <xref target="delegationtokens"/>, and presents a list of requiremen <xref target="snisecreq" format="counter"></xref> and <xref
ts target="delegationtokens" format="counter"></xref> and presents a list of
to mitigate these attacks. Current HTTP-based solutions requirements to mitigate these attacks. Current HTTP-based solutions
described in <xref target="httpfronting"/> only meet some of these requirements. described in <xref target="httpfronting" format="default"/> only meet some of
In practice, it may well be that no solution can meet every requirement, these requirements. In practice, it may well be that no solution can meet
and that practical solutions will have to make some compromises. every requirement and that practical solutions will have to make some
compromises.
</t> </t>
<t>In particular, the requirement to not stick out presented in <t>In particular, the requirement to not stick out, presented in
<xref target="snireqdontstickout"/> may have to be lifted, especially <xref target="snireqdontstickout" format="default"/>, may have to be lifted,
for proposed solutions that could quickly reach large scale deployments. especially for proposed solutions that could quickly reach large-scale
deployments.
</t> </t>
<t>Replacing clear text SNI transmission by an encrypted variant will break <t>Replacing cleartext SNI transmission by an encrypted variant will
or reduce the efficacy of the operational practices and techniques break or reduce the efficacy of the operational practices and techniques
implemented in middle-boxes as described in <xref target="snileak"/>. implemented in middleboxes, as described in <xref target="snileak"
As explained in <xref target="end-to-end"/>, alternative solutions will have to format="default"/>. As explained in <xref target="end-to-end"
be developed. format="default"/>, alternative solutions will have to be developed.
</t> </t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This draft does not require any IANA action. <t>This document has no IANA actions.
</t> </t>
</section> </section>
<section anchor="acknowledgements" title="Acknowledgements"> </middle>
<t>A large part of this draft originates in discussion of SNI encryption <back>
<displayreference target="I-D.ietf-httpbis-http2-secondary-certs"
to="HTTP2-SEC-CERTS"/>
<displayreference target="I-D.ietf-quic-tls" to="QUIC"/>
<displayreference target="I-D.ietf-tls-dtls13" to="DTLS-1.3"/>
<references>
<name>Informative References</name>
<!-- draft-ietf-httpbis-http2-secondary-certs-05: I-D Exits -->
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-httpbis-http2-secondary-certs.xml"/>
<!-- draft-ietf-quic-tls-24: I-D Exists -->
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-quic-tls.xml"/>
<!-- draft-ietf-tls-dtls13-34: Publication Requested -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-tls-dtls13.xml"/>
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.22
46.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3207.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3546.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4346.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4366.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5246.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6066.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7258.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7540.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7590.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7858.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8314.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8336.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8404.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8484.xml"/>
<reference anchor="DOMFRONT" target="https://www.bamsoftware.com/papers/fr
onting/">
<front>
<title>Blocking-resistant communication through domain fronting</title
>
<seriesInfo name="DOI" value="10.1515/popets-2015-0009"/>
<author initials="D." surname="Fifield" fullname="David Fifield">
<organization/>
</author>
<author initials="C." surname="Lan" fullname="Chang Lan">
<organization/>
</author>
<author initials="R." surname="Hynes" fullname="Rod Hynes">
<organization/>
</author>
<author initials="P." surname="Wegmann" fullname="Percy Wegmann">
<organization/>
</author>
<author initials="V." surname="Paxson" fullname="Vern Paxson">
<organization/>
</author>
<date year="2015"/>
</front>
</reference>
</references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>A large part of this document originated in discussion of SNI encryptio
n
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:
<eref target="https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90 <eref
Ftw"/>. target="https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90Ft
w"
brackets="angle"/>.
</t> </t>
<t>Thanks to Daniel Kahn Gillmor for a pretty detailed review of the <t>Thanks to <contact fullname="Daniel Kahn Gillmor"/> for a pretty
initial draft. Thanks to Bernard Aboba, Mike Bishop, Alissa Cooper, detailed review of the initial draft of this document. Thanks to
Roman Danyliw, Stephen Farrell, Warren Kumari, Mirja Kuelewind <contact fullname="Bernard Aboba"/>, <contact fullname="Mike Bishop"/>,
Barry Leiba, Martin Rex, Adam Roach, <contact fullname="Alissa Cooper"/>, <contact fullname="Roman
Meral Shirazipour, Martin Thomson, Eric Vyncke, and employees of the Danyliw"/>, <contact fullname="Stephen Farrell"/>, <contact
UK National Cyber Security Centre for their reviews. Thanks to fullname="Warren Kumari"/>, <contact fullname="Mirja Kuelewind"/>,
Chris Wood, Ben Kaduk and Sean Turner for helping publish this <contact fullname="Barry Leiba"/>, <contact fullname="Martin Rex"/>,
document. <contact fullname="Adam Roach"/>, <contact fullname="Meral
Shirazipour"/>, <contact fullname="Martin Thomson"/>, <contact
fullname="Eric Vyncke"/>, and employees of the UK National Cyber
Security Centre for their reviews. Thanks to <contact fullname="Chris
Wood"/>, <contact fullname="Ben Kaduk"/>, and <contact fullname="Sean
Turner"/> for helping move this document toward publication.
</t> </t>
</section> </section>
</middle>
<back>
<references title="Informative References">
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-httpbis-http2-secondary-certs.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-quic-tls.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-tls-dtls13.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.22
46.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.35
46.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.43
46.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.43
66.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.52
46.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.60
66.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.72
58.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.75
40.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.75
90.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.78
58.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.83
14.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.83
36.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84
04.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84
46.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84
84.xml"?>
<reference anchor='domfront' target='https://www.bamsoftware.com/papers/fronting
/'>
<front>
<title>Blocking-resistant communication through domain fronting</title>
<author initials='D.' surname='Fifield' fullname='David Fifield'>
<organization/>
</author>
<author initials='C.' surname='Lan' fullname='Chang Lan'>
<organization/>
</author>
<author initials='R.' surname='Hynes' fullname='Rod Hynes'>
<organization/>
</author>
<author initials='P.' surname='Wegmann' fullname='Percy Wegmann'>
<organization/>
</author>
<author initials='V.' surname='Paxson' fullname='Vern Paxson'>
<organization/>
</author>
<date year='2015'/>
</front>
<seriesInfo name="DOI" value="10.1515/popets-2015-0009"/> </back>
</reference>
</references>
</back>
</rfc> </rfc>
 End of changes. 93 change blocks. 
478 lines changed or deleted 528 lines changed or added

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