Movatterモバイル変換

[0]ホーム

	rfc9849.original.xml	rfc9849.xml
	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

	<!-- generated by https://github.com/cabo/kramdown-rfc version1.7.29 (Ruby3.4.	<!-- generated by https://github.com/cabo/kramdown-rfc version1.7.30 (Ruby2.5.
	4) -->	9) -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-tls-esni-25" category="std" consensus="true" submissionType="IETF"tocIncl	-ietf-tls-esni-25" category="std" consensus="true" submissionType="IETF"number=
	ude="true" sortRefs="true" symRefs="true" version="3">	"9849" tocInclude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion3.28.1 -->	<!-- xml2rfc v2v3 conversion3.31.0 -->
		<link href="https://datatracker.ietf.org/doc/draft-ietf-tls-esni-25" rel="prev
		"/>
	<front>	<front>
	<title abbrev="TLS Encrypted Client Hello">TLS Encrypted Client Hello</title>	<title abbrev="TLS Encrypted Client Hello">TLS Encrypted Client Hello</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-25"/>	<seriesInfo name="RFC" value="9849"/>
	<author initials="E." surname="Rescorla" fullname="Eric Rescorla">	<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
	<organization>Independent</organization>	<organization>Independent</organization>
	<address>	<address>
	<email>ekr@rtfm.com</email>	<email>ekr@rtfm.com</email>
	</address>	</address>
	</author>	</author>

	<authorinitials="K." surname="Oku" fullname="Kazuho Oku">	<authorfullname="奥一穂" asciiFullname="Kazuho Oku">
	<organization>Fastly</organization>	<organization>Fastly</organization>
	<address>	<address>
	<email>kazuhooku@gmail.com</email>	<email>kazuhooku@gmail.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="N." surname="Sullivan" fullname="Nick Sullivan">	<author initials="N." surname="Sullivan" fullname="Nick Sullivan">
	<organization>Cryptography Consulting LLC</organization>	<organization>Cryptography Consulting LLC</organization>
	<address>	<address>
	<email>nicholas.sullivan+ietf@gmail.com</email>	<email>nicholas.sullivan+ietf@gmail.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="C. A." surname="Wood" fullname="Christopher A. Wood">	<author initials="C. A." surname="Wood" fullname="Christopher A. Wood">

	<organization>Cloudflare</organization>	<organization>Apple</organization>
	<address>	<address>
	<email>caw@heapingbits.net</email>	<email>caw@heapingbits.net</email>
	</address>	</address>
	</author>	</author>

	<date year="2025" month="June" day="14"/>	<date year="2026" month="February"/>
	<area>SEC</area>	<area>SEC</area>
	<workgroup>tls</workgroup>	<workgroup>tls</workgroup>

	<keyword>Internet-Draft</keyword>
	<abstract>	<abstract>

	<?line67?>	<?line109?>

		<!-- [rfced] References

		a) Regarding [WHATWG-IPV4], this reference's date is May 2021.
		The URL provided resolves to a page with "Last Updated 12 May 2025".

		Note that WHATWG provides "commit snapshots" of their living standards and
		there are several commit snapshots from May 2021 with the latest being from 20
		May 2021. For example: 20 May 2021
		(https://url.spec.whatwg.org/commit-snapshots/1b8b8c55eb4bed9f139c9a439fb1c1bf55
		66b619/#concept-ipv4-parser)

		We recommend updating this reference to the most current version of the WHATWG
		Living Standard, replacing the URL with the more general URL to the standard
		(https://url.spec.whatwg.org/), and adding a "commit snapshot" URL to the
		reference.

		Current:
		[WHATWG-IPV4]
		WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May
		2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>.

		d) FYI, RFCYYY1 (draft-ietf-tls-svcb-ech) will be updated during the XML stage.

		OK.
		-->

	<t>This document describes a mechanism in Transport Layer Security (TLS) for	<t>This document describes a mechanism in Transport Layer Security (TLS) for

	encrypting aClientHello message under a server public key.</t>	encrypting a<tt>ClientHello</tt> message under a server public key.</t>
	</abstract>	</abstract>

	<note removeInRFC="true">
	<name>Discussion Venues</name>
	<t>Source for this draft and an issue tracker can be found at
	<eref>https://github.com
	/tlswg/draft-ietf-tls-esni</eref>.</t>
	</note>
	</front>	</front>
	<middle>	<middle>

	<?line72?>	<?line139?>

	<section anchor="intro">	<section anchor="intro">
	<name>Introduction</name>	<name>Introduction</name>
	<t>Although TLS 1.3 <xref/> encrypts most of the handshake, including the	<t>Although TLS 1.3 <xref/> encrypts most of the handshake, including the
	server certificate, there are several ways in which an on-path attacker can	server certificate, there are several ways in which an on-path attacker can
	learn private information about the connection. The plaintext Server Name	learn private information about the connection. The plaintext Server Name

	Indication (SNI) extension inClientHello messages, which leaks the target	Indication (SNI) extension in<tt>ClientHello</tt> messages, which leaks the target
	domain for a given connection, is perhaps the most sensitive information	domain for a given connection, is perhaps the most sensitive information
	left unencrypted in TLS 1.3.</t>	left unencrypted in TLS 1.3.</t>

	<t>This document specifies a new TLSextension, called Encrypted ClientHe	<t>This document specifies a new TLSextension called Encrypted Client
	llo	Hello (ECH) that allows clients to encrypt their<tt>ClientHello</tt> to the
	(ECH), that allows clients to encrypt theirClientHello to the TLS server.	TLS server. This protects the SNI and other potentially sensitive
	This protects the SNI and other potentially sensitive fields, such as the	fields, such as theApplication-Layer Protocol Negotiation (ALPN) list
	Application Layer Protocol Negotiation (ALPN)	<xref/>. Co-located servers with consistent externallyvisible
	list <xref/>. Co-located servers with consistent externallyvis	TLS configurations and behavior, including supported versions and cipher suites
	ible TLS	and
	configurations and behavior, including supported versions and cipher suites and
	how they respond to incoming client connections, form an anonymity set. (Note	how they respond to incoming client connections, form an anonymity set. (Note
	that implementation-specific choices, such as extension ordering within TLS	that implementation-specific choices, such as extension ordering within TLS
	messages or division of data into record-layer boundaries, can result in	messages or division of data into record-layer boundaries, can result in
	different externally visible behavior, even for servers with consistent TLS	different externally visible behavior, even for servers with consistent TLS
	configurations.) Usage of this mechanism reveals that a client is connecting	configurations.) Usage of this mechanism reveals that a client is connecting
	to a particular service provider, but does not reveal which server from the	to a particular service provider, but does not reveal which server from the
	anonymity set terminates the connection. Deployment implications of this	anonymity set terminates the connection. Deployment implications of this
	feature are discussed in <xref/>.</t>	feature are discussed in <xref/>.</t>
	<t>ECH is not in itself sufficient to protect the identity of the server.	<t>ECH is not in itself sufficient to protect the identity of the server.
	The target domain may also be visible through other channels, such as	The target domain may also be visible through other channels, such as

	skipping to change at line 126 ¶	skipping to change at line 146 ¶
	\| \|	\| \|
	Client <-----> \| private.example.org \|	Client <-----> \| private.example.org \|
	\| \|	\| \|
	\| public.example.com \|	\| public.example.com \|
	\| \|	\| \|
	+---------------------+	+---------------------+
	Server	Server
	(Client-Facing and Backend Combined)	(Client-Facing and Backend Combined)
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>InShared Mode, the provider is the origin server for all the domains whose DNS	<t>Inshared mode, the provider is the origin server for all the domains whose DNS
	records point to it. In this mode, the TLS connection is terminated by the	records point to it. In this mode, the TLS connection is terminated by the
	provider.</t>	provider.</t>
	<figure anchor="split-mode">	<figure anchor="split-mode">
	<name>Split Mode Topology</name>	<name>Split Mode Topology</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	+--------------------+ +---------------------+	+--------------------+ +---------------------+
	\| \| \| \|	\| \| \| \|
	\| 2001:DB8::1111 \| \| 2001:DB8::EEEE \|	\| 2001:DB8::1111 \| \| 2001:DB8::EEEE \|
	Client <----------------------------->\| \|	Client <----------------------------->\| \|
	\| public.example.com \| \| private.example.org \|	\| public.example.com \| \| private.example.org \|
	\| \| \| \|	\| \| \| \|
	+--------------------+ +---------------------+	+--------------------+ +---------------------+
	Client-Facing Server Backend Server	Client-Facing Server Backend Server
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>InSplit Mode, the provider is not the origin server for private domains.	<t>Insplit mode, the provider is not the origin server for private domains.
	Rather, the DNS records for private domains point to the provider, and the	Rather, the DNS records for private domains point to the provider, and the
	provider's server relays the connection back to the origin server, who	provider's server relays the connection back to the origin server, who
	terminates the TLS connection with the client. Importantly, the service provider	terminates the TLS connection with the client. Importantly, the service provider
	does not have access to the plaintext of the connection beyond the unencrypted	does not have access to the plaintext of the connection beyond the unencrypted
	portions of the handshake.</t>	portions of the handshake.</t>
	<t>In the remainder of this document, we will refer to the ECH-service provider as	<t>In the remainder of this document, we will refer to the ECH-service provider as
	the "client-facing server" and to the TLS terminator as the "backend server".	the "client-facing server" and to the TLS terminator as the "backend server".

	These are the same entity inShared Mode, but in Split Mode, the client-facing	These are the same entity inshared mode, but in split mode, the client-facing
	and backend servers are physically separated.</t>	and backend servers are physically separated.</t>
	<t>See <xref/> for more discussion about the ECH threat model	<t>See <xref/> for more discussion about the ECH threat model
	and how it relates to the client, client-facing server, and backend server.</t>	and how it relates to the client, client-facing server, and backend server.</t>
	</section>	</section>
	<section anchor="encrypted-clienthello-ech">	<section anchor="encrypted-clienthello-ech">
	<name>Encrypted ClientHello (ECH)</name>	<name>Encrypted ClientHello (ECH)</name>
	<t>A client-facing server enables ECH by publishing an ECH configuration, which	<t>A client-facing server enables ECH by publishing an ECH configuration, which
	is an encryption public key and associated metadata. Domains which wish to	is an encryption public key and associated metadata. Domains which wish to
	use ECH must publish this configuration, using the key associated	use ECH must publish this configuration, using the key associated
	with the client-facing server. This document	with the client-facing server. This document
	defines the ECH configuration's format, but delegates DNS publication details	defines the ECH configuration's format, but delegates DNS publication details
	to <xref/>. See	to <xref/>. See

	<xref/> for specifics about how ECH configurations	<xref/> for specifics about how ECH configurations
	are advertised in SVCB and HTTPS records. Other delivery mechanisms are	are advertised in SVCB and HTTPS records. Other delivery mechanisms are
	also possible. For example, the client may have the ECH configuration	also possible. For example, the client may have the ECH configuration
	preconfigured.</t>	preconfigured.</t>
	<t>When a client wants to establish a TLS session with some backend server, it	<t>When a client wants to establish a TLS session with some backend server, it

	constructs a privateClientHello, referred to as theClientHelloInner.	constructs a private<tt>ClientHello</tt>, referred to as the<tt>ClientHelloInn
	The client then constructs a publicClientHello, referred to as the	er</tt>.
	ClientHelloOuter. TheClientHelloOuter contains innocuousvalues for	The client then constructs a public<tt>ClientHello</tt>, referred to as the
		<tt>ClientHelloOuter</tt>. The<tt>ClientHelloOuter</tt> contains innocuousvalu
		es for
	sensitive extensions and an "encrypted_client_hello" extension	sensitive extensions and an "encrypted_client_hello" extension

	(<xref/>), which carries the encryptedClientHel	(<xref/>), which carries the encrypted<tt>Clien
	loInner.	tHelloInner</tt>.
	Finally, the client sendsClientHelloOuter to the server.</t>	Finally, the client sends<tt>ClientHelloOuter</tt> to the server.</t>
	<t>The server takes one of the following actions:</t>	<t>The server takes one of the following actions:</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>
	<t>If it does not support ECH or cannot decrypt the extension, it completes	<t>If it does not support ECH or cannot decrypt the extension, it completes

	the handshake withClientHelloOuter. This is referred to as rejecting ECH.</t>	the handshake with<tt>ClientHelloOuter</tt>. This is referred to as rejecting ECH.</t>
	</li>	</li>
	<li>	<li>

	<t>If it successfully decrypts the extension, it forwards theClientHelloInner	<t>If it successfully decrypts the extension, it forwards the<tt>ClientHelloInner</tt>
	to the backend server, which completes the handshake. This is referred to	to the backend server, which completes the handshake. This is referred to
	as accepting ECH.</t>	as accepting ECH.</t>
	</li>	</li>
	</ol>	</ol>
	<t>Upon receiving the server's response, the client determines whether or not ECH	<t>Upon receiving the server's response, the client determines whether or not ECH
	was accepted (<xref/>) and proceeds with the handshake	was accepted (<xref/>) and proceeds with the handshake
	accordingly. When ECH is rejected, the resulting connection is not usable by	accordingly. When ECH is rejected, the resulting connection is not usable by
	the client for application data. Instead, ECH rejection allows the client to	the client for application data. Instead, ECH rejection allows the client to
	retry with up-to-date configuration (<xref/>).</t>	retry with up-to-date configuration (<xref/>).</t>
	<t>The primary goal of ECH is to ensure that connections to servers in the same	<t>The primary goal of ECH is to ensure that connections to servers in the same
	anonymity set are indistinguishable from one another. Moreover, it should	anonymity set are indistinguishable from one another. Moreover, it should
	achieve this goal without affecting any existing security properties of TLS 1.3.	achieve this goal without affecting any existing security properties of TLS 1.3.
	See <xref/> for more details about the ECH security and privacy goals.</t>	See <xref/> for more details about the ECH security and privacy goals.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="ech-configuration">	<section anchor="ech-configuration">
	<name>Encrypted ClientHello Configuration</name>	<name>Encrypted ClientHello Configuration</name>

	<t>ECH uses HPKE for public key encryption <xref/>.	<t>ECH uses Hybrid Public Key Encryption (HPKE) for public key encryption <xref/>.
	The ECH configuration is defined by the following <tt>ECHConfig</tt> structure.</t>	The ECH configuration is defined by the following <tt>ECHConfig</tt> structure.</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	opaque HpkePublicKey<1..2^16-1>;	opaque HpkePublicKey<1..2^16-1>;

	uint16 HpkeKemId; // Defined inRFC9180	uint16 HpkeKemId; // Defined inRFC 9180
	uint16 HpkeKdfId; // Defined inRFC9180	uint16 HpkeKdfId; // Defined inRFC 9180
	uint16 HpkeAeadId; // Defined inRFC9180	uint16 HpkeAeadId; // Defined inRFC 9180
	uint16 ECHConfigExtensionType; // Defined in Section 11.3	uint16 ECHConfigExtensionType; // Defined in Section 11.3

	struct {	struct {
	HpkeKdfId kdf_id;	HpkeKdfId kdf_id;
	HpkeAeadId aead_id;	HpkeAeadId aead_id;
	} HpkeSymmetricCipherSuite;	} HpkeSymmetricCipherSuite;

	struct {	struct {
	uint8 config_id;	uint8 config_id;
	HpkeKemId kem_id;	HpkeKemId kem_id;

	skipping to change at line 241 ¶	skipping to change at line 261 ¶
	struct {	struct {
	uint16 version;	uint16 version;
	uint16 length;	uint16 length;
	select (ECHConfig.version) {	select (ECHConfig.version) {
	case 0xfe0d: ECHConfigContents contents;	case 0xfe0d: ECHConfigContents contents;
	}	}
	} ECHConfig;	} ECHConfig;
	]]></artwork>	]]></artwork>
	<t>The structure contains the following fields:</t>	<t>The structure contains the following fields:</t>
	<dl>	<dl>

	<dt>version</dt>	<dt>version:</dt>
	<dd>	<dd>
	<t>The version of ECH for which this configuration is used. The version	<t>The version of ECH for which this configuration is used. The version
	is the same as the code point for the	is the same as the code point for the
	"encrypted_client_hello" extension. Clients MUST ignore any <tt>ECHConfig</tt>	"encrypted_client_hello" extension. Clients MUST ignore any <tt>ECHConfig</tt>
	structure with a version they do not support.</t>	structure with a version they do not support.</t>
	</dd>	</dd>

	<dt>length</dt>	<dt>length:</dt>
	<dd>	<dd>
	<t>The length, in bytes, of the next field. This length field allows	<t>The length, in bytes, of the next field. This length field allows
	implementations to skip over the elements in such a list where they cannot	implementations to skip over the elements in such a list where they cannot

	parse the specific version ofECHConfig.</t>	parse the specific version of<tt>ECHConfig</tt>.</t>
	</dd>	</dd>

	<dt>contents</dt>	<dt>contents:</dt>
	<dd>	<dd>
	<t>An opaque byte string whose contents depend on the version. For this	<t>An opaque byte string whose contents depend on the version. For this
	specification, the contents are an <tt>ECHConfigContents</tt> structure.</t>	specification, the contents are an <tt>ECHConfigContents</tt> structure.</t>
	</dd>	</dd>
	</dl>	</dl>
	<t>The <tt>ECHConfigContents</tt> structure contains the following fields:</t>	<t>The <tt>ECHConfigContents</tt> structure contains the following fields:</t>
	<dl>	<dl>

	<dt>key_config</dt>	<dt>key_config:</dt>
	<dd>	<dd>
	<t>A <tt>HpkeKeyConfig</tt> structure carrying the configuration information	<t>A <tt>HpkeKeyConfig</tt> structure carrying the configuration information
	associated with the HPKE public key (an "ECH key"). Note that this	associated with the HPKE public key (an "ECH key"). Note that this
	structure contains the <tt>config_id</tt> field, which applies to the entire	structure contains the <tt>config_id</tt> field, which applies to the entire

	ECHConfigContents.</t>	<tt>ECHConfigContents</tt>.</t>
	</dd>	</dd>

	<dt>maximum_name_length</dt>	<dt><tt>maximum_name_length</tt>:</dt>
	<dd>	<dd>
	<t>The longest name of a backend server, if known. If not known, this value can	<t>The longest name of a backend server, if known. If not known, this value can
	be set to zero. It is used to compute padding (<xref/>) and does not	be set to zero. It is used to compute padding (<xref/>) and does not
	constrain server name lengths. Names may exceed this length if, e.g.,	constrain server name lengths. Names may exceed this length if, e.g.,
	the server uses wildcard names or added new names to the anonymity set.</t>	the server uses wildcard names or added new names to the anonymity set.</t>
	</dd>	</dd>

	<dt>public_name</dt>	<dt>public_name:</dt>
	<dd>	<dd>
	<t>The DNS name of the client-facing server, i.e., the entity trusted	<t>The DNS name of the client-facing server, i.e., the entity trusted
	to update the ECH configuration. This is used to correct misconfigured clients,	to update the ECH configuration. This is used to correct misconfigured clients,
	as described in <xref/>.</t>	as described in <xref/>.</t>
	</dd>	</dd>
	<dt/>	<dt/>
	<dd>	<dd>
	<t>See <xref/> for how the client interprets and validates the	<t>See <xref/> for how the client interprets and validates the
	public_name.</t>	public_name.</t>
	</dd>	</dd>

	<dt>extensions</dt>	<dt>extensions:</dt>
	<dd>	<dd>
	<t>A list of ECHConfigExtension values that the client must take into	<t>A list of ECHConfigExtension values that the client must take into

	consideration when generating aClientHello message. Each ECHConfigExtension	consideration when generating a<tt>ClientHello</tt> message. Each ECHConfigExtension
	has a 2-octet type and opaque data value, where the data value is encoded	has a 2-octet type and opaque data value, where the data value is encoded
	with a 2-octet integer representing the length of the data, in network byte	with a 2-octet integer representing the length of the data, in network byte
	order. ECHConfigExtension values are described below (<xref/>).</t>	order. ECHConfigExtension values are described below (<xref/>).</t>
	</dd>	</dd>
	</dl>	</dl>
	<t>The <tt>HpkeKeyConfig</tt> structure contains the following fields:</t>	<t>The <tt>HpkeKeyConfig</tt> structure contains the following fields:</t>
	<dl>	<dl>

	<dt>config_id</dt>	<dt><tt>config_id</tt>:</dt>
	<dd>	<dd>
	<t>A one-byte identifier for the given HPKE key configuration. This is used by	<t>A one-byte identifier for the given HPKE key configuration. This is used by

	clients to indicate the key used forClientHello encryption. <xref/>	clients to indicate the key used for<tt>ClientHello</tt> encryption. <xref target="config-ids"/>
	describes how client-facing servers allocate this value.</t>	describes how client-facing servers allocate this value.</t>
	</dd>	</dd>

	<dt>kem_id</dt>	<dt>kem_id:</dt>
	<dd>	<dd>
	<t>The HPKE Key Encapsulation Mechanism (KEM) identifier corresponding	<t>The HPKE Key Encapsulation Mechanism (KEM) identifier corresponding
	to <tt>public_key</tt>. Clients MUST ignore any <tt>ECHConfig</tt> structure with a	to <tt>public_key</tt>. Clients MUST ignore any <tt>ECHConfig</tt> structure with a
	key using a KEM they do not support.</t>	key using a KEM they do not support.</t>
	</dd>	</dd>

	<dt>public_key</dt>	<dt><tt>public_key</tt>:</dt>
	<dd>	<dd>

	<t>The HPKE public key used by the client to encryptClientHelloInner.</t>	<t>The HPKE public key used by the client to encrypt<tt>ClientHelloInner</tt>.</t>
	</dd>	</dd>

	<dt>cipher_suites</dt>	<dt>cipher_suites:</dt>
	<dd>	<dd>

	<t>The list of HPKEKDF andAEAD identifier pairs clients can use for	<t>The list of HPKEKey Derivation Function (KDF) andAuthenticated En
	encrypting	cryption with Associated Data (AEAD) identifier pairs clients can use forencryp
	ClientHelloInner. See <xref/> for how clients choose from this	ting
	list.</t>	<tt>ClientHelloInner</tt>. See <xref/> for how clients choose
		from this list.</t>
	</dd>	</dd>
	</dl>	</dl>
	<t>The client-facing server advertises a sequence of ECH configurations to clients,	<t>The client-facing server advertises a sequence of ECH configurations to clients,
	serialized as follows.</t>	serialized as follows.</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	ECHConfig ECHConfigList<4..2^16-1>;	ECHConfig ECHConfigList<4..2^16-1>;
	]]></artwork>	]]></artwork>
	<t>The <tt>ECHConfigList</tt> structure contains one or more <tt>ECHConfig</tt> structures in	<t>The <tt>ECHConfigList</tt> structure contains one or more <tt>ECHConfig</tt> structures in
	decreasing order of preference. This allows a server to support multiple	decreasing order of preference. This allows a server to support multiple
	versions of ECH and multiple sets of ECH parameters.</t>	versions of ECH and multiple sets of ECH parameters.</t>
	<section anchor="config-ids">	<section anchor="config-ids">
	<name>Configuration Identifiers</name>	<name>Configuration Identifiers</name>

	<t>A client-facing server has a set of knownECHConfig values, with corresponding	<t>A client-facing server has a set of known<tt>ECHConfig</tt> values with corresponding
	private keys. This set SHOULD contain the currently published values, as well as	private keys. This set SHOULD contain the currently published values, as well as
	previous values that may still be in use, since clients may cache DNS records	previous values that may still be in use, since clients may cache DNS records
	up to a TTL or longer.</t>	up to a TTL or longer.</t>
	<t><xref/> describes a trial decryption process for decrypting the	<t><xref/> describes a trial decryption process for decrypting the

	ClientHello. This can impact performance when the client-facing server maintains	<tt>ClientHello</tt>. This can impact performance when the client-facing server
	many knownECHConfig values. To avoid this, the client-facing serverSHOULD	maintains
	allocate distinct <tt>config_id</tt> values for eachECHConfig in itsknown set.	many known<tt>ECHConfig</tt> values. To avoid this, the client-facing serverSH
	The	OULD
		allocate distinct <tt>config_id</tt> values for each<tt>ECHConfig</tt> in itsk
		nown set. The
	RECOMMENDED strategy is via rejection sampling, i.e., to randomly select	RECOMMENDED strategy is via rejection sampling, i.e., to randomly select

	<tt>config_id</tt> repeatedly until it does not match any knownECHConfig.</t>	<tt>config_id</tt> repeatedly until it does not match any known<tt>ECHConfig</tt>.</t>
	<t>It is not necessary for <tt>config_id</tt> values across different client-facing	<t>It is not necessary for <tt>config_id</tt> values across different client-facing
	servers to be distinct. A backend server may be hosted behind two different	servers to be distinct. A backend server may be hosted behind two different
	client-facing servers with colliding <tt>config_id</tt> values without any performance	client-facing servers with colliding <tt>config_id</tt> values without any performance

	impact. Values may also be reused if the previousECHConfig is no longer in the	impact. Values may also be reused if the previous<tt>ECHConfig</tt> is no longer in the
	known set.</t>	known set.</t>
	</section>	</section>
	<section anchor="config-extensions">	<section anchor="config-extensions">
	<name>Configuration Extensions</name>	<name>Configuration Extensions</name>
	<t>ECH configuration extensions are used to provide room for additional	<t>ECH configuration extensions are used to provide room for additional
	functionality as needed. The format is as defined in	functionality as needed. The format is as defined in
	<xref/> and mirrors <xref section="4.2" sectionFormat="of"/>. However,	<xref/> and mirrors <xref section="4.2" sectionFormat="of"/>. However,
	ECH configuration extension types are maintained by IANA as described	ECH configuration extension types are maintained by IANA as described
	in <xref/>. ECH configuration extensions follow	in <xref/>. ECH configuration extensions follow
	the same interpretation rules as TLS extensions: extensions MAY appear	the same interpretation rules as TLS extensions: extensions MAY appear
	in any order, but there MUST NOT be more than one extension of the	in any order, but there MUST NOT be more than one extension of the
	same type in the extensions block. Unlike TLS extensions, an extension	same type in the extensions block. Unlike TLS extensions, an extension
	can be tagged as mandatory by using an extension type codepoint with	can be tagged as mandatory by using an extension type codepoint with
	the high order bit set to 1.</t>	the high order bit set to 1.</t>
	<t>Clients MUST parse the extension list and check for unsupported mandatory	<t>Clients MUST parse the extension list and check for unsupported mandatory
	extensions. If an unsupported mandatory extension is present, clients MUST	extensions. If an unsupported mandatory extension is present, clients MUST
	ignore the <tt>ECHConfig</tt>.</t>	ignore the <tt>ECHConfig</tt>.</t>

	<t>Any future information or hints that influenceClientHelloOuter SHOUL	<t>Any future information or hints that influence<tt>ClientHelloOuter</
	D be	tt> SHOULD be
	specified asECHConfig extensions. This is primarily because the outer	specified as<tt>ECHConfig</tt> extensions. This is primarily because the outer
	ClientHello exists only in support of ECH. Namely, it is both anenvelope for	<tt>ClientHello</tt> exists only in support of ECH. Namely, it is both anenvelo
	the encrypted innerClientHello and enabler for authenticated keymismatch	pe for
	signals (see <xref/>). In contrast, the innerClientHel	the encrypted inner<tt>ClientHello</tt> andan enabler for authenticated keymi
	lo is the	smatch
	trueClientHello used upon ECH negotiation.</t>	signals (see <xref/>). In contrast, the inner<tt>Clien
		tHello</tt> is the
		true<tt>ClientHello</tt> used upon ECH negotiation.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="encrypted-client-hello">	<section anchor="encrypted-client-hello">
	<name>The "encrypted_client_hello" Extension</name>	<name>The "encrypted_client_hello" Extension</name>
	<t>To offer ECH, the client sends an "encrypted_client_hello" extension in the	<t>To offer ECH, the client sends an "encrypted_client_hello" extension in the

	ClientHelloOuter. When it does, it MUST also send the extension in	<tt>ClientHelloOuter</tt>. When it does, it MUST also send the extension in
	ClientHelloInner.</t>	<tt>ClientHelloInner</tt>.</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	enum {	enum {
	encrypted_client_hello(0xfe0d), (65535)	encrypted_client_hello(0xfe0d), (65535)
	} ExtensionType;	} ExtensionType;
	]]></artwork>	]]></artwork>
	<t>The payload of the extension has the following structure:</t>	<t>The payload of the extension has the following structure:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	enum { outer(0), inner(1) } ECHClientHelloType;	enum { outer(0), inner(1) } ECHClientHelloType;

	struct {	struct {

	skipping to change at line 399 ¶	skipping to change at line 419 ¶
	opaque enc<0..2^16-1>;	opaque enc<0..2^16-1>;
	opaque payload<1..2^16-1>;	opaque payload<1..2^16-1>;
	case inner:	case inner:
	Empty;	Empty;
	};	};
	} ECHClientHello;	} ECHClientHello;
	]]></artwork>	]]></artwork>
	<t>The outer extension uses the <tt>outer</tt> variant and the inner extension uses the	<t>The outer extension uses the <tt>outer</tt> variant and the inner extension uses the
	<tt>inner</tt> variant. The inner extension has an empty payload, which is included	<tt>inner</tt> variant. The inner extension has an empty payload, which is included
	because TLS servers are not allowed to provide extensions in ServerHello	because TLS servers are not allowed to provide extensions in ServerHello

	which were not included inClientHello. The outer extension has the following	which were not included in<tt>ClientHello</tt>. The outer extension has the following
	fields:</t>	fields:</t>
	<dl>	<dl>

	<dt>config_id</dt>	<dt><tt>config_id</tt>:</dt>
	<dd>	<dd>

	<t>TheECHConfigContents.key_config.config_id for the chosen ECHConfig.</t>	<t>The<tt>ECHConfigContents.key_config.config_id</tt> for the chosen <tt>ECHConfig</tt>.</t>
	</dd>	</dd>

	<dt>cipher_suite</dt>	<dt><tt>cipher_suite</tt>:</dt>
	<dd>	<dd>

	<t>The cipher suite used to encryptClientHelloInner. ThisMUST match	<t>The cipher suite used to encrypt<tt>ClientHelloInner</tt>. ThisMU
	a value	ST match a value
	provided in the corresponding<tt>ECHConfigContents.cipher_suites</tt> list.</t>	provided in the corresponding<tt>ECHConfigContents.key_config.cipher_suites</tt
		> list.</t>
	</dd>	</dd>

	<dt>enc</dt>	<dt>enc:</dt>
	<dd>	<dd>

	<t>The HPKE encapsulatedkey, used by servers to decrypt thecorrespon	<t>The HPKE encapsulatedkey used by servers to decrypt thecorrespond
	ding	ing
	<tt>payload</tt> field. This field is empty in aClientHelloOuter sent inrespon	<tt>payload</tt> field. This field is empty in a<tt>ClientHelloOuter</tt> sent
	se to	inresponse to
	HelloRetryRequest.</t>	HelloRetryRequest.</t>
	</dd>	</dd>

	<dt>payload</dt>	<dt>payload:</dt>
	<dd>	<dd>

	<t>The serialized and encryptedEncodedClientHelloInner structure, encrypted	<t>The serialized and encrypted<tt>EncodedClientHelloInner</tt> structure, encrypted
	using HPKE as described in <xref/>.</t>	using HPKE as described in <xref/>.</t>
	</dd>	</dd>
	</dl>	</dl>
	<t>When a client offers the <tt>outer</tt> version of an "encrypted_client_hello"	<t>When a client offers the <tt>outer</tt> version of an "encrypted_client_hello"
	extension, the server MAY include an "encrypted_client_hello" extension in its	extension, the server MAY include an "encrypted_client_hello" extension in its
	EncryptedExtensions message, as described in <xref/>, with the	EncryptedExtensions message, as described in <xref/>, with the
	following payload:</t>	following payload:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	struct {	struct {
	ECHConfigList retry_configs;	ECHConfigList retry_configs;
	} ECHEncryptedExtensions;	} ECHEncryptedExtensions;
	]]></artwork>	]]></artwork>

	<t>The response is valid only when the server used theClientHelloOuter. If the	<t>The response is valid only when the server used the<tt>ClientHelloOuter</tt>. If the
	server sent this extension in response to the <tt>inner</tt> variant, then the client	server sent this extension in response to the <tt>inner</tt> variant, then the client
	MUST abort with an "unsupported_extension" alert.</t>	MUST abort with an "unsupported_extension" alert.</t>
	<dl>	<dl>

	<dt>retry_configs</dt>	<dt>retry_configs:</dt>
	<dd>	<dd>

	<t>AnECHConfigList structure containing one or more ECHConfig structures, in	<t>An<tt>ECHConfigList</tt> structure containing one or more <tt>ECHConfig</tt> structures, in
	decreasing order of preference, to be used by the client as described in	decreasing order of preference, to be used by the client as described in
	<xref/>. These are known as the server's "retry configurations".</t>	<xref/>. These are known as the server's "retry configurations".</t>
	</dd>	</dd>
	</dl>	</dl>
	<t>Finally, when the client offers the "encrypted_client_hello", if the payload is	<t>Finally, when the client offers the "encrypted_client_hello", if the payload is
	the <tt>inner</tt> variant and the server responds with HelloRetryRequest, it MUST	the <tt>inner</tt> variant and the server responds with HelloRetryRequest, it MUST
	include an "encrypted_client_hello" extension with the following payload:</t>	include an "encrypted_client_hello" extension with the following payload:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	struct {	struct {
	opaque confirmation[8];	opaque confirmation[8];
	} ECHHelloRetryRequest;	} ECHHelloRetryRequest;
	]]></artwork>	]]></artwork>
	<t>The value of ECHHelloRetryRequest.confirmation is set to	<t>The value of ECHHelloRetryRequest.confirmation is set to
	<tt>hrr_accept_confirmation</tt> as described in <xref/>.</t>	<tt>hrr_accept_confirmation</tt> as described in <xref/>.</t>
	<t>This document also defines the "ech_required" alert, which the client MUST send	<t>This document also defines the "ech_required" alert, which the client MUST send
	when it offered an "encrypted_client_hello" extension that was not accepted by	when it offered an "encrypted_client_hello" extension that was not accepted by
	the server. (See <xref/>.)</t>	the server. (See <xref/>.)</t>
	<section anchor="encoding-inner">	<section anchor="encoding-inner">
	<name>Encoding the ClientHelloInner</name>	<name>Encoding the ClientHelloInner</name>

	<t>Before encrypting, the client pads and optionally compressesClientHe	<t>Before encrypting, the client pads and optionally compresses<tt>Clie
	lloInner	ntHelloInner</tt>
	intoa EncodedClientHelloInner structure, defined below:</t>	intoan <tt>EncodedClientHelloInner</tt> structure, defined below:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	struct {	struct {
	ClientHello client_hello;	ClientHello client_hello;
	uint8 zeros[length_of_padding];	uint8 zeros[length_of_padding];
	} EncodedClientHelloInner;	} EncodedClientHelloInner;
	]]></artwork>	]]></artwork>

	<t>The <tt>client_hello</tt> field is computed by first making a copy ofClientHelloInner	<t>The <tt>client_hello</tt> field is computed by first making a copy of<tt>ClientHelloInner</tt>
	and setting the <tt>legacy_session_id</tt> field to the empty string. In TLS, this	and setting the <tt>legacy_session_id</tt> field to the empty string. In TLS, this

	field uses theClientHello structure defined in <xref section="4.1.2"sectionFor	field uses the<tt>ClientHello</tt> structure defined in <xref section="4.1.2"s
	mat="of"/>.	ectionFormat="of"/>.
	In DTLS, it uses theClientHello structured defined in	In DTLS, it uses the<tt>ClientHello</tt> structure defined in
	<xref section="5.3" sectionFormat="of"/>. This does not include	<xref section="5.3" sectionFormat="of"/>. This does not include
	Handshake structure's	the Handshake structure's
	four-byte header in TLS, nor twelve-byte header in DTLS. The <tt>zeros</tt>fiel	four-byte header in TLS, northe twelve-byte header in DTLS. The <tt>zeros</tt>
	d MUST	field MUST
	be allzeroes of length <tt>length_of_padding</tt> (see <xreftarget="padding"/>	be allzeros of length <tt>length_of_padding</tt> (see <xreftarget="padding"/>)
	).</t>	.</t>
	<t>Repeating large extensions, such as "key_share" with post-quantum algorithms,	<t>Repeating large extensions, such as "key_share" with post-quantum algorithms,

	betweenClientHelloInner and ClientHelloOuter can lead to excessive size. To	between<tt>ClientHelloInner</tt> and <tt>ClientHelloOuter</tt> can lead to excessive size. To
	reduce the size impact, the client MAY substitute extensions which it knows	reduce the size impact, the client MAY substitute extensions which it knows

	will be duplicated inClientHelloOuter. It does so by removing andreplacing	will be duplicated in<tt>ClientHelloOuter</tt>. It does so by removing andrepl
	extensions fromEncodedClientHelloInner with a single"ech_outer_extensions"	acing
		extensions from<tt>EncodedClientHelloInner</tt> with a single"ech_outer_extens
		ions"
	extension, defined as follows:</t>	extension, defined as follows:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	enum {	enum {
	ech_outer_extensions(0xfd00), (65535)	ech_outer_extensions(0xfd00), (65535)
	} ExtensionType;	} ExtensionType;

	ExtensionType OuterExtensions<2..254>;	ExtensionType OuterExtensions<2..254>;
	]]></artwork>	]]></artwork>

	<t>OuterExtensions contains the removed ExtensionType values. Each value	<t>OuterExtensions containsa list of the removed ExtensionType values.
	references	Each value references
	the matching extension inClientHelloOuter. The values MUST be ordered	the matching extension in<tt>ClientHelloOuter</tt>. The values MUST be ordered
	contiguously inClientHelloInner, and the "ech_outer_extensions"extension MUST	contiguously in<tt>ClientHelloInner</tt>, and the "ech_outer_extensions"extens
	be inserted in the corresponding position inEncodedClientHelloInner.	ion MUST
	Additionally, the extensions MUST appear inClientHelloOuter in thesame	be inserted in the corresponding position in<tt>EncodedClientHelloInner</tt>.
		Additionally, the extensions MUST appear in<tt>ClientHelloOuter</tt> in thesam
		e
	relative order. However, there is no requirement that they be contiguous. For	relative order. However, there is no requirement that they be contiguous. For

	example, OuterExtensions may contain extensions A, B, C, whileClientHelloOuter	example, OuterExtensions may contain extensions A, B,and C, while<tt>ClientHel
	contains extensions A, D, B, C, E, F.</t>	loOuter</tt>
		contains extensions A, D, B, C, E,and F.</t>
	<t>The "ech_outer_extensions" extension can only be included in	<t>The "ech_outer_extensions" extension can only be included in

	EncodedClientHelloInner, and MUST NOT appear in eitherClientHelloOuter or	<tt>EncodedClientHelloInner</tt> and MUST NOT appear in either<tt>ClientHelloOu
	ClientHelloInner.</t>	ter</tt> or
		<tt>ClientHelloInner</tt>.</t>
	<t>Finally, the client pads the message by setting the <tt>zeros</tt> field to a byte	<t>Finally, the client pads the message by setting the <tt>zeros</tt> field to a byte
	string whose contents are all zeros and whose length is the amount of padding	string whose contents are all zeros and whose length is the amount of padding
	to add. <xref/> describes a recommended padding scheme.</t>	to add. <xref/> describes a recommended padding scheme.</t>

	<t>The client-facing server computesClientHelloInner byreversing this	<t>The client-facing server computes<tt>ClientHelloInner</tt> byrevers
	process.	ing this process.
	First it parsesEncodedClientHelloInner, interpreting all bytes after	First, it parses<tt>EncodedClientHelloInner</tt>, interpreting all bytes after
	<tt>client_hello</tt> as padding. If any padding byte is non-zero, the server MUST	<tt>client_hello</tt> as padding. If any padding byte is non-zero, the server MUST
	abort the connection with an "illegal_parameter" alert.</t>	abort the connection with an "illegal_parameter" alert.</t>

	<t>Next it makes a copy of the <tt>client_hello</tt> field and copiesth	<t>Next, it makes a copy of the <tt>client_hello</tt> field and copiest
	e	he
	<tt>legacy_session_id</tt> field fromClientHelloOuter. It then looksfor an	<tt>legacy_session_id</tt> field from<tt>ClientHelloOuter</tt>. It then looksf
		or an
	"ech_outer_extensions" extension. If found, it replaces the extension with the	"ech_outer_extensions" extension. If found, it replaces the extension with the

	corresponding sequence of extensions in theClientHelloOuter. The server MUST	corresponding sequence of extensions in the<tt>ClientHelloOuter</tt>. The server MUST
	abort the connection with an "illegal_parameter" alert if any of the following	abort the connection with an "illegal_parameter" alert if any of the following
	are true:</t>	are true:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>Any referenced extension is missing inClientHelloOuter.</t>	<t>Any referenced extension is missing in<tt>ClientHelloOuter</tt>.</t>
	</li>	</li>
	<li>	<li>
	<t>Any extension is referenced in OuterExtensions more than once.</t>	<t>Any extension is referenced in OuterExtensions more than once.</t>
	</li>	</li>
	<li>	<li>
	<t>"encrypted_client_hello" is referenced in OuterExtensions.</t>	<t>"encrypted_client_hello" is referenced in OuterExtensions.</t>
	</li>	</li>
	<li>	<li>

	<t>The extensions inClientHelloOuter corresponding to those in OuterExtensions	<t>The extensions in<tt>ClientHelloOuter</tt> corresponding to those in OuterExtensions
	do not occur in the same order.</t>	do not occur in the same order.</t>
	</li>	</li>
	</ul>	</ul>
	<t>These requirements prevent an attacker from performing a packet amplification	<t>These requirements prevent an attacker from performing a packet amplification

	attack, by crafting aClientHelloOuter which decompresses to a muchlarger	attack by crafting a<tt>ClientHelloOuter</tt> which decompresses to a muchlarg
	ClientHelloInner. This is discussed further in <xreftarget="decompression-amp"/	er
	>.</t>	<tt>ClientHelloInner</tt>. This is discussed further in <xreftarget="decompress
	<t>Implementations SHOULD construct theClientHelloInner in linear	ion-amp"/>.</t>
		<t>Receiving implementations SHOULD construct the<tt>ClientHelloInner</
		tt> in linear
	time. Quadratic time implementations (such as may happen via naive	time. Quadratic time implementations (such as may happen via naive

	copying) create a denial ofservice risk.	copying) create a denial-of-service risk.
	<xref/> describes a linear-time procedure that may be used	<xref/> describes a linear-time procedure that may be used
	for this purpose.</t>	for this purpose.</t>
	</section>	</section>
	<section anchor="authenticating-outer">	<section anchor="authenticating-outer">
	<name>Authenticating the ClientHelloOuter</name>	<name>Authenticating the ClientHelloOuter</name>
	<t>To prevent a network attacker from modifying the <tt>ClientHelloOuter</tt>	<t>To prevent a network attacker from modifying the <tt>ClientHelloOuter</tt>
	while keeping the same encrypted <tt>ClientHelloInner</tt>	while keeping the same encrypted <tt>ClientHelloInner</tt>

	(see <xref/>), ECH authenticatesClientHe	(see <xref/>), ECH authenticates<tt>Clie
	lloOuter	ntHelloOuter</tt>
	by passingClientHelloOuterAAD as the associated data for HPKE sealing	by passing<tt>ClientHelloOuterAAD</tt> as the associated data for HPKE sealing
	and opening operations. TheClientHelloOuterAAD is a serialized	and opening operations. The<tt>ClientHelloOuterAAD</tt> is a serialized
	ClientHello structure, defined in <xref section="4.1.2"sectionFormat="of" targe	<tt>ClientHello</tt> structure, defined in <xref section="4.1.2"sectionFormat="
	t="RFC8446"/> for TLS and	of"/> for TLS and
	<xref section="5.3" sectionFormat="of"/> for DTLS, which matche	<xref section="5.3" sectionFormat="of"/> for DTLS, which matche
	s theClientHelloOuter except	s the<tt>ClientHelloOuter</tt> except
	that the <tt>payload</tt> field of the "encrypted_client_hello" is replaced with a byte	that the <tt>payload</tt> field of the "encrypted_client_hello" is replaced with a byte
	string of the same length but whose contents are zeros. This value does not	string of the same length but whose contents are zeros. This value does not

	includeHandshake structure's four-byte header in TLS nor twelve-byte header in	includethe Handshake structure's four-byte header in TLS nor the twelve-byte header in
	DTLS.</t>	DTLS.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="client-behavior">	<section anchor="client-behavior">
	<name>Client Behavior</name>	<name>Client Behavior</name>
	<t>Clients that implement the ECH extension behave in one of two ways: either they	<t>Clients that implement the ECH extension behave in one of two ways: either they

	offer a real ECH extension, as described in <xref/>; or they send a	offer a real ECH extension, as described in <xref/>, or they send a
	Generate Random Extensions And Sustain Extensibility (GREASE) <xref/>	Generate Random Extensions And Sustain Extensibility (GREASE) <xref/>

	ECH extension, as described in <xref/>. Clients of thelatte	ECH extension, as described in <xref/>.
	r type do not	The client offers ECH if it is in possession of a compatible ECH configuration a
	negotiateECH. Instead, they generate a dummy ECH extension that is ignored by	nd sends GREASE ECH
	the server. (See <xref/> for an explanation.)The client	(see <xref/>) otherwise.
	offers ECH	Clients of thelatter type do not
	if it isin possession of a compatible ECH configuration and sends GREASE ECH	negotiateECH; instead, they generate a dummy ECH extension that is ignored by
	(see <xref/>) otherwise.</t>	the server. (See <xref/> for an explanation.)It isals
		o possible for clients to always
		send GREASE ECHwithout implementing the remainder of this specification.</t>
	<section anchor="real-ech">	<section anchor="real-ech">
	<name>Offering ECH</name>	<name>Offering ECH</name>

	<t>To offer ECH, the client first chooses a suitableECHConfig from the	<t>To offer ECH, the client first chooses a suitable<tt>ECHConfig</tt>
	server's	from the server's
	ECHConfigList. To determine if a given <tt>ECHConfig</tt> is suitable, it checks	<tt>ECHConfigList</tt>. To determine if a given <tt>ECHConfig</tt> is suitable,
	that	it checks that
	it supports the KEM algorithm identified by<tt>ECHConfig.contents.kem_id</tt>,	it supports the KEM algorithm identified by
	at	<tt>ECHConfig.contents.key_config.kem_id</tt>, at least one KDF/AEAD algorithm
	least one KDF/AEAD algorithm identified by<tt>ECHConfig.contents.cipher_suites<	identified by<tt>ECHConfig.contents.key_config.cipher_suites</tt>, and thevers
	/tt>,	ion of
	and theversion of ECH indicated by<tt>ECHConfig.contents.version</tt>. Once a	ECH indicated by<tt>ECHConfig.version</tt>. Once a suitable configuration isfo
	suitable configuration isfound, the client selects the cipher suite it will	und,
	use for encryption. It MUST NOT choose a cipher suite or version not advertised	the client selects the cipher suite it will use for encryption. It MUST NOT
	by the configuration. If no compatible configuration is found, then the client	choose a cipher suite or version not advertised by the configuration. If no
	SHOULD proceed as described in <xref/>.</t>	compatible configuration is found, then the client SHOULD proceed as described
	<t>Next, the client constructs theClientHelloInner messagejust as itd	in <xref/>.</t>
	oes a	<t>Next, the client constructs the<tt>ClientHelloInner</tt> messagejus
	standardClientHello, with the exception of the following rules:</t>	t as itdoes a
		standard<tt>ClientHello</tt>, with the exception of the following rules:</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>
	<t>It MUST NOT offer to negotiate TLS 1.2 or below. This is necessary to ensure	<t>It MUST NOT offer to negotiate TLS 1.2 or below. This is necessary to ensure
	the backend server does not negotiate a TLS version that is incompatible with	the backend server does not negotiate a TLS version that is incompatible with
	ECH.</t>	ECH.</t>
	</li>	</li>
	<li>	<li>
	<t>It MUST NOT offer to resume any session for TLS 1.2 and below.</t>	<t>It MUST NOT offer to resume any session for TLS 1.2 and below.</t>
	</li>	</li>
	<li>	<li>
	<t>If it intends to compress any extensions (see <xref/>), it MUST	<t>If it intends to compress any extensions (see <xref/>), it MUST
	order those extensions consecutively.</t>	order those extensions consecutively.</t>
	</li>	</li>
	<li>	<li>
	<t>It MUST include the "encrypted_client_hello" extension of type <tt>inner</tt> as	<t>It MUST include the "encrypted_client_hello" extension of type <tt>inner</tt> as
	described in <xref/>. (This requirement is not applicable	described in <xref/>. (This requirement is not applicable
	when the "encrypted_client_hello" extension is generated as described in	when the "encrypted_client_hello" extension is generated as described in
	<xref/>.)</t>	<xref/>.)</t>
	</li>	</li>
	</ol>	</ol>

	<t>The client then constructsEncodedClientHelloInner as described in	<t>The client then constructs<tt>EncodedClientHelloInner</tt> as described in
	<xref/>. It also computes an HPKE encryption context and <tt>enc</tt> value	<xref/>. It also computes an HPKE encryption context and <tt>enc</tt> value
	as:</t>	as:</t>
	<artwork><![CDATA[	<artwork><![CDATA[

	pkR = DeserializePublicKey(ECHConfig.contents.public_key)	pkR = DeserializePublicKey(ECHConfig.contents.key_config.public_key)
	enc, context = SetupBaseS(pkR,	enc, context = SetupBaseS(pkR,
	"tls ech" \|\| 0x00 \|\| ECHConfig)	"tls ech" \|\| 0x00 \|\| ECHConfig)
	]]></artwork>	]]></artwork>

	<t>Next, it constructs a partialClientHelloOuterAAD as it does astanda	<t>Next, it constructs a partial<tt>ClientHelloOuterAAD</tt> as it does
	rd	astandard
	ClientHello, with the exception of the following rules:</t>	<tt>ClientHello</tt>, with the exception of the following rules:</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>
	<t>It MUST offer to negotiate TLS 1.3 or above.</t>	<t>It MUST offer to negotiate TLS 1.3 or above.</t>
	</li>	</li>
	<li>	<li>

	<t>If it compressed any extensions inEncodedClientHelloInner, itMU	<t>If it compressed any extensions in<tt>EncodedClientHelloInner</t
	ST copy the	t>, itMUST copy the
	corresponding extensions fromClientHelloInner. The copied extensions	corresponding extensions from<tt>ClientHelloInner</tt>. The copied extensions
	additionally MUST be in the same relative order as inClientHelloInner.</t>	additionally MUST be in the same relative order as in<tt>ClientHelloInner</tt>.
		</t>
	</li>	</li>
	<li>	<li>

	<t>It MUST copy the legacy_session_id field fromClientHelloInner. This	<t>It MUST copy the legacy_session_id field from<tt>ClientHelloInner</tt>. This
	allows the server to echo the correct session ID for TLS 1.3's compatibility	allows the server to echo the correct session ID for TLS 1.3's compatibility
	mode (see <xref section="D.4" sectionFormat="of"/>) when ECH is negotiated. Note that	mode (see <xref section="D.4" sectionFormat="of"/>) when ECH is negotiated. Note that
	compatibility mode is not used in DTLS 1.3, but following this rule will	compatibility mode is not used in DTLS 1.3, but following this rule will
	produce the correct results for both TLS 1.3 and DTLS 1.3.</t>	produce the correct results for both TLS 1.3 and DTLS 1.3.</t>
	</li>	</li>
	<li>	<li>

	<t>It MAY copy any other field from theClientHelloInner except	<t>It MAY copy any other field from the<tt>ClientHelloInner</tt> ex
	ClientHelloInner.random. Instead,It MUST generate a fresh	cept
	ClientHelloOuter.random using a secure random number generator. (See	<tt>ClientHelloInner.random</tt>. Instead,it MUST generate a fresh
		<tt>ClientHelloOuter.random</tt> using a secure random number generator. (See
	<xref/>.)</t>	<xref/>.)</t>
	</li>	</li>
	<li>	<li>
	<t>It SHOULD place the value of <tt>ECHConfig.contents.public_name</tt> in the	<t>It SHOULD place the value of <tt>ECHConfig.contents.public_name</tt> in the
	"server_name" extension. Clients that do not follow this step, or place a	"server_name" extension. Clients that do not follow this step, or place a
	different value in the "server_name" extension, risk breaking the retry	different value in the "server_name" extension, risk breaking the retry
	mechanism described in <xref/> or failing to interoperate with	mechanism described in <xref/> or failing to interoperate with
	servers that require this step to be done; see <xref/>.</t>	servers that require this step to be done; see <xref/>.</t>
	</li>	</li>
	<li>	<li>

	<t>When the client offers the "pre_shared_key" extension inClientHe	<t>When the client offers the "pre_shared_key" extension in<tt>Clie
	lloInner, it	ntHelloInner</tt>, it
	SHOULD also include a GREASE "pre_shared_key" extension inClientHelloOuter,	SHOULD also include a GREASE "pre_shared_key" extension in<tt>ClientHelloOuter<
		/tt>,
	generated in the manner described in <xref/>. The client MUST NOT use	generated in the manner described in <xref/>. The client MUST NOT use
	this extension to advertise a PSK to the client-facing server. (See	this extension to advertise a PSK to the client-facing server. (See
	<xref/>.) When the client includes a GREASE	<xref/>.) When the client includes a GREASE
	"pre_shared_key" extension, it MUST also copy the "psk_key_exchange_modes"	"pre_shared_key" extension, it MUST also copy the "psk_key_exchange_modes"

	from theClientHelloInner into the ClientHelloOuter.</t>	from the<tt>ClientHelloInner</tt> into the <tt>ClientHelloOuter</tt>.</t>
	</li>	</li>
	<li>	<li>

	<t>When the client offers the "early_data" extension inClientHelloI	<t>When the client offers the "early_data" extension in<tt>ClientHe
	nner, it	lloInner</tt>, it
	MUST also include the "early_data" extension inClientHelloOuter. This	MUST also include the "early_data" extension in<tt>ClientHelloOuter</tt>. This
	allows servers that reject ECH and useClientHelloOuter to safelyignore any	allows servers that reject ECH and use<tt>ClientHelloOuter</tt> to safelyignor
		e any
	early data sent by the client per <xref section="4.2.10" sectionFormat="comma" target="RFC8446"/>.</t>	early data sent by the client per <xref section="4.2.10" sectionFormat="comma" target="RFC8446"/>.</t>
	</li>	</li>
	</ol>	</ol>
	<t>The client might duplicate non-sensitive extensions in both messages. However,	<t>The client might duplicate non-sensitive extensions in both messages. However,
	implementations need to take care to ensure that sensitive extensions are not	implementations need to take care to ensure that sensitive extensions are not

	offered in theClientHelloOuter. See <xref/> for additional	offered in the<tt>ClientHelloOuter</tt>. See <xref/> for additional
	guidance.</t>	guidance.</t>

	<t>Finally, the client encrypts theEncodedClientHelloInner with theabo	<t>Finally, the client encrypts the<tt>EncodedClientHelloInner</tt> wit
	ve values,	h theabove values,
	as described in <xref/>, to construct aClientHe	as described in <xref/>, to construct a<tt>Clie
	lloOuter. It	ntHelloOuter</tt>. It
	sends this to theserver, and processes the response as described in	sends this to theserver and processes the response as described in
	<xref/>.</t>	<xref/>.</t>
	<section anchor="encrypting-clienthello">	<section anchor="encrypting-clienthello">
	<name>Encrypting the ClientHello</name>	<name>Encrypting the ClientHello</name>

	<t>Given anEncodedClientHelloInner, an HPKE encryptioncontext and<t	<t>Given an<tt>EncodedClientHelloInner</tt>, an HPKE encryptionconte
	t>enc</tt> value,	xt and<tt>enc</tt> value,
	and a partialClientHelloOuterAAD, the client constructs aClientHelloOuter as	and a partial<tt>ClientHelloOuterAAD</tt>, the client constructs a<tt>ClientHe
		lloOuter</tt> as
	follows.</t>	follows.</t>

	<t>First, the client determines the length L of encryptingEncodedClientHelloInner	<t>First, the client determines the length L of encrypting<tt>EncodedClientHelloInner</tt>
	with the selected HPKE AEAD. This is typically the sum of the plaintext length	with the selected HPKE AEAD. This is typically the sum of the plaintext length

	and the AEAD tag length. The client then completes theClientHelloOuterAAD with	and the AEAD tag length. The client then completes the<tt>ClientHelloOuterAAD</tt> with
	an "encrypted_client_hello" extension. This extension value contains the outer	an "encrypted_client_hello" extension. This extension value contains the outer

	variant ofECHClientHello with the following fields:</t>	variant of<tt>ECHClientHello</tt> with the following fields:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t><tt>config_id</tt>, the identifier corresponding to the chosenECHConfig structure;</t>	<t><tt>config_id</tt>, the identifier corresponding to the chosen<tt>ECHConfig</tt> structure;</t>
	</li>	</li>
	<li>	<li>
	<t><tt>cipher_suite</tt>, the client's chosen cipher suite;</t>	<t><tt>cipher_suite</tt>, the client's chosen cipher suite;</t>
	</li>	</li>
	<li>	<li>
	<t><tt>enc</tt>, as given above; and</t>	<t><tt>enc</tt>, as given above; and</t>
	</li>	</li>
	<li>	<li>
	<t><tt>payload</tt>, a placeholder byte string containing L zeros.</t>	<t><tt>payload</tt>, a placeholder byte string containing L zeros.</t>
	</li>	</li>
	</ul>	</ul>
	<t>If configuration identifiers (see <xref/>) are to be	<t>If configuration identifiers (see <xref/>) are to be
	ignored, <tt>config_id</tt> SHOULD be set to a randomly generated byte in the	ignored, <tt>config_id</tt> SHOULD be set to a randomly generated byte in the

	firstClientHelloOuter and, in the event of a HelloRetryRequest (HRR),	first<tt>ClientHelloOuter</tt> and, in the event of a HelloRetryRequest (HRR),
	MUST be left unchanged for the secondClientHelloOuter.</t>	MUST be left unchanged for the second<tt>ClientHelloOuter</tt>.</t>
	<t>The client serializes this structure to construct theClientHelloOu	<t>The client serializes this structure to construct the<tt>ClientHel
	terAAD.	loOuterAAD</tt>.
	It then computes the final payload as:</t>	It then computes the final payload as:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	final_payload = context.Seal(ClientHelloOuterAAD,	final_payload = context.Seal(ClientHelloOuterAAD,
	EncodedClientHelloInner)	EncodedClientHelloInner)
	]]></artwork>	]]></artwork>
	<t>Including <tt>ClientHelloOuterAAD</tt> as the HPKE AAD binds the <tt>ClientHelloOuter</tt>	<t>Including <tt>ClientHelloOuterAAD</tt> as the HPKE AAD binds the <tt>ClientHelloOuter</tt>
	to the <tt>ClientHelloInner</tt>, thus preventing attackers from modifying	to the <tt>ClientHelloInner</tt>, thus preventing attackers from modifying
	<tt>ClientHelloOuter</tt> while keeping the same <tt>ClientHelloInner</tt>, as described in	<tt>ClientHelloOuter</tt> while keeping the same <tt>ClientHelloInner</tt>, as described in
	<xref/>.</t>	<xref/>.</t>
	<t>Finally, the client replaces <tt>payload</tt> with <tt>final_payload</tt> to obtain	<t>Finally, the client replaces <tt>payload</tt> with <tt>final_payload</tt> to obtain

	ClientHelloOuter. The two values have the same length, so it is not necessary	<tt>ClientHelloOuter</tt>. The two values have the same length, so it is not necessary
	to recompute length prefixes in the serialized structure.</t>	to recompute length prefixes in the serialized structure.</t>
	<t>Note this construction requires the "encrypted_client_hello" be computed after	<t>Note this construction requires the "encrypted_client_hello" be computed after

	all other extensions. This is possible because theClientHelloOuter's	all other extensions. This is possible because the<tt>ClientHelloOuter</tt>'s
	"pre_shared_key" extension is eitheromitted, or uses a random binder	"pre_shared_key" extension is eitheromitted or uses a random binder
	(<xref/>).</t>	(<xref/>).</t>
	</section>	</section>
	<section anchor="grease-psk">	<section anchor="grease-psk">
	<name>GREASE PSK</name>	<name>GREASE PSK</name>
	<t>When offering ECH, the client is not permitted to advertise PSK identities in	<t>When offering ECH, the client is not permitted to advertise PSK identities in

	theClientHelloOuter. However, the client can send a "pre_shared_key"extension	the<tt>ClientHelloOuter</tt>. However, the client can send a "pre_shared_key"e
	in theClientHelloInner. In this case, when resuming a session with the client,	xtension
		in the<tt>ClientHelloInner</tt>. In this case, when resuming a session with the
		client,
	the backend server sends a "pre_shared_key" extension in its ServerHello. This	the backend server sends a "pre_shared_key" extension in its ServerHello. This
	would appear to a network observer as if the server were sending this	would appear to a network observer as if the server were sending this
	extension without solicitation, which would violate the extension rules	extension without solicitation, which would violate the extension rules

	described in <xref/>. When offering a PSK inClientHelloInner,	described in <xref/>. When offering a PSK in<tt>ClientHelloInner</tt>,
	clients SHOULD send a GREASE "pre_shared_key" extension in the	clients SHOULD send a GREASE "pre_shared_key" extension in the

	ClientHelloOuter to make it appear to the network as if the extension were	<tt>ClientHelloOuter</tt> to make it appear to the network as if the extension were
	negotiated properly.</t>	negotiated properly.</t>
	<t>The client generates the extension payload by constructing an <tt>OfferedPsks</tt>	<t>The client generates the extension payload by constructing an <tt>OfferedPsks</tt>
	structure (see <xref section="4.2.11" sectionFormat="comma"/>) as follows. For each PSK identity	structure (see <xref section="4.2.11" sectionFormat="comma"/>) as follows. For each PSK identity

	advertised in theClientHelloInner, the client generates a random PSK identity	advertised in the<tt>ClientHelloInner</tt>, the client generates a random PSK identity
	with the same length. It also generates a random, 32-bit, unsigned integer to	with the same length. It also generates a random, 32-bit, unsigned integer to
	use as the <tt>obfuscated_ticket_age</tt>. Likewise, for each inner PSK binder, the	use as the <tt>obfuscated_ticket_age</tt>. Likewise, for each inner PSK binder, the
	client generates a random string of the same length.</t>	client generates a random string of the same length.</t>
	<t>Per the rules of <xref/>, the server is not permitted to resume a	<t>Per the rules of <xref/>, the server is not permitted to resume a
	connection in the outer handshake. If ECH is rejected and the client-facing	connection in the outer handshake. If ECH is rejected and the client-facing
	server replies with a "pre_shared_key" extension in its ServerHello, then the	server replies with a "pre_shared_key" extension in its ServerHello, then the
	client MUST abort the handshake with an "illegal_parameter" alert.</t>	client MUST abort the handshake with an "illegal_parameter" alert.</t>
	</section>	</section>
	<section anchor="padding">	<section anchor="padding">
	<name>Recommended Padding Scheme</name>	<name>Recommended Padding Scheme</name>

	<t>If theClientHelloInner is encrypted without padding, then the length of	<t>If the<tt>ClientHelloInner</tt> is encrypted without padding, then the length of
	the <tt>ClientHelloOuter.payload</tt> can leak information about <tt>ClientHelloInner</tt>.	the <tt>ClientHelloOuter.payload</tt> can leak information about <tt>ClientHelloInner</tt>.

	In order to prevent this the <tt>EncodedClientHelloInner</tt> structure	In order to prevent this, the <tt>EncodedClientHelloInner</tt> structure
	has a padding field. This section describes a deterministic mechanism for	has a padding field. This section describes a deterministic mechanism for
	computing the required amount of padding based on the following	computing the required amount of padding based on the following
	observation: individual extensions can reveal sensitive information through	observation: individual extensions can reveal sensitive information through

	their length. Thus, each extension in the innerClientHello may require	their length. Thus, each extension in the inner<tt>ClientHello</tt> may require
	different amounts of padding. This padding may be fully determined by the	different amounts of padding. This padding may be fully determined by the
	client's configuration or may require server input.</t>	client's configuration or may require server input.</t>
	<t>By way of example, clients typically support a small number of application	<t>By way of example, clients typically support a small number of application
	profiles. For instance, a browser might support HTTP with ALPN values	profiles. For instance, a browser might support HTTP with ALPN values
	["http/1.1", "h2"] and WebRTC media with ALPNs ["webrtc", "c-webrtc"]. Clients	["http/1.1", "h2"] and WebRTC media with ALPNs ["webrtc", "c-webrtc"]. Clients
	SHOULD pad this extension by rounding up to the total size of the longest ALPN	SHOULD pad this extension by rounding up to the total size of the longest ALPN
	extension across all application profiles. The target padding length of most	extension across all application profiles. The target padding length of most

	ClientHello extensions can be computed in this way.</t>	<tt>ClientHello</tt> extensions can be computed in this way.</t>
	<t>In contrast, clients do not know the longest SNI value in the client-facing	<t>In contrast, clients do not know the longest SNI value in the client-facing

	server's anonymity set without server input. Clients SHOULD use theECHConfig's	server's anonymity set without server input. Clients SHOULD use the<tt>ECHConfi
	<tt>maximum_name_length</tt> field as follows, whereL is the <tt>maximum_name_l	g</tt>'s
	ength</tt>	<tt>maximum_name_length</tt> field as follows, whereM is the <tt>maximum_name_l
		ength</tt>
	value.</t>	value.</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>

	<t>If theClientHelloInner contained a "server_name"extension wit	<t>If the<tt>ClientHelloInner</tt> contained a "server_name"exte
	h a name of	nsion with a name of
	length D, add max(0,L - D) bytes of padding.</t>	length D, add max(0,M - D) bytes of padding.</t>
	</li>	</li>
	<li>	<li>

	<t>If theClientHelloInner did not contain a"server_name" extensi	<t>If the<tt>ClientHelloInner</tt> did not contain a"server_name
	on (e.g., if	" extension (e.g., if
	the client is connecting to an IP address), addL + 9 bytes of padding. This	the client is connecting to an IP address), addM + 9 bytes of padding. This
	is the length of a "server_name" extension with anL-byte name.</t>	is the length of a "server_name" extension with anM-byte name.</t>
	</li>	</li>
	</ol>	</ol>
	<t>Finally, the client SHOULD pad the entire message as follows:</t>	<t>Finally, the client SHOULD pad the entire message as follows:</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>

	<t>Let L be the length of theEncodedClientHelloInner with all the padding	<t>Let L be the length of the<tt>EncodedClientHelloInner</tt> with all the padding
	computed so far.</t>	computed so far.</t>
	</li>	</li>
	<li>	<li>
	<t>Let N = 31 - ((L - 1) % 32) and add N bytes of padding.</t>	<t>Let N = 31 - ((L - 1) % 32) and add N bytes of padding.</t>
	</li>	</li>
	</ol>	</ol>

	<t>This rounds the length ofEncodedClientHelloInner up to a multipleof 32 bytes,	<t>This rounds the length of<tt>EncodedClientHelloInner</tt> up to a multipleof 32 bytes,
	reducing the set of possible lengths across all clients.</t>	reducing the set of possible lengths across all clients.</t>

	<t>In addition to paddingClientHelloInner, clients and servers will also need to	<t>In addition to padding<tt>ClientHelloInner</tt>, clients and servers will also need to
	pad all other handshake messages that have sensitive-length fields. For example,	pad all other handshake messages that have sensitive-length fields. For example,

	if a client proposes ALPN values inClientHelloInner, the server-selected value	if a client proposes ALPN values in<tt>ClientHelloInner</tt>, the server-selected value
	will be returned in an EncryptedExtension, so that handshake message also needs	will be returned in an EncryptedExtension, so that handshake message also needs
	to be padded using TLS record layer padding.</t>	to be padded using TLS record layer padding.</t>
	</section>	</section>
	<section anchor="determining-ech-acceptance">	<section anchor="determining-ech-acceptance">
	<name>Determining ECH Acceptance</name>	<name>Determining ECH Acceptance</name>
	<t>As described in <xref/>, the server may either accept ECH and use	<t>As described in <xref/>, the server may either accept ECH and use

	ClientHelloInner or reject it and use ClientHelloOuter. This is determined by	<tt>ClientHelloInner</tt> or reject it and use <tt>ClientHelloOuter</tt>. This is determined by
	the server's initial message.</t>	the server's initial message.</t>
	<t>If the message does not negotiate TLS 1.3 or higher, the server has rejected	<t>If the message does not negotiate TLS 1.3 or higher, the server has rejected

	ECH. Otherwise,it is either a ServerHello or HelloRetryRequest.</t>	ECH. Otherwise,the message will be either a ServerHello or a HelloRetryRequest.</t>
	<t>If the message is a ServerHello, the client computes <tt>accept_confirmation</tt> as	<t>If the message is a ServerHello, the client computes <tt>accept_confirmation</tt> as
	described in <xref/>. If this value matches the last 8 bytes of	described in <xref/>. If this value matches the last 8 bytes of
	<tt>ServerHello.random</tt>, the server has accepted ECH. Otherwise, it has rejected	<tt>ServerHello.random</tt>, the server has accepted ECH. Otherwise, it has rejected
	ECH.</t>	ECH.</t>
	<t>If the message is a HelloRetryRequest, the client checks for the	<t>If the message is a HelloRetryRequest, the client checks for the
	"encrypted_client_hello" extension. If none is found, the server has rejected	"encrypted_client_hello" extension. If none is found, the server has rejected

	ECH. Otherwise, ifit has a length other than 8, the clientaborts the handshake	ECH. Otherwise, ifthe extension
		has a length other than 8, the clientMUST abort the handshake
	with a "decode_error" alert. Otherwise, the client computes	with a "decode_error" alert. Otherwise, the client computes
	<tt>hrr_accept_confirmation</tt> as described in <xref/>. If this value	<tt>hrr_accept_confirmation</tt> as described in <xref/>. If this value
	matches the extension payload, the server has accepted ECH. Otherwise, it has	matches the extension payload, the server has accepted ECH. Otherwise, it has
	rejected ECH.</t>	rejected ECH.</t>

	<t>If the server accepts ECH, the client handshakes withClientHelloInner as	<t>If the server accepts ECH, the client handshakes with<tt>ClientHelloInner</tt> as
	described in <xref/>. Otherwise, the client handshakes with	described in <xref/>. Otherwise, the client handshakes with

	ClientHelloOuter as described in <xref/>.</t>	<tt>ClientHelloOuter</tt> as described in <xref/>.</t>
	</section>	</section>
	<section anchor="accepted-ech">	<section anchor="accepted-ech">
	<name>Handshaking with ClientHelloInner</name>	<name>Handshaking with ClientHelloInner</name>
	<t>If the server accepts ECH, the client proceeds with the connection as in	<t>If the server accepts ECH, the client proceeds with the connection as in
	<xref/>, with the following modifications:</t>	<xref/>, with the following modifications:</t>

	<t>The client behaves as if it had sentClientHelloInner asthe Client	<t>The client behaves as if it had sent<tt>ClientHelloInner</tt> ast
	Hello. That	he <tt>ClientHello</tt>. That
	is, it evaluates the handshake using theClientHelloInner's preferences, and,	is, it evaluates the handshake using the<tt>ClientHelloInner</tt>'s preferences
		, and,
	when computing the transcript hash (<xref section="4.4.1" sectionFormat="of" target="RFC8446"/>), it uses	when computing the transcript hash (<xref section="4.4.1" sectionFormat="of" target="RFC8446"/>), it uses

	ClientHelloInner as the first ClientHello.</t>	<tt>ClientHelloInner</tt> as the first <tt>ClientHello</tt>.</t>
	<t>If the server responds with a HelloRetryRequest, the client computes the updated	<t>If the server responds with a HelloRetryRequest, the client computes the updated

	ClientHello message as follows:</t>	<tt>ClientHello</tt> message as follows:</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>

	<t>It computes a secondClientHelloInner based on thefirst Client	<t>It computes a second<tt>ClientHelloInner</tt> based on thefir
	HelloInner, as	st <tt>ClientHelloInner</tt>, as
	in <xref section="4.1.4" sectionFormat="of"/>. TheClientHelloI	in <xref section="4.1.4" sectionFormat="of"/>. The<tt>ClientHe
	nner's	lloInner</tt>'s
	"encrypted_client_hello" extension is left unmodified.</t>	"encrypted_client_hello" extension is left unmodified.</t>
	</li>	</li>
	<li>	<li>

	<t>It constructsEncodedClientHelloInner as described in <xref target="encoding-inner"/>.</t>	<t>It constructs<tt>EncodedClientHelloInner</tt> as described in <xref target="encoding-inner"/>.</t>
	</li>	</li>
	<li>	<li>

	<t>It constructs a second partialClientHelloOuterAAD message. This message MUST	<t>It constructs a second partial<tt>ClientHelloOuterAAD</tt> message. This message MUST
	be syntactically valid. The extensions MAY be copied from the original	be syntactically valid. The extensions MAY be copied from the original

	ClientHelloOuter unmodified, or omitted. If not sensitive, the clientMAY	<tt>ClientHelloOuter</tt> unmodified or omitted. If not sensitive, the clientMA
	copy updated extensions from the secondClientHelloInner forcompression.</t>	Y
		copy updated extensions from the second<tt>ClientHelloInner</tt> forcompressio
		n.</t>
	</li>	</li>
	<li>	<li>

	<t>It encryptsEncodedClientHelloInner as described in	<t>It encrypts<tt>EncodedClientHelloInner</tt> as described in
	<xref/>, using the second partialClientHelloOut	<xref/>, using the second partial<tt>ClientHell
	erAAD, to	oOuterAAD</tt>, to
	obtain a secondClientHelloOuter. It reuses the original HPKEencryption	obtain a second<tt>ClientHelloOuter</tt>. It reuses the original HPKEencryptio
		n
	context computed in <xref/> and uses the empty string for <tt>enc</tt>. </t>	context computed in <xref/> and uses the empty string for <tt>enc</tt>. </t>
	<t>	<t>
	The HPKE context maintains a sequence number, so this operation internally	The HPKE context maintains a sequence number, so this operation internally
	uses a fresh nonce for each AEAD operation. Reusing the HPKE context avoids	uses a fresh nonce for each AEAD operation. Reusing the HPKE context avoids
	an attack described in <xref/>.</t>	an attack described in <xref/>.</t>
	</li>	</li>
	</ol>	</ol>

	<t>The client then sends the secondClientHelloOuter to theserver. Ho	<t>The client then sends the second<tt>ClientHelloOuter</tt> to thes
	wever, as	erver. However, as
	above, it uses the secondClientHelloInner for preferences, and boththe	above, it uses the second<tt>ClientHelloInner</tt> for preferences, and bothth
	ClientHelloInner messages for the transcript hash. Additionally, itchecks the	e
		<tt>ClientHelloInner</tt> messages for the transcript hash. Additionally, itche
		cks the
	resulting ServerHello for ECH acceptance as in <xref/>.	resulting ServerHello for ECH acceptance as in <xref/>.
	If the ServerHello does not also indicate ECH acceptance, the client MUST	If the ServerHello does not also indicate ECH acceptance, the client MUST
	terminate the connection with an "illegal_parameter" alert.</t>	terminate the connection with an "illegal_parameter" alert.</t>
	</section>	</section>
	<section anchor="rejected-ech">	<section anchor="rejected-ech">
	<name>Handshaking with ClientHelloOuter</name>	<name>Handshaking with ClientHelloOuter</name>
	<t>If the server rejects ECH, the client proceeds with the handshake,	<t>If the server rejects ECH, the client proceeds with the handshake,

	authenticating forECHConfig.contents.public_name as described in	authenticating for<tt>ECHConfig.contents.public_name</tt> as described in
	<xref/>. If authentication or the handshake fails, the client MUST	<xref/>. If authentication or the handshake fails, the client MUST
	return a failure to the calling application. It MUST NOT use the retry	return a failure to the calling application. It MUST NOT use the retry
	configurations. It MUST NOT treat this as a secure signal to	configurations. It MUST NOT treat this as a secure signal to
	disable ECH.</t>	disable ECH.</t>
	<t>If the server supplied an "encrypted_client_hello" extension in its	<t>If the server supplied an "encrypted_client_hello" extension in its
	EncryptedExtensions message, the client MUST check that it is syntactically	EncryptedExtensions message, the client MUST check that it is syntactically
	valid and the client MUST abort the connection with a "decode_error" alert	valid and the client MUST abort the connection with a "decode_error" alert
	otherwise. If an earlier TLS version was negotiated, the client MUST NOT enable	otherwise. If an earlier TLS version was negotiated, the client MUST NOT enable
	the False Start optimization <xref/> for this handshake. If both	the False Start optimization <xref/> for this handshake. If both
	authentication and the handshake complete successfully, the client MUST perform	authentication and the handshake complete successfully, the client MUST perform

	the processing described belowthen abort the connection with an "ech_required"	the processing described belowand then abort the connection with an "ech_required"
	alert before sending any application data to the server.</t>	alert before sending any application data to the server.</t>
	<t>If the server provided "retry_configs" and if at least one of the	<t>If the server provided "retry_configs" and if at least one of the
	values contains a version supported by the client, the client can	values contains a version supported by the client, the client can
	regard the ECH configuration as securely replaced by the server. It	regard the ECH configuration as securely replaced by the server. It

	SHOULD retry the handshake with a new transport connection, using the	SHOULD retry the handshake with a new transport connection using the
	retry configurations supplied by the server.</t>	retry configurations supplied by the server.</t>

	<t>Clients can implement a new transport connection ina way thatbest	<t>Because the new ECH configuration replaces the old ECH configuratio
	suits their deployment. For example, clients can reuse the same server	n,
	IP address when establishing the new transport connection or they can	clients can implement a new transport connection inany way thatis
	choose to use a different IP address if providedwith options from	consistent with the previous ECH configuration. For example, clients
	DNS. ECH does notmandate any specific implementation choices when	can reuse the same server IP address when establishing the new
	establishing this newconnection.</t>	transport connection or they can choose to use a different IP address
		ifDNS providedother IP addresses for the previous configuration.
		However, it is notsafe to use IP addresses discovered with a new
		DNS query, as those may correspond to a different ECH server
		configuration, for instance associated with a different ECH server
		with a different <tt>public_name</tt>.</t>
	<t>The retry configurations are meant to be used for retried connections. Further	<t>The retry configurations are meant to be used for retried connections. Further
	use of retry configurations could yield a tracking vector. In settings where	use of retry configurations could yield a tracking vector. In settings where
	the client will otherwise already let the server track the client, e.g.,	the client will otherwise already let the server track the client, e.g.,
	because the client will send cookies to the server in parallel connections,	because the client will send cookies to the server in parallel connections,
	using the retry configurations for these parallel connections does not	using the retry configurations for these parallel connections does not
	introduce a new tracking vector.</t>	introduce a new tracking vector.</t>
	<t>If none of the values provided in "retry_configs" contains a supported	<t>If none of the values provided in "retry_configs" contains a supported
	version, the server did not supply an "encrypted_client_hello"	version, the server did not supply an "encrypted_client_hello"
	extension in its EncryptedExtensions message, or an earlier TLS	extension in its EncryptedExtensions message, or an earlier TLS
	version was negotiated, the client can regard ECH as securely disabled	version was negotiated, the client can regard ECH as securely disabled

	skipping to change at line 888 ¶	skipping to change at line 916 ¶
	a node with configuration B in the second. Note that this guidance	a node with configuration B in the second. Note that this guidance
	does not apply to the cases in the previous paragraph where the server	does not apply to the cases in the previous paragraph where the server
	has securely disabled ECH.</t>	has securely disabled ECH.</t>
	<t>If a client does not retry, it MUST report an error to the calling	<t>If a client does not retry, it MUST report an error to the calling
	application.</t>	application.</t>
	</section>	</section>
	<section anchor="auth-public-name">	<section anchor="auth-public-name">
	<name>Authenticating for the Public Name</name>	<name>Authenticating for the Public Name</name>
	<t>When the server rejects ECH, it continues with the handshake using the plaintext	<t>When the server rejects ECH, it continues with the handshake using the plaintext
	"server_name" extension instead (see <xref/>). Clients that offer	"server_name" extension instead (see <xref/>). Clients that offer

	ECH then authenticate the connection with the public name, as follows:</t>	ECH then authenticate the connection with the public name as follows:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>The client MUST verify that the certificate is valid for	<t>The client MUST verify that the certificate is valid for

	ECHConfig.contents.public_name. If invalid, it MUST abort the connection with	<tt>ECHConfig.contents.public_name</tt>. If invalid, it MUST abort the connection with
	the appropriate alert.</t>	the appropriate alert.</t>
	</li>	</li>
	<li>	<li>
	<t>If the server requests a client certificate, the client MUST respond with an	<t>If the server requests a client certificate, the client MUST respond with an
	empty Certificate message, denoting no client certificate.</t>	empty Certificate message, denoting no client certificate.</t>
	</li>	</li>
	</ul>	</ul>
	<t>In verifying the client-facing server certificate, the client MUST	<t>In verifying the client-facing server certificate, the client MUST
	interpret the public name as a DNS-based reference identity	interpret the public name as a DNS-based reference identity

	<xref/>. Clients that incorporate DNS names and IP addresses into	<xref/>. Clients that incorporate DNS names and IP addresses into
	the same syntax (e.g. <xref section="7.4" sectionFormat="of"/> and <xref/>)	the same syntax (e.g. <xref section="7.4" sectionFormat="of"/> and <xref/>)
	MUST reject names that would be interpreted as IPv4 addresses.	MUST reject names that would be interpreted as IPv4 addresses.

	Clients that enforce this by checkingECHConfig.contents.public_name	Clients that enforce this by checking<tt>ECHConfig.contents.public_name</tt>
	do not need to repeat the check when processing ECH rejection.</t>	do not need to repeat the check when processing ECH rejection.</t>
	<t>Note that authenticating a connection for the public name does not authenticate	<t>Note that authenticating a connection for the public name does not authenticate
	it for the origin. The TLS implementation MUST NOT report such connections as	it for the origin. The TLS implementation MUST NOT report such connections as
	successful to the application. It additionally MUST ignore all session tickets	successful to the application. It additionally MUST ignore all session tickets
	and session IDs presented by the server. These connections are only used to	and session IDs presented by the server. These connections are only used to
	trigger retries, as described in <xref/>. This may be implemented, for	trigger retries, as described in <xref/>. This may be implemented, for
	instance, by reporting a failed connection with a dedicated error code.</t>	instance, by reporting a failed connection with a dedicated error code.</t>

	<t>Prior to attempting a connection, a client SHOULD validate the<tt>	<t>Prior to attempting a connection, a client SHOULD validate the
	ECHConfig</tt>.	<tt>ECHConfig.contents.public_name</tt>. Clients SHOULD ignore any
	Clients SHOULD ignore any
	<tt>ECHConfig</tt> structure with a public_name that is not a valid host name in	<tt>ECHConfig</tt> structure with a public_name that is not a valid host name in

	preferred name syntax (see <xref section="2" sectionFormat="of"/>). That is, to be	preferred name syntax (see <xref section="2" sectionFormat="of"/>). That is, to be
	valid, the public_name needs to be a dot-separated sequence of LDH labels, as	valid, the public_name needs to be a dot-separated sequence of LDH labels, as
	defined in <xref section="2.3.1" sectionFormat="of"/>, where:</t>	defined in <xref section="2.3.1" sectionFormat="of"/>, where:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>the sequence does not begin or end with an ASCII dot, and</t>	<t>the sequence does not begin or end with an ASCII dot, and</t>
	</li>	</li>
	<li>	<li>
	<t>all labels are at most 63 octets.</t>	<t>all labels are at most 63 octets.</t>
	</li>	</li>
	</ul>	</ul>
	<t>Clients additionally SHOULD ignore the structure if the final LDH	<t>Clients additionally SHOULD ignore the structure if the final LDH

	label either consists of all ASCII digits (i.e. '0' through '9') or is	label either consists of all ASCII digits (i.e., '0' through '9') or is
	"0x" or "0X" followed by some, possibly empty, sequence of ASCII	"0x" or "0X" followed by some, possibly empty, sequence of ASCII

	hexadecimal digits (i.e. '0' through '9', 'a' through 'f', and 'A'	hexadecimal digits (i.e., '0' through '9', 'a' through 'f', and 'A'
	through 'F'). This avoids public_name values that may be interpreted	through 'F'). This avoids public_name values that may be interpreted
	as IPv4 literals.</t>	as IPv4 literals.</t>
	</section>	</section>
	<section anchor="impact-of-retry-on-future-connections">	<section anchor="impact-of-retry-on-future-connections">
	<name>Impact of Retry on Future Connections</name>	<name>Impact of Retry on Future Connections</name>
	<t>Clients MAY use information learned from a rejected ECH for future	<t>Clients MAY use information learned from a rejected ECH for future
	connections to avoid repeatedly connecting to the same server and	connections to avoid repeatedly connecting to the same server and
	being forced to retry. However, they MUST handle ECH rejection for	being forced to retry. However, they MUST handle ECH rejection for
	those connections as if it were a fresh connection, rather than	those connections as if it were a fresh connection, rather than
	enforcing the single retry limit from <xref/>. The reason	enforcing the single retry limit from <xref/>. The reason
	for this requirement is that if the server sends a "retry_config"	for this requirement is that if the server sends a "retry_config"
	and then immediately rejects the resulting connection, it is	and then immediately rejects the resulting connection, it is
	most likely misconfigured. However, if the server sends a "retry_config"	most likely misconfigured. However, if the server sends a "retry_config"
	and then the client tries to use that to connect some time	and then the client tries to use that to connect some time
	later, it is possible that the server has changed	later, it is possible that the server has changed
	its configuration again and is now trying to recover.</t>	its configuration again and is now trying to recover.</t>

	<t>Any persisted information MUST be associated with theECHConfig source	<t>Any persisted information MUST be associated with the<tt>ECHConfig</tt> source
	used to bootstrap the connection, such as a DNS SVCB ServiceMode record	used to bootstrap the connection, such as a DNS SVCB ServiceMode record

	<xreftarget="ECH-IN-DNS"/>. Clients MUST limit any sharing of persistedECH-rel	<xreftarget="RFCYYY1"/>. Clients MUST limit any sharing of persistedECH-relate
	ated	d
	state to connections that use the sameECHConfig source. Otherwise, it	state to connections that use the same<tt>ECHConfig</tt> source. Otherwise, it
	might become possible for the client to have the wrong public name for	might become possible for the client to have the wrong public name for
	the server, making recovery impossible.</t>	the server, making recovery impossible.</t>
	<t>ECHConfigs learned from ECH rejection can be used as a tracking	<t>ECHConfigs learned from ECH rejection can be used as a tracking
	vector. Clients SHOULD impose the same lifetime and scope restrictions	vector. Clients SHOULD impose the same lifetime and scope restrictions
	that they apply to other server-based	that they apply to other server-based
	tracking vectors such as PSKs.</t>	tracking vectors such as PSKs.</t>
	<t>In general, the safest way for clients to minimize ECH retries is to	<t>In general, the safest way for clients to minimize ECH retries is to
	comply with any freshness rules (e.g., DNS TTLs) imposed by the ECH	comply with any freshness rules (e.g., DNS TTLs) imposed by the ECH
	configuration.</t>	configuration.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="grease-ech">	<section anchor="grease-ech">
	<name>GREASE ECH</name>	<name>GREASE ECH</name>

	<t>The GREASE ECH mechanism allows a connection between and ECH-capable client	<t>The GREASE ECH mechanism allows a connection between an ECH-capable client
	and a non-ECH server to appear to use ECH, thus reducing the extent to	and a non-ECH server to appear to use ECH, thus reducing the extent to
	which ECH connections stick out (see <xref/>).</t>	which ECH connections stick out (see <xref/>).</t>
	<section anchor="client-greasing">	<section anchor="client-greasing">
	<name>Client Greasing</name>	<name>Client Greasing</name>

	<t>If the client attempts to connect to a server and does not have anECHConfig	<t>If the client attempts to connect to a server and does not have an<tt>ECHConfig</tt>
	structure available for the server, it SHOULD send a GREASE <xref/>	structure available for the server, it SHOULD send a GREASE <xref/>

	"encrypted_client_hello" extension in the firstClientHello as follows:</t>	"encrypted_client_hello" extension in the first<tt>ClientHello</tt> as follows:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>Set the <tt>config_id</tt> field to a random byte.</t>	<t>Set the <tt>config_id</tt> field to a random byte.</t>
	</li>	</li>
	<li>	<li>
	<t>Set the <tt>cipher_suite</tt> field to a supported HpkeSymmetricCipherSuite. The	<t>Set the <tt>cipher_suite</tt> field to a supported HpkeSymmetricCipherSuite. The

	selection SHOULDvary to exercise allsupported configurations, but MAY be	selection SHOULDvary, so that allplausible configurations are exercised,
	held constant for successive connections to the same server in thesame	but MAY be held constant for successive connections to the same server in thesa
	session.</t>	me
		session.
		Note: A "plausible" configuration is one that an observer might
		expect to see. A client that fully supports ECH will have a set of
		supported HPKE cipher suites to select from. A client that only
		supports GREASE ECH has no such list, so it should select from a set
		of values that are in common usage.</t>
	</li>	</li>
	<li>	<li>

	<t>Set the <tt>enc</tt> field to a randomly-generated valid encapsulated public key	<t>Set the <tt>enc</tt> field to a randomlygenerated valid encapsulated public key
	output by the HPKE KEM.</t>	output by the HPKE KEM.</t>
	</li>	</li>
	<li>	<li>

	<t>Set the <tt>payload</tt> field to a randomly-generated string of L+C bytes, where C	<t>Set the <tt>payload</tt> field to a randomlygenerated string of L+C bytes, where C
	is the ciphertext expansion of the selected AEAD scheme and L is the size of	is the ciphertext expansion of the selected AEAD scheme and L is the size of

	theEncodedClientHelloInner the client would compute when offering ECH, padded	the<tt>EncodedClientHelloInner</tt> the client would compute when offering ECH, padded
	according to <xref/>.</t>	according to <xref/>.</t>
	</li>	</li>
	</ul>	</ul>

	<t>If sending a secondClientHello in response to a HelloRetryRequest, the	<t>If sending a second<tt>ClientHello</tt> in response to a HelloRetryRequest, the
	client copies the entire "encrypted_client_hello" extension from the first	client copies the entire "encrypted_client_hello" extension from the first

	ClientHello. The identical value will reveal to an observer that the value of	<tt>ClientHello</tt>. The identical value will reveal to an observer that the value of
	"encrypted_client_hello" was fake, but this only occurs if there is a	"encrypted_client_hello" was fake, but this only occurs if there is a
	HelloRetryRequest.</t>	HelloRetryRequest.</t>
	<t>If the server sends an "encrypted_client_hello" extension in either	<t>If the server sends an "encrypted_client_hello" extension in either
	HelloRetryRequest or EncryptedExtensions, the client MUST check the extension	HelloRetryRequest or EncryptedExtensions, the client MUST check the extension
	syntactically and abort the connection with a "decode_error" alert if it is	syntactically and abort the connection with a "decode_error" alert if it is
	invalid. It otherwise ignores the extension. It MUST NOT save the	invalid. It otherwise ignores the extension. It MUST NOT save the
	"retry_configs" value in EncryptedExtensions.</t>	"retry_configs" value in EncryptedExtensions.</t>

	<t>Offering a GREASE extension is not considered offering an encryptedClientHello	<t>Offering a GREASE extension is not considered offering an encrypted<tt>ClientHello</tt>
	for purposes of requirements in <xref/>. In particular, the client	for purposes of requirements in <xref/>. In particular, the client
	MAY offer to resume sessions established without ECH.</t>	MAY offer to resume sessions established without ECH.</t>
	</section>	</section>
	<section anchor="server-greasing">	<section anchor="server-greasing">
	<name>Server Greasing</name>	<name>Server Greasing</name>
	<t><xref/> describes a set of Reserved extensions	<t><xref/> describes a set of Reserved extensions
	which will never be registered. These can be used by servers to	which will never be registered. These can be used by servers to
	"grease" the contents of the ECH configuration, as inspired by	"grease" the contents of the ECH configuration, as inspired by
	<xref/>. This helps ensure clients process ECH extensions	<xref/>. This helps ensure clients process ECH extensions
	correctly. When constructing ECH configurations, servers SHOULD	correctly. When constructing ECH configurations, servers SHOULD
	randomly select from reserved values with the high-order bit	randomly select from reserved values with the high-order bit

	clear. Correctly-implemented client will ignore those extensions.</t>	clear. Correctly implemented clients will ignore those extensions.</t>
	<t>The reserved values with the high-order bit set are mandatory, as	<t>The reserved values with the high-order bit set are mandatory, as
	defined in <xref/>. Servers SHOULD randomly select from	defined in <xref/>. Servers SHOULD randomly select from
	these values and include them in extraneous ECH configurations.	these values and include them in extraneous ECH configurations.

	Correctly-implemented clients will ignore these configurations because	Correctlyimplemented clients will ignore these configurations because
	they do not recognize the mandatory extension. Servers SHOULD ensure	they do not recognize the mandatory extension. Servers SHOULD ensure
	that any client using these configurations encounters a warning or error	that any client using these configurations encounters a warning or error
	message. This can be accomplished in several ways, including:</t>	message. This can be accomplished in several ways, including:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>By giving the extraneous configurations distinctive config IDs or	<t>By giving the extraneous configurations distinctive config IDs or
	public names, and rejecting the TLS connection or inserting an	public names, and rejecting the TLS connection or inserting an
	application-level warning message when these are observed.</t>	application-level warning message when these are observed.</t>
	</li>	</li>
	<li>	<li>
	<t>By giving the extraneous configurations an invalid public	<t>By giving the extraneous configurations an invalid public

	key and a public name not associated with theserver, so that	key and a public name not associated with theserver so that
	the initialClientHelloOuter will not be decryptable and	the initial<tt>ClientHelloOuter</tt> will not be decryptable and
	the server cannot perform the recovery flow described	the server cannot perform the recovery flow described
	in <xref/>.</t>	in <xref/>.</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	<section anchor="server-behavior">	<section anchor="server-behavior">
	<name>Server Behavior</name>	<name>Server Behavior</name>
	<t>As described in <xref/>, servers can play two roles, either as	<t>As described in <xref/>, servers can play two roles, either as

	the client-facing server or as the back-end server.	the client-facing server or as the backend server.
	Depending on the server role, the <tt>ECHClientHello</tt> will be different:</t>	Depending on the server role, the <tt>ECHClientHello</tt> will be different:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>A client-facing server expects a <tt>ECHClientHello.type</tt> of <tt>outer</tt>, and	<t>A client-facing server expects an <tt>ECHClientHello.type</tt> of <tt>outer</tt>, and
	proceeds as described in <xref/> to extract a	proceeds as described in <xref/> to extract a

	ClientHelloInner, if available.</t>	<tt>ClientHelloInner</tt>, if available.</t>
	</li>	</li>
	<li>	<li>

	<t>A backend server expects a <tt>ECHClientHello.type</tt> of <tt>inner</tt>, and	<t>A backend server expects an <tt>ECHClientHello.type</tt> of <tt>inner</tt>, and
	proceeds as described in <xref/>.</t>	proceeds as described in <xref/>.</t>
	</li>	</li>
	</ul>	</ul>

		<t>If <tt>ECHClientHello.type</tt> is not a valid <tt>ECHClientHelloType</
		tt>, then
		the server MUST abort with an "illegal_parameter" alert.</t>
	<t>In split mode, a client-facing server which receives a <tt>ClientHello</tt>	<t>In split mode, a client-facing server which receives a <tt>ClientHello</tt>
	with <tt>ECHClientHello.type</tt> of <tt>inner</tt> MUST abort with an	with <tt>ECHClientHello.type</tt> of <tt>inner</tt> MUST abort with an
	"illegal_parameter" alert. Similarly, in split mode, a backend server	"illegal_parameter" alert. Similarly, in split mode, a backend server
	which receives a <tt>ClientHello</tt> with <tt>ECHClientHello.type</tt> of <tt>outer</tt>	which receives a <tt>ClientHello</tt> with <tt>ECHClientHello.type</tt> of <tt>outer</tt>
	MUST abort with an "illegal_parameter" alert.</t>	MUST abort with an "illegal_parameter" alert.</t>
	<t>In shared mode, a server plays both roles, first decrypting the	<t>In shared mode, a server plays both roles, first decrypting the
	<tt>ClientHelloOuter</tt> and then using the contents of the	<tt>ClientHelloOuter</tt> and then using the contents of the
	<tt>ClientHelloInner</tt>. A shared mode server which receives a	<tt>ClientHelloInner</tt>. A shared mode server which receives a
	<tt>ClientHello</tt> with <tt>ECHClientHello.type</tt> of <tt>inner</tt> MUST abort with an	<tt>ClientHello</tt> with <tt>ECHClientHello.type</tt> of <tt>inner</tt> MUST abort with an
	"illegal_parameter" alert, because such a <tt>ClientHello</tt> should never	"illegal_parameter" alert, because such a <tt>ClientHello</tt> should never
	be received directly from the network.</t>	be received directly from the network.</t>

	<t>If <tt>ECHClientHello.type</tt> is not a valid <tt>ECHClientHelloType</
	tt>, then
	the server MUST abort with an "illegal_parameter" alert.</t>
	<t>If the "encrypted_client_hello" is not present, then the server completes the	<t>If the "encrypted_client_hello" is not present, then the server completes the
	handshake normally, as described in <xref/>.</t>	handshake normally, as described in <xref/>.</t>
	<section anchor="client-facing-server">	<section anchor="client-facing-server">
	<name>Client-Facing Server</name>	<name>Client-Facing Server</name>
	<t>Upon receiving an "encrypted_client_hello" extension in an initial	<t>Upon receiving an "encrypted_client_hello" extension in an initial

	ClientHello, the client-facing server determines if it will accept ECH,prior	<tt>ClientHello</tt>, the client-facing server determines if it will accept ECHprior
	to negotiating any other TLS parameters. Note that successfully decrypting the	to negotiating any other TLS parameters. Note that successfully decrypting the

	extension will result in a newClientHello to process, so even the client's TLS	extension will result in a new<tt>ClientHello</tt> to process, so even the client's TLS
	version preferences may have changed.</t>	version preferences may have changed.</t>

	<t>First, the server collects a set of candidateECHConfig values. Thislist is	<t>First, the server collects a set of candidate<tt>ECHConfig</tt> values. Thislist is
	determined by one of the two following methods:</t>	determined by one of the two following methods:</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>

	<t>CompareECHClientHello.config_id against identifiers of each known ECHConfig	<t>Compare<tt>ECHClientHello.config_id</tt> against identifiers of each known <tt>ECHConfig</tt>
	and select the ones that match, if any, as candidates.</t>	and select the ones that match, if any, as candidates.</t>
	</li>	</li>
	<li>	<li>

	<t>Collect all knownECHConfig values as candidates, with trial decryption	<t>Collect all known<tt>ECHConfig</tt> values as candidates, with trial decryption
	below determining the final selection.</t>	below determining the final selection.</t>
	</li>	</li>
	</ol>	</ol>
	<t>Some uses of ECH, such as local discovery mode, may randomize the	<t>Some uses of ECH, such as local discovery mode, may randomize the

	ECHClientHello.config_id since it can be used as a tracking vector. In such	<tt>ECHClientHello.config_id</tt> since it can be used as a tracking vector. In
	cases, the second method SHOULD be used for matching theECHClientHello to a	such
	knownECHConfig. See <xref/>. Unless specified by thea	cases, the second method SHOULD be used for matching the<tt>ECHClientHello</tt>
	pplication	to a
		known<tt>ECHConfig</tt>. See <xref/>. Unless specified
		by theapplication
	profile or otherwise externally configured, implementations MUST use the first	profile or otherwise externally configured, implementations MUST use the first
	method.</t>	method.</t>

	<t>The server then iterates over the candidateECHConfig values, attempting to	<t>The server then iterates over the candidate<tt>ECHConfig</tt> values, attempting to
	decrypt the "encrypted_client_hello" extension as follows.</t>	decrypt the "encrypted_client_hello" extension as follows.</t>

	<t>The server verifies that theECHConfig supports the ciphersuite indi	<t>The server verifies that the<tt>ECHConfig</tt> supports the ciphers
	cated by	uite indicated by
	theECHClientHello.cipher_suite and that the version of ECH indicatedby the	the<tt>ECHClientHello.cipher_suite</tt> and that the version of ECH indicatedb
	client matches theECHConfig.version. If not, the server continues tothe next	y the
	candidateECHConfig.</t>	client matches the<tt>ECHConfig.version</tt>. If not, the server continues tot
	<t>Next, the server decryptsECHClientHello.payload, using the privatek	he next
	ey skR	candidate<tt>ECHConfig</tt>.</t>
	corresponding toECHConfig, as follows:</t>	<t>Next, the server decrypts<tt>ECHClientHello.payload</tt>, using the
		privatekey skR
		corresponding to<tt>ECHConfig</tt>, as follows:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	context = SetupBaseR(ECHClientHello.enc, skR,	context = SetupBaseR(ECHClientHello.enc, skR,
	"tls ech" \|\| 0x00 \|\| ECHConfig)	"tls ech" \|\| 0x00 \|\| ECHConfig)
	EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,	EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,

	ECHClientHello.payload)	ECHClientHello.payload)
	]]></artwork>	]]></artwork>

	<t>ClientHelloOuterAAD is computed from ClientHelloOuter as described in	<t><tt>ClientHelloOuterAAD</tt> is computed from <tt>ClientHelloOuter</tt> as described in
	<xref/>. The <tt>info</tt> parameter to SetupBaseR is the	<xref/>. The <tt>info</tt> parameter to SetupBaseR is the

	concatenation "tls ech", a zero byte, and the serializedECHConfig. If	concatenation "tls ech", a zero byte, and the serialized<tt>ECHConfig</tt>. If
	decryption fails, the server continues to the next candidateECHConfig.	decryption fails, the server continues to the next candidate<tt>ECHConfig</tt>.
	Otherwise, the server reconstructsClientHelloInner from	Otherwise, the server reconstructs<tt>ClientHelloInner</tt> from
	EncodedClientHelloInner, as described in <xreftarget="encoding-inner"/>. Itthe	<tt>EncodedClientHelloInner</tt>, as described in <xreftarget="encoding-inner"/
	n stops	>. Itthen stops
	iterating over the candidateECHConfig values.</t>	iterating over the candidate<tt>ECHConfig</tt> values.</t>
	<t>Once the server has chosen the correctECHConfig, it MAYverify that	<t>Once the server has chosen the correct<tt>ECHConfig</tt>, it MAYver
	the value	ify that the value
	in theClientHelloOuter "server_name" extension matches the value of	in the<tt>ClientHelloOuter</tt> "server_name" extension matches the value of
	ECHConfig.contents.public_name, and abort with an "illegal_parameter"alert if	<tt>ECHConfig.contents.public_name</tt> and abort with an "illegal_parameter"al
		ert if
	these do not match. This optional check allows the server to limit ECH	these do not match. This optional check allows the server to limit ECH
	connections to only use the public SNI values advertised in its ECHConfigs.	connections to only use the public SNI values advertised in its ECHConfigs.
	The server MUST be careful not to unnecessarily reject connections if the same	The server MUST be careful not to unnecessarily reject connections if the same

	ECHConfig id or keypair is used in multiple ECHConfigs with distinct public	<tt>ECHConfig</tt> id or keypair is used in multiple ECHConfigs with distinct public
	names.</t>	names.</t>

	<t>Upon determining theClientHelloInner, the client-facing server checks that the	<t>Upon determining the<tt>ClientHelloInner</tt>, the client-facing server checks that the
	message includes a well-formed "encrypted_client_hello" extension of type	message includes a well-formed "encrypted_client_hello" extension of type
	<tt>inner</tt> and that it does not offer TLS 1.2 or below. If either of these checks	<tt>inner</tt> and that it does not offer TLS 1.2 or below. If either of these checks
	fails, the client-facing server MUST abort with an "illegal_parameter" alert.</t>	fails, the client-facing server MUST abort with an "illegal_parameter" alert.</t>
	<t>If these checks succeed, the client-facing server then forwards the	<t>If these checks succeed, the client-facing server then forwards the

	ClientHelloInner to the appropriate backend server, which proceeds as in	<tt>ClientHelloInner</tt> to the appropriate backend server, which proceeds as in
	<xref/>. If the backend server responds with a HelloRetryRequest, the	<xref/>. If the backend server responds with a HelloRetryRequest, the

	client-facing server forwards it, decrypts the client's secondClientHelloOuter	client-facing server forwards it, decrypts the client's second<tt>ClientHelloOuter</tt>
	using the procedure in <xref/>, and forwards the resulting	using the procedure in <xref/>, and forwards the resulting

	secondClientHelloInner. The client-facing server forwards all other TLS	second<tt>ClientHelloInner</tt>. The client-facing server forwards all other TLS
	messages between the client and backend server unmodified.</t>	messages between the client and backend server unmodified.</t>

	<t>Otherwise, if all candidateECHConfig values fail to decrypt the extension, the	<t>Otherwise, if all candidate<tt>ECHConfig</tt> values fail to decrypt the extension, the
	client-facing server MUST ignore the extension and proceed with the connection	client-facing server MUST ignore the extension and proceed with the connection

	usingClientHelloOuter, with the following modifications:</t>	using<tt>ClientHelloOuter</tt> with the following modifications:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>If sending a HelloRetryRequest, the server MAY include an	<t>If sending a HelloRetryRequest, the server MAY include an
	"encrypted_client_hello" extension with a payload of 8 random bytes; see	"encrypted_client_hello" extension with a payload of 8 random bytes; see
	<xref/> for details.</t>	<xref/> for details.</t>
	</li>	</li>
	<li>	<li>
	<t>If the server is configured with any ECHConfigs, it MUST include the	<t>If the server is configured with any ECHConfigs, it MUST include the
	"encrypted_client_hello" extension in its EncryptedExtensions with the	"encrypted_client_hello" extension in its EncryptedExtensions with the

	"retry_configs" field set to one or moreECHConfig structures withup-to-date	"retry_configs" field set to one or more<tt>ECHConfig</tt> structures withup-t
	keys. Servers MAY supply multipleECHConfig values of differentversions.	o-date
		keys. Servers MAY supply multiple<tt>ECHConfig</tt> values of differentversion
		s.
	This allows a server to support multiple versions at once.</t>	This allows a server to support multiple versions at once.</t>
	</li>	</li>
	</ul>	</ul>
	<t>Note that decryption failure could indicate a GREASE ECH extension (see	<t>Note that decryption failure could indicate a GREASE ECH extension (see
	<xref/>), so it is necessary for servers to proceed with the connection	<xref/>), so it is necessary for servers to proceed with the connection
	and rely on the client to abort if ECH was required. In particular, the	and rely on the client to abort if ECH was required. In particular, the
	unrecognized value alone does not indicate a misconfigured ECH advertisement	unrecognized value alone does not indicate a misconfigured ECH advertisement
	(<xref/>). Instead, servers can measure occurrences of the	(<xref/>). Instead, servers can measure occurrences of the
	"ech_required" alert to detect this case.</t>	"ech_required" alert to detect this case.</t>
	<section anchor="client-facing-server-hrr">	<section anchor="client-facing-server-hrr">

	<name>Sending HelloRetryRequest</name>	<name>Processing ClientHello after HelloRetryRequest</name>
	<t>After sending or forwarding a HelloRetryRequest, the client-facing server does	<t>After sending or forwarding a HelloRetryRequest, the client-facing server does
	not repeat the steps in <xref/> with the second	not repeat the steps in <xref/> with the second

	ClientHelloOuter. Instead, it continues with theECHConfig selection from the	<tt>ClientHelloOuter</tt>. Instead, it continues with the<tt>ECHConfig</tt> sel
	firstClientHelloOuter as follows:</t>	ection from the
	<t>If the client-facing server accepted ECH, it checks the secondClie	first<tt>ClientHelloOuter</tt> as follows:</t>
	ntHelloOuter	<t>If the client-facing server accepted ECH, it checksthat the second
		<tt>ClientHelloOuter</tt>
	also contains the "encrypted_client_hello" extension. If not, it MUST abort the	also contains the "encrypted_client_hello" extension. If not, it MUST abort the
	handshake with a "missing_extension" alert. Otherwise, it checks that	handshake with a "missing_extension" alert. Otherwise, it checks that

	ECHClientHello.cipher_suite andECHClientHello.config_id areunchanged, and that	<tt>ECHClientHello.cipher_suite</tt> and<tt>ECHClientHello.config_id</tt> areu
	ECHClientHello.enc is empty. If not, it MUST abort the handshake withan	nchanged, and that
		<tt>ECHClientHello.enc</tt> is empty. If not, it MUST abort the handshake witha
		n
	"illegal_parameter" alert.</t>	"illegal_parameter" alert.</t>

	<t>Finally, it decrypts the newECHClientHello.payload as a second message with the	<t>Finally, it decrypts the new<tt>ECHClientHello.payload</tt> as a second message with the
	previous HPKE context:</t>	previous HPKE context:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,	EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,

	ECHClientHello.payload)	ECHClientHello.payload)
	]]></artwork>	]]></artwork>

	<t>ClientHelloOuterAAD is computed as described in <xreftarget="authe	<t><tt>ClientHelloOuterAAD</tt> is computed as described in <xreftarg
	nticating-outer"/>, but	et="authenticating-outer"/>, but
	using the secondClientHelloOuter. If decryption fails, theclient-facing	using the second<tt>ClientHelloOuter</tt>. If decryption fails, theclient-faci
		ng
	server MUST abort the handshake with a "decrypt_error" alert. Otherwise, it	server MUST abort the handshake with a "decrypt_error" alert. Otherwise, it

	reconstructs the secondClientHelloInner from the newEncodedClientHelloInner	reconstructs the second<tt>ClientHelloInner</tt> from the new<tt>EncodedClient
	as described in <xref/>, using the secondClientHelloOut	HelloInner</tt>
	er for	as described in <xref/>, using the second<tt>ClientHell
		oOuter</tt> for
	any referenced extensions.</t>	any referenced extensions.</t>

	<t>The client-facing server then forwards the resultingClientHelloInner to the	<t>The client-facing server then forwards the resulting<tt>ClientHelloInner</tt> to the
	backend server. It forwards all subsequent TLS messages between the client and	backend server. It forwards all subsequent TLS messages between the client and
	backend server unmodified.</t>	backend server unmodified.</t>

	<t>If the client-facing server rejected ECH, or if the firstClientHello did not	<t>If the client-facing server rejected ECH, or if the first<tt>ClientHello</tt> did not
	include an "encrypted_client_hello" extension, the client-facing server	include an "encrypted_client_hello" extension, the client-facing server
	proceeds with the connection as usual. The server does not decrypt the	proceeds with the connection as usual. The server does not decrypt the

	secondClientHello's ECHClientHello.payload value, if there is one.	second<tt>ClientHello</tt>'s <tt>ECHClientHello.payload</tt> value, if there is one.
	Moreover, if the server is configured with any ECHConfigs, it MUST include the	Moreover, if the server is configured with any ECHConfigs, it MUST include the
	"encrypted_client_hello" extension in its EncryptedExtensions with the	"encrypted_client_hello" extension in its EncryptedExtensions with the

	"retry_configs" field set to one or moreECHConfig structures with up-to-date	"retry_configs" field set to one or more<tt>ECHConfig</tt> structures with up-to-date
	keys, as described in <xref/>.</t>	keys, as described in <xref/>.</t>

	<t>Note that a client-facing server that forwards the firstClientHello cannot	<t>Note that a client-facing server that forwards the first<tt>ClientHello</tt> cannot
	include its own "cookie" extension if the backend server sends a	include its own "cookie" extension if the backend server sends a
	HelloRetryRequest. This means that the client-facing server either needs to	HelloRetryRequest. This means that the client-facing server either needs to
	maintain state for such a connection or it needs to coordinate with the backend	maintain state for such a connection or it needs to coordinate with the backend

	server to include any information it requires to process the secondClientHello.</t>	server to include any information it requires to process the second<tt>ClientHello</tt>.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="backend-server">	<section anchor="backend-server">
	<name>Backend Server</name>	<name>Backend Server</name>
	<t>Upon receipt of an "encrypted_client_hello" extension of type <tt>inner</tt> in a	<t>Upon receipt of an "encrypted_client_hello" extension of type <tt>inner</tt> in a

	ClientHello, if the backend server negotiates TLS 1.3 or higher, then it MUST	<tt>ClientHello</tt>, if the backend server negotiates TLS 1.3 or higher, then it MUST
	confirm ECH acceptance to the client by computing its ServerHello as described	confirm ECH acceptance to the client by computing its ServerHello as described
	here.</t>	here.</t>

	<t>The backend server embeds inServerHello.random a string derived from the inner	<t>The backend server embeds in<tt>ServerHello.random</tt> a string derived from the inner
	handshake. It begins by computing its ServerHello as usual, except the last 8	handshake. It begins by computing its ServerHello as usual, except the last 8

	bytes ofServerHello.random are set to zero. It then computes thetranscript	bytes of<tt>ServerHello.random</tt> are set to zero. It then computes thetrans
	hash forClientHelloInner up to and including the modified ServerHello, as	cript
		hash for<tt>ClientHelloInner</tt> up to and including the modified ServerHello,
		as
	described in <xref section="4.4.1" sectionFormat="comma"/>. Let transcript_ech_conf denote the	described in <xref section="4.4.1" sectionFormat="comma"/>. Let transcript_ech_conf denote the
	output. Finally, the backend server overwrites the last 8 bytes of the	output. Finally, the backend server overwrites the last 8 bytes of the

	ServerHello.random with the following string:</t>	<tt>ServerHello.random</tt> with the following string:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	accept_confirmation = HKDF-Expand-Label(	accept_confirmation = HKDF-Expand-Label(
	HKDF-Extract(0, ClientHelloInner.random),	HKDF-Extract(0, ClientHelloInner.random),
	"ech accept confirmation",	"ech accept confirmation",
	transcript_ech_conf,	transcript_ech_conf,
	8)	8)
	]]></artwork>	]]></artwork>
	<t>where HKDF-Expand-Label is defined in <xref section="7.1" sectionFormat="comma"/>, "0" indicates a	<t>where HKDF-Expand-Label is defined in <xref section="7.1" sectionFormat="comma"/>, "0" indicates a
	string of Hash.length bytes set to zero, and Hash is the hash function used to	string of Hash.length bytes set to zero, and Hash is the hash function used to
	compute the transcript hash. In DTLS, the modified version of HKDF-Expand-Label	compute the transcript hash. In DTLS, the modified version of HKDF-Expand-Label
	defined in <xref section="5.9" sectionFormat="comma"/> is used instead.</t>	defined in <xref section="5.9" sectionFormat="comma"/> is used instead.</t>
	<t>The backend server MUST NOT perform this operation if it negotiated TLS 1.2 or	<t>The backend server MUST NOT perform this operation if it negotiated TLS 1.2 or
	below. Note that doing so would overwrite the downgrade signal for TLS 1.3 (see	below. Note that doing so would overwrite the downgrade signal for TLS 1.3 (see
	<xref section="4.1.3" sectionFormat="comma"/>).</t>	<xref section="4.1.3" sectionFormat="comma"/>).</t>
	<section anchor="backend-server-hrr">	<section anchor="backend-server-hrr">
	<name>Sending HelloRetryRequest</name>	<name>Sending HelloRetryRequest</name>

	<t>When the backend server sends HelloRetryRequest in response to theClientHello,	<t>When the backend server sends HelloRetryRequest in response to the<tt>ClientHello</tt>,
	it similarly confirms ECH acceptance by adding a confirmation signal to its	it similarly confirms ECH acceptance by adding a confirmation signal to its
	HelloRetryRequest. But instead of embedding the signal in the	HelloRetryRequest. But instead of embedding the signal in the
	HelloRetryRequest.random (the value of which is specified by <xref/>), it	HelloRetryRequest.random (the value of which is specified by <xref/>), it
	sends the signal in an extension.</t>	sends the signal in an extension.</t>
	<t>The backend server begins by computing HelloRetryRequest as usual, except that	<t>The backend server begins by computing HelloRetryRequest as usual, except that
	it also contains an "encrypted_client_hello" extension with a payload of 8 zero	it also contains an "encrypted_client_hello" extension with a payload of 8 zero

	bytes. It then computes the transcript hash for the firstClientHelloInner,	bytes. It then computes the transcript hash for the first<tt>ClientHelloInner</tt>,
	denoted ClientHelloInner1, up to and including the modified HelloRetryRequest.	denoted ClientHelloInner1, up to and including the modified HelloRetryRequest.
	Let transcript_hrr_ech_conf denote the output. Finally, the backend server	Let transcript_hrr_ech_conf denote the output. Finally, the backend server
	overwrites the payload of the "encrypted_client_hello" extension with the	overwrites the payload of the "encrypted_client_hello" extension with the
	following string:</t>	following string:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	hrr_accept_confirmation = HKDF-Expand-Label(	hrr_accept_confirmation = HKDF-Expand-Label(
	HKDF-Extract(0, ClientHelloInner1.random),	HKDF-Extract(0, ClientHelloInner1.random),
	"hrr ech accept confirmation",	"hrr ech accept confirmation",
	transcript_hrr_ech_conf,	transcript_hrr_ech_conf,
	8)	8)
	]]></artwork>	]]></artwork>
	<t>In the subsequent ServerHello message, the backend server sends the	<t>In the subsequent ServerHello message, the backend server sends the

	accept_confirmation value as described in <xref/>.</t>	<tt>accept_confirmation</tt> value as described in <xref/>.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	<section anchor="deployment">	<section anchor="deployment">
	<name>Deployment Considerations</name>	<name>Deployment Considerations</name>
	<t>The design of ECH as specified in this document necessarily requires changes	<t>The design of ECH as specified in this document necessarily requires changes
	to client, client-facing server, and backend server. Coordination between	to client, client-facing server, and backend server. Coordination between
	client-facing and backend server requires care, as deployment mistakes	client-facing and backend server requires care, as deployment mistakes
	can lead to compatibility issues. These are discussed in <xref/>.</t>	can lead to compatibility issues. These are discussed in <xref/>.</t>

	<t>Beyond coordination difficulties, ECH deployments may alsoinduce chall	<t>Beyond coordination difficulties, ECH deployments may alsocreate chall
	enges	enges
	foruse cases of information that ECH protects. In particular,	foruses of information that ECH protects. In particular,
	use cases which depend on this unencrypted information may no longer work	use cases which depend on this unencrypted information may no longer work
	as desired. This is elaborated upon in <xref/>.</t>	as desired. This is elaborated upon in <xref/>.</t>
	<section anchor="compat-issues">	<section anchor="compat-issues">
	<name>Compatibility Issues</name>	<name>Compatibility Issues</name>
	<t>Unlike most TLS extensions, placing the SNI value in an ECH extension is not	<t>Unlike most TLS extensions, placing the SNI value in an ECH extension is not
	interoperable with existing servers, which expect the value in the existing	interoperable with existing servers, which expect the value in the existing

	plaintext extension. Thus server operators SHOULD ensure servers understand a	plaintext extension. Thus, server operators SHOULD ensure servers understand a
	given set of ECH keys before advertising them. Additionally, servers SHOULD	given set of ECH keys before advertising them. Additionally, servers SHOULD

	retain support for any previously-advertised keys for the duration of their	retain support for any previouslyadvertised keys for the duration of their
	validity.</t>	validity.</t>
	<t>However, in more complex deployment scenarios, this may be difficult to fully	<t>However, in more complex deployment scenarios, this may be difficult to fully

	guarantee. Thus this protocol was designed to be robust in case of	guarantee. Thus, this protocol was designed to be robust in case of
	inconsistencies between systems that advertise ECH keys and servers, at the cost	inconsistencies between systems that advertise ECH keys and servers, at the cost
	of extra round-trips due to a retry. Two specific scenarios are detailed below.</t>	of extra round-trips due to a retry. Two specific scenarios are detailed below.</t>
	<section anchor="misconfiguration">	<section anchor="misconfiguration">
	<name>Misconfiguration and Deployment Concerns</name>	<name>Misconfiguration and Deployment Concerns</name>
	<t>It is possible for ECH advertisements and servers to become inconsistent. This	<t>It is possible for ECH advertisements and servers to become inconsistent. This
	may occur, for instance, from DNS misconfiguration, caching issues, or an	may occur, for instance, from DNS misconfiguration, caching issues, or an
	incomplete rollout in a multi-server deployment. This may also occur if a server	incomplete rollout in a multi-server deployment. This may also occur if a server
	loses its ECH keys, or if a deployment of ECH must be rolled back on the server.</t>	loses its ECH keys, or if a deployment of ECH must be rolled back on the server.</t>
	<t>The retry mechanism repairs inconsistencies, provided the TLS server	<t>The retry mechanism repairs inconsistencies, provided the TLS server
	has a certificate for the public name. If server and advertised keys	has a certificate for the public name. If server and advertised keys
	mismatch, the server will reject ECH and respond with	mismatch, the server will reject ECH and respond with
	"retry_configs". If the server does	"retry_configs". If the server does

	not understand	not understand the "encrypted_client_hello" extension at all, it will ignore it
	the "encrypted_client_hello" extension at all, it will ignore it as required by	as required by <xref section="4.1.2" sectionFormat="of"/>.Prov
	<xref section="4.1.2" sectionFormat="of"/>.Provided the server	ided the server can present a certificate
	can present a certificate
	valid for the public name, the client can safely retry with updated settings,	valid for the public name, the client can safely retry with updated settings,
	as described in <xref/>.</t>	as described in <xref/>.</t>
	<t>Unless ECH is disabled as a result of successfully establishing a connection to	<t>Unless ECH is disabled as a result of successfully establishing a connection to
	the public name, the client MUST NOT fall back to using unencrypted	the public name, the client MUST NOT fall back to using unencrypted
	ClientHellos, as this allows a network attacker to disclose the contents of this	ClientHellos, as this allows a network attacker to disclose the contents of this

	ClientHello, including the SNI. It MAY attempt to use another server from the	<tt>ClientHello</tt>, including the SNI. It MAY attempt to use another server from the
	DNS results, if one is provided.</t>	DNS results, if one is provided.</t>

	<t>In order to ensure that the retry mechanism works successfully servers	<t>In order to ensure that the retry mechanism works successfully, servers
	SHOULD ensure that every endpoint which might receive a TLS connection	SHOULD ensure that every endpoint which might receive a TLS connection
	is provisioned with an appropriate certificate for the public name.	is provisioned with an appropriate certificate for the public name.
	This is especially important during periods of server reconfiguration	This is especially important during periods of server reconfiguration
	when different endpoints might have different configurations.</t>	when different endpoints might have different configurations.</t>
	</section>	</section>
	<section anchor="middleboxes">	<section anchor="middleboxes">
	<name>Middleboxes</name>	<name>Middleboxes</name>
	<t>The requirements in <xref section="9.3" sectionFormat="comma" target="RFC8446"/> which require proxies to	<t>The requirements in <xref section="9.3" sectionFormat="comma" target="RFC8446"/> which require proxies to
	act as conforming TLS client and server provide interoperability	act as conforming TLS client and server provide interoperability
	with TLS-terminating proxies even in cases where the server supports	with TLS-terminating proxies even in cases where the server supports
	ECH but the proxy does not, as detailed below.</t>	ECH but the proxy does not, as detailed below.</t>

	<t>The proxy must ignore unknownparameters, and	<t>The proxy must ignore unknownparameters and
	generate its ownClientHello containing only parameters it understands. Thus,	generate its own<tt>ClientHello</tt> containing only parameters it understands.
	when presenting a certificate to the client or sending aClientHello to the	Thus,
	server, the proxy will act as if connecting to theClientHelloOuter	when presenting a certificate to the client or sending a<tt>ClientHello</tt> to
	server_name, which SHOULD match the public name (see <xreftarget="real-ech"/>),	the
	without	server, the proxy will act as if connecting to the<tt>ClientHelloOuter</tt>
		server_name, which SHOULD match the public name (see <xreftarget="real-ech"/>)
		without
	echoing the "encrypted_client_hello" extension.</t>	echoing the "encrypted_client_hello" extension.</t>
	<t>Depending on whether the client is configured to accept the proxy's certificate	<t>Depending on whether the client is configured to accept the proxy's certificate
	as authoritative for the public name, this may trigger the retry logic described	as authoritative for the public name, this may trigger the retry logic described
	in <xref/> or result in a connection failure. A proxy which is not	in <xref/> or result in a connection failure. A proxy which is not
	authoritative for the public name cannot forge a signal to disable ECH.</t>	authoritative for the public name cannot forge a signal to disable ECH.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="no-sni">	<section anchor="no-sni">
	<name>Deployment Impact</name>	<name>Deployment Impact</name>
	<t>Some use cases which depend on information ECH encrypts may break with the	<t>Some use cases which depend on information ECH encrypts may break with the

	skipping to change at line 1345 ¶	skipping to change at line 1377 ¶
	intercept and decrypt client TLS connections. The feasibility of alternative	intercept and decrypt client TLS connections. The feasibility of alternative
	solutions is specific to individual deployments.</t>	solutions is specific to individual deployments.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="compliance">	<section anchor="compliance">
	<name>Compliance Requirements</name>	<name>Compliance Requirements</name>
	<t>In the absence of an application profile standard specifying otherwise,	<t>In the absence of an application profile standard specifying otherwise,
	a compliant ECH application MUST implement the following HPKE cipher suite:</t>	a compliant ECH application MUST implement the following HPKE cipher suite:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>KEM: DHKEM(X25519, HKDF-SHA256) (see <xref section="7.1" sectionFormat="of"/>)</t>	<t>KEM: DHKEM(X25519, HKDF-SHA256) (see <xref section="7.1" sectionFormat="of"/>)</t>
	</li>	</li>
	<li>	<li>

	<t>KDF: HKDF-SHA256 (see <xref section="7.2" sectionFormat="of" target="HPKE"/>)</t>	<t>KDF: HKDF-SHA256 (see <xref section="7.2" sectionFormat="of" target="RFC9180"/>)</t>
	</li>	</li>
	<li>	<li>

	<t>AEAD: AES-128-GCM (see <xref section="7.3" sectionFormat="of" target="HPKE"/>)</t>	<t>AEAD: AES-128-GCM (see <xref section="7.3" sectionFormat="of" target="RFC9180"/>)</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>
	<section anchor="security-considerations">	<section anchor="security-considerations">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>This section contains security considerations for ECH.</t>	<t>This section contains security considerations for ECH.</t>
	<section anchor="goals">	<section anchor="goals">
	<name>Security and Privacy Goals</name>	<name>Security and Privacy Goals</name>
	<t>ECH considers two types of attackers: passive and active. Passive attackers can	<t>ECH considers two types of attackers: passive and active. Passive attackers can
	read packets from the network, but they cannot perform any sort of active	read packets from the network, but they cannot perform any sort of active
	behavior such as probing servers or querying DNS. A middlebox that filters based	behavior such as probing servers or querying DNS. A middlebox that filters based
	on plaintext packet contents is one example of a passive attacker. In contrast,	on plaintext packet contents is one example of a passive attacker. In contrast,
	active attackers can also write packets into the network for malicious purposes,	active attackers can also write packets into the network for malicious purposes,
	such as interfering with existing connections, probing servers, and querying	such as interfering with existing connections, probing servers, and querying
	DNS. In short, an active attacker corresponds to the conventional threat model	DNS. In short, an active attacker corresponds to the conventional threat model
	<xref/> for TLS 1.3 <xref/>.</t>	<xref/> for TLS 1.3 <xref/>.</t>
	<t>Passive and active attackers can exist anywhere in the network, including	<t>Passive and active attackers can exist anywhere in the network, including
	between the client and client-facing server, as well as between the	between the client and client-facing server, as well as between the

	client-facing and backend servers when running ECH inSplit Mode. However,	client-facing and backend servers when running ECH insplit mode. However,
	forSplit Mode in particular, ECH makes two additional assumptions:</t>	forsplit mode in particular, ECH makes two additional assumptions:</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>
	<t>The channel between each client-facing and each backend server is	<t>The channel between each client-facing and each backend server is
	authenticated such that the backend server only accepts messages from trusted	authenticated such that the backend server only accepts messages from trusted
	client-facing servers. The exact mechanism for establishing this authenticated	client-facing servers. The exact mechanism for establishing this authenticated
	channel is out of scope for this document.</t>	channel is out of scope for this document.</t>
	</li>	</li>
	<li>	<li>

	<t>The attacker cannot correlate messages betweenclient and client-facing	<t>The attacker cannot correlate messages betweena client and client-facing
	server with messages between client-facing and backend server. Such correlation	server with messages between client-facing and backend server. Such correlation
	could allow an attacker to link information unique to a backend server, such as	could allow an attacker to link information unique to a backend server, such as

	their server name or IP address, with a client's encryptedClientHelloInner.	their server name or IP address, with a client's encrypted<tt>ClientHelloInner</tt>.
	Correlation could occur through timing analysis of messages across the	Correlation could occur through timing analysis of messages across the
	client-facing server, or via examining the contents of messages sent between	client-facing server, or via examining the contents of messages sent between
	client-facing and backend servers. The exact mechanism for preventing this sort	client-facing and backend servers. The exact mechanism for preventing this sort
	of correlation is out of scope for this document.</t>	of correlation is out of scope for this document.</t>
	</li>	</li>
	</ol>	</ol>
	<t>Given this threat model, the primary goals of ECH are as follows.</t>	<t>Given this threat model, the primary goals of ECH are as follows.</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>
	<t>Security preservation. Use of ECH does not weaken the security properties of	<t>Security preservation. Use of ECH does not weaken the security properties of
	TLS without ECH.</t>	TLS without ECH.</t>

	skipping to change at line 1408 ¶	skipping to change at line 1440 ¶
	is defined in <xref/>.)</t>	is defined in <xref/>.)</t>
	</li>	</li>
	<li>	<li>
	<t>Downgrade resistance. An attacker cannot downgrade a connection that	<t>Downgrade resistance. An attacker cannot downgrade a connection that
	attempts to use ECH to one that does not use ECH.</t>	attempts to use ECH to one that does not use ECH.</t>
	</li>	</li>
	</ol>	</ol>
	<t>These properties were formally proven in <xref/>.</t>	<t>These properties were formally proven in <xref/>.</t>
	<t>With regards to handshake privacy, client-facing server configuration	<t>With regards to handshake privacy, client-facing server configuration
	determines the size of the anonymity set. For example, if a	determines the size of the anonymity set. For example, if a

	client-facing server uses distinctECHConfig values for each server	client-facing server uses distinct<tt>ECHConfig</tt> values for each server
	name, then each anonymity set has size k = 1. Client-facing servers	name, then each anonymity set has size k = 1. Client-facing servers
	SHOULD deploy ECH in such a way so as to maximize the size of the	SHOULD deploy ECH in such a way so as to maximize the size of the
	anonymity set where possible. This means client-facing servers should	anonymity set where possible. This means client-facing servers should

	use the sameECHConfig for as many server names as possible. An	use the same<tt>ECHConfig</tt> for as many server names as possible. An
	attacker can distinguish two server names that have different	attacker can distinguish two server names that have different

	ECHConfig values based on the ECHClientHello.config_id value.</t>	<tt>ECHConfig</tt> values based on the <tt>ECHClientHello</tt>.<tt>config_id</tt> value.</t>
	<t>This also means public information in a TLS handshake should be	<t>This also means public information in a TLS handshake should be
	consistent across server names. For example, if a client-facing server	consistent across server names. For example, if a client-facing server
	services many backend origin server names, only one of which supports some	services many backend origin server names, only one of which supports some
	cipher suite, it may be possible to identify that server name based on the	cipher suite, it may be possible to identify that server name based on the

	contents of unencrypted handshake message. Similarly, if a backend	contents oftheunencrypted handshake message. Similarly, if a backend
	origin reuses KeyShare values, then that provides a unique identifier	origin reuses KeyShare values, then that provides a unique identifier
	for that server.</t>	for that server.</t>
	<t>Beyond these primary security and privacy goals, ECH also aims to hide, to some	<t>Beyond these primary security and privacy goals, ECH also aims to hide, to some
	extent, the fact that it is being used at all. Specifically, the GREASE ECH	extent, the fact that it is being used at all. Specifically, the GREASE ECH
	extension described in <xref/> does not change the security properties of	extension described in <xref/> does not change the security properties of
	the TLS handshake at all. Its goal is to provide "cover" for the real ECH	the TLS handshake at all. Its goal is to provide "cover" for the real ECH
	protocol (<xref/>), as a means of addressing the "do not stick out"	protocol (<xref/>), as a means of addressing the "do not stick out"
	requirements of <xref/>. See <xref/> for details.</t>	requirements of <xref/>. See <xref/> for details.</t>
	</section>	</section>
	<section anchor="plaintext-dns">	<section anchor="plaintext-dns">
	<name>Unauthenticated and Plaintext DNS</name>	<name>Unauthenticated and Plaintext DNS</name>
	<t>ECH supports delivery of configurations through the DNS using SVCB or HTTPS	<t>ECH supports delivery of configurations through the DNS using SVCB or HTTPS

	records, without requiring any verifiable authenticity or provenance	records without requiring any verifiable authenticity or provenance
	information <xreftarget="ECH-IN-DNS"/>. This means that any attacker which can	information <xreftarget="RFCYYY1"/>. This means that any attacker which caninj
	inject	ect
	DNS responses or poison DNS caches, which is a common scenario in	DNS responses or poison DNS caches, which is a common scenario in
	client access networks, can supply clients with fake ECH configurations (so	client access networks, can supply clients with fake ECH configurations (so
	that the client encrypts data to them) or strip the ECH configurations from	that the client encrypts data to them) or strip the ECH configurations from
	the response. However, in the face of an attacker that controls DNS,	the response. However, in the face of an attacker that controls DNS,
	no encryption scheme can work because the attacker can replace the IP	no encryption scheme can work because the attacker can replace the IP
	address, thus blocking client connections, or substitute a unique IP	address, thus blocking client connections, or substitute a unique IP
	address for each DNS name that was looked up. Thus, using DNS records	address for each DNS name that was looked up. Thus, using DNS records
	without additional authentication does not make the situation significantly	without additional authentication does not make the situation significantly
	worse.</t>	worse.</t>
	<t>Clearly, DNSSEC (if the client validates and hard fails) is a defense	<t>Clearly, DNSSEC (if the client validates and hard fails) is a defense
	against this form of attack, but encrypted DNS transport is also a	against this form of attack, but encrypted DNS transport is also a
	defense against DNS attacks by attackers on the local network, which	defense against DNS attacks by attackers on the local network, which

	is a common case whereClientHello and SNI encryption are	is a common case where<tt>ClientHello</tt> and SNI encryption are
	desired. Moreover, as noted in the introduction, SNI encryption is	desired. Moreover, as noted in the introduction, SNI encryption is
	less useful without encryption of DNS queries in transit.</t>	less useful without encryption of DNS queries in transit.</t>
	</section>	</section>
	<section anchor="client-tracking">	<section anchor="client-tracking">
	<name>Client Tracking</name>	<name>Client Tracking</name>

	<t>A malicious client-facing server could distribute unique, per-clientECHConfig	<t>A malicious client-facing server could distribute unique, per-client<tt>ECHConfig</tt>
	structures as a way of tracking clients across subsequent connections. On-path	structures as a way of tracking clients across subsequent connections. On-path
	adversaries which know about these unique keys could also track clients in this	adversaries which know about these unique keys could also track clients in this
	way by observing TLS connection attempts.</t>	way by observing TLS connection attempts.</t>
	<t>The cost of this type of attack scales linearly with the desired number of	<t>The cost of this type of attack scales linearly with the desired number of
	target clients. Moreover, DNS caching behavior makes targeting individual users	target clients. Moreover, DNS caching behavior makes targeting individual users

	for extended periods of time, e.g., using per-clientECHConfig structures	for extended periods of time, e.g., using per-client<tt>ECHConfig</tt> structures
	delivered via HTTPS RRs with high TTLs, challenging. Clients can help mitigate	delivered via HTTPS RRs with high TTLs, challenging. Clients can help mitigate

	this problem by flushing any DNS orECHConfig state upon changing networks	this problem by flushing any DNS or<tt>ECHConfig</tt> state upon changing networks
	(this may not be possible if clients use the operating system resolver	(this may not be possible if clients use the operating system resolver
	rather than doing their own resolution).</t>	rather than doing their own resolution).</t>

	<t>ECHConfig rotation rate is also an issue for non-malicious servers,	<t><tt>ECHConfig</tt> rotation rate is also an issue for non-malicious servers,
	which may want to rotate keys frequently to limit exposure if the key	which may want to rotate keys frequently to limit exposure if the key
	is compromised. Rotating too frequently limits the client anonymity	is compromised. Rotating too frequently limits the client anonymity
	set. In practice, servers which service many server names and thus	set. In practice, servers which service many server names and thus
	have high loads are the best candidates to be client-facing servers	have high loads are the best candidates to be client-facing servers
	and so anonymity sets will typically involve many connections even	and so anonymity sets will typically involve many connections even
	with fairly fast rotation intervals.</t>	with fairly fast rotation intervals.</t>
	</section>	</section>
	<section anchor="ignored-configs">	<section anchor="ignored-configs">
	<name>Ignored Configuration Identifiers and Trial Decryption</name>	<name>Ignored Configuration Identifiers and Trial Decryption</name>
	<t>Ignoring configuration identifiers may be useful in scenarios where clients and	<t>Ignoring configuration identifiers may be useful in scenarios where clients and
	client-facing servers do not want to reveal information about the client-facing	client-facing servers do not want to reveal information about the client-facing
	server in the "encrypted_client_hello" extension. In such settings, clients send	server in the "encrypted_client_hello" extension. In such settings, clients send

	a randomly generatedconfig_id in the ECHClientHello. Serversin these settings	a randomly generated<tt>config_id</tt> in the <tt>ECHClientHello</tt>. Serversin these settings
	must perform trial decryption since they cannot identify the client's chosen ECH	must perform trial decryption since they cannot identify the client's chosen ECH

	key using theconfig_id value. As a result, ignoring configuration	key using the<tt>config_id</tt> value. As a result, ignoring configuration
	identifiers may exacerbate DoS attacks. Specifically, an adversary may send	identifiers may exacerbate DoS attacks. Specifically, an adversary may send

	maliciousClientHello messages, i.e., those which will not decrypt with any	malicious<tt>ClientHello</tt> messages, i.e., those which will not decrypt with any
	known ECH key, in order to force wasteful decryption. Servers that support this	known ECH key, in order to force wasteful decryption. Servers that support this
	feature should, for example, implement some form of rate limiting mechanism to	feature should, for example, implement some form of rate limiting mechanism to
	limit the potential damage caused by such attacks.</t>	limit the potential damage caused by such attacks.</t>
	<t>Unless specified by the application using (D)TLS or externally configured,	<t>Unless specified by the application using (D)TLS or externally configured,

	implementations MUST NOT use this mode.</t>	clientimplementations MUST NOT use this mode.</t>
	</section>	</section>
	<section anchor="outer-clienthello">	<section anchor="outer-clienthello">
	<name>Outer ClientHello</name>	<name>Outer ClientHello</name>

	<t>Any information that the client includes in theClientHelloOuter isv	<t>Any information that the client includes in the<tt>ClientHelloOuter<
	isible to	/tt> isvisible to
	passive observers. The client SHOULD NOT send values in theClientHelloOuter	passive observers. The client SHOULD NOT send values in the<tt>ClientHelloOuter
	which would reveal a sensitiveClientHelloInner property, such as thetrue	</tt>
		which would reveal a sensitive<tt>ClientHelloInner</tt> property, such as thet
		rue
	server name. It MAY send values associated with the public name in the	server name. It MAY send values associated with the public name in the

	ClientHelloOuter.</t>	<tt>ClientHelloOuter</tt>.</t>
	<t>In particular, some extensions require the client send a server-name-specific	<t>In particular, some extensions require the client send a server-name-specific

	value in theClientHello. These values may reveal information about the	value in the<tt>ClientHello</tt>. These values may reveal information about the
	true server name. For example, the "cached_info"ClientHello extension	true server name. For example, the "cached_info"<tt>ClientHello</tt> extension
	<xref/> can contain the hash of a previously observed server certificate.	<xref/> can contain the hash of a previously observed server certificate.
	The client SHOULD NOT send values associated with the true server name in the	The client SHOULD NOT send values associated with the true server name in the

	ClientHelloOuter. It MAY send such values in the ClientHelloInner.</t>	<tt>ClientHelloOuter</tt>. It MAY send such values in the <tt>ClientHelloInner</tt>.</t>
	<t>A client may also use different preferences in different contexts. For example,	<t>A client may also use different preferences in different contexts. For example,
	it may send different ALPN lists to different servers or in different	it may send different ALPN lists to different servers or in different
	application contexts. A client that treats this context as sensitive SHOULD NOT	application contexts. A client that treats this context as sensitive SHOULD NOT

	send context-specific values inClientHelloOuter.</t>	send context-specific values in<tt>ClientHelloOuter</tt>.</t>
	<t>Values which are independent of the true server name, or other information the	<t>Values which are independent of the true server name, or other information the

	client wishes to protect, MAY be included inClientHelloOuter. If they match	client wishes to protect, MAY be included in<tt>ClientHelloOuter</tt>. If they
	the correspondingClientHelloInner, they MAY be compressed as described in	match
		the corresponding<tt>ClientHelloInner</tt>, they MAY be compressed as described
		in
	<xref/>. However, note that the payload length reveals information	<xref/>. However, note that the payload length reveals information
	about which extensions are compressed, so inner extensions which only sometimes	about which extensions are compressed, so inner extensions which only sometimes
	match the corresponding outer extension SHOULD NOT be compressed.</t>	match the corresponding outer extension SHOULD NOT be compressed.</t>

	<t>Clients MAY include additional extensions inClientHelloOuter to avoid	<t>Clients MAY include additional extensions in<tt>ClientHelloOuter</tt> to avoid
	signaling unusual behavior to passive observers, provided the choice of value	signaling unusual behavior to passive observers, provided the choice of value
	and value itself are not sensitive. See <xref/>.</t>	and value itself are not sensitive. See <xref/>.</t>
	</section>	</section>
	<section anchor="inner-clienthello">	<section anchor="inner-clienthello">
	<name>Inner ClientHello</name>	<name>Inner ClientHello</name>

	<t>Values which depend on the contents ofClientHelloInner, such as the	<t>Values which depend on the contents of<tt>ClientHelloInner</tt>, such as the
	true server name, can influence how client-facing servers process this message.	true server name, can influence how client-facing servers process this message.
	In particular, timing side channels can reveal information about the contents	In particular, timing side channels can reveal information about the contents

	ofClientHelloInner. Implementations should take such side channels into	of<tt>ClientHelloInner</tt>. Implementations should take such side channels into
	consideration when reasoning about the privacy properties that ECH provides.</t>	consideration when reasoning about the privacy properties that ECH provides.</t>
	</section>	</section>
	<section anchor="related-privacy-leaks">	<section anchor="related-privacy-leaks">
	<name>Related Privacy Leaks</name>	<name>Related Privacy Leaks</name>
	<t>ECH requires encrypted DNS to be an effective privacy protection mechanism.	<t>ECH requires encrypted DNS to be an effective privacy protection mechanism.
	However, verifying the server's identity from the Certificate message,	However, verifying the server's identity from the Certificate message,
	particularly when using the X509 CertificateType, may result in additional	particularly when using the X509 CertificateType, may result in additional
	network traffic that may reveal the server identity. Examples of this traffic	network traffic that may reveal the server identity. Examples of this traffic

	may include requests for revocation information, such asOCSP orCRL traffic, or	may include requests for revocation information, such asOnline Certificate Stat
	requests for repository information, such as authorityInformationAccess. It may	us Protocol (OCSP) orCertificate Revocation List (CRL) traffic, or requests for
	also include implementation-specific traffic for additional information sources	repository information, such as authorityInformationAccess. It may also include
	as part ofverification.</t>	implementation-specific traffic for additional information sources as part ofv
		erification.</t>
	<t>Implementations SHOULD avoid leaking information that may identify the server.	<t>Implementations SHOULD avoid leaking information that may identify the server.
	Even when sent over an encrypted transport, such requests may result in indirect	Even when sent over an encrypted transport, such requests may result in indirect
	exposure of the server's identity, such as indicating a specific CA or service	exposure of the server's identity, such as indicating a specific CA or service
	being used. To mitigate this risk, servers SHOULD deliver such information	being used. To mitigate this risk, servers SHOULD deliver such information
	in-band when possible, such as through the use of OCSP stapling, and clients	in-band when possible, such as through the use of OCSP stapling, and clients
	SHOULD take steps to minimize or protect such requests during certificate	SHOULD take steps to minimize or protect such requests during certificate
	validation.</t>	validation.</t>
	<t>Attacks that rely on non-ECH traffic to infer server identity in an ECH	<t>Attacks that rely on non-ECH traffic to infer server identity in an ECH
	connection are out of scope for this document. For example, a client that	connection are out of scope for this document. For example, a client that
	connects to a particular host prior to ECH deployment may later resume a	connects to a particular host prior to ECH deployment may later resume a
	connection to that same host after ECH deployment. An adversary that observes	connection to that same host after ECH deployment. An adversary that observes
	this can deduce that the ECH-enabled connection was made to a host that the	this can deduce that the ECH-enabled connection was made to a host that the
	client previously connected to and which is within the same anonymity set.</t>	client previously connected to and which is within the same anonymity set.</t>
	</section>	</section>
	<section anchor="cookies">	<section anchor="cookies">
	<name>Cookies</name>	<name>Cookies</name>
	<t><xref section="4.2.2" sectionFormat="of"/> defines a cookie value that servers may send in	<t><xref section="4.2.2" sectionFormat="of"/> defines a cookie value that servers may send in

	HelloRetryRequest for clients to echo in the secondClientHello. While ECH	HelloRetryRequest for clients to echo in the second<tt>ClientHello</tt>. While
	encrypts the cookie in the secondClientHelloInner, the backendserver's	ECH
	HelloRetryRequest isunencrypted.This means differences in cookies between	encrypts the cookie in the second<tt>ClientHelloInner</tt>, the backendserver'
		s
		HelloRetryRequest isunencrypted. This means differences in cookies between
	backend servers, such as lengths or cleartext components, may leak information	backend servers, such as lengths or cleartext components, may leak information
	about the server identity.</t>	about the server identity.</t>
	<t>Backend servers in an anonymity set SHOULD NOT reveal information in the cookie	<t>Backend servers in an anonymity set SHOULD NOT reveal information in the cookie
	which identifies the server. This may be done by handling HelloRetryRequest	which identifies the server. This may be done by handling HelloRetryRequest
	statefully, thus not sending cookies, or by using the same cookie construction	statefully, thus not sending cookies, or by using the same cookie construction
	for all backend servers.</t>	for all backend servers.</t>
	<t>Note that, if the cookie includes a key name, analogous to <xref section="4" sectionFormat="of"/>, this may leak information if different backend servers issue	<t>Note that, if the cookie includes a key name, analogous to <xref section="4" sectionFormat="of"/>, this may leak information if different backend servers issue
	cookies with different key names at the time of the connection. In particular,	cookies with different key names at the time of the connection. In particular,

	if the deployment operates inSplit Mode, the backend servers may not share	if the deployment operates insplit mode, the backend servers may not share
	cookie encryption keys. Backend servers may mitigate thisby either handling	cookie encryption keys. Backend servers may mitigate this eitherby handling
	key rotation with trialdecryption, or coordinating to match key names.</t>	key rotation with trialdecryption orby coordinating to match key names.</t>
	</section>	</section>
	<section anchor="attacks-exploiting-acceptance-confirmation">	<section anchor="attacks-exploiting-acceptance-confirmation">
	<name>Attacks Exploiting Acceptance Confirmation</name>	<name>Attacks Exploiting Acceptance Confirmation</name>
	<t>To signal acceptance, the backend server overwrites 8 bytes of its	<t>To signal acceptance, the backend server overwrites 8 bytes of its

	ServerHello.random with a value derived from the ClientHelloInner.random. (See	<tt>ServerHello.random</tt> with a value derived from the <tt>ClientHelloInner.random</tt>. (See
	<xref/> for details.) This behavior increases the likelihood of the	<xref/> for details.) This behavior increases the likelihood of the

	ServerHello.random colliding with the ServerHello.random of aprevious session,	<tt>ServerHello.random</tt> colliding with the <tt>ServerHello.random</tt> of aprevious session,
	potentially reducing the overall security of the protocol. However, the	potentially reducing the overall security of the protocol. However, the
	remaining 24 bytes provide enough entropy to ensure this is not a practical	remaining 24 bytes provide enough entropy to ensure this is not a practical
	avenue of attack.</t>	avenue of attack.</t>
	<t>On the other hand, the probability that two 8-byte strings are the same is	<t>On the other hand, the probability that two 8-byte strings are the same is
	non-negligible. This poses a modest operational risk. Suppose the client-facing	non-negligible. This poses a modest operational risk. Suppose the client-facing
	server terminates the connection (i.e., ECH is rejected or bypassed): if the	server terminates the connection (i.e., ECH is rejected or bypassed): if the

	last 8 bytes of itsServerHello.random coincide with the confirmation signal,	last 8 bytes of its<tt>ServerHello.random</tt> coincide with the confirmation signal,
	then the client will incorrectly presume acceptance and proceed as if the	then the client will incorrectly presume acceptance and proceed as if the
	backend server terminated the connection. However, the probability of a false	backend server terminated the connection. However, the probability of a false
	positive occurring for a given connection is only 1 in 2^64. This value is	positive occurring for a given connection is only 1 in 2^64. This value is
	smaller than the probability of network connection failures in practice.</t>	smaller than the probability of network connection failures in practice.</t>

	<t>Note that the same bytes of theServerHello.random are used to implement	<t>Note that the same bytes of the<tt>ServerHello.random</tt> are used to implement
	downgrade protection for TLS 1.3 (see <xref section="4.1.3" sectionFormat="comma"/>). These	downgrade protection for TLS 1.3 (see <xref section="4.1.3" sectionFormat="comma"/>). These
	mechanisms do not interfere because the backend server only signals ECH	mechanisms do not interfere because the backend server only signals ECH
	acceptance in TLS 1.3 or higher.</t>	acceptance in TLS 1.3 or higher.</t>
	</section>	</section>
	<section anchor="comparison-against-criteria">	<section anchor="comparison-against-criteria">
	<name>Comparison Against Criteria</name>	<name>Comparison Against Criteria</name>
	<t><xref/> lists several requirements for SNI encryption.	<t><xref/> lists several requirements for SNI encryption.

	In this section, we re-iterate these requirements and assess the ECH design	In this section, we reiterate these requirements and assess the ECH design
	against them.</t>	against them.</t>
	<section anchor="mitigate-cut-and-paste-attacks">	<section anchor="mitigate-cut-and-paste-attacks">
	<name>Mitigate Cut-and-Paste Attacks</name>	<name>Mitigate Cut-and-Paste Attacks</name>

	<t>Since servers process eitherClientHelloInner orClientHelloOuter,	<t>Since servers process either<tt>ClientHelloInner</tt> or<tt>Clien
	and because	tHelloOuter</tt>, and because
	ClientHelloInner.random is encrypted, it is not possible for anattacker to "cut	<tt>ClientHelloInner</tt>.random is encrypted, it is not possible for anattacke
		r to "cut
	and paste" the ECH value in a different Client Hello and learn information from	and paste" the ECH value in a different Client Hello and learn information from

	ClientHelloInner.</t>	<tt>ClientHelloInner</tt>.</t>
	</section>	</section>
	<section anchor="avoid-widely-shared-secrets">	<section anchor="avoid-widely-shared-secrets">
	<name>Avoid Widely Shared Secrets</name>	<name>Avoid Widely Shared Secrets</name>
	<t>This design depends upon DNS as a vehicle for semi-static public key	<t>This design depends upon DNS as a vehicle for semi-static public key
	distribution. Server operators may partition their private keys	distribution. Server operators may partition their private keys
	however they see fit provided each server behind an IP address has the	however they see fit provided each server behind an IP address has the
	corresponding private key to decrypt a key. Thus, when one ECH key is	corresponding private key to decrypt a key. Thus, when one ECH key is
	provided, sharing is optimally bound by the number of hosts that share	provided, sharing is optimally bound by the number of hosts that share
	an IP address. Server operators may further limit sharing of private	an IP address. Server operators may further limit sharing of private

	keys by publishing different DNS records containingECHConfig values	keys by publishing different DNS records containing<tt>ECHConfig</tt> values
	with different public keys using a short TTL.</t>	with different public keys using a short TTL.</t>
	</section>	</section>
	<section anchor="sni-based-denial-of-service-attacks">	<section anchor="sni-based-denial-of-service-attacks">
	<name>SNI-Based Denial-of-Service Attacks</name>	<name>SNI-Based Denial-of-Service Attacks</name>

	<t>This design requires servers to decryptClientHello messages with ECHClientHello	<t>This design requires servers to decrypt<tt>ClientHello</tt> messages with <tt>ECHClientHello</tt>
	extensions carrying valid digests. Thus, it is possible for an attacker to force	extensions carrying valid digests. Thus, it is possible for an attacker to force
	decryption operations on the server. This attack is bound by the number of valid	decryption operations on the server. This attack is bound by the number of valid
	transport connections an attacker can open.</t>	transport connections an attacker can open.</t>
	</section>	</section>
	<section anchor="dont-stick-out">	<section anchor="dont-stick-out">
	<name>Do Not Stick Out</name>	<name>Do Not Stick Out</name>
	<t>As a means of reducing the impact of network ossification, <xref target="RFC8744"/>	<t>As a means of reducing the impact of network ossification, <xref target="RFC8744"/>
	recommends SNI-protection mechanisms be designed in such a way that network	recommends SNI-protection mechanisms be designed in such a way that network
	operators do not differentiate connections using the mechanism from connections	operators do not differentiate connections using the mechanism from connections
	not using the mechanism. To that end, ECH is designed to resemble a standard	not using the mechanism. To that end, ECH is designed to resemble a standard

	skipping to change at line 1637 ¶	skipping to change at line 1666 ¶
	(<xref/>) without changing the security properties of the handshake. The	(<xref/>) without changing the security properties of the handshake. The
	underlying theory is that if GREASE ECH is deployable without triggering	underlying theory is that if GREASE ECH is deployable without triggering
	middlebox misbehavior, and real ECH looks enough like GREASE ECH, then ECH	middlebox misbehavior, and real ECH looks enough like GREASE ECH, then ECH
	should be deployable as well. Thus, the strategy for mitigating network	should be deployable as well. Thus, the strategy for mitigating network
	ossification is to deploy GREASE ECH widely enough to disincentivize	ossification is to deploy GREASE ECH widely enough to disincentivize
	differential treatment of the real ECH protocol by the network.</t>	differential treatment of the real ECH protocol by the network.</t>
	<t>Ensuring that networks do not differentiate between real ECH and GREASE ECH may	<t>Ensuring that networks do not differentiate between real ECH and GREASE ECH may
	not be feasible for all implementations. While most middleboxes will not treat	not be feasible for all implementations. While most middleboxes will not treat
	them differently, some operators may wish to block real ECH usage but allow	them differently, some operators may wish to block real ECH usage but allow
	GREASE ECH. This specification aims to provide a baseline security level that	GREASE ECH. This specification aims to provide a baseline security level that

	most deployments can achieve easily, while providing implementations enough	most deployments can achieve easily while providing implementations enough
	flexibility to achieve stronger security where possible. Minimally, real ECH is	flexibility to achieve stronger security where possible. Minimally, real ECH is
	designed to be indifferentiable from GREASE ECH for passive adversaries with	designed to be indifferentiable from GREASE ECH for passive adversaries with
	following capabilities:</t>	following capabilities:</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>

	<t>The attacker does not know theECHConfigList used by the server.</t>	<t>The attacker does not know the<tt>ECHConfigList</tt> used by the server.</t>
	</li>	</li>
	<li>	<li>
	<t>The attacker keeps per-connection state only. In particular, it does not	<t>The attacker keeps per-connection state only. In particular, it does not
	track endpoints across connections.</t>	track endpoints across connections.</t>
	</li>	</li>
	</ol>	</ol>
	<t>Moreover, real ECH and GREASE ECH are designed so that the following features	<t>Moreover, real ECH and GREASE ECH are designed so that the following features
	do not noticeably vary to the attacker, i.e., they are not distinguishers:</t>	do not noticeably vary to the attacker, i.e., they are not distinguishers:</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>
	<t>the code points of extensions negotiated in the clear, and their order;</t>	<t>the code points of extensions negotiated in the clear, and their order;</t>

	skipping to change at line 1686 ¶	skipping to change at line 1715 ¶
	<t>HRR issuance, which may depend on ECH acceptance.</t>	<t>HRR issuance, which may depend on ECH acceptance.</t>
	</li>	</li>
	</ol>	</ol>
	<t>These can be addressed with more sophisticated implementations, but some	<t>These can be addressed with more sophisticated implementations, but some
	mitigations require coordination between the client and server, and even	mitigations require coordination between the client and server, and even
	across different client and server implementations. These mitigations are	across different client and server implementations. These mitigations are
	out-of-scope for this specification.</t>	out-of-scope for this specification.</t>
	</section>	</section>
	<section anchor="maintain-forward-secrecy">	<section anchor="maintain-forward-secrecy">
	<name>Maintain Forward Secrecy</name>	<name>Maintain Forward Secrecy</name>

	<t>This design does not provide forward secrecy for the innerClientHello	<t>This design does not provide forward secrecy for the inner<tt>ClientHello</tt>
	because the server's ECH key is static. However, the window of	because the server's ECH key is static. However, the window of
	exposure is bound by the key lifetime. It is RECOMMENDED that servers	exposure is bound by the key lifetime. It is RECOMMENDED that servers
	rotate keys regularly.</t>	rotate keys regularly.</t>
	</section>	</section>
	<section anchor="enable-multi-party-security-contexts">	<section anchor="enable-multi-party-security-contexts">
	<name>Enable Multi-party Security Contexts</name>	<name>Enable Multi-party Security Contexts</name>

	<t>This design permits servers operating inSplit Mode to forward connections	<t>This design permits servers operating insplit mode to forward connections
	directly to backend origin servers. The client authenticates the identity of	directly to backend origin servers. The client authenticates the identity of
	the backend origin server, thereby allowing the backend origin server	the backend origin server, thereby allowing the backend origin server
	to hide behind the client-facing server without the client-facing	to hide behind the client-facing server without the client-facing
	server decrypting and reencrypting the connection.</t>	server decrypting and reencrypting the connection.</t>
	<t>Conversely, if the DNS records used for configuration are	<t>Conversely, if the DNS records used for configuration are
	authenticated, e.g., via DNSSEC,	authenticated, e.g., via DNSSEC,

	spoofing a client-facing server operating inSplit Mode is not	spoofing a client-facing server operating insplit mode is not
	possible. See <xref/> for more details regarding plaintext	possible. See <xref/> for more details regarding plaintext
	DNS.</t>	DNS.</t>

	<t>Authenticating theECHConfig structure naturally authenticates theincluded	<t>Authenticating the<tt>ECHConfig</tt> structure naturally authenticates theincluded
	public name. This also authenticates any retry signals from the client-facing	public name. This also authenticates any retry signals from the client-facing
	server because the client validates the server certificate against the public	server because the client validates the server certificate against the public
	name before retrying.</t>	name before retrying.</t>
	</section>	</section>
	<section anchor="support-multiple-protocols">	<section anchor="support-multiple-protocols">
	<name>Support Multiple Protocols</name>	<name>Support Multiple Protocols</name>
	<t>This design has no impact on application layer protocol negotiation. It may	<t>This design has no impact on application layer protocol negotiation. It may
	affect connection routing, server certificate selection, and client certificate	affect connection routing, server certificate selection, and client certificate
	verification. Thus, it is compatible with multiple application and transport	verification. Thus, it is compatible with multiple application and transport

	protocols. By encrypting the entireClientHello, this design additionally	protocols. By encrypting the entire<tt>ClientHello</tt>, this design additionally
	supports encrypting the ALPN extension.</t>	supports encrypting the ALPN extension.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="padding-policy">	<section anchor="padding-policy">
	<name>Padding Policy</name>	<name>Padding Policy</name>

	<t>Variations in the length of theClientHelloInner ciphertext could leak	<t>Variations in the length of the<tt>ClientHelloInner</tt> ciphertext could leak
	information about the corresponding plaintext. <xref/> describes a	information about the corresponding plaintext. <xref/> describes a
	RECOMMENDED padding mechanism for clients aimed at reducing potential	RECOMMENDED padding mechanism for clients aimed at reducing potential
	information leakage.</t>	information leakage.</t>
	</section>	</section>
	<section anchor="active-attack-mitigations">	<section anchor="active-attack-mitigations">
	<name>Active Attack Mitigations</name>	<name>Active Attack Mitigations</name>
	<t>This section describes the rationale for ECH properties and mechanics as	<t>This section describes the rationale for ECH properties and mechanics as
	defenses against active attacks. In all the attacks below, the attacker is	defenses against active attacks. In all the attacks below, the attacker is
	on-path between the target client and server. The goal of the attacker is to	on-path between the target client and server. The goal of the attacker is to

	learn private information about the innerClientHello, such as the true SNI	learn private information about the inner<tt>ClientHello</tt>, such as the true SNI
	value.</t>	value.</t>
	<section anchor="flow-client-reaction">	<section anchor="flow-client-reaction">
	<name>Client Reaction Attack Mitigation</name>	<name>Client Reaction Attack Mitigation</name>
	<t>This attack uses the client's reaction to an incorrect certificate as an oracle.	<t>This attack uses the client's reaction to an incorrect certificate as an oracle.

	The attacker intercepts a legitimateClientHello and replies with a ServerHello,	The attacker intercepts a legitimate<tt>ClientHello</tt> and replies with a ServerHello,
	Certificate, CertificateVerify, and Finished messages, wherein the Certificate	Certificate, CertificateVerify, and Finished messages, wherein the Certificate
	message contains a "test" certificate for the domain name it wishes to query. If	message contains a "test" certificate for the domain name it wishes to query. If
	the client decrypted the Certificate and failed verification (or leaked	the client decrypted the Certificate and failed verification (or leaked
	information about its verification process by a timing side channel), the	information about its verification process by a timing side channel), the
	attacker learns that its test certificate name was incorrect. As an example,	attacker learns that its test certificate name was incorrect. As an example,

	suppose the client's SNI value in its innerClientHello is "example.com," and	suppose the client's SNI value in its inner<tt>ClientHello</tt> is "example.com," and
	the attacker replied with a Certificate for "test.com". If the client produces a	the attacker replied with a Certificate for "test.com". If the client produces a
	verification failure alert because of the mismatch faster than it would due to	verification failure alert because of the mismatch faster than it would due to
	the Certificate signature validation, information about the name leaks. Note	the Certificate signature validation, information about the name leaks. Note
	that the attacker can also withhold the CertificateVerify message. In that	that the attacker can also withhold the CertificateVerify message. In that
	scenario, a client which first verifies the Certificate would then respond	scenario, a client which first verifies the Certificate would then respond
	similarly and leak the same information.</t>	similarly and leak the same information.</t>
	<figure anchor="flow-diagram-client-reaction">	<figure anchor="flow-diagram-client-reaction">

	<name>Clientreaction attack</name>	<name>ClientReaction Attack</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	Client Attacker Server	Client Attacker Server
	ClientHello	ClientHello
	+ key_share	+ key_share
	+ ech ------> (intercept) -----> X (drop)	+ ech ------> (intercept) -----> X (drop)

	ServerHello	ServerHello
	+ key_share	+ key_share
	{EncryptedExtensions}	{EncryptedExtensions}
	{CertificateRequest*}	{CertificateRequest*}
	{Certificate*}	{Certificate*}
	{CertificateVerify*}	{CertificateVerify*}
	<------	<------
	Alert	Alert
	------>	------>
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>ClientHelloInner.random prevents this attack. In particular, since theattacker	<t><tt>ClientHelloInner.random</tt> prevents this attack: because theattacker
	does not have access to this value, it cannot produce the right transcript and	does not have access to this value, it cannot produce the right transcript and
	handshake keys needed for encrypting the Certificate message. Thus, the client	handshake keys needed for encrypting the Certificate message. Thus, the client
	will fail to decrypt the Certificate and abort the connection.</t>	will fail to decrypt the Certificate and abort the connection.</t>
	</section>	</section>
	<section anchor="flow-hrr-hijack">	<section anchor="flow-hrr-hijack">
	<name>HelloRetryRequest Hijack Mitigation</name>	<name>HelloRetryRequest Hijack Mitigation</name>
	<t>This attack aims to exploit server HRR state management to recover information	<t>This attack aims to exploit server HRR state management to recover information

	about a legitimateClientHello using its own attacker-controlledClientHello.	about a legitimate<tt>ClientHello</tt> using its own attacker-controlled<tt>Cl
	To begin, the attacker intercepts and forwards a legitimateClientHello with an	ientHello</tt>.
		To begin, the attacker intercepts and forwards a legitimate<tt>ClientHello</tt>
		with an
	"encrypted_client_hello" (ech) extension to the server, which triggers a	"encrypted_client_hello" (ech) extension to the server, which triggers a
	legitimate HelloRetryRequest in return. Rather than forward the retry to the	legitimate HelloRetryRequest in return. Rather than forward the retry to the

	client, the attacker attempts to generate its ownClientHello inresponse based	client, the attacker attempts to generate its own<tt>ClientHello</tt> inrespon
	on the contents of the firstClientHello and HelloRetryRequest exchange with the	se based
		on the contents of the first<tt>ClientHello</tt> and HelloRetryRequest exchange
		with the
	result that the server encrypts the Certificate to the attacker. If the server	result that the server encrypts the Certificate to the attacker. If the server

	used the SNI from the firstClientHello and the key share from thesecond	used the SNI from the first<tt>ClientHello</tt> and the key share from theseco
	(attacker-controlled)ClientHello, the Certificate produced would leak the	nd
		(attacker-controlled)<tt>ClientHello</tt>, the Certificate produced would leak
		the
	client's chosen SNI to the attacker.</t>	client's chosen SNI to the attacker.</t>
	<figure anchor="flow-diagram-hrr-hijack">	<figure anchor="flow-diagram-hrr-hijack">

	<name>HelloRetryRequesthijack attack</name>	<name>HelloRetryRequestHijack Attack</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	Client Attacker Server	Client Attacker Server
	ClientHello	ClientHello
	+ key_share	+ key_share
	+ ech ------> (forward) ------->	+ ech ------> (forward) ------->
	HelloRetryRequest	HelloRetryRequest
	+ key_share	+ key_share
	(intercept) <-------	(intercept) <-------

	ClientHello	ClientHello

	skipping to change at line 1809 ¶	skipping to change at line 1838 ¶
	+ key_share	+ key_share
	{EncryptedExtensions}	{EncryptedExtensions}
	{CertificateRequest*}	{CertificateRequest*}
	{Certificate*}	{Certificate*}
	{CertificateVerify*}	{CertificateVerify*}
	{Finished}	{Finished}
	<-------	<-------
	(process server flight)	(process server flight)
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>This attack is mitigated by using the same HPKE context for bothClientHello	<t>This attack is mitigated by using the same HPKE context for both<tt>ClientHello</tt>
	messages. The attacker does not possess the context's keys, so it cannot	messages. The attacker does not possess the context's keys, so it cannot

	generate a valid encryption of the second innerClientHello.</t>	generate a valid encryption of the second inner<tt>ClientHello</tt>.</t>
	<t>If the attacker could manipulate the secondClientHello, it mightb	<t>If the attacker could manipulate the second<tt>ClientHello</tt>, i
	e possible	t mightbe possible
	for the server to act as an oracle if it required parameters from the first	for the server to act as an oracle if it required parameters from the first

	ClientHello to match that of the secondClientHello. Forexample, imagine the	<tt>ClientHello</tt> to match that of the second<tt>ClientHello</tt>. Forexamp
	client's original SNI value in the innerClientHello is "example.com", and the	le, imagine the
	attacker's hijacked SNI value in its innerClientHello is "test.com". A server	client's original SNI value in the inner<tt>ClientHello</tt> is "example.com",
		and the
		attacker's hijacked SNI value in its inner<tt>ClientHello</tt> is "test.com". A
		server
	which checks these for equality and changes behavior based on the result can be	which checks these for equality and changes behavior based on the result can be
	used as an oracle to learn the client's SNI.</t>	used as an oracle to learn the client's SNI.</t>
	</section>	</section>
	<section anchor="flow-clienthello-malleability">	<section anchor="flow-clienthello-malleability">
	<name>ClientHello Malleability Mitigation</name>	<name>ClientHello Malleability Mitigation</name>
	<t>This attack aims to leak information about secret parts of the encrypted	<t>This attack aims to leak information about secret parts of the encrypted

	ClientHello by adding attacker-controlled parameters and observing theserver's	<tt>ClientHello</tt> by adding attacker-controlled parameters and observing theserver's
	response. In particular, the compression mechanism described in	response. In particular, the compression mechanism described in
	<xref/> references parts of a potentially attacker-controlled	<xref/> references parts of a potentially attacker-controlled

	ClientHelloOuter to constructClientHelloInner, or a buggyserver may	<tt>ClientHelloOuter</tt> to construct<tt>ClientHelloInner</tt>, or a buggyser
	incorrectly apply parameters fromClientHelloOuter to thehandshake.</t>	ver may
		incorrectly apply parameters from<tt>ClientHelloOuter</tt> to thehandshake.</t
		>
	<t>To begin, the attacker first interacts with a server to obtain a resumption	<t>To begin, the attacker first interacts with a server to obtain a resumption
	ticket for a given test domain, such as "example.com". Later, upon receipt of a	ticket for a given test domain, such as "example.com". Later, upon receipt of a

	ClientHelloOuter, it modifies it such that the server will process the	<tt>ClientHelloOuter</tt>, it modifies it such that the server will process the
	resumption ticket withClientHelloInner. If the server only acceptsresumption	resumption ticket with<tt>ClientHelloInner</tt>. If the server only acceptsres
		umption
	PSKs that match the server name, it will fail the PSK binder check with an	PSKs that match the server name, it will fail the PSK binder check with an

	alert whenClientHelloInner is for "example.com" but silently ignorethe PSK	alert when<tt>ClientHelloInner</tt> is for "example.com" but silently ignoreth
	and continue whenClientHelloInner is for any other name. Thisintroduces an	e PSK
		and continue when<tt>ClientHelloInner</tt> is for any other name. Thisintroduc
		es an
	oracle for testing encrypted SNI values.</t>	oracle for testing encrypted SNI values.</t>
	<figure anchor="tls-clienthello-malleability">	<figure anchor="tls-clienthello-malleability">

	<name>Messageflow for malleable ClientHello</name>	<name>MessageFlow for Malleable ClientHello</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	Client Attacker Server	Client Attacker Server

	handshake and ticket	handshake and ticket
	for "example.com"	for "example.com"
	<-------->	<-------->

	ClientHello	ClientHello
	+ key_share	+ key_share
	+ ech	+ ech

	skipping to change at line 1869 ¶	skipping to change at line 1898 ¶
	-or-	-or-
	ServerHello	ServerHello
	...	...
	Finished	Finished
	<--------	<--------
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	<t>This attack may be generalized to any parameter which the server varies by	<t>This attack may be generalized to any parameter which the server varies by
	server name, such as ALPN preferences.</t>	server name, such as ALPN preferences.</t>
	<t>ECH mitigates this attack by only negotiating TLS parameters from	<t>ECH mitigates this attack by only negotiating TLS parameters from

	ClientHelloInner and authenticating all inputs to theClientHelloInner	<tt>ClientHelloInner</tt> and authenticating all inputs to the<tt>ClientHelloIn
	(EncodedClientHelloInner andClientHelloOuter) with the HPKEAEAD. See	ner</tt>
		(<tt>EncodedClientHelloInner</tt> and<tt>ClientHelloOuter</tt>) with the HPKEA
		EAD. See
	<xref/>. The decompression process in <xref target="encoding-inner"/>	<xref/>. The decompression process in <xref target="encoding-inner"/>
	forbids "encrypted_client_hello" in OuterExtensions. This ensures the	forbids "encrypted_client_hello" in OuterExtensions. This ensures the

	unauthenticated portion ofClientHelloOuter is not incorporated into	unauthenticated portion of<tt>ClientHelloOuter</tt> is not incorporated into
	ClientHelloInner.	<tt>ClientHelloInner</tt>. An earlier iteration of this specification only
	An earlier iteration of this specification only
	encrypted and authenticated the "server_name" extension, which left the overall	encrypted and authenticated the "server_name" extension, which left the overall

	ClientHello vulnerable to an analogue of this attack.</t>	<tt>ClientHello</tt> vulnerable to an analogue of this attack.</t>
	</section>	</section>
	<section anchor="decompression-amp">	<section anchor="decompression-amp">
	<name>ClientHelloInner Packet Amplification Mitigation</name>	<name>ClientHelloInner Packet Amplification Mitigation</name>
	<t>Client-facing servers must decompress EncodedClientHelloInners. A malicious	<t>Client-facing servers must decompress EncodedClientHelloInners. A malicious
	attacker may craft a packet which takes excessive resources to decompress	attacker may craft a packet which takes excessive resources to decompress
	or may be much larger than the incoming packet:</t>	or may be much larger than the incoming packet:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>If looking up aClientHelloOuter extension takes time linear in the number of	<t>If looking up a<tt>ClientHelloOuter</tt> extension takes time linear in the number of
	extensions, the overall decoding process would take O(M*N) time, where	extensions, the overall decoding process would take O(M*N) time, where

	M is the number of extensions inClientHelloOuter and N is the	M is the number of extensions in<tt>ClientHelloOuter</tt> and N is the
	size of OuterExtensions.</t>	size of OuterExtensions.</t>
	</li>	</li>
	<li>	<li>

	<t>If the sameClientHelloOuter extension can be copied multiple times,	<t>If the same<tt>ClientHelloOuter</tt> extension can be copied multiple times,
	an attacker could cause the client-facing server to construct a large	an attacker could cause the client-facing server to construct a large

	ClientHelloInner by including a large extension inClientHelloOuter,	<tt>ClientHelloInner</tt> by including a large extension in<tt>ClientHelloOuter
	of lengthL, and an OuterExtensions list referencing N copies of that	</tt>
		of lengthL and an OuterExtensions list referencing N copies of that
	extension. The client-facing server would then use O(N*L) memory in	extension. The client-facing server would then use O(N*L) memory in

	response to O(N+L) bandwidth from the client. Insplit-mode, an	response to O(N+L) bandwidth from the client. Insplit mode, an
	O(N*L) sized packet would then be transmitted to the	O(N*L)-sized packet would then be transmitted to the
	backend server.</t>	backend server.</t>
	</li>	</li>
	</ul>	</ul>
	<t>ECH mitigates this attack by requiring that OuterExtensions be referenced in	<t>ECH mitigates this attack by requiring that OuterExtensions be referenced in
	order, that duplicate references be rejected, and by recommending that	order, that duplicate references be rejected, and by recommending that
	client-facing servers use a linear scan to perform decompression. These	client-facing servers use a linear scan to perform decompression. These
	requirements are detailed in <xref/>.</t>	requirements are detailed in <xref/>.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	<section anchor="iana-considerations">	<section anchor="iana-considerations">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>
	<section anchor="update-of-the-tls-extensiontype-registry">	<section anchor="update-of-the-tls-extensiontype-registry">
	<name>Update of the TLS ExtensionType Registry</name>	<name>Update of the TLS ExtensionType Registry</name>

	<t>IANAis requested to create the following entries in the existingreg	<t>IANAhas created the following entries in the existing
	istry for	"TLS ExtensionTypeValues" registry (defined in <xref/>):</t>
	ExtensionType (defined in <xref/>):</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>

	<t>encrypted_client_hello(0xfe0d), with "TLS 1.3" column values setto	<t>encrypted_client_hello (0xfe0d), with "TLS 1.3" column values setto
	"CH, HRR, EE", "DTLS-Only" column set to "N", and "Recommended" column set	"CH, HRR, EE", "DTLS-Only" column set to "N", and "Recommended" column set

	to "Yes".</t>	to "Y".</t>
	</li>	</li>
	<li>	<li>

	<t>ech_outer_extensions(0xfd00), with the "TLS 1.3" column valuesse	<t>ech_outer_extensions (0xfd00), with the "TLS 1.3" column valuess
	t to "CH",	et to "CH",
	"DTLS-Only" column set to "N", "Recommended" column set to"Yes", and the	"DTLS-Only" column set to "N", "Recommended" column set to"Y", and the
	"Comment" column set to "Only appears in inner CH."</t>	"Comment" column set to "Only appears in inner CH."</t>
	</li>	</li>
	</ol>	</ol>
	</section>	</section>
	<section anchor="alerts">	<section anchor="alerts">
	<name>Update of the TLS Alert Registry</name>	<name>Update of the TLS Alert Registry</name>

	<t>IANAis requested to create an entry,ech_required(121) in theexisti	<t>IANAhas created an entry,ech_required (121) in theexisting "TLS
	ng registry	Alerts" registry (defined in <xref/>), with the "DTLS-OK"colum
	for Alerts (defined in <xref/>), with the "DTLS-OK"column set	n
	to	set to "Y".</t>
	"Y".</t>
	</section>	</section>
	<section anchor="config-extensions-iana">	<section anchor="config-extensions-iana">
	<name>ECH Configuration Extension Registry</name>	<name>ECH Configuration Extension Registry</name>

	<t>IANAis requested to create a new"ECHConfig Extension" registry in a	<t>IANAhas created a new"TLS ECHConfig Extension" registry in a new
	new	"TLS Encrypted Client Hello (ECH) Configuration Extensions"registry group. New
	"TLS Encrypted Client Hello (ECH) Configuration Extensions"page. New	registrationswill list the following attributes:</t>
	registrationsneed to list the following attributes:</t>
	<dl spacing="compact">	<dl spacing="compact">
	<dt>Value:</dt>	<dt>Value:</dt>
	<dd>	<dd>
	<t>The two-byte identifier for the ECHConfigExtension, i.e., the	<t>The two-byte identifier for the ECHConfigExtension, i.e., the
	ECHConfigExtensionType</t>	ECHConfigExtensionType</t>
	</dd>	</dd>
	<dt>Extension Name:</dt>	<dt>Extension Name:</dt>
	<dd>	<dd>
	<t>Name of the ECHConfigExtension</t>	<t>Name of the ECHConfigExtension</t>
	</dd>	</dd>
	<dt>Recommended:</dt>	<dt>Recommended:</dt>
	<dd>	<dd>

	<t>A "Y" or "N" value indicating if theextension is TLS WG recommends that the	<t>A "Y" or "N" value indicating if theTLS Working Group recommends that the
	extension be supported. This column is assigned a value of "N" unless	extension be supported. This column is assigned a value of "N" unless

	explicitly requested. Adding a valuewith a valueof "Y" requires Standards	explicitly requested. Adding a value of "Y" requires Standards
	Action <xref/>.</t>	Action <xref/>.</t>
	</dd>	</dd>
	<dt>Reference:</dt>	<dt>Reference:</dt>
	<dd>	<dd>
	<t>The specification where the ECHConfigExtension is defined</t>	<t>The specification where the ECHConfigExtension is defined</t>
	</dd>	</dd>
	<dt>Notes:</dt>	<dt>Notes:</dt>
	<dd>	<dd>
	<t>Any notes associated with the entry</t>	<t>Any notes associated with the entry</t>
	</dd>	</dd>
	</dl>	</dl>

	<t>New entries in the "ECHConfig Extension" registry are subject tothe	<t>New entries in the "TLS ECHConfig Extension" registry are subject tothe
	Specification Required registration policy (<xref section="4.6" sectionFormat="comma"/>), with the policies described in <xref section="17" sectionFormat="comma"/>. IANA	Specification Required registration policy (<xref section="4.6" sectionFormat="comma"/>), with the policies described in <xref section="17" sectionFormat="comma"/>. IANA

	[shall add/has added] the following note to the TLS ECHConfig Extension	has added the following note to the "TLS ECHConfig Extension"
	registry:</t>	registry:</t>
	<t>Note: The role of the designated expert is described in RFC 8447.	<t>Note: The role of the designated expert is described in RFC 8447.
	The designated expert <xref/> ensures that the specification is	The designated expert <xref/> ensures that the specification is
	publicly available. It is sufficient to have an Internet-Draft	publicly available. It is sufficient to have an Internet-Draft
	(that is posted and never published as an RFC) or a document from	(that is posted and never published as an RFC) or a document from
	another standards body, industry consortium, university site, etc.	another standards body, industry consortium, university site, etc.

	The expert may provide more indepth reviews, but their approval	The expert may provide more in-depth reviews, but their approval
	should not be taken as an endorsement of the extension.</t>	should not be taken as an endorsement of the extension.</t>
	<t>This document defines several Reserved values for ECH configuration extensions	<t>This document defines several Reserved values for ECH configuration extensions
	to be used for "greasing" as described in <xref/>.</t>	to be used for "greasing" as described in <xref/>.</t>

	<t>The initial contents for this registry consists of multiple reserved values,	<t>The initial contents for this registry consists of multiple reserved values
	with the following attributes, which are repeated for each registration:</t>	with the following attributes, which are repeated for each registration:</t>
	<dl spacing="compact">	<dl spacing="compact">
	<dt>Value:</dt>	<dt>Value:</dt>
	<dd>	<dd>
	<t>0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0x8A8A,	<t>0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0x8A8A,
	0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, 0xFAFA</t>	0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, 0xFAFA</t>
	</dd>	</dd>
	<dt>Extension Name:</dt>	<dt>Extension Name:</dt>
	<dd>	<dd>
	<t>RESERVED</t>	<t>RESERVED</t>
	</dd>	</dd>
	<dt>Recommended:</dt>	<dt>Recommended:</dt>
	<dd>	<dd>
	<t>Y</t>	<t>Y</t>
	</dd>	</dd>
	<dt>Reference:</dt>	<dt>Reference:</dt>
	<dd>	<dd>

	<t>This document</t>	<t>RFC 9849</t>
	</dd>	</dd>
	<dt>Notes:</dt>	<dt>Notes:</dt>
	<dd>	<dd>

	<t>Grease entries.</t>	<t>GREASE entries</t>
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>

		<displayreference to="HPKE"/>
		<displayreference to="DNS-TERMS"/>
		<displayreference to="PROTECTED-SNI"/>
	<references anchor="sec-combined-references">	<references anchor="sec-combined-references">
	<name>References</name>	<name>References</name>
	<references anchor="sec-normative-references">	<references anchor="sec-normative-references">
	<name>Normative References</name>	<name>Normative References</name>

	<reference anchor="RFC2119">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<front>	119.xml"/>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	le>	918.xml"/>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<date month="March" year="1997"/>	180.xml"/>
	<abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<t>In many standards track documents several words are used to sig	446.xml"/>
	nify the requirements in the specification. These words are often capitalized. T	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	his document defines these words as they should be interpreted in IETF documents	147.xml"/>
	. This document specifies an Internet Best Current Practices for the Internet Co	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	mmunity, and requests discussion and suggestions for improvements.</t>	174.xml"/>
	</abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	</front>	460.xml"/>
	<seriesInfo name="BCP" value="14"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<seriesInfo name="RFC" value="2119"/>	525.xml"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	</reference>	890.xml"/>
	<reference anchor="RFC7918">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<front>	126.xml"/>
	<title>Transport Layer Security (TLS) False Start</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname="A. Langley" initials="A." surname="Langley"/>	447.xml"/>
	<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>	</references>
	<author fullname="B. Moeller" initials="B." surname="Moeller"/>	<references anchor="sec-informative-references">
	<date month="August" year="2016"/>	<name>Informative References</name>
	<abstract>	<reference anchor="RFCYYY1">
	Security (TLS) client implementations, dubbed "False Start". It affects only pr
	otocol timing, not on-the-wire protocol data, and can be implemented unilaterall
	y. A TLS False Start reduces handshake latency to one round trip.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7918"/>
	<seriesInfo name="DOI" value="10.17487/RFC7918"/>
	</reference>
	<reference anchor="RFC8446">
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
	e>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
	<date month="August" year="2018"/>
	<abstract>
	<t>This document specifies version 1.3 of the Transport Layer Secu
	rity (TLS) protocol. TLS allows client/server applications to communicate over t
	he Internet in a way that is designed to prevent eavesdropping, tampering, and m
	essage forgery.</t>
	<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
	77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
	plementations.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8446"/>
	<seriesInfo name="DOI" value="10.17487/RFC8446"/>
	</reference>
	<reference anchor="RFC9147">
	<front>
	<title>The Datagram Transport Layer Security (DTLS) Protocol Version
	1.3</title>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
	>
	<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
	<date month="April" year="2022"/>
	<abstract>
	<t>This document specifies version 1.3 of the Datagram Transport L
	ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
	municate over the Internet in a way that is designed to prevent eavesdropping, t
	ampering, and message forgery.</t>
	<t>The DTLS 1.3 protocol is based on the Transport Layer Security
	(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
	n of order protection / non-replayability. Datagram semantics of the underlying
	transport are preserved by the DTLS protocol.</t>
	<t>This document obsoletes RFC 6347.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9147"/>
	<seriesInfo name="DOI" value="10.17487/RFC9147"/>
	</reference>
	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying that
	only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	<reference anchor="RFC9460">
	<front>
	<title>Service Binding and Parameter Specification via the DNS (SVCB
	and HTTPS Resource Records)</title>
	<author fullname="B. Schwartz" initials="B." surname="Schwartz"/>
	<author fullname="M. Bishop" initials="M." surname="Bishop"/>
	<author fullname="E. Nygren" initials="E." surname="Nygren"/>
	<date month="November" year="2023"/>
	<abstract>
	<t>This document specifies the "SVCB" ("Service Binding") and "HTT
	PS" DNS resource record (RR) types to facilitate the lookup of information neede
	d to make connections to network services, such as for HTTP origins. SVCB record
	s allow a service to be provided from multiple alternative endpoints, each with
	associated parameters (such as transport protocol configuration), and are extens
	ible to support future uses (such as keys for encrypting the TLS ClientHello). T
	hey also enable aliasing of apex domains, which is not possible with CNAME. The
	HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics
	"). By providing more information to the client before it attempts to establish
	a connection, these records offer potential benefits to both performance and pri
	vacy.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9460"/>
	<seriesInfo name="DOI" value="10.17487/RFC9460"/>
	</reference>
	<reference anchor="ECH-IN-DNS">
	<front>	<front>
	<title>Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings</title>	<title>Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings</title>

	<author fullname="Benjamin M.Schwartz" initials="B. M." surname="Sc	<authorinitials="B." surname="Schwartz" fullname="Benjamin M.Schwa
	hwartz">	rtz">
	<organization>Meta Platforms, Inc.</organization>	<organization/>
	</author>	</author>

	<authorfullname="Mike Bishop" initials="M."surname="Bishop">	<author initials="M."surname="Bishop" fullname="Mike Bishop">
	<organization>Akamai Technologies</organization>	<organization/>
	</author>	</author>

	<authorfullname="Erik Nygren" initials="E."surname="Nygren">	<author initials="E."surname="Nygren" fullname="Erik Nygren">
	<organization>Akamai Technologies</organization>	<organization/>
	</author>	</author>

	<dateday="12" month="February" year="2025"/>	<dateyear="2025" month="December"/>
	<abstract>
	<t> To use TLS Encrypted ClientHello (ECH) the client needs to l
	earn the
	ECH configuration for a server before it attempts a connection to the
	server. This specification provides a mechanism for conveying the
	ECH configuration information via DNS, using a SVCB or HTTPS record.

	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-svcb-ech-07"/>
	</reference>
	<reference anchor="HPKE">
	<front>
	<title>Hybrid Public Key Encryption</title>
	<author fullname="R. Barnes" initials="R." surname="Barnes"/>
	<author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
	<author fullname="B. Lipp" initials="B." surname="Lipp"/>
	<author fullname="C. Wood" initials="C." surname="Wood"/>
	<date month="February" year="2022"/>
	<abstract>
	<t>This document describes a scheme for hybrid public key encrypti
	on (HPKE). This scheme provides a variant of public key encryption of arbitrary-
	sized plaintexts for a recipient public key. It also includes three authenticate
	d variants, including one that authenticates possession of a pre-shared key and
	two optional ones that authenticate possession of a key encapsulation mechanism
	(KEM) private key. HPKE works for any combination of an asymmetric KEM, key deri
	vation function (KDF), and authenticated encryption with additional data (AEAD)
	encryption function. Some authenticated variants may not be supported by all KEM
	s. We provide instantiations of the scheme using widely used and efficient primi
	tives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based ke
	y derivation function (HKDF), and SHA2.</t>
	<t>This document is a product of the Crypto Forum Research Group (
	CFRG) in the IRTF.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9180"/>
	<seriesInfo name="DOI" value="10.17487/RFC9180"/>
	</reference>
	<reference anchor="RFC6125">
	<front>
	<title>Representation and Verification of Domain-Based Application S
	ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer
	tificates in the Context of Transport Layer Security (TLS)</title>
	<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
	"/>
	<author fullname="J. Hodges" initials="J." surname="Hodges"/>
	<date month="March" year="2011"/>
	<abstract>
	<t>Many application technologies enable secure communication betwe
	en two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX
	) certificates in the context of Transport Layer Security (TLS). This document s
	pecifies procedures for representing and verifying the identity of application s
	ervices in such interactions. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6125"/>
	<seriesInfo name="DOI" value="10.17487/RFC6125"/>
	</reference>
	<reference anchor="RFC5890">
	<front>
	<title>Internationalized Domain Names for Applications (IDNA): Defin
	itions and Document Framework</title>
	<author fullname="J. Klensin" initials="J." surname="Klensin"/>
	<date month="August" year="2010"/>
	<abstract>
	<t>This document is one of a collection that, together, describe t
	he protocol and usage context for a revision of Internationalized Domain Names f
	or Applications (IDNA), superseding the earlier version. It describes the docume
	nt collection and provides definitions and other material that are common to the
	set. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5890"/>
	<seriesInfo name="DOI" value="10.17487/RFC5890"/>
	</reference>
	<reference anchor="RFC8126">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs
	</title>
	<author fullname="M. Cotton" initials="M." surname="Cotton"/>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<author fullname="T. Narten" initials="T." surname="Narten"/>
	<date month="June" year="2017"/>
	<abstract>
	<t>Many protocols make use of points of extensibility that use con
	stants to identify various protocol parameters. To ensure that the values in the
	se fields do not have conflicting uses and to promote interoperability, their al
	locations are often coordinated by a central record keeper. For IETF protocols,
	that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
	<t>To make assignments in a given registry prudently, guidance des
	cribing the conditions under which new values should be assigned, as well as whe
	n and how modifications to existing values can be made, is needed. This document
	defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Consideratio
	ns is clear and addresses the various issues that are likely in the operation of
	a registry.</t>
	<t>This is the third edition of this document; it obsoletes RFC 52
	26.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="26"/>
	<seriesInfo name="RFC" value="8126"/>
	<seriesInfo name="DOI" value="10.17487/RFC8126"/>
	</reference>
	<reference anchor="RFC8447">
	<front>
	<title>IANA Registry Updates for TLS and DTLS</title>
	<author fullname="J. Salowey" initials="J." surname="Salowey"/>
	<author fullname="S. Turner" initials="S." surname="Turner"/>
	<date month="August" year="2018"/>
	<abstract>
	<t>This document describes a number of changes to TLS and DTLS IAN
	A registries that range from adding notes to the registry all the way to changin
	g the registration policy. These changes were mostly motivated by WG review of t
	he TLS- and DTLS-related registries undertaken as part of the TLS 1.3 developmen
	t process.</t>
	<t>This document updates the following RFCs: 3749, 5077, 4680, 524
	6, 5705, 5878, 6520, and 7301.</t>
	</abstract>
	</front>	</front>

	<seriesInfo name="RFC"value="8447"/>	<seriesInfo name="RFC"value="YYY1"/>
	<seriesInfo name="DOI"value="10.17487/RFC8447"/>	<seriesInfo name="DOI"value="10.17487/RFCYYY1"/>
	</reference>	</reference>

	</references>
	<references anchor="sec-informative-references">
	<name>Informative References</name>
	<reference anchor="WHATWG-IPV4">	<reference anchor="WHATWG-IPV4">
	<front>	<front>

	<title>URLLiving Standard- IPv4 Parser</title>	<title>URL - IPv4 Parser</title>
	<author>	<author>

	<organization/>	<organization>WHATWG</organization>
	</author>	</author>
	<date year="2021" month="May"/>	<date year="2021" month="May"/>
	</front>	</front>

		<refcontent>WHATWG Living Standard</refcontent>
	</reference>	</reference>
	<reference anchor="ECH-Analysis">	<reference anchor="ECH-Analysis">
	<front>	<front>
	<title>A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello</title>	<title>A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello</title>

	<author>	<author initials="K." surname="Bhargavan">
	<organization/>	<organization>Inria</organization>
		</author>
		<author initials="V." surname="Cheval">
		<organization>Inria</organization>
		</author>
		<author initials="C." surname="Wood">
		<organization>Cloudflare</organization>
	</author>	</author>
	<date year="2022" month="November"/>	<date year="2022" month="November"/>
	</front>	</front>

		<seriesInfo name="DOI" value="10.1145/3548606.3559360"/>
		<refcontent>CCS '22: Proceedings of the 2022 ACM SIGSAC Conference on
		Computer and Communications Security, pp. 365-379</refcontent>
	</reference>	</reference>

	<reference anchor="RFC7301">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<front>	499.xml"/>
	<title>Transport Layer Security (TLS) Application-Layer Protocol Neg	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
	otiation Extension</title>	kazuho-protected-sni.xml"/>
	<author fullname="S. Friedl" initials="S." surname="Friedl"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<author fullname="A. Popov" initials="A." surname="Popov"/>	301.xml"/>
	<author fullname="A. Langley" initials="A." surname="Langley"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname="E. Stephan" initials="E." surname="Stephan"/>	484.xml"/>
	<date month="July" year="2014"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<abstract>	858.xml"/>
	<t>This document describes a Transport Layer Security (TLS) extens	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ion for application-layer protocol negotiation within the TLS handshake. For ins	094.xml"/>
	tances in which multiple application protocols are supported on the same TCP or	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	UDP port, this extension allows the application layer to negotiate which protoco	250.xml"/>
	l will be used within the TLS connection.</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	</abstract>	701.xml"/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	<seriesInfo name="RFC" value="7301"/>	986.xml"/>
	<seriesInfo name="DOI" value="10.17487/RFC7301"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	</reference>	552.xml"/>
	<reference anchor="RFC8484">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<front>	744.xml"/>
	<title>DNS Queries over HTTPS (DoH)</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>	924.xml"/>
	<author fullname="P. McManus" initials="P." surname="McManus"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	<date month="October" year="2018"/>	077.xml"/>
	<abstract>
	<t>This document defines a protocol for sending DNS queries and ge
	tting DNS responses over HTTPS. Each DNS query-response pair is mapped into an H
	TTP exchange.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8484"/>
	<seriesInfo name="DOI" value="10.17487/RFC8484"/>
	</reference>
	<reference anchor="RFC7858">
	<front>
	<title>Specification for DNS over Transport Layer Security (TLS)</ti
	tle>
	<author fullname="Z. Hu" initials="Z." surname="Hu"/>
	<author fullname="L. Zhu" initials="L." surname="Zhu"/>
	<author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
	<author fullname="A. Mankin" initials="A." surname="Mankin"/>
	<author fullname="D. Wessels" initials="D." surname="Wessels"/>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<date month="May" year="2016"/>
	<abstract>
	<t>This document describes the use of Transport Layer Security (TL
	S) to provide privacy for DNS. Encryption provided by TLS eliminates opportuniti
	es for eavesdropping and on-path tampering with DNS queries in the network, such
	as discussed in RFC 7626. In addition, this document specifies two usage profil
	es for DNS over TLS and provides advice on performance considerations to minimiz
	e overhead from using TCP and TLS with DNS.</t>
	<t>This document focuses on securing stub-to-recursive traffic, as
	per the charter of the DPRIVE Working Group. It does not prevent future applica
	tions of the protocol to recursive-to-authoritative traffic.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7858"/>
	<seriesInfo name="DOI" value="10.17487/RFC7858"/>
	</reference>
	<reference anchor="RFC8094">
	<front>
	<title>DNS over Datagram Transport Layer Security (DTLS)</title>
	<author fullname="T. Reddy" initials="T." surname="Reddy"/>
	<author fullname="D. Wing" initials="D." surname="Wing"/>
	<author fullname="P. Patil" initials="P." surname="Patil"/>
	<date month="February" year="2017"/>
	<abstract>
	<t>DNS queries and responses are visible to network elements on th
	e path between the DNS client and its server. These queries and responses can co
	ntain privacy-sensitive information, which is valuable to protect.</t>
	<t>This document proposes the use of Datagram Transport Layer Secu
	rity (DTLS) for DNS, to protect against passive listeners and certain active att
	acks. As latency is critical for DNS, this proposal also discusses mechanisms to
	reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechan
	ism runs over port 853.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8094"/>
	<seriesInfo name="DOI" value="10.17487/RFC8094"/>
	</reference>
	<reference anchor="RFC9250">
	<front>
	<title>DNS over Dedicated QUIC Connections</title>
	<author fullname="C. Huitema" initials="C." surname="Huitema"/>
	<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
	<author fullname="A. Mankin" initials="A." surname="Mankin"/>
	<date month="May" year="2022"/>
	<abstract>
	<t>This document describes the use of QUIC to provide transport co
	nfidentiality for DNS. The encryption provided by QUIC has similar properties to
	those provided by TLS, while QUIC transport eliminates the head-of-line blockin
	g issues inherent with TCP and provides more efficient packet-loss recovery than
	UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) s
	pecified in RFC 7858, and latency characteristics similar to classic DNS over UD
	P. This specification describes the use of DoQ as a general-purpose transport fo
	r DNS and includes the use of DoQ for stub to recursive, recursive to authoritat
	ive, and zone transfer scenarios.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9250"/>
	<seriesInfo name="DOI" value="10.17487/RFC9250"/>
	</reference>
	<reference anchor="RFC8701">
	<front>
	<title>Applying Generate Random Extensions And Sustain Extensibility
	(GREASE) to TLS Extensibility</title>
	<author fullname="D. Benjamin" initials="D." surname="Benjamin"/>
	<date month="January" year="2020"/>
	<abstract>
	<t>This document describes GREASE (Generate Random Extensions And
	Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS
	ecosystem. It reserves a set of TLS protocol values that may be advertised to e
	nsure peers correctly handle unknown values.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8701"/>
	<seriesInfo name="DOI" value="10.17487/RFC8701"/>
	</reference>
	<reference anchor="RFC3986">
	<front>
	<title>Uniform Resource Identifier (URI): Generic Syntax</title>
	<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
	"/>
	<author fullname="R. Fielding" initials="R." surname="Fielding"/>
	<author fullname="L. Masinter" initials="L." surname="Masinter"/>
	<date month="January" year="2005"/>
	<abstract>
	<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
	aracters that identifies an abstract or physical resource. This specification de
	fines the generic URI syntax and a process for resolving URI references that mig
	ht be in relative form, along with guidelines and security considerations for th
	e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
	et of all valid URIs, allowing an implementation to parse the common components
	of a URI reference without knowing the scheme-specific requirements of every pos
	sible identifier. This specification does not define a generative grammar for UR
	Is; that task is performed by the individual specifications of each URI scheme.
	[STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="66"/>
	<seriesInfo name="RFC" value="3986"/>
	<seriesInfo name="DOI" value="10.17487/RFC3986"/>
	</reference>
	<reference anchor="DNS-TERMS">
	<front>
	<title>DNS Terminology</title>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
	<date month="March" year="2024"/>
	<abstract>
	<t>The Domain Name System (DNS) is defined in literally dozens of
	different RFCs. The terminology used by implementers and developers of DNS proto
	cols, and by operators of DNS systems, has changed in the decades since the DNS
	was first defined. This document gives current definitions for many of the terms
	used in the DNS in a single document.</t>
	<t>This document updates RFC 2308 by clarifying the definitions of
	"forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and cla
	rifications. Comprehensive lists of changed and new definitions can be found in
	Appendices A and B.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="219"/>
	<seriesInfo name="RFC" value="9499"/>
	<seriesInfo name="DOI" value="10.17487/RFC9499"/>
	</reference>
	<reference anchor="RFC3552">
	<front>
	<title>Guidelines for Writing RFC Text on Security Considerations</t
	itle>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
	<author fullname="B. Korver" initials="B." surname="Korver"/>
	<date month="July" year="2003"/>
	<abstract>
	<t>All RFCs are required to have a Security Considerations section
	. Historically, such sections have been relatively weak. This document provides
	guidelines to RFC authors on how to write a good Security Considerations section
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="72"/>
	<seriesInfo name="RFC" value="3552"/>
	<seriesInfo name="DOI" value="10.17487/RFC3552"/>
	</reference>
	<reference anchor="RFC8744">
	<front>
	<title>Issues and Requirements for Server Name Identification (SNI)
	Encryption in TLS</title>
	<author fullname="C. Huitema" initials="C." surname="Huitema"/>
	<date month="July" year="2020"/>
	<abstract>
	<t>This document describes the general problem of encrypting the S
	erver Name Identification (SNI) TLS parameter. The proposed solutions hide a hid
	den service behind a fronting service, only disclosing the SNI of the fronting s
	ervice to external observers. This document lists known attacks against SNI encr
	yption, discusses the current "HTTP co-tenancy" solution, and presents requireme
	nts for future TLS-layer solutions.</t>
	<t>In practice, it may well be that no solution can meet every req
	uirement and that practical solutions will have to make some compromises.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8744"/>
	<seriesInfo name="DOI" value="10.17487/RFC8744"/>
	</reference>
	<reference anchor="RFC7924">
	<front>
	<title>Transport Layer Security (TLS) Cached Information Extension</
	title>
	<author fullname="S. Santesson" initials="S." surname="Santesson"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
	>
	<date month="July" year="2016"/>
	<abstract>
	<t>Transport Layer Security (TLS) handshakes often include fairly
	static information, such as the server certificate and a list of trusted certifi
	cation authorities (CAs). This information can be of considerable size, particul
	arly if the server certificate is bundled with a complete certificate chain (i.e
	., the certificates of intermediate CAs up to the root CA).</t>
	<t>This document defines an extension that allows a TLS client to
	inform a server of cached information, thereby enabling the server to omit alrea
	dy available information.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7924"/>
	<seriesInfo name="DOI" value="10.17487/RFC7924"/>
	</reference>
	<reference anchor="RFC5077">
	<front>
	<title>Transport Layer Security (TLS) Session Resumption without Ser
	ver-Side State</title>
	<author fullname="J. Salowey" initials="J." surname="Salowey"/>
	<author fullname="H. Zhou" initials="H." surname="Zhou"/>
	<author fullname="P. Eronen" initials="P." surname="Eronen"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
	>
	<date month="January" year="2008"/>
	<abstract>
	<t>This document describes a mechanism that enables the Transport
	Layer Security (TLS) server to resume sessions and avoid keeping per-client sess
	ion state. The TLS server encapsulates the session state into a ticket and forwa
	rds it to the client. The client can subsequently resume a session using the obt
	ained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5077"/>
	<seriesInfo name="DOI" value="10.17487/RFC5077"/>
	</reference>
	<reference anchor="I-D.kazuho-protected-sni">
	<front>
	<title>TLS Extensions for Protecting SNI</title>
	<author fullname="Kazuho Oku" initials="K." surname="Oku">
	</author>
	<date day="18" month="July" year="2017"/>
	<abstract>
	<t> This memo introduces TLS extensions and a DNS Resource Recor
	d Type
	that can be used to protect attackers from obtaining the value of the
	Server Name Indication extension being transmitted over a Transport
	Layer Security (TLS) version 1.3 handshake.

	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-kazuho-protected-sni-00
	"/>
	</reference>
	</references>	</references>
	</references>	</references>

	<?line 2017?>	<?line 2092?>

	<section anchor="linear-outer-extensions">	<section anchor="linear-outer-extensions">

	<name>Linear-time Outer Extension Processing</name>	<name>Linear-Time Outer Extension Processing</name>
	<t>The following procedure processes the "ech_outer_extensions" extension (see	<t>The following procedure processes the "ech_outer_extensions" extension (see
	<xref/>) in linear time, ensuring that each referenced extension	<xref/>) in linear time, ensuring that each referenced extension

	in theClientHelloOuter is included at most once:</t>	in the<tt>ClientHelloOuter</tt> is included at most once:</t>
	<ol spacing="normal" type="1"><li>	<ol spacing="normal" type="1"><li>
	<t>Let I be initialized to zero and N be set to the number of extensions	<t>Let I be initialized to zero and N be set to the number of extensions

	inClientHelloOuter.</t>	in<tt>ClientHelloOuter</tt>.</t>
	</li>	</li>
	<li>	<li>
	<t>For each extension type, E, in OuterExtensions: </t>	<t>For each extension type, E, in OuterExtensions: </t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>If E is "encrypted_client_hello", abort the connection with an	<t>If E is "encrypted_client_hello", abort the connection with an
	"illegal_parameter" alert and terminate this procedure.</t>	"illegal_parameter" alert and terminate this procedure.</t>
	</li>	</li>
	<li>	<li>
	<t>While I is less than N and the I-th extension of	<t>While I is less than N and the I-th extension of

	ClientHelloOuter does not have type E, increment I.</t>	<tt>ClientHelloOuter</tt> does not have type E, increment I.</t>
	</li>	</li>
	<li>	<li>
	<t>If I is equal to N, abort the connection with an "illegal_parameter"	<t>If I is equal to N, abort the connection with an "illegal_parameter"
	alert and terminate this procedure.</t>	alert and terminate this procedure.</t>
	</li>	</li>
	<li>	<li>

	<t>Otherwise, the I-th extension ofClientHelloOuter has type E.C	<t>Otherwise, the I-th extension of<tt>ClientHelloOuter</tt> has
	opy	type E.Copy
	it to theEncodedClientHelloInner and increment I.</t>	it to the<tt>EncodedClientHelloInner</tt> and increment I.</t>
	</li>	</li>
	</ul>	</ul>
	</li>	</li>
	</ol>	</ol>
	</section>	</section>

	<section anchor="acknowledgements">	<sectionnumbered="false"anchor="acknowledgements">
	<name>Acknowledgements</name>	<name>Acknowledgements</name>
	<t>This document draws extensively from ideas in <xref/>, but	<t>This document draws extensively from ideas in <xref/>, but
	is a much more limited mechanism because it depends on the DNS for the	is a much more limited mechanism because it depends on the DNS for the

	protection of the ECH key.Richard Barnes, Christian Huitema, Patrick McManus,	protection of the ECH key.<contact fullname="Richard Barnes"/>, <contact fullna
	Matthew Prince, Nick Sullivan, Martin Thomson, andDavid Benjamin alsoprovided	me="Christian Huitema"/>, <contact fullname="Patrick McManus"/>,
		<contact fullname="Matthew Prince"/>, <contact fullname="Nick Sullivan"/>, <cont
		act fullname="Martin Thomson"/>, and<contact fullname="David Benjamin"/> alsop
		rovided
	important ideas and contributions.</t>	important ideas and contributions.</t>
	</section>	</section>

	<section anchor="change-log">
	<name>Change Log</name>
	<ul empty="true">
	<li>
	<t><strong>RFC Editor's Note:</strong> Please remove this section prio
	r to publication of a
	final version of this document.</t>
	</li>
	</ul>
	<t>Issue and pull request numbers are listed with a leading octothorp.</t>
	<section anchor="since-draft-ietf-tls-esni-16">
	<name>Since draft-ietf-tls-esni-16</name>
	<ul spacing="normal">
	<li>
	<t>Keep-alive</t>
	</li>
	</ul>
	</section>
	<section anchor="since-draft-ietf-tls-esni-15">
	<name>Since draft-ietf-tls-esni-15</name>
	<ul spacing="normal">
	<li>
	<t>Add CCS2022 reference and summary (#539)</t>
	</li>
	</ul>
	</section>
	<section anchor="since-draft-ietf-tls-esni-14">
	<name>Since draft-ietf-tls-esni-14</name>
	<ul spacing="normal">
	<li>
	<t>Keep-alive</t>
	</li>
	</ul>
	</section>
	<section anchor="since-draft-ietf-tls-esni-13">
	<name>Since draft-ietf-tls-esni-13</name>
	<ul spacing="normal">
	<li>
	<t>Editorial improvements</t>
	</li>
	</ul>
	</section>
	<section anchor="since-draft-ietf-tls-esni-12">
	<name>Since draft-ietf-tls-esni-12</name>
	<ul spacing="normal">
	<li>
	<t>Abort on duplicate OuterExtensions (#514)</t>
	</li>
	<li>
	<t>Improve EncodedClientHelloInner definition (#503)</t>
	</li>
	<li>
	<t>Clarify retry configuration usage (#498)</t>
	</li>
	<li>
	<t>Expand on config_id generation implications (#491)</t>
	</li>
	<li>
	<t>Server-side acceptance signal extension GREASE (#481)</t>
	</li>
	<li>
	<t>Refactor overview, client implementation, and middlebox
	sections (#480, #478, #475, #508)</t>
	</li>
	<li>
	<t>Editorial iprovements (#485, #488, #490, #495, #496, #499, #500,
	#501, #504, #505, #507, #510, #511)</t>
	</li>
	</ul>
	</section>
	<section anchor="since-draft-ietf-tls-esni-11">
	<name>Since draft-ietf-tls-esni-11</name>
	<ul spacing="normal">
	<li>
	<t>Move ClientHello padding to the encoding (#443)</t>
	</li>
	<li>
	<t>Align codepoints (#464)</t>
	</li>
	<li>
	<t>Relax OuterExtensions checks for alignment with RFC8446 (#467)</t
	>
	</li>
	<li>
	<t>Clarify HRR acceptance and rejection logic (#470)</t>
	</li>
	<li>
	<t>Editorial improvements (#468, #465, #462, #461)</t>
	</li>
	</ul>
	</section>
	<section anchor="since-draft-ietf-tls-esni-10">
	<name>Since draft-ietf-tls-esni-10</name>
	<ul spacing="normal">
	<li>
	<t>Make HRR confirmation and ECH acceptance explicit (#422, #423)</t
	>
	</li>
	<li>
	<t>Relax computation of the acceptance signal (#420, #449)</t>
	</li>
	<li>
	<t>Simplify ClientHelloOuterAAD generation (#438, #442)</t>
	</li>
	<li>
	<t>Allow empty enc in ECHClientHello (#444)</t>
	</li>
	<li>
	<t>Authenticate ECHClientHello extensions position in ClientHelloOut
	erAAD (#410)</t>
	</li>
	<li>
	<t>Allow clients to send a dummy PSK and early_data in ClientHelloOu
	ter when
	applicable (#414, #415)</t>
	</li>
	<li>
	<t>Compress ECHConfigContents (#409)</t>
	</li>
	<li>
	<t>Validate ECHConfig.contents.public_name (#413, #456)</t>
	</li>
	<li>
	<t>Validate ClientHelloInner contents (#411)</t>
	</li>
	<li>
	<t>Note split-mode challenges for HRR (#418)</t>
	</li>
	<li>
	<t>Editorial improvements (#428, #432, #439, #445, #458, #455)</t>
	</li>
	</ul>
	</section>
	<section anchor="since-draft-ietf-tls-esni-09">
	<name>Since draft-ietf-tls-esni-09</name>
	<ul spacing="normal">
	<li>
	<t>Finalize HPKE dependency (#390)</t>
	</li>
	<li>
	<t>Move from client-computed to server-chosen, one-byte config
	identifier (#376, #381)</t>
	</li>
	<li>
	<t>Rename ECHConfigs to ECHConfigList (#391)</t>
	</li>
	<li>
	<t>Clarify some security and privacy properties (#385, #383)</t>
	</li>
	</ul>
	</section>
	</section>
	</back>	</back>
	<!-- ##markdown-source:	<!-- ##markdown-source:

	H4sIAAAAAAAAA8y9a3PcyJE2+r1+BZaKEyLt7h6RI81IGo93KYozYoxur6jx	H4sIAMXzlWkAA9S963IbSZIu+D+eIodlayK7AZSoS5XE6u4dilKVZKXbEVVd
	rMPrVwS70SSsbqANoEm1ZZ3ffvJalVVAk5S9H45i1xqRuBSqsrLy8uST4/HY	U9bTR0wACTJbQCYmM0EKrdHa2nmX8+O8wT7Qru1rrF8jPDIDJNU9f5ZmM10C
	dWW3KJ5m71+eZsfVtNmsumKWHS3KouqyF8ViUbv8/Lwprm68ZFZPq3wJj5k1	EpFx8fC7fz4ej11XdsviKHv/8jR7Vs2a7bor5tnJsiyqLnteLJe1y6fTpri8
	+bwbl0U3H3eLdly0VTk+eOSmeVdc1M3madZ2M+fKVfM065p12x08ePDkwYFr	9pF5PavyFQwzb/JFNy6LbjHulu24aKtyfO+hm+VdcV4326Os7eau2qymRXOU
	1+fLsm3Luuo2K3jMyfH7n1zeFPnT7PT4yF3XzceLpl6v4K5F6z4WG/jJDC6r	PX704LEr1/BfXbNpu3t37z6+e8+1m+mqbNuyrrrtGoZ88ez9j26znsMQ7ZGr
	uqKpim78HF/rXNvl1exDvqgreMamaN2qfJr9pauno6ytm64p5i3812aJ//FX	p229LOg/8ZOj7N7de9+N4WezumqLqt20NFrhYML3Xd4U+VF2+uzEXdXNx/Om
	5/J1d1k3T102dhn/Kav2aXY8yd4V7bRuFrn+nD/uuCmnvV/VzUVelf/IOxg8	3qzh62XrPhZb+GR+5Fzb5dX8Q76sKxhsW7RuXR5lf+nq2Shr66ZrikUL/7Vd
	jmhWrAr4n6rTC4plXi6eZsXH5r+abr6cTOulS1/5yyR783Edv+2X/B/ry9r+	4X/81bl8013UzZHLxhn+8aqfNeUse1e0s7pZ5i7jv7KCqTybDD6vm3NYVDUv
	PH7VT3nbLTbJWz7STfXH9X9d4A8GX/Z6kp2uF4vyKq/iN74upx97v4pfeoSr	1gX8v6rTz4tVXi6PsuJj869Nt1hNZvXK6WsWm+WSXqUPZ9nRUfb//M//mf3f
	X180+epykx3VVbtedGV1kb18eZSMpCqnl/UibyetPPD3KBU3DOtokh1Ost/q	/9f/+f/+r/8RPs7bWQkL+Dn/++aizt583ESv/TFvu+W298aP9Gz9cfOv5/hB
	ehaP6uiyKduuXl0WTXpBMrZFvZ7NFyA2yVCm+fV/XRb5CgZ6XnbtBCTGOVfV	9GJe3+ty9jE7hTmUl3kVre/1ZPA5vegEqaQ+b/L1xTY7gaPZLLuyOs9evjzp
	zRLuvCpAALJ3Px0d7O8/kf/8/sn+46cgptXcXvPbi8P3v/08Pnn7p4f4z0x2	vb0qZxf1Mm8nrYzze6SenVM5uWjKtqvXF0WTHU+yX+t6Hk3oZNL/mOZzvF4v
	zs6v715mL8srnIZTFMC8mWXj7OTt1cPsbd60RbNDV+fNRdE9zS67btU+/eab	i96bZ/nVv14U+RrmNS27dlIVnXOuqptV3pWXtNfvfjy5d3j4WP7z+8eHj4Bi
	dbOYtKtiOrm+zLvriwl8yzf3pnU1LVawgVZXD8cruhnvncH2eZq9yjfZwYOD	6L/hP+/KaczLdr3Mgbafv/35mXNltegN8dtvvx3ys3LZ/iQzeVLXXdvBJuEc
	ffjJ8dGL8WGVLzZt2dJY/GAOs9PN8rxegKTqBVk9z942sATTTQYfRPt4f/Jt	kveLrld2VXYX2dPXp9lp0VyWsyJ7UlZz+EnLg+bNedEdZRddt26Pvv326upq
	dl12l1s29A4/Mxny9fX1ZNpO6k+TfDpZf/xmVdSrRfENfPkU7pxML4urfPHN	0ixm42JednUzgfV/i3P6Fj7DmdBv2qIpixY/VpKCeR5l/vsse/rmxVF2eHdy
	an2+KNtvnh39Np5O24ODyWo2p8fxV7yur4rlOawlfMoB/Zy3oXxHFqTCb41n	+P2DR99/K6ug7/jePS1mBV5jvIAP6XN/Nehv7GmSzuUJEMrs4ipvur/7L9pN
	lzCQ3MgkLjzutabMh2/60wTEBkdz5zuOYsni641EOTcej7P8vO2afAri8/4S	w4c6+MbTe/akqP6Wr8oqezUYoPcGeOBJ2V7U6+H4vc/D6K/Kj0X8bW9QuL+v
	JhbU3nqJkzYDpdCU50Wb5dmymF6CVLZLeHD2vsmrdgW6J3uZb+CjT4vpuim7	t+dNUQ0H7X0eBgVu8FG/ha9/fX78/tefxi/e/vkB7Y3ZJnkZUSg/5gKR7P3y
	TbYLq7CHy+EKXgEUn1wWgdYAHtS2+UWRrUGdNPA7EIYr+A+a32kGSnDCg1qW	7iWQ/ou3lw+yt3kDJ7bnEqe9aZaTdl3MJlcXeXd1Tsf9DTDDWbEGRry+fDBe
	s9kCRngP9WFTz9ZT3A/Z53sl/vOLc4cLmOD1xaVf+c+f/wOk/PHDh999+ZLJ	04+dP7lX+RYPjQ4TuBo82wGlybnt8Tyyl+Ul0uQpcse8me/hSp6dPB8fV/ly
	+9tsWbcdykp3WWTwBbP2Mv9YjOArpov1DIcHv3AyiGnRdOW8RL0+wp83RQaz	25ZtRM97x9npdjWtl8AG9YGsXmRvG7jQs20GF4Ko+3Byn2k5LUb2dpLzrJ3U
	BEOEX+aL7DrftPj515egBbK8yuoKxBnELe+6fPoRHwCruSjypspWKJpdkfnd	nyb5bLL5+O26qOEufwvTm8EvJ7OL4jJffrveTJdl++2Tk1/Hs1l7795kPV8Y
	BmPPz+t1RwOBHVEV9EGT7D38e7XI4bOKTx1MJY3kNSgJB2oXx4K37p6+PtnL	an1dX3pqvbfjBniKP3zw8Nv7Dx88+u7ud5P7Dx8+vv/dXXpksFnZ3snJaXbn
	4IKiwvMERzEwqXAO8NhgDB9behNLOxxloDQq2ih5dgFbvzJjgNlos1XRXOYr	3r0jWGo9Kwq6lLjy7qKgV2XHJ6+y0xc/nR6fIBtcFEAUcH/rCv61Wm86mBFs
	vonmrMVXoZaw3wBfN+9g7Qq/wVAceAEmqfygIoDpJPmpimu6zn/CCCZrsYAH	MP5jtQFOCFwDeCVc89mmKbvtKFuvJ9n97x6O73//eO/mS/YzXIEL2L7csGOV
	bDl8d0Eb7OEq5F0GF9bXbTal38MQa11eHG3ZRFMBv8RPwHfxqk54VKum7uBz	N02Zp3/05wkwVdzDW//iJGawwvGX9Wa+WILEVQ754PHjPocEHjZ+/+zdq1N8
	+QNhNmH9ZlmNi5yt4DdVV8JbNuarYeCLGZ6sa1xsus8drlYLXRIW/bfw2Hpa	5sX46YRlz3jd1F0xA3oYg8LQ/9Hbd2/ePzt5/+zp+PT1C+fG43GWT5FtzoBf
	L7LXYArAM3i1Dl++fb3nQGF0IJX/ibr32wf7X77A/q3Hixrlayaja1lhwWKA	/+Ff4J9/AdZWzP8KolY2uAVBfQD/PAfSRTL+i7mEfx3B6QB9NvrwnZaIJIPP
	TsNh0Aw1FQ3mqmzL8wV9jIMr5uXFuqE3tDT68+Iyvyrrxkpzu17hxoTn48P9	9GpM3Hs4QLyAMLPLcg6E2hSgeFwWbdbVWZ6t8/OCSXnvJcjU7BfST+bZ4T0d
	pdOSTpp2XXYF/cRd1tf4SZusKWArwyUwcfCYeolP4Zk2IgLzgDKAQp9XdbVZ	4+HexLnXsCx4W97J9dbh2mwPRNuq7LK2ytfAfrp2T8imbLIl371W7l6LJOLg
	4m5vi26S7b6G2XO0TOUSFCeuPI1xLMs/zeDILKeFmcogx2DwFA2+EWeBRcmp	q6bIYHuBci+LJl9m/RGyRVOv/BJ4dkiHS9Scumxa4KD0zL27zq80+xEuZ/Ep
	MMMvs1mJc4AXzlHT5jBEGGdTgLEyGy9oBWBT4elU4gtg/+H3wPENF7pZOZ/D	X62XpE0F9rB/HYvhl4/9y789nD6aPpo9fFhMH0yL+ePF4f3Hs8f5g/uPF9PD
	Hh6e0zB5Be4G3BnbVqQ//ZO97FfSYqRYQLqCegSjssgXrQiuziRcopNZXTj4	2eF08fDhd99Nvzt8nGROB879WsAW46igFWWk7uF045PCvccVrWpYD1yRBlkH
	hDyDg7Arp2vQw/RimCGU0asSJmSUnYOimNUwB1XdySNla4uqmjf1kkQyWo4M	bAYqi3rrhI/2+NcIBgFqmvGYfLR+g1Y17Op5UdGu4jfyGj2A63fiYERXOJ8T
	PhMWMMdFTvXM82K1qDe0MXGhRIxb/QQ3L/JuLRpvVrbTddvy9v78eeZvBRl2	peWDk90zQzq/FCCOE17AkYuoM6hyKjpGKVEwytKMeoTnZ8fAoxxlf/hacfEn
	DnYmfhAODX4NtkexmMPazmGt6WPh82S30SBKtBtxgKKFw7ZU9ZSJelqCLQBz	mOD8IPvxtxcjVWGy/Z52317OpuNidnEAW7lcAoHxucE1mAP7kp3+t1cvcSPP
	V8Pi+HXqLhvS8rxVcZarYhFkyQXVKVP9/PVp9vd1gQKBEqTPkXk7eZvlsxnI	ccVvfp7A9f2Tg9sFxwpGw2aFJwj3YdaUU7gVebaC8fKqbFfAarL3TV61a9DC
	SFu0k+xFfY26feSCPsPb/Wq2/jX44xof8OL9+7ensqsfP3z88MuXUeZ/CZLy	s5f5Flil8sVsH6TJAYoVV7Ak4a0/M0rTGQzVtnhNN6BmA5tFjg+0kpGkmGVg
	zXNUPbLrHz96DGeRXPzgCV2Mm8/f8H9+PTmS3z85ePTgyxcnMmDHgLJpdB+Z	AUyYmazK+RyUQ/cN8LyuqeebGXLh7PM3Jf7zi3PHS+C5m/MLL8M+f/4X2JNH
	U2AE4EMWaBWD1iZxAAsQfQo8+leq2XHzL/NqYxRim12ifl+ikQsbVia/dbDL	Dx589+VLJjNomSqFCmEN8/Yi/1iMYB2z5WYu2+FkErOi6coFMvwC2VH/al/l
	aHng6DHTNGErC46yuikv4LpolVgyCtJFJbwKBL5eLuGcCKKsmz4nOQbjD4Xj	2xY34OoCtGMgLxAYcC5ArnnX5bOPOABw+GWRNxWwFBCyyL5U74S559N609FE
	02YC5zr/rqiuyqauULzakVfPTUGjIhmHw3SZNxvYxii3JZws5QXs5gysp3KR	4GirghY0yZCnwSWAZRWfOtIlYaDXoLM4MEdE+GT7wGQPgCGAmKNrBbNIbitY
	k5TUWX2unwf/mBW8EwpzvN9vvSgGIQ76MhxkkSUBqxv/+Mn+w+91HeFUg0X0	RTw7mMXHlt7FkhuMQdCvKxL6eXYOanBlZjFCNrsumgu4HOEuo+VWosZsVwHr
	mlYEHK/HeacbV3JAtBO0ZcC5uMIhqF5+XszLqqR/O9oQYABl6Aa22c6rX0/f	W3RweoVXFpAk+AgmfRpCmoYNJRqqiit6Lixili+X8Pu+2uFYvd4HxeaA2TQ8
	74z47+z1G/rvd8cgMe+On+N/n744fPnS/4decfriza8v4fdO/ivcefTm1avj	V1+12Yy+Jl4vbxfWHG+FXGp8F5/rJMtoWiLPeIWwocQhajznbF2jAlHCi7Zh
	18/5Zvhplvzo1eGfd1hgdt68fX/y5vXhyx2cFdIO/lBH9dDR2uO2a1ZNgZMH	2Q5mvpyjobnB8+bfoc0ipzJm+gclAwzTepm9BmsaxuADO3759vUBCI22c58/
	66vWIs3ks6O32f5DmDFxQWgX0KTufw+7wF1fFiKcdQVKmf9Jx1G+WoEBhc8A	/+9op9y/e/jlC4j1erysZ3QheXot8zw0leFp3DbcItBncTKXZVtOl7waeGJR
	dQ0KfVV2Oe53eEMLZ1aVoVkGThX8EvUyKCE+c0HuCtkH9FZcvRFapvTbb0lx	nm8a0Udw9tPiIr8s68YSdLtZ4+2E8YUJ86OzksyzdlN2BQuvi/oKl7RFKbqu
	3cveXKGqLa5dMAro9C5p/CBVBR2ENVhDbL3B+FjLX6NpsaoX9QUqlnKxWKPR	4RHYORimXuEovNmGRmAfkAiQ7vOqrrYrvPJt0U2yfRSojk6qRIGFR88bJOc/
	3JHog3Uycqyerwuya2AdwLyHX76qZ8UOT+opCG/HPyCrr0VDa4bHMWpcO3so	y8CaBAvJbGWgAjD4C+JLuAtMS06pGb4EjQP3gEUJ8LEcpgjzRKnUzMdLOgG4
	s/MajR460kWDw/jvZe/9GJz7f+GPN+31z+/HQ39+37vun+kP+KeD1x08eLD/	V8hmS3wBXEFcD1i28KCblwti7ak9NZtX4HXAq7HrRHBS8fZPDrJfiJERbwHq
	9Pmzx0+f7sOf7dcNPU+Muj/QMP6I14lpPCk+5WgwoI/4Fc/rX8eug38cCMLX	CjyygeHyZSu0qzsJj+hmVudO9BXgN7MNqGf0YrQhRRWBOU2BV8xr2IOq7mRI
	jC/9yV3nT/+wwW5+vctfPP4pn5L3A0v/DL0D+PuoXp6DTprt8dJ9fprda0lM	udvCrUhpQEqPjiODZcIBonYxYDVPQdrWW7qZeFBes5UluEWRdxtheqDozTZt
	xigI7O3+aCVHl3uzAw4P6EvzK9aUqmZRgPHfrKO9kYDmPggj/ka0PGy1GgQP	y/f78+e5/ynQsHNwN3FBODX4Guz0YrmAs13AWdNiYXly22gSJbpUcILCiOVe
	zg7HVhRsgrrkQ7vsSCmzQeNfgUos2BH0IjUyQPY3oqB5GJO+UA7O5+/vOtWD	kj7H/CkT/rQCPQf2rka5pefUXTTE6Pmq4i5XxTLQkgvcU7YajfL/2JApgRSk
	q/bPuy7ooOz+c+BXx/CH747EddufP97p3QNyqe++dQv8e9/97815FguweKTm	48i+vXiLagHQSFu0k+x5fYXsfeQCQ8Of+9Ns/Wvw4xoHeP7+/dvTjG/1oweP
	j4qziH6QZVRwsSh7ldeTZP+bviCjYTkszOpVizBP3LsczUJ+BNpDKtMDFwc5	Hnz5Msr8l0Ap3z7F2yq3/tHDRyCO5OG7j+lhvHz+B//tlxcn8v3jew/vfvni
	t+/jQ8jKMJgJ8samWKDHHxvS2Tl8vT4lGiE637VLLPBk95BrQQ+kOYb9tkTz	hAbsHJA2Dfsj1QBsAxxkiU6iteiZVdGhTw0tgrWydrz8q7zaZoEjttkFMvgV
	I6+6xWbkrWPrCzjvBoC/Atb5FDyp1n+FN37F9LDjLDY1f5r11x2+zhorPiYy	+n/gwsrmtw5uGR0PSB+zTRM2GUGa1U15Ds9Fp8SUURAvKlHlIhUYBEUgZb30
	oXXBH7HphYuh7o2e/iM8367h8INrwLXSYWDgLh03Gs34ux3+0vGcpYmnik9E	OdExKDJIHJ+2ExDt/F1RXZZNXSF5tSPPnpuCZkU0DvJ0lTdbuMZIt6jIledw
	46rrrKHC4onbORcpkzvIX2jZPfFmqjgWZaIZ0Xsq+zIWjcSRBx29g0/i1eWm	mzMwqsplTlRSZ/VUlwf/mBd8Ewoj4cGoUFIMRBz4ZZBkkTIBpxt//Pjwwfd6
	LacSDAAnDfUczM1pUYBh0Uqka0zu4awQfxDMG5S4ZR18pzjgg9YmeDLgYpFm	jiDW4BA9pxUCx+dx3+mHaxEQ7QTVGTA4L3EKypefFouyKunfji4E6EAZukHB
	XdDb0QUvOxIzEpfajHKUDc0bS2s8arYL0igKB0MoiOLc4eDDYPbQdm5pcKDI	HHn1y+l7UCrpf7PXb+i/3z0Dinn37Cn+9+nz45cv/X/oE6fP3/zyEr538l/h
	OcR5yYcW/TByeiW25Eq0XDUAg18ZQnc0urxt62lJp8Oy6HL02sH59KcPGUnw	lydvXr169vop/xg+zXofvTr+bY8JZu/N2/cv3rw+frmHu0LcwUt1ZA8dnT1e
	Gvhct255ZpZgS+nrWeCSN69bidTxW/wbXLKf4g9EK8sIr5uhsS37svd590lp	u2bdFLh5cL6qMtJOPjl5mx0+gB0Tdx3dAtrUw+/hFriri0KIs66AKfM/SRzl
	LPNOnO9iUVzQsqBa4U9kQxNcC/A6WnTixSF4+N0DjO2AhDj4CW6Gk9djuO3H	6zXoUDgGsGtg6Ouyy/G+wxtAdb+qMtTMJtkxfIl8GZgQy1ygu0LuAb0VT2+E
	k/Hzic8atVfT8zE4dSIrGh1pRUpQGHqDajFdBJ7YFQYmxR0//dPRM5po9kRF	6il9e58Y1zfZm0tktcWV6Cp6OEgJMH+gqoIEYQ3qECtwMD/m8legWNTrelmf
	402yN+Qgw7hLuHpj/UeM9JLDtqpbcoYn2U8wAjl87N4g3470zOAcgY4s9Ae0	I2MB5XqD9m5HpA8Kysgxe74qSLOBcwCrH758Vc+LPd7UUyDejj8gxa9FTQsN
	KX4Duz0EOa5zjc61Xc6LmYvfyfuBVqsFQz0R4RFsA4ywgEW9xhBd7nW3EeYR	T+K4dveQZhc16j0k0oWDw/y/yd77OTj3f8CftSvo7/fj1N/vB8/9Z/8D/jT5
	65yGLXTREub3J6D5JKog4+kuOcxpHsuiestTnfn9m3XHghS9i36Kj+5Iqsuq	3L27dw+Pnj55dHR0CH+7n0uNJ96kP9A0/oTPiXY8EQsX7Z2vGG/4HFsPfjgg
	Ahmr1212lS/WBUmSC5FEH+5inw92z47Xxx94rB8uKUERLnW7nz/7i8Yi3XTR	hK+ZX/+T2+6f/rHObr7e5xWPf2TTFo/+CRoI7FOaAk+aH/DRfT7KvmmJTMZI
	ly97Guad5g2FOXAmiiEFIHPyU0mxr2ilYXhwTva+SZSQVy3v/T+yDg6J1vtD	COy6+6OlHD3u7R7YPMgv+St8mjmlslkkYPw382ivJKC+D8SI3wiXh6tWA+GB
	8PPgouQcJHzq3D4caXPUav7YEg+bpKmmEDn+dFb4AK6NCZcYdESphJ1H+SV7	7HCsRcElqEsW2mVHTJkVGv8KUT5Fj6AXqZIBtL8VBs3TmAyJMrmfv7/tVidP
	QrH8DC0O7HL4v2Qlm+JvHG/DV0/CyNo1naHzNap4GUc7MBBYxOscjYkhQaPB	7T9ve6BJ2v3PxFfP4I9/HZHrrr8/3erdCbrUd994Bf65df9ze57FBCxGqflT
	8Vylsixro5+RnLJDo8WHYYRkimkyP2D366rGcOa04DRcWJf7rURt23j3+qgH	chbSD7SMDC4mZc/yBpRM36QJGRXLNDGrYS3EPHHvclQLeQjUh5SmEw8HOrfv
	KtqC9AHMOE43PNBd+1fAS3cxqsdXw7NRL435d3k1LUDESFLhLJ8WxawNZov/	YyFkaRjUBHljUyzR6I8V6WwKq9dRohmi9V27ngbeuz3ewcX6HNy3FaofedUt
	DgdXg96BexebSUZ6QCIqPO3FbCS2hCZTYx8CB7VuKXZzvnHmG8hnMWF2Pj9O	tyOvHVtbwHkzAOwV0M5nYEm1fhVe+RXVw86z2Na8NGuwO3ydVVa8W2RC54If
	YBMXOTwTXyILW1eaGDC3w2Q2RQf6j4a8Xo27eowpuliR4efrOFkn74msa6jp	seqFh6HmjUr/Eco38iyR10yngVGI/rxRacbv9nil4wVTE28VS0T5NW6R7hoy
	os4XKOfyUZRyaNdke+RRYBx/peZDGSJoSVwW1TiYVGWLU7EGzUhfTtEK3FBw	LN64valQmfyC7IWWzROvpophUfY4I1pP5ZDGopk4sqCjd7AkXl9s23ImzgAw
	Ma7WBIyVpqhFI2K8Y72YwUxflgWpZBgIjQu/Dc+MfD4XCccIX/GJH5+pkYLr	0pDPwd6cFgUoFq24u8ZkHs4LsQdBvUGKI6+l2E6xzwe1TbBkwMSi+Szp7WiC
	t8KToyBrz6dp2JTBJ8WGCx9sidXiH8YCwQlXupcCKsN2x1E02Z/voXhFC/CF	lx2RWVf4M+VZjrLUvjG1xrNmvSAdpSQ3inPHycFg91B3bmlywMg5XnPBQos+
	A3BgALTZi7e/HLPBHgwJY17AkYpX/Eiht8d40tJC9Q4njuHgCa9uqVFQZ3A5	jIxecS65EjVX9cHgKoP3jr2ubVvPSpIOq6LL0WoH49NLH1KS4DWwXLdpeWdW
	D+os4+MA1tJ6q/Uq//u6yF6sPhZvaRi/FJs/7E8mB/93/7vx/h9/oIvWYGzv	oEvp65ngem/etOq7pLf4N7jefYoXOMkih5Sbo7It93KwvDvENFZ5J8Z3sSzO
	f0cX/VIsT2Y/xD7YN99wPI/PaRlv78bZ/F+78RDkP73z1hv9Zx+ranu/WRU/	6ViQrfASWdEE0wKsjhaNeDEIHnx3F307QCGOVE/0zApFqA+kFVrAIx+8usWk
	JDdqlGwfxMPR7TxH2WfvF/qhZx9n8w/l7IfoNzy2LIe//O++0G9ON0uwApty	CLC3LtEDKUb36Z9PntB2sr0pfG2SvSEzGGZXwtNbayVimIfMsnXdkskbxRHs
	ekQZqFNMQP2w5R045seyqL1X0ISDbCx7v/HrJQL0AQQovmJoEJIS+8ApsT88	DSALjrhJcieAExb6AZH+r6CdB1fGVa5uuLbL+chysS6Z6ulMWlDHe4Q6AmKn
	lKV++Ec7engoT9+2IQ/Pb4Z4nzAEkS3UZH94kIjUl4FHbHtZNCLcJh+mMrh4	nJCu2aAjLvccOnLhjZi3NKyJCzewT7wAFtecsf9A5tRdsEfTDM1EeePIzj7x
	Bpf5p3K5Xn5ApMmHRVFddJe9wchU4SUk5o8e/fGHG77K2DA3fQL8L2bM2ptW	BqN/Z+yVHX6OL+iIisuqApqqN212mS83BVGOCw5T795iGw9uy57nvx94xh8u
	GKRSAuY/pD9Px9qCEQ737/rnT+TOPfPMDEwK8CMefJoXD2ZP+2MhM40HpTd8	KLoaHnX7nz/7h8ZCzfTQly8H6ted5Q25NXBHgscitTc/luTtik4dJgiSMbEu
	Scf9AysCtnZUPQT7LtYlnBgGW0cG456SeSj/0kMDFRpbAn2HBlUVqL7ZxN7o	ja0oO3nv/5F1IBhabwPB58EsydkxeOTcIYixBXIyL6rEqibaqskzjp/OC++3
	JIRHjm2uYYdZIXELfB7aprebjhNRxW1GmYPyokLtjieE0YIufCadlLkfP0Xh	DQtHqkDjbU0pRBROt1KJqSl9SHC3NRQVzrQp/sZeNnz5JMyt3ZDkxJyArc6k
	Z7W13UBR8tLIp/I/MO0MmrbDxKtYhBWGImh+xM7hK/lHclq7OE3MB+jHcsUJ	TUwFjvKKInxpsqMJ8n71qVvOSJfSk66p+VLuQUsyfR2m7H5Z1+jGnBUcRwpn
	MTLD+Nd0nnL2KKNU+jUhMmh8bEU6AhPxrGmyOV4GERvnVAjgCw4r3QQ4eFxv	c6cVb20b32fv7UAGWxCHgF3HLYcB3ZV/Bbx0H715/DSMjaGiMX+XV7MCSI0o
	SkBTXFQvyxjwlklOTB7KfhPlQ/R94qBK7IXvJZ+tMrOtohifPTiTN15zqwAG	ds2R8zaoK34dDp6uKYK73E4y4gziSeGNL+Yj0SE0vyi2HXBSm5Z8NtOtM2sg
	FYCflZ1FCiJ6EDgKG7UhE1E04A7junuLj05nczLvovuCAg7/2NmbZJj+Z6OI	WyW41zOWGy/gShc5jIkvkaOtK40JmJ/DZjZFBxyRprxZj7t6TCHkiLXh8nWe
	52V48Gdeq5/x8NVMJlMvBD8woAPeam9WYLoGtJqKY11dgMtJyDpc97zvXs6z	uHZYsNC7upjO63yJtC6LomhDu2kkZGwc4viVqg1l8Jz1/LHI2DExqMWt2ACv
	j1V9XZELgIJN/xrx1iSfjaA75wUn0evsH0VTw8Wd7lTOuy5X4HBkq3xGUAuw	pJWTlwIvFTyMpzUBFbkpauGR6OfYLOew0xdlQUwaJkLzwrWhFMkXC6Fx9OwV
	IeU/1V5Wn0d82TwEL2loPGhw1RHdw3nU4hMa2DwO2SvlfJQVk4vJyAWDnw2l	n3j4TJUTPL81ypKCtDwfn2EVBkeKFRYWaD1txQ/GBMFZI/RbcqSk9Y2TaLM/
	63IxmyIOr6L70VCezeBuxNbwj2QWY4iGc0bZy5RhUEOna1v4BKZtUkxGfl3g	f4PkFR3AF3a8geBvs+fbaVPOs7fMqX8Gwf4sKBX7mLl1wHp80C+M1kGSFlO+
	cYRuLWYY+1ivyKwejBMEJyfMHbg6oMqXZRsCCJrUHrk0fZha5/ANTzM2WxFX	0LPzPiXH2KmDIl/tVMO9zuBxnu1ZxlIDDtmar/U6/49NkT1ffyx4hjDBPxxO
	N+YPGuMXiAUrcBaPt9DcJLvcsMTlTGOydjrgweFko01EmsYqj3AGinMvwh5i	Jvf+++F348M//UAPbUD7PvyOHvq5WL2Y/xAbZd9+yw4+Fukw3wwnPPjlfPEP
	Jhi9QueYwCkuigxSZjO7KCr69zYw3CQ7BiN/4JXukhLnB+Ma5qIjs4KTpsGi	/vIYrkb/pzf/0q/8mTK+99t18UPvl+o5OwTScZyeQ9uUffa2op989nG++FDO
	4FGNgnI0P8UVgOMCDhGJlIVH4QRdUIwbZqnF5RXtIFIocoHPIj2v2AJUmY5Q	f4i+4cllOfyP/+4LfXO6XYFm2JSzE4pKnWJQ6ocd78A5P5JzHbyC9hwIYzX4
	O5MbpijOaFKCFLcLL/04zHjwu27QXbcoQa9ZaPnAmxqTWudUP1zV6NEpuDdS	xh+ZUM8HoJ74idQkJEz2gcNkf3ggp/3gT3b2MChv364pp/c3w9TZMAUhL+Ry
	aKjJbhJZ8EkN4qJkIF7hI5B0DT7WLmbwWSaZ/9ZyBh/pApIS5XRos7V0OspL	f7jbo6oviSF2vSyaEd6RDzOZXLyDq/xTudqsPmA+3IdlUZ13F4PJyFbhI0Tp
	VClNUMUv+dPeqy5GQxe8rnwFjjXL2CsPPtr95fjVnv102neE7xLc0Vmwkc/u	Dx/+6YdrVmX0nOuWcML5We11JwxUKU70H/qf9+fagmIOv9/340/klwdmzAxU
	ZChkqaHgeAJYmOF9WwyG8B47eHOQyDzHzrsH9vWDWC4y2FX1y27lmXn+E+2O	DrAt7n5aFHfnR8O5ZDM/Kf3Bl/68f2BewNqQcoigA8bshIPFoAvJZI7cEWmR
	w+PD53YSVnnZBPQgYsQw8IzLF1CqrvdC0TdNkS9M2DasX4u4NrQZBIqFGhxG	JhMG+ROyM1YThlYOsivgi/OJ/aETvx5Zu7n6IuaFODNwPFRib9YvJ8Kn24zC
	I/I8GHD3gdyWgK+whatpoQZjAvBDpanqEW4vQYP9g4EWvAda67365Qr/9RLG	CeV5hawfxYfhhC6sk8Ro7udPrvl5bZU7YJZ8NrpW/hcGo4HddhiOFZ2xQgcF
	4r0aNNWDhXsWXTS41yjKJ3GBQWFoCWBXTGF6SBRIJeCnrCiuhR8mW0piNB7p	7ZBoQfwkfySy3MXBYxavH8s1h8lITeOvSdpyTIkC7KjxsEtgK3qmo3QZ3jYN
	i+aehAQVgqSWdKtzQaglxSe1qMXlF5iPWWLcquW0RxxoOPFr3maf75kduDUF	QZtzMOuFJSgh4CKOK70JOH88dIpMk8NUn8s4STyTYJmMy6YWBUr0lWK5ilOG
	wvoVD/1aTAQzl6zMRooHtDtJ49MgyK18Jz5EIDcyjSza6wYhiAufXylm/sHw	f0tmXmVmoPQYyyAyP6575kYqDHyA1pWdRWwiGglMiq1qmT16NHkfxqj3OiFK
	8msQOIKxNcVVaSLIdMighdB2mG4juA2K7ShrEZjuZRAvmcLhEaU/3XpFMdDs	aCuc99HQQSqHf+wdTLKQaccbk579meftZzx/VaRJGQxuEXT1gIWb2BfYsbME
	/fuXuIxkIOEWArVkZ2HMswCibaHeHQqbBkYpwYNhwJaTqvpjAU6bXSPTgNsL	ezvzdFlX55hth98hAeRDu3SRfazqq4psBSRx+pckJZKJR8k904Jj7HX296Kp
	LPwcDvtV0ZBtieOlc3CbpZFhcogEzxFWbXgh4AXwTVd1yfbSQE5PH8fL4LxG	4eFO7yyHZSl7NFtL2hmomvKfqlareSRGcB58mzQ1njbY+Jj/w2HW4hPq4TwP
	5bgbjMiaoSFUnxXR6SugRhkFgVxh1ziDlsoY+nOxwfPiqsxNRLLFnAoMxRtP	uTTlYpQVk/PJyAW7gPWpq3I5h+Oc02gU+4bXw68x94Y/kq2MMzicM3xf9wyd
	ddaANNdLSieiO+vsIOD4LdDeht+uQXQXUeQcrHLCmfcmBFO1nUZRqwIXB2OW	Hrpfu9wrsG+TYjLypwPjUdFIMUffCOedpT0MwRgKmwcmEbD1VdkG14MGvUeu
	+CkDX5hPmxpWL6Bh4zyoQc2dh6mawFkaW9EkanAFggcD4A9xUf7Jbvhkk/2z	H17sa/GwiKOM1VvMxh3zisa4AtF0Jd3F52No7JJNdDjjcq4+W7sfMHCQcnyX
	ABuMYnH9IfqAJnyrkRrHgjTJ/sSXWeRhU9ABUs4lnS/bx6wiTo+IvoKqwpIO	iOkwP+8LRPEGCM0Hdwu6t9CSpuwVF7kOKfQpmY7XpcxNsmdgDyRe6i4otn5v
	aI/jkKbxysOYKhyxjJ0nm9kBTanWrmI4mxpOhjnb6QTyyxduvq6m/J8UVIVB	XMN2dKRlcFw1KBg8r1HglOZTPAQQHiBSxJkWhsI9Oic3OGxUiycsbEIoUUgD
	ggOgoQB2xXDoeQhmgqL9/LkfQf3CWrJsmhrV3WcN4j2cHKAy8wBGg3K94QPI	xyKmr+kHyDwdJfZMrtmkOOhJMVS8Mnz647DpwUS7hondwA4Nj+EzBNtrTDye
	tuSv0M3Ix/PJ4evDCN7nyD7vzc+4zKsc3zYQmTXTxIeX84EOb6jzlc0aE9Lw	EwLgwUZlqaTHEXNDrnYd4YIFa/IySs7YK7yfkp7BYeMTDUbMJPMLLuewUhfS
	uqhWoH1qH/Hq8M+CEsShoMjQ4cN5247MYIVMoqDQGQbqlKF8Bno+Z2wojoIM	LpFeU5euJXkpr1HuNEGOj0qwXl+avVhU+Roscaa1Vz5Laf/nZ68O7OrpAlIi
	a1HY5k3noD8+TrJfq0X5sUiGNKIsuDfUUe2dI5754oJP6SXWTHU1bMtzby6l	mCQonQXF+exWykPWVx4c7wETNbxvhxJhXxTN34gW2e3Y4Pd5gCkHmItUeS8K
	803xHQ7v4A6gWbksEexMp+k55gDYH90HgY2MtRD5CI8kY4jQ/pfF9CMJ3roK	5O76/XlakAsSN+fHTcUWz/7PT39khn28QcdiV3LCnrFOaYHHQSY+xfu0f/zs
	AFc/IuPykEOMBtHQdbbeBLGS5CeM/NGD43BiNHaRWXEGoz2EdZmvyaqwNTBo	+Gm0qeu8bELmIianoccbKSLkyLrE7IWVNUW+ZP7mWZgf66JGrUSywFA6wMrk
	QpVkVlPFQDVfsBHUS0TKUXpeaKiFpzXsb/sRartz9qZcoKKa5muZoRof6CJT	niR9/d673FLaLbAGKnpYJLzRxI+V82JNBjDHv3OOB9+t1trJngDCf72EuXjj
	HVMlLWNPKcjE9ggbGeyfY7q0pK14XneXDHm4AkdmRbvUxSnXEi3GyBnAZWB8	CS2CoEifRQ8l7zA5G8U1kSSvlnL7ihlsDxEXsRpcyjqkcvM9FTeRzzNGnVI8
	hcDw1piN7kqu/UD7F1xhUvCOwcxtttsKxAS15ljrE9BFQlQe2hRN3nZ87PVf	k5r9pAp7q3tBCVOaGtWigJAvMBS0QtdZyxGX2Nfxwp96m33+xlzqndEX5tuo
	yNFDB/ZZNJmsk9aYScR9WYUqFVgjd4+0ztaQYvDrPt/bkowGi7KGeUMwEDx/	UNSifkTLFTYpuYj2cqrXHC5GKwvFUSTdR/aRrwqnsy99bKeYy7iUT3MFJEcp
	IMN8p2y36ud+bpcyi3Io0oKQ9NMhgM9PdgCoygHHQa3kolovQ+B4eFC7HEfe	dE1xWRpvNskvVD/aTpLIS6LcUdZihY8nQnxkBlIpCr26zZrrMd6/f4nnSNoX
	G2W73z169O2jPQ0VR/kT523pVb5Z1PlM/eUwlMs89Vi97fzUWO48JhbR3Qd7	epWB1dltGPM2AG3bXPMOqU3dsxRcQldkywFd/VjytiOuKhuBdwwsiRxUiXXR
	I17Z3f09CU+Hr+EXD8bV+xfGGQgbRzcGG14TR9I5lE6DeWp/rNmHWxMpP6R3	kP6KMyYhu0uPyTA0RbTnKFNu11nAK2Bdl3XJClkipqgD8lE4z6nZ/wdzsspu
	bc3pxOkIWIxeXqF/lUx2Ly9nB0/z1xv88XLVhaTQF5u4CBNifSSaA7OcFIAj	CB1kBYp2+0JOq5SZUJotXB5n8rUyTj4636Isuixz4xttMd4Dk/HqWZ01QNT1
	LUe/QcsFzOSqU/ig7Mj+De6MfuNv4IM+vZr8EFAxOEz9TA2Romqj+i44e1Wt	igKaaDxbeYjSvUAeBt9ugIKXkR8ftH9Kdk9sCoaLO/XoVgUeEvpPSdwNV5nP
	2WoOPLPRECRHKzZAzFlGaT68gcvrFK0u9+oLksJCHmw6Fz3RdoPBGMnSJoHc	mhpOMWTkxrFYk7k3Dds1AUkdq+pEcvAEJjCGpEPMzfIju7TUlHu0BD2P3H/D
	ELOe+It9hGaKQfjY0LXSJQ+1xWze5toaOODDgdSGGNRsdSrgUxH3sYc3EJmf	KXrnKqzW0I5jcppkf+bHbPZjU5BgKheSUiDXKDpJ3CC5BJraFY41wUieheCR
	RAGIM/X24cU2wlH40Azr+ZEPdETlKQH9EjuWZ7L4Z1EahfMnGM0jAUGzp39i	5yNGG2L/aWyo2XgTME3VqTWTtKlBSCzYHKBUw3zpFiLsgLWjixcmCXaG+h7Y
	thz49NAQxELQr98hIOIdhhtowPIGGbSNLdCZpWfaMQcO0/kMamwULnZs4NAE	7MOp58GDCjz38+ehP/cLM8yyaWrkfJ/Vbfhgcg/5mk+jNLm21yyA1FdehV5K
	DMVyNYTSg4zRyZFsrJDAueHsCDZMgM3C4NA2FFm++8kDzp7zOAbjBUh0djTw	Fvwvjl8fR0mGjqyAwf6My7zK8W0Jd7DZJpZjzntWvDnATzYbDIvD66KShfbI
	ScNu9MinTUz5hkz303AODalvH47JCL4iW6Q1impghOYc8ovOscPSFNbY+eHd	DvHq+DfJVcSpINGQHOLocUeatiZuIqmQOAPGygmFJgF+wRmqOAvS3YV1mzdN
	MgBmI0OwC6XQLQPoyjaeKiNbvGixchsx5i4YAY6P63O0rjh8CItijM0P/uk7	gYt8nGS/VEssjY2nNKJYvLcFkP1NMav6/JwF9gpLkLoaLubU62L9/SaHEvuT
	oL8KihxGE8D5uniGevEqCkCZiFUwEkO8anR7wGokPvBAZDKRANdLUEhBD+pi	8A7QrlyUmHJNgnWKEQk2ew+xRMpqgsHTEoYkHYtqDi6K2UcivE0V0mz9jIxh
	djJFR3rA1g7DkuIo3w58rgfnJSESuze2yfHI+79ihpQMuk6WxR9SHthO+kY8	RXY3akep52zhC2Zskiky8kII5+FEI+0iDQNZ1DGcy2JDCoYtxkFtqiS1neoW
	856O8HaW+7qt5HOGXyP8crTTvIiT8JfHfzVy3xuekXrOcrDZ3ld19pmZROhA	qsWS9aFEcFTE6rRQzw5vrL3jdiFqH3A8qVwiu5rlG9mlGsd0PXMAwzct58GS
	J55dNs0HBrt9sJecDexzCYHIDh/DnaTE4jp3skYtuHgHZOJDA6Mom2Imgj3y	a4sVFNY62BmAgdySLuS07i44/eISLKY13VUXh4NL1CF7JoeEoTnhQ/ICI90W
	aAC/wLQ30IqlcjicdFry4o4QUXahENVHp78i+wROpxDoXUmb4RhaGPyewsVr	lWywvYnfO86ubrP9VnJekIWOtWACDTJME0RFo8nbjuVg6q3su3SI/dD7hljU
	ZT/oHZls7dPvxyRIYOU/K+a4s0LAPDL1V/mslcQUxzYWG0qXcp1tHzxJVdz5	BsOceE2rUDoDR+a+ISa006UZLMnP3+yImIOuWcMGYoYSjJ8Igt8qJK/sOhV8
	XY4Yj+jCHNINYhT5PHbCUnAMZnbbv3CW60M9/yAp3CBxw2MyQndmH38WzmbJ	psCnSEo6G7oOJBfwDb0rAbwzaaOoDl1Um1XwXqcnts/O7INRtv/dw4f3Hx6o
	D5PqAKHCEtv8I6dJpvWKyp97E5FTeK3z2bczRJ1PNx8EMR3y5T5BTgYAYxbI	vzoK4jivaa/z7bLO52qlh8lc5H072WvWR0av5zkxxe7fPRjxCe8fHoiPPCyH
	LwRLkPPYbIQFQ9VOSNCYIagUhYz206AR1oI8p2eX3S3PnMWRKn3oo8m38kiu	X5x07g8fjMMg1pkfnpvgM7E7n/35NJkj+7GGQG6M5vzQ/9XOwFIcE4HDGAQ3
	mPVo/KK1Jmf2wsN7/RPvw8fU64YTeZdFPuMIHg2nQlPxulhcFemvcbhssJ7R	hk/JZg/ig3bytH+DyT9brbsQmfpioydhQ6wFRXtgjpNcf8T4amZYl8B28qrT
	IuvMkSYDtY6VcPgLRkNKnvOsJwln6oiH5D7s+HcUqMVlWmDJehQI0grnHbRt	vEa5mcMfuDP6xv+AZX//abJSgHPgNHWZ6qFFTkeFZyCOlcvZMhMU46gdkhkW
	qaBvh3Xhqm678d/XoIHBycsXF3UDP122IxgNfEJR9XceykMfZw7qYAGfSWbu	6yRGvFGsEX/AuDWaRi+/1RcMih55uv3dGBC32+UESjvZJ8FzPrGOafENzTAW
	J4z2Iqq8BZsNQ+JwXs7WU0HBwM8k+h7tTzSL2vV525UdIhiMWyAuBiMiWnct	0FeDzyyd+bFtxZ1Xya7xWLDkIDYiWjcrps6Xu6tRZ43Bm5ZgnSBn6iSAWUSO
	yYbZmhG4PY9AjQUJU2MsFikklvWVFjs2xWrBkWUb9sMc2bbtLqlpPJYXojzJ	lsI7iUQSqLslKqgJuTuxOXomVHEWhXg4toPORaIcVJFS0rVlZ6xPa8E8Dvr+
	FgzGQRvZeypuIRf2dKuTP/AsdPFnDx7c5uJzYi2C9dHHB/PrDwcInHv4R9EN	HSZzvEM/BU1Z3qHTtl4JIHOTC/WMfZmD/Q1MbhQed6wR0SakXMzqfhnkwJFs
	yW/jxDVNEVrV0QM1sUHpfz7MvDXCJzm5LDi127hfTIGCBNPpWDkv2MIB2xzH	6V27EGG6RroEpSdk+wKVoDIplH572QQWovNpGMZsEI/xKLGktAU+8jEdU3Xi
	ASZHvW452pXOvy+B2zL15tW6leCrCi2a77tOIPalYIu2rfnEHfqQuBYm2BAv	d9xLqRRz966cjLJvhO5aw8YSMzRSyp87uzJLUw9k94fvTzIrj3THLpRxt5wP
	WY2+Ery3IyzQmsqncEMIKkGj3RIK5jSAHMZLtmoZv0HZjDA5BO5yvigmXU1K	WLbxZhkC44Fi5jfiFMKgKDgW6FNUxdidCcdi9NMPfvQ94G8FeTKjLZCA4o0O
	tElez4z0cJQ9G2VHdLov+ma180IQ3/NcbzseZT9JyvjW2Z9SDJuCm9Zhd1vm	L/Jg3ejyGt3s8xqJ9ZzwlfYIwQ3CJ1KOhAybjVNhoz7tbI+Tq2JHIcJp+ETD
	mNfVh8LDdBYlTk1/VutmKHo2VDxC5z2Jp7A5kXtrjrFIAdNZT8CRYawd4eVE	novFXpFd5DzylrPoKiWnjPfOxksyn5ZPvEds+gG38OqY+7ob5eOaX3MHRP7T
	ObMZwRcoIIpflS/rNVnFCsAiGpXZbGJVdZTIxGzocom8dTMP2mqnl8WyuClJ	vohx8ZdHfzXkP5ieIX4OwLCiP2R6dsxMfHzAHc8umuYDp+x9sI+cJa67OE/k
	L8d432phTUfuKX0m8wegOsYKGzzvy47j8u02sR+FfAepS1S2G2LkmaOwJJYF	oo/hl8TL4jJ9UlptavQe0MSHBmZRNsVcqHvk0xb8AdMFQWWXivlw0+nIi1sm
	6DcZtoTpN/4zGOKCol2NcdpiJxh3KftcgveLyk/RuAQ1D4bG4oPPpwf36zVi	vLLphbmJpCJofqIkBWoC974E9XAOLUz+QJPda4VvyPqsns0C+n5MhATmwJNi
	OEsyXmgW1Xbptpk+lHGoV6XGu7aaMHQIDJ4l5DUilwnnY/PK3bYZaEbmSP0z	gXcreN0jm2CdM6ALnCb7RJZbiuZylXAqCZSq0CmSfwtx43PQMMZ1DS1FmXR2
	4hpKPHS0FKrnkbhYQVnoRRwiG3aN3/+vzC36apStSqqnqMYP4/Zwiv0uw7yJ	1/q5PBh9bv/CUbgP9eKDhJkD2aUnZSjvzA5/FoS1xLCJfwBlYZVw/pEDOLN6
	PwNmcQqG2CSri8ETQO+NbjAPgnt6Ks1kxqYFPWGr13Hbw+ju95dpyHGgZs4u	TRXcid3IyT/X+fjgGabOz7YfJCE8hPZ9LJ90As6vIFsStEaOtrO6ZpTayGwM
	BBm1NUVt0wfC8SuYono6XUcqXzS9k4pgo9spS3VFPlkVWNlI7iStzPb4Cn8B	zDN4pSKf02Hf64QlLU9p9LL7mlFdGPXh5L6MyZW/vqqgaK2GyikRPm3ZD3oH
	F2GuXkG8jq8f4TafIvNmD67HX8AW06ww/g0puCVagWQcDqhRn6EKzErzdUNq	1lRvGg43XhT5nP2ANKdK1MruqlheFv1HcN6Si04nrptIvA0YPVb20Rc4PYnJ
	WBiW9HEwkjGMi9zMkwQpHeAl4v4Mem8lZgIrTI92Jai67P+s8xnGG6YZ/jtL	ng2o4kzN+JCMACzgHXl98cCWWIEfeZS0YHsPFUmqq9lj5riu2278HxtgyWAa
	4de7ar5y7SecEhVhGqocDlWHux8mYi/DwAnonBy+vCq5NkpLvpuy/TgBy5/f	5svzuoFPV+0IJgMrKKoEbdC1SqXSw+VZwkpJKf6EzmNMnG9Bo0MvO0jS+WYm
	OqZdG4H8Iq0sV9FYSH/OfFmVIAww/uLmgrTOVusGDIqCM/aHIY024L3yAn2+	KTzwmbj0o0uLKlO7mbZd2WHWhTEoxDjhLI7WKRDOfMPJxUNbwisS4vlG5y7i
	l0dX8YA4U+XFwwMaYylZgtc790jps/TZZ46P+Y9FsfIleVyIrmHTs3Q9zpz4	YqzqS63g9FBFznoRMfq2mwVIOB3l9VK4KumKQXVoI31QqS/E2Y52uggSY6GD
	E3PY7pI8o001XiIBXn5eIhKAqjoJ+mQShf36TId12jlrgfR3h4fPNepkgNyE	YH737k0OAg7aRZmJtP6gnv3hHub+PfiT8IvetyFQl/twakeaHGwXRkmjoTVy
	BsXJpOBsW+QLLX6vYaUpErbSMvbhOld8bikALgkVR8nUAW/9Fu/SE3Yih9J2	QskLLO+agAiGvyNjB7d5J76NrcoQXz3JnmnBahDo8Tgn0EvqTctOtCEh+jq/
	j5EuYyeUNx0Zw31X9I3kJzAA4jw6N4mkq9q9WcPRKTJTj8TaLEpeFoDchDcY	HQdhXq/3C9ZYKDLA0PCCy1B2OttdNDBxx97nrtUY1odMOqYveE/cE5tZTnVi
	MGXIjJEdzza9x4Xf6PNmW3ze7S6vI5eXeKXYLnsmSeMAFoiJ+TxcO5wSlGdO	eE0kt0Id6uJt5kiDyO0Va8Gch0Ihk7BFlKzmfF1Q/3wpqidBRDPX41H2hDfx
	mY6Q6fKp2oloKjtO8aJNBXs/esJQeDxE/H/IOLWz4XRt7n5mLHSRvSNYlEXd	hJSBZUoZd5444l8+pR/DD5/xED9KqPrGs5iRw5y8qNYV4HbfOhzeO97D3hYl
	HCKnyLolE1t+zJsj2/353fHh6fGeUql9j2yK7tZhXGCwt9AIrU6JrCR4DVTw	7lJqi+sm7ZxLldCQpkBUK0BWZCQbyRcxagqDUjZMOpWQ0gE9E8eJ8wOa6cWv
	jH4YnzROs+MFwwB80SmN/0IHDipwvVxuknnkiW4FRbstDDcDQRmDGz79iFpJ	ylf1hvRpzSwj+Jj5fGJ5ehRE9aBtsFeajdbOLopVcV2GgMj+lL7D7JAsXAWA
	RJxwISB5Fefl97Jgm2oQGOt3y7kAEuDbsJJfiuqp4AFPD7gbi0r78BsOMmG8	k7gsVho1onNTMKDdfRlGIcxCbBXZ8pbgiBbkFY91EuCCMneJDmz9WjhzB8m9
	l6eRniZKyU7RHpPsXZeqbd/gy6UeGdSqX9Ubkv4c+GJkLOmMddnlMiyJySt1	GuPexaY03l622ySlMaq9Rd0UBAIoKMsPPqIfTLjXQHq0mBUVPgW1p9ulNVGk
	oY+Nuyi8TzC/wN+GRpMgty0Qlajb+NFcNY6QFxZ3V3ocMqsKBCn76EsABlOg	o16X6lTbqfuwtEiLHTI+EcuF48F55W66GbQpC4Q+GnENKconLQ0b2DQu5l02
	LjxzMg0pSsRcn4FEdcjmighjGMgvz3/6hpDFX/OoOGU4cuppJ8ViCjDf+hy5	/yP2xO2ysd//l2ww2nsUKevVklH9I4YJQOD9LsOYjRcS8zj8QzDUsIK0iNBf
	/mySvUG7NXd+XnuFZWIUR0CMhWc+jXKnZUdkLi6FQ5N53QXXUYDOeXx37Znv	Rz8xQ8GvBtzOxOUIAvB3u22XmwajX7+/6Hs3k5WE9jhIK67JRdwfEqS1JEzV
	OADtWSqc5k5igD2V3lhJvWHoUQ5JzB6pRr9tn7MHE02A4YAYtJjUi/0bVnLA	s9mmsfJAxICTumjD+ClKdkm2XRXg6Yj+JLDNKv0av4CHMF9AM5YdP483fobQ
	4xWEmTP3OpbcmHtClk/OnIAmM5kPQrIJIYKZSt41YDAGXcN12Qc4nxTlDsZi	gsOURFkCa1nzwhhKxO9WqD2SUpnkqz5AFiCmFpuGeLNATemAMJkxTI0s1ne+
	gHb6+nMlRUiwmT6qGh7L1Buhqk/UU2UWgEBnnICcbB0oVvAvuSxAVU7g2z4Q	GK6fJh6yXsSc6lOwcLASA5MVRmu7Evhg9t82+RzdGLMM/z0Ydl+VYC6VBTFS
	IlocdmBYQCcX1Y0UTaFZKxXqXteL+knyDGgEae4Jc0OUo2MPoYgCa1iVjkGf	UZpFlSM0HDIFmMxBhv4Y4EU57ENV5stxvfB18E3ZfpyAGcFvHdNVjtIaI5Yt
	xSYauJ6vNx70MQQQ1b+my3LinEiEaxsLB+h0WicbWhJIrvAXwBTj83xe7y7Z	T9FciLXOfc2ZpDygW8ctJMs8W28aUEAKTiAwaWoJo5jOC4ziPHqKJ8SRMk8t
	6NafMz1Bx2clsr7nbuI72RZv7Scz02WgGaW0lo+G5JXHNygunLTTJ84unsHP	PoUzJpoVGNMLnySekPqsDnwsirWvV+Tq/N0lqk6skgVwAAne0S0brxAXMJ+W
	Bc7rchuPXX18l/2YPS+88ejLtXcH9FyoGtmTaO505N/zY3ZadOvVM/j+0114	mJhApa+UlGWClakSVofl6zmzhsG3x8dPz9ShZfLYKQcWN5Tcv22RLxUVoIbT
	7mgrKR//2ekWLUaAd7J//jN78OnBA/zbv3SPo7asLMpISQg5L1g6W2xsryAy	JifbWuv7d5QE08ilJJiJQ9rtMC5Ht7VZPTQzAkztNkPpMTZt+SqSIp0wcOW+
	VRDuf0NBbFUO31Kx33l9VZhd5h3QWbq5tsddA4SOwjoYGkHgVOSUp2H7IWe2	opW17pzPTe657ZUnX8/8SMjM1bKxqo1iu4VEdkqESGg8pO0IH2CLwOfF32hK
	4IiPiU/Q1slNUNfHoa3nHgdraSr7AeloS+s4Mw4r/Y/Glf6HcEODcSXjctOg	ZztM6estaUeWNMFvsRr3RELZIZshxi/0WetBkFD0uw8IhZigR6paoqLtOOiM
	AklIKEEBsahD6Hraed128ty2E7jf+gOLLFF8HhHcif46RHd5Vn7Knk8eRi7O	Kli+jEdIueNDhGGU8QK2HD7O3U+cEV5k7yh3y6YFHSP0yqYlBV0+5uuS7f/0
	Hm97pUrW9ZyZglmeefNwfrInR2EFpOyzDG8O4kO+McoQH+G404glv4i+iulX	7tnx6bMDRZz7HkEn3Y3TOEevcqGuYFtXL05cKoZdSAoC/AQRBqTYn+opkGXD
	OKpGOFaVJ89PS4wgMt+Hf+bppigV2f5mggdPTnG64vwrzz+XPRgrWlfUGNJz	RcHS1mHaDXuH0F/Ls6OaZLn99s0HDPF3VSJb03MRsgLDB5kYZauwPHSaNECv
	GN9lcjeHs/huX2dGLCSFlFJk1Zp6LciDajGvWT8aL3sMqnLKWHnQlPyNakug	/AGNNS4Upk08190DzrxZrba9w+TTbiWReZfTcQ5UO26B6XxEZik3jrJn4BpU
	n8eWmEIIhswuUyl6phhVVCwsR/TzwcJ7Om0lfMVLxusFM7Ea4V7m91PXhlCX	nK5wkEkVSIS80Efsy5dIKY6ONmyCzzjzdKfccwjAElUVMdd/g2cjRePA3j0t
	ITWbclgMv2NE0ZbsHD7to0YgCFlCkukLAW+spsUBzPNyIRE4Ckkr462aBB6s	XZP8wC49zh0mrrUpOypItkEHRZb0zn/Xi2FQHmQA2EOdTpLme4lvOjyX+GM2
	hl8iR1z4Bi0WAbv4h4x3wjAiikTrtxuALaDBOGU6Q6W/szXN5bUXDk4WkQ4o	EF80V/r8b2ZXmBzu/UkhgZoOJow5mSUinJz3juZ9hw4l9EfAnH5++uO3mI0d
	D1FR5+bOjyRBozMkHLky+cucpHvYzFy1HwXwEwE50GiCTcsGWoSbojyFGMcw	RnXRqNkNo8Zx0+A7CEE+xg+UjP/+kPIY7NQb1LLNRg8q/liFt4XwnBMhpX42
	zrenv8Rcfylr3aAwD4WMwFVM51amo/XzQfK6dUoSSLVXtjvwkXjpB9jgIFIX	iFx2DL3TzyEnY6DzRq+T3PA8/nXtcQrZ4R7QRjRWFBc6UCWUMzd7x9T7gTPV
	xQeiKqYOKtu1AcE6BkPot4lBkTeLzQeMVd1RBMKYY5vvDs8xrGHmeEgEHveL	yARDIJG0F7EbNbnMAF6X24XB4K3vv2FhDbxAU1Zzp/jgfeAPH9xhMRgy70y0
	L0VE/6gXb8I6xnxeYE7VF87i82gIHHYjEF0MJFthgLLPT/1wcjDZfyDYolBZ	h7L+BM4ibKdcJbjFgeNwRf093FNy6getNiTCeuQAhbToZbJ6/3EYlmFUQsml
	Xl5cdiEXT9meQVo5JOJA7a6tE0zNTxrurQrGy1LB+lTYvC231TBvHeOEnQKU	MKnKHAIl6HHsdbJzooi9sOL6DGXTod3DPYEOxmkHdAy0zJFFSx0b6t+CLeDF
	tqZKOMzBIWAjuBrpCHVQF+tylnPaYSjD6Pu3UMTqJuAAxTvRNNKyygE2gQBb	jrDsXmwFNTSNt2E8jOKSbM0Ukc8Q8QTQe7XcRhO3Iv8WQSM8NBQCGiLMCTGk
	igc1Ej59Caf3o/14ZjiOndCmjujxRoEkrVWEjAdI9o3sm/jWKN7i2bQGQtuh	J8924agAZ3/P4PXBRyYJzII8MeWOND6WeZtAfOulzQAGE8fq0fuBuw635hq3
	AiP9COd+puhIfoPRd3fjnUMUNxrA21zrgVxJ3rpQrUw50m18dWzhUVj1JaXl	1iCE2z8I2lMSQ96Tk1c+wUPz6YnbfeKY6hl8LunPLrfO5vXHd9kfs6eF12p9
	wkxs+arA/cnxDZhm+kaM0QQXGvw7IXOlK9dLNcQDda5wiWhohmI8XX4hP48U	Of3+9XwzlPIciNd6NvKv/GN2WnSb9RPYjNN9eMVoJ6Yi/+11yxY93XvZf/5n
	vXhYltlvyEOgQ/ROGD4ZaFBVQkZioSNcvqRQTqGmMJIxALv0ePyxrbaU0qEt	dvfT3bv4v/79B+yd9g4bs4uCrQwa2E5bwHOM0FHgv4Zj7OQW96kgc1pfFuba
	7AD+TEow+CFE/QM9zkS0zuxq3m/1VhslontQvCg+y3E82q0/UPB/HML0I5Q6	eeN53r9t13mVQ8IheafQv4NJZpFPYRCmSJriBbuujJOF7lNunNbe125dD7Er
	NIsu6wVVvxlyHoPzfSnxdefAC0oiSKb8W+xzicZK6WRLRC3awEBq18AytRWp	mjY05XSPbrrONWMP2b+ri+zfQX7vcpFZpwFNLOC+hJIeIJE6OOhnnWd6L57a
	vu5MS+/yUMAb7ATOvwtTP4U8+7JPqWmpKbziAw8e1oOpZrsv3r3bGzl1l6TD	Njd3Wq+nkraM4xFWoTC2YzTy5+Wn7OnkQWSQHTA/UNRrPde5qXDm/TeD88ge
	Eh+7oTSiRebVPjgsPjC8k92qraa4v0jPbZHbiTsxIr5WCZ+jevYI48i5p199	74Y5kwIJc454ICPuqLFZMrQejrWmngdFtCpG1GEHIaUBK115qGECeZEdP/6N
	0F/9qEplclrki90h1XGLx46xqOHdLt76iW901MvNwePPNP/FigB24nlZCVJl	N5zcbWSfmC3eIVbFRIT3D76ccAnJmUHkURo0uvYC5njR/z3dO/29rwckeJlC
	IJenGPZexg7Feu1zyeSBSJawTdKErv/YbEuKcOg1/UPiNotv+LT08IeQ9CKt	KlMybj+nQ9WigzP7NB6CMXDSGZcdACPllaq6gZYp62iaVZHS8UxprwZX8C17
	cBYt0Bm3ScGdtIXiFnM/giLzLMAm44UNJyUHEVWeO+nJxPxIosYRV19+KgIr	TE30eRI0gYSxeOL44EQv74o12W78furOE4pcpMJWZEn6HSPyFGVTWNrHoP93
	Zig0sSxY4g4zRRr/oiTaU3I5boa/M4BLULcMoUFIDbuug/WhQoAclYemU3G/	DdOnL9i8tvwZJ7DIy6U4E8nNrhDGqjH4XD5ciUjAsAatvAHl+YeM70M6V4wI
	dTf5EK3mxepl2RHPaS38TKopSOpgLLuxy7Anh7z4KegGfL5nLpDamNokXaJF	7Ndrcn2An3HQeI5iYG93WC/wMpyeHCPJL5+3o8bS7QdlZwdJliCV5QBWOaWH
	lllf4ZGJL479CnyctLcpmZ1j2ECz8Dh/iOeVpOducBVc3+aTQIv2jMD6Oylj	pI3fdftR8qCi/BbUq+D6sg4X5ZRREEZ0aJjp29OfYwDHPhRhkqBTLi+wKfv7
	oKCxuu6G/Dm8lOmtkjC2lIze4sMhOYOpZRNT/hrJUhXlRnpbU/zaGYjCTbYH	KxvS+h0hmt25Kb2EdM9492CR+OgHuOhAVufFB8Kfpi5W1/EFynbZERm4iRyK
	Fde/4Us1ohJgpp6ToK2p55DlQM/4XVdlvVBWoHAfxfVcYoCaavx4kdkdHHJ0	vFluP6Cv7dakEGYeK4e3GcmCwxmB0SN+vDu+2BPNqTQoXpsvCown+3JnHJGm
	PAGRnEiyQHfycruBWlqckyWxVHVmlnDsHgrhp8fMAsxQyIvOhFIWw+723NGD	wc5DSjWMM+3W6Godwo8/mNybHN6V5KuAC1CeX3QhL4HiWUkUQURUQY6vnTFM
	McVf6clwvjG7myvhz96wK/G2/dhaNkI5uIc9pH06wAMFDvOYI3jWiP/GxYTp	MVXfcV0VnGlMcAMzAWu3EGZpmELOtnaawXVNJIh9I+zONkSs7pFQYna+Kec5
	Q0IbiX8Yvd/B0eOCoRlUYYiQ9+8eZd8ejM9LsHXXlfQUUrotIb3PteTtfL5u	x1RSoVTfo4dedH0SBXluUXXS6tUEIETI7YqnNZKWCRIeSMUyUI44dlHRJY/w
	KfH3AXPCRfcBvLezSfay/FhgGnYU6Em4YhTHxdqFvsBt/4KtsAVYubdCtMhs	EAMgXqvpQz6XdKiUX4etR24bj5yW8NSHgpb+Kpz7iRws16Wcjb5C3R+Rn/sG
	C3CJzdhHUMIhnaMJIWfAbzLNXClqyK5PPIOyhqA82DiKfThfmcR0gALA+Co9	PXmXUZ4MB+WtC8XhEhM2PzcIhawCkof4JQUgw37sXFvAeWXvCGw3rRR9PMH4
	EBKHOi2m+AzfmBCJ34KDRFX9ziBI3wr08pQQpKC6FXRKluhwPKQ1wCDVJ3Kb	BstQgHvpyc1KNfYAk8wvdurPIR9Rl5/L5xH/F9vMojmmzQmSsLfKeZSpBu4l
	SXN6yjU3aKhM/PEthQAfs35X0b51QSUckkELwCf2YvE1Wwwtw/Ek7HOKObUF	2DIWvoJLxDT1VdUYG1JIJKr6IoexrWyVyqwdIA9eXA1qGoLH/Qca0JY32FO9
	qdKTKgJ2ef8W8Q0mFol0CXxKh4All0b1Mb1wIOCuFdrNAJFkFS4tkTFbflXO	0+qPraeJfoOkRq5mdgzS5f2BIhrjEHkYIQWi3nRRL6nS0KAumezolxIycA6M
	1mCV2qwg9X6kTomDrUsz6SSIk1w2xrtbtyPeYqkKHWBZQISajN60l+TPaM13	pp4XylTdixovPl0pU20Je0dbVkidICivtv7XV/hpmWMeCqaDEsFJB9Kbgfyo
	yDTpVwmwTSnnxev17ZOCAxX5M3Vj3+e3ZAUzCfL5bIMwHYawCmZdT4zg9Cqz	qVtA4Xip4LxkWQjDDZJ7s/3n794djJzaVtJWi6Xy3JebtIjDm8qfi+WIN9Nb
	BRzDaEhq5Bw9kcCxjpXQc7BZRZ+C30lRCXTIzhtQs5ghp0iUPg07T/Aewkan	Veg0oTFifTspeOJeGHLfKLUvkGv73OzIQUBffdCv/qhsZnJa5Mv9xCtuMvXR
	YjG6v+xgS+Vv9if72E3u8mDnr7TXfyvO370/AnmYlXm4qc3+snNdnDfdFC+e	o5W++mLmv/ANrq4N7zFTgDs9LasEhKsECxPajLLQ7mLjo+dkqEggtO1FQhNF
	juW//+pj6D7rn8/SeCrisBEpgDPLTFe4WF3d4dJjBYwifIQXFN9nDnbhQ8Lp	gdmOKGgyF20gOG5SCtNC1Kd9hGge4+VGB3TG7XHwPu2EO8ZwliTXeWRoE8zD
	sETzYRLIEubGlLqAgRURe+MmXCKRCFqTVJrn4Tpxd51A4qFLJUkCrL6Jxowt	ztsS/4nq/Z1042LoK2HrWJNQfioCLmqo1rEwZ2I9Mw4ef1ES8C3ZJteXDnBG
	EKN8wJC6vN/GVJ/BZrGi4rMSMqNq93oPHwzeswF2VY/v9uetsky+VEz+4G1O	myQrc/4Q5hOxpZusx9XQjC3HHW7GndZdZ2y0GuyrV2WHr64Fe0tZBhEeTGY/
	uQv3tai4rxnFoS/I5BzOdOgZIDSl6DnKKjwfYSARaa53H4xgMOPs+Z7g6M0O	NiwORPaLPYPGwudvzANSX1SbkE50zrLta5Sh9N7I+sDhpLNRyegou5Q3mzLo
	dAfbXz8rZzTtWtCxfRC7RMUKdpECL4IxPvUNXcncrEzTzD0e4cvs99mT/sh8	JXteSdDxGpPCJTRCdc5oyxCscpQ6EPJAq6FvUMHDaznk0fOJS3HuDfYeImOY
	6LlsY/1/62RU2UuGAAp36ZAvGO0bZdT1EJeoZgoW6CVIzUtiLrpMuT9vLteS	ikFR9q8QM1cT/oiJazKDNoYiN5VtQcZVhvhS9cKEdFwfnGtrajllIfAzftdl
	tnJaiyG5TBJ7MIrmeUMLgI9/nf2YfbsPq7S7i2u1v5f9P2AgMWMuztLrgbXj	WS8V7in8jnyCrqecGhiE+KDZcEybQx5bSgSUHNKtbOIuWbeM+7IiHLLO7BTO
	Clva5ekcbRuWct553kC49tsDIajmIjnvjzPfn/cGhZjXagbZn7xtNWxNB6lo	3yd++C0yOwG7FMKtc0EXRj++FUIqKfspaCokpltzzRmG4OwNmxtv24+txZ4U
	hL5FqVs6r2xzZ9QyaCZK3N3hugQnNZgkvusxBeHJ+/bH2NjSaLdx9x5HADnN	SZ62og5JogcoIga5x/Ricw22LkbT383uE/P3dzkaMGiggSsGl/vw16Ps/r3x
	LoB1TsA7o5eHsyjBxhv78CmjN7QEsCnABhAwL8eWE/oBigbIaJOvCJ9MfZLO	tAQ1eFNJYykFVJPOBwptX08Xm5bCiB8w2Fx0H8DGg3v1svxYYDR8FDBiuDoX
	WU6QiIjyuZh3ZqrCjHs4h3VHq+t5CJST9XjoA+Vgdd0QRXfusBf577EpReYt	58V8hlbgdq9gZ3IGnN1bwdVksAt4JM5HMNckxX00xuRM/p9sNNfkGuTzFx5O
	UTCzN8/PsSmfHoofD2TJDJXd1sSQwfrbg96gQbERLTZ9heNKCYC9DakTOADo	W91WPqAa+UqcL/Bi5EdJM/kqbhDikbotppAP39hDlr8hHxSZ9juTTvtWUlBP
	MlAQJAmLV5FIWdTGdgRfpYZQ7EVwzEa/1BrN+LR+5XxvOIT/Tm3tkAOQaOHZ	KZ0WmLhm4JJyust/0ppUKOUr8kMTP/Wwemn2PfHSXIonPmbD/rIpH/yLSsNy
	lqr61BuOq+oJbiSN5vjIszjvBeIvH3sV4c6s58++zllvInwx/MBE9CZq+GMH	IdUrABjdooRJIAY1/daW+UpvsiiXzdvAmDthXJgIVcEyO/g5uchsmOMMkgGv
	WBHsJzPc9GtI+Qn+WBUJRPNOqzfXcedeD3aMzIaN+TgaGHk7Sc8h5X7ewSqT	rqCshkRR5uW04iMKv1+W8w1oqTbWSD1AqWNmsodtJh0lcZexs7e3/DawI3TL
	WfGhQMpAdXTsiwbW9N9nS4jX1tm17QUKvnYhnfcqo4XUcA/d3PYCaX5i2l5H	+pw0CW6BaXkyf9NolBfSmpXIRum6JJtP2xCIVewbaQXDKrJz6sa+z9/LCvYS
	KQXIpRKr41As+fCkJQ/uh2DuwHOOClDLA6hWcnCEn+9FI7rrl/cbOhkfnsBY	iPTJFjOROJlXkvp98ok3iRVXBCQyqpbqckf7JKDuY7H5ArRYYauYVJNTaWme
	zsSqRkOpJQp9a/P4p1EUiEsJWokj0QrNOAc+BEFMDDNUm4jdZpa3AoUl73XP	TRvgtojARE4rHQ27kwga3su3r0WDdH/Zw97W3x5ODrGv4MW9vb/Shf+1mL57
	Mo0A00febw2TC7EzzkbMqxH7nmB/V7gCKxKgS6QlDyGmh5P9GMXl6Q/6h4GS	fwIUMS/z8KM2+8veVTFtuhk+PBvLf//VO9+duvjzed8Ji3npmIWAO8u4Y3hc
	YKXZn54Yxmwrt2oWm3phkv243GabJXdi7s0H0kVSwxr51+nYNV3M1mlaxBMj	Xd3h4WPhkOYPCQQsvs/IeEGlwu2wrQfCJpBmzC1K9QAD+CW2SR5guURkaJVU
	3HrFQrIMBDi5E9JVMl0sUdRPUD/jayGsA0jioaf5abkJ3uk5+ekY19lWSDLm	aaSIJ8WdlgJ+ih6WxBewbCmaNbbDjEIJKa55p41xXYMCY4nFBzRkT70mHKx/
	BTfgNEw78bCJbGmSlj4ilO7cgyQ9Yob7xeaLIcibmQlKKUh6wbes8NZgyuzA	TPhJwelqvrsXvQoo+korFZI/c4pQeaiV2ikWKeZ+QVpoOlCi4kBgadGilLN4
	tvdqo9LSA3AOpw95IvEEM6WHftY8/uKuIGLCK23HWYSNe/sSjKQlHqeqBoU5	OkK/I0Kc798dwXTG2dMDKS0w99Ddu24C83JOm6+VL7unsU/ou6AmaWJH0NFn
	lA4TD3AbzW6KdeAJ4mS/9c0jcncx5+RgMiwrTKuMKewJcUK81/yiPtKTV1tS	vsVvxvWhoY3qAc/xVfb77PFwbt5fXbaxKLhxO6rsFWc7ClptykqM7o8iKfsk
	dw60iIkMcuSL7BhuR24bPk0SRwSERPtgWoSQLyER/I2T7F0RZjEaAZFiM5hJ	mqjcDA7pJdDOS0KRuuhDvd5U6yatBrVORYKiRP6gIy3yhg4BX/A6+2N2/xBO
	y17T7UF5RTiQx5fl3+DXtD962HEFumzNNiftIUMyCTQGZfVjupibhC5V1gxg	an//Jfz/w4PsfwN9iVE3cZ9eJ86P65bpvvd3affEFI3QQzrC0/fvCUA51xl6
	ShIXUXmGN7dSHT7JYjIJWw6E/BDagdCavfgosvWDb8Fg5NtwOqLb7bO8rS54	a52hGL2lKHjMlkvITeULrL5ukqvCHVJKpl7vvLJNv5HnoOYoDnuHpxNM2KCl
	NGkWET8+3rWoTXyn6PQgvmt0+iYzQUthI/uifzL9jQqDbjcT/Ak8cnFxrU7k	+G7Y5L0n29yLtbEFUm/jfk+O8vI0LAEqO+X8GS69KwgTFL+xd7ZyjohWUjYF
	DcjZgSx3v4kLMxyYR3P8Mz79EbTa9ieSPVXcRfB7ATvQNSAOlG0KUb64xkUj	aAWSyYydwgYID+QtkPn21hEWTR20pkwtiAZFgWEMYzOQZMbdvcPpoyr2NLjX
	YQygjanZ4is7at1MO1k6BhAemal7UV3NylbL3HoGAIZNF+Wdab3uwkiYTIEw	SaU89u51UMWu8b07dzwIGAxgrSKdl9C32dbncWy8KFHYgCJaAktld01cyRRA
	PnORD/l60SHlmBEwzryk2ZGeAA76Cy6UCAp1NOIdEUxkq42IlMwnDfvDxSll	WOFv8k+xTTG2BAYRptjPXrnUTUwkj5ksEwRvUyPfgI2q8u0IV4waibF5YUfW
	dmRyi3+CjQNbqsuRgxlU9rL8h3SORGP0+yf7jwU/SAsQp5dQbbhEcPRDg+Qo	M9a1W92aMliGzszh9Cglvq+Uh0iC1pntQDHoG88xigElOklWLAtFm/i+xAzQ
	Zitq/tofl5AE0KAE14cClLayIWV5MwlExADnmP/hnDnUNN+MKPu002mv/24s	R555uDPrKJAchMHGePCB/saU3XDj0otNoFDYJXPu69d0a6D0y6qI8yxvdZp9
	SZ6ydCciSeR26hgIQjSbFiwKwblEgTykLHR6C5TfEUY1hQbA/rrAEjiJGafF	+120d2WWHeeqw719FNdT7zCTFBV8Dytz5sWHApEe1UDqU1HviP95sIr4qJ09
	pa1shsUm1E/L8/SYOPE1fEyCOJSMoy5WpNgpxRDm1NgObohDMWyv+K2hBlpa	6oGL4WvP1XlrNDpXdRbRj9uBK85vTDtsTeZz9fokrDPRHPv0tvWGTjlwbgGE
	UkgJ9PY3Ma8qJlVoI52DaU51lnSOlAgHXy3qDT4kaaA9NS8ieyTkXHkwLoSG	j3xSiyeo6BRn2Z8k1gPZOd129cPOYMb+pzQwZ7xdo1SsinzoomqjymF8SFxk
	GR/hO2Treb51TFo+jQshdZgdsXpjxs1noMzzy3kQE5pa5uRjW9A9f31KjZts	0YoXik5pzlH25C4PdDnirphfzph8BRJNPmjFZrpJDoe90xpIHYLXnI8Y4CQ2
	l4mKOnlRgZ920YtRwwjsK6fcVbhyydipvOXaDHmijKQDa0X9BYqce/0o1eac	XUF1r/Ac1kRKFwhdH9xUDyaHcQaZh59ISQ6FLBsElc4GRBlD39zIdmw0h/sx
	4mpgbGFLsNBZFyaZKTIoZQ7SPPjEKUExNpypwCmc0nl4BQ+pGZsixEQtJy9s	9MuTdimBL8yv81QcSguDIzN9sIIQ7yDltl/4FOfZDYus9Ego3eVWqbgSSGMa
	r2EKdXqFBgoOtPxsA1uos5uOnhntD27PZjFE9oEE1JjW9UfT184nZKiDDRzr	o+aVupivz7FNJDunxvPbc33Sqe/jQPJf913zpjH4uAXLY9aJuU5gWJN+NSmm
	C/ulIxcMu8GPFMOnLQZvt/wCnRQBeSmPpoP0SWVaeItysFTIqWoxisMrDG3Y	9U190qbP2eE2xPkymXp3ZvYDJbiELnyvE69N9uE1WH9fb5V0BjmlO0KUsptU
	E8VrNKlC+3FzN/JeTePfeNhJiXw4Z9wdzhnei6S4yBAzakrOal+nbNHcpU+g	AxNqOf3W+cSP2yc7U9rU7gSPcJ9vcxIjabzIAbE0dZvSbMJ4bqNt7mdZ8EZx
	3FVVWRgEPoE2l7zBKCF5KjFxcag5muidlF03NyvsOFwsbkt8VfyUSQaWqRwv	goG19yMEf1EJRXYZAByGzMaA+YTAOd5rHFOH9PDkFrmf3TeiaANB+VpFzv4j
	ya+cZiPBi1z7kuvc2zDKmxGQH1GzvoGmhJwUplSFT7pgfTGsX9txLCNW1LV/	IxBHk+gUZWaiRjErgjeZsh/8DyfZuyLsZDQDAj3nfCotKO7fFIpfgsweX5R/
	iyI0sELrkrKAFda+SacYe74cagJUmAWiyXbb73sWcIfohKSNKjOtP3DBeiex	g6/pqgwy3TXH5prIdq8ZaYhYAQuhLIIYyed68utzcs6i6sdG4qISr6b1Wfwk
	9bZjG6CLvrsM7r6LJl9dmnZ7ouEvhyQsmIM+ReNfR4sT6m/g7KREPQg6mluJ	i7E8bE0TgnNov0urMONQZDcEO4VzpW/KFBK2b8fyOr+kxkmzkXj4gUoX+pH3
	DeusDcvW/2HfDscbuLyWWlgIE05kaAvIcJsTwHWw8EDtyrM1/ubx825byrLk	pfVt3d/X6RJaWxwpIUOh9TcqaLpZl/AieuTiamW+Izfl8w6j6sNmQAwmYQZn
	wr+b+lro5qBlIUwckXqwfWWIcAbNLBoFfy2+ehRHxMa9Ai14eznfBEGfIkZs	72qsIGAubTvcSrZ78TbB95JeQc8AQVBIK/gQ48oc9bJxXm8Mohc/2VGLcLrR
	zs/3rNkIVslucWi4ALeiG0wB1TZ70HHiGFawqVcN1+aLFzfOUoeMAoJtEBcz	0h6C0qQZkRkZ17zk5qkplRWdssvy1gBst4GQ7BsIjOnNpUnk8oqklmMIxzi4
	yL65KpFFtTrhRRy4ODJf5rXorACpw9Wr6oGHc6KTp0iXOIIceHq8GwbkPLtd	07csBiSYNC1cKAYVcHBMvMQkJlsjRfBxPjI5nC5uKYNek4H9I1wduFRdjvja
	ujjsNYHxMeYApHf+A8ru8+f/AGP/u/2DR5asRdrETOsGtgd+j3Yu5TxrsHto	wLpX5d/z0Ez0+8eHjySNkQ4gjmAh63A9wtGFBsrRfLGo3fBwXgLDQJOS3EIk
	t4IjFiwv9IA+cQLfBDK/5zAm0sh8++TxdxL5+fz5txeH73/7eXzy9k8PQTSd	oH4/JBm/um73qh5en2OkjSkj3mlwG8sA+t11B32fY2ryuLN7Ea7lHs0KnUu2
	zC8l+6S3KrEtk7VxbvoWcZ3+ydurh2Ekk5h+p0AQ0lRQzgiFRGdNkps3iJkT	4FJg7MWzZCCi9KQCsHuUMNvPRIA7do7le/hpopS4lQux3IZidBlPBcaLTuMF
	bIhWbHGvMJ5zcvfIkjRuCm4d34ksQKvhnsRnt2eLVxx2tYJONJsQeVX0Yg61	DFmZivlRSzRi7xTEMHvqBaBLAV6GGxa/FAEGQ1YJDj6ce4TQUi/nw0dCwF+6
	cdgTHb/EXvROnmg1ohizFkveuuCJ+ba1iZ/erybXSjuyshhWzLjJVpiUtYbb	mEgx+jXTlc4DGP2RckHuLtYidwx81XemSHRii3rEywQcx9B0QRQ3FqoIHm3O
	tyvqOyPvyY6KBgOPJF5N6SXhwBS94OaoaJS2wwxHKf172SrMy08GnpqoUAKi	9PBN4FVxgLm65Fy1wB3HlhJVbBNH2fMhgBbGRwcm9pXxdMiui/CAEdV+gfHi
	iigkcUp4GTBgERm9amGALSaEMHwaoB+OwM2m5KMBuYuWq95ijoLiEHtDO9/S	nNceQuoSJnXri6OxEJAEm00GfANcCs4AVK5mO2I7DafNCFmaSsn+5bACbp6M
	FEQdmhLDxBQx3tT90zaOz5RUhCRFFCi2h2MhKhFYhvsckX6V3ZJ8IOiOJG6w	mxVzeg7ja0gt63dU3DHE4LszK/ImiqKboFVqolHk3CpLcWEX5KYEvbOYm7NB
	/0Td8P743avTH5H/6+GTJ3RAUFIoo2Z/VLIjOjfIKw+EkAbiUsDk1d24LfCs	1zGDsFBiAlzm5IgzSnvZchgICXJGSsElDIIlOy8qxcJqOTJkq5rJr+h5OvB4
	JjSKIXt8+fxFtsjBiac1dYN0ZQeTbzkLhOro0eMnDygRhsc98TOyKMkj/T45	EHTzLXCQzvIcGjNiD9zq0CZt2QEpJWZW1x9No0gf76KOTaDbLO1KRy7ouMlF
	Ly5K8tWKoI6zw9OjkxMcDZmWcC/KLb+eOU87QpNl332bUVPe1piLkezHS0Qj	Ckm1RfLnFquikyItfz+j7SB2WgXeqF53C+fd56yGb3p+qQ2qIu+WRquIH21v
	8MsiiG0u0oHvc/QCzfWLMUbgGny7DAk2L/xsF1sUZvcf3M8EGpndf3J/D7+i	BzityRLXyntBOAii1t1C1DK3IL5N2qjh0qKuzF3EMFkZL31k6rac2iab4Aj4
	bN3Og087+J87D/57R45VaWNS41kr2JkNnzijaJbpJe4S3OMZuJNLbCZ5wwtH	Nn2DaU0ioxIAHPvuo43e6+NB5+aEHfvexYKLn4pHmWSgnot07X3lNNgLhvXG
	2f3c/GB+nw3x+4f3nf/hT/f3tJsohbqjxU87Zsba2al2XpTws3zRivl0wj0q	18vnXo1TDJaQXxP1vUw0+OSoO0V/fCQLC8M9r+8Lqtq/RfNgsHbuggKsFdYm
	MaNFhj6s/E/cruwoqAbTdO3wz+R0W0DpAlySStM7eWZz0aQouf2Zs6qm0w6W	SkMkK6KONb4sOBHRZrvdv3sSEj3RGut3fs20EsQFE4bI1qvPbcgV9Zwcb995
	pvFjjCNLIgckOeeFWHhTPQlgxHEphyhItNSEAyz0pOR+ZXWq9TRLS0UQmoKw	k68vTNtK4YkXKQoLGrGPevnX0eGEqigQxZQJAYSOGmdPjXdWjWcT6HhojOAP
	ugT2j6IMHJ9hPofDVN3sIi3KJZ4MOAmDbTHQyG/BifEBvIQxh7VIHDHVOpDY	pHM9dmgRfKXI1pCkzl2WENcsw4C+zdsuL6UvX3C7YsGCfnJdxxa9HHQslH9I
	g5G4HkZzCE7acdDpb57dKsT67XdQRNTRVsNGfotN7NmYify6URjrh84JDcyw	EBasXhp4paSWSbPg1VbSiTq4C8eDqjl4ebnYBjqfYSregof3QO+YDpTdaNRx
	hVnrGGjHEPemw3KRRuE4Hn6Wul7oSkj5n8NtkwTcLigpVs1Y86InuhHZQUwV	pXRFPzF1bbv0YccheTjCpl43jKogtuw465ul5DFtA72YaQ5VdpX2onXDi9iJ
	h74OuZEmOWKzSGi1zNBQRHpr2tR81msQNqfNlc7rusOep6vEvg3c92TcZad/	c2LW5tnovACyw+Or6sTgHD7mTdIzjlI6PCTjNRNyHkwxdTo5qk5j9s56J0hI
	OnpGqZFyWrxCx4xRXmDbwaPHJ6/HcJG17mgwLD8UfrrMtWghDB7vJNoYmA04	Zvz8+V8QSOrhvYdoEUekgVylgfuB69EuwBy7jrQl6mQblEO0Aj9xaoTx8X7P
	RrvCTC3vKZy+KOiWfkeCHHHsuJ4juL8Iy+CbUMmS1qEG7rqpkdfcWEjaA1Bj	Hl7EIrr/+NF34gX7/PnX58fvf/1p/OLtnx8AbTrZXwqeSqNiwgYndWNqunMx
	B9LqQVZggzaAPHfiAr9dG+uMeJsKepjmPG9NMMtpMCs9svEdtkivnBdEq0q2	wsKLt5cPwkwmMYZTgYleM8krx5xTNFjLqFFGmtCcZN9oAR33xeNdJ6OX1F1j
	0BRbFcKGwHZtrMwC8bl3dRlHpK4ZmuYuiRm1fonfnv4ieEguN1lI9CefI2AZ	rOHt8V33Qjo7/Kbnu7DiJWis5rwCWzT3EEFy9GF2PLI3GM3fuOgvmLrC2Ai7
	w6aUTFbLt84wh7ZEPDZ/J+8RKqKnegBsT8Qn5YaVT4XhS65JEdgtytT79y/b	zioteeuCPeq7QPe8FcOify18JEWLs7g5QbUVyG8ts/dtuYbm2HtSpaLJwJAE
	PflWb8whg2FML+eIsTAQHIbaOmEshLvMb0N5gu9Pbaww7c8g8ZzxNF8x2R59	6SpNUcBaKM+5zzDqpW0aKKvfrqBsNZXObwYKTmQqIWuNYEtxS/gY0G0T6b1e
	nJTIIxsDPiqQCoWyKhRHyaqtUeEZ8Ck5yNSIhmvJJKTuxZnYIbGSRu2klDNS	8y4Ux4cFAnojMEO2KVk6IPrUaj04zFFgHaJyaB9p9jHeyNp6CospNL2ur25m
	6whZGrKfpaORzxUoEoxNxNZqIooYhYMl2C8k6bmp+jYVWfkVWKm53SEq9CFY	BlGzj8lHOCt2R2TKKjGjD68/WjWVvaksKPSiKgLd4wePH5O0oDhaRjmiVDgl
	FhenRSydd+7+2IejpB79qTiWtl7bUMxr9eWG3Fl7ua1Zt3eEDMi27obc+1lb	/DdQLr+d8jjEvoBtrLtxW6DgpowfAzL68unzbJlPiyWdrksi4d2b3OewGbKm
	KOJgvWEttHyfCjgXW3FK/PPi0BeTNzEoBB52iQMgXApGwnFWxRnCkpXEXEjt	h48e36X4Icp+QgVlopIh/Y2ZFuclmZZFYM3Z8enJixc4G9Iz4bdIwfx6xtzt
	Adv6IFOPJ/5cYnPozctiMw7162yrR73qRLt9LBCXAIK2WnvuEgIb/HL8Kn5N	KHcv++5+Rp2uW6M7RrcgPheagT8LCbNzkRSsz9ELNG9CNDNKYMK3y5TgGsNn
	wq+77VWhEO3l748Eji3hsyPnMfC8RIRmKD6tctuiN/A7ECCCGfxJfH0dglR9	+9yY887dO5nkomZ3Ht85wGWAAb9399Me/ufe3X/bEykr3XjqFdC0pCdtWfyM
	SKRlG2TFBurJj9eK5et+3S3jleGB+RRPMDlgTacBDuv5XN4A1qEfqx1Gfmks	om2mt7gLMOfnxaxcYSfV694IH+Tmg8Ud1svvHN9x/sMf7xxoM10KAkTH3+8X
	NHDoK2j/DlvHA3xo86T92DW8MgUbnKG1lKGQMimuWvDVsd4MUUqs7VsX4+5z	G/Nqp7x6WcJn+bIVbeoF92dFiiO9v8bey7SnJ4FNmEaDx7+RsW5TeJdgoVQa
	RANIz+VSeukSVbtWkXLzjXywB+HJkKF11+w4+zb956K7MpBI2J4tN5AtF6O6	AcszG8gnpskt/5xlO532bjUNT+N8vb6rA2lnWojCN1OpADOO62iEWaLiJvh3
	SMN/ZWo8U4JeJ7FBCmKE9BK7bwnyNYYZtGJwuDQJ40uBBr4PpvNNKCcWFRwB	oRcrd+er+xxQw9tUf6LBGctX4AZpmoZjieYjXIwmzxbTslyhlMBNSLZ0QZ2/
	7aTUpS2pIYwpPq5MfaIRHTLVhXe95cybodhPezpijo3QXFPQJFFlrUONlxKJ	BZvGuzR7yEfMPGIfspbgxAaN90SWK0rf7dgF9zePVBbiH3Yd5HZxdNmweeVy
	ispqQw7UFEdyvBxPNwbYmNNte8/xqApRajveFSRbEUGh1G7jDqjQ3ucqhws0	Gxs6ZiO/bhZGFyKZoQ4d1jhrnQNdGQJ4dVip4/1APsWvb4mhZSFFmA7vTc/9
	MxvpwI4+kjHDoq6dbocNih2VCab81mqZNDM+YkBRuyqFDtqeiuLNgnSvWmVf	eE4Bw2rODBcN063QDuassSfwmNvHkl02j4hWiz37nh98f8Tv6w2Qm9OeYdO6
	UstJInoxv3TrhNJvsZES8qiguvd2bEslI+cDy3kWE+kGTJqj0WkSJzqE/MFE	7rDb77qn74ZGDaTsZad/PnlCAaNyVrxCS43z6Dgf47fffju0qh7NhcmHYMIu
	Hvs25KCiwLABA1THMDYxrij56WMUMWerzwnf6XW0iNyKXlqR98M1PWHAST2N	ci0UCXOHKY0J6Ac2AyRqV5id5SuFuxc5CYfL6OXdODZkp1hSUcR4ifZM61CE
	Pjkb+mTHeVQZALlRgUBsmXF3H7ixwHxPf1on7qY5aJNJkEijTYJJ1tiRHS4R	eNXUiLZv1CVteam+BGlRIkewRYVAxp1Qt1yeUBszjfieSrI2bXneGueWU+dW
	XvQaLio8w3AuBvqvU1ov+jRhA+boLhjQsgY+P9N/MQJk1xgXaQnk0DD3f8MB	X1TjO2yVZLkoCLyXFKMZduaEG4ENCZmbBSh+b/qyO1NNNdTUXc+H1PoTfnv6
	RudRryyYsgnw8MMeGbRHsVE6bhs4OZAffiQTB4+hwNizDdL7GCtXJzEZxwzr	sySdcpHPUrxB+QLzw9H920OcxMDiChPgeZ18SQjagEowsMUWC8stc58KHbpc
	g6tpJ7YOemkYr6W8i/GwBBUo7pE8FUPNMTaCO1GxMsPTOoSQxwsY7MJ/qQJ5	CST5zUhS79+/bA9krV6zQ/jOnpuV8CgNsKWvbRQ8SviV+TZUhPj+7EYl014i
	lY1XmnXK6TebfM0nIJ6EVbyMGN6MLd2FOsu4iRQZHfC01YKWlKgYLloV1MPx	OSEujWf5moETaW0CW4BAGcFHSqzdV7MhPUqkcYMMzyT4kr1MTZS4jE+84Z6e
	sc6iOKP2DiaDHINDmT1JYd2kXh89fomJiEuKENAQxnbZtgIEVb3aTAA8qTR3	CesTy5dUPeojgGoZJxND9pN04/KREyFfURdby4nIgWQQJbwGQ4SeR/X3phQu
	N1Rp1dWrelFfgAmDAVNVPihIqwVCaq7hBKgXuK5ah9QaLEaSZao9vh5rSsaB	vwSdNbdXRKk+eM/iusAI+vXWTU5T2Ud9K/9UTE1bO28aHWgB7JYMXPu4xQ+w
	ImTinhcrMbrqOI9ZLyQjdRYTZJ1lvqud4mW4087wq8H8LBgsnjyH+qWfEVUo	vwgxoV0tPLnvufYJxel6RRsdOurlQg1rvcw37RCokjW+4lMBIhSIGAvREXxL
	tyoeyfx7uORd+wSz34COdkccoH0EPmK51O3i1j4pVcpdhlkqzdBtw+wVZJGb	EmkucC6Uy4N+ctxisZOwZqinPfTVA9uaI1NjaAL/iYbgUXac7fkp7Q3BM9Ex
	38Je6oiUNuQVksniIxVErCip8iPiITjjwqPbxmfTp5rJ3A59zU7LJcxLQ0Df	zHOvQoEqMUf0LHxaC80AHYIyfhyyKOAXXDvkAVQZSRZ2gClJ0thxSmF7KZnD
	dIzxHLmbR5fdMjpe5MEOxjcAc3HeiLDCD0qxe7ALWkY5yz5gf1f2s0LcBgil	YDS0PDY1X0V2OHgHGmhhCAvdSzKyqpk1YQMYLQ1vL8heN6PyZGAYECtWVcyp
	fMAxZN8T6yO6S+gfMpAZM5JtK+a+ak7+hRUbebIlDiQli9BekitGBpkjg4xG	GzPGSlcUcuMUZ0MxBFQyIK0IjoEtnahzpciIjwXOHO7reuPReWgDfn72Kn5N
	NoPNysdscHGEp4bdh+ExJsmo5CLsucjFgpXFsXztCt/eSIZ0MCcgDc+HaTDn	DwF716tCEeXL359I5YA4JU+cL9ng7aV0GTi+3Hb3DqAllHHDrTiIC7zUX0ux
	+QNdwFZUGKMlWGp/g5rGrBTn4o8a/8SbURT253uD6sa5X1fEqIUTK2b/3Rwt	krivdmdG2QAIbbeW3l8N68c5sR6GzGeoCIimYpqGsLvUh4hTyTRnQy94OudQ
	OufoSIrpzbeqbUPoKLkFqn/2pbXgV2MG0xmKc0XCciQSD3g/5a0F7Vjgbrpn	vcyhFYbWmdyCB/lsMuJCbpDSqZ6rGVg0nPNNBC9Vflxq4y+R1+kUCG43F8SY
	bJk8ubeYBWA0J0K1rE9OVChkX9Phi6Qo5nPutxG8zNQoSHcstFk4Mh8TWvql	xgLTTaRpeyltuKnXglZCc2udPNmW9EVKa71t8gWbisNx0fhLBGl2J2PYZO84
	XSwKrTQiPwTOvxknYENQWrt+kqW1wI7mJRq3lhXEQPTw4DTldwWY1jMp+TpC	i5DE5VdmXnikbyduV/IOhdAdW8O9HOw4i6UV5c31A1y+ii2xPtjON6EsXhhO
	9nDpd262go+Oca4An2+YEZEwBKtLuE15CPhR9chMTWVK8lchrdZNL0fSwI7k	lNwp9VltSU2fTBF9taPVwBlZPtIroeW4pumS0e/yihFMSh2cAUeJQBIcyos+
	039XS3X+R/zhFARLHuxNbXuTlhYiJZxfTa7UYYi1KcIw+U0fhYPZP8Xg/Voc	vq6w/DbEwE15L0cjUFngHC6jLHz+zPthukGMy7zKey0hpBzpXUHUFUF0CgoB
	VJItDVQv6inlHFsxfFgRE5UKOQRiaLut0wZqdko8WVtD8hG+FF7rCC+mskCR	3oEKzScuyjlHtZ2sKnG6GaU2aubr9lg921OqYHB+YVbDvATOWWvXpWClWxVD
	IF4pwyfpsa6+p6vmXGL5zF0yg8qq2yOznGS/Vgt0FQW3G+LjA+wuVFPmgxG4	nANA3+tWccZUDxVnaQy+3joBtFxuBQwhggUYvB0b0snMWfY7z6KtqGl0m0TQ
	ZRpt1B0wfilbMKlGza1wiIm/Sxw6Hzqi/uXCQVVfabBtq/CPLIIByydYBG5W	hIAKyNQx1z9Pwf6YoRUA6rzOwboP/cRpZ73XJ8Yy9iH3W72PTpEi8YgyCzr9
	rIbCJVCAReMg/FKpUpuktGxLoLgNjum+4/prEjXxkcNYI2U3tPExkT1b8xxW	dugAG1AD7upptOYstWbHYWqZAJmlAS9vlXH7Lvhhkcz8QMf5V2yCeHGtYiVB
	VW7WAr9EkSgIz3O0fQIvvD+fUbsbr4W1di/+Dl9kbVB8TXmFz0Pvpf34zvUY	eUdmjXjP0Qg7r1CY4V74RVtG0V+aoGSLMrRVDufDX8MXY1b2Bv1MeE2uwKgj
	Yf2LEnidMoBO+7053u0m76UmHu2N/Tpua9VxAzOooR19A57Bv0g76ulHB6dM	8dyw89b5RGumTLkFKAOxzw1d0hIzFS7RjqIWDiPZOBiGXI1PtghbZawG3cTe
	2EeHykVt4/fBBqdbyp+KtD+hJMvPMFl7Fg5BXIQwtRLwxtwXChp3DAuzh+Ym	POZY4V7NOlEW4SvyhVNcyxisknsq1qaMim78ODmG280xP0OhHdzz4yVMdulX
	0uNSmD30dTbUm0apnMxd0Ly2tuomGRza0xOXlMN7NKOpve0XAWIwZjtj9e0F	6ku1xBMijXtFAM4nX7METDRiLi8zhjdjB3CBhzNWNzmYE54LlX2siosCowVs
	vr5xbAuuZ+tY/ZBfeLv+wZhpNbUAXsm6E4ExW9jcQcNsgJJTOCmOlHkNtjCi	KZQk4lrkutWm4mTfoLctsyPCwQnqBLpQxMkkJj5mGxtY+WxXKYwyX234AZZp
	byX0sTrBB9xvBgSOTFj6Lt1mJdQlQSZ6oRgdXBIChyRHwgc7pHBaXhKtNiOl	PzaaKg3s6nW9rM9BkUEftLIfpCRQ6beEldTUSzxYLZNrTa5LL4hXN1rhEaPd
	UDlWIBzs8HRVbRaTL5aihvjImlhlrUgEJKFHFCAOElOnlfLKlh7dESXFykBp	TNzTYi26Vx2HietloeAMA+w3aWap+UDcMSv9ZjYjWm9dhoEmCKJ+RpWz3L58
	GCYMTBw84ECPrfKS0OvaQMVD000WnmZPA1Eaw6Go00Ss5dT+6EvoViPYtKKj	JPvvc3Jv2zucG3ii46Ij9NskrOci2LHco6sP/HOrmZahkeP1Mx0UDJKilh64
	veppRUJrhmt4zhgjNFjKdec+Vc73qdIzqDR4co6z95uJwemihLVzjQzSCF2v	FzrpPYQ9LLlesLLZGKne4NdkUWNiFFzmjkChQ9Cod1os1BvqdFX0URYFAfGm
	nDL5kH/JL/KPZ4s9rspIXkC7F6bhOm+47rhf+xugoR48HTv5SslqoxukZLeQ	zUnMzO2eWXZaruBUGspm788xPiF3/eyyG2bHRJbsqX7DvhHsi5+UpqbCLWw5
	zPQ4Z+9Gz+AGP8CPHck+/bEb+RNbKqmdPYO1Ce7WkBFTqfD+t/MVAE9uS621	mV/uIbsvhJ9oCmcaoI89yCG7oqf/JJuWAcWamew6MfdVe/IPnNjIo5exY7Df
	pa/fNvhAR4XOj6+2VhCEyZ5RnXY8fRF/Q0xaQzxaW1UwnTi4vtb2M41Jtk66	yJgtcFIJHamENLM5cAuR897QErynYMJc1/eJ2DAHeA1cjWkb6REyXUhfqdDv
	RQJH94R2DDbUaspo1oN9c+9Ec/K7LMr2buHw0BHCKeH70qBTc4c9rvBaYcyF	TcnPwwtq+jOT65BXMf6R74Pw7M/fJDmOc7+sKZ1WO8Ld2t4iWUdyqY/1v5N3
	vfrYAhpa6rPjsm09REFf4W6eyEjNYMrWWPgBcRO0YShhMJmQuw36huot33o9	G9hSidhQ3X4oCF9jiNgZuH9NtmbvLkp5f4itTYyy+eF9urUYD2TmYmiFVkDp
	61WUMV5A6PXJ0224F/lAzwF50Ho17uoxyhGH2tuQ68HJlpKzvqpXWYPpNH2W	cPGhE6gP6dnkiEF4H7OeO22UxGcKYqSzHaouHPCIcVv96S65G423R0AKzjnG
	2PCGyZJsh4cAhdNPqS79I/UmRO1Ku/QQnEjsKMrmUVjLkwHkFnxk6AVxUZMu	bZ392ueXVC5qC1yilmvhbUwqJApQUxBagI49l8LDE0TRbwaSb2J8jhSGwTcY
	rJZl3TeAJJCIT0XeKOWcNllsND4e8Gysy0t2Vq5zj8ScDeVw3bryeSlJ2MFE	8E/EvsGSJsROiX2pVLTk3VKUTVGFmGU3uxhJV0oiVL+6lqAqTnj55GAcDO01
	4XL5I8d8XYSo5Io7tQPQnUQudHNJzl259kx3MJswWMJs4BwSnEDiLxLojAur	b/szLXlFxEN/rlwixjn9pu7HBJC9gxNO4RRDIxsxWMmTo2GAZT2jmG4rahCz
	xdTpuGHsVKAI6Iv7LDLv2D5WYDhYRorWuUPkkvfbvfa68sbNPxwRg7lynOPz	RUIGIvtA9G53zeYB25sR/tvOkEeUzwsvdpSfp1RBHiI+MQOc6nOLfTfnpPaC
	1RvYQau9MT9g8kSo1QfY+v28DVdsmZ3kgUsaR93asML6dxGWLPkmS8qVsG1s	nho32EfFlB4gt06yX6olGpDS/SrEIBKQRVTa6J0UeIW4CM5rvJge0kfLJuar
	Pe6kvZRpa3JnzrRuoMbK9Woyd0C8UL1/8LcPMZwlnYJvc/S3B9ZAOn2PjpE3	ESx2PvHaxMrzLiWMfHaCrlbLR9dehZFNGsG6HSaF63mtQSYKAHfRTChprFT6
	yNIHwicS8R5i5G/4mj4z9Q0JEMP6WXax0YHBzmEH1rNWcGRKUqGqon19o2WV	HUQObVOtuHeU6VTlEmcziZ30LCbVj+abXmWDplfG8xf1H0z1wuJ60x570QRI
	MU7+//897767OOxjE2DJ9ciIBvbXPFXqQ5ay61vKQ8tJcCF81nbqvbJzkbs8	j0P4qXPJfY06RXn27EtJ49UEhGGTRdmUlzgmmjftx3duAIZsXjZKN2GfDTvZ
	PLjgOYf13tId6XYHeoCUqacTEOaM1oIPhM/6oI67mfYGm7/FyHexZUn+fWSj	vNvvvZpa3rTXdre5qbHNNXC4Bmv3DRgP/yDWrkHdTe6bgO7u7Hfpi1x39DTe
	tutzLjPpyM25xVB1NxmqN6k3W8dBxee+xCaFp0rFuwu23h202vbDwt1Gz7du	UYlX9LuPask3RsnPgqDEwwgbLC5yjDki2XHjvbCHqBYiPjQ55kOnNoM5G7Ga
	1/mCLXpzvNBRbIzoAVfg/rZYoDT9ihB7cMRP3Cuwx+qBmoh/0Zr8X7Il/3ct	FwsXuLIt9LuOItM3feJ6MA4+sdR7tJLNtMl3cx2M+81l6L5ndAumauuYNZEh
	SbQjhyJNw4dyXFC5TerzLpb6vtAwRMPLDH4zRvt3mDEimpFBf1XAkgOwykwp	eRvehJ7WamZTqiXxgbC8WSfmnjPRlSg5bNZP7mVkjp0dA3biV1l+4V31N9d4
	6/LKRMCHQQ4cEdC6OaccZhlXWAgk+TJGxeNW6EKtHQwYLSLtGmrH6oIhHfbG	eo/2bbpNi4tMnFP0RtFR6jVneYkTPdlYiPMjJN5tQ4Gavsh8hZ0kHqStzWLs
	JqpDKX1b0dYk5bYoI7LmsmcyET7dmbj4NtG54nZbd8p0pm3AMXEYJzyHV8Iz	0ZJjdJKFMLHcXDNCsE8DZmbiJDGEXSm+cumzbKJopCbLYOgx6rlIBf7A4NZ5
	T7RbuHkr38x8ysypKeVY1AaUu6QoV2XS3CISU4dbVbRvCgtZnuPywCf0eXKp	SWUF2nnI1wyYdAjaP3VhqfeH/FUT0bH7qsr1CKr93OXQ75Gur4fLCb1MrmCg
	XXXDhEYN5dj9SUJf7iyzktQ0treOipTSSDoB08OYstd5Vu+hkTS+vxrGq0Ms	MTp3sMjw1r3fnO/9pkKqNKn+7KQfNugD4aPQzQv1KtIM3aDYt7eQrzVa4+FZ
	N6K/DDxvjrg6USx7h4fwfnsgnx5pqu1j2uI+tetAp5mHE4JoInl5GMIH9Dxw	0Y8LZnovoIsM23CVN/N2hwlqknZ9YntsoSs2sfWLEOfdAZ80AF++HbaISy7B
	HbmSnvUa4+QnWUTEniwJqtHrptSPSgiN6TEDMzQQk+DFC3bZACsvmGQvfnn+	zx7xbr1UjsyQnRX/zopo7Xy90+PEuEDM5+2ehQQ0txMTwLZ32LWAAMGGdpPH
	0/gYMfSz8UusBd0VG0x+QbAjJM7vhYr4zXtqs6Grpbl7+44dvWBgbvRXj8Vu	BNCsFBOCIzyBeAsj4JEYkonQ467hySSK8JStomg6+uzcepupHf0mNC6x7lpT
	Y5x/b0jMjm3QnL1F+B6XYJTtPNjxXiYqvVBM8AKJ/4QNmefSyBNb5HiJVgiw	6bRJt8tONpjog/b8LosixztwaHSKIDV8Tyc0hW5x2TXVWdCj4dI+shkmLXWp
	/KwrfroWemsBQCxsQip4ws23R7E0mZRf77Nc+k1P9h9+H77p0eQJ+HYhNE0e	ctmuNr3AuvBaT2SmZjJlayyCkAUVGGOoMjHhlNtN+poKO91THKgXFOXsA+k9
	3PA29ojwgOSLSSTnrIp9X6YQ93US9zXRiZqkp5aqBy+P9GEzOHwumnzmyexM	QVYy2FF101PtNSVIhtqsx109RmJij30bQka43VIY6Pl+guBgS02nMtbSW8xf
	93MNTwxsEfhtqES6ycse4IQ2HCSDZ1v/MUklRRKQHyEzQauwMJXVNlW2oMiE	4WxfTc0K4lAxX/2g+qOMEkZmBtM/77KelkVxQXJPeeSK3GaVGHxNPNhea2jb
	uz+P5Dmw+BHv3sC5+mzdeTYThE+gjvV6Ru6Wrlv9u2U/79pEj8SsyyRzb3A+	fsB3WKV0HR/UvJbUOf6y3KqjPeQZMmMv2bS5yn2K7DwVDXabyge4JPIHG4VH
	xDzsDCGnf0teGQ95UHiGFHd/TgdUN/Ivd1nsqt/tCB2KXuJG5EPgVvWeefU+	5uWPWV2U6sqVkaoYoAmKPQLMIzn3tTswHfZs4GEFu4F7SKkJ4sERh2Vc/y+6
	aDNJQzTWu32HaH90+yEwUISSqHfkOR9Q8dkdVLxLVLyZhrtFOoKFu13bb+Fh	T8ctmmeS1oA2vMSj34YSFnP1uYlColNJ2g1HbNi5Y/qR8oHa89FruULa0wYb
	/3c0/n5P5cNLsq9Q+3bOUtV/IqC34LRZwyFishzUAjgbQ98rkci7YFixlYRS	6DiC6OtusDFde23wwUShkOcnu1vYhoWJgrvokvk0M3WUXtPqxRqIUf5fb2UW
	9mFZPxXACLIFO0no76Q8FB4Iu0zBHLndnMqdNauna3panKMUO5bjQdTyghd6	ha7fCds6VRKSUdq3me5At4YO7BLFcm5QXbsHBIiU8MH/PIXs1+vefbPr4Drn
	NGh9jwbyKAihEnPaFKAmCZCB9Et4N5hU4sz4T16WLbb5bp00Dpux2b5cwUu4	HdCwb3Qz8jrcYFBKAUOsZ6xyuGZNQzz3awIeBh637GI9hRyrO7wIHoqFfV8K
	oyiooFawaIqIR9zUum1DnQVePubraFafFZuaGe7CeDG4jrHjjuhSiALND4Ox	lCkM3VesWsgk4zT4/4clPzQ60xY7pUq5AeJW8uIt+kIgpWa7oZqdOlZKVcKx
	c8qNi+R0ME8LPLqLliqN1q3ybdXzpGNXzh05wDvA8G6bxqlduJU16ozA4Rz5	dgNQlp2LTO8d0zNWuDn5XY3HbjbGE/hjCXaBSeuoZ3gH/HyYU3I768CUWuy0
	xoO2CvVN9sE4oKrmZktNhqBSiZeUUgjEDTyKBcZ06Hxdr9hF/fy5qsdtVQpX	E1wv1Iz+gkjFbTdTLhzqyFa6Qc911+m51/E+W5hD4AK+amqYbSyYBi5oirfg
	P0Pw/Gye0CxhbDmaNXBMKmQeYLoPPFxDEGVETY9VX0Vtn7get1fKxSxLZAtg	drslirsJqnLTbvIlmwRGBpEQNzp4yppAkMidvIL760W5g6AgTNwr0OjqRKnL
	DQCpjuITJbNVwlrNijJK3IAMtCGxXO9CG+yoJ/W69dYr2Rx1Wnni4/VrbEaI	P6iP/hdpo//VuihqoikPVlp+x1Wzu+g/72L6TxEPJ4t42sF1Y5Rhj7FBol1J
	hawzMM+4v7NAH3Hs6GIr76kmBORblyltc1qvVLBDKokYah+PrAYSq1xsxgZp	Gr+SuplI8swUsDGvjMxO51uwg0GLIp0C92VcPSPp5RdxvQNeii4UUsKEUX3S
	QO/R82PmG6iR/i0bpo2BBYI1C1wPFYcKGI77ye6bdlpUsLVrCvkFXh8v5LiN	zr12ri6o4uGObKMSo9K39m1NYHAXazojjTB7Ilvh4649j4GNuK65o92tQq7i
	CIjqLtY5aMOuKGTS6HKU1npaLyjFwkpFaBSKrKnP12zQoNgi5sMw5k1LE81q	r/GRbgxg9iOv6dPwOCPtDljrSu8EV6I0qz7KXtSKl3sPKXprr2FMRKwOr6xw
	N/CjpTjyoc+rn1XTZgjRdBIuajtHHeFASXP7pDEcIysYxlpqUIU75P11Hdg+	436KymqKR4Sg6ebXvq91rmni86KhmLuXL7R6Z8HEpGy1vXFexKJG0pebBmN8
	/feyAqBUopLdion3Kkne0Otj7TotGtKrvTyPw77SlvDCk2/bFFHcOIlmi/gZ	a+fB8dNzaXwrQ/SMB29xBAgb4A0dIdgSxN5QoAiAvs8uVFHnIUXNDEYJ6ONE
	LKOgtM7C9aDcEPfHDPRK5M8iaUA6BlDEOWMueUsKqSRNvjADN3jyrgU2TGm/	F6cHE0ocxT4AYRIf0IrB02TwBOZynMU/yaKuBr2DQaZ61ZS6rB4COPvTUruU
	scfTBd5Xz/NE+owGQalutQQWVDIpqJeMI0y1XGIkTLbHEmXhnN9dsG6Pq1oi	8HLwEQbdLYFcDWrb85+f/jh+hjn+8/FLLPrdFz1NvqBkKOxE0d9MefWB6nVo
	LtXAWdAUiHJps0R2RoHIEx+BisawE+YR490A7deEc9yeHSDZXw4mVYDAJiAo	uGkygX3Hnj6Q2B396pFodlyHMJgSA8ybJNPBMXyPhzDK9u7ueZsVGWAodniO
	iOu/CVZKirYCL10as5sk6WmfIAuKxN3RaMoJbzzyOHPBBJRk2/oek1R5aR2X	mJeCGs67aWiKNXd8RCsYmIY2leKocW2/lifEBCd4mmBgY9/6UUxPJtw4WJbr
	g6SNxVs7Z6GOSgH88bw5TxOYzl6/o3I+Z34aXDuJPc6EkooZaUcDUfpePZZA	r+nx4YPvw5oeTh6DURj83mT4pa+zz1UP+YUxiuqC2bLvehZcyk5cysbXURP1
	fKWNqmeWpAUVpDt8TwSPjxh6oxCeEORtG7Z3O+cYbydxJDILfI45S21wjCOo	1FKT4SmSFjYHQXTe5HOP4ogXTdmaODsSlwS+DQVnCjSUMs8TuOkGeSYp54bD
	XZRG9w2FpWs6JWhhRy6UriQuXynbJNoWmfBwJHKR9OGfFTTsGZAry18SEpyo	9Ko8+t7+sxHCUbSaLqbU2vbZLjA0aYSRRxQdACwJcjIhZZ9sOo9ig8kcyG09
	AXhqWordSdsl3RxcpeNbo8qB5gOm6WbDT2njCRYt5eIjkcn+CHIORsgKvO5O	r5FfS1+74a/FMbhvQ0niDi972QMm+YhQuZ3BpPVvyStjTyfJJ8XAh7uaYOGI
	jmEmnJHSFpiguI7R6dhQqkNUPQI93bZ1nbdZSKsTsBs5UxqimIATEacTjvKy	Tt5lsWF/O3Ga8ojiVWRhcCOTzzyTT+tQ2nSQue98wLwORzeLgkSJTI/JYz+A
	ntGsW4hmUJPcMCcgJfQzWsv1Gn6dlsbqUTGbLYrz+hNsbNFeafV4L6DwBMMJ	BKPPbsHoXY/Rm424nWckaL27Of6OfgX/DNc/HLB9eEn2Fazf7lmf/b+QXLxg
	vjaJ+53Cx39iViVHhXKceagb6itOMxhASVpjxSucGQuJDDMuRIN7xtp0gaZD	zlkVIoJxTXICko7JBg3i3bxNci32ZVkv6y3BCpxIgY5k2GBbFv1OSoFhQLhp
	XkBFIHIitz1mVw8cJ2pS5jvgwW18+kUM7+TcfO+vIz0v6mldMbw/lLlwgZ4y	mk6S2wuquGnzerah0eJAqGi27D2i/jF81KOkPj5KhGgwpUsUbFNs3IusJCI7
	ZviMQJQ0YHecqx5hacPN1HDDq85WGto64YYkDSZawEhQHHeuA9QhT4tlOJ/E	4d2gXImB45e8KkHB/1gwbOYSORgp8qs1vIQb+AIbaiU/TtP1MYtr07ahCAQf
	Xkv4binr6YREbNpjMOvl/w0KVm1T2Tx0pKTyrNw3gWZgb6QkAa5AOnLRDndA	H/NztKtPim3N6IZhvuiwR390Rzg5BH/np8EZfcxZEEWYEvuWKMCLluqgNKUs
	Ebi4ZBRmpruM2UDipBaaSVMfzKYPxta85gxA3buGsTTUFv5qcEca01HpJINy	7oWXayJjjd7itu/2JkBIRmhjhjqnpHV2pKOkrULplR0Y51LV3MKsyTDXVFwp
	wTrZqYnnD2h+bjYYCpmMEheIEdjPuhwaTULv4NaRaZEw/ArbSJnwV9zE4l7k	pVQocROcYokuHxKwmzXbrJ8/V/W4rUppZsEZgX4jX9AGoVc62jCwUSpEmGBg
	Pgtf3ud74v+EApwtDpj1t8iN0Y5CZE032MbaRz16lpFpqEQ/ouupLyI9H5OU	F5SuwbsyoibjyqyiZmpcZD6oMmNsLVIGsDSB+EbxiULlSlytxlu1VteLHm3/
	eM74bsZazuLAU0ZnxRwi0kNdufp1+am0n8t79EwNv4QbcCo5ltN0SuisTAsY	Lc+70Hw+6gO/8YVNonXU/ZIY7//fYKtPLFGeg4LGDdUlGRMnjya3wv1qgEEW
	U27WrfRDn4ElLRHn+H5lwUiLamj3RCcsajNDgeG9tCv5fBkhmaCJOCfMq4ID	u+pjlvcrqQo2TyWwsyD0x63H4MMCwpDKQO9R+TH3nQmJ+5YNIwTBCcGhBVCP
	ZHYn49GoxREWzKULFlxBYnRN3GXVynNQNjm9jwrx9CxwdFjlDGmvPSSJDs8S	ip0HnCP8yd6ZdlZUcK1rcgkGMCdP4HiFKDnWnW9y4IVdUeiu0fNIr/WsXlLM
	e95GDRPQ98orWE/kICKqRnRtglmEB7Y+UL2vWD6FIgcbcJV5dgGuzgr8CxDx	hjmKwGUUWVNPN6zTIOFiWomBSpyVxs3VbuGjlZYl+4bKfltNyy5M6BMvUts5
	jYJktfgmnX3kdasr5SLMuZxMc4o2akHz48L8oG8+HjMNOskUxfjO8wX4HrgY	6rUIPJrbkY1BiqxhGhspkRWUmPdXtfK2WVgw336KTyrQs2h5r3rRIHp9zFpn
	8Ls4ruDTDSs6ixZ8DOEasyHY/sAojpxotsgUQgNJfkmp+DUbd8TlpraSum3K	RUNMdRA4ctjD3UKbeOh5G3OKm5DRbhEQh4WSlGZ0eCAUbIpxa0ds2CI6RH8O
	e3ZSBZvqE12f6pKRt5T6k8rRBFJ3LDOMI5DJiw0V6Y09R0oWiXgQryjtPVQ3	wIVzTv7kSyloorT5gordoODdSC4zxRHHPpVPl2nQvYiZ0SQohK6KwJKqOSWv
	rq0Xa0Hpt8G/7LgrkvRsN3NMMbojopigEP07aylwFIV/88V/Zn7eKs8om0hp	JmOXUy2PGBKT+7FCWpjyuwtm7HG9TQSiG8ApmgKzaNqsRzujgOCKQyCraQMs
	A++MDkLk/ef3EzmiL3wDkzvTx4rDYh7BuAXfKiROvzE4yhSOESfZL8evnmbP	ZR5hHSbA3iYcOPc4EL0L5mBTJSvZ+AglDZzygLQNmcUj7LvxJr2Ytw+uGU5y
	X8Bfu/998OjR/pMRh11PXxwePPpuLyW7/Z65ZfFZSDMN9z//6am9o3/DQXwD	S52J0RVGPvddMg1AcTaxUlasre2igGLa2eWt3bNQ4KVlBfG+OQ8Q2d+9YePy
	kmA9hf89He8fPB7/fPSqf8e39g4idAA3FVcrjoFKl+VW+Qc15N/q5dM4ZCpu	fMFIRHh24oycC/wYQxGPEi78QaGY5BlLl2IPKUoHKun3sJ4oZz8Cvo48egKM
	Ox8N/pkoNW+xjAy23s81uMXIvId/fyHiQ/+QlipZMdHObLTiG7RPQcUy8xn5	uGva3vJcoCOeyJFgS3AcI02d0SNbAZ+2cXnfsZvacbBbEHWKpeLSxHUtZTtw
	nEQMAk6Z/kwvk040OXaOI8bnXl24klFxsxRLg0HckhhEwvfSC5xSWfiiUZCe	vUU6PIhFruE+/k0zlz08d2WhakJoFHkAb05LjjxpV6bXgwt4fOdhkWneg9q/
	cxNAQxX+93XB1JrUNOUQbGAxbAXnUS7IAGPaxEiB8hCDm8OoGtV/3Ol7lXwh	briYtgebL4zKxWKRcR4pAR40kTXY3p3IYgYXkrIX2KO4yNLp5JCwg689yqm6
	xTan2iDe8Tjj7+egA+fudBaQ9NzOglSYgkhzxwJhcRo5/VDa70IAFccOzUYf	6fY6r7gQY6cEc8THaQhABKQi7ieI87Ke08bblNDAKbmhVMi+0GW0Fuc3fN2v
	pfPB55vOCLeRIaqDuiF64ywZbxYqCX39GDwfDzSuPOouqaUW1uYuhBrp20eP	21VpMZ8vi2n9Ce62MLB+bfvArfAYnQq+bombCcPiPzGElqMiPo5H1Jj4x/0Y
	DgTOrgnIuPL9bU9QkvmhT8HlZiNejlEvH94mcFtqG7ZE61sq2MG/zX23xual	Tb6T1l/xEWdGTSLtjIvU4Ddj7TpC2yEvoNIUEcrtANXXJ68TLC3jMfDktj4w
	1U+zrnwna4RlEGEFkqMG3lmKgodfSJsYD8amSBF1lcUdFJihkVlmvVxpicK+	I4p3T3S+988RqxcOtam40CCU31AkS2E9fIigF0dgm5xrMuFsza9Lyz5bUUac
	1HqA21oVCz9UKvbuj5V+nCQT4HCxhO8z3hzeMU5xDeiIaKfZ0KOPdiVbR4P1	oIISFxNOYEgodkPXIVWiX7olYTs1XMLSpeCoE9C42QCxLpE2YBJuVUuVG0Si
	G63admhOBi+bjLReZ6FoOE4/LT0ZPbOwpmcmOhlBHFkjkFQuTF+EsKTbxMD5	pU/UinYUkBAOFMbAwT9rZRG3yD1wcU0rbE53UUTQXnG4C7WlmXdu04qx97UR
	QBfslS13bRcCsCyY+57fiz42VwZQsCT0a9Sau+pjZHmtq/LvGrlN655kQzsK	BciCNzAXsPtzKrTeIRVEY1As0cBhsI53Zjz8CQHAvTtDkZXh5ZK6BHq0nod6
	cXtMEhr4MB2hMcJIk7O+JGmQ840hIMxutZCuTwwXoBinUnFjczb60HyxaUvS	ldBMuHFmWsQMX50XBgC8zuI+Lt9EJrQAJH7+RgyhUBK0wxKzhhfZM9pii7Tq
	5H5O8mlTt+3A3tARw7jQWkM1GCrrbCzIP4oCb3dNgt0gUZgtEA+Ye99gwx6k	BlvFe9/HQEEyTcboI3qemozS+Bi+RHHj24VraY0DaxmNFiNJWFX03ST0+Al7
	ZTCfeQdpcj+XTBRBaJKguNQnLpdYo0Gnnk8fNkVcpr4/CWfmionQpNXBr9ze	gMuNVLSGL+EHuJXs0Wk6BfRWLAj0LjcbwqPDXQOFWnzP8e8Vp6Nf4EPXJxK0
	KurKdQ3+jqcN8XehGYkpNua6TN0GknptCim13VOM9cesWX6XLbUsxAoPPhef	yNEMSIc31y5l+TJD0kR75NyD3ZUcQ4bzMpaNKh7hwFz/wIJNSHC+PbtZOfMC
	yfknsBurzRJfjkkdjDBVXDZ5sYYHMCkss5/HQUZEJ3lSDyua8miy5OyzJ9nu	+E1O76MiQZUHjgRWzsnztc9pIglaYjPpqKUH2mB5BeeJaEmEzYkWTtCOUGrr
	+/Rn1IQ4AQpRhys4DPbwW5977ArMZ8lJADioq962DyCXeKBMvRVR5QpzrwJK	gGqFxfQpQD7YlK7Ms3OweNZgZgCJbzULV0uA+ruPOH51peCTORe4aZzRei5o
	BUAjqyK/5NhOW9gVIRb1uVC4UCCqkIQhEggfyn6hY+w33I/cm4rdkXTJhtPG	f1zYHzTSx2OGwSeaIk/fNF+CCYKHAd/FDgYfeFiTPFqyKMIzZn2w/YFzPXJC
	cbjNGa4VBoj8w1OGJDMbu15gewzX1RGXhi+K7ZfraVtaSSn44LEcMbGoUDsk	VSONCPUk+ZKC9BvW8Qi7T1Umtd4U5+5FFVSrT/R8n5eMvLo03FR2KxC7Y5rh
	HNLH7MdsX6mrk5NA46fsEegJKcBTJJRuCWGIVNL5p1J5O+ynuvitfOx75m2L	LAPZvFhZkebzCwSNEdcHQcnS3UN249p6uZFygDaYmR23BgPxvKECRL/H5Kc7
	hx08ioR9yG1hD58zDdmS7McgxFRjGl5yWDkrb5nZIHRgR3eSPMVhVNeb6qhJ	IQwMctW/s9oCu1P4my9+mfm0VWRZVpN8+yCtuSNZiH0f+P2EhumL8EDzznRY
	99YaFLp4IkY8WYb8pRLqicC2lQSdg6gJ79I5cQlowy7R4HbEA+IzDF7Hv0pm	sVvMEJzR4JvcxIG4AWAZAdD9/OzVUfb0OfzP/r/de/jw8PGIna+nz4/vPfzu
	yoHpUg3NjWKiJ46EK7YySChPzoFc+c46WZTeEW81MObXSmkjdfhWxdjZc/Z0	oA9q/L3vwvn48NFdBBqHIZ7+eGR/NPzNvcFvELTrCP7/6fjw3qPxTyevhj+6
	sWiAMBGe+dASi83DeevkE6TR9C/F5hRZtTyRScdYtrzT6DNmQOTcDrw70v3A	3/sRIU+A2YrHFjtEpYt5q8CTGgNo9fFZ7D8VM55lhB8Tyect1rPBHfypBjMZ
	DzXgKDrRJHyGtNatEnXABwvbgbTOeblkxVEisQ1WK+KscbSMjyQMg2WmHSx3	IRfxf78Q4qUfpKVSW4zCMxKx2ArtEfBaBrkjG5QgTMBI08/0MenIlGNHRcL9
	kGAeG8qawedqGMGDmkKFomFUStJTtlIx6EUGvtx0Wmk+Msy7juMEFgc/kJnh	HhSQK3IW9/WxeB0EK4peJXwvvcAp5oavZwUymhqXGvJy6rWDn4F1gVJ3pVqu
	fQh/h8h7dnwAEyPBNDSfXd9NwsOUEeMtgA4WWz8+TiwsCJ5dfcdFaQmKmjA/	JIKUS1LGGC8z4qQ8xWD2CMieMEKaRli1rJC8nfiLJm+7keN5xutnJwSH83QX
	68OHTCU6xL2e1NqiI/xrFdvM5A97TxBTUZ/vec9wPKvUL/YiD3ZESUkjsksi	EPze7oKUvgJtc+sKAZwaOV0oXXxBq4q9iebGj/r7wYJOd8TRjhAmQt0QtHXW
	oklvdV1y4yvOxFGXBRjHi/fv3546brHQ+vC4ROqUV4vYKkpmi9RxUuCmkUOK	m69pSuTL12B8lGxc69RdUHs5LBteCorT/YcP70nOvMYk4/r8twNC6e0PLQWP
	muBZZZE2a0iLCqhvrSo83r7UYbXCkJPm3girSV70qi5beCr+fErxwVGIV1Ms	mzV6kaeePrxy4HbUUOxw3bdUHoT/a353o6NeulI1m8r3iI+QLQLiMLnEwxfS
	ZokQTEEgYOm+GuKUb1PnrR1xTpULffkSqehAIuoBptZst61dUgURgtCm2e6S	L8hne5PniFox4w0KqOCIgbNZrbUO4lBqSsCIrYqlnyrVog/nSh/3IgsgZSzs
	Wt4g3G6lCrfXf1OIY/2X2Z4hle44H5TyFj2+nVz6GgxDmIGRq2rTmF65zPHL	/5wvhzeT+8kOaJRoc+bQsZJuJatJySqRVpU81CuDzU3aWtzAq2yjLgQwnCyt
	yHe3LUWjM0U669IvTt46b9pTe4HzRc2kVJp8tn48hTjOQYS7NRXqimYKDwkH	LyI9prTGaia6GYEcmSMQVS5Nf4xwpPlOQnDe9QW3ZfC7m8gAlAzugcBvRpOb
	u7ZW43FfE5NW/ZHAT1Rbsm61ZIwXmeTOxzStXxq3YzatZj/qCa4tKDH5QFqo	iw/IfRK6mGqdX/UxUsI2Vfkf6svtV1nJlXbk9fYJS6jr17Y52Ujjtb4AKg1R
	6jA+WjdUunuEdMOoluBFp8dH2W4ZtTbQplYc5r7EWB9V6O2xTIHBCMoLbANh	J5VJjMXFU5U6CfZ7KhA7NiukpebLbVsSN/e7ks+aum0T90PnDDND1Q1ZYajm
	PyOznQJBPu7EsaJwHOAHhfa7ep7mTh7lidTwOn4C4WtD9EEOa6Ye8wEHDiFb	s/4hPxQ5424bFbuGqjCEIBYxN0LC7k2IHmGWeQuKcj+VjGdBSSaBeamFXK6w
	QSfUj7Dfm0wbfgfGl41swBnjPCItlGPlNJUKSaRUJ7V8ZZRL8gxw6Ak8ADKF	EIQkn48nNkVcPX84CXJzzbBt0vTiF+51RmE0Tf28AuPHA5z4X6FOiTE3hujs
	DCu6VOYKmBH8JgzslNLwEqeh7CaGZzB7r51I3KGJLW0xUtGsQBsITg0UORa4	2xBE+domVQrNZ+j/jzG+/E1bae2JJR8cF8fkqBQokdV2hS/HSA+6nCou1Tzf
	EQbjxrJ+A10mpK86Gn1o2SnNmm50NUwCmDSKSr+pxqsc+4AjYgVRmT4fhblW	wAAMCMwIq7HjEZOWPPqIJU4ZmtQ6O/Yk23/f/4x6dffyh6jdGQiEA1zrU5/S
	rMzkyGCrw2EIlXriyMJLTX71dQL3dDgcZOMjkmCfdjY1eeI4aCUkwvskTM8l	AvtZcmAAhHU1uPoh9yWeKCOFRUDJgtuseaeSVyOnIl+ys6ct7IkQhv5CwGbI
	RV7gYKvn2NgEPHwS7VDfIWscklmuy5uLQkPwrV18VaI4FB/BlNAQ3UQIpxBq	M1VIGBHho4/lvpAo+xVvJDcqY9ukf2TpOHLsf3MGE4azRv7ucU16OxvbYaB/
	h3VvGGNJBzqCXAwGAHvFSFtX2ddDa2Qq6JwcVVgGAX48nT/Zu3eih7Hwibq1	pCv4NtJ9kAtxU6WB2rBZAg3epSyCJiYW6o6Fk/qY/TE7VOTynjxQlyobCF5O
	jDzAkzI/RzKpqMeQ8DwDc728wDyqouUwtYXzPF+sBbMCRwx+Kwec/TgwbkNA	cnYq4om3lICISOL5p1KBRexiXfxWFv4eeN0mzSYFkoAVuZ3w8QvGTVuRHhkI
	TLI38EI9Hdyuz7YKTbK3FTE/LSNQ1Sp1FCi0BLJDtV4v0Ig1La+kbIKjK5iP	mepaw2uOK2dpLjOXhAR39Euiqdi36hLbHfW072OYTCz6Nf1gIio96Ym8YvEA
	p4sou7Fne/pkYI+wLmukkyjrjoqhZqResVVM2DcaUpUMHA76Wlpi07NEOucN	RZm5lfijA9EJXNO0sD07hZfbeScIKZ3xjv9TMrQPbJryam4eFI04EpjbyiRK
	izp36mE6puITfJdp+4bdOqQOGo4ohGpNsnc0HsrF1/Yh9ATLThNcNkd+ImJr	eewQ7JngrO1FwR8xYkPnhFrxdwQKwDIbu4Ouh68VZQyEzfCojRaTbBHkr5Nl
	G+qBUAQ0ptjnbNwPuUJkwq5bR04NyQDmxRhKSFFDLDYIzI+Cgxx0x7iJYx27	SDv2n4vtKQJyebSVjhPe8k6d0xgjETkegIKkE4afbkiz6ISvsERpraElzIHF
	kpIvhe0kvRnK6goXi8diiaEw1OPEJChxj82x1MovDwW+r7QDXHbCbIrZUQRr	DGuGdNZ5uWI2UiIKDxZI4s6xI40FFHrIMtMsmbuJMOQOxdVgueph8FlPoSjS
	PDFMmTia98RQ+TyUgn++l9IwOkePkgi6eZZl3RQPRhRxWRnMJZ8GXtNVW8Km	AEH1Ali2ODJwSc6LuU52acQy7LvO4wUcEC6QmwR4D/8eIQ3ted8m+ohpaj7+
	yuPlRYWbeFjLzeu54QimnBh3Il4QNzzkjXV8iBRxodFLFhq9BM+0HPRcPWNL	vh85jkccM+NrgCYXa0PehSxIDB5pf89FUQtyqDC47IMHDIOawuHvlfiiafxL
	qQTs+nRH+Bhf6pSQggodp03sGOfPUC0Jexs6CchnGLElRz5zdhjAcyPG5fRW	FWvRZCF72xBDVZ+/8bbieF6ppezJHrSKkmJKpKVEIJleB7vglmgcq6N+GzCP
	z6Wrh+HFojmnHrS1twJSPwrNPzmENnQbzVfY+/bQ12gnDGFSTEaS/rVdKkxh	5+/fvz113Gyj9WoBL0vRwAgzo2ScS50muXQakVjUHtHyi6hrR78Cgbo5K9vj
	t5ZaB3JQ3PxkfnokG7eZBcOtIykLUxjmXrh0GVNNZ9y84PwzBwQStETIhVIT	60stgyv0RGlcjpI5yaZe12ULQ+LnM3IbjoIbO1cYds1PQNAAVcopFqemXDvi
	OzWiSNORPiGuJB9y7WrHeorCojX6o7SW+RKxG2TbclMNCvHIDHqI400sprKa	iCtXFvMjUgCCGNoJhNlsv61dr2Qi+KZNC+oV9T7CXDxucpIYSgFv/cps75hK
	u8/38AiWA61PYNrDWnhEI+t+PCO4lSpoAKY4sCvy+R7xRMgZSNviCzfT65Ul	b5v3VXntHt9OBn4NKiLswMhVtc6BElMZjB1XRpa87TQbSRbp30xfvHjrvJpP
	WPiQErtt4wDE7tKlRi6cJv608U5rObpsn3hqqiUhoS2P1p4mZMiIRsBwLlpw	bSamy5qxszQ0ba16cnhMgXy7DdUFC1cKgwQBrw33eN5XBPlVf6TkKCpE2bRa
	+I5etax45ZvAlttRJdZaYV6KBGbApR3CUB8DCyuSCrgelwal7m0+i0QpVEB4	bcaHTDTnXZ3WSo0blXsWgSatSHLtTIoxCeJAVYdu07qhSuETxElGlgQvOn12
	aImZUuknJkWD+PixoglcVMgQKZj3trUHg1a260iHH51FHx1FukhVksc6+4AP	ku2XUYsLbXTG3u8LdAFSgd8B0xSojsC4QEcQqDZS4Mkt5L1Q7DkKogAXFPpG
	2IkkJTQO4rDB908OHn75QjaO5NHpAVTXxuleX7fge054k9m24b5dFIbWIf2W	qzzNnQzlUd/wOR6B0m+DL0IENmOkefcDe5YtoVNOEKsrvXYXWAPz+oWlDpAw
	rYsRLSyJwFYBk4yQ0z4JAfaOeymgQC1LdlnF8FCMeSQhRCfxPBpBuPjw5dvX	zueshQou6oDQab4ixUGpFzBnwfTGAAOfkguAqhDjRQ/LPFFzo2t09JTSCRU3
	RIbdMtJHf27y8fbhzuqG8CI/Vt6jmKkRcLLCY/LWbI8ww1RqqRd5WTOTMyDW	ouwmBh0xe68tadyx8TXtUFhRsUBdCGQGEh2T3Aidc2M5wWS/kZbZNyqAKK0V
	f5ImNrQFc8o3M1pIUFtDCzPyNMyJSvFkwdfYbUVDYVj1NJLGcapnZoPDEVj9	EU4vuyonIds0cli/qcbrvLtwlNOCSZs+VIWhWCzuZF9hqxPiJCu1zBFCmPo/
	hvGU3FkjIvPt1VPy5fJssiCLtu1z6bgh6lUf/ah8lXFnCh+lLpu3X2u/1PH+	6+skG9ThdBBAkACOfVTaFPOJGaFllJgCKB58rkDyRAfXPcceN2DxE3mHIhA5
	0+okrwPyxo6BKdBIYZlr+CYKHqMKQfcFa0EUPhp/LilyUyxgNlP0uZO4x6+n	5RDncl3enBfqnW/t8Ssjxal4n6Y4i+hHlAMVvPBw8g2nYJJAxzQYkyKAbYOk
	qwjRDDOCgYn3LX0d4ygZKk+VtcFFw8VMtX5SrIGYVo4gMZ9srhse8cDFYk4z	46/c7fQpmbI7J8IKqyXAricJlL17J9wY66Sodc/IZ4BSWOhEthW5GeK1Z6C8
	RBFMld5tMUoxb2n24sONZjQ53CIhtuVzcWa2Lz3m/Oip0pFEBMGhI7DWJTjh	l+cYZNWMOox74U4vlhvJawFBg6vF0qBoJujNoYRN0jnwUZUSbt8HYwXl2euM
	w0Zt4P0oPYhgkh4YknRGGJHCG1oJi91kA8vw3cDwJ4hnjQwFyYd0lBsh0zd6	GL+WOSiLlYILJF1KxUP2Xi9RmTUt0KS+gj0uGLOnhyj4gQUSdmaglTBXa6TX
	G8JsXISHEnQH9TYmn9W/WMP2JgJuKxkpR8CL9I772nr81MsiB1/Wcb9UKexM	LHORilPSiNFi86Bwf9TVKiE6nPaV9EynsYRGFw0TPLduYmCo4hOszLQCxMYj
	glTc47zKClCEDIExr+skLuEtskmod6NA8CYQPuH8g9HMZm5n2mwcGaC4lum6	UlINwgpTuibZO5oPRetrOwiNYBFyghHnyHbELNyGGjkUIW1TNHVW81OmESmy
	sBwYu4ibkfz3owdP7F3YZkP49gOA2e8np0ClrsnnhA7Uxt3aljBA73Vwk+yY	m9aRkUN0gIEzTjkkbyJWJQSwSsmXTBpo3OKzjo1LCajCpZIGE2V1icfFc7EQ
	T482hFf4bqoF003bcGk3hzThafVUPT8vH0Fu3xydvkVlfPTupT4MlbNLHgL+	Vej+caIclHjTFliX5Y+HHOKX2hMwe8HQj9lJlP74wgB84mzeE6jm01BT/vmb
	dknNuAYfomDrzUn47SEFrumkhcE5KXwVtp9I6sI5o3NBGcegeqxgcyvjFsHn	PmakczSUeNZtyx0zltgywpDLyuRmslzw/K7a4U5VRDFPKtyJxCpwntul/Zoi
	uBikKSi2H4CgiUiLyuOG44uCOxT3DFmaQOtPaYLqGDPYtNSExqi5LMzIow+Y	OW6F5yCGeQgs6/wwm8Qle9ZYK7XcYcl6wJhSYeT1DY4SaXxlVA/LVDBEbdDH
	ynz4mYuXHuNRSKXtfPCing/LYJhX4fzgkgQ/S0eHmdBggqp0IacFll/to0os	mIIG8kkA5dBcQNDFUCY/tKGz45BqN+IUnsEZuv4ZouOxaKbUqbj2WkHfpkJ1
	Hk3ZfkxLSjXTwm+xh1JZjc8Fv135yJFVcSENs2awBklP2+WrBUHMA2rIJ7VZ	UATSln5GuxY4QKwEqCcUJkEtMzlObBtumPpwrdYWTFPJRiWF1Oe9cTtiUOU6
	kxDVo+2FzHkXIquMJ01qdHq1Zrq6hxJ2pkVTfk/tQez3EoraPGAu/O725cTO	orawjWH/BRCYk7BJ4i0KDlSzi6CXVhGCptTeUNUq4njEVwiwybtju9oxvyKX
	hi+b4jboS2wT59a80idxV3ujsEHdozvfyMkXV4OTcFAfdG0ImdshdbW4qGjE	aY3WKZ1nvsIkD9J2uT8IOX9kD31K5HXQq3Ki+08PUCCLeBuiru7KDvCJkCwM
	0nNy4uKMH8IgD+9n0x1ysLau0wZ2s4KqzW0viHFRcfmceeU1pfhngrKid3ru	UGhw311gCJTJFOHTfP6GEChEMNIt+cLdFgf1DDbdSNHmduMTYkPyUp0aTiOE
	bvlcY7zLjVInQjIjySwDbaHRxygMqRZHjq/WRRWJB0lFogBeOGmA14sdYLLH	2k6otaBhmkZFPW7QtyIeo52Da6cW0nCESaDXF5U7fEui3lYM9m1A/e2ojmuj
	bbCgwUDrc3skjbixYEYN/AFyrey3y5JR9c7nx/gApbdvvdEQoceArPsDLCpZ	2WGaRsy5mnYaqfYMNhlJ6ucSWB0U8rfhL6KsUELhU1LM1krbOSk7xBeMNQvB
	XI4/MVlFNerFgeDXeohdwuPXmj4vZGWSa0D9Kcm+R8uurvDL+QhCvTdggA4d	RZUQw3ZOoWsJp7vsZp4OF55FC4+cYcRDyaidf8AB9nrXOTRGYr/C94/vPfjy
	Ms49SwCcQyAoY0gOmB9lZaZOvHMfSbIU+6aUGEtQEA1xvqH0+GKQr8VR+JvK	hVQgCb3TEFQbxxHiUPugDTW8Vm07uN9MFKnT6K/mmiOJDphIYTexaRDJ+SZu
	DyXtJ8bgjENXNGfkXZzb0BdJoiykp5fEaaCTRkpQLJTOsNx53jMvCJ7AHuNr	Pnse71bIJLX432UVp5iiY6Tna3Ti+KM5hIePX759TSDfLWcK6ecmjG8Hd5Zl
	2pIgX9QXGNqi/sherDGRgY7xowfff48VCD4+ny4IviS4eymElmLoTkVCePv1	hBfFDec6DO5IjrOm1+StuSphl6lkUx/yNGe2J0ngf5Y+PXQhuQMd5xtJ3lfq
	Yh1Fq/Xv6BLo6RJ2eI81Qj7LVh2tpHdNhNAdku2QZKDmajI0m1JjeupUlPCu	eEYeVLrHZDzo8RU2lFGPGRZQjbS1oHCe+Y4JSYb+llMyuXtIBEi8A2xzq+OT
	+IiCdRIaPl11Clv6ePVghyRa4UC9wRV37AP52WBdo+fF8Sf4Sg7UHQYypCND	mlm07RC7x6UAY72zpPJVy50popQ6b76KrV2t47uoxU6eI+SNnQMDtBGukXmG
	qeIcHJ9SBRb4km7jMjMUZkibtI3CLBft1aOc20I/Nsl2T4l0KuVziaAXe7x7	f0S+ZmQoaOlgYYnmoMYLJvZuKg/MtYqWO4lbQ3sojOD8MDNIbr7vBe04H5Mz
	vIMFoknAFKFYKz/CSX9Z10rBMzQ67NVVzjwKHu8buCqK3WTSuxjMYY1tUoE3	76lSN9hzeKR9WdCr/cDcWHY5MQZurpcfk4uL5YL2iNydSsW7HJqiBdP+xUKP
	HDO633CCiKtUYTAijYpaMa4zjqspllLWefBQ5lMBMEVFNkeB+d3VJipU5kpf	9rQn9CJStvV4cVA3RUFGpgxY60iciGD9UdrXBdjsae034IqUPgth0hchErHG
	bnQnGRuwq3Ow19Ym5Ug9TnhQXsp8Eee5VMbKUXddZ4/H+H6hHQrpG1IgJZbo	PCTNj2jFk3adsiwLcMkFTDA3NlIiJIjSUUCFtOTofZip46KUKkkQocbYZOL6
	V+OquFiUFwZaxw2ic4qptl3gJwNBQgMMwc+rlS/6HspJaD1u0SabNtvloLjU	V6uf37jMbXkkBRX4oN5xV2SfgvWyyMHwddxrVwpFe54tMrQwWwaYImfRmNd1
	23lSVlJw6EwXs72noqBcyqmX0BSGJQc5wbm1/KopD9jIdZdxZQCTC1S+ATPB	4sjwStsk1NCR63gbAKbwBEC3Zl24My09TkzeuRb+unAg6OyIG5/828O7j+2v
	d8lyCfvJth7ItUdJSkHrP3bW01BWKqL1IQGcgxNROHJFKIZAvOgoNaTFM6Zd	sNmNdBMIydD+VjnNdeqafEGZhtr1XdswhlR+ndwke8aSpA3+GP41lZfp1W24
	MXOn/dj3UZ8d/N/vHsp6SUChdS3CVDXROfBK9dH6VaekIjVNGHGiemmx1Ibb	WJz9oDBaPVMj0VNIoNw3FTpvotWeAjGAIv/WhyTenJy+JZeyfepdGPglZizt
	yB+FgS84RC5gdI0jm5LRDfM1Chkdx3+dd359ykxLXooIYDNUzsAiQGwLzqwu	n7x7eaDzGXEOeDQPsO5Lal6WnIfmfm9fhG+PyWFOotsLYA9JFBFuEFu6nRTv
	fHKP4dPw/zSEcDoUjMgR6kdQ285ZRJnENrWDcgQ+o/KPCLkx4XK3UJ01yq7R	DDzM3g7upM2Rz5wz6jigEPJSe7dCeCc3vF8W3CB7oCfTGVjLTYNizzCGTtRC
	vx1LkzVJoEVPoaqYtlUWVbaY8YMMEKZYej4XOYqO1t0YicPeYtZIDw3nTinn	+SA1F6sZkvaOWtkPv3Mx9aAPDHHEnXeV1Is0GYd9FTASLpLwu3RynAnaJ3Bc
	lkZp5LzqZRViXk7pqkFAfel2vUXZE2GBmoQjbXqAlVuWKiYpktiZrjsKj61w	F+JooE7W3o/FFNaU7cd+patGd/gtVrqV1Xgq6eSV91RZPhlCPxtOF0HiQg/Y
	yDv+YwNvkjERBMASUDZoKMbFyQTuGoh74zQdku/8G+gMEI5T7qYKctcUnVbP	ekkZ7yFzyQfVmRkReKVtxc3BHsLkjDdNyoYGFXB6usfi7qZDUxhT7YHtryOS
	CWmY1iUTPIFQQqgXrwowAOUr2mJZjtGIAzdN0iaYvfdIGVuGGkiX0Gwg00XD	2iJkfXgG4cucnXWZNsVNyTexop1bbU1HajmLJTAZkBnoOGhEgMYF6kQcyDgb
	xGVjm7a17pIVBwdzcYfMyy5EFg1gGw/LEkWkMsUhhNMmRycKntq2cKZDC9l9	7aCZ2yl10syZMgFoHIYkjQfhNBNvz3OzYpbPreu04d8c234bNQdTQYqKi/rM
	wjDAvjKarZKKRLWi7x2RccR0O9RsilHx50hIpMm9ULyNLpdmJsmmioa4ZVLm	K68owWAumV70To9XLss19oD8UMpWiGYkiGaSa2j2cR6IVLEjEFmL3T9DneS9
	64ZkkfON+jp4mozdMfXUhueaYSVBLAyAzXIrpEhslxicYd1asbFzLoFD3IuS	Xp2kpNxwsAKfF3XCRKzboJCDpjeEHOn1gcf6HbUYkghg2a8XJaf5Ox+ZYzlM
	Yb4+GT8jCPLzogILYVzPx6cCn/Dby4qOj/QZ7iOd8aF0MZ9ecXLdmSD1NG+4	79/9UwsAH6eF3UkAvGQxVEAU0lRDQYwSfrPP9ethD7amGw7prGRuUFdPshlQ
	bJGpamblBcYXdNnKPhVTsr8oi2xbw/ljvU3IiaR7CgOc0BwbXl8ahwvwOovZ	T6wrXD6LMmR+CXU2Jayce9LLJU3lYhm1NKHIlJXZPbH+vdvK9hcwVc5YFoOp
	yONiDXxXJRP5vEYO0+yUELugU5CyLw51Uxtyg/mNLLGSCQvMYYbfrOGyUQT3	GNMtxeWXSSwZRz53qYukmKMolnP2k9GekRSbWk8bkaOcpYfGxG0gcSNlMTaj
	JRDtckk7GNdvKJTacvN1YfOK6xRIduU1LsipHD9efpjJxXx98NNM2VJDloq/	zyDyeXQ2TwseuR/deawyYkJifY5+NOot7WkbIyhocD+8+/33WBXhgwL9A8GX
	iMmR+hdS0IspZ9CuU34gQzeGRUZLAv76mmiXYLBhL2n9qymaEKK6+pyt3uCf	BBOyn81LbnunJCEtC/RhnUWrpfloYKiICdd8AGkhy7KVUGvp7dNrgzck7hDZ
	K5tuyH5ycuIpt13F/dCGMlm0FZSSaZRwMsH0/4ePeLDV0xRMXsZ5Ux1i8k2I	oIZwMjUbzWMw7j4p4a9iOSVogebUyUvqXeTJPlJywAEUhAsB2aby+8EsR8XG
	SM0ILa0DZ1J8BuCZHjseJn4TgN0g9hf19RhtVl5P2FCoAXIlySVP0dhHRFHB	s0+wTvYKHgeophOD9uIcSFGpTQtoTjehrRmQNQR12g2ylgsbG0DjDfiJ/m6S
	rGZ2dEtQRlP5GIar+3G4GK7usZgeytZtBc/HM0IL5IjyZaHhfIpPiwoF09NM	7Z8SMFYfbSbK/DjgO+RNNiBQyosRILjyIwj9i7pWiKD0DLHDWTn3ifk0rdRz
	Q9n6wQtXIEU/mJEE7fBQ1LwsW/WnRkLjJd+Ak96qQ0JEhuENUgCBBpMvKbGv	kXcok97PoGCrQ5Wq0EHq6M3DjSKkVc3EEbrUxBljkuPcmmIldaf3Hsi+ag5O
	lOJZVT/0lR2aMBfc1Eh8YgPmc3afSlWAVAiZD7vmM1kGxeQQaLPALrsq/wH6	UZEKUmCQeb2Naqm5FpkbWEq4CDT1HNS3jYl6Ur8XnhSRHNKbrzGdSu2uSL6r
	K2y6BSeClV5kcHm81vI9xo/R2+L5DZt7y57WalD/WJw+M1jMAwgukckTVPOi	Ons0xvcLNFKIHRErKRFHoBpXxfmyPDeZftxgO6dr03YBRw0ICvUxzMder31l
	YxFH7TUaRzvQbiWPCKKPQSdlGUZB/IkIq4gPyWuqQaoZIR5Gt6b2L4iApipU	eiogohXDRdu7vtk+e+KlGtBDytJNQBO9mB8cCatyffQ/DLLtOHagFtxdiw7b
	F0YqKj2imPDlJuqZ5lRig0jWILALMEIWHBamkVsiDapcn16WcEmGX4+DvaaP	xysbue4iLlhgDITKt7CmjGJSZcLNsn0Xcm3W0ofQ9cudD7iVpYvohIgEF2BV
	5CeSnZDkLnhd3XxRfFKqCeLl4aeABDHFhn9/Wvn1CuPtDMnyn01dtiM2Rkwz	FI5sE/JNEB480g1x9IzhYczuaU/7Q+Rt9/77dw/kxMRR0boWM2c10pp4pdp9
	+HX0xYxm4aiGVKvOLbgYme0CNcQ0X7FygN+FSmx/sHkAPKGRFRpHhsZLLFhX	w6pYYpcapYywXD29WBjG3WCVghYYbCQXEoeNedwHzkujSwpwHvuZnTepfcxO
	WJTNvqTP+FhgJoEAusEnY0gsei69Dl6mNaRj0l6QgMDnJYBqi6J2punHNkFm	a3GKKNcnVWfBRECwEM6cLyx6gEpqoIoaSrY6lnSVE+SVwMSds4lt4j3VJtRR
	fkiZw7YOjl+YC8GTwVzzToH/B9MHZncDhkCz8R0d5cMC+A1MSM1xmxI6ZIig	DhyuMk4hmXBBXigbG2VXaDVLRzoJ3kWDULVO2yr4K+vQuB6TklOsPO6MyKWT
	GWWPGd1D/gJh/RGjx1ChawgWLX3fAxcxvAiT+0EfJRAFU3T8A2Ev5dehb1xg	TTdGfLO3GK1S+eHcKcX7+s4fkV+JEEYPSPRN6DDse4YnXDsC4lca18lIez5g
	deBmY3q5Vt7Ba67oBLlC0eDjwQdlIj2BuxK0LxqElG6ZGJIih4oZFBl+PZm0	XZkFtukVcOzNNh1539Y48T2/5IDzZLQGSacRkNWK7OMmrqHmDl0pBztu1zFZ
	JKOjeG7DRHgicR/EGECd/jB4NQMjwMrxv0ab4Epo7cM8apkO6pGAC4g51ekR	1b8C8wAaOeW2sEB+TdFpdZ8gnGkBNSVKUN4SssjLArRCWUdbrMoxanZgwEmk
	CiaOij7udLdO+It37yjQy2HH22/09bdC4CSeggKiiNa1rVeXKEVclJWoFy7/	BrMIfOaOrZcNKFGoS5A+o97osrHd7Vp3wRyE/cV4URZlF1yXJpUcZWeJpFKZ
	oKo5PX8sEG06QMVsA0KBcY7li4DHsqMM/KlHT9dT9fwVdgjo/lgZCSm5lPaH	0hXKICcTKPLP2v55pk8NKYMKzURWNOqyEgpF/qLvHZHGxPBA1H6LM/anCKCk
	vHht2/IT95xh33S6SXxTVT+qwKVDDWpPvNrX2JUpZsTZeIlP1waHL2N/dpLF	wcVQZY7GmEZGSdGKprhjUxabhmiS4536OhhN5u4YK2vLe80pLoEwTEqdxYEY
	8SuQ1RkounoeUr6pd4D3L8o5gXjUknp3fPTm1avj18+Pn0fJLmdR8U1xwSgE	Zoi7nh4aTq4V1TvnIj3MwlEEz9cvxk8oLfppUYG6MK4X41NJ5PAXzRKPdyQa
	mYJjSuhlr4iwlcm6LN0N4cLi6VhhFK4L7laoBoiC/+IK0URZc5yT2QzKH6xy	tCbd83TIOtlw+MwZb/gsb7i4kgF25uU5+h/08MohgFTvnlEs2/bP83K+7UEq
	jfGctjiQjWefk5WyyMGH0EQ2BdYYqWLdeq2TUlD18HvBVpU/b/5ti8aq0yc0	SRMZTrpCHS19yjQPF9L+bAZJHpeT4Lsq2cynNYKvZqeURQzsBVEGY486dXU3
	C02hEakApNaIpXNHSOfSgCGw8Yki61bToUaJyJg3GP17WzCpFShYUcLlXiMH	eciRalYyvoKRbbhmdaeNohRkSuxdrege4xmmvLUt97IXDLK4joIoWF7jArWK
	fmI9F9rCoQ/ZtmRCgRfMAEZIxeWXnEkgJaFsaVyMT5EPvZQobsDBjNrIxWd3	LPI0xOAzZvXBhDOFVag3m4cY0mn4IDnFGCUHFT1FNTIgaVgGtaJsZF/C7Xp5
	qIxhDi+KcQyst8D2XES1G6q24zu42xqSBGos0mdMBpfM7tBeeZzJclr6RxMP	4XCjtErXFHUIwF49ZTU4mO4KAxwCrhwDOeK+tXgn2lDMi6qDAklROmWMJPUv
	tM2vlaibXo+lOxLQELT4K22F+lZs5mRfXVJpmve7Y3KuRb5h9DFb23rMcHZO	3iPCSlBTMOQah2p1ir01YaZsRhncOnFG+OekQNNqyKeuX5dUb6oIlvXVGJVY
	gDKEaLIh56am5hWjoW/wfS0t+CJGT1h0TBT9UAp8ZU/3TV7tiMlw0JiFrzrG	Ps/aFcgFckX3JSPSqEuEqMFYbHZ2K2BJM1kMp9D7ebj9JPZKSK3rdib0xztC
	zN4mS7ZFQVx0UUsSgVHwzOSG59z5ut/kIQSAtayVMPVvpWHJW2K2Q7BeU8pB	B+QIpGapEQPyXwsjBU3UbEPZ+skLxiE5RhhABRXzUHq9Kls1skYCPiZrwE1v
	IVZOMGOGcmpCVyaJcXTOMPvqtuHlohCgboQJbiAeB2ET2JvGZjxWX8sVCf2K	1UIhAMbwBinKQO3Jl7rYV0qJb4D1I5sDNvacezuJuWySC529p1KpIBVMZmFX
	L2opl1x57iM0PoEWDWbBLI+SwGR4G8fMNGBd9nnLwpDIs5MEVGAZN750Tt0v	LJllUoxlgRoM3LLL8u/Av8KlW3LcWdFQksfjuZZvmf4MzS/e33C5d9xprVj1
	aYTTlntBUX1n67dERCvF/QbQSQsWa8v0rqPIiEXXouYaxMheiCr5jCXAJwRV	w+L2mcmC2HKSJ8lYD8p50c6Ivfrqq6MbaK+Sz0uixaDNsgqzIBwtzOaIReUV
	vStlR3gSVVFQlFrDsMPr1Tut+5h+NPOc8kTcC/Wc7wrmPexPbvb53hxDIaJr	VUjVnLkeZreh3jaYmU2Vsi7MVFh6hIjhS2DUVM2p9IcCNJ5gl6CKLNltTDO3
	Grnwi9JM8PVrzbT62hu9kFExIVsW6x2K99VgHC8E6R4+W1kIKRZTXJQYM+76	uB9UXz+7KOGRDFdPQSpcIw9IykIvtMHH6hbL4pMCYxCKEA8CBMSAIP71/cK0
	RbJYCO2RAHnU28sZCOLI4hH/RMhH1hM/gV8ITsXMFN+Q66jwd6M/tE1qaIWT	V+iO58wwv2rqVR5BSGIUwh+jr7Y050ZFrloab/OdEY4vAFnM8jXzBvgulIt7
	7YBS7XYGyZhnNWZyBXxvUdzEmYbwbGdUtBy0kgi0iEtir2QeYavAsl0knERS	uebz8ilB2mfpkbaBQaqzTLOzbHimP8rHAkMNlDUcbDTO0UU7ZtDJzPTLdAw1
	oNnA9kVzJrpaEzZoPwzBZ/c4/eynn+RNA0gYjKeiPTMsJu/J27CyXEVVBVx/	DCQQMMgky9umdjvTvmQXJTOspexiWwdDMOyGpLXBbvNVgf8D/Qf2dwuaQLP1
	28v13m/jhhYlldamuGQQqx15yAQ082gnUw54PzxedWXGjuYL55+WBe8N7PIe	TS5lYSEHDzRJjaWbCj8EsqA9ZQsajUVegaAUidZjQNzVPYsqv+8VjEnFmK33
	uIW10aStovnRLt3s0ukZKntRee6pflCTpLimXNpMfFwuXTc6rckWCKi90Zad	gw4lyRCmLvoHSgWVr0P/vAA+wU3X9HEtCYTXXJIIuUTiYPng3TQRo8BrCewX
	S5OJi9lym65AUxDFwpntDz75sl70BIWFOrCXnAidkdYVGrAeO1TcVYlnQXav	tUKKx0wMqJJDzgycDFdPmi1R6Sje27ARHgDdOzUSSbA/JJ/mFAxQc/zXqBRc
	HT9/XMeYZjoFXGipJYmzjwYRED5sIi2KRLds+3Oonxb/4R2MIQrrd8A/f4/2	CiB/2EetH0JGEvIPYix4GkJzm6NqlFv9Wjf8+bt35ARmh+TNP/QlwgI4JQaD
	/gdOCNE/sS+R/hnTnz/yP3a98tgLv/xj9t/Z7gxU/567uQexUSE3X5gMKP3z	JmERHG1bry+QirhSrMdguC6FSvlUANkEuFkCPto6iAJKHtMX5UHLjTLpVgNI
	eaBz6ZfBC820C7jrd4MXDly/5cLPPcEYuvAPPGv4i0OU+/4VMq20np+fZnwU	vQGv51XYKaAVZGkkxOz6MEVk1GvzmR+5dw6bqLNtz0RVBqQcXDrtIP/Ep33h
	zMr8osmX6ZEAaqVbFD/uyLL7H7MI73xxW5O+QsqmXQMYrJLGr3zRp98Tzvux	H+f2RIaHs/4TH9ENll/Ghu0kiz1aQK1zYHb1IkSF+wYC/n5ZLihhSJWpd89O
	VGos/CAUTlJoAzf4FvJP3vpsFBB7vek3hhom5BjIscS+puKxJJbZACDehrOF	3rx69ez102dPo3iYs2n6TXHOuQ6yCc8o5pe9IqRZhhezuDyUiRZvyBr9cl2w
	5VlYncuFzd8NaffQJzpyp/B47qMmX5R/Gz6gL5tmfEm/TM5mjdYWjPtS2xlj	ukKBQhQaEGuItspq5Bzv5iqBZAFunE9qaxZZf/ZhW6nWTA5CG9kUWP6krHXn
	LBwuZOZlJX9Dd+0qrkYSiOTWc5iTUUpTr8szFqKTRcwrOEFwGXWkS00mc+Iz	s04qVNXUHzhglQK9BrjLQ6t2n2BBNIV6qAKghPownTtB3JkGdIGtDyNZ+5rE
	Y7N0et72Wt8afVv98i5oiD1T8iORRnWoWQ1K6gNPBPOeLS0HQZ+D6/DOkAJo	GsUqY8BjNPRtHacWxmCZC1eijRyYivVCsBZTC9l1ZALaF1QBzsWKq0I5wkBs
	RICTCJ2PZwpSOPlGSyx3I7+/bXDo+WRFREynjKF+wtTpsjf84pNwMnmOdQHk	QvHdGDGAXCD6KGHxgI0ZtcjryW9TsMO4Y+TuSJy4JAq6CCU4lJTHv+Aecghs
	B6gOy0WE+LWimsRpk74tjgE8l9yyyruow8PTgA/pznAxI4rd7oAE7aXOVDw2	qN5JH01JHpq9o4PaPRMFtaiVxkVo+4IryDi9HiuKxLMhieuvtC2s5uH0btYF
	2dszObX0aHJpKTiOLf2Of+u0wj//CydWtitytBf/GlTv1hEN/unDhL/ufv5z	Vc154zsGFFvmW8YVZZVbRQ1H7yhzwOWUOWXd0E1NjTdGqTX4Vp42QyNOsbAp
	y8lm/qRHrT9Uxrecsulc3W0092+9FKb4vvnBvziN/OfOlsDW0dx1Gu2fO9sN	NJELRKH7FfrdN7y1MyblQR0XvhwaI3/brHcxCsLP6zVUkWwL3pvcoLQ7X5Lc
	2+7/SnPiDo/5uvvvZnzc6UnqnX39/V4Mt16xqz6RdgtaoFGwN2zrhNNVzZy+	G4bSbi3WJjZzlXYrbwmPD1MDm1LEheg6QZlJRtzOBGZNgudopWGE1u3Kzos8
	ipXfB3snQcMo2ns2gMhnLnkpSUaT47wGNW33iE8zbUklYoxToX7yINB73HAM	gnodJniNeCaUxMBmNbYTslxbnughxfham3LFZfHeVeNDa9FkloxOKSFOTqVj
	C87UDgp9ZXIBBMXsT0ER910zrClLwhMcRQITolytFwqP6JeGMGsjWV2Gi8ep	B5r6scshzFqYEpl4EpoKIOnGqM6pxyfNcNZyPysqQG39tYhQsLhhAlprQXNt
	s6x42FqbyPiwgHQ29kgR0+gmPmSsdRkw8FwJNN8yqpTLcplflFURnxwcWc8X	GZp2FCmzaGTUXCAZ6Q1RmaHRCFhOUEm+oouEkaiog9zW6pVNn1dCag/rClDh
	sec6GG9JPdcdn230jjU8kMWkmN3VFTa+7KEetsKyd1lwARgmjchO/fs6XyhZ	cwpl8U0oOH1XMGLjcHuzz98s0CsiHKeRB78oEgY/v9FIrC8I0gc5gSbE0WLu
	pDQfDZj4iEVUTn9OmPHhHU07Qmso5pR671HgiEf5CrHDCobZFjoim2y8NJdu	Q66/GtTkpeTZh4UrfiK5ZYrzEp3IXaqOF6u1fcZAHvUocyYpcGQzBP9MmZbM
	sVN79SBsfVJuqiOXwBs/gw3IbF/nAVPUCBDOUqDysiktF3j90tLjy1AsHsHB	L34EKxEMjLmpByJDUi6V+ZX2iDftfLI9YK7dXhJMel5jnFeS/23+OMG8YVq4
	bquRzwwrgv+IPLOFAwPD7RE2SDMVzjQMFF8R/vt8fXHhaZkwlG7B6jkxJqb7	M6xaRK4ECW02IyFvMg6yZWTZPoJlIobRPHGFUbGJntZYDmoSqYTdAw5O+wMg
	aOg9XQQzctsMd7bxyBDIp50PxYU9XZ9TTpIZdpif3iFmr+givDrFmDhsFiKX	mlNvEvrnqZ7QTIuxhvI2nC2XdlWhpqAdRILvtHFXjpJqfweUi3S/J8NMgEeP
	0X6aZC9zghITqpbap624iUNvnljhcLdn6okVU9f7BBj4aKHknI1iHmEmI6Sv	9shIiK4Gn7tie0c7hidAB4O/DRD5Ps8LC7iJZ0U7pL3L2cBTaSo3UsH6qbhR
	GSgXj5oWRtT35ivfnv4iQbRASxCVxWurQvYT4bdwR3aOvBENb2/v5XBkikC2	Q6h4qlx/TRBirn9yJLdJKwhJfqMd95e2E4+z5XZjAU0hco0zRCEs+aJeDkiF
	vag+0xnGc8UZ7XJBYCDF3ckbCC0dWvLc9MzA2m3SVMoxSBF0JxqDdHnBnSNC	yToArLwQ/CUtejS5fWxecW8o3gW5wXb+vLiOs6hJFrjQGEziaR9NxkBY2ETa
	TbBXcu3Ed67OskFr+wYTG/+ImX0nS8AgGlEB00re1YTozeRdb1STA6zN6Cut	LAl/2fV3rEuL//gOo8PCEAX+8/eo+3/gKBH9E3sr6d+Y/v7E/9j3DOQgfPmn
	Adk3CclkDa+gf34gTMaHAGcBW6Xgu2Yf4AF7/t745wMjHd9qARsTfus1dzHW	7N+y/TkIgAN3fb9lw0Suf7A3of7f50RH1i/JB822SxrY75IPJp7f8eDnAWGk
	72LtJh+75YK7fv7Q7fGVt/kL9s/tM3Xrny1RtDuPoG5usFe3//l3/RT9M5lM	HvwD7xp+cYx0P3xCtpXO8/NRxuJgXubnTb7qiwVgLN2y+ONeWqzsfXHDUKvP
	/sX71U7/itv9bvEGd7dot9oKanW/khwMGhba2QYvWkShodT4lqJatnwX5T+0	DhAcOW1+QL84SoJ0OG/KUvGzYJeQR0mzHbiTucCU8n1nfYBA902rNGQrIc5A
	WNscgxoNCgr6ipF95xsXaWw9mCg9a6iOmALSG/lRMJM4Q/GI8GluoQ5NTuFe	liU2aBWTpaeWJfLurUtbgKkFiLpc2jheiqmHFtiRPYVyeZhV+bz8W1oyXzTN
	hJTjgzHkgDCi1Wrd+T466V1u9xiNj2I2+Lj0pNwL1W/khWA/KQJKgBETv3pM	+IK+7All9dgWnBSmqjO6WdhjyGDRClGH9tplXP4kGZTXCGAOSSnAvh7QWGBY
	+5IpoBErYe0gPUQJU53aPmjnn5ezdjvVINxGgwkurxw1XOPIh/M6YdbGtLl4	lsWgC+37mhvq9TUmI+4ZaFoaWO9+te8Bv6uueh+Yw4GpMhKXo9rVzAElCILC
	LUMUa1zpBYbPSnq2E2dLv7DnEBsWNPBjuKtTMhelFYmRr7iILhxuyepIAGyH	wLxpR9dEYOVgP7wzcAXqGOBwQucdm5JT3FulBcG7oTuB7dLoEXCFVCKMrVSL
	5YV6WxoSRQ04Loo52yBSGhrZrlfrRSV93DlxyuXUa9/tLdRyJlY4L/BbbjR1	ZGrYOVhC8UlQozxAvKTvhzweppAoO9gSbc9p2+s94zi354Ibb3lbddcE1ftD
	iA3N/KgjkzxatjGccj4wn1LxEAljuDzbIlTEsuUJDUMKETfdtMnnVJTKw5I9	zDM8zvnHbj9BSwdDuyqen9z0uQgulU6uX6aO8+uv5Z8SWPj3XyC0sn2hp4P4
	Rvy0xSeUF8ytI48qUZlIoFze5+pGNy5B+xeYOzcVitSqm6AD9PCnzv0OrTLE	a+C+O2eU/BvmFH/d7/nvBuFm/vrS1suV8Q2Ctr9Xt5vNnRsfhS2+Yz74B7eR
	phMPyCpuXvom4X/iUVCBOHPw+u5Qnnc3M4DSkV0yGqUURrHYXweyoDe7r/7n	/26tDOyczW230f7dWnXY9fuv1ChuMczX/f52+setRlIT7et/78lw5xP7ahhp
	d6/3hE2XksnwpFdaKhH3qLyBRwqF67XcBQ/QJhfpNpHP9pGEGz5Z0JHTeoW5	z6MlqggHaXUnyFrVdHYK6qDy9PJjNDV8nkjfZzB8qYlGBWRaY55P5Ir3kacd
	Uw9yId6skcvi2hv6oBRKlMCuIl8k5xVyWV8qz5WShyFcdJ0Z18DX43DgYwXN	8UV0emoyoAwFnI9bp2GRmupFoT9OLklCMU5VYMYpCw0r0Xq+CnYpgVJRrjdL
	8pId6bynJKiI0ntW+PTX/HniIlI7F0Nj+n7bl5hsJ37xm93X//O7l3vg3S2Z	TZpIVaIwyiRpYgYzyKndrGmztTbD8T4CadXsM0hMy55Y3MQNsELaPNcQLXbO
	6gce4+Px8NXw+9/Dr5Ej5rqcIcFsjMliwlTEoY2XxBuQ4xP0qS2dQLonwpux	rI+/ucrPy6qIZQi73PNlbMjucMH0Ddk9H4r0ljYMySRVzG9vGxvj9ljFr6AD
	/yKmpOAMET4RXvqkg9QtB02g+yfHI50x7C6vhxa5qgSDHvHFszXjnQrrrdId	XhRcQIYxJdJh/2OTLxXgUvqphkT6CAFV9AGOp7E4j7YfU2/IFdU36CNvEqdb
	XG0tRZybzNdH6Xu2cNRSV27dYC0KINYNCLFrpIq0WjcuYfWYPC3X6VHPYT/D	vsJUY02W2eVPIk1tvDKP7tBhB6UkrJlS6KqjiLdXiEJbtXjbTMPqhJoa944y
	k8PXh71ehtiKgTpnarQAD1w/EchJlb0Dbxakd+McPaFslX2HZx8pBCSiFeDs	AGQ24uUCImG/Avoi1K1HCWM3letnBqbBLyPPbK1BYroJFAnpD8OBiGT5FiWN
	MC7PjI4hCG2W18izqNVo/JrdqGNRKHPaY/z28Jm4++DTvHgwkzbH2Y7UG+8g	Tzfn5x5KCn3tNsM9J7zH/q1Kv6uL0pHcLsWetT9SD/JZ57104Y7XUwpdMiIQ
	T8F6WSkgHRlIuL/SDtbevHj3bpQdH++Msp3n2N76DRxY/ha+Ntt5LYGpnXe6	o+07zO0ruijNndxP7FELbs3oZk2yl1hwOOIcXOoMt+aWFIndYhbEzayp31cM
	isXMXkT1AXDdn4t2hwoPBm1yGN/swQMdHx18N44RB7gzopHePLRtw/JjCmE1	xe/jZGDJhQp4Vph5jpnMkRMxU9XrUVvGCMzfrPTt6c/iYwtYCVGdvjZjZHsS
	+my6tutd+abiYAdIXsu0UxRdezHZ2SIbZL17mYCjklxu4nO+QTqIAQuuH9Es	voVfZFMEtGj4qns7iN1WlJabcP0zKGO8Yxz+LpeUOqRZevIOyrEO/YauHzXg
	aZxyd/9gf2+rjFDck17XbhcOO7E8Yb8k3+h2/rzD0DhUCDFvtZdA+0GMvB2H	kJuIliIlkqPdCQchHl9wP4xQY+zZXjvx7bmzLKmLX6OA458o4bfSE0wGJLJk
	RRyXYF/c9oFgtV5nOwHl6h+9E4SewjtwnSMZOE4aykm59S48Y2/bONsd0IiY	Os/bKhiDvbztD1UhAV00WqVVL4cKIym04RX0zw+UwvEhZL+AJlPwr+YfYIAD
	SH8NT5HnCrQRM/FMed6mxSWg9ritABaFEHXhU/eU1Hx3XTOBRah/8Ngs/y3H	/9v488RMxzfqx0bB3/nMbVT52+jCvcXueOC2y0/9PH7yJmvC/t28Uzf+7XCz
	wTjzVSeu/1vcxS5s6uw1HLT4ntd5oJfp3+WcEWS8/BDEdwcjdCDmPvLrec0E	3XoGdXONNrv775+1YvRvMpn8g79XLf4rfu5vi1fHu2W7U3dQnfyVhGl+xAYg
	Mm2OxZbE8refM1ON6pmownXnhRI4E/MZk5uSmJREDsvFOXmo+sDXr4liGfH4	eFNFFwH+Y2i0r5pLfS5rxcvy71r8bQSi+owCk77kVMDp1kVcWwUUxXENEtOE
	aLh1i01Ye7DnJHwqt0S8LXj/n3dCkfKpVJK27pDxHszIsH/ALTrf6Tmi6xIb	kUPUBIh8nYR7imLCR8QF/rQnjxPVKuxNjDMUKKu0Wm863x9o+Du3f/YM9ZFi
	1FymNTx/ptcb00q0NIkVse1s4b2lrYjeZLuig+jHHcL2Tjt0CUGyUvV9i1jj	nh5yKDcPQhEd2SrYMIuyK0C1iScwpvvJkNaYYGG1IxWplIvd14jQDpiW83Y3
	+dOuz/Hw0+P4NBr/O81LWInVxtO7sp9hLjw7hXs4STY3XYxDSgpTRRV8H4gt	YCL8jGYTDGMROVwsyaJ600MJxzi7WDZpZDguGANlaC1d6glQJiXaj7EZQwOf
	9r9H3wv3qvtLix0VMM79DcKs4e9i9tdkbzAVax3Ovv6n6kbbPKWQFU7y04yW	NxnXZXmLaZA1iwfqgqDrnZO4y/aYdqiLp4GDVBflsliwViJ1pj299nKzrKR7
	qakXXrQZtUwTDfJSNFrmGkYLQ81wrBo/eD94119kMv5qvDqNx0azWrbyHAaj	PcdauU5741vbhdLQno7OIERvuZnWMXZv8/OOFPbo8MYg874oLlMfLYjAJMPj
	ox6/AhsgJwi/FIe0ayS4KwW1wgigCswuZAEvuvFz9DzkKbsMY6SaZnXbKiJJ	2Q7qIkgwD8sYYo54BWdNvqAaV56W3DhC3C0+IdVgQB5RYRkohV3s8j5XN3qN
	EC4An/yAAe5xCF0J79gv5+do02wtnsYSlhlRrs/WJC5oDKNPul6OsK8I1VAh	qTBgiQF3U+5I7ckp34AGP3Lud6inYWY7oYyse81ahTiMC5mRf7H2nHGFfQ8s
	Sxi1LSu6qZ0emRPic5AyHCpBKIk7gslyy+K69V2MS+nWDdtQHiP1tVJI2lGD	jyWcmXzUkT02mqeUVzH5XwU8ozf7r/79d68PBCGY4s8w0isttYhbcl4LeIUk
	SP4OUBXYOcdWuFok+XtL6efp5ZSK5F0hdNSm0V+vB5LxXhzXTvr6jh0qqQYJ	9lp+B0NoG4/+hZGle8/DtcuWBMtZvcaAq8+RIZCvkcvi+h1aVD8TqZe3Fdkq
	3Empg0GqhcFbLyEd8Z68uZIqcz2+xdc5+c0ofem4Mag6L0082JHz+2rokBgZ	OZ8TjJPgbFPFDuIsMHrSzCy5BzASrFiyYV7ypRuwDKrL9NYXjv6aFyiGJLWt
	cuamWBUknb7fkd3D9jh58OkB/BnB3/uH+4f498HhAf397eG39PfDw4f096PD	MdCs73etxQRJcc1v9l//++9eHoAFuGJAIRjGe/Jh3fD97+FrRKK5KucImhsn
	R/T3d4ff0d/fH35Pfz8+fHw4cg8+PTl8Qv8+hD/497PDZ/T30eER/f388Dn9	dTEIrAEmyHEEGXXcklzSuxHejE0nMagFkkVQS/j4e72ybhA/oZMBmST9HZsW
	fXx4TH//dPjT4dDB8+749Pjdn46f946YP/c0rllpo0V/pqp31YaTbRpzPB6T	wVolc5ZyqUf88HzDCVOFtWjpF1zELUWh28xXWel7duDuUj9yvWYtkiBWHwhQ
	94FG9ksy4sfkMbNnGcb1lt1gnOzP99ja52CRsTW+8EKHZSHfeYYIWfGiBYW6	bcSStAA4Lov1aX1a9DNAysPejS+OXx8P+jZikwlqF6o+BRTDfiMQPCt7B7Yu
	M2RumkAKEf8MZNjI3hJXQ1rZRCXbssbe9zGkBdt5+j3HNrV4RRIEmlm0il+C	0O/WORoBM94QkUBZekiEh8l4qHf0Tkg3QLc3HJPB3vYwC5HGzvajvkyhVOqA
	EXbCVcMkuxpX/EfR1OK9nxdqjm5z/d0wlfi+pKZzy4pNLYTAvB8NhMtYgVMo	U8DT8jHbv/tpUdydH0hfsj2pYN5D/IPNqtKkdkQ44TZSe1jA8/zdu1H27Nne
	4Jjz0MORttEg3NBnmUiv7JSLRXGRLz748OSOAKPJ7lbSqkzb9fAqTmQEXK5+	KNt7im2934Dk8j/hZ7O91+K/2nunh1jM7UNUYwDP/bZHpQspNZ2mN797V6dH
	klEpLKXVQCG99rivk3FnP4kb12b9uY/BndQ8iT58yr5hdjIJX0wvo+Q3TvXr	AvDaKeL89kY00etntmtWMqXgeqM105Pd4Lk3FTtCgOpaBrYipL7nk70ddEH6
	m79x6PN4DHf/xjd4DlyXrZDi9b6p/znEq0MfMQELeCWpmtLLxk0R2/ijsRAG	vKcHEJdkiBM+dZ8yCFgLHhrRzng35v7hvcODPoHQpjga/FYkYbeTt+lnXZsL
	68bBJWbUZttT6E1+3ep4rpAVgcITcMTkEqD9z5Px88nH/B/ry1q5TYrZuK1K	e8C5dMgEYvxtT4h2IZywOw5nNy5Bt0guDJTWKz5GnxQbxjTTJ08PPCvk7xWj
	5N4ATcktyijsRoeSViCHbLdC5MvOUx0JsgBr/sTQdoY3JZjJTBr0DvQwAief	qFJ7H8Y42DVBuxnUoHiSvYbx5DPbC5oYfHwZgdVxmwSsJqHrduSOiLV3VzVj
	5XBeg2I+umzQS4L1eYFtPpf5KHubg3ZCsOv0VV6tQbe/Ak1+CUbc26akyuDX	YYTCCZ/I5Zf0LKhmvlzFDb/Fywyc1m/paxCw+J7XecCsGf7KOUO++PgxHhh6
	+NvT9WJRXuVgwr/CPH0FOq9etloH9jyHozV7VlR/wx7TDKFXViJsDgJygv1z	7YC4vVfYI6aVgQJ/5W7Q2U/Ur9lUsXqEqyAwp4XCT3toJrkAJeHYck1PHopF
	eG40Lar8S8ScCCMj4OTL+sK5P2a/+x0aO8czJIG+37LJ9LvfZW8XpFBhneor	8OUbAojGJH5U2brlVgHNcIxjcaqan/y2F2qaT6XotHXHnAvCSA6H97jn6DsV
	kRqtR/LEt2zN+PhyDk+bE7REi601xmsaTZ9Qzyhit4LvVCNdVAkHSNAtCrUQ	FnoQsf7MJV3pDTON6xiQoqVdqwizZwcqL10/NCTbNUmbP+5RBvCsQ2sQ6KjP
	MA7mu592NXJRr9hDZP6uGVpF47Lo5mPMthSw4uP970DPZ78UxWqcIx3ybZc/	rm9B0iho2s0UpZzK3dNoDe/0nlsa1bba+3KJYT88soV7MOndaHoYp9WrY5X7
	wsvBQ8iOjk4PHhwcBJXKBU3rJTUu3b336Nsne7c97OHXvftbvJznHo2Fckkt	/30AxTj8Hk0uvKAOL2g+nw8kEsPC1tevTy/U9oj8VLi9RxkdUFMvPRVzTjNt
	K2UT3HzrAQ2b9ALWiPlAVxofg3HvP9zDi0/46Vu3JtlNzMMFNz34lm46WuRU	MRBH0WgtbJgjTDDDGarT4H3yV3+RLfirMeHUFRvtZdnKOJysjqz6EkR8Tkn+
	h8FY4NhkYpqN3XsPnzyma48/rXIuZw8NiQSdRVbw0hcftnTXPt3F2b4xVe8Y	Uj7SbhAlr5S0Fk4RqkCrQsDyohs/RQNDRtnn9EYqfFb7rCI8BYEN8BEQmOAB
	Sjrh6wxaSFga4MbH/19hV9PTMAxD/wrS7lPSfLQ5ViBuXLmiCRBCGvQASPDv	e9AVNY+NcR5HG4FrhTUWucwJHX6+ISJBbRcN0M3/19i19KYNBOG7fwVyrzaC
	8XtO2qSt1EumdbWT2Y6T2LGtgLIxkGV90qSd2FuWIk6rOHSdOHOqEdieS34i	hCRwqKoFOypSoIigSj1VW1gVt2CQDSEKyn/vvHa9BIPKZYRtgXftndfOfN86
	IJON0Mn3A9sgbTD53yxsWbhCCLzlB0IkQic+SZFtIg4Dy5B8Wn7zbBV7j9Ya	QkIU6rNClDHiXDO7uT89MicE/SCtOtSkkOXxwmwZujczh9IRMmfCQA4LUH5G
	tvZQoCyG8jC1pW7maMSsbMvOAaPzyrfxisBMMDqnk5Cfos90u15+N3KSL19p	mnCl23RHPJc8DtALSPvjt8H6deYzHxfQYdRZ8JKpEZhsj63wjMDJC1EC7rB0
	1haBpeblHMwmHGLoG6HAnftVjki1rDLWcXp7fwZQb9b0/GgJGknKSCLGju0x	HSAh9V3DOxh+BDKGd1nQxe0lpB1mFLRl1L7rCl9cL5RbgkKqx/ymNjopTm82
	YQwJAwcFRtHkucQ42oQKN8UugO46dtG5ihjYIv58X2rFvhVFgJLdPqngUqCF	cIupzhxEHlp0YbZs1RxXk79wfcPRem3BJwLZVm2F8kbdkLxVtyQ7qkPyTt2R
	DOvFcRzvarkXOMd/6LvMGjh7cW+egbZYwdpkZ2Sj8qoKz17XG6v9LZo5c9/1	vFf3JB/UA8mu6qooaL32VI++K/ig7Ks+yYEakExUQjJVKclH9ajqTMw0fU6n
	gNEIQmuqzqvc2bkS0YuouT/e1mHCB0RFPbGG7J4rBzds4F/RaGI499ABhNzb	39PkzJj8+KBqcV32up2epzmlwVM04CUlGccxRRXoPD+Rcx7PMB5mGP/qjiYc
	oBIyO9nKIf22HITkVaMEfMxx3MtL53JcOuvaQp8jkTsgD7GF24YDV51Y1RLM	5OI0Hz+xF88pIc+feOcnXD0QiowXWDArMbIUpYZ1nqSXKiGMoJrdNfKqJIQQ
	37m4LubSjfkgCOHBy5s5v5LRjhx0FB2XyE3Ka+DzEI7k1STgv8fyCMcXPdOl	8p2Thm55ui6m8SANrpEIOMBvIqlFkASaVXR5n8DVGnJbMb22No/4ZoqNxOa/
	mA5MKyeXlEGc65ojTT0QKpu6Fc+nTb39jzrjr2oTVH0rLKmMg4Kyh0Zys7r8	jHU2L4X2wSVk87ZsUGsfoJuIj8B3j2oSY6y9KdRPeS+6PqcW1RYjur0lUioh
	bKq/f+Xc9VWeHozCNjOcOZd2a3ZXUccCRp3oBplT/8MMB+yehAEA	OFXmt179dAnJUGqlya+2KFcNSzHET7Ipd8AN7cMG9crSdhpoo7GrBBvGO39I
		TL7bqJv/0+JPIn2ioc858msMm9WY6e9oAxyne3x9lHUD5Lv4/1F+QzNwyEpB
		1DsbVd2ACIOHhtEEp3crGzSZe0Ou52hPB459MthgDkEvV3biOuZXzCw+h4Qo
		5hLflZ4v9KG09/mCiAqUlADLoyVJ+2UYJ82/+m2/3FhcFLOIyzxD3A7QoEy7
		Rkk3slW2ebnaB7eFvNnOgSVJ1QE2C4qrHXiYK5WjzLBDR3AcQUVjtWVfgyUv
		3/G/4ehgWWDIBA/wK3KYrrU9MdGgybBmdj7S+Z6uBx1xHIHaX4KrNykQKsJe
		PMYrn/erVfaic3twhFv8OVjlzbrc8FGccziTaDDMjb7J/yDRNpzhynyLgBRk
		a/SxkTOIZ9Fup1qsJ8zA/QP7BquMAYoBAA==

	-->	-->

	</rfc>	</rfc>

End of changes. 317 change blocks.
	1885 lines changed or deleted	1399 lines changed or added
This html diff was produced by rfcdiff 1.48.

[8]ページ先頭