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">		<title abbrev="TLS-SNI Encryption Requirements">Issues and Requirements
	<organization>Private Octopus Inc.</organization>		for Server Name Identification (SNI) Encryption in TLS</title>
	<address>		<seriesInfo name="RFC" value="8744"/>
	<postal>		<author initials="C." surname="Huitema" fullname="Christian Huitema">
	<street></street>		<organization>Private Octopus Inc.</organization>
	<city>Friday Harbor</city>		<address>
	<code>WA 98250</code>		<postal>
	<country>U.S.A</country>		<street/>
	<region></region>		<city>Friday Harbor</city>
	</postal>		<region>WA</region>
	<phone></phone>		<code>98250</code>
	<email>huitema@huitema.net</email>		<country>United States of America</country>
	<uri></uri>		</postal>
	</address>		<phone/>
	</author>		<email>huitema@huitema.net</email>
	<author initials="E." surname="Rescorla" fullname="Eric Rescorla">		<uri/>
	<organization>RTFM, Inc.</organization>		</address>
	<address>		</author>
	<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>		<date month="July" year="2020"/>
	<workgroup></workgroup>		<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>
			<xi:include
			href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
			etf-httpbis-http2-secondary-certs.xml"/>
			<xi:include
			href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
			etf-quic-tls.xml"/>
			<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
	</t>		w"
	<t>Thanks to Daniel Kahn Gillmor for a pretty detailed review of the		brackets="angle"/>.
	initial draft. 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, and employees of the
	UK National Cyber Security Centre for their reviews. Thanks to
	Chris Wood, Ben Kaduk and Sean Turner for helping publish this
	document.
	</t>		</t>
	</section>
	</middle>		<t>Thanks to Eric Rescorla for his multiple suggestions, reviews, and edits
	<back>		to the successive draft versions of this document.
	<references title="Informative References">		</t>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i		<t>Thanks to <contact fullname="Daniel Kahn Gillmor"/> for a pretty
	etf-httpbis-http2-secondary-certs.xml"?>		detailed review of the initial draft of this document. Thanks to
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i		<contact fullname="Bernard Aboba"/>, <contact fullname="Mike Bishop"/>,
	etf-quic-tls.xml"?>		<contact fullname="Alissa Cooper"/>, <contact fullname="Roman
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i		Danyliw"/>, <contact fullname="Stephen Farrell"/>, <contact
	etf-tls-dtls13.xml"?>		fullname="Warren Kumari"/>, <contact fullname="Mirja Kuelewind"/>,
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.22		<contact fullname="Barry Leiba"/>, <contact fullname="Martin Rex"/>,
	46.xml"?>		<contact fullname="Adam Roach"/>, <contact fullname="Meral
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.35		Shirazipour"/>, <contact fullname="Martin Thomson"/>, <contact
	46.xml"?>		fullname="Eric Vyncke"/>, and employees of the UK National Cyber
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.43		Security Centre for their reviews. Thanks to <contact fullname="Chris
	46.xml"?>		Wood"/>, <contact fullname="Ben Kaduk"/>, and <contact fullname="Sean
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.43		Turner"/> for helping move this document toward publication.
	66.xml"?>		</t>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.52		</section>
	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. 94 change blocks.
	477 lines changed or deleted		514 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/