<?xml version="1.0" encoding="UTF-8"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []> "rfc2629-xhtml.ent">
<rfc number="8744" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude"
     category="info" docName="draft-ietf-tls-sni-encryption-09">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?> docName="draft-ietf-tls-sni-encryption-09" obsoletes=""
     updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
     symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.37.3 -->

    <title abbrev="TLS-SNI Encryption Requirements">Issues and Requirements
    for SNI 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>
          <city>Friday Harbor</city>
<code>WA  98250</code>
          <country>United States of America</country>
    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>RTFM, Inc.</organization>
          <country>United States of America</country>
    <date year="2019" month="October" day="28"/> month="March" year="2020"/>

      <t>This draft document describes the general problem of encrypting the
Server Name Identification (SNI) TLS parameter. The proposed
solutions hide a Hidden Service hidden service behind a fronting service,
only disclosing the SNI of the fronting service to external
observers. The draft This document lists known attacks against
SNI encryption, discusses the current &quot;co-tenancy fronting&quot; "HTTP co-tenancy" solution,
and presents requirements for future TLS layer TLS-layer solutions.

      <t>In practice, it may well be that no solution can meet every requirement, requirement
and that practical solutions will have to make some compromises.
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <t>Historically, adversaries have been able to monitor the use of web
services through three primary channels: looking at DNS requests, looking
at IP addresses in packet headers, and looking at the data stream between
user and services. These channels are getting progressively closed.
A growing fraction of
Internet communication is encrypted, mostly using Transport Layer Security
(TLS) <xref target="RFC5246"/>. target="RFC8446" format="default"/>.
Progressive deployment of solutions like DNS in over
TLS <xref target="RFC7858"/> target="RFC7858" format="default"/> and DNS over HTTPS <xref target="RFC8484"/>
target="RFC8484" format="default"/>
mitigates the disclosure of DNS information. More and
more services are colocated on multiplexed servers, loosening the
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,
and the IP address and port do not uniquely identify a service. In cloud or
Content Delivery Networks (CDNs) Network (CDN) solutions, a given platform hosts the services
or servers servers of a lot of organization, organizations, and looking up to what netblock
an IP address belongs to reveals little. However, multiplexed servers
rely on the Service Server Name Information (SNI) TLS extension <xref target="RFC6066"/>
target="RFC6066" format="default"/> to direct connections
to the appropriate service implementation. This protocol element
is transmitted in clear text. cleartext. As the other methods of monitoring get
blocked, monitoring focuses on the clear text cleartext SNI. The purpose
of SNI encryption is to prevent that and aid privacy.
      <t>Replacing clear text cleartext SNI transmission by an encrypted variant will
improve the privacy and reliability of TLS connections, but the design
of proper SNI encryption solutions is difficult.
In the past, there have been multiple attempts at defining SNI encryption.
These attempts have generally floundered, because the simple designs fail
to mitigate several of the attacks listed in <xref target="snisecreq"/>. target="snisecreq"
format="default"/>. In the absence of
a TLS-level solution, the most popular approach to SNI privacy for web
services is HTTP-level fronting, which we discuss in <xref target="httpfronting"/>.
target="httpfronting" format="default"/>.
      <t>This document does not present the design of a solution, solution but
provides guidelines for evaluating proposed solutions. (The review of
HTTP-level solutions in <xref target="httpfronting"/> target="httpfronting" format="default"/> is not
an endorsement of these solutions.)
The need for related work on the encryption of the Application Layer Application-Layer
Protocol Negotiation (ALPN) parameters of TLS is discussed in
<xref target="hiding-alpn"/>. target="hiding-alpn" format="default"/>.
    <section anchor="history-of-the-tls-sni-extension" title="History numbered="true" toc="default">
      <name>History of the TLS SNI extension"> Extension</name>
      <t>The SNI extension was specified in 2003 in <xref target="RFC3546"/> target="RFC3546"
      format="default"/> to facilitate management
of &quot;colocation servers&quot;, "colocation servers", in which multiple services shared the same IP
address. A typical example would be multiple web sites websites served by the
same web server. The SNI extension carries the name of a specific
server, enabling the TLS connection to be established with the desired
server context. The current SNI extension specification can be
found in <xref target="RFC6066"/>. target="RFC6066" format="default"/>.
      <t>The SNI specification allowed for different types of server names,
though only the &quot;hostname&quot; "hostname" variant was specified and deployed. In that
variant, the SNI extension carries the domain name of the target
server. The SNI extension is carried in clear text cleartext in the TLS &quot;ClientHello&quot; "ClientHello"
      <section anchor="snileak" title="Unanticipated usage numbered="true" toc="default">
        <name>Unanticipated Usage of SNI information"> Information</name>
        <t>The SNI was defined to facilitate management of servers, but the
developers of middleboxes found out that they could take
advantage of the information. Many examples of such usage are
reviewed in <xref target="RFC8404"/>. target="RFC8404" format="default"/>. Other examples came out
during discussions of this draft. document. They include:
<list style="symbols">
        <ul spacing="normal">
          <li>Filtering or censorship of censoring specific services for a variety of reasons.</t>
<t>Content reasons</li>

          <li>Content filtering by network operators or ISP ISPs blocking specific web sites
in order to implement,
	  websites, for example, to implement parental controls, controls or to prevent access
to phishing or other fraudulent web sites.</t>
<t>ISP websites</li>
          <li>ISP assigning different QoS profiles to target services,</t>
<t>Firewalls services</li>
          <li>Firewalls within enterprise networks blocking web sites websites not deemed
appropriate for work, or</t>
<t>Firewalls work</li>
          <li>Firewalls within enterprise networks exempting specific web sites websites from
man-in-the-middle (MITM) inspection, such as healthcare or financial
sites for which inspection would intrude on the privacy of employees.</t>
</t> employees</li>
        <t>The SNI is probably also included in the general collection of metadata
by pervasive surveillance actors <xref target="RFC7258"/>, target="RFC7258" format="default"/>,
for example example, to identify services
used by surveillance targets.
      <section anchor="sniwhyencryptnow" title="SNI encryption timeliness"> numbered="true" toc="default">
        <name>SNI Encryption Timeliness</name>
        <t>The clear-text cleartext transmission of the SNI was not flagged as a problem
in the security consideration Security Considerations sections of <xref target="RFC3546"/>, target="RFC3546"
format="default"/>, <xref target="RFC4366"/>, target="RFC4366" format="default"/>, or
<xref target="RFC6066"/>. target="RFC6066" format="default"/>. These specifications did not anticipate the
alternative usage described
in <xref target="snileak"/>. target="snileak" format="default"/>. One reason may be that, when
these RFCs were written, the
SNI information was available through a variety of other means,
such as tracking IP addresses, DNS names, or server certificates.
        <t>Many deployments still allocate different IP addresses to different
services, so that different services can be identified by their IP
addresses. However, CDNs commonly
serve a large number of services through a comparatively small
number of addresses.
        <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="snileak"/>
target="snileak" format="default"/>
could also be implemented by monitoring DNS traffic or controlling DNS
usage. But this is changing with the advent of DNS resolvers
providing services like DNS over TLS <xref target="RFC7858"/> target="RFC7858" format="default"/>
or DNS over HTTPS <xref target="RFC8484"/>. target="RFC8484" format="default"/>.

        <t>The subjectAltName extension of type dNSName of the server certificate,
or certificate
(or in its absence absence, the common name component, expose component) exposes
the same name as the SNI. In TLS versions 1.0 <xref target="RFC2246"/>, target="RFC2246"
format="default"/>, 1.1 <xref target="RFC4346"/>, target="RFC4346" format="default"/>,
and 1.2 <xref target="RFC5246"/>, target="RFC5246" format="default"/>, servers send certificates in clear text, cleartext,
ensuring that there would be limited benefits in hiding the SNI. However,
in TLS 1.3 <xref target="RFC8446"/>, target="RFC8446" format="default"/>, server certificates are
encrypted in transit.
Note that encryption alone is insufficient to protect server certificates;
see <xref target="replayattack"/> target="cutandpasteattack" format="default"/> for details.

        <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 RFC 7258-style adversary
        <xref target="RFC7258"/>-style
adversary. target="RFC7258" format="default"/>. Encrypting the SNI
        complements this push for privacy and
make makes it harder to censor or
        otherwise provide differential treatment to specific internet Internet
      <section anchor="end-to-end" title="End-to-end alternatives"> numbered="true" toc="default">
        <name>End-to-End Alternatives</name>
        <t>Deploying SNI encryption helps thwart most of the unanticipated SNI usages usages,
including censorship and pervasive surveillance, but it also
will break or reduce the efficacy of the operational practices and
techniques implemented in middle-boxes middleboxes, as described in <xref target="snileak"/>. target="snileak"
format="default"/>. Most of
these functions can, however, be realized by other means. For example, some DNS service
providers offer customers the provision to &quot;opt in&quot; "opt in" to filtering services
for parental control and phishing protection. Per-stream QoS could be provided by
a combination of packet marking and end-to-end agreements. As
SNI encryption becomes common, we can expect more deployment of such &quot;end-to-end&quot; "end-to-end"
        <t>At the time of this writing, enterprises have the option of installing a
firewall performing SNI filtering to
prevent connections to certain websites. With SNI encryption 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.
Enterprise managers could rely instead on filtering software and management
software deployed on the enterprise's computers.
    <section anchor="snisecreq" title="Security numbered="true" toc="default">
      <name>Security and Privacy Requirements for SNI Encryption"> Encryption</name>
      <t>Over the past years, there have been multiple proposals to add an SNI encryption
option in TLS. A review of the TLS mailing list archives shows that
many of these proposals appeared promising but were rejected
after security reviews identified plausible attacks. In this section,
we collect a list of these known attacks.
      <section anchor="replayattack" title="Mitigate Replay Attacks"> anchor="cutandpasteattack" numbered="true" toc="default">
        <name>Mitigate Cut-and-Paste Attacks</name>
        <t>The simplest SNI encryption designs
	replace the cleartext SNI in the initial TLS
   exchange the clear text SNI with
an encrypted value, using a key known to the multiplexed server. Regardless of the
encryption used, these designs can be broken by a simple replay cut-and-paste attack, which works
as follows:
<t>1- The
<ol spacing="normal" type="1">
        <li>The user starts a TLS connection to the multiplexed server, including an encrypted
   SNI value.
<t>2- The value.</li>
        <li>The adversary observes the exchange and copies the encrypted SNI parameter.
<t>3- The parameter.</li>
        <li>The adversary starts its own connection to the multiplexed server, including in its
   connection parameters the encrypted SNI copied from the observed exchange.
<t>4- The exchange.</li>
        <li>The multiplexed server establishes the connection to the protected service, which sends its certificate, thus revealing the identity of the service.
</t> service.</li>

        <t>One of the goals of SNI encryption is to prevent adversaries from knowing which
Hidden Service
hidden service the client is using. Successful replay cut-and-paste attacks break that goal by
allowing adversaries to discover that service.
</t> service.</t>

      <section anchor="sharedsecrets" title="Avoid numbered="true" toc="default">
        <name>Avoid Widely Shared Secrets"> Secrets</name>
        <t>It is easy to think of simple schemes in which the SNI is encrypted or hashed using a
shared secret. This symmetric key must be known by the multiplexed server, server and by
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 protected
      <section anchor="serveroverload" title="Prevent SNI-based Denial of Service Attacks"> numbered="true" toc="default">
        <name>Prevent SNI-Based Denial-of-Service Attacks</name>
        <t>Encrypting the SNI may create extra load for the multiplexed server. Adversaries may mount
denial of service
denial-of-service (DoS) attacks by generating random encrypted SNI values and forcing the
multiplexed server to spend resources in useless decryption attempts.
        <t>It may be argued that this is not an important Denial of Service Attacks (DoS) avenue, avenue for DoS attacks,
as regular TLS connection
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 component
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 component.
      <section anchor="snireqdontstickout" title="Do not stick out"> numbered="true" toc="default">
        <name>Do Not Stick Out</name>
        <t>In some designs, handshakes using SNI encryption can be easily differentiated from
"regular" handshakes. For example, some designs require specific extensions in
the Client Hello packets, ClientHello packets or specific values of the clear text cleartext SNI parameter.
If adversaries can easily detect the use of SNI encryption,
they could block it, or they could flag the users of SNI encryption for
special treatment.
        <t>In the future, it might be possible to assume that a large fraction of TLS handshakes
use SNI encryption. If that were the case, the detection of SNI encryption would
be a lesser concern. However, we have to assume that that, in the near future, only
a small fraction of TLS connections will use SNI encryption.
        <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 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 just as well as
to regular TLS sessions.
        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, connections and retrieve
        the protected SNI used in these connections. These designs failed fail to
        maintain forward secrecy of SNI encryption.
      <section anchor="nocontextsharing" title="Multi-Party numbered="true" toc="default">
        <name>Enable Multi-party Security Contexts"> Contexts</name>
        <t>We can design solutions in which a fronting
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 service.
The master secret is verified by verifying a certificate provided by
the fronting service, service but not by the protected service.
These solutions expose the client to a Man-In-The-Middle MITM attack by
the fronting service. Even if the client
has some reasonable trust in this service, the possibility of a
MITM attack is troubling.
        <t>There are other classes of solutions in which the master secret is verified by
verifying a certificate provided by the protected service. These solutions offer
more protection against a MITM attack by the fronting service.
downside is that the client will not verify the identity of the fronting service,
which enables fronting server spoofing attacks attacks, such as the &quot;honeypot&quot; "honeypot" attack
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.
        <t>The fronting service could be pressured by adversaries.
By design, it could be forced to deny access to
the protected service, service or to divulge which client accessed it. But
if a MITM attack is possible, the adversaries would also be able to pressure
the fronting service into intercepting or spoofing the communications between
client and protected service.
        <t>Adversaries could also mount an attack by spoofing the fronting service. A
spoofed fronting service could act as a &quot;honeypot&quot; "honeypot" for users of
hidden services. At a minimum, the fake server could record the IP
addresses of these users. If the SNI encryption solution places too
much trust on the fronting server, the fake server could also
serve fake content of its own choosing, including various forms of
        <t>There are two main channels by which adversaries can conduct this
attack. Adversaries can simply try to mislead users into believing
that the honeypot is a valid fronting server, especially if that
information is carried by word of mouth or in unprotected DNS
records. Adversaries can also attempt to hijack the traffic to the
regular fronting server, using, for example, spoofed DNS responses
or spoofed IP level IP-level routing, combined with a spoofed certificate.
      <section anchor="multi-protocol" title="Supporting multiple protocols"> numbered="true" toc="default">
        <name>Support Multiple Protocols</name>
        <t>The SNI encryption requirement does not stop with HTTP over
Multiple other
applications currently use TLS, including, for example, SMTP <xref target="RFC5246"/>,
target="RFC3207" format="default"/>,
DNS <xref target="RFC7858"/>, target="RFC7858" format="default"/>, IMAP <xref target="RFC8314"/>, target="RFC8314"
and the Extensible Messaging and XMPP Presence Protocol (XMPP) <xref target="RFC7590"/>. target="RFC7590"
format="default"/>. These applications, too,
will benefit from SNI encryption.
HTTP-only methods methods, like those described in <xref target="httpfrontingtunnels"/> target="httpfrontingtunnels"
would not apply there. In fact, even for the HTTPS case, the HTTPS tunneling
service described in <xref target="httpfrontingtunnels"/> target="httpfrontingtunnels" format="default"/> is
compatible with HTTP 1.0 and HTTP 1.1, 1.1
but interacts awkwardly with the multiple streams feature of HTTP/2 <xref target="RFC7540"/>.
target="RFC7540" format="default"/>.
This points to the need for an application-agnostic solution, which would be
implemented fully in the TLS layer.
        <section anchor="hiding-alpn" title="Hiding numbered="true" toc="default">
          <name>Hiding the Application Layer Application-Layer Protocol Negotiation"> Negotiation</name>
          <t>The Application Layer Application-Layer Protocol Negotiation (ALPN) parameters of
	  TLS allow implementations to negotiate the application layer application-layer
	  protocol used on a given connection. TLS provides the ALPN values in clear text
	  cleartext during the initial handshake. While exposing the ALPN
	  does not create the same privacy issues as exposing the SNI, there
	  is still a risk. For example, some networks may attempt to block
	  applications that they do not
understand, understand or that they wish users
	  would not use.
          <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
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
probably beget the same responses, in which the applications just move
over HTTP, 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.
          <t>In addition to hiding the SNI, it is thus desirable to also hide
	  the 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
        <section anchor="support-other-transports-than-tcp" title="Support other transports numbered="true"
          <name>Supporting Other Transports than TCP"> TCP</name>
          <t>The TLS handshake is also used over other transports transports, such as UDP
with both DTLS <xref target="I-D.ietf-tls-dtls13"/> target="I-D.ietf-tls-dtls13" format="default"/> and
QUIC <xref target="I-D.ietf-quic-tls"/>. target="I-D.ietf-quic-tls" format="default"/>. The requirement to
encrypt the SNI applies just as well for these transports as for TLS over
          <t>This points to a requirement for SNI Encryption encryption mechanisms to also
be applicable to non-TCP transports such as DTLS or QUIC.
    <section anchor="httpfronting" title="HTTP Co-Tenancy Fronting"> numbered="true" toc="default">
      <name>HTTP Co-tenancy Fronting</name>
      <t>In the absence of TLS-level SNI encryption, many sites rely on an &quot;HTTP Co-Tenancy&quot;
      "HTTP co-tenancy" solution, often refered referred to as Domain Fronting "domain fronting" <xref target="domfront"/>.
      target="DOMFRONT" format="default"/>. The TLS connection is established
      with the fronting server, and HTTP requests are then sent over that
      connection to the hidden service.
For example, the TLS SNI could be set
      to &quot;fronting.example.com&quot;, the "fronting.example.com" (the fronting
server, server), and HTTP requests sent
      over that connection could be directed to &quot;hidden.example.com&quot;, accessing "hidden.example.com"
      (accessing the hidden service. service). This solution works well in
practice when the fronting server and the hidden server
are &quot;co-tenants&quot; "co-tenants" of the same multiplexed server.
      <t>The HTTP domain fronting solution can be deployed without modification to
      the TLS
protocol, protocol and does not require using any specific version of
      TLS. There are, however, a few issues regarding discovery, client
      implementations, trust, and applicability:
<list style="symbols">
      <ul spacing="normal">
        <li>The client has to discover that the hidden service can be accessed
	through the fronting server.</t>
<t>The server.</li>
        <li>The client's browser has to be directed to access the hidden
	service through the fronting service.</t>
<t>Since 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. The Thus, the solution does thus not mitigate the
	context sharing issues described in <xref target="nocontextsharing"/>.</t>
<t>Since 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"/>.</t>
</t> target="multi-protocol" format="default"/>.</li>

      <t>The discovery issue is common to most SNI encryption solutions.
The browser issue was solved in <xref target="domfront"/> target="DOMFRONT" format="default"/> by
implementing domain fronting as a pluggable transport for the Tor browser. The
multi-protocol issue can be mitigated by using implementation of implementing other
applications over HTTP,
such as for example example, DNS over HTTPS <xref target="RFC8484"/>.
target="RFC8484" format="default"/>. The trust issue, however, requires
specific developments.
      <section anchor="httpfrontingtunnels" title="HTTPS Tunnels"> numbered="true" toc="default">
        <name>HTTPS Tunnels</name>
        <t>The HTTP Fronting domain fronting solution places a lot of trust in the Fronting Server. fronting
	server. This required trust can be reduced by tunnelling tunneling HTTPS in
	HTTPS, which effectively treats the Fronting Server fronting server as an HTTP Proxy.
	proxy. In this solution, the client establishes a TLS connection to
	the Fronting Server, fronting server and then issues an HTTP Connect connect request to the Hidden Server.
	hidden server. This will establish an end-to-end HTTPS over TLS HTTPS-over-TLS
	connection between the client and the Hidden Server, hidden server, mitigating the
	issues described in <xref target="nocontextsharing"/>. target="nocontextsharing"
        <t>The HTTPS in HTTPS HTTPS-in-HTTPS solution requires double encryption of every packet. It
also requires that the fronting server decrypt and relay messages to the
hidden server. Both of these requirements make the implementation onerous.
      <section anchor="delegationtokens" title="Delegation Control"> numbered="true" toc="default">
        <name>Delegation Control</name>
        <t>Clients would see their privacy compromised if they contacted the wrong
fronting server to access the hidden service, since this wrong server
could disclose their access to adversaries. This requires a controlled
way to indicate which fronting server is acceptable by the hidden service.
        <t>This problem is both similar and different from to the &quot;fronting "word of mouth" variant
of the "fronting server
spoofing" attack described in <xref target="nocontextsharing"/>. Here, the target="nocontextsharing"
format="default"/>. The spoofing
would be performed by distributing fake advice, such as &quot;to "to reach
hidden.example.com, use fake.example.com as a fronting
server", when &quot;fake.example.com&quot; "fake.example.com" is under the control of an
        <t>In practice, this attack is well mitigated when the hidden service
        is accessed through a specialized application. The name of the
        fronting server can then be programmed in the code of the
        application. But the attack is harder to mitigate when the hidden
        service has to be accessed through general
purpose general-purpose web browsers.

        <t>There are several proposed solutions to this problem, such as creating
a special form of certificate to codify the relation between the fronting and
hidden server, server or obtaining the relation between the hidden and fronting service
through the DNS, possibly using DNSSEC DNSSEC, to avoid spoofing.
The experiment
described in <xref target="domfront"/> target="DOMFRONT" format="default"/> solved the issue by
integrating with the Lantern Internet circumvention circumvention tool.
        <t>We can observe that CDNs have a similar requirement.
They need to convince the client that &quot;www.example.com&quot; "www.example.com" can be accessed
through the seemingly unrelated &quot;cdn-node-xyz.example.net&quot;. "cdn-node-xyz.example.net". Most CDNs have
deployed DNS-based solutions to this problem. However, the CDN often
holds the authoritative certificate of the origin. There is simultaneously is, simultaneously,
verification of a relationship between the origin and the CDN, through CDN (through the certificate,
certificate) and a risk that the CDN can spoof the
content from the origin.
      <section anchor="related-work" title="Related work"> numbered="true" toc="default">
        <name>Related Work</name>
        <t>The ORIGIN frame defined for HTTP/2 <xref target="RFC8336"/> target="RFC8336"
	format="default"/> can be used to flag content provided by the hidden
	server. Secondary certificate authentication <xref target="I-D.ietf-httpbis-http2-secondary-certs"/>
	target="I-D.ietf-httpbis-http2-secondary-certs" format="default"/> can
	be used to manage authentication of hidden server content, content or to
	perform client authentication before accessing hidden content.
    <section anchor="secusec" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document lists a number of attacks against SNI encryption in Sections
      <xref target="snisecreq"/> target="snisecreq" format="counter"></xref> and also in <xref target="delegationtokens"/>,
      target="delegationtokens" format="counter"></xref> and presents a list of
      requirements to mitigate these attacks. Current HTTP-based solutions
described in <xref target="httpfronting"/> target="httpfronting" format="default"/> only meet some of
these requirements. In practice, it may well be that no solution can meet
every requirement, requirement and that practical solutions will have to make some
      <t>In particular, the requirement to not stick out out, presented in
<xref target="snireqdontstickout"/> target="snireqdontstickout" format="default"/>, may have to be lifted,
especially for proposed solutions that could quickly reach large scale large-scale
      <t>Replacing clear text cleartext SNI transmission by an encrypted variant will
      break or reduce the efficacy of the operational practices and techniques
implemented in middle-boxes middleboxes, as described in <xref target="snileak"/>. target="snileak"
format="default"/>. As explained in <xref target="end-to-end"/>, target="end-to-end"
format="default"/>, alternative solutions will have to be developed.
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This draft does not require any document has no IANA action. actions.


<displayreference target="I-D.ietf-httpbis-http2-secondary-certs"
<displayreference target="I-D.ietf-quic-tls" to="QUIC"/>
<displayreference target="I-D.ietf-tls-dtls13" to="DTLS-1.3"/>

      <name>Informative References</name>
<!-- draft-ietf-httpbis-http2-secondary-certs-05: I-D Exits -->
<!-- draft-ietf-quic-tls-24: I-D Exists -->
<!-- draft-ietf-tls-dtls13-34: Publication Requested -->
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-dtls13.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3207.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3546.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4346.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4366.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7540.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7590.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8314.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8336.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8404.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
      <reference anchor="DOMFRONT" target="https://www.bamsoftware.com/papers/fronting/">
          <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">
          <author initials="C." surname="Lan" fullname="Chang Lan">
          <author initials="R." surname="Hynes" fullname="Rod Hynes">
          <author initials="P." surname="Wegmann" fullname="Percy Wegmann">
          <author initials="V." surname="Paxson" fullname="Vern Paxson">
          <date year="2015"/>
    <section anchor="acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <t>A large part of this draft originates document originated in discussion of SNI encryption
on the TLS WG mailing list, including comments after the tunneling
approach was first proposed in a message to that list:
<eref target="https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90Ftw"/>.
      <t>Thanks to Daniel <contact fullname="Daniel Kahn Gillmor Gillmor"/> for a pretty
      detailed review of the initial draft. draft of this document. Thanks to Bernard Aboba, Mike Bishop, Alissa Cooper,
Roman Danyliw, Stephen Farrell, Warren Kumari, Mirja Kuelewind
Barry Leiba, Martin Rex, Adam Roach,
Meral Shirazipour, Martin Thomson, Eric Vyncke,
      <contact fullname="Bernard Aboba"/>, <contact fullname="Mike Bishop"/>,
      <contact fullname="Alissa Cooper"/>, <contact fullname="Roman
      Danyliw"/>, <contact fullname="Stephen Farrell"/>, <contact
      fullname="Warren Kumari"/>, <contact fullname="Mirja Kuelewind"/>,
      <contact fullname="Barry Leiba"/>, <contact fullname="Martin Rex"/>,
      <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
Chris Wood, Ben Kaduk and Sean Turner <contact fullname="Chris
      Wood"/>, <contact fullname="Ben Kaduk"/>, and <contact fullname="Sean
      Turner"/> for helping publish move this
document. document toward publication.

<references title="Informative References">
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-http2-secondary-certs.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-quic-tls.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-dtls13.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2246.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3546.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4346.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4366.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7540.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7590.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8314.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8336.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8404.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"?>
<reference anchor='domfront' target='https://www.bamsoftware.com/papers/fronting/'>
        <title>Blocking-resistant communication through domain fronting</title>
        <author initials='D.' surname='Fifield' fullname='David Fifield'>
        <author initials='C.' surname='Lan' fullname='Chang Lan'>
        <author initials='R.' surname='Hynes' fullname='Rod Hynes'>
        <author initials='P.' surname='Wegmann' fullname='Percy Wegmann'>
        <author initials='V.' surname='Paxson' fullname='Vern Paxson'>
        <date year='2015'/>

  <seriesInfo name="DOI" value="10.1515/popets-2015-0009"/>