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 "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4. <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.30 (Ruby 2.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 conversion 3.28.1 --> <!-- xml2rfc v2v3 conversion 3.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>
<author initials="K." surname="Oku" fullname="Kazuho Oku"> <author fullname="奥 一穂" 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>
<?line 67?> <?line 109?>
<!-- [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.
-->
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<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 a ClientHello 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 target="https://github.com/tlswg/draft-ietf-tls-esni">https://github.com
/tlswg/draft-ietf-tls-esni</eref>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 72?> <?line 142?>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>Although TLS 1.3 <xref target="RFC8446"/> encrypts most of the handshak e, including the <t>Although TLS 1.3 <xref target="RFC8446"/> encrypts most of the handshak e, 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 in ClientHello messages, which leaks the target Indication (SNI) extension in <tt>ClientHello</tt> messages, which leaks the tar get
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 TLS extension, called Encrypted Client He <t>This document specifies a new TLS extension called Encrypted Client
llo Hello (ECH) that allows clients to encrypt their <tt>ClientHello</tt> to the
(ECH), that allows clients to encrypt their ClientHello 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 the Application-Layer Protocol Negotiation (ALPN) list
Application Layer Protocol Negotiation (ALPN) <xref target="RFC7301"/>. Co-located servers with consistent externally visible
list <xref target="RFC7301"/>. Co-located servers with consistent externally vis 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 target="deployment"/>.</t> feature are discussed in <xref target="deployment"/>.</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 149
| | | |
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>In Shared Mode, the provider is the origin server for all the domains whose DNS <t>In shared 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>In Split Mode, the provider is not the origin server for private doma ins. <t>In split mode, the provider is not the origin server for private doma ins.
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 p rovider as <t>In the remainder of this document, we will refer to the ECH-service p rovider 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 in Shared Mode, but in Split Mode, the client-facing These are the same entity in shared 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 target="security-considerations"/> for more discussion abou t the ECH threat model <t>See <xref target="security-considerations"/> for more discussion abou t 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 target="RFC9460"/>. See to <xref target="RFC9460"/>. See
<xref target="ECH-IN-DNS"/> for specifics about how ECH configurations <xref target="RFCYYY1"/> 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 serv er, it <t>When a client wants to establish a TLS session with some backend serv er, it
constructs a private ClientHello, referred to as the ClientHelloInner. constructs a private <tt>ClientHello</tt>, referred to as the <tt>ClientHelloInn
The client then constructs a public ClientHello, referred to as the er</tt>.
ClientHelloOuter. The ClientHelloOuter contains innocuous values for The client then constructs a public <tt>ClientHello</tt>, referred to as the
<tt>ClientHelloOuter</tt>. The <tt>ClientHelloOuter</tt> contains innocuous valu
es for
sensitive extensions and an "encrypted_client_hello" extension sensitive extensions and an "encrypted_client_hello" extension
(<xref target="encrypted-client-hello"/>), which carries the encrypted ClientHel (<xref target="encrypted-client-hello"/>), which carries the encrypted <tt>Clien
loInner. tHelloInner</tt>.
Finally, the client sends ClientHelloOuter 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 co mpletes <t>If it does not support ECH or cannot decrypt the extension, it co mpletes
the handshake with ClientHelloOuter. This is referred to as rejecting ECH.</t> the handshake with <tt>ClientHelloOuter</tt>. This is referred to as rejecting E CH.</t>
</li> </li>
<li> <li>
<t>If it successfully decrypts the extension, it forwards the Client HelloInner <t>If it successfully decrypts the extension, it forwards the <tt>Cl ientHelloInner</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 o r not ECH <t>Upon receiving the server's response, the client determines whether o r not ECH
was accepted (<xref target="determining-ech-acceptance"/>) and proceeds with the handshake was accepted (<xref target="determining-ech-acceptance"/>) 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 target="rejected-ech"/>).</t> retry with up-to-date configuration (<xref target="rejected-ech"/>).</t>
<t>The primary goal of ECH is to ensure that connections to servers in t he same <t>The primary goal of ECH is to ensure that connections to servers in t he 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 target="goals"/> for more details about the ECH security and privacy g oals.</t> See <xref target="goals"/> for more details about the ECH security and privacy g oals.</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 target="HPKE"/>. <t>ECH uses Hybrid Public Key Encryption (HPKE) for public key encryption <xref target="RFC9180"/>.
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 in RFC9180 uint16 HpkeKemId; // Defined in RFC 9180
uint16 HpkeKdfId; // Defined in RFC9180 uint16 HpkeKdfId; // Defined in RFC 9180
uint16 HpkeAeadId; // Defined in RFC9180 uint16 HpkeAeadId; // Defined in RFC 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 264
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 versio n <t>The version of ECH for which this configuration is used. The versio n
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 of ECHConfig.</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 thi s <t>An opaque byte string whose contents depend on the version. For thi s
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 infor mation <t>A <tt>HpkeKeyConfig</tt> structure carrying the configuration infor mation
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 target="padding"/>) and doe s not be set to zero. It is used to compute padding (<xref target="padding"/>) and doe s 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 target="rejected-ech"/>.</t> as described in <xref target="rejected-ech"/>.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>See <xref target="auth-public-name"/> for how the client interprets and validates the <t>See <xref target="auth-public-name"/> 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 a ClientHello message. Each ECHConfigExtension consideration when generating a <tt>ClientHello</tt> message. Each ECHConfigExte nsion
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 target="config-exten sions"/>).</t> order. ECHConfigExtension values are described below (<xref target="config-exten sions"/>).</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 for ClientHello encryption. <xref target="confi g-ids"/> clients to indicate the key used for <tt>ClientHello</tt> encryption. <xref targ et="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 wit h a to <tt>public_key</tt>. Clients MUST ignore any <tt>ECHConfig</tt> structure wit h 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 encrypt ClientHelloInner. </t> <t>The HPKE public key used by the client to encrypt <tt>ClientHelloIn ner</tt>.</t>
</dd> </dd>
<dt>cipher_suites</dt> <dt>cipher_suites:</dt>
<dd> <dd>
<t>The list of HPKE KDF and AEAD identifier pairs clients can use for <t>The list of HPKE Key Derivation Function (KDF) and Authenticated En
encrypting cryption with Associated Data (AEAD) identifier pairs clients can use for encryp
ClientHelloInner. See <xref target="real-ech"/> for how clients choose from this ting
list.</t> <tt>ClientHelloInner</tt>. See <xref target="real-ech"/> 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 known ECHConfig values, with corr esponding <t>A client-facing server has a set of known <tt>ECHConfig</tt> values w ith 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 target="client-facing-server"/> describes a trial decryption pr ocess for decrypting the <t><xref target="client-facing-server"/> describes a trial decryption pr ocess 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 known ECHConfig values. To avoid this, the client-facing server SHOULD maintains
allocate distinct <tt>config_id</tt> values for each ECHConfig in its known set. many known <tt>ECHConfig</tt> values. To avoid this, the client-facing server SH
The OULD
allocate distinct <tt>config_id</tt> values for each <tt>ECHConfig</tt> in its k
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 known ECHConfig.</t> <tt>config_id</tt> repeatedly until it does not match any known <tt>ECHConfig</t t>.</t>
<t>It is not necessary for <tt>config_id</tt> values across different cl ient-facing <t>It is not necessary for <tt>config_id</tt> values across different cl ient-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 perfo rmance client-facing servers with colliding <tt>config_id</tt> values without any perfo rmance
impact. Values may also be reused if the previous ECHConfig is no longer in the impact. Values may also be reused if the previous <tt>ECHConfig</tt> is no longe r 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 target="ech-configuration"/> and mirrors <xref section="4.2" sectionFormat ="of" target="RFC8446"/>. However, <xref target="ech-configuration"/> and mirrors <xref section="4.2" sectionFormat ="of" target="RFC8446"/>. However,
ECH configuration extension types are maintained by IANA as described ECH configuration extension types are maintained by IANA as described
in <xref target="config-extensions-iana"/>. ECH configuration extensions follow in <xref target="config-extensions-iana"/>. 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 manda tory <t>Clients MUST parse the extension list and check for unsupported manda tory
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 influence ClientHelloOuter SHOUL <t>Any future information or hints that influence <tt>ClientHelloOuter</
D be tt> SHOULD be
specified as ECHConfig 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 an envelope for <tt>ClientHello</tt> exists only in support of ECH. Namely, it is both an envelo
the encrypted inner ClientHello and enabler for authenticated key mismatch pe for
signals (see <xref target="server-behavior"/>). In contrast, the inner ClientHel the encrypted inner <tt>ClientHello</tt> and an enabler for authenticated key mi
lo is the smatch
true ClientHello used upon ECH negotiation.</t> signals (see <xref target="server-behavior"/>). 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[ <t>~~
enum { enum {
encrypted_client_hello(0xfe0d), (65535) encrypted_client_hello(0xfe0d), (65535)
} ExtensionType; } ExtensionType;
]]></artwork> ~~</t>
<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 {
ECHClientHelloType type; ECHClientHelloType type;
select (ECHClientHello.type) { select (ECHClientHello.type) {
case outer: case outer:
HpkeSymmetricCipherSuite cipher_suite; HpkeSymmetricCipherSuite cipher_suite;
uint8 config_id; uint8 config_id;
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 exten sion uses the <t>The outer extension uses the <tt>outer</tt> variant and the inner exten sion uses the
<tt>inner</tt> variant. The inner extension has an empty payload, which is inclu ded <tt>inner</tt> variant. The inner extension has an empty payload, which is inclu ded
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 in ClientHello. The outer extension has the following which were not included in <tt>ClientHello</tt>. The outer extension has the fol lowing
fields:</t> fields:</t>
<dl> <dl>
<dt>config_id</dt> <dt><tt>config_id</tt>:</dt>
<dd> <dd>
<t>The ECHConfigContents.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 encrypt ClientHelloInner. This MUST match <t>The cipher suite used to encrypt <tt>ClientHelloInner</tt>. This MU
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 encapsulated key, used by servers to decrypt the correspon <t>The HPKE encapsulated key used by servers to decrypt the correspond
ding ing
<tt>payload</tt> field. This field is empty in a ClientHelloOuter sent in respon <tt>payload</tt> field. This field is empty in a <tt>ClientHelloOuter</tt> sent
se to in response to
HelloRetryRequest.</t> HelloRetryRequest.</t>
</dd> </dd>
<dt>payload</dt> <dt>payload:</dt>
<dd> <dd>
<t>The serialized and encrypted EncodedClientHelloInner structure, enc rypted <t>The serialized and encrypted <tt>EncodedClientHelloInner</tt> struc ture, encrypted
using HPKE as described in <xref target="real-ech"/>.</t> using HPKE as described in <xref target="real-ech"/>.</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 target="client-facing-server" />, with the EncryptedExtensions message, as described in <xref target="client-facing-server" />, with the
following payload:</t> following payload:</t>
<artwork><![CDATA[ <t>~~
struct { struct {
ECHConfigList retry_configs; ECHConfigList retry_configs;
} ECHEncryptedExtensions; } ECHEncryptedExtensions;
]]></artwork> ~~</t>
<t>The response is valid only when the server used the ClientHelloOuter. I <t>The response is valid only when the server used the <tt>ClientHelloOute
f the r</tt>. If the
server sent this extension in response to the <tt>inner</tt> variant, then the c lient server sent this extension in response to the <tt>inner</tt> variant, then the c lient
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>An ECHConfigList structure containing one or more ECHConfig structu res, in <t>An <tt>ECHConfigList</tt> structure containing one or more <tt>ECHC onfig</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 target="rejected-ech"/>. These are known as the server's "retry configurat ions".</t> <xref target="rejected-ech"/>. These are known as the server's "retry configurat ions".</t>
</dd> </dd>
</dl> </dl>
<t>Finally, when the client offers the "encrypted_client_hello", if the pa yload is <t>Finally, when the client offers the "encrypted_client_hello", if the pa yload is
the <tt>inner</tt> variant and the server responds with HelloRetryRequest, it MU ST the <tt>inner</tt> variant and the server responds with HelloRetryRequest, it MU ST
include an "encrypted_client_hello" extension with the following payload:</t> include an "encrypted_client_hello" extension with the following payload:</t>
<artwork><![CDATA[ <t>~~
struct { struct {
opaque confirmation[8]; opaque confirmation[8];
} ECHHelloRetryRequest; } ECHHelloRetryRequest;
]]></artwork> ~~</t>
<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 target="backend-server-hr r"/>.</t> <tt>hrr_accept_confirmation</tt> as described in <xref target="backend-server-hr r"/>.</t>
<t>This document also defines the "ech_required" alert, which the client M UST send <t>This document also defines the "ech_required" alert, which the client M UST 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 target="alerts"/>.)</t> the server. (See <xref target="alerts"/>.)</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 compresses ClientHe <t>Before encrypting, the client pads and optionally compresses <tt>Clie
lloInner ntHelloInner</tt>
into a EncodedClientHelloInner structure, defined below:</t> into an <tt>EncodedClientHelloInner</tt> structure, defined below:</t>
<artwork><![CDATA[ <t>~~
struct { struct {
ClientHello client_hello; ClientHello client_hello;
uint8 zeros[length_of_padding]; uint8 zeros[length_of_padding];
} EncodedClientHelloInner; } EncodedClientHelloInner;
]]></artwork> ~~</t>
<t>The <tt>client_hello</tt> field is computed by first making a copy of <t>The <tt>client_hello</tt> field is computed by first making a copy of
ClientHelloInner <tt>ClientHelloInner</tt>
and setting the <tt>legacy_session_id</tt> field to the empty string. In TLS, th is and setting the <tt>legacy_session_id</tt> field to the empty string. In TLS, th is
field uses the ClientHello 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" target="RFC8446"/>. ectionFormat="of" target="RFC8446"/>.
In DTLS, it uses the ClientHello structured defined in In DTLS, it uses the <tt>ClientHello</tt> structure defined in
<xref section="5.3" sectionFormat="of" target="RFC9147"/>. This does not include <xref section="5.3" sectionFormat="of" target="RFC9147"/>. 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, nor the twelve-byte header in DTLS. The <tt>zeros</tt>
d MUST field MUST
be all zeroes of length <tt>length_of_padding</tt> (see <xref target="padding"/> be all zeros of length <tt>length_of_padding</tt> (see <xref target="padding"/>)
).</t> .</t>
<t>Repeating large extensions, such as "key_share" with post-quantum alg orithms, <t>Repeating large extensions, such as "key_share" with post-quantum alg orithms,
between ClientHelloInner and ClientHelloOuter can lead to excessive size. To between <tt>ClientHelloInner</tt> and <tt>ClientHelloOuter</tt> can lead to exce ssive 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 in ClientHelloOuter. It does so by removing and replacing will be duplicated in <tt>ClientHelloOuter</tt>. It does so by removing and repl
extensions from EncodedClientHelloInner 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[ <t>~~
enum { enum {
ech_outer_extensions(0xfd00), (65535) ech_outer_extensions(0xfd00), (65535)
} ExtensionType; } ExtensionType;</t>
<artwork><![CDATA[
ExtensionType OuterExtensions<2..254>; ExtensionType OuterExtensions<2..254>; ~~
]]></artwork> ]]></artwork>
<t>OuterExtensions contains the removed ExtensionType values. Each value <t>OuterExtensions contains a list of the removed ExtensionType values.
references Each value references
the matching extension in ClientHelloOuter. The values MUST be ordered the matching extension in <tt>ClientHelloOuter</tt>. The values MUST be ordered
contiguously in ClientHelloInner, and the "ech_outer_extensions" extension MUST contiguously in <tt>ClientHelloInner</tt>, and the "ech_outer_extensions" extens
be inserted in the corresponding position in EncodedClientHelloInner. ion MUST
Additionally, the extensions MUST appear in ClientHelloOuter in the same be inserted in the corresponding position in <tt>EncodedClientHelloInner</tt>.
Additionally, the extensions MUST appear in <tt>ClientHelloOuter</tt> in the sam
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, while ClientHelloOuter 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 either ClientHelloOuter 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> fi eld to a byte <t>Finally, the client pads the message by setting the <tt>zeros</tt> fi eld 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 target="padding"/> describes a recommended padding scheme.</t> to add. <xref target="padding"/> describes a recommended padding scheme.</t>
<t>The client-facing server computes ClientHelloInner by reversing this <t>The client-facing server computes <tt>ClientHelloInner</tt> by revers
process. ing this process.
First it parses EncodedClientHelloInner, 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 MU ST <tt>client_hello</tt> as padding. If any padding byte is non-zero, the server MU ST
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 copies th <t>Next, it makes a copy of the <tt>client_hello</tt> field and copies t
e he
<tt>legacy_session_id</tt> field from ClientHelloOuter. It then looks for an <tt>legacy_session_id</tt> field from <tt>ClientHelloOuter</tt>. It then looks f
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 the ClientHelloOuter. The server MUST corresponding sequence of extensions in the <tt>ClientHelloOuter</tt>. The serve r 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 in ClientHelloOuter.</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 in ClientHelloOuter corresponding to those in Oute rExtensions <t>The extensions in <tt>ClientHelloOuter</tt> corresponding to thos e 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 ampli fication <t>These requirements prevent an attacker from performing a packet ampli fication
attack, by crafting a ClientHelloOuter which decompresses to a much larger attack by crafting a <tt>ClientHelloOuter</tt> which decompresses to a much larg
ClientHelloInner. This is discussed further in <xref target="decompression-amp"/ er
>.</t> <tt>ClientHelloInner</tt>. This is discussed further in <xref target="decompress
<t>Implementations SHOULD construct the ClientHelloInner 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 of service risk. copying) create a denial-of-service risk.
<xref target="linear-outer-extensions"/> describes a linear-time procedure that may be used <xref target="linear-outer-extensions"/> 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 target="flow-clienthello-malleability"/>), ECH authenticates ClientHe (see <xref target="flow-clienthello-malleability"/>), ECH authenticates <tt>Clie
lloOuter ntHelloOuter</tt>
by passing ClientHelloOuterAAD as the associated data for HPKE sealing by passing <tt>ClientHelloOuterAAD</tt> as the associated data for HPKE sealing
and opening operations. The ClientHelloOuterAAD 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" target="RFC8446"/> for TLS and
<xref section="5.3" sectionFormat="of" target="RFC9147"/> for DTLS, which matche <xref section="5.3" sectionFormat="of" target="RFC9147"/> for DTLS, which matche
s the ClientHelloOuter 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
include Handshake structure's four-byte header in TLS nor twelve-byte header in include the Handshake structure's four-byte header in TLS nor the twelve-byte he ader 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: eit her they <t>Clients that implement the ECH extension behave in one of two ways: eit her they
offer a real ECH extension, as described in <xref target="real-ech"/>; or they s end a offer a real ECH extension, as described in <xref target="real-ech"/>, or they s end a
Generate Random Extensions And Sustain Extensibility (GREASE) <xref target="RFC8 701"/> Generate Random Extensions And Sustain Extensibility (GREASE) <xref target="RFC8 701"/>
ECH extension, as described in <xref target="grease-ech"/>. Clients of the latte ECH extension, as described in <xref target="grease-ech"/>.
r type do not The client offers ECH if it is in possession of a compatible ECH configuration a
negotiate ECH. Instead, they generate a dummy ECH extension that is ignored by nd sends GREASE ECH
the server. (See <xref target="dont-stick-out"/> for an explanation.) The client (see <xref target="grease-ech"/>) otherwise.
offers ECH Clients of the latter type do not
if it is in possession of a compatible ECH configuration and sends GREASE ECH negotiate ECH; instead, they generate a dummy ECH extension that is ignored by
(see <xref target="grease-ech"/>) otherwise.</t> the server. (See <xref target="dont-stick-out"/> for an explanation.) It is als
o possible for clients to always
send GREASE ECH without 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 suitable ECHConfig 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 the vers
/tt>, ion of
and the version of ECH indicated by <tt>ECHConfig.contents.version</tt>. Once a ECH indicated by <tt>ECHConfig.version</tt>. Once a suitable configuration is fo
suitable configuration is found, 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 target="grease-ech"/>.</t> compatible configuration is found, then the client SHOULD proceed as described
<t>Next, the client constructs the ClientHelloInner message just as it d in <xref target="grease-ech"/>.</t>
oes a <t>Next, the client constructs the <tt>ClientHelloInner</tt> message jus
standard ClientHello, with the exception of the following rules:</t> t as it does 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 necessar y to ensure <t>It MUST NOT offer to negotiate TLS 1.2 or below. This is necessar y 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 target="encod ing-inner"/>), it MUST <t>If it intends to compress any extensions (see <xref target="encod ing-inner"/>), 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 <t t>inner</tt> as <t>It MUST include the "encrypted_client_hello" extension of type <t t>inner</tt> as
described in <xref target="encrypted-client-hello"/>. (This requirement is not a pplicable described in <xref target="encrypted-client-hello"/>. (This requirement is not a pplicable
when the "encrypted_client_hello" extension is generated as described in when the "encrypted_client_hello" extension is generated as described in
<xref target="grease-ech"/>.)</t> <xref target="grease-ech"/>.)</t>
</li> </li>
</ol> </ol>
<t>The client then constructs EncodedClientHelloInner as described in <t>The client then constructs <tt>EncodedClientHelloInner</tt> as descri bed in
<xref target="encoding-inner"/>. It also computes an HPKE encryption context and <tt>enc</tt> value <xref target="encoding-inner"/>. It also computes an HPKE encryption context and <tt>enc</tt> value
as:</t> as:</t>
<artwork><![CDATA[ <t>~~
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> ~~</t>
<t>Next, it constructs a partial ClientHelloOuterAAD as it does a standa <t>Next, it constructs a partial <tt>ClientHelloOuterAAD</tt> as it does
rd a standard
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 in EncodedClientHelloInner, it MU <t>If it compressed any extensions in <tt>EncodedClientHelloInner</t
ST copy the t>, it MUST copy the
corresponding extensions from ClientHelloInner. The copied extensions corresponding extensions from <tt>ClientHelloInner</tt>. The copied extensions
additionally MUST be in the same relative order as in ClientHelloInner.</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 from ClientHelloInner. T his <t>It MUST copy the legacy_session_id field from <tt>ClientHelloInne r</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" target="RFC8446"/>) when ECH is negotiated. Note that mode (see <xref section="D.4" sectionFormat="of" target="RFC8446"/>) 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 the ClientHelloInner 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 target="flow-client-reaction"/>.)</t> <xref target="flow-client-reaction"/>.)</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 target="rejected-ech"/> or failing to interoperate with mechanism described in <xref target="rejected-ech"/> or failing to interoperate with
servers that require this step to be done; see <xref target="client-facing-serve r"/>.</t> servers that require this step to be done; see <xref target="client-facing-serve r"/>.</t>
</li> </li>
<li> <li>
<t>When the client offers the "pre_shared_key" extension in ClientHe <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 in ClientHelloOuter, SHOULD also include a GREASE "pre_shared_key" extension in <tt>ClientHelloOuter<
/tt>,
generated in the manner described in <xref target="grease-psk"/>. The client MUS T NOT use generated in the manner described in <xref target="grease-psk"/>. The client MUS T 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 target="flow-clienthello-malleability"/>.) When the client includes a GREA SE <xref target="flow-clienthello-malleability"/>.) When the client includes a GREA SE
"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 the ClientHelloInner 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 in ClientHelloI <t>When the client offers the "early_data" extension in <tt>ClientHe
nner, it lloInner</tt>, it
MUST also include the "early_data" extension in ClientHelloOuter. This MUST also include the "early_data" extension in <tt>ClientHelloOuter</tt>. This
allows servers that reject ECH and use ClientHelloOuter to safely ignore any allows servers that reject ECH and use <tt>ClientHelloOuter</tt> to safely ignor
e any
early data sent by the client per <xref section="4.2.10" sectionFormat="comma" t arget="RFC8446"/>.</t> early data sent by the client per <xref section="4.2.10" sectionFormat="comma" t arget="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 the ClientHelloOuter. See <xref target="outer-clienthello"/> for addi tional offered in the <tt>ClientHelloOuter</tt>. See <xref target="outer-clienthello"/> for additional
guidance.</t> guidance.</t>
<t>Finally, the client encrypts the EncodedClientHelloInner with the abo <t>Finally, the client encrypts the <tt>EncodedClientHelloInner</tt> wit
ve values, h the above values,
as described in <xref target="encrypting-clienthello"/>, to construct a ClientHe as described in <xref target="encrypting-clienthello"/>, to construct a <tt>Clie
lloOuter. It ntHelloOuter</tt>. It
sends this to the server, and processes the response as described in sends this to the server and processes the response as described in
<xref target="determining-ech-acceptance"/>.</t> <xref target="determining-ech-acceptance"/>.</t>
<section anchor="encrypting-clienthello"> <section anchor="encrypting-clienthello">
<name>Encrypting the ClientHello</name> <name>Encrypting the ClientHello</name>
<t>Given an EncodedClientHelloInner, an HPKE encryption context and <t <t>Given an <tt>EncodedClientHelloInner</tt>, an HPKE encryption conte
t>enc</tt> value, xt and <tt>enc</tt> value,
and a partial ClientHelloOuterAAD, the client constructs a ClientHelloOuter 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 encrypting EncodedClie ntHelloInner <t>First, the client determines the length L of encrypting <tt>Encoded ClientHelloInner</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 the ClientHelloOuterAAD 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 of ECHClientHello 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 chosen ECHConfig 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 target="ignored-configs"/>) are to be <t>If configuration identifiers (see <xref target="ignored-configs"/>) 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
first ClientHelloOuter 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 second ClientHelloOuter.</t> MUST be left unchanged for the second <tt>ClientHelloOuter</tt>.</t>
<t>The client serializes this structure to construct the ClientHelloOu <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[ <t>~~
final_payload = context.Seal(ClientHelloOuterAAD, final_payload = context.Seal(ClientHelloOuterAAD,
EncodedClientHelloInner) EncodedClientHelloInner)
]]></artwork> ~~</t>
<t>Including <tt>ClientHelloOuterAAD</tt> as the HPKE AAD binds the <t t>ClientHelloOuter</tt> <t>Including <tt>ClientHelloOuterAAD</tt> as the HPKE AAD binds the <t t>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 d escribed in <tt>ClientHelloOuter</tt> while keeping the same <tt>ClientHelloInner</tt>, as d escribed in
<xref target="flow-clienthello-malleability"/>.</t> <xref target="flow-clienthello-malleability"/>.</t>
<t>Finally, the client replaces <tt>payload</tt> with <tt>final_payloa d</tt> to obtain <t>Finally, the client replaces <tt>payload</tt> with <tt>final_payloa d</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 nec essary
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 com puted after <t>Note this construction requires the "encrypted_client_hello" be com puted after
all other extensions. This is possible because the ClientHelloOuter's all other extensions. This is possible because the <tt>ClientHelloOuter</tt>'s
"pre_shared_key" extension is either omitted, or uses a random binder "pre_shared_key" extension is either omitted or uses a random binder
(<xref target="grease-psk"/>).</t> (<xref target="grease-psk"/>).</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 ide ntities in <t>When offering ECH, the client is not permitted to advertise PSK ide ntities in
the ClientHelloOuter. 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 the ClientHelloInner. 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 target="RFC8446"/>. When offering a PSK in ClientHelloInner, described in <xref target="RFC8446"/>. When offering a PSK in <tt>ClientHelloInn er</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 w ere
negotiated properly.</t> negotiated properly.</t>
<t>The client generates the extension payload by constructing an <tt>O fferedPsks</tt> <t>The client generates the extension payload by constructing an <tt>O fferedPsks</tt>
structure (see <xref section="4.2.11" sectionFormat="comma" target="RFC8446"/>) as follows. For each PSK identity structure (see <xref section="4.2.11" sectionFormat="comma" target="RFC8446"/>) as follows. For each PSK identity
advertised in the ClientHelloInner, the client generates a random PSK identity advertised in the <tt>ClientHelloInner</tt>, the client generates a random PSK i dentity
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 target="real-ech"/>, the server is not permi tted to resume a <t>Per the rules of <xref target="real-ech"/>, the server is not permi tted 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 the ClientHelloInner is encrypted without padding, then the leng th 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>ClientHello Inner</tt>. the <tt>ClientHelloOuter.payload</tt> can leak information about <tt>ClientHello Inner</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 inner ClientHello 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 appl ication <t>By way of example, clients typically support a small number of appl ication
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 clien t-facing <t>In contrast, clients do not know the longest SNI value in the clien t-facing
server's anonymity set without server input. Clients SHOULD use the ECHConfig's server's anonymity set without server input. Clients SHOULD use the <tt>ECHConfi
<tt>maximum_name_length</tt> field as follows, where L is the <tt>maximum_name_l g</tt>'s
ength</tt> <tt>maximum_name_length</tt> field as follows, where M 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 the ClientHelloInner 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 the ClientHelloInner 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), add L + 9 bytes of padding. This the client is connecting to an IP address), add M + 9 bytes of padding. This
is the length of a "server_name" extension with an L-byte name.</t> is the length of a "server_name" extension with an M-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 the EncodedClientHelloInner with all the padding <t>Let L be the length of the <tt>EncodedClientHelloInner</tt> wit h 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 of EncodedClientHelloInner up to a multiple of 32 bytes, <t>This rounds the length of <tt>EncodedClientHelloInner</tt> up to a multiple of 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 padding ClientHelloInner, clients and servers will a lso need to <t>In addition to padding <tt>ClientHelloInner</tt>, clients and serve rs 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 in ClientHelloInner, the server-selected value if a client proposes ALPN values in <tt>ClientHelloInner</tt>, the server-select ed 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 target="server-behavior"/>, the server may ei ther accept ECH and use <t>As described in <xref target="server-behavior"/>, the server may ei ther 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 i s 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_con firmation</tt> as <t>If the message is a ServerHello, the client computes <tt>accept_con firmation</tt> as
described in <xref target="backend-server"/>. If this value matches the last 8 b ytes of described in <xref target="backend-server"/>. If this value matches the last 8 b ytes of
<tt>ServerHello.random</tt>, the server has accepted ECH. Otherwise, it has reje cted <tt>ServerHello.random</tt>, the server has accepted ECH. Otherwise, it has reje cted
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, if it has a length other than 8, the client aborts the handshake ECH. Otherwise, if the extension
has a length other than 8, the client MUST 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 target="backend-server-hr r"/>. If this value <tt>hrr_accept_confirmation</tt> as described in <xref target="backend-server-hr r"/>. 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 with ClientHelloIn ner as <t>If the server accepts ECH, the client handshakes with <tt>ClientHel loInner</tt> as
described in <xref target="accepted-ech"/>. Otherwise, the client handshakes wit h described in <xref target="accepted-ech"/>. Otherwise, the client handshakes wit h
ClientHelloOuter as described in <xref target="rejected-ech"/>.</t> <tt>ClientHelloOuter</tt> as described in <xref target="rejected-ech"/>.</t>
</section> <!-- [rfced] In the following sentence, does "length other than 8" ref
er to
bytes? If yes, may we update as follows?
Current:
Otherwise, if it has a length other than 8, the client aborts the
handshake with a "decode_error" alert.
Perhaps:
Otherwise, if it has a length other than 8 bytes, the client aborts
the handshake with a "decode_error" alert. -->
</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 target="RFC8446"/>, with the following modifications:</t> <xref target="RFC8446"/>, with the following modifications:</t>
<t>The client behaves as if it had sent ClientHelloInner as the Client <t>The client behaves as if it had sent <tt>ClientHelloInner</tt> as t
Hello. That he <tt>ClientHello</tt>. That
is, it evaluates the handshake using the ClientHelloInner'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" tar get="RFC8446"/>), it uses when computing the transcript hash (<xref section="4.4.1" sectionFormat="of" tar get="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 compute s the updated <t>If the server responds with a HelloRetryRequest, the client compute s 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 second ClientHelloInner based on the first Client <t>It computes a second <tt>ClientHelloInner</tt> based on the fir
HelloInner, as st <tt>ClientHelloInner</tt>, as
in <xref section="4.1.4" sectionFormat="of" target="RFC8446"/>. The ClientHelloI in <xref section="4.1.4" sectionFormat="of" target="RFC8446"/>. 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 constructs EncodedClientHelloInner as described in <xref tar get="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 partial ClientHelloOuterAAD message. Thi s message MUST <t>It constructs a second partial <tt>ClientHelloOuterAAD</tt> mes sage. 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 client MAY <tt>ClientHelloOuter</tt> unmodified or omitted. If not sensitive, the client MA
copy updated extensions from the second ClientHelloInner for compression.</t> Y
copy updated extensions from the second <tt>ClientHelloInner</tt> for compressio
n.</t>
</li> </li>
<li> <li>
<t>It encrypts EncodedClientHelloInner as described in <t>It encrypts <tt>EncodedClientHelloInner</tt> as described in
<xref target="encrypting-clienthello"/>, using the second partial ClientHelloOut <xref target="encrypting-clienthello"/>, using the second partial <tt>ClientHell
erAAD, to oOuterAAD</tt>, to
obtain a second ClientHelloOuter. It reuses the original HPKE encryption obtain a second <tt>ClientHelloOuter</tt>. It reuses the original HPKE encryptio
n
context computed in <xref target="real-ech"/> and uses the empty string for <tt> enc</tt>. </t> context computed in <xref target="real-ech"/> 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 target="flow-hrr-hijack"/>.</t> an attack described in <xref target="flow-hrr-hijack"/>.</t>
</li> </li>
</ol> </ol>
<t>The client then sends the second ClientHelloOuter to the server. Ho <t>The client then sends the second <tt>ClientHelloOuter</tt> to the s
wever, as erver. However, as
above, it uses the second ClientHelloInner for preferences, and both the above, it uses the second <tt>ClientHelloInner</tt> for preferences, and both th
ClientHelloInner messages for the transcript hash. Additionally, it checks the e
<tt>ClientHelloInner</tt> messages for the transcript hash. Additionally, it che
cks the
resulting ServerHello for ECH acceptance as in <xref target="determining-ech-acc eptance"/>. resulting ServerHello for ECH acceptance as in <xref target="determining-ech-acc eptance"/>.
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 for ECHConfig.contents.public_name as described in authenticating for <tt>ECHConfig.contents.public_name</tt> as described in
<xref target="auth-public-name"/>. If authentication or the handshake fails, the client MUST <xref target="auth-public-name"/>. 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 target="RFC7918"/> for this handshake. If bot h the False Start optimization <xref target="RFC7918"/> for this handshake. If bot h
authentication and the handshake complete successfully, the client MUST perform authentication and the handshake complete successfully, the client MUST perform
the processing described below then abort the connection with an "ech_required" the processing described below and then abort the connection with an "ech_requir ed"
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 in a way that best <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 in any way that is
choose to use a different IP address if provided with options from consistent with the previous ECH configuration. For example, clients
DNS. ECH does not mandate any specific implementation choices when can reuse the same server IP address when establishing the new
establishing this new connection.</t> transport connection or they can choose to use a different IP address
if DNS provided other IP addresses for the previous configuration.
However, it is not safe 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 connectio ns. Further <t>The retry configurations are meant to be used for retried connectio ns. 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 suppor ted <t>If none of the values provided in "retry_configs" contains a suppor ted
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 930
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 target="server-behavior"/>). Clients that offer "server_name" extension instead (see <xref target="server-behavior"/>). 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 connectio n with
the appropriate alert.</t> the appropriate alert.</t>
</li> </li>
<li> <li>
<t>If the server requests a client certificate, the client MUST re spond with an <t>If the server requests a client certificate, the client MUST re spond 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 target="RFC6125"/>. Clients that incorporate DNS names and IP addresses in to <xref target="RFC9525"/>. Clients that incorporate DNS names and IP addresses in to
the same syntax (e.g. <xref section="7.4" sectionFormat="of" target="RFC3986"/> and <xref target="WHATWG-IPV4"/>) the same syntax (e.g. <xref section="7.4" sectionFormat="of" target="RFC3986"/> and <xref target="WHATWG-IPV4"/>)
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 checking ECHConfig.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 target="rejected-ech"/>. This may be impl emented, for trigger retries, as described in <xref target="rejected-ech"/>. This may be impl emented, 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" target="DNS-TERM S"/>). That is, to be preferred name syntax (see <xref section="2" sectionFormat="of" target="RFC9499" />). 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" target="RFC5890"/>, where:</ t> defined in <xref section="2.3.1" sectionFormat="of" target="RFC5890"/>, 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 target="rejected-ech"/>. The reason enforcing the single retry limit from <xref target="rejected-ech"/>. 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 the ECHConfig sou rce <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
<xref target="ECH-IN-DNS"/>. Clients MUST limit any sharing of persisted ECH-rel <xref target="RFCYYY1"/>. Clients MUST limit any sharing of persisted ECH-relate
ated d
state to connections that use the same ECHConfig 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 t o <t>In general, the safest way for clients to minimize ECH retries is t o
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 c lient
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 target="dont-stick-out"/>).</t> which ECH connections stick out (see <xref target="dont-stick-out"/>).</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 an ECHConfig <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 target="RFC870 1"/> structure available for the server, it SHOULD send a GREASE <xref target="RFC870 1"/>
"encrypted_client_hello" extension in the first ClientHello 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 HpkeSymmetri cCipherSuite. The <t>Set the <tt>cipher_suite</tt> field to a supported HpkeSymmetri cCipherSuite. The
selection SHOULD vary to exercise all supported configurations, but MAY be selection SHOULD vary, so that all plausible configurations are exercised,
held constant for successive connections to the same server in the same but MAY be held constant for successive connections to the same server in the sa
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 encaps ulated public key <t>Set the <tt>enc</tt> field to a randomly generated valid encaps ulated 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 o f L+C bytes, where C <t>Set the <tt>payload</tt> field to a randomly generated string o f 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
the EncodedClientHelloInner the client would compute when offering ECH, padded the <tt>EncodedClientHelloInner</tt> the client would compute when offering ECH, padded
according to <xref target="padding"/>.</t> according to <xref target="padding"/>.</t>
</li> </li>
</ul> </ul>
<t>If sending a second ClientHello in response to a HelloRetryRequest, the <t>If sending a second <tt>ClientHello</tt> in response to a HelloRetr yRequest, 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 va lue 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 encrypted ClientHello <t>Offering a GREASE extension is not considered offering an encrypted <tt>ClientHello</tt>
for purposes of requirements in <xref target="real-ech"/>. In particular, the cl ient for purposes of requirements in <xref target="real-ech"/>. In particular, the cl ient
MAY offer to resume sessions established without ECH.</t> MAY offer to resume sessions established without ECH.</t>
</section> <!-- [rfced] It seems that "client" was intended to be "clients" (plur
al) in
the sentence below and updated as follows. Please let us know if that is not
accurate.
Original:
Correctly-implemented client will ignore those extensions.
Current:
Correctly implemented clients will ignore those extensions.
-->
</section>
<section anchor="server-greasing"> <section anchor="server-greasing">
<name>Server Greasing</name> <name>Server Greasing</name>
<t><xref target="config-extensions-iana"/> describes a set of Reserved extensions <t><xref target="config-extensions-iana"/> 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 target="RFC8701"/>. This helps ensure clients process ECH extensions <xref target="RFC8701"/>. 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 target="config-extensions"/>. Servers SHOULD randomly select fr om defined in <xref target="config-extensions"/>. Servers SHOULD randomly select fr om
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 Correctly implemented 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 the server, so that key and a public name not associated with the server so that
the initial ClientHelloOuter 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 target="rejected-ech"/>.</t> in <xref target="rejected-ech"/>.</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 target="topologies"/>, servers can play two roles , either as <t>As described in <xref target="topologies"/>, 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 <t t>outer</tt>, and <t>A client-facing server expects an <tt>ECHClientHello.type</tt> of < tt>outer</tt>, and
proceeds as described in <xref target="client-facing-server"/> to extract a proceeds as described in <xref target="client-facing-server"/> 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>inne r</tt>, and <t>A backend server expects an <tt>ECHClientHello.type</tt> of <tt>inn er</tt>, and
proceeds as described in <xref target="backend-server"/>.</t> proceeds as described in <xref target="backend-server"/>.</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>o uter</tt> which receives a <tt>ClientHello</tt> with <tt>ECHClientHello.type</tt> of <tt>o uter</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 ab ort with an <tt>ClientHello</tt> with <tt>ECHClientHello.type</tt> of <tt>inner</tt> MUST ab ort 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 complet es the <t>If the "encrypted_client_hello" is not present, then the server complet es the
handshake normally, as described in <xref target="RFC8446"/>.</t> handshake normally, as described in <xref target="RFC8446"/>.</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 ECH prior
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 new ClientHello to process, so even the client's TLS extension will result in a new <tt>ClientHello</tt> to process, so even the clie nt's TLS
version preferences may have changed.</t> version preferences may have changed.</t>
<t>First, the server collects a set of candidate ECHConfig values. This list is <t>First, the server collects a set of candidate <tt>ECHConfig</tt> valu es. This list 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>Compare ECHClientHello.config_id against identifiers of each know n 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 known ECHConfig values as candidates, with trial decr yption <t>Collect all known <tt>ECHConfig</tt> values as candidates, with t rial 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 the ECHClientHello to a such
known ECHConfig. See <xref target="ignored-configs"/>. Unless specified by the a cases, the second method SHOULD be used for matching the <tt>ECHClientHello</tt>
pplication to a
known <tt>ECHConfig</tt>. See <xref target="ignored-configs"/>. Unless specified
by the application
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 candidate ECHConfig values, attempt ing 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 the ECHConfig supports the cipher suite indi <t>The server verifies that the <tt>ECHConfig</tt> supports the cipher s
cated by uite indicated by
the ECHClientHello.cipher_suite and that the version of ECH indicated by the the <tt>ECHClientHello.cipher_suite</tt> and that the version of ECH indicated b
client matches the ECHConfig.version. If not, the server continues to the next y the
candidate ECHConfig.</t> client matches the <tt>ECHConfig.version</tt>. If not, the server continues to t
<t>Next, the server decrypts ECHClientHello.payload, using the private k he next
ey skR candidate <tt>ECHConfig</tt>.</t>
corresponding to ECHConfig, as follows:</t> <t>Next, the server decrypts <tt>ECHClientHello.payload</tt>, using the
<artwork><![CDATA[ private key skR
corresponding to <tt>ECHConfig</tt>, as follows:</t>
<t>~~
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> ~~</t>
<t>ClientHelloOuterAAD is computed from ClientHelloOuter as described in <t><tt>ClientHelloOuterAAD</tt> is computed from <tt>ClientHelloOuter</t
t> as described in
<xref target="authenticating-outer"/>. The <tt>info</tt> parameter to SetupBaseR is the <xref target="authenticating-outer"/>. The <tt>info</tt> parameter to SetupBaseR is the
concatenation "tls ech", a zero byte, and the serialized ECHConfig. If concatenation "tls ech", a zero byte, and the serialized <tt>ECHConfig</tt>. If
decryption fails, the server continues to the next candidate ECHConfig. decryption fails, the server continues to the next candidate <tt>ECHConfig</tt>.
Otherwise, the server reconstructs ClientHelloInner from Otherwise, the server reconstructs <tt>ClientHelloInner</tt> from
EncodedClientHelloInner, as described in <xref target="encoding-inner"/>. It the <tt>EncodedClientHelloInner</tt>, as described in <xref target="encoding-inner"/
n stops >. It then stops
iterating over the candidate ECHConfig values.</t> iterating over the candidate <tt>ECHConfig</tt> values.</t>
<t>Once the server has chosen the correct ECHConfig, it MAY verify that <t>Once the server has chosen the correct <tt>ECHConfig</tt>, it MAY ver
the value ify that the value
in the ClientHelloOuter "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 pu blic
names.</t> names.</t>
<t>Upon determining the ClientHelloInner, the client-facing server check s that the <t>Upon determining the <tt>ClientHelloInner</tt>, the client-facing ser ver 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 c hecks <tt>inner</tt> and that it does not offer TLS 1.2 or below. If either of these c hecks
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 i n
<xref target="backend-server"/>. If the backend server responds with a HelloRetr yRequest, the <xref target="backend-server"/>. If the backend server responds with a HelloRetr yRequest, the
client-facing server forwards it, decrypts the client's second ClientHelloOuter client-facing server forwards it, decrypts the client's second <tt>ClientHelloOu ter</tt>
using the procedure in <xref target="client-facing-server-hrr"/>, and forwards t he resulting using the procedure in <xref target="client-facing-server-hrr"/>, and forwards t he resulting
second ClientHelloInner. The client-facing server forwards all other TLS second <tt>ClientHelloInner</tt>. The client-facing server forwards all other TL S
messages between the client and backend server unmodified.</t> messages between the client and backend server unmodified.</t>
<t>Otherwise, if all candidate ECHConfig values fail to decrypt the exte nsion, 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
using ClientHelloOuter, 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 target="dont-stick-out"/> for details.</t> <xref target="dont-stick-out"/> 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 more ECHConfig structures with up-to-date "retry_configs" field set to one or more <tt>ECHConfig</tt> structures with up-t
keys. Servers MAY supply multiple ECHConfig values of different versions. o-date
keys. Servers MAY supply multiple <tt>ECHConfig</tt> values of different version
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 (s ee <t>Note that decryption failure could indicate a GREASE ECH extension (s ee
<xref target="grease-ech"/>), so it is necessary for servers to proceed with the connection <xref target="grease-ech"/>), 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 target="misconfiguration"/>). Instead, servers can measure occurrences of the (<xref target="misconfiguration"/>). 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 target="client-facing-server"/> with the second not repeat the steps in <xref target="client-facing-server"/> with the second
ClientHelloOuter. Instead, it continues with the ECHConfig selection from the <tt>ClientHelloOuter</tt>. Instead, it continues with the <tt>ECHConfig</tt> sel
first ClientHelloOuter as follows:</t> ection from the
<t>If the client-facing server accepted ECH, it checks the second Clie first <tt>ClientHelloOuter</tt> as follows:</t>
ntHelloOuter <t>If the client-facing server accepted ECH, it checks that 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 and ECHClientHello.config_id are unchanged, and that <tt>ECHClientHello.cipher_suite</tt> and <tt>ECHClientHello.config_id</tt> are u
ECHClientHello.enc is empty. If not, it MUST abort the handshake with an nchanged, and that
<tt>ECHClientHello.enc</tt> is empty. If not, it MUST abort the handshake with a
n
"illegal_parameter" alert.</t> "illegal_parameter" alert.</t>
<t>Finally, it decrypts the new ECHClientHello.payload as a second mes sage with the <t>Finally, it decrypts the new <tt>ECHClientHello.payload</tt> as a s econd message with the
previous HPKE context:</t> previous HPKE context:</t>
<artwork><![CDATA[ <t>~~
EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,
ECHClientHello.payload) ECHClientHello.payload)
]]></artwork> ~~</t>
<t>ClientHelloOuterAAD is computed as described in <xref target="authe <t><tt>ClientHelloOuterAAD</tt> is computed as described in <xref targ
nticating-outer"/>, but et="authenticating-outer"/>, but
using the second ClientHelloOuter. If decryption fails, the client-facing using the second <tt>ClientHelloOuter</tt>. If decryption fails, the client-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 second ClientHelloInner from the new EncodedClientHelloInner reconstructs the second <tt>ClientHelloInner</tt> from the new <tt>EncodedClient
as described in <xref target="encoding-inner"/>, using the second ClientHelloOut HelloInner</tt>
er for as described in <xref target="encoding-inner"/>, using the second <tt>ClientHell
oOuter</tt> for
any referenced extensions.</t> any referenced extensions.</t>
<t>The client-facing server then forwards the resulting ClientHelloInn er to the <t>The client-facing server then forwards the resulting <tt>ClientHell oInner</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 first ClientHel lo did not <t>If the client-facing server rejected ECH, or if the first <tt>Clien tHello</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
second ClientHello'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 more ECHConfig structures with up-to-date "retry_configs" field set to one or more <tt>ECHConfig</tt> structures with up-t o-date
keys, as described in <xref target="client-facing-server"/>.</t> keys, as described in <xref target="client-facing-server"/>.</t>
<t>Note that a client-facing server that forwards the first ClientHell o cannot <t>Note that a client-facing server that forwards the first <tt>Client Hello</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 second ClientHello. server to include any information it requires to process the second <tt>ClientHe
</t> llo</tt>.</t>
</section> <!-- [rfced] May we rephrase the following text for an improved senten
ce flow?
Original:
The backend server embeds in `ServerHello.random` a string derived from
the inner handshake.
Perhaps:
A string derived from the inner handshake is embedded into
`ServerHello.random` by the backend server. -->
</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>inn er</tt> in a <t>Upon receipt of an "encrypted_client_hello" extension of type <tt>inn er</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 i t 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 in ServerHello.random a string derived from the inner <t>The backend server embeds in <tt>ServerHello.random</tt> a string der ived 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 of ServerHello.random are set to zero. It then computes the transcript bytes of <tt>ServerHello.random</tt> are set to zero. It then computes the trans
hash for ClientHelloInner 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" target="RFC8446"/>. Let transcript_ech_conf denote the described in <xref section="4.4.1" sectionFormat="comma" target="RFC8446"/>. 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[ <t>~~
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> ~~</t>
<t>where HKDF-Expand-Label is defined in <xref section="7.1" sectionForm at="comma" target="RFC8446"/>, "0" indicates a <t>where HKDF-Expand-Label is defined in <xref section="7.1" sectionForm at="comma" target="RFC8446"/>, "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" target="RFC9147"/> is used instead.</t> defined in <xref section="5.9" sectionFormat="comma" target="RFC9147"/> is used instead.</t>
<t>The backend server MUST NOT perform this operation if it negotiated T LS 1.2 or <t>The backend server MUST NOT perform this operation if it negotiated T LS 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" target="RFC8446"/>).</t> <xref section="4.1.3" sectionFormat="comma" target="RFC8446"/>).</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 the ClientHello, <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 target="RFC84 46"/>), it HelloRetryRequest.random (the value of which is specified by <xref target="RFC84 46"/>), 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 first ClientHelloInner, 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[ <t>~~
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> ~~</t>
<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 target="backend-server"/>.</t> <tt>accept_confirmation</tt> value as described in <xref target="backend-server" />.</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 ch anges <t>The design of ECH as specified in this document necessarily requires ch anges
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 target="compat-is sues"/>.</t> can lead to compatibility issues. These are discussed in <xref target="compat-is sues"/>.</t>
<t>Beyond coordination difficulties, ECH deployments may also induce chall <t>Beyond coordination difficulties, ECH deployments may also create chall
enges enges
for use cases of information that ECH protects. In particular, for uses 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 target="no-sni"/>.</t> as desired. This is elaborated upon in <xref target="no-sni"/>.</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 previously advertised 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 inconsi stent. This <t>It is possible for ECH advertisements and servers to become inconsi stent. 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 serve r <t>The retry mechanism repairs inconsistencies, provided the TLS serve r
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" target="RFC8446"/>. Prov
<xref section="4.1.2" sectionFormat="of" target="RFC8446"/>. 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 target="rejected-ech"/>.</t> as described in <xref target="rejected-ech"/>.</t>
<t>Unless ECH is disabled as a result of successfully establishing a c onnection to <t>Unless ECH is disabled as a result of successfully establishing a c onnection 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 fr om 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 serv ers <t>In order to ensure that the retry mechanism works successfully, ser vers
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" targe <!--[rfced] How may we update this sentence to make it clear whether
t="RFC8446"/> which require proxies to all the requirements or only some of the requirements require
proxies to act as conforming TLS client and server?
For background, in general, the RPC recommends using nonrestrictive "which"
and restrictive "that". (More details are on
https://www.rfc-editor.org/styleguide/tips/) However, edits to that
usage have not been made in this document. In this specific sentence,
we are asking about the usage because it can affect the understanding
of the statement.
Original:
The requirements in [RFC8446], Section 9.3 which require proxies to
act as conforming TLS client and server provide interoperability with
TLS-terminating proxies even in cases where the server supports ECH
but the proxy does not, as detailed below.
Option A (all requirements require it):
The requirements in [RFC8446], Section 9.3, which require proxies to
act as conforming TLS client and server, provide interoperability with
TLS-terminating proxies even in cases where the server supports ECH
but the proxy does not, as detailed below.
Option B (some requirements require it):
The requirements in [RFC8446], Section 9.3 that require proxies to
act as conforming TLS client and server provide interoperability with
TLS-terminating proxies even in cases where the server supports ECH
but the proxy does not, as detailed below.
-->
<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 unknown parameters, and <t>The proxy must ignore unknown parameters and
generate its own ClientHello 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 a ClientHello to the Thus,
server, the proxy will act as if connecting to the ClientHelloOuter when presenting a certificate to the client or sending a <tt>ClientHello</tt> to
server_name, which SHOULD match the public name (see <xref target="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 <xref target="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 target="rejected-ech"/> or result in a connection failure. A proxy whic h is not in <xref target="rejected-ech"/> or result in a connection failure. A proxy whic h 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 wit h the <t>Some use cases which depend on information ECH encrypts may break wit h the
skipping to change at line 1345 skipping to change at line 1442
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" sectionFor mat="of" target="HPKE"/>)</t> <t>KEM: DHKEM(X25519, HKDF-SHA256) (see <xref section="7.1" sectionFor mat="of" target="RFC9180"/>)</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" targe t="HPKE"/>)</t> <t>AEAD: AES-128-GCM (see <xref section="7.3" sectionFormat="of" targe t="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 att ackers can <t>ECH considers two types of attackers: passive and active. Passive att ackers 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 target="RFC3552"/> for TLS 1.3 <xref target="RFC8446"/>.</t> <xref target="RFC3552"/> for TLS 1.3 <xref target="RFC8446"/>.</t>
<t>Passive and active attackers can exist anywhere in the network, inclu ding <t>Passive and active attackers can exist anywhere in the network, inclu ding
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 in Split Mode. However, client-facing and backend servers when running ECH in split mode. However,
for Split Mode in particular, ECH makes two additional assumptions:</t> for split 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 between client and client- facing <t>The attacker cannot correlate messages between a client and clien t-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 encrypted ClientHelloInner. 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 pr operties of <t>Security preservation. Use of ECH does not weaken the security pr operties of
TLS without ECH.</t> TLS without ECH.</t>
skipping to change at line 1408 skipping to change at line 1505
is defined in <xref target="intro"/>.)</t> is defined in <xref target="intro"/>.)</t>
</li> </li>
<li> <li>
<t>Downgrade resistance. An attacker cannot downgrade a connection t hat <t>Downgrade resistance. An attacker cannot downgrade a connection t hat
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 target="ECH-Analysis"/ >.</t> <t>These properties were formally proven in <xref target="ECH-Analysis"/ >.</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 distinct ECHConfig 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 same ECHConfig 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 of the unencrypted 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 hid e, to some <t>Beyond these primary security and privacy goals, ECH also aims to hid e, 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 target="grease-ech"/> does not change the security properties of extension described in <xref target="grease-ech"/> 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 target="real-ech"/>), as a means of addressing the "do not stick out" protocol (<xref target="real-ech"/>), as a means of addressing the "do not stick out"
requirements of <xref target="RFC8744"/>. See <xref target="dont-stick-out"/> fo r details.</t> requirements of <xref target="RFC8744"/>. See <xref target="dont-stick-out"/> fo r 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 <xref target="ECH-IN-DNS"/>. This means that any attacker which can information <xref target="RFCYYY1"/>. This means that any attacker which can inj
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 where ClientHello 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-client ECHConfig <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 numb er of <t>The cost of this type of attack scales linearly with the desired numb er 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-client ECHConfig structures for extended periods of time, e.g., using per-client <tt>ECHConfig</tt> structur es
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 or ECHConfig state upon changing networks this problem by flushing any DNS or <tt>ECHConfig</tt> state upon changing netwo rks
(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 s ervers,
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 c lients and <t>Ignoring configuration identifiers may be useful in scenarios where c lients 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 generated config_id in the ECHClientHello. Servers in these settings a randomly generated <tt>config_id</tt> in the <tt>ECHClientHello</tt>. Servers in 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 the config_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
malicious ClientHello 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 config ured, <t>Unless specified by the application using (D)TLS or externally config ured,
implementations MUST NOT use this mode.</t> client implementations 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 the ClientHelloOuter is v <t>Any information that the client includes in the <tt>ClientHelloOuter<
isible to /tt> is visible to
passive observers. The client SHOULD NOT send values in the ClientHelloOuter passive observers. The client SHOULD NOT send values in the <tt>ClientHelloOuter
which would reveal a sensitive ClientHelloInner property, such as the true </tt>
which would reveal a sensitive <tt>ClientHelloInner</tt> property, such as the t
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 the ClientHello. 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 target="RFC7924"/> can contain the hash of a previously observed server ce rtificate. <xref target="RFC7924"/> can contain the hash of a previously observed server ce rtificate.
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. Fo r example, <t>A client may also use different preferences in different contexts. Fo r 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 in ClientHelloOuter.</t> send context-specific values in <tt>ClientHelloOuter</tt>.</t>
<t>Values which are independent of the true server name, or other inform ation the <t>Values which are independent of the true server name, or other inform ation the
client wishes to protect, MAY be included in ClientHelloOuter. If they match client wishes to protect, MAY be included in <tt>ClientHelloOuter</tt>. If they
the corresponding ClientHelloInner, they MAY be compressed as described in match
the corresponding <tt>ClientHelloInner</tt>, they MAY be compressed as described
in
<xref target="encoding-inner"/>. However, note that the payload length reveals i nformation <xref target="encoding-inner"/>. However, note that the payload length reveals i nformation
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 in ClientHelloOuter to avoi d <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 target="dont-stick-out"/>.</t> and value itself are not sensitive. See <xref target="dont-stick-out"/>.</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 of ClientHelloInner, such as the <t>Values which depend on the contents of <tt>ClientHelloInner</tt>, suc h 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
of ClientHelloInner. Implementations should take such side channels into of <tt>ClientHelloInner</tt>. Implementations should take such side channels int o
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 mech anism. <t>ECH requires encrypted DNS to be an effective privacy protection mech anism.
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 as OCSP or CRL traffic, or may include requests for revocation information, such as Online Certificate Stat
requests for repository information, such as authorityInformationAccess. It may us Protocol (OCSP) or Certificate 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 of verification.</t> implementation-specific traffic for additional information sources as part of v
erification.</t>
<t>Implementations SHOULD avoid leaking information that may identify th e server. <t>Implementations SHOULD avoid leaking information that may identify th e 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 E CH <t>Attacks that rely on non-ECH traffic to infer server identity in an E CH
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" target="RFC8446"/> defines a cookie value that servers may send in <t><xref section="4.2.2" sectionFormat="of" target="RFC8446"/> defines a cookie value that servers may send in
HelloRetryRequest for clients to echo in the second ClientHello. While ECH HelloRetryRequest for clients to echo in the second <tt>ClientHello</tt>. While
encrypts the cookie in the second ClientHelloInner, the backend server's ECH
HelloRetryRequest is unencrypted.This means differences in cookies between encrypts the cookie in the second <tt>ClientHelloInner</tt>, the backend server'
s
HelloRetryRequest is unencrypted. 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 sect ion="4" sectionFormat="of" target="RFC5077"/>, this may leak information if diff erent backend servers issue <t>Note that, if the cookie includes a key name, analogous to <xref sect ion="4" sectionFormat="of" target="RFC5077"/>, this may leak information if diff erent 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 in Split Mode, the backend servers may not share if the deployment operates in split mode, the backend servers may not share
cookie encryption keys. Backend servers may mitigate this by either handling cookie encryption keys. Backend servers may mitigate this either by handling
key rotation with trial decryption, or coordinating to match key names.</t> key rotation with trial decryption or by 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.r andom</tt>. (See
<xref target="backend-server"/> for details.) This behavior increases the likeli hood of the <xref target="backend-server"/> for details.) This behavior increases the likeli hood of the
ServerHello.random colliding with the ServerHello.random of a previous session, <tt>ServerHello.random</tt> colliding with the <tt>ServerHello.random</tt> of a previous 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 sa me is <t>On the other hand, the probability that two 8-byte strings are the sa me 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 its ServerHello.random coincide with the confirmation signal, last 8 bytes of its <tt>ServerHello.random</tt> coincide with the confirmation s ignal,
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 the ServerHello.random are used to implem ent <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 " target="RFC8446"/>). These downgrade protection for TLS 1.3 (see <xref section="4.1.3" sectionFormat="comma " target="RFC8446"/>). 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 target="RFC8744"/> lists several requirements for SNI encryptio n. <t><xref target="RFC8744"/> lists several requirements for SNI encryptio n.
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 either ClientHelloInner or ClientHelloOuter, <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 an attacker to "cut <tt>ClientHelloInner</tt>.random is encrypted, it is not possible for an attacke
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 ke y <t>This design depends upon DNS as a vehicle for semi-static public ke y
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 containing ECHConfig 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 decrypt ClientHello messages with E CHClientHello <t>This design requires servers to decrypt <tt>ClientHello</tt> messag es 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 ta rget="RFC8744"/> <t>As a means of reducing the impact of network ossification, <xref ta rget="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 1731
(<xref target="real-ech"/>) without changing the security properties of the hand shake. The (<xref target="real-ech"/>) without changing the security properties of the hand shake. 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 GR EASE ECH may <t>Ensuring that networks do not differentiate between real ECH and GR EASE 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 the ECHConfigList used by the server .</t> <t>The attacker does not know the <tt>ECHConfigList</tt> used by t he 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 followin g features <t>Moreover, real ECH and GREASE ECH are designed so that the followin g 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 thei r order;</t> <t>the code points of extensions negotiated in the clear, and thei r order;</t>
skipping to change at line 1686 skipping to change at line 1780
<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 inner ClientHe llo <t>This design does not provide forward secrecy for the inner <tt>Clie ntHello</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 in Split Mode to forward conn ections <t>This design permits servers operating in split mode to forward conn ections
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 in Split Mode is not spoofing a client-facing server operating in split mode is not
possible. See <xref target="plaintext-dns"/> for more details regarding plaintex t possible. See <xref target="plaintext-dns"/> for more details regarding plaintex t
DNS.</t> DNS.</t>
<t>Authenticating the ECHConfig structure naturally authenticates the included <t>Authenticating the <tt>ECHConfig</tt> structure naturally authentic ates the included
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 entire ClientHello, this design additionally protocols. By encrypting the entire <tt>ClientHello</tt>, this design additional ly
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 the ClientHelloInner ciphertext could lea k <t>Variations in the length of the <tt>ClientHelloInner</tt> ciphertext could leak
information about the corresponding plaintext. <xref target="padding"/> describe s a information about the corresponding plaintext. <xref target="padding"/> describe s 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 inner ClientHello, 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 legitimate ClientHello and replies with a ServerHello, The attacker intercepts a legitimate <tt>ClientHello</tt> and replies with a Ser verHello,
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 inner ClientHello 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"> <t>~~
<name>Client reaction attack</name>
<artwork><![CDATA[
Client Attacker Server Client Attacker Server
ClientHello ClientHello
+ key_share + key_share
+ ech ------> (intercept) -----> X (drop) + ech ------&gt; (intercept) -----&gt; X (drop)</t>
<figure anchor="flow-diagram-client-reaction">
ServerHello <name>Client Reaction Attack</name>
+ key_share <artwork><![CDATA[
{EncryptedExtensions} ServerHello
{CertificateRequest*} + key_share
{Certificate*} {EncryptedExtensions}
{CertificateVerify*} {CertificateRequest*}
<------ {Certificate*}
Alert {CertificateVerify*}
------> <------ Alert
------> ~~
]]></artwork> ]]></artwork>
</figure> </figure>
<t>ClientHelloInner.random prevents this attack. In particular, since the attacker <t><tt>ClientHelloInner.random</tt> prevents this attack: because the attacker
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 legitimate ClientHello using its own attacker-controlled ClientHello. about a legitimate <tt>ClientHello</tt> using its own attacker-controlled <tt>Cl
To begin, the attacker intercepts and forwards a legitimate ClientHello 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 own ClientHello in response based client, the attacker attempts to generate its own <tt>ClientHello</tt> in respon
on the contents of the first ClientHello 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 first ClientHello and the key share from the second used the SNI from the first <tt>ClientHello</tt> and the key share from the seco
(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"> <t>~~
<name>HelloRetryRequest hijack attack</name>
<artwork><![CDATA[
Client Attacker Server Client Attacker Server
ClientHello ClientHello
+ key_share + key_share
+ ech ------> (forward) -------&gt; + ech ------> (forward) -------&gt;
HelloRetryRequest HelloRetryRequest
+ key_share + key_share
(intercept) <------- (intercept) &lt;-------</t>
<figure anchor="flow-diagram-hrr-hijack">
ClientHello <name>HelloRetryRequest Hijack Attack</name>
+ key_share' <artwork><![CDATA[
+ ech' -------> ClientHello
ServerHello + key_share'
+ key_share + ech' ------->
{EncryptedExtensions} ServerHello
{CertificateRequest*} + key_share
{Certificate*} {EncryptedExtensions}
{CertificateVerify*} {CertificateRequest*}
{Finished} {Certificate*}
<------- {CertificateVerify*}
(process server flight) {Finished}
<-------
(process server flight) ~~
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This attack is mitigated by using the same HPKE context for both Cl ientHello <t>This attack is mitigated by using the same HPKE context for both <t t>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 inner ClientHello.</t> generate a valid encryption of the second inner <tt>ClientHello</tt>.</t>
<t>If the attacker could manipulate the second ClientHello, it might b <t>If the attacker could manipulate the second <tt>ClientHello</tt>, i
e possible t might be 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 second ClientHello. For example, imagine the <tt>ClientHello</tt> to match that of the second <tt>ClientHello</tt>. For examp
client's original SNI value in the inner ClientHello is "example.com", and the le, imagine the
attacker's hijacked SNI value in its inner ClientHello 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 encr ypted <t>This attack aims to leak information about secret parts of the encr ypted
ClientHello by adding attacker-controlled parameters and observing the server's <tt>ClientHello</tt> by adding attacker-controlled parameters and observing the server's
response. In particular, the compression mechanism described in response. In particular, the compression mechanism described in
<xref target="encoding-inner"/> references parts of a potentially attacker-contr olled <xref target="encoding-inner"/> references parts of a potentially attacker-contr olled
ClientHelloOuter to construct ClientHelloInner, or a buggy server may <tt>ClientHelloOuter</tt> to construct <tt>ClientHelloInner</tt>, or a buggy ser
incorrectly apply parameters from ClientHelloOuter to the handshake.</t> ver may
incorrectly apply parameters from <tt>ClientHelloOuter</tt> to the handshake.</t
>
<t>To begin, the attacker first interacts with a server to obtain a re sumption <t>To begin, the attacker first interacts with a server to obtain a re sumption
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 with ClientHelloInner. If the server only accepts resumption resumption ticket with <tt>ClientHelloInner</tt>. If the server only accepts res
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 when ClientHelloInner is for "example.com" but silently ignore the PSK alert when <tt>ClientHelloInner</tt> is for "example.com" but silently ignore th
and continue when ClientHelloInner is for any other name. This introduces an e PSK
and continue when <tt>ClientHelloInner</tt> is for any other name. This introduc
es an
oracle for testing encrypted SNI values.</t> oracle for testing encrypted SNI values.</t>
<t>~~
Client Attacker Server</t>
<figure anchor="tls-clienthello-malleability"> <figure anchor="tls-clienthello-malleability">
<name>Message flow for malleable ClientHello</name> <name>Message Flow for Malleable ClientHello</name>
<artwork><![CDATA[ <artwork><![CDATA[
Client Attacker Server handshake and ticket
for "example.com"
handshake and ticket <-------->
for "example.com"
<-------->
ClientHello ClientHello
+ key_share + key_share
+ ech + ech
+ ech_outer_extensions(pre_shared_key) + ech_outer_extensions(pre_shared_key)
+ pre_shared_key + pre_shared_key
--------> -------->
(intercept) (intercept)
ClientHello ClientHello
+ key_share + key_share
+ ech + ech
+ ech_outer_extensions(pre_shared_key) + ech_outer_extensions(pre_shared_key)
+ pre_shared_key' + pre_shared_key'
--------> -------->
Alert Alert
-or- -or-
ServerHello ServerHello
... ...
Finished Finished
<-------- <-------- ~~
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This attack may be generalized to any parameter which the server va ries by <t>This attack may be generalized to any parameter which the server va ries 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 the ClientHelloInner <tt>ClientHelloInner</tt> and authenticating all inputs to the <tt>ClientHelloIn
(EncodedClientHelloInner and ClientHelloOuter) with the HPKE AEAD. See ner</tt>
(<tt>EncodedClientHelloInner</tt> and <tt>ClientHelloOuter</tt>) with the HPKE A
EAD. See
<xref target="authenticating-outer"/>. The decompression process in <xref target ="encoding-inner"/> <xref target="authenticating-outer"/>. 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 of ClientHelloOuter 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 m alicious <t>Client-facing servers must decompress EncodedClientHelloInners. A m alicious
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 a ClientHelloOuter 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 in ClientHelloOuter 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 same ClientHelloOuter extension can be copied multiple t imes, <t>If the same <tt>ClientHelloOuter</tt> extension can be copied m ultiple 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 in ClientHelloOuter, <tt>ClientHelloInner</tt> by including a large extension in <tt>ClientHelloOuter
of length L, and an OuterExtensions list referencing N copies of that </tt>
of length L 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. In split-mode, an response to O(N+L) bandwidth from the client. In split 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 refe renced in <t>ECH mitigates this attack by requiring that OuterExtensions be refe renced 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 target="encoding-inner"/>.</t> requirements are detailed in <xref target="encoding-inner"/>.</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>IANA is requested to create the following entries in the existing reg <t>IANA has created the following entries in the existing
istry for "TLS ExtensionType Values" registry (defined in <xref target="RFC8446"/>):</t>
ExtensionType (defined in <xref target="RFC8446"/>):</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>encrypted_client_hello(0xfe0d), with "TLS 1.3" column values set to <t>encrypted_client_hello (0xfe0d), with "TLS 1.3" column values set to
"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 values se <t>ech_outer_extensions (0xfd00), with the "TLS 1.3" column values s
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>IANA is requested to create an entry, ech_required(121) in the existi <t>IANA has created an entry, ech_required (121) in the existing "TLS
ng registry Alerts" registry (defined in <xref target="RFC8446"/>), with the "DTLS-OK" colum
for Alerts (defined in <xref target="RFC8446"/>), 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>IANA is requested to create a new "ECHConfig Extension" registry in a <t>IANA has 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 registrations will list the following attributes:</t>
registrations need 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 the extension is TLS WG recommen ds that the <t>A "Y" or "N" value indicating if the TLS 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 value with a value of "Y" requires Standards explicitly requested. Adding a value of "Y" requires Standards
Action <xref target="RFC8126"/>.</t> Action <xref target="RFC8126"/>.</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 to the <t>New entries in the "TLS ECHConfig Extension" registry are subject to the
Specification Required registration policy (<xref section="4.6" sectionFormat="c omma" target="RFC8126"/>), with the policies described in <xref section="17" sec tionFormat="comma" target="RFC8447"/>. IANA Specification Required registration policy (<xref section="4.6" sectionFormat="c omma" target="RFC8126"/>), with the policies described in <xref section="17" sec tionFormat="comma" target="RFC8447"/>. 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 target="RFC8126"/> ensures that the specificat ion is The designated expert <xref target="RFC8126"/> ensures that the specificat ion 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 in depth 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 e xtensions <t>This document defines several Reserved values for ECH configuration e xtensions
to be used for "greasing" as described in <xref target="server-greasing"/>.</t> to be used for "greasing" as described in <xref target="server-greasing"/>.</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, 0 x8A8A, <t>0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0 x8A8A,
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 target="RFC9180" to="HPKE"/>
<displayreference target="RFC9499" to="DNS-TERMS"/>
<displayreference target="I-D.kazuho-protected-sni" 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" target="https://www.rfc-editor.org/info/rfcY
<t>This document specifies an optional behavior of Transport Layer YY1">
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 Bind ings</title> <title>Bootstrapping TLS Encrypted ClientHello with DNS Service Bind ings</title>
<author fullname="Benjamin M. Schwartz" initials="B. M." surname="Sc <author initials="B." surname="Schwartz" fullname="Benjamin M. Schwa
hwartz"> rtz">
<organization>Meta Platforms, Inc.</organization> <organization/>
</author> </author>
<author fullname="Mike Bishop" initials="M." surname="Bishop"> <author initials="M." surname="Bishop" fullname="Mike Bishop">
<organization>Akamai Technologies</organization> <organization/>
</author> </author>
<author fullname="Erik Nygren" initials="E." surname="Nygren"> <author initials="E." surname="Nygren" fullname="Erik Nygren">
<organization>Akamai Technologies</organization> <organization/>
</author> </author>
<date day="12" month="February" year="2025"/> <date year="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" target="https://url.spec.whatwg.org/#con cept-ipv4-parser"> <reference anchor="WHATWG-IPV4" target="https://url.spec.whatwg.org/#con cept-ipv4-parser">
<front> <front>
<title>URL Living 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" target="https://www.cs.ox.ac.uk/people/ vincent.cheval/publis/BCW-ccs22.pdf"> <reference anchor="ECH-Analysis" target="https://www.cs.ox.ac.uk/people/ vincent.cheval/publis/BCW-ccs22.pdf">
<front> <front>
<title>A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Cli ent Hello</title> <title>A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Cli ent 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 2157?>
<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 target="encoding-inner"/>) in linear time, ensuring that each referenced e xtension <xref target="encoding-inner"/>) in linear time, ensuring that each referenced e xtension
in the ClientHelloOuter 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 extensio ns <t>Let I be initialized to zero and N be set to the number of extensio ns
in ClientHelloOuter.</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_param eter" <t>If I is equal to N, abort the connection with an "illegal_param eter"
alert and terminate this procedure.</t> alert and terminate this procedure.</t>
</li> </li>
<li> <li>
<t>Otherwise, the I-th extension of ClientHelloOuter has type E. C <t>Otherwise, the I-th extension of <tt>ClientHelloOuter</tt> has
opy type E. Copy
it to the EncodedClientHelloInner 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"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>This document draws extensively from ideas in <xref target="I-D.kazuho- protected-sni"/>, but <t>This document draws extensively from ideas in <xref target="I-D.kazuho- protected-sni"/>, 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, and David Benjamin also provided 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"/> also p
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 H4sIAGXklGkAA9y97XIbyZU2+D+vooYdGyJtAC2qpW6JbfcMRanditbXK6rd
rMPrVwS70SSsbqANoEm1ZZ3ffvJalVVAk5S9H45i1xqRuBSqsrLy8uST4/HY 4/D4lYpAgSwLQGGqCqRgjd7Y2Ht5f+wd7AXtxt7Gns/Mk1kJkrL9Y3cZMeMW
dWW3KJ5m71+eZsfVtNmsumKWHS3KouqyF8ViUbv8/Lwprm68ZFZPq3wJj5k1 UMjKz5Pn4znPGY/Hrq/7RXVUvH1+WjxdTdvtuq9mxcmirlZ98VO1WDSuPDtr
+bwbl0U3H3eLdly0VTk+eOSmeVdc1M3madZ2M+fKVfM065p12x08ePDkwYFr q8trH5k101W5hGZmbTnvx3XVz8f9ohtX3aoe33vgpmVfnTft9qjo+plbbZZn
1+fLsm3Luuo2K3jMyfH7n1zeFPnT7PT4yF3XzceLpl6v4K5F6z4WG/jJDC6r VXtUPHp4/5Gr1/Bffbvp+nt37z66e891m7Nl3XV1s+q3a2jy2dO3P7rNegZN
uqKpim78HF/rXNvl1exDvqgreMamaN2qfJr9pauno6ytm64p5i3812aJ//FX dEeuOeuaRUX/iZ8cFffu3vt2DD+bNquuWnWbjlqrHHT4G1e2VXlUnD49cVdN
5/J1d1k3T102dhn/Kav2aXY8yd4V7bRuFrn+nD/uuCmnvV/VzUVelf/IOxg8 B/+1XeJ//MW5ctNfNO2RK8YF/vGon7b1tHhTddOmXZSu4L96BV15Ohl83rTn
jmhWrAr4n6rTC4plXi6eZsXH5r+abr6cTOulS1/5yyR783Edv+2X/B/ry9r+ MKjVrFpX8P9WvX5eLct6cVRUH9p/a/v5cjJtlk5fM98sFvQqfbgojo6K/+t/
PH7VT3nbLTbJWz7STfXH9X9d4A8GX/Z6kp2uF4vyKq/iN74upx97v4pfeoSr /s/i//w//tf/+3//38LHZTetYQA/l3/bXDTFqw+b6LU/ll2/2CZv/EDPNh82
X180+epykx3VVbtedGV1kb18eZSMpCqnl/UibyetPPD3KBU3DOtokh1Ost/q /3aOH0Qv5vG9rKcfilPoQ31ZrqLxvZwMPqcXneAuac7bcn2xLU5gaTaLvl6d
ehaP6uiyKduuXl0WTXpBMrZFvZ7NFyA2yVCm+fV/XRb5CgZ6XnbtBCTGOVfV F8+fnyRvX9XTi2ZRdpNO2vkt7p6dXTm5aOuub9YXVVscT4pfm2YWdehkkn5M
zRLuvCpAALJ3Px0d7O8/kf/8/sn+46cgptXcXvPbi8P3v/08Pnn7p4f4z0x2 /TlerxdV8uZpefVvF1W5hn6d1X03WVW9c27VtMuyry9prt/8eHLv8PCR/Od3
zs6v715mL8srnIZTFMC8mWXj7OTt1cPsbd60RbNDV+fNRdE9zS67btU+/eab jw4fwo6h/4b/vCurMau79aKEvf3T65+fOlev5kkTf/rTnw75WTlsP0hPHjdN
dbOYtKtiOrm+zLvriwl8yzf3pnU1LVawgVZXD8cruhnvncH2eZq9yjfZwYOD 3/UwSdiH7Pmi41Vc1f1F8eTlaXFatZf1tCoe16sZ/KTjRsv2vOqPiou+X3dH
ffjJ8dGL8WGVLzZt2dJY/GAOs9PN8rxegKTqBVk9z942sATTTQYfRPt4f/Jt X399dXU1aefTcTWr+6adwPi/xj59DZ9hT+g3XdXWVYcf65aCfh4V/vuiePLq
dl12l1s29A4/Mxny9fX1ZNpO6k+TfDpZf/xmVdSrRfENfPkU7pxML4urfPHN 2VFxeHdy+N39h999LaOg7/jcPammFR5jPIAP6HN/NOhv7Pckrctj2CjTi6uy
an2+KNtvnh39Np5O24ODyWo2p8fxV7yur4rlOawlfMoB/Zy3oXxHFqTCb41n 7f/mv+g2LS/q4Bu/34vH1eqv5bJeFS8GDSRvgAce191Fsx62n3weWn9Rf6ji
lzCQ3MgkLjzutabMh2/60wTEBkdz5zuOYsni641EOTcej7P8vO2afAri8/4S b5NG4fy+3J631WrYaPJ5aBSkwQf9Fr7+9afjt7/+Yfzs9R/v09yYaZKX0Q7l
JhbU3nqJkzYDpdCU50Wb5dmymF6CVLZLeHD2vsmrdgW6J3uZb+CjT4vpuim7 x1zYJHu/vHkOW//Z68v7xeuyhRXbc5nV3rSLSbeuppOri7K/Oqfl/gqE4bRa
TbYLq7CHy+EKXgEUn1wWgdYAHtS2+UWRrUGdNPA7EIYr+A+a32kGSnDCg1qW gyBeX94fr+nHzq/ci3KLi0aLCVINnu1hp8m67XE/iuf1Je7JU5SOZTvbw5E8
s9kCRngP9WFTz9ZT3A/Z53sl/vOLc4cLmOD1xaVf+c+f/wOk/PHDh999+ZLJ PflpfLwqF9uu7qL9vHdcnG6XZ80CxKA+UDTz4nULB3q6LeBA0O4+nHzDezl/
+9tsWbcdykp3WWTwBbP2Mv9YjOArpov1DIcHv3AyiGnRdOW8RL0+wp83RQaz jezt3M7TbtJ8nJTTyebD1+uqgbP8NXRvCr+cTC+qy3Lx9Xpztqi7rx+f/Dqe
BEOEX+aL7DrftPj515egBbK8yuoKxBnELe+6fPoRHwCruSjypspWKJpdkfnd Trt79ybr2dzs1pfNpd+t93acAL/jD+8/+PqbB/cffnv328k3Dx48+ubbu/TI
BmPPz+t1RwOBHVEV9EGT7D38e7XI4bOKTx1MJY3kNSgJB2oXx4K37p6+PtnL YLKKvZOT0+LOvXtHMNRmWlV0KHHk/UVFryqOT14Up8/+cHp8gmJwXsGmgPPb
4IKiwvMERzEwqXAO8NhgDB9behNLOxxloDQq2ih5dgFbvzJjgNlos1XRXOYr rOBfy/Wmhx7BBOM/lhuQhCA1QFbCMZ9u2rrfjor1elJ88+2D8TffPdq7+ZD9
vonmrMVXoZaw3wBfN+9g7Qq/wVAceAEmqfygIoDpJPmpimu6zn/CCCZrsYAH DEfgAqavNOJY75u2LvM/+uMEhCrO4a1/cRILWJH4i2Yzmy/gxlUJef/Ro1RC
bDl8d0Eb7OEq5F0GF9bXbTal38MQa11eHG3ZRFMBv8RPwHfxqk54VKum7uBz ggwbv3365sUpPvNs/GTCd8943TZ9NYX9MAaFIf3R6zev3j49efv0yfj05TPn
+QNhNmH9ZlmNi5yt4DdVV8JbNuarYeCLGZ6sa1xsus8drlYLXRIW/bfw2Hpa xuNxUZ6h2JyCvP7dv8A//wyirZr9Ba5ameAOLuoD+Oc5bF3cxn82h/AvI1gd
L7LXYArAM3i1Dl++fb3nQGF0IJX/ibr32wf7X77A/q3Hixrlayaja1lhwWKA 2J+tPnyno01SwGd6NCbuLSwgHkDo2WU9g43aVqB4XFZd0TdFWazL84q38t5z
TsNh0Aw1FQ3mqmzL8wV9jIMr5uXFuqE3tDT68+Iyvyrrxkpzu17hxoTn48P9 uFOLX0g/mRWH97SNB3sT517CsOBtZS/HW5vrij242pZ1X3Srcg3ip+/2ZNvU
pdOSTpp2XXYF/cRd1tf4SZusKWArwyUwcfCYeolP4Zk2IgLzgDKAQp9XdbVZ bbHgs9fJ2etwizj4qq0KmF7YuZdVWy6KtIVi3jZLPwTuHe7DBWpOfXFWYaP0
4m5vi26S7b6G2XO0TOUSFCeuPI1xLMs/zeDILKeFmcogx2DwFA2+EWeBRcmp zL27zo+0+BEOZ/WxXK4XpE0F8bB/nYjhl4/9y78+PHt49nD64EF1dv+smj2a
MMMvs1mJc4AXzlHT5jBEGGdTgLEyGy9oBWBT4elU4gtg/+H3wPENF7pZOZ/D H37zaPqovP/No/nZ4fTwbP7gwbffnn17+CgrnA6c+7WCKcZWQSsqSN3D7sYr
Hh6e0zB5Be4G3BnbVqQ//ZO97FfSYqRYQLqCegSjssgXrQiuziRcopNZXTj4 hXOPI1o2MB44Ii2KDpgMVBb11IkcTeTXCBqB3TTlNnlp/QQtG5jV82pFs4rf
hDyDg7Arp2vQw/RimCGU0asSJmSUnYOimNUwB1XdySNla4uqmjf1kkQyWo4M yGt0Aa6fiYMRHeFyRjutHKzsnmnS+aHA5jjhARy5aHcGVU6vjlHuKhgVeUE9
PhMWMMdFTvXM82K1qDe0MXGhRIxb/QQ3L/JuLRpvVrbTddvy9v78eeZvBRl2 wvWzbeBSjorffel18QN0cHZQ/PinZyNVYYr9RLvvLqdn42p6cQBTuVjABuN1
DnYmfhAODX4NtkexmMPazmGt6WPh82S30SBKtBtxgKKFw7ZU9ZSJelqCLQBz g2MwA/ElM/3vL57jRJ7jiF/9PIHj+0Nyal8vqrKrULRUbQ9zuS1EO++K/bNq
V8Pi+HXqLhvS8rxVcZarYhFkyQXVKVP9/PVp9vd1gQKBEqTPkXk7eZvlsxnI 28Dkgszr5CCBslSVLTyNJ4IvoAO6YDYdydVrtKAOfji9mBTUhbe4s8Bu2Sxx
SFu0k+xFfY26feSCPsPb/Wq2/jX44xof8OL9+7ensqsfP3z88MuXUeZ/CZLy E8GRnLb1GRzMsljCkMpV3S3hJcXbtlx1azAEiuflFqS1iuZiHy40erGr+DLj
zXNUPbLrHz96DGeRXPzgCV2Mm8/f8H9+PTmS3z85ePTgyxcnMmDHgLJpdB+Z 1X9v9Lb30FTXoaTYgKYPkh4vHdiuBV1WUxzmhOXZsp7NQD91X4HY7dtmtpni
U2AE4EMWaBWD1iZxAAsQfQo8+leq2XHzL/NqYxRim12ifl+ikQsbVia/dbDL RVB8+qrGf3527ngBU7A5v/DX6KdP/wLL8vD+/W8/fy6kBx0fDDkIMIZZd1F+
aHng6DHTNGErC46yuikv4LpolVgyCtJFJbwKBL5eLuGcCKKsmz4nOQbjD4Xj qEYwjuliM5MVcdKJKcx2Pcc7p0KJmEqXq3Lb4QRcXYCCDqsCcwtbA05M2ffl
02YC5zr/rqiuyqauULzakVfPTUGjIhmHw3SZNxvYxii3JZws5QXs5gysp3KR 9AM2AJcMLF27AqkG9zxKUFV9oe/lWbPpqSOwu1YVDWhSoFiFcwjDqj72pM5C
k5TUWX2unwf/mBW8EwpzvN9vvSgGIQ76MhxkkSUBqxv/+Mn+w+91HeFUg0X0 Qy9BbXJgEcn9V+yDnD8AmQQ3LZ1s6EV2WsEw495BLz509C5WHsAeBRV/Rdui
mlYEHK/HeacbV3JAtBO0ZcC5uMIhqF5+XszLqqR/O9oQYABl6Aa22c6rX0/f LM5BE1+ZXoxQ0q+r9gLOZxAnaDzWqLTbUcD45j2sXuX1FdwSvASTdA/hsYIJ
74z47+z1G/rvd8cgMe+On+N/n744fPnS/4decfriza8v4fdO/ivcefTm1avj pT20qq7ouTCIablYwO9Tzcexhr8PutWBbHD491VXTOlrum7k7XI7xFMhcgXf
18/5Zvhplvzo1eGfd1hgdt68fX/y5vXhyx2cFdIO/lBH9dDR2uO2a1ZNgZMH xes6KQrqllypPEKYUBJSDa5zsW5Qh6nhRdswbAc9X8zQ1t3gevPv0GySVRnz
66vWIs3ks6O32f5DmDFxQWgX0KTufw+7wF1fFiKcdQVKmf9Jx1G+WoEBhc8A /gc9B2zjZlG8BIMe2uAFO37++uUB3Ftd7z59+lc0lb65e/j5M2gWzXjRTEkm
dQ0KfVV2Oe53eEMLZ1aVoVkGThX8EvUyKCE+c0HuCtkH9FZcvRFapvTbb0lx cPc6FrtorcPTOG04RaBSY2cu664+W/Bo4Il5fb5pRSXC3p9VF+Vl3bR2Q3eb
3cveXKGqLa5dMAro9C5p/CBVBR2ENVhDbL3B+FjLX6NpsaoX9QUqlnKxWKPR NZ5OaF/uAX50WpOF2G3qvuL786K5wiFt8SJfk0xpsJlmia3wZJs9AvOAmwD3
3JHog3Uycqyerwuya2AdwLyHX76qZ8UOT+opCG/HPyCrr0VDa4bHMWpcO3so fblqVtslHvmu6ifFPt7pjlaqxjsTl54nSNZ/WoBBC0aamcqwC0CqVSQacRZ4
s/MajR460kWDw/jvZe/9GJz7f+GPN+31z+/HQ39+37vun+kP+KeD1x08eLD/ LzndzfAlKD04B3ybgSgtoYvQT7wY29l4QSsA5wolfY0vgCOI4wHjGgXirJ7T
9Pmzx0+f7sOf7dcNPU+Muj/QMP6I14lpPCk+5WgwoI/4Fc/rX8eug38cCMLX 7ZKbUzN5FR4HPBq7VgQ7FU//5KD4hQQZyRbYXUFGttBcuehk7+pMwiM6matz
jC/9yV3nT/+wwW5+vctfPP4pn5L3A0v/DL0D+PuoXp6DTprt8dJ9fprda0lM JyoTyJvpBjREejGasaINQZ/OQFbMGpiDVdNLk3K2RVqR3oI7PVqOAoYJC4gK
xigI7O3+aCVHl3uzAw4P6EvzK9aUqmZRgPHfrKO9kYDmPggj/ka0PGy1GgQP zkDUPIELv9nSycSF8sq1DMHNq7LfiNADXXO66To+358+zfxPYQ87B2cTB4Rd
zg7HVhRsgrrkQ7vsSCmzQeNfgUos2BH0IjUyQPY3oqB5GJO+UA7O5+/vOtWD g6/rvqsWc1jbOaw1DRaGJ6eNOlGjVwc7KIJYziWplCyfCpFPS1C1YO4avDp1
q/bPuy7ooOz+c+BXx/CH747EddufP97p3QNyqe++dQv8e9/97815FguweKTm nfqLlgQ9H1Wc5VW1CHvJBekpU41+gf/ckDWDO0jbkXl79ho1E9gjXdVNip+a
j4qziH6QZVRwsSh7ldeTZP+bviCjYTkszOpVizBP3LsczUJ+BNpDKtMDFwc5 KxTvIxcEGv7cr2bnX4MfN9jAT2/fvj4t+FQ/vP/w/ufPo8J/CTvl6yd4WuXU
t+/jQ8jKMJgJ8samWKDHHxvS2Tl8vT4lGiE637VLLPBk95BrQQ+kOYb9tkTz P3zwEK4jefjuI3oYD5//wX/75dmJfP/o3oO7nz872QO2D7g3jfgj7QTME2xk
I6+6xWbkrWPrCzjvBoC/Atb5FDyp1n+FN37F9LDjLDY1f5r11x2+zhorPiYy gX6qtai6q6pHtx5qDmsV7Xj4l6hDBInYFRco4JfogoIDK5PfOThltDxw+5hp
oXXBH7HphYuh7o2e/iM8367h8INrwLXSYWDgLh03Gs34ux3+0vGcpYmnik9E mrDVCrdZ09bn8Fy0SrwzKpJFNWp9pIXDRRG2sh76kvYx6FK4OT5uJ3C183fV
46rrrKHC4onbORcpkzvIX2jZPfFmqjgWZaIZ0Xsq+zIWjcSRBx29g0/i1eWm 6rJumxVur27kxXNbUa9oj8N9uizbLRxj3LeoS9bncJoLsOvqRUm7pCmaMx0e
LacSDAAnDfUczM1pUYBh0Uqka0zu4awQfxDMG5S4ZR18pzjgg9YmeDLgYpFm /GNW8UmozA0Pdo1uxbCJg7wMN1mkTMDqxh8/Orz/na4jXGuwiF7SygbH53He
XdDb0QUvOxIzEpfajHKUDc0bS2s8arYL0igKB0MoiOLc4eDDYPbQdm5pcKDI 6YdruSC6CaozYPNeYhdULj+p5vWqpn87OhCgAxWs6+29+OX0Lei19L/Fy1f0
OcR5yYcW/TByeiW25Eq0XDUAg18ZQnc0urxt62lJp8Oy6HL02sH59KcPGUnw 32+ewo558/QJ/vfpT8fPn/v/0CdOf3r1y3P43sl/hV+evHrx4unLJ/xj+LRI
Gvhct255ZpZgS+nrWeCSN69bidTxW/wbXLKf4g9EK8sIr5uhsS37svd590lp Pnpx/Kc93jB7r16/ffbq5fHzPZwVkg7+Vkfx0NPa47Fr122FkwfrqyojzeTj
LPNOnO9iUVzQsqBa4U9kQxNcC/A6WnTixSF4+N0DjO2AhDj4CW6Gk9djuO3H k9fF4X2YMfEY0imgST38Dk6Bu7qoZHM2KxDK/E+6jrw+ixc/CPR13Zd43uEN
k/Hzic8atVfT8zE4dSIrGh1pRUpQGHqDajFdBJ7YFQYmxR0//dPRM5po9kRF YD1cgUILIn1SHMOXKJdBCPGdC/uuknNAb8XVG6F6St9+Q4Lrq+LVJYra6kp0
402yN+Qgw7hLuHpj/UeM9JLDtqpbcoYn2U8wAjl87N4g3470zOAcgY4s9Ae0 FV0c3AnQf9hVFV2EDahDrMBB/1jKX4Fi0aybRXOOggX0+w2a3D1tfVBQRo7F
KX4Duz0EOa5zjc61Xc6LmYvfyfuBVqsFQz0R4RFsA4ywgEW9xhBd7nW3EeYR 81VFmg2swwXM1Kx40cyqPZ7UU9i8PX9Ail+HmhbaviRx7ezhnp03qPfQlS4S
65yGLXTREub3J6D5JKog4+kuOcxpHsuiestTnfn9m3XHghS9i36Kj+5Iqsuq HPr/VfHW98G5//E//oe1bOjvt+Pc328Hz/1X+gF/mn3u3t27h0dPHj88OjqE
Ahmr1212lS/WBUmSC5FEH+5inw92z47Xxx94rB8uKUERLnW7nz/7i8Yi3XTR v93P5doTf9bvqBs/4HOiHE/ExkZL5AvaGz7HxoNvDvbBl/Qv/eS286d/rLKb
ly97Guad5g2FOXAmiiEFIHPyU0mxr2ilYXhwTva+SZSQVy3v/T+yDg6J1vtD r/d5xOMf2bjGlX+M9gF7tc5AJM0OaOU+HRVfdbRJxrgN2HT7vd03utjbPbB4
8PPgouQcJHzq3D4caXPUav7YEg+bpKmmEDn+dFb4AK6NCZcYdESphJ1H+SV7 UFryV/g0y0kVsrh98d8sob2KgNo+bEX8RmQ8HDQ0HOHmcKxDwRFoar6y655E
QrH8DC0O7HL4v2Qlm+JvHG/DV0/CyNo1naHzNap4GUc7MBBYxOscjYkhQaPB Mqsz/hWieooWQS9SFQN2/lbEM3djMtiS2dn87W0nOrtm/3Xb5czu3P/KfPUU
8Vylsixro5+RnLJDo8WHYYRkimkyP2D366rGcOa04DRcWJf7rURt23j3+qgH /vjX0Wbd9ffDrd6d2ZX67hsPwD827n9szot4+4pFav50M8vG9zsZhVu8kb24
KtqC9AHMOE43PNBd+1fAS3cxqsdXw7NRL435d3k1LUDESFLhLJ8WxawNZov/ G+xj+ia/jVGpzG9lNaplK0/cmxJVQm4CdSHd0ZmHwy637+MLyO5gUBHkjW21
DgdXg96BexebSUZ6QCIqPO3FbCS2hCZTYx8CB7VuKXZzvnHmG8hnMWF2Pj9O QIM/VqKLMxi8thL1EC3vxiXad3J2vH+NdTk4bUtUPcpVv9iOvGZs7QDnTQCw
YBMXOTwTXyILW1eaGDC3w2Q2RQf6j4a8Xo27eowpuliR4efrOFkn74msa6jp VUAzn4IV1flReMVX1A7bT3UTVdZYd/g6q6h4l8iE1gU/YrULF0NNG735R3i3
os4XKOfyUZRyaNdke+RRYBx/peZDGSJoSVwW1TiYVGWLU7EGzUhfTtEK3FBw kWOLnHbaDQyCpP1GhRm/2+ORjue8mXiq+DaUX+MU6ayhuOKJ2zuTTSa/IFuh
Ma7WBIyVpqhFI2K8Y72YwUxflgWpZBgIjQu/Dc+MfD4XCccIX/GJH5+pkYLr Y9PEq6hiVNSJXETLqR7usagnjqzn6B18C68vtl09FUcAGGgo5WBuTqsKlIpO
t8KToyBrz6dp2JTBJ8WGCx9sidXiH8YCwQlXupcCKsN2x1E02Z/voXhFC/CF XF1jMg1nldiCoNrgjiOnqdhNsb8HNU2wYsC8ov4s6O1oftc9bbO+8mvKvRwV
A3BgALTZi7e/HLPBHgwJY17AkYpX/Eiht8d40tJC9Q4njuHgCa9uqVFQZ3A5 uXnj3Rr3mnWCfJCUXCjOHWcbg9lDvbmjzoEY53DRBd9Y9GFk8IpjydWotar/
D+os4+MA1tJ6q/Uq//u6yF6sPhZvaRi/FJs/7E8mB/93/7vx/h9/oIvWYGzv BUcZPHfs9O26ZlrT3bCs+hItdjA8/d1DChK8Bobr0D2J71mCHqWv5w2XvHnT
f0cX/VIsT2Y/xD7YN99wPI/PaRlv78bZ/F+78RDkP73z1hv9Zx+ranu/WRU/ qeuU3uLf4JLzFA9wUkTOKDdDRVvO5WB4d0hoLMteDO9qUZ3TsqBY4SGykglm
JDdqlGwfxMPR7TxH2WfvF/qhZx9n8w/l7IfoNzy2LIe//O++0G9ON0uwApty BVgcHRrwYgzc//Yu+nVghzhSO9ExLDtC/R+d7AVc8sGrO8RkgK11id5HMbhP
ekQZqFNMQP2w5R045seyqL1X0ISDbCx7v/HrJQL0AQQovmJoEJIS+8ApsT88 /3jymKaTbU2Ra5PiFZnA0Lsant5aCxGjTGSSrZuOzN0ojGFPAFlvJE2yMwGS
lKV++Ec7engoT9+2IQ/Pb4Z4nzAEkS3UZH94kIjUl4FHbHtZNCLcJh+mMrh4 sNIPaOv/Cpp5cGNcleqC6/qSl6wUy5J3Pa1JB6p4slFHsNkJktK3G3TClV5C
Bpf5p3K5Xn5ApMmHRVFddJe9wchU4SUk5o8e/fGHG77K2DA3fQL8L2bM2ptW R+67EcuWlrVwkQb2iWcg4tr37DuQPvUX7M00TfOmvLFlZ594hcHH9+yRHX6O
GKRSAuY/pD9Px9qCEQ737/rnT+TOPfPMDEwK8CMefJoXD2ZP+2MhM40HpTd8 L+hpF9erFeypZtMVl+ViU9HOccFZ6l1bbN/Badnz8vcd9/jdBQV3w6Nu/9Mn
Scf9AysCtnZUPQT7LtYlnBgGW0cG456SeSj/0kMDFRpbAn2HBlUVqL7ZxN7o /9BYdjM99Pnzgfp0p2VLLg2ckeCtyM3NjzV5uqJVhw7CzZgZl4Z2VJy89f8o
JIRHjm2uYYdZIXELfB7aprebjhNRxW1GmYPyokLtjieE0YIufCadlLkfP0Xh ergYOm//wOfBJCnZKXjk3CFcY3OUZP6qEoua9lZDXnH8dFZ5n20YOO4KNNzW
Z7W13UBR8tLIp/I/MO0MmrbDxKtYhBWGImh+xM7hK/lHclq7OE3MB+jHcsUJ hGCiaL69lXg35RcJzrZGwsKattVf2cOGL5+EvnUbujkRkrDVnnSZrsBSXlGA
MTLD+Nd0nnL2KKNU+jUhMmh8bEU6AhPxrGmyOV4GERvnVAjgCw4r3QQ4eFxv Mb/tqIM8X+nuljXSoSS3a66/BH3o6E5fhy67X9YNujCnFYexwtrc6cRT28Xn
SkBTXFQvyxjwlklOTB7KfhPlQ/R94qBK7IXvJZ+tMrOtohifPTiTN15zqwAG 2Xs6UMBWJCFg1nHKoUF35V8BL91HTx4/DW1jpGrM35WraQVbjXbsmgP3XVBX
FYCflZ1FCiJ6EDgKG7UhE1E04A7junuLj05nczLvovuCAg7/2NmbZJj+Z6OI /DgcPN1QAHmxnRQkGcSLwhNfzUaiQyi8KbYcsFObjvw1Z1tnxkCWSnCtF3xv
52V48Gdeq5/x8NVMJlMvBD8woAPeam9WYLoGtJqKY11dgMtJyDpc97zvXs6z PIMjXZXQJr5ElrZZaTzA/Bwms616kIjU5c163DdjimBHog2Hr/3EscOAZb+r
j1V9XZELgIJN/xrx1iSfjaA75wUn0evsH0VTw8Wd7lTOuy5X4HBkq3xGUAuw e+m8KRe412VQFGnoNq0E2owzHL9StaEOXrPEF4uCHXFJHU7FBmQljZw8FHio
IeU/1V5Wn0d82TwEL2loPGhw1RHdw3nU4hMa2DwO2SvlfJQVk4vJyAWDnw2l 4GFcrQmoyG3ViIxEH8dmMYOZvqgrEtLQEeoXjg1vkXI+lz2OXr3qIzdfqHKC
63IxmyIOr6L70VCezeBuxNbwj2QWY4iGc0bZy5RhUEOna1v4BKZtUkxGfl3g 67fGu6QiLc/HZliFwZZihYUvtERb8Y3xhmDQCv2WnCh5feMkmuxPX+H2ihbg
cYRuLWYY+1ivyKwejBMEJyfMHbg6oMqXZRsCCJrUHrk0fZha5/ANTzM2WxFX Mzvd4OLvip+2Z209K16zpP4ZLvanQanYR+AYBzGNfmG0DrppEXGGXp23uXuM
N+YPGuMXiAUrcBaPt9DcJLvcsMTlTGOydjrgweFko01EmsYqj3AGinMvwh5i HTp45auVaqTXe3ice/u+4FsDFtkYr826/M9NVfy0/lBxB6F/vzucTO7998Nv
Jhi9QueYwCkuigxSZjO7KCr69zYw3CQ7BiN/4JXukhLnB+Ma5qIjs4KTpsGi x4c/fE8PbUD5PvyWHvq5Wj6bfR+bZF9/zb49vtGhuwX2d/DL2fzv/OUxnIz0
4FGNgnI0P8UVgOMCDhGJlIVH4QRdUIwbZqnF5RXtIFIocoHPIj2v2AJUmY5Q pzf/0g/8qcq9t9t19X3yS3WaHcLOcQwOolkqPnlL0Xe++DCbv6tn30ffcOeK
O5MbpijOaFKCFLcLL/04zHjwu27QXbcoQa9ZaPnAmxqTWudUP1zV6NEpuDdS Ev7Hf/eZvjndLkExbOvpCQWkTjEe9f2Od2CfH8qyDl5Bcw77Yjn4xi+ZbJ53
aKjJbhJZ8EkN4qJkIF7hI5B0DT7WLmbwWSaZ/9ZyBh/pApIS5XRos7V0OspL sHniJ3KdkAjZO46Q/e6+rPb9H2zvoVGevl1dzs9vgcDd0AXZXijkfnc32VWf
VClNUMUv+dPeqy5GQxe8rnwFjjXL2CsPPtr95fjVnv102neE7xLc0Vmwkc/u M03selnUIzwi76bSuXgGl+XHerlZvkM03rtFtTrvLwadkanCR2inP3jww/fX
ZChkqaHgeAJYmOF9WwyG8B47eHOQyDzHzrsH9vWDWC4y2FX1y27lmXn+E+2O jMqoOdcN4YTRYd11Kwy7Uvzn36efp33tQC+H3+/79ifyywPTZgEaB5gWdz/O
w+PD53YSVnnZBPQgYsQw8IzLF1CqrvdC0TdNkS9M2DasX4u4NrQZBIqFGhxG q7uzo2FfiqnvlP7gc9rv70kUsC6k8iFogLEw4TAxaELSlyN3RDqkgeGgdEJh
I/I8GHD3gdyWgK+whatpoQZjAvBDpanqEW4vQYP9g4EWvAda67365Qr/9RLG xkrC0MZBYQVScTaxP3Ti0yNbt1RPxKwSVwa2hyrszdrlRKR0V1AgoT5foeDH
4r0aNNWDhXsWXTS41yjKJ3GBQWFoCWBXTGF6SBRIJeCnrCiuhR8mW0piNB7p y8PIQRfGSZdo6ftPTvlZY1U7EJW8NDpW/heGoUHY9hiIFY1xhe4JmiHRgfhJ
i+aehAQVgqSWdKtzQaglxSe1qMXlF5iPWWLcquW0RxxoOPFr3maf75kduDUF /khucheHjfly/VCvOUBGShp/TXctR5MotI76DjsEtqJlOsLq8LRp8Nmsgxkv
wvoVD/1aTAQzl6zMRooHtDtJ49MgyK18Jz5EIDcyjSza6wYhiAufXylm/sHw DEH3AQ7ieKUHAfuPi04xaXKW6nMFI9QLCZNJu2xoUYhEXyl2q7hk+Ldk5K1M
8msQOIKxNcVVaSLIdMighdB2mG4juA2K7ShrEZjuZRAvmcLhEaU/3XpFMdDs D3Q7xjcQGR/XPXPjLgxigMZVvI+kRNQSGBRb1TGT/WgQH8ak9xoh3s/2at5H
/fuXuIxkIOEWArVkZ2HMswCibaHeHQqbBkYpwYNhwJaTqvpjAU6bXSPTgNsL Mwd3Ofxj72BSBJgfT0y+9++9aH/P/Vc1mlTB4BRBRw/Yt5l5gRl7n5Fu7/2+
LPwcDvtV0ZBtieOlc3CbpZFhcogEzxFWbXgh4AXwTVd1yfbSQE5PH8fL4LxG bFbnCPXD73ADlEOrdF58WDVXK7IUcIvTvwQRSQYewXrOKo6uN8XfqraBh3s9
5bgbjMiaoSFUnxXR6SugRhkFgVxh1ziDlsoY+nOxwfPiqsxNRLLFnAoMxRtP sxyQJehqsRbMGyia8p+qVKtxJCZwGTyb1DXuNlj4iPzhAGv1EbVw7occmno+
ddaANNdLSieiO+vsIOD4LdDeht+uQXQXUeQcrHLCmfcmBFO1nUZRqwIXB2OW KqrJ+WTkglXA2tRVvZjBcs6oNYp6w+vh14i64Y9kKmPshnNG7OucoctD52uX
+CkDX5hPmxpWL6Bh4zyoQc2dh6mawFkaW9EkanAFggcD4A9xUf7Jbvhkk/2z cwXmbVJNRn51oD3KWKlm6Blh0FvevxBMoTB5YBCBVF/WXXA8aLh75NLAYqrD
ABuMYnH9IfqAJnyrkRrHgjTJ/sSXWeRhU9ABUs4lnS/bx6wiTo+IvoKqwpIO wyCOClZuEQo85hGNcQSi5wrQxSMxNGrJBjqscT1Tj62dD2g4XHJ8lkjosDxP
aI/jkKbxysOYKhyxjJ0nm9kBTanWrmI4mxpOhjnb6QTyyxduvq6m/J8UVIVB 70PxBcieD84WdG6hHU24FRc5DinoKTDL68Byk+IpWAOZl7oLiqrfGzcwHT0p
ggOgoQB2xXDoeQhmgqL9/LkfQf3CWrJsmhrV3WcN4j2cHKAy8wBGg3K94QPI GRxRDfoF92sUJKX5FBcBLg+4UsSVFprCOTonJzhMVIcrLGJCdqJsDWyLhL4C
tuSv0M3Ix/PJ4evDCN7nyD7vzc+4zKsc3zYQmTXTxIeX84EOb6jzlc0aE9Lw D1B4OoL0TK6ZpDjcSdFTPDK8+uMw6cFAu0aI3SAOjYzhNQTLa0wynqEA8GCr
uqhWoH1qH/Hq8M+CEsShoMjQ4cN5247MYIVMoqDQGQbqlKF8Bno+Z2wojoIM d6kA40i4oVS7buOC/WoQGTVj9SrvpaRnsNl4RYMJMyn8gOsZjNQFwCXu19yh
a1HY5k3noD8+TrJfq0X5sUiGNKIsuDfUUe2dI5754oJP6SXWTHU1bMtzby6l 6+i+lNeodJqgxEcdWI8v9V7sqXINdjjvtRcen7T/89MXB3b0dAAJAibQpPdB
803xHQ7v4A6gWbksEexMp+k55gDYH90HgY2MtRD5CI8kY4jQ/pfF9CMJ3roK b35/K+WhSJUHx3PAmxret0OJsC+K+m+uFpnt2Nz3CMCc+8tFmry/CuTs+vl5
AFc/IuPykEOMBtHQdbbeBLGS5CeM/NGD43BiNHaRWXEGoz2EdZmvyaqwNTBo UpEDEifnx82KDZ79n5/8yAL7eINuxb5mqJ6xTWmAx+FOfILnaf/46fGTaFLX
QpVkVlPFQDVfsBHUS0TKUXpeaKiFpzXsb/sRartz9qZcoKKa5muZoRof6CJT Zd0GzCLC0tDfjTsioGNdpvciytqqXLB88yLMt3XRoFYi+C+8HWBkck6ynn7v
HVMlLWNPKcjE9ggbGeyfY7q0pK14XneXDHm4AkdmRbvUxSnXEi3GyBnAZWB8 W+4IcAuigTIu5hlfNMljlbyYEALC8W+M7uCz1Rkr2a9/+K/n0BVvOqE94NXo
hcDw1piN7kqu/UD7F1xhUvCOwcxtttsKxAS15ljrE9BFQlQe2hRN3nZ87PVf 99Ez2RNMjkZxS2Q3V0eYvmoKk0NbiwQNDmQdUOR8SsVF5PHFqFGKV1JRT6qu
yNFDB/ZZNJmsk9aYScR9WYUqFVgjd4+0ztaQYvDrPt/bkowGi7KGeUMwEDx/ dzoTBJRSSFSH14N8gWGgJbrNOo62xH6OZ37Nu+LTV+ZI74y8sNRGdaIR5SMa
IMN8p2y36ud+bpcyi3Io0oKQ9NMhgM9PdgCoygHHQa3kolovQ+B4eFC7HEfe rghJwSDao6keczgWnQwUWxGYj8wjHxRG0i98XKeaSbuEo7mCDUfQuba6rI0n
G2W73z169O2jPQ0VR/kT523pVb5Z1PlM/eUwlMs89Vi97fzUWO48JhbR3Qd7 m24vVD66XvDrNe3bUdFhcpHfgvjIFO6kKOzqNmtOBXn79jmuI+le6FEGQWen
I17Z3f09CU+Hr+EXD8bV+xfGGQgbRzcGG14TR9I5lE6DeWp/rNmHWxMpP6R3 YczTADvbYsx73GvqmqXAErohOw7m6seC145kqkwEnjCwI0pQJNZVS9or9piu
bc3pxOkIWIxeXqF/lUx2Ly9nB0/z1xv88XLVhaTQF5u4CBNifSSaA7OcFIAj 2F1aTIFhKdp7jhByu9YCXgHjumxqVscy8URtkJfCeTnNvj/ok1V1Q9igqPBi
LUe/QcsFzOSqU/ig7Mj+De6MfuNv4IM+vZr8EFAxOEz9TA2Romqj+i44e1Wt ty9kOKX0hOC1cHicwWkVDDo63+JNdFmXxi/aYawHOuOVs6ZoYVM3SwpmouVs
2WoOPLPRECRHKzZAzFlGaT68gcvrFK0u9+oLksJCHmw6Fz3RdoPBGMnSJoHc b0O82yuUYPDtBnbwIvLhg+5PIPfMpGCouFdv7qrCRULfKV12w1GW07aBVQxI
ELOe+It9hGaKQfjY0LXSJQ+1xWze5toaOODDgdSGGNRsdSrgUxH3sYc3EJmf 3DgOaxB7Z2G6JnBPx4o6bTl4AoGLAWyImCzfssvfmXKOFqDlketv2EXvWIXR
RAGIM/X24cU2wlH40Azr+ZEPdETlKQH9EjuWZ7L4Z1EahfMnGM0jAUGzp39i mr3jeDtNij/yYxb12FZ0LdVzgRPIMYpWEidIDoFCusKyZgTJ0xA48nLE6ELs
thz49NAQxELQr98hIOIdhhtowPIGGbSNLdCZpWfaMQcO0/kMamwULnZs4NAE O43NNBtrAqGpGrUiSNsGrog5GwMEMSwXbi5XHQh2dO9CJ8HKUM8DG33Y9TJ4
DMVyNYTSg4zRyZFsrJDAueHsCDZMgM3C4NA2FFm++8kDzp7zOAbjBUh0djTw T0Hmfvo09OV+ZoFZt22Dku+T+gzvT+6hXPPwSYOxvWYApLzyKPRQ8rX/7Pjl
ScNu9MinTUz5hkz303AODalvH47JCL4iW6Q1impghOYc8ovOscPSFNbY+eHd cQQudGQDDOZnXJerEt+WcQWbaeJbzHm/ijcG+Ml2gyFxeF2UqtAd2SZeHP9J
MgBmI0OwC6XQLQPoyjaeKiNbvGixchsx5i4YAY6P63O0rjh8CItijM0P/uk7 MIrYFdw0dA9x5LgnPVsBm7hV6DoDwcpAQgN8nzMyFXtBmruIbvOmM5AiHybF
oL8KihxGE8D5uniGevEqCkCZiFUwEkO8anR7wGokPvBAZDKRANdLUEhBD+pi L6sFZuXGXRpRHN5bAij+zhBNfX7O1/USs5/6Bg7mmdfE0vkmdxJ7k/AM0Kxc
djJFR3rA1g7DkuIo3w58rgfnJSESuze2yfHI+79ihpQMuk6WxR9SHthO+kY8 1Ai1pov1DKMRbPQeYnaW1QODnyU0SRoW5RpcVNMPnIK0CvBa3yNjVpHVjbpR
856O8HaW+7qt5HOGXyP8crTTvIiT8JfHfzVy3xuekXrOcrDZ3ld19pmZROhA 7jmb8IJITTJERv4Swn440Uf7SMNAEXUM6zLfkIJhk3BQl6pJaad8hdV8wdpQ
J55dNs0HBrt9sJecDexzCYHIDh/DnaTE4jp3skYtuHgHZOJDA6Mom2Imgj3y JjAq1+pZpX4dnlh7xu1A1DrgWFK9QHE1LTcySw226RJjAEM3HeNfybHFCgpr
aAC/wLQ30IqlcjicdFry4o4QUXahENVHp78i+wROpxDoXUmb4RhaGPyewsVr HewKwCBuTQfyrOkvGHpxCfbSms6qi0PBNWqQicEhIWgGewgiMNJsUcUGy5vk
ZT/oHZls7dPvxyRIYOU/K+a4s0LAPDL1V/mslcQUxzYWG0qXcp1tHzxJVdz5 vWNUdVfsd4J3QRE61kQJNMcQIIiKRlt2Pd+Dubey59Ih7UTyDYmoDYY48Ziu
XY4Yj+jCHNINYhT5PHbCUnAMZnbbv3CW60M9/yAp3CBxw2MyQndmH38WzmbJ QsoMLJn7ioTQTodmsCM/fbUjWg66ZgMTiOgkaD8TAL9VOF7FdS7wTEFPuSlp
D5PqAKHCEtv8I6dJpvWKyp97E5FTeK3z2bczRJ1PNx8EMR3y5T5BTgYAYxbI beg40L2Ab0iOBMjOrIUiGnS12iyD5zrfr312ZB+Miv1vHzz45sGB+qqjAI5T
LwRLkPPYbIQFQ9VOSNCYIagUhYz206AR1oI8p2eX3S3PnMWRKn3oo8m38kiu PXtdbhdNOVMLPXTlokxtZK9XHwWdnnvE23X/7sGIl3f/8EC842Es/NqsW3/4
mPVo/KK1Jmf2wsN7/RPvw8fU64YTeZdFPuMIHg2nQlPxulhcFemvcbhssJ7R YBwAsW788NwEn4kd+ezJp84c2Y81+HFjHOf79Fc7Q0pxNASWYhDWGD4lcz2I
IuvMkSYDtY6VcPgLRkNKnvOsJwln6oiH5D7s+HcUqMVlWmDJehQI0grnHbRt DNrO0/wNOv90ue5DTOqzjZuECTHWE02BWUxy+pHQa1hYXYLIKVe94hnlVA5/
qaBvh3Xhqm678d/XoIHBycsXF3UDP122IxgNfEJR9XceykMfZw7qYAGfSWbu 4N7TN/4HfO+nT5OFAlIDe6mjVN8sSjlKNoOrWCWcTS3BKxw1QzLBYn3EXG0U
J4z2Iqq8BZsNQ+JwXs7WU0HBwM8k+h7tTzSL2vV525UdIhiMWyAuBiMiWnct ZMQfMF2OQuflt/qCQaIjdzedjcHWdrvcP3n3+iT4zCfWJS1eoSlGAVIV+L3d
yYbZmhG4PY9AjQUJU2MsFikklvWVFjs2xWrBkWUb9sMc2bbtLqlpPJYXojzJ Zr5tm2Xn1bFrfBV8a5AIEY2blVLns+zVoLOG4E1DsO6P9+oegF5ELpbKu4fk
FgzGQRvZeypuIRf2dKuTP/AsdPFnDx7c5uJzYi2C9dHHB/PrDwcInHv4R9EN FlBHS5REEzA7sSn6XnbF+yi4w1EddCvSzkH1KHezduyG9XAWxG/Q928QxPEG
yW/jxDVNEVrV0QM1sUHpfz7MvDXCJzm5LDi127hfTIGCBNPpWDkv2MIB2xzH PRTUZXmHdtv6I2CbGwzUU/ZiDuY3iLhReNyxNkSTkHMuq+NlgH2jeyU5diG2
ASZHvW452pXOvy+B2zL15tW6leCrCi2a77tOIPalYIu2rfnEHfqQuBYm2BAv dM3NEhSegPKFXYKKpOz0299LYB06D78wJoP4ikeZIeWt75GP5phMEz/jekPl
WY2+Ery3IyzQmsqncEMIKkGj3RIK5jSAHMZLtmoZv0HZjDA5BO5yvigmXU1K RLv34hQEupFt1xkhlulguKH8qrMLszYZQHZ2+PRksXikNfYhcbtjFGDdxVNl
tElez4z0cJQ9G2VHdLov+ma180IQ3/NcbzseZT9JyvjW2Z9SDJuCm9Zhd1vm thc3FIu+EQMHg4rg+Co/QyWM3ZiwKEYzfedb3wPpVpEHM5oBCSTe6Ooi39WN
mNfVh8LDdBYlTk1/VutmKHo2VDxC5z2Jp7A5kXtrjrFIAdNZT8CRYawd4eVE zq7Rzd6ukdjNGR9psg3cIGwiCUgortksFSHqwWZ7DKmKHYTI4eHhhYlzxR6Q
ObMZwRcoIIpflS/rNVnFCsAiGpXZbGJVdZTIxGzocom8dTMP2mqnl8WyuClJ XZt55G1m0VNqBoona+PvMQ/GJ8kj1vxAVnhFzH3ZefLxzC84AXL307SIVfHn
L8d432phTUfuKX0m8wegOsYKGzzvy47j8u02sR+FfAepS1S2G2LkmaOwJJYF h38xm3/Qu7D1OezCCv5Q4NkmC/HtgWR8f9G27xim984+8j5z1MVpIod8DL8k
6DcZtoTpN/4zGOKCol2NcdpiJxh3KftcgveLyk/RuAQ1D4bG4oPPpwf36zVi ORan5ZOyauHQe7Aj3rXQi7qtZrK3Rx6s4JeXjgcquZS8h1NOC17dEuTKJhfi
OEsyXmgW1Xbptpk+lHGoV6XGu7aaMHQIDJ4l5DUilwnnY/PK3bYZaEbmSP0z EUk9UEyiAAEVtL0voTzsQwedP1CAe6N0DUUq5tkcoO/HtI3ADHhczfFkBV97
4hpKPHS0FKrnkbhYQVnoRRwiG3aN3/+vzC36apStSqqnqMYP4/Zwiv0uw7yJ ZAusS+aQgcVkX8hiSzFczgrOAT8p65zi97e4ajzuDCNbu3dSBJ6zk5bidzDk
PwNmcQqG2CSri8ETQO+NbjAPgnt6Ks1kxqYFPWGr13Hbw+ju95dpyHGgZs4u 3P2ZQ2/vmvk7iS2HTZfvU9h3723r78M1LXFrkh2wrzAnuPzAQZtps6Z87cxc
BBm1NUVt0wfC8SuYono6XUcqXzS9k4pgo9spS3VFPlkVWNlI7iStzPb4Cn8B lOSV631M8D2C5afbdwIBD+F8H78nbYAxFWRBgr7IEXZW1Iw6GxmLQXAGX1Tk
F2GuXkG8jq8f4TafIvNmD67HX8AW06ww/g0puCVagWQcDqhRn6EKzErzdUNq aTpMfU2YxPKEWq/7L2nVhVYfTL6RNjnP1+cRVJ3VTRkG4YHKvtE7MKZm03KI
WBiW9HEwkjGMi9zMkwQpHeAl4v4Mem8lZgIrTI92Jai67P+s8xnGG6YZ/jtL 8aIqZ+z9oz6tRKHsr6rFZZU+gv0W9DktuE4iyTUQ8pjJR19g9yQO+36wKd6r
4de7ar5y7SecEhVhGqocDlWHux8mYi/DwAnonBy+vCq5NkpLvpuy/TgBy5/f 8R4ACCAA3pCvFxdsgfn2kR9J07P3UIWkTJo9FozrpuvH/7kBcQw2Ybk4b1r4
OqZdG4H8Iq0sV9FYSH/OfFmVIAww/uLmgrTOVusGDIqCM/aHIY024L3yAn2+ dNmNoDMwgmqV2Rt0qHLgeTg6CxgpqcMf0WWMUPkOdDn0rcMtOttMBbYDn4kj
l0dX8YA4U+XFwwMaYylZgtc790jps/TZZ46P+Y9FsfIleVyIrmHTs3Q9zpz4 PzqyqCx1m7Our3tEWhhTQswSRm50Tpl3ZhuGEw+tCK9EiL8bXbrIgrFsLjVh
E3PY7pI8o001XiIBXn5eIhKAqjoJ+mQShf36TId12jlrgfR3h4fPNepkgNyE 03MjOes7xIjbbgEgIXS8qxciU0lLDGpDF2mCuvtCbO1ol2Mg0xS6BWZ3797k
BsXJpOBsW+QLLX6vYaUpErbSMvbhOld8bikALgkVR8nUAW/9Fu/SE3Yih9J2 FuBAXYRFpOEHxex39xDtd/8HlhbJlyE4V/oAak86HEwWxkWjljVaQnAFvuva
j5EuYyeUNx0Zw31X9I3kJzAA4jw6N4mkq9q9WcPRKTJTj8TaLEpeFoDchDcY QECGvyMjByd5J5eNzcIQ/zzdO2cVK0Cgv2OfQCNpNh07zobb0Of17VgG83o9
MGXIjJEdzza9x4Xf6PNmW3ze7S6vI5eXeKXYLnsmSeMAFoiJ+TxcO5wSlGdO XUy2tMvggqNQ99rbXTtg4o69n12zL6zfmLRLn9yeOSUWSU55YXhIBE2hTnTx
mY6Q6fKp2oloKjtO8aJNBXs/esJQeDxE/H/IOLWz4XRt7n5mLHSRvSNYlEXd MHN0Qe7sJeu/jDyhMEmYIoKnOZ8HlK4vRfIkcGj6ejwqHvMknpAisMip4c5v
HCKnyLolE1t+zJsj2/353fHh6fGeUql9j2yK7tZhXGCwt9AIrU6JrCR4DVTw jviXT+jH8MOn3MSPEpy+cS2m5CQnz6l1AbjdZw6b9872MLdVjbOUm+KmzTvk
jH4YnzROs+MFwwB80SmN/0IHDipwvVxuknnkiW4FRbstDDcDQRmDGz79iFpJ cikzpCXQrhXSKjKOzb0XiWkKfRL+JQ8eJACgF+HYcX5AsV38qnLZbEiTViwZ
RJxwISB5Fefl97Jgm2oQGOt3y7kAEuDbsJJfiuqp4AFPD7gbi0r78BsOMmG8 UcXMZhMr0aPAqeeIg7lS/Fk3vaiW1XWYALn5c7oOC0OybJVvTmKxmFnUirZN
l6eRniZKyU7RHpPsXZeqbd/gy6UeGdSqX9Ubkv4c+GJkLOmMddnlMiyJySt1 AYBu92EYhdAKCVUUyluiHpqTJzzWSEAGSt8lIrD1Y2GsDm731RjnLjah8fSy
oY+Nuyi8TzC/wN+GRpMgty0Qlajb+NFcNY6QFxZ3V3ocMqsKBCn76EsABlOg xSYgxijXFvVSuA5APVm881H8YLy9hK1Hg1lSolNQevpdOhNFN5p1rc60nZoP
LjxzMg0pSsRcn4FEdcjmighjGMgvz3/6hpDFX/OoOGU4cuppJ8ViCjDf+hy5 3xX5S4fMTuRt4RhwuXI3nQyalDnSHI04ZxRvJ00FG1gzLpZdFvERe+B2Wddv
/mySvUG7NXd+XnuFZWIUR0CMhWc+jXKnZUdkLi6FQ5N53QXXUYDOeXx37Znv /ykTjJYeRceS3DHKd8TQAFx3vykwTuMviVkc8iHWaxhB/orQX0c/MU3BrwbS
OADtWSqc5k5igD2V3lhJvWHoUQ5JzB6pRr9tn7MHE02A4YAYtJjUi/0bVnLA zsTiiHHwN7vtlpsao1+/vUi9mtnMQbscpBM35BlOm4TLWiBSzXS6ae19INeA
4xWEmTP3OpbcmHtClk/OnIAmM5kPQrIJIYKZSt41YDAGXcN12Qc4nxTlDsZi kzxoI/gpMnZJdt0qUNHR/pNgNiv0a/wCHkKMgGKUHT+PJ36KTIZDEKIMgXWs
gHb6+nMlRUiwmT6qGh7L1Buhqk/UU2UWgEBnnICcbB0oVvAvuSxAVU7g2z4Q WWWMJJJ3S9QdSaXMylUfFAt0UvNNS7JZaKW0QejMGLpG1uobn/yWAsMD0kVs
IlocdmBYQCcX1Y0UTaFZKxXqXteL+knyDGgEae4Jc0OUo2MPoYgCa1iVjkGf qXQHiwSrMRi5wghtX4McLP7bppyhA2Na4L8Hze6rCsypsXCNrAhasSqRBg6F
xSYauJ6vNx70MQQQ1b+my3LinEiEaxsLB+h0WicbWhJIrvAXwBTj83xe7y7Z AnTmoEBPDMiiEuZhVZeLcTP3ee9t3X2YgBHBbx3TUY6AjJHIlqeoLyRaZz7H
6NafMz1Bx2clsr7nbuI72RZv7Scz02WgGaW0lo+G5JXHNygunLTTJ84unsHP TGAO6NBxc8GVF+tNCwpIxaABA0zLGMS0XmAQl9FT3CGOjvnd4kGb8aZZgiE9
Bc7rchuPXX18l/2YPS+88ejLtXcH9FyoGtmTaO505N/zY3ZadOvVM/j+0114 97DwzK3P6sCHqlr7/ETOxt+dkurEJpmDBJCAHZ2y8RI5AMuzGsEIlOpKQCwT
7mgrKR//2ekWLUaAd7J//jN78OnBA/zbv3SPo7asLMpISQg5L1g6W2xsryAy oMylrDpMVy9ZNAy+PT5+8l5dWQa5TqhXnFBy+3ZVuVAWgAZWm9xra83n35EC
VRDuf0NBbFUO31Kx33l9VZhd5h3QWbq5tsddA4SOwjoYGkHgVOSUp2H7IWe2 TC3XAioTR7TbYVqObmuxeiZoJJPabYTSY2zY8lEkRTpj3sp5RRtr3TuPRk7c
4IiPiU/Q1slNUNfHoa3nHgdraSr7AeloS+s4Mw4r/Y/Glf6HcEODcSXjctOg 9SqTrxd+dMnM1K6xqo3yuAXoOoEfMhoPaTsiB9gi8Ej4Gw3pYochfb0d7ciO
AklIKEEBsahD6Hraed128ty2E7jf+gOLLFF8HhHcif46RHd5Vn7Knk8eRi7O JqotVuMeS/g6IBhirkKPUw8XCUW8U/In5P88UtUSFW3HgWZUwcpF3ELODR8i
Hm97pUrW9ZyZglmeefNwfrInR2EFpOyzDG8O4kO+McoQH+G404glv4i+iulX C6OCB7DlkHHp/sAY8Kp4Q3gtCwU6RqaVTUcKunzMx6XY/8Obp8enTw+UXe47
OKpGOFaVJ89PS4wgMt+Hf+bppigV2f5mggdPTnG64vwrzz+XPRgrWlfUGNJz JJh0N3bjHP3JlTqBbR69uG8p+XUusAP4CTIKSHI/ZVCgyIaDgqmsQ6gN+4bQ
GN9lcjeHs/huX2dGLCSFlFJk1Zp6LciDajGvWT8aL3sMqnLKWHnQlPyNakug U8u9oxxkOf32zQdM53dVo1jTdZFtBYYPCjFCqPB96BQoQK/8Ho01TgymSTzX
n8eWmEIIhswuUyl6phhVVCwsR/TzwcJ7Om0lfMVLxusFM7Ea4V7m91PXhlCX 2QPJvFkut8li8mp3Al3e5XCcwa4ddyB0PqCwlBNHiBk4BiuGKBwUkvcRMS2k
ITWbclgMv2NE0ZbsHD7to0YgCFlCkukLAW+spsUBzPNyIRE4Ckkr462aBB6s 7HzlAneKo6UNk+BRZn7fqfQcEq5EeUQs9V/h2kiSOIh3v5euATywQ4/RwiS1
hl8iR1z4Bi0WAbv4h4x3wjAiikTrtxuALaDBOGU6Q6W/szXN5bUXDk4WkQ4o NnVPCcg23KAskt7t75LoBWEfA5ke6nQCk0/Abto8p/QjAogPmqs94pvFFcLB
D1FR5+bOjyRBozMkHLky+cucpHvYzFy1HwXwEwE50GiCTcsGWoSbojyFGMcw vTcpQKZpYUKbk2kmsslIdzTve3QnoT8C+vTzkx+/Rvx1aNVFrRY3tBrHS4Pv
zrenv8Rcfylr3aAwD4WMwFVM51amo/XzQfK6dUoSSLVXtjvwkXjpB9jgIFIX IAT3mCtQMP5pk/IYzNQr1LLNRA9y/FiFt4nvDIWQ5D4bPK57ptpJUeNkDPTe
xQeiKqYOKtu1AcE6BkPot4lBkTeLzQeMVd1RBMKYY5vvDs8xrGHmeEgEHveL 6HWCBi/jXzeek5Cd7YFdRKNEcWoD5T45c7J3dD0NmalGJpwBGaBeJG7U5DIN
L0VE/6gXb8I6xnxeYE7VF87i82gIHHYjEF0MJFthgLLPT/1wcjDZfyDYolBZ eF1uF+eCt77/iqk08AKFqZZO6chTog8f1uFrMKDtTJyHkH5CXxGmU44SnOIg
Xl5cdiEXT9meQVo5JOJA7a6tE0zNTxrurQrGy1LB+lTYvC231TBvHeOEnQKU cTiD/h7OKTn0g1YbwK+eKUApLBL0qvceh2aZNiUkWYqQWplFIFAeB10nOzuK
tqZKOMzBIWAjuBrpCHVQF+tylnPaYSjD6Pu3UMTqJuAAxTvRNNKyygE2gQBb XAtLzshQMR2qS9wTmmDsdmDDQMscRbRkrqH+LVwC/toRkZ3EVVBD00gbhsIo
igc1Ej59Caf3o/14ZjiOndCmjujxRoEkrVWEjAdI9o3sm/jWKN7i2bQGQtuh IsnWTBX5DJE/AL1Xi23UcXvl3yJghIuGl4AGB0tiCEnus128KSDZ3zJXfvCR
AiP9COd+puhIfoPRd3fjnUMUNxrA21zrgVxJ3rpQrUw50m18dWzhUVj1JaXl CWhZmCbOuACOj2LeJgDf+dtmQHmJbSX7/cBdx1NzjVtrELxNF4LmlK4h78kp
wkxs+arA/cnxDZhm+kaM0QQXGvw7IXOlK9dLNcQDda5wiWhohmI8XX4hP48U Vx7YoRh6knYfOZr6Hj4XyLMrjat5/eFN8fviSeWVWp8+v3+92Ay5Owfis56O
vXhYltlvyEOgQ/ROGD4ZaFBVQkZioSNcvqRQTqGmMJIxALv0ePyxrbaU0qEt /Bt/X5xW/Wb9GObidB9eMdrJn8h/e/2iQz/3XvFf/1Xc/Xj3Lv6vf/8B+aa9
7AD+TEow+CFE/QM9zkS0zuxq3m/1VhslontQvCg+y3E82q0/UPB/HML0I5Q6 u8bMobAog/610xLw8iKUL/jnyIudsuIbSsA8ay4rc+i86TxLz9p1PuUAMSTf
NIsu6wVVvxlyHoPzfSnxdefAC0oiSKb8W+xzicZK6WRLRC3awEBq18AytRWp FHp3EFkWeRQGIYqsIV6x48q4WOg0lcZl7T3t1vEQO6JpQnMu9+ica18L9o/9
vu5MS+/yUMAb7ATOvwtTP4U8+7JPqWmpKbziAw8e1oOpZrsv3r3bGzl1l6TD hzrI/gNu710OMusyoI4FlpeQxAM7pAnu+WnvRd6zJ7amzp3Oa6mkK2N7xEwo
Eh+7oTSiRebVPjgsPjC8k92qraa4v0jPbZHbiTsxIr5WCZ+jevYI48i5p199 Yu0YTfxZ/bF4MrkfmWMHLA2U31rXdWYymnn+TePcsme3YbmklMGMCg/biMt3
0F/9qEplclrki90h1XGLx46xqOHdLt76iW901MvNwePPNP/FigB24nlZCVJl bBZMpIdtram6QRWNivlz2D1IwF/dV55UmChdZMaP/8QTTs42sk7MFO+4VMVA
IJenGPZexg7Feu1zyeSBSJawTdKErv/YbEuKcOg1/UPiNotv+LT08IeQ9CKt hPcPvpxw0sh7w7+je9Bo2nPo40X6ezp3+nuf/0dkMpXkohRc606bakQDZ+Fp
cBYt0Bm3ScGdtIXiFnM/giLzLMAm44UNJyUHEVWeO+nJxPxIosYRV19+KgIr /ANjkKNTTjQAMcojVWUD7VLW0BRPkdPwTCqvhlbwLXu8m+jzLEkCXcXih+OF
Zig0sSxY4g4zRRr/oiTaU3I5boa/M4BLULcMoUFIDbuug/WhQoAclYemU3G/ E628r9ZkufH7qRRQSGuRjFq5SfLvGJGfqDiDoX0I2n/f8v70CZrXpjtjB+Zl
dTf5EK3mxepl2RHPaS38TKopSOpgLLuxy7Anh7z4KegGfL5nLpDamNokXaJF vRBXIjnZlaxY9QWP4MORyP0XxqC5NqA6f1/wecgjxGiD/XoNxgfkGQeMZ3gL
lllf4ZGJL479CnyctLcpmZ1j2ECz8Dh/iOeVpOducBVc3+aTQIv2jMD6Oylj 7O0O6gVZht2TZaTby+N11FS6faPs6qCLJdzJsgDLkoAhedN33X0Q/FOEbEGt
oKCxuu6G/Dm8lOmtkjC2lIze4sMhOYOpZRNT/hrJUhXlRnpbU/zaGYjCTbYH Co4va3ARloxCMKJBQ09fn/4c0zWmxIPZDZ1zeIFFmc6vTEjnZ4T27M5JSSDo
Fde/4Us1ohJgpp6ToK2p55DlQM/4XVdlvVBWoHAfxfVcYoCaavx4kdkdHHJ0 XvDuwSDx0Xdw0GFbnVfviGmaSmZdJxcI57IjLnDTdqjKdrF9h562W2+F0PNY
PAGRnEiyQHfycruBWlqckyWxVHVmlnDsHgrhp8fMAsxQyIvOhFIWw+723NGD NbxNS5YKzlwYyebHs+PTO9GYylPgdeW8wmiyT2/GFqkb7DokiGGMsFujo3VI
McVf6clwvjG7myvhz96wK/G2/dhaNkI5uIc9pH06wAMFDvOYI3jWiP/GxYTp NH5/cm9yeFdgV4EHoD6/6AMmgaJZWc5AZFBBia81MEz6VOq2XlWMLyZ6ganQ
Q0IbiX8Yvd/B0eOCoRlUYYiQ9+8eZd8ejM9LsHXXlfQUUrotIb3PteTtfL5u slvCsjwpIWOsnWK3rokDsWeEndlmE6tzJCSVnW/qWckRlVwg1VfjoRddD6Ag
KfH3AXPCRfcBvLezSfay/FhgGnYU6Em4YhTHxdqFvsBt/4KtsAVYubdCtMhs vy2qTpqvmiGACKiuuFsjKY4gwYFcJAPvEccOKjrkEfthoL/rFDrkMaRDlfw6
C3CJzdhHUMIhnaMJIWfAbzLNXClqyK5PPIOyhqA82DiKfThfmcR0gALA+Co9 Jj1y2nietIyfPqSwpKNw7g/kXrkObDb6AmV/RF7uG/TkXSZ5NhhUdi4kg0tE
EBKHOi2m+AzfmBCJ34KDRFX9ziBI3wr08pQQpKC6FXRKluhwPKQ1wCDVJ3Kb 2Pzc8BGyCkj+4ecUfgzzsXNsgdWVfSMw3TRS9PAE0xvsQqHppSc3S9XYAyky
SXN6yjU3aKhM/PEthQAfs35X0b51QSUckkELwCf2YvE1Wwwtw/Ek7HOKObUF v9ipN4c8RH15Lp9H8l8sM8vdmDcn6Ia9FdpRuhqkl3DJWLoKTgpTyKuqMTag
qdKTKgJ2ef8W8Q0mFol0CXxKh4All0b1Mb1wIOCuFdrNAJFkFS4tkTFbflXO kAGo+tSGsc1llVysHaQO/roaZDIEf/v31KBNarCreqfTH1s/E/0Gtxo5mtkt
1mCV2qwg9X6kTomDrUsz6SSIk1w2xrtbtyPeYqkKHWBZQISajN60l+TPaM13 SIf3e4pnjEPcYYQ7EPWmi2ZBuYWGZcmgop9LwMA5MJoSH5TJsxc1Xjy6kpja
yDTpVwmwTSnnxev17ZOCAxX5M3Vj3+e3ZAUzCfL5bIMwHYawCmZdT4zg9Cqz EdeOFqeQzEBQXm3Gr8/p08TGMqRIByWCIQdShYG8qLlTQMF4ydm85LsQmhvA
BRzDaEhq5Bw9kcCxjpXQc7BZRZ+C30lRCXTIzhtQs5ghp0iUPg07T/Aewkan eov9n968ORg5ta2kgBbfyjOfZNIh624OOxffI95K71ShUzBjJPp27uCJe2a2
YjG6v+xgS+Vv9if72E3u8mDnr7TXfyvO370/AnmYlXm4qc3+snNdnDfdFC+e +0Z3+xyltsdkW/cAffNOv/m9SpnJaVUu9jNvuMnQR3dW/uSzkf/MF7K6NrTH
juW//+pj6D7rn8/SeCrisBEpgDPLTFe4WF3d4dJjBYwifIQXFN9nDnbhQ8Lp IgFO9Fm9ytC1SqAwo8uoAO0vNj5yTmaKBEG7JAqaSQIsdkRAszi0wbVxk0qY
sETzYRLIEubGlLqAgRURe+MmXCKRCFqTVJrn4Tpxd51A4qFLJUkCrL6Jxowt v0I95CNE8pgbN1qf91wGB0/TTmpjDGUJsM6zQJtAHhb5lthPlN/vpOoWE12J
EKN8wJC6vN/GVJ/BZrGi4rMSMqNq93oPHwzeswF2VY/v9uetsky+VEz+4G1O UMdMhPpjFThQQ4aOJTUT25lZ7/iLmkhuyTK5PmGA0WwCU2bsEGKJ2M7N5t9q
uQv3tai4rxnFoS/I5BzOdOgZIDSl6DnKKjwfYSARaa53H4xgMOPs+Z7g6M0O WMam3w4n407nrjM1Og30Ncu6x1c3wrSlAoM2HnRmPzYrDuTmF2sGTYVPX5kH
dAfbXz8rZzTtWtCxfRC7RMUKdpECL4IxPvUNXcncrEzTzD0e4cvs99mT/sh8 JKeoMeGcaJ1l2td4g9J7I9sDm5MKRjWzoexS3Sxc0N/r5UoCjtcYFC6jD6pr
6LlsY/1/62RU2UuGAAp36ZAvGO0bZdT1EJeoZgoW6CVIzUtiLrpMuT9vLteS RouDYGKjZH+Q91nNfMMAHl7L4Y7EHy7JuDdYe8iEYbIERdW/Qn5cBfuRCFcg
tnJaiyG5TBJ7MIrmeUMLgI9/nf2YfbsPq7S7i2u1v5f9P2AgMWMuztLrgbXj gxaAIieVLTXGmYX4UvXBBCCuD8x1DZWWsnT3Bb/rsm4WSu4UfkceQZeopob2
Clva5ekcbRuWct553kC49tsDIajmIjnvjzPfn/cGhZjXagbZn7xtNWxNB6lo IF5oNhvzxpBnkpLrSRbpVhZxn81TxnlZEutYb2YK++9BH36KzEzALIVQ60yY
hL5FqVs6r2xzZ9QyaCZK3N3hugQnNZgkvusxBeHJ+/bH2NjSaLdx9x5HADnN hNGHb68gvSdT+JneEWdbc8yZduD9KzY2XncfOss0Kfd43oY6pPs8EA8xoT1C
LoB1TsA7o5eHsyjBxhv78CmjN7QEsCnABhAwL8eWE/oBigbIaJOvCJ9MfZLO i80x2LqYOX+3uM/035/lqMGgfwapGNztw1+Pim/ujc9qUII3KykgpfRpUuVA
WU6QiIjyuZh3ZqrCjHs4h3VHq+t5CJST9XjoA+Vgdd0QRXfusBf577EpReYt aeybs/mmoxDiOww0V/07sPDgXD2vP1QYCR8FThjOyMV+sZyhEbjdI9gJzIC1
UTCzN8/PsSmfHoofD2TJDJXd1sSQwfrbg96gQbERLTZ9heNKCYC9DakTOADo ey0smkxuAY/EWARzTHLSR+NLzmD/ZKI5D9ewnD/z1NnqtPLB1MhT4nxaF/M8
MlAQJAmLV5FIWdTGdgRfpYZQ7EVwzEa/1BrN+LR+5XxvOIT/Tm3tkAOQaOHZ CsTki6RBiEXqtJj0PXxjwiJ/AxYUhfYbA6V9LfDTU4LSghBX9C2ppru8J52B
lqr61BuOq+oJbiSN5vjIszjvBeIvH3sV4c6s58++zllvInwx/MBE9CZq+GMH QalckR+a2Kkn0cuL74m/zSVt4kMxrCOb88A/W2lILsC8AmHRLVKXhFBQobc2
WBHsJzPc9GtI+Qn+WBUJRPNOqzfXcedeD3aMzIaN+TgaGHk7Sc8h5X7ewSqT tVdqkEU4Nm8BI27CODCRmoLv7ODl5OSyIb4ZbgY8usKpGkCiLMtpxEcUer+s
WfGhQMpAdXTsiwbW9N9nS4jX1tm17QUKvnYhnfcqo4XUcA/d3PYCaX5i2l5H ZxvQUW2ckWp9UmXMbK3aQipH4ixjEXFv921gRuiUpZI0S2aBkDzpvykoygPp
KQXIpRKr41As+fCkJQ/uh2DuwHOOClDLA6hWcnCEn+9FI7rrl/cbOhkfnsBY zEhkonRcguTTkgNiE/uSWcGsiqycprXv8+dyBXMJm/TxFlFIDOQVQL8HnniD
zsSqRkOpJQp9a/P4p1EUiEsJWokj0QrNOAc+BEFMDDNUm4jdZpa3AoUl73XP WHlE4EZG1VId7midBIZ9TDCfgxYrYhUBNSUllJbFWQvSFhmXyGWlrWElEuG+
Mo0A00febw2TC7EzzkbMqxH7nmB/V7gCKxKgS6QlDyGmh5P9GMXl6Q/6h4GS e/76pWiQ7s97WF3668PJIdYPvLi39xc68L9WZ2/ensCOmNVl+FFX/Hnvqjpr
YKXZn54Yxmwrt2oWm3phkv243GabJXdi7s0H0kVSwxr51+nYNV3M1mlaxBMj +yk+PB3Lf//Fu96dOvjLWeqCRUw6IhBwZplnDJerb3pcfEwZUuyQEL7i+8wd
3HrFQrIMBDi5E9JVMl0sUdRPUD/jayGsA0jioaf5abkJ3uk5+ekY19lWSDLm LyxUOB22zECYBNKMuRSpLmCgusRyyAPulmgbWiVVCibiSnFVpcCXoosl0QVM
BTfgNEw78bCJbGmSlj4ilO7cgyQ9Yob7xeaLIcibmQlKKUh6wbes8NZgyuzA WIp6jWUvo0BCTmre6WIW16DA2M3iwxkyp14TDrY/gn1y5LmKdfdXr9KHvtAs
tvdqo9LSA3AOpw95IvEEM6WHftY8/uKuIGLCK23HWYSNe/sSjKQlHqeqBoU5 hezPnPJRHmp+dk5EirFfkRaaD5PodSAktGhQylo8GaHXEfnM9++OoDvj4smB
lA4TD3AbzW6KdeAJ4mS/9c0jcncx5+RgMiwrTKuMKewJcUK81/yiPtKTV1tS pBWYc+juXdeBWT2jydesl93d2CeuXVCTFNQRdPSpL+VbcF5oKJd6wH18Ufy2
dw60iIkMcuSL7BhuR24bPk0SRwSERPtgWoSQLyER/I2T7F0RZjEaAZFiM5hJ eDTsm/dW1118Fdw4HaviBSMdhZs2ZyVG50d5kz2AJko0g0V6DnvnObFGXaTE
y17T7UF5RTiQx5fl3+DXtD962HEFumzNNiftIUMyCTQGZfVjupibhC5V1gxg rjdluUlRQc1RkZAobX/QkeZlS4uAL3hZ/L745hBWan//Ofz/w4PifwF9iTk2
ShIXUXmGN7dSHT7JYjIJWw6E/BDagdCavfgosvWDb8Fg5NtwOqLb7bO8rS54 cZ5eZtaP85XpvKeztLtjyj7oKRzh6W/uCR05Zxh6a52pF72lKOzLVkrISeUD
NGkWET8+3rWoTXyn6PQgvmt0+iYzQUthI/uifzL9jQqDbjcT/Ak8cnFxrU7k rJ5uuldFOuSUTD3e5coW90aZg5qjuOsdrk4wYYOW4qtek++ebHN/rY0tbXoX
DcjZgSx3v4kLMxyYR3P8Mz79EbTa9ieSPVXcRfB7ATvQNSAOlG0KUb64xkUj 13ZyhMnToASo7IT3M1J6VwgmKH5j72plfIjmULYVaAWCYsaqYANaB/IWSH+T
YQygjanZ4is7at1MO1k6BhAemal7UV3NylbL3HoGAIZNF+Wdab3uwkiYTIEw cYRBU7WsM94tyP5EYWEMYjNxZMFVvMPqoyr2JDjXSaU89s51UMWu8bw7dzwI
PnORD/l60SHlmBEwzryk2ZGeAA76Cy6UCAp1NOIdEUxkq42IlMwnDfvDxSll FwxorCKdl7i22dbndmy0KJPUgFe0hJXq/pqokkl+sJe/wZ5iOWIs/QtXmDI9
dmRyi3+CjQNbqsuRgxlU9rL8h3SORGP0+yf7jwU/SAsQp5dQbbhEcPRDg+Qo e+VSJzEDHDMYEyRrUyPfkIuq8u2IR4yKhrF5YVvWNdaxW92a8CtDV+awewSH
Zitq/tofl5AE0KAE14cClLayIWV5MwlExADnmP/hnDnUNN+MKPu002mv/24s T5XyEEfQHLMd7AWp8RyzFxDISRCxfCla0PsC0Z8PvfBw762jQBAIg4nxpAPp
SZ6ydCciSeR26hgIQjSbFiwKwblEgTykLHR6C5TfEUY1hQbA/rrAEjiJGafF xNT9cOLyg81wT9ghM+71S2ozEPRyVcUYy1utZmq/i/auwrJnnDqc24dxJvUO
pa1shsUm1E/L8/SYOPE1fEyCOJSMoy5WpNgpxRDm1NgObohDMWyv+K2hBlpa M0k5wPcwK2dWvauQ2VENpHQXJUv8j5NUxEvt7FIPXAxfuq7OW6PRuqqziH7c
UkgJ9PY3Ma8qJlVoI52DaU51lnSOlAgHXy3qDT4kaaA9NS8ieyTkXHkwLoSG DVxxfmK6YRkyj9NLt7D2RPH1+WlLms45cG5Be/+7fxmPiz+382k1+0vxLDGg
GR/hO2Treb51TFo+jQshdZgdsXpjxs1noMzzy3kQE5pa5uRjW9A9f31KjZts KGLNHDEkQ/Yy22LPF/J0dI7+FRdhi8wzKBSvKiXyD4rDvzp3wtTCRy7eiXKC
l4mKOnlRgZ920YtRwwjsK6fcVbhyydipvOXaDHmijKQDa0X9BYqce/0o1eac bt5+tPM4fTK10PNbjxwYF+W6+5JXahmSwYtdzjWwY88X4/EPfB1pfgrl9eJP
4mpgbGFLsNBZFyaZKTIoZQ7SPPjEKUExNpypwCmc0nl4BQ+pGZsixEQtJy9s 0r2AKVd26W+7yYbF1oybhbB2zjgVR7mAIIUqxKJBzc646jiPpRNnH83XjKEM
r2EKdXqFBgoOtPxsA1uos5uOnhntD27PZjFE9oEE1JjW9UfT184nZKiDDRzr 2c08UJnpEkMIP1MdVng2y0F1O1Ogc9jsnc7wFRFr6WzE/DGxhwAspBVu9zUt
C/ulIxcMu8GPFMOnLQZvt/wCnRQBeSmPpoP0SWVaeItysFTIqWoxisMrDG3Y 6gXWAwjewPuTwxim5/k9che0ssENInfvB2c/5hW6UbrbkBmfjTQDbJeu/cz8
E8VrNKlC+3FzN/JeTePfeNhJiXw4Z9wdzhnei6S4yBAzakrOal+nbNHcpU+g uswF+zT3OvKGDEYQwkpkQ6S5ZTGYcZjHpktCmKJboZ0lWsl7jOqB6mC+HMac
3FVVWRgEPoE2l7zBKCF5KjFxcag5muidlF03NyvsOFwsbkt8VfyUSQaWqRwv wZPn2vPTcz2y1xfHIDVL512h6Rjh3YKBN+3FK0JMY5M0YRexk2ceGeuBUVzZ
ya+cZiPBi1z7kuvc2zDKmxGQH1GzvoGmhJwUplSFT7pgfTGsX9txLCNW1LV/ uVxk8Y3vzXygoiQRIl9AxivtKX8Jm0nrrW6dAXC3z8eBZTYpzSiky/qp8+ia
iyI0sELrkrKAFda+SacYe74cagJUmAWiyXbb73sWcIfohKSNKjOtP3DBeiex 2+PJCZu2G0UTzvNtVmIktSw57pjf3Sb7naizu2iaUygLTxSjOKxbJSqLIJq3
9bZjG6CLvrsM7r6LJl9dmnZ7ouEvhyQsmIM+ReNfR4sT6m/g7KREPQg6mluJ qAiGYYiZyBGVMCH6k7caLtYmPeu7LYfAXjKxZ2BD+XRQhliSrY2tSRCQ4K+o
DeusDcvW/2HfDscbuLyWWlgIE05kaAvIcJsTwHWw8EDtyrM1/ubx825byrLk uE2r4LQniIn/4aR4U4WZjHpAXPIMWtOc7fSkUJgYVKPxRf1X+JqOyiCZQIFM
wr+b+lro5qBlIUwckXqwfWWIcAbNLBoFfy2+ehRHxMa9Ai14eznfBEGfIkZs 18AHkvquITAIIoSgGjFV0vXbL5XkDFVLQ1Bx3o7XhlMRPyliuhSbNob8J1pC
zs/3rNkIVslucWi4ALeiG0wB1TZ70HHiGFawqVcN1+aLFzfOUoeMAoJtEBcz 1Nol2BSZZ8EcZED6TXAsEfu2LW9aCf5QKrjEzQ8051DiPb2tbxtluE6X0PTt
yL65KpFFtTrhRRy4ODJf5rXorACpw9Wr6oGHc6KTp0iXOIIceHq8GwbkPLtd SNcbXlp/pZyxm3UJf0WPXJwQzmfkJtD0ELwwrLDEfB2mcXZixwoCApa74VSy
ujjsNYHxMeYApHf+A8ru8+f/AGP/u/2DR5asRdrETOsGtgd+j3Yu5TxrsHto ewFPE3wvGBZ6BjYERQ6DqzZOflJnJoOnY4bC+Mmeqq7TiZaqG4RFZ6JrFFyz
t4IjFiwv9IA+cQLfBDK/5zAm0sh8++TxdxL5+fz5txeH73/7eXzy9k8PQTSd muvR5iwD9H0v6lvz292GnTO1w5gqnbO/yLMY3VqO+THjGFpqwA22YFabdSHf
zC8l+6S3KrEtk7VxbvoWcZ3+ydurh2Ekk5h+p0AQ0lRQzgiFRGdNkps3iJkT VjjXEd2KSDGbhkbsfD4APOwuTilziZMe/SMcHThUfYm05SC6l/XfylCf9btH
bIhWbHGvMJ5zcvfIkjRuCm4d34ksQKvhnsRnt2eLVxx2tYJONJsQeVX0Yg61 hw8FK0oLEAcKUXS4ZOPoQMPOUVBeVMF52C9huqBOCYATN1BaZEraX103e6uE
cdgTHb/EXvROnmg1ohizFkveuuCJ+ba1iZ/erybXSjuyshhWzLjJVpiUtYbb DtExmckZEwoqhgBzLdKCxYNS2vFu8pS+exFp6B71Cn14NqdVqgOIA8+wcOlK
tyvqOyPvyY6KBgOPJF5N6SXhwBS94OaoaJS2wwxHKf172SrMy08GnpqoUAKi Bb78CJWcAj7gjJ1jhiR+msnW7uRALLYh31/a0wvjWa9hGeYDzdpPWGeOxDvF
iigkcUp4GTBgERm9amGALSaEMHwaoB+OwM2m5KMBuYuWq95ijoLiEHtDO9/S isyc+gvQ5dhEwwmLX4r8jQG8g40P+x6R4DSL2fCRgKuQ4jCS739Nd6WgAwbZ
FEQdmhLDxBQx3tT90zaOz5RUhCRFFCi2h2MhKhFYhvsckX6V3ZJ8IOiOJG6w JCOTS7Z1KB2DXPUFPzLl7axrVj3CjkOVOiAKz8uuCIEDBtSAzVFSxR5VHKCv
/0Td8P743avTH5H/6+GTJ3RAUFIoo2Z/VLIjOjfIKw+EkAbiUsDk1d24LfCs LttX5RDAtiULGGvvUYpCiFOG9tFPjOV6/D5kezk8YK5qP8B4cM5rDwEhhsh5
JjSKIXt8+fxFtsjBiac1dYN0ZQeTbzkLhOro0eMnDygRhsc98TOyKMkj/T45 fXHUFnK+YAXPQCGBQ8EegMrVbkdsp2G3mYRM8arsxg8j4HrUOFmxpGe0hEYu
Ly5K8tWKoI6zw9OjkxMcDZmWcC/KLb+eOU87QpNl332bUVPe1piLkezHS0Qj i7RM5Y4mBt+9t1feRCmKM3uVapNUJdcfU9LdOXmDQe+sZmZt0EPPPDeE/4DD
8MsiiG0u0oHvc/QCzfWLMUbgGny7DAk2L/xsF1sUZvcf3M8EGpndf3J/D7+i nG1xSuiiLUfbcENOSSm4hEYwL+rZSunGOg7A2cRxct96mQ4yHi662RYkSG9l
bN3Og087+J87D/57R45VaWNS41kr2JkNnzijaJbpJe4S3OMZuJNLbCZ5wwtH DrUZiQeuH2mxcbZBQh5Nm+aDqb7pw4pUCAt0m4Ud6cgFHTc7SNlSXZX9uaUD
2f3c/GB+nw3x+4f3nf/hT/f3tJsohbqjxU87Zsba2al2XpTws3zRivl0wj0q 6SUTzp/PaDpInK6CbNTghmVKTyWrkZteXmrdr8iJqEFBkkfb23F5Kybl2vte
MaNFhj6s/E/cruwoqAbTdO3wz+R0W0DpAlySStM7eWZz0aQouf2Zs6qm0w6W SCTCVetucdWytCC5TdqokdKirsxcJDBZGa99APC2ktpierAFfJu+wVR8kVaJ
pvFjjCNLIgckOeeFWHhTPQlgxHEphyhItNSEAyz0pOR+ZXWq9TRLS0UQmoKw Y49DJNFE76Vk26VZYcchDrHg4qfiViYFqOdyuyZfOY2pg2G98ZQEpVfjlOYm
ugT2j6IMHJ9hPofDVN3sIi3KJZ4MOAmDbTHQyG/BifEBvIQxh7VIHDHVOpDY wJiiYqKZqqkMbqAgmw8YYu69l/XpRdX4tyjcCBMULyiOvcIEUKkzZa+oYw3j
g5G4HkZzCE7acdDpb57dKsT67XdQRNTRVsNGfotN7NmYify6URjrh84JDcyw CxVHNNlu9+8eBzwtWmNpOd1C021cMGFo23r1uQuQXC/J8fSdt+X6wtQCFZl4
hVnrGGjHEPemw3KRRuE4Hn6Wul7oSkj5n8NtkwTcLigpVs1Y86InuhHZQUwV kdthQSP2wUX/OlqckHoGVzEBTmCjo8aZqPHOqvFsAh0PjRH8AWeeU+EbobCK
h74OuZEmOWKzSGi1zNBQRHpr2tR81msQNqfNlc7rusOep6vEvg3c92TcZad/ bA3Bzu6yhDgxHBr01fN2eSl9jojbFXIXgpnrCuHo4aBlIZgnsYSwemkYrLJa
OnpGqZFyWrxCx4xRXmDbwaPHJ6/HcJG17mgwLD8UfrrMtWghDB7vJNoYmA04 JvWCR7uS8t7BXTgepCbCy+v5NuzzKSIe59y8Z9FH1FVxo1HH6egr+olJHtyl
RrvCTC3vKZy+KOiWfkeCHHHsuJ4juL8Iy+CbUMmS1qEG7rqpkdfcWEjaA1Bj DztGPsASts26ZeIKsWXHRWqWkse0C/vFdHOosuttL1o3vIidOCdmbF6MzirY
B9LqQVZggzaAPHfiAr9dG+uMeJsKepjmPG9NMMtpMCs9svEdtkivnBdEq0q2 drh8qybTOEfpeZJ0jSPkjGe9vKZDzvNV5lanRNVpzN5Z7wQJmNFPn/4Fuboe
0BRbFcKGwHZtrMwC8bl3dRlHpK4ZmuYuiRm1fonfnv4ieEguN1lI9CefI2AZ 3HuAFnG0NVCqtHA+cDxaWpkhApG2ROWBg3KIVuBHRqAYH+937OFFuqdvHj38
w6aUTFbLt84wh7ZEPDZ/J+8RKqKnegBsT8Qn5YaVT4XhS65JEdgtytT79y/b Vrxgnz79+tPx21//MH72+o/3YW86mV+KUUv1Z6JeJ3XjzBQ9YxKLZ68v74ee
PflWb8whg2FML+eIsTAQHIbaOmEshLvMb0N5gu9Pbaww7c8g8ZzxNF8x2R59 TGKarArxdFOB7yO0Fw3WOqpBkt9oTkBOmqXI5QZ51snoJXXXGGt4enwxw5A1
nJTIIxsDPiqQCoWyKhRHyaqtUeEZ8Ck5yNSIhmvJJKTuxZnYIbGSRu2klDNS AL9JfBf2egkaq1mvIBbNOUQeIn2YHY/sDUbzN86sDKauCDaiB7RKS9m5YI/6
6whZGrKfpaORzxUoEoxNxNZqIooYhYMl2C8k6bmp+jYVWfkVWKm53SEq9CFY 0tqJt2LIrKDZpaRoMVieccCdcKorl4GvdjY0x96SKhV1Bpok1lypNwPWQn3O
FhenRSydd+7+2IejpB79qTiWtl7bUMxr9eWG3Fl7ua1Zt3eEDMi27obc+1lb xZtRL+3yXGRpLYi6U8Sinwy8OFGoBHAgMcPilPAyoNsm0nu95l0pVRJfCOiN
KOJgvWEttHyfCjgXW3FK/PPi0BeTNzEoBB52iQMgXApGwnFWxRnCkpXEXEjt wDheW/PtgARfy/VgMUdBdIjKocW52cd4o2hLFBaTzXtdseLCNKJmH28fkaxY
Adv6IFOPJ/5cYnPozctiMw7162yrR73qRLt9LBCXAIK2WnvuEgIb/HL8Kn5N dJJ3Vo3ASTz+aNWs7Enli0IPqpL8Pbr/6BHdFhRHKwiKS9lpIn/DzuW3E1xG
wq+77VWhEO3l748Eji3hsyPnMfC8RIRmKD6tctuiN/A7ECCCGfxJfH0dglR9 7AuYxqYfdxVe3ASsMjyuz5/8VCzKs2pBq+uyZIP3Jt9w2AxF04OHj+5S/BDv
SKRlG2TFBurJj9eK5et+3S3jleGB+RRPMDlgTacBDuv5XN4A1qEfqx1Gfmks fiJe5U0lTfoTc1ad12RaVkE0F8enJ8+eYW9Iz4Tf4g7m1zOtcU8QyeLbbwoq
NHDoK2j/DlvHA3xo86T92DW8MgUbnKG1lKGQMimuWvDVsd4MUUqs7VsX4+5z H94Z3TE6BfG6UA/8WgiagTPRYHyOXqDwFNHMCCeGb5cuwTGGz/a53umdu3cK
RANIz+VSeukSVbtWkXLzjXywB+HJkKF11+w4+zb956K7MpBI2J4tN5AtF6O6 gfwWdx7dOcBhgAG/d/fjHv7n3t1/35NbVgodNUvY04IC2/L1M4qmmd7iLsCc
SMN/ZWo8U4JeJ7FBCmKE9BK7bwnyNYYZtGJwuDQJ40uBBr4PpvNNKCcWFRwB n1XTeokFaq97I3xQmg/md1gvv3N8x/kPf7xzoDWKKQgQLX9ahjeW1U5l9aKG
7aTUpS2pIYwpPq5MfaIRHTLVhXe95cybodhPezpijo3QXFPQJFFlrUONlxKJ z8pFJ9rUMy57izuO9P4GC1rTnJ4EMWHqNx7/iYx1i5RegIWy0ghYWVi8BAlN
ispqQw7UFEdyvBxPNwbYmNNte8/xqApRajveFSRbEUGh1G7jDqjQ3ucqhws0 rqTorNjptSSuqSMbwyJTVwfunbNKFL6p3grQ4zhdSYQlKm5CMRhK3HLRwyaV
MxvpwI4+kjHDoq6dbocNih2VCab81mqZNDM+YkBRuyqFDtqeiuLNgnSvWmVf gBrepjQfDc5YuQInSLEBjm80H+Fiun62mBb1Em8JnIRsvRzU+TuwabxLMyGX
UstJInoxv3TrhNJvsZES8qiguvd2bEslI+cDy3kWE+kGTJqj0WkSJzqE/MFE YuER+5A10yk2aLwnsl4SSrpnF9xfPRlciH/YcZDbxdFhw5qgi21s6JiJ/LJe
Hvs25KCiwLABA1THMDYxrij56WMUMWerzwnf6XW0iNyKXlqR98M1PWHAST2N GF2I7gx16LDG2Wgf6MgQh67DhCjvB/JIytQSQ8tCMl0dnpvE/XhOAcPVjAUu
Pjkb+mTHeVQZALlRgUBsmXF3H7ixwHxPf1on7qY5aJNJkEijTYJJ1tiRHS4R GqZb2TsIDWRP4DFX5SW7bBZtWs2oTT0/+P5I3jcb2G5Oy7GdNU2PRZTXib4b
XvQaLio8w3AuBvqvU1ov+jRhA+boLhjQsgY+P9N/MQJk1xgXaQnk0DD3f8MB KmGQslec/vHkMQWM6mn1Ai01hisyHuNPf/rToVX1qC+8fYiJ7aLUfJzQd+jS
RudRryyYsgnw8MMeGbRHsVE6bhs4OZAffiQTB4+hwNizDdL7GCtXJzEZxwzr mNiUYDLgRu0rM7N8pHD2IifhcBgJvMmxIXuGmStVTElp17QJuZ5XbYMFDYy6
g6tpJ7YOemkYr6W8i/GwBBUo7pE8FUPNMTaCO1GxMsPTOoSQxwsY7MJ/qQJ5 pJVE1ZcgNWBkCbaoEEi7EypCzB3qYqERn1PBxNOUl51xbjl1bqVXNb7DJqPW
lY1XmnXK6TebfM0nIJ6EVbyMGN6MLd2FOsu4iRQZHfC01YKWlKgYLloV1MPx 84r4kUkxmmLBUzgRWOqRpVmoduBNX3ZnqqmGmrpLfEidX+HXpz8LtpdzqRbi
sc6iOKP2DiaDHINDmT1JYd2kXh89fomJiEuKENAQxnbZtgIEVb3aTAA8qTR3 DSrnCMNH929C6omBxSXmGfA4+ZAQfwRlumD9Mr4styx9VujQ5YQrgZHjlnr7
N1Rp1dWrelFfgAmDAVNVPihIqwVCaq7hBKgXuK5ah9QaLEaSZao9vh5rSsaB 9nl3IGP1mh0ypCZuVqL8NNyhPoVUKD/hV+bbkHjjy94blUyLtZREazWelmvm
ImTinhcrMbrqOI9ZLyQjdRYTZJ1lvqud4mW4087wq8H8LBgsnjyH+qWfEVUo pqSxCTcEspEEHymJdp80iPtRIo0bFHgGR032MtWo4mxJ8Yb7/Ux0qpglpupR
tyoeyfx7uORd+wSz34COdkccoH0EPmK51O3i1j4pVcpdhlkqzdBtw+wVZJGb SrKq2bK8GYo/SKkzHzlR5Bari52VRORAMrQdXoOhjV5GJAcm47C8BJ21tEdE
38Je6oiUNuQVksniIxVErCip8iPiITjjwqPbxmfTp5rJ3A59zU7LJcxLQ0Df d33wnsXplxG77q1rx+bQR6mVfyqmpiUoMLUkNM94SwaufdySNNhfhJjQruKo
dIzxHLmbR5fdMjpe5MEOxjcAc3HeiLDCD0qxe7ALWkY5yz5gf1f2s0LcBgil XE5eK7Bid72ijQ4d9XKhhrVelJtuyAXKGl/1sYIrFDYxpvsjw5kAaS6wL4Tl
fMAxZN8T6yO6S+gfMpAZM5JtK+a+ak7+hRUbebIlDiQli9BekitGBpkjg4xG QT85TrHYSZialWgPqXpgq58UagxN4D/REDwqjos936W9IT8pOoa576uQB0zC
NoPNysdscHGEp4bdh+ExJsmo5CLsucjFgpXFsXztCt/eSIZ0MCcgDc+HaTDn ET0LH9eyZ2AfgjJ+HFAU8AtO0fIctUzWCzPAO0myBbBLYXoJzGGIMDpum8ra
+QNdwFZUGKMlWGp/g5rGrBTn4o8a/8SbURT253uD6sa5X1fEqIUTK2b/3Rwt ojgcvAMNtNCEZUemO3LVsGjCGjuagd9dkL1uWuXOQDNwrVhVsaQi1xgrXVLI
OufoSIrpzbeqbUPoKLkFqn/2pbXgV2MG0xmKc0XCciQSD3g/5a0F7Vjgbrpn jZHkZscQG8xga0WcF2zpREVB5Y74UGHP4byuN54CiSbg56cv4tckJOO7XhVy
bJk8ubeYBWA0J0K1rE9OVChkX9Phi6Qo5nPutxG8zNQoSHcstFk4Mh8TWvql VZ//9kSBmuyUPHE+M4anl+AysHylLZoemGEIccPVTkgKPNdfS06YuK92I6Ns
XSwKrTQiPwTOvxknYENQWrt+kqW1wI7mJRq3lhXEQPTw4DTldwWY1jMp+TpC AISmWxkOroZp+py/AE2WU1QERFMxdVnYXepDxDkwzfuhFzyPOVQvc6g2ouk8
9nDpd262go+Oca4An2+YEZEwBKtLuE15CPhR9chMTWVK8lchrdZNL0fSwI7k t5BBHk1GUsgNIJ3quZqCRcPQetrwkkzJGU3+EHmdTtn2dktBjGnMEW5CMoFx
039XS3X+R/zhFARLHuxNbXuTlhYiJZxfTa7UYYi1KcIw+U0fhYPZP8Xg/Voc VOiZoHIWmnDO1YvKbMXXZzmt9bbgCzYVh+2i8ZcJ0uwGY1hMfYwipOvyC5EX
VJItDVQv6inlHFsxfFgRE5UKOQRiaLut0wZqdko8WVtD8hG+FF7rCC+mskCR nkzdiduVvEMhdMfWcAJ1j1EsnShvLg1w+WTBzPhgOl8F9gEROBG4U9Lguprq
IF4pwyfpsa6+p6vmXGL5zF0yg8qq2yOznGS/Vgt0FQW3G+LjA+wuVFPmgxG4 ahmugtWOag7vyfKRchQdxzVNIZK0gC5GMAk6OAWJEnFROLwvUgpjEfldiIGb
ZRpt1B0wfilbMKlGza1wiIm/Sxw6Hzqi/uXCQVVfabBtq/CPLIIByydYBG5W LGqORsSQd8RaVksRgnvcMm9CZjgWfb/S72DC9tcLuDQWB8qdoSh5AxBRdKal
rIbCJVCAReMg/FKpUpuktGxLoLgNjum+4/prEjXxkcNYI2U3tPExkT1b8xxW HniNyIyKoqugBFHeJm1m7ytyJW5x9kW/EljjkTthPs/FdmycalHA1btCYg7l
VW7WAr9EkSgIz3O0fQIvvD+fUbsbr4W1di/+Dl9kbVB8TXmFz0Pvpf34zvUY icHZ+0aKYSPdDa14ADsD34yG9ekTbyJTpWRcl6syKVUiqXJvKjqSEXmsMGTg
Yf2LEnidMoBO+7053u0m76UmHu2N/Tpua9VxAzOooR19A57Bv0g76ulHB6dM +1doc3LC2DnaOmSKiqfSWAJRcWm3xzrtnh4lLhohEn4I5mCgX7euhcPf6mXi
2EeHykVt4/fBBqdbyp+KtD+hJMvPMFl7Fg5BXIQwtRLwxtwXChp3DAuzh+Ym UQGhsO6UAU8nSDzMcVGAzk11VoWoI6KsGLwdyyRKz1lhcv5es/dzq9Mkt3OI
0uNSmD30dTbUm0apnMxd0Ly2tuomGRza0xOXlMN7NKOpve0XAWIwZjtj9e0F QoEiMubc/DMw2qZoOoEN9A+srJZSvs37aBUJvoD8x2AIbYdew8FuwFk9jcZc
vr5xbAuuZ+tY/ZBfeLv+wZhpNbUAXsm6E4ExW9jcQcNsgJJTOCmOlHkNtjCi 5MbsOLYvHSBbPjA5LgsuKwc/rLJwGYw2fMEkiOvbaqOCZHBkC0rIAS3X8xVq
byX0sTrBB9xvBgSOTFj6Lt1mJdQlQSZ6oRgdXBIChyRHwgc7pHBaXhKtNiOl ADgXftBWuqZDE/Z20SC3ekZ9zHD4YoSyb9A5h8fkCixh0mla9ng7j07nnSmn
UDlWIBzs8HRVbRaTL5aihvjImlhlrUgEJKFHFCAOElOnlfLKlh7dESXFykBp ABUHrL9Ekq1GeMclGp9UWmQkEwfNkH/28RYJ1YyppZOY9GOG7AuraS8aNnxF
GCYMTBw84ECPrfKS0OvaQMVD000WnmZPA1Eaw6Go00Ss5dT+6EvoViPYtKKj AQQKBhorXwC7YqJLqxj7iBFFXAaRLwHUdEJMY7yAzi78SH0aobiPpJS0aA2z
veppRUJrhmt4zhgjNFjKdec+Vc73qdIzqDR4co6z95uJwemihLVzjQzSCF2v yZcMAdFZfDVKj+HNWJFeiAuNq4K88hl3jyoMbL+I1qfJlTkGL5Ja5O/WIvdk
nDL5kH/JL/KPZ4s9rspIXkC7F6bhOm+47rhf+xugoR48HTv5SslqoxukZLeQ FKKLsrAtwsIJIwr6ncQzJ34RhGibcgfFjjQtL3y1EA2Y82lAOZe22jfrZtGc
zPQ4Z+9Gz+AGP8CPHck+/bEb+RNbKqmdPYO1Ce7WkBFTqfD+t/MVAE9uS621 g/aHjnsVP7iTwA7aEo9X2yxwYTWFszMAoSTy2bSaFhMzMU3ck2otCmsTx9ab
pa/fNvhAR4XOj6+2VhCEyZ5RnXY8fRF/Q0xaQzxaW1UwnTi4vtb2M41Jtk66 RaXEIQNWQimxqiAqruSWfzPbXp03yUNDEyT3f09Z3Q1z+cr8eyDzbWvZc1lZ
RQJH94R2DDbUaspo1oN9c+9Ec/K7LMr2buHw0BHCKeH70qBTc4c9rvBaYcyF 9Pb0xMucJZydB+Ofa8elpFS36mkdCoxe39NBMitpt/mGk3hT8hDWVuVc1pWF
vfrYAhpa6rPjsm09REFf4W6eyEjNYMrWWPgBcRO0YShhMJmQuw36huot33o9 sOSq1V8DPUc0GRzmnujKQ6QtWS2+1FuqwFal/J/CzXnT5GR65nb3rDitl7Aq
61WUMV5A6PXJ0224F/lAzwF50Ho17uoxyhGH2tuQ68HJlpKzvqpXWYPpNH2W LaUApH2MV8hd37viht7xJnN/x7wRJZHvlOJ54RR2nAEh55B9PiJPFPeap45k
2PCGyZJsh4cAhdNPqS79I/UmRO1Ku/QQnEjsKMrmUVjLkwHkFnxk6AVxUZMu t3uApCT6T7aYHuxY05NdK+a+aE7+jhUbeWY99qam5bXZbUEqoSOVkHo2A2kh
rJZl3TeAJJCIT0XeKOWcNllsND4e8Gysy0t2Vq5zj8ScDeVw3bryeSlJ2MFE 97y3ToWLLNh919UjIzHMUXFDpWTKmXruVpNXusJgASHGhwfUVA0nfyuPYvwj
4XL5I8d8XYSo5Io7tQPQnUQudHNJzl259kx3MJswWMJs4BwSnEDiLxLojAur nweR2Z++ykoc535ZEwZZKxXe2kilu47upbQKxU7ZbQh1JcxFnBKBrGCNcXVn
xdTpuGHsVKAI6Iv7LDLv2D5WYDhYRorWuUPkkvfbvfa68sbNPxwRg7lynOPz ClEoQp1d4njL+0XsLJrMgurTfWv5R8g3gPEoGgFhCONFJ8Ip0rPJe4XUU2Y8
1RvYQau9MT9g8kSo1QfY+v28DVdsmZ3kgUsaR93asML6dxGWLPkmS8qVsG1s d7oI+WiyiKTiIqouHCWKGYX96i64SpK3R+AWnDEwwEZItP40qVxUrrpGLddS
Pe6kvZRpa3JnzrRuoMbK9Woyd0C8UL1/8LcPMZwlnYJvc/S3B9ZAOn2PjpE3 Lxn8KF6gJou2Ah17JtmaJ1jfoR3cfBPjqKXYFb7B0NIiLxPmgaF9GDugKdPL
yNIHwicS8R5i5G/4mj4z9Q0JEMP6WXax0YHBzmEH1rNWcGRKUqGqon19o2WV +/IIgrIKgd5+ejGSaqm0Uf3oOqJROeHhk1d20LTXvO3PNE8Y2Tj9unJeHdu5
MU7+//897767OOxjE2DJ9ciIBvbXPFXqQ5ay61vKQ8tJcCF81nbqvbJzkbs8 JlnKRN29VxhW4RTjSRux8sn9pbGTRTOlQHgnahCLRWKtIvtA9G53zeSB2JsS
PLjgOYf13tId6XYHeoCUqacTEOaM1oIPhM/6oI67mfYGm7/FyHexZUn+fWSj N+HOOFEEgoYXOwI16q4gtxqvmKH09YBsX2U8q72ge8sN5lHZzgecwpPil9UC
tutzLjPpyM25xVB1NxmqN6k3W8dBxee+xCaFp0rFuwu23h202vbDwt1Gz7du DUipyhYCNxk6LcoH9Z4dPEKcOeg1XsTUpDzuJHw17MceOx6bWHneD4fh4l6Y
1/mCLXpzvNBRbIzoAVfg/rZYoDT9ihB7cMRP3Cuwx+qBmoh/0Zr8X7Il/3ct /xr56NqjMLJIG0x24q1wvaw1rFnBAxL1hJB2te7fQbjVFnuLa5qZCmouszaT
SbQjhyJNw4dyXFC5TerzLpb6vtAwRMPLDH4zRvt3mDEimpFBf1XAkgOwykwp OLLB16Q6H30xtmJQjM24S6O6mLkabZykm4gXRY16jsyPvcvOa1TBzItnn38b
6/LKRMCHQQ4cEdC6OaccZhlXWAgk+TJGxeNW6EKtHQwYLSLtGmrH6oIhHfbG jyZwXxvoaVtfYpto3nQf3rgBTbd52SgOGAkh83RYYenNfvJmKsXUXVt16aaC
JqpDKX1b0dYk5bYoI7LmsmcyET7dmbj4NtG54nZbd8p0pm3AMXEYJzyHV8Iz S9cQNRsW6FdgO/ydLNCGDzo7bUwHvbMKq88L3lFpe0fyYpXWxNUseQQWvA/X
T7RbuHkr38x8ysypKeVY1AaUu6QoV2XS3CISU4dbVbRvCgtZnuPywCf0eXKp JC5FmF+JKmCYFjcdl4MMU4hKIfKWUywj1A80bMiRoHk2d0Em29zI6/Zj/pxP
XXXDhEYN5dj9SUJf7iyzktQ0treOipTSSDoB08OYstd5Vu+hkTS+vxrGq0Ms XEIw4rG43p+VLfFOnpvrygvcnLnvK5l3YKh2jgUTmZG3kUzoJl1NLQpdsCLE
N6K/DDxvjrg6USx7h4fwfnsgnx5pqu1j2uI+tetAp5mHE4JoInl5GMIH9Dxw Mc8aMddCig5EzZHGFA/NnDE7K1nsZFaz0sJHN25Oi/VBgNvUQBcHmbim6I2i
HbmSnvUa4+QnWUTEniwJqtHrptSPSgiN6TEDMzQQk+DFC3bZACsvmGQvfnn+ oTRrBsZJ3CFb8IohJQIRsNFTRXyyVGEXiacP7IqYFbfmsKYANyZWliuIBuuH
0/gYMfSz8UusBd0VG0x+QbAjJM7vhYr4zXtqs6Grpbl7+44dvWBgbvRXj8Vu IJgVO4lR/5Uyf9cemBQFcBVfhNHaqBIocSKAeFuXNWViaEUsn2ZhECQ0f+rA
Y5x/b0jMjm3QnL1F+B6XYJTtPNjxXiYqvVBM8AKJ/4QNmefSyBNb5HiJVgiw Ut8PeasmomGnisr13L4p3DtUIaXj64mcQo2dK2hojK4dzMu8dUVCp3aTv6Jq
/KwrfroWemsBQCxsQip4ws23R7E0mZRf77Nc+k1P9h9+H77p0eQJ+HYhNE0e kx3BcY1h2Ui4epRUfK4+ReqhG+RHJwP5UpM1bp7V/DjHKHkBHWSYhquyZUKB
3PA29ojwgOSLSSTnrIp9X6YQ93US9zXRiZqkp5aqBy+P9GEzOHwumnzmyexM XEJ/wDn7XIDYPlfWbOsVIcm7g9hrQAt+OzoWlx2C7z0yMfs7OTJCdpIkOHtB
93MNTwxsEfhtqES6ycse4IQ2HCSDZ1v/MUklRRKQHyEzQauwMJXVNlW2oMiE az32nf4mZqxiOW/nLGD23E4aBVt2ZNcAAjkgWk2eRkGBPCZqSRQM8RRGXC0x
uz+P5Dmw+BHv3sC5+mzdeTYThE+gjvV6Ru6Wrlv9u2U/79pEj8SsyyRzb3A+ XxLxGl4jk+kqwlW2aqKpNLVz6i24PfpNKKhjnbUmOWyTL+KeLXyS8hz9poiC
xDzsDCGnf0teGQ95UHiGFHd/TgdUN/Ivd1nsqt/tCB2KXuJG5EPgVvWeefU+ 7Tuoe7SLcGv4WmNoCN3isCs6XHjN4dA+tKCcjqqnuWJX8WgQXXisJ9JT05m6
aDNJQzTWu32HaH90+yEwUISSqHfkOR9Q8dkdVLxLVLyZhrtFOoKFu13bb+Fh M/ZAAI4FwRgSc0ww5XadviYpUecUG0riyAzYkJooZCODFdW0iWKvKCpparMe
/3c0/n5P5cNLsq9Q+3bOUtV/IqC34LRZwyFishzUAjgbQ98rkci7YFixlYRS 980YNxP767sQMMLpllxKL/czGw6m1FTQYx29Q8gPA6QVzRauQ2Uj9o3qjwrC
9mFZPxXACLIFO0no76Q8FB4Iu0zBHLndnMqdNauna3panKMUO5bjQdTyghd6 2ExNtYmyLxIti6KC5JzyZB+lBeIY5ldc2KRguS2M4ev+EsLJhzSv3eocfVls
NGh9jwbyKAihEnPaFKAmCZCB9Et4N5hU4sz4T16WLbb5bp00Dpux2b5cwUu4 1c0eoJks2Gs2bK5Kjyqe5QLobrPy4S2J+8FE4ZL5+8eMLkIHczKpKgZogGL1
oyiooFawaIqIR9zUum1DnQVePubraFafFZuaGe7CeDG4jrHjjuhSiALND4Ox CvNIyfUWD0zlRxt2WMJs4BwSmkP8N+KujCkTRPfpuXD4VJAgaMEL3u91yPox
c8qNi+R0ME8LPLqLliqN1q3ybdXzpGNXzh05wDvA8G6bxqlduJU16ozA4Rz5 R5/Le2Qq6OSdcCSGnTumH6kcaLwcvVYq5P1sMIGO44c+VQkLJnbXhh5MDApl
xoO2CvVN9sE4oKrmZktNhqBSiZeUUgjEDTyKBcZ06Hxdr9hF/fy5qsdtVQpX frbuii2kmclRjA6ZR+apm/SaEkTWPIwgk8nILD9iWp/dulQyN6OUFTRVq25N
P0Pw/Gye0CxhbDmaNXBMKmQeYLoPPFxDEGVETY9VX0Vtn7get1fKxSxLZAtg atln8gsznH+wAXEnvPM/z3FOJjXlb3YcXOe6gz3sCzCNvA43aJRQc8hCjokh
DQCpjuITJbNVwlrNijJK3IAMtCGxXO9CG+yoJ/W69dYr2Rx1Wnni4/VrbEaI 14xpWGngmnCHIW6u+1hPIbfqDh+CZ69hz5dSuIpA90m+lmUquAz+P2HHD03O
hawzMM+4v7NAH3Hs6GIr76kmBORblyltc1qvVLBDKokYah+PrAYSq1xsxgZp vL1O2DI3oCjLHrt5egXklGw3VLJzi0rYLmxrNzFq3bvI8N7RPWODm3XfVQ7v
QO/R82PmG6iR/i0bpo2BBYI1C1wPFYcKGI77ye6bdlpUsLVrCvkFXh8v5LiN ZlM8Q9iWERaI8kctwzvfZ0M8ye1sA5ObstNKcEmYGb0FkYLbbc4406onS+kG
CIjqLtY5aMOuKGTS6HKU1npaLyjFwkpFaBSKrKnP12zQoNgi5sMw5k1LE81q Ldddp+VeJ/lsJhOxMfg0syE8W0ggXNATbyHrdt8n7iZuz023KRdsEJgbiK5w
N/CjpTjyoc+rn1XTZgjRdBIuajtHHeFASXP7pDEcIysYxlpqUIU75P11Hdg+ o4HnbAlk1dwpKbjqYwS2BPVg4l6APtdkcoP+Tm30n6SL/rM1UdRDc/6r/O0d
/feyAqBUopLdion3Kkne0Otj7TotGtKrvTyPw77SlvDCk2/bFFHcOIlmi/gZ pxnv2v9lH+//3OZhoIjfOzhujDDsMZlKNCtZ01ewrhlUbKEMl+XK3Nh5rAW7
LKOgtM7C9aDcEPfHDPRK5M8iaUA6BlDEOWMueUsKqSRNvjADN3jyrgU2TGm/ FzSL1CnTYcHpRoLHv4gTRPBQ9CHzFDqMypPWk7Z9dUERD2dkG+Vk1b7gdGeC
scfTBd5Xz/NE+owGQalutQQWVDIpqJeMI0y1XGIkTLbHEmXhnN9dsG6Pq1oi grtE0/sU0vmCeYdBAbtoS42IhOLp6AedM6VKvUTil2oWEJwIx/lXi758O5zl
LtXAWdAUiHJps0R2RoHIEx+BisawE+YR490A7deEc9yeHSDZXw4mVYDAJiAo anmGw0RC/AxfON6wjE2fVS3FrBXhJoVhAoOZISU+zv2oyPyIdQnoALPVwPpk
iOu/CVZKirYCL10as5sk6WmfIAuKxN3RaMoJbzzyOHPBBJRk2/oek1R5aR2X OyHRpVSAKhlx8Vi+8BHqxLtiY9Nrrkp5q+C0+LY8JgBDvWmMOr93PY1Nt4Oc
g6SNxVs7Z6GOSgH88bw5TxOYzl6/o3I+Z34aXDuJPc6EkooZaUcDUfpePZZA fqUShBOd2mVK4hiV0+YKYkoOnJR9io62QwEnd9c/YaXDojnLVSdZ0d2N/SKB
fKWNqmeWpAUVpDt8TwSPjxh6oxCeEORtG7Z3O+cYbydxJDILfI45S21wjCOo PoIppcg8NsYs9c6XuMj3pfXlSDGKEDzrEd9wYM90RJBMDI7D61fKYHgcpioG
XZRG9w2FpWs6JWhhRy6UriQuXynbJNoWmfBwJHKR9OGfFTTsGZAry18SEpyo nrHW9GCUITDP1GK7PyGILVbzCJ14hxYfriZzc/CdwEkikyKqTZIsDF5BV22t
AXhqWordSdsl3RxcpeNbo8qB5gOm6WbDT2njCRYt5eIjkcn+CHIORsgKvO5O w0p4/Nn3mJuljEeIl9DruRn6eVBxf/r5yY/jp5hBMhs/x5TyfdFp5QtCjWE5
jmEmnJHSFpiguI7R6dhQqkNUPQI93bZ1nbdZSKsTsBs5UxqimIATEacTjvKy mXQu5c0HqgOjjauoC/uOPX0gMzn61UPWgjnJZdAjLhJhwLiDRfgOl2BU7N3d
ntGsW4hmUJPcMCcgJfQzWsv1Gn6dlsbqUTGbLYrz+hNsbNFeafV4L6DwBMMJ 89Y9XhYhk+YnJFQVHnSeS7Oj2MbBRzQ9hnfQZqUkfUwcobkv8XYTstZnq+IJ
vjaJ+53Cx39iViVHhXKceagb6itOMxhASVpjxSucGQuJDDMuRIN7xtp0gaZD nO5RvJtMWHYwLJeO6dHh/e/CmB5MHoH5HCIEZCLnD7NPhAg4zJiid85XmK9c
XkBFIHIitz1mVw8cJ2pS5jvgwW18+kUM7+TcfO+vIz0v6mldMbw/lLlwgZ4y GJzvTpzvxivU0N5pJOHH70ca2Awu7fO2nHmKUDxmKtTELZQ5IvBtyGZUFquc
ZviMQJQ0YHecqx5hacPN1HDDq85WGto64YYkDSZawEhQHHeuA9QhT4tlOJ/E IyNT+8DQGmV1gmEzSQpRGhd5P0Kuk05hdbpZu1TogjiTYjZltKEDOyrxmWY0
Xkv4binr6YREbNpjMOvl/w0KVm1T2Tx0pKTyrNw3gWZgb6QkAa5AOnLRDndA kseb3lMkIeiFLrWQUU+/ltqUw1+LC3XfBt0kcFAnKAsD0iLKd2cIj/1bypXx
Ebi4ZBRmpruM2UDipBaaSVMfzKYPxta85gxA3buGsTTUFv5qcEca01HpJINy PGS3T058D2c1I8CR+l74gb0L5HaXac53jEeRr4IbRXzhRXxe39TCoSx7ZwPZ
wTrZqYnnD2h+bjYYCpmMEheIEdjPuhwaTULv4NaRaZEw/ArbSJnwV9zE4l7k dTi6+SLI5F8lIh5remTEfHELMe8SMW8m4nY+pGAh7JT3O0qO/CMy/3Ag9OEl
Pgtf3ud74v+EApwtDpj1t8iN0Y5CZE032MbaRz16lpFpqEQ/ouupLyI9H5OU xRcIfjtlifCXCh3G8LXqQ8QQnJUDdDNmS6yIF/g2EGSsrLReNFtirDiR3C/B
eM74bsZazuLAU0ZnxRwi0kNdufp1+am0n8t79EwNv4QbcCo5ltN0SuisTAsY IWFhJf1OssyhQThnCrop7fFUSr5ZM91Qa3HAWGwA9rJRBShe6FHWchllQlkI
U27WrfRDn4ElLRHn+H5lwUiLamj3RCcsajNDgeG9tCv5fBkhmaCJOCfMq4ID fBNTxOSxJxGoTAQsvBsUKzEF/ZCXNZhCHypmZF2g/CKTZ7mGl3AJbhBCnaAI
ZHYn49GoxREWzKULFlxBYnRN3GXVynNQNjm9jwrx9CxwdFjlDGmvPSSJDs8S NakBsW6brgupMvj4mJ+jWX1cbRsmzgz9xcAG+u17omAiZkXfDcY9slxBgmqC
e95GDRPQ98orWE/kICKqRnRtglmEB7Y+UL2vWD6FIgcbcJV5dgGuzgr8CxDx Py7w+oaezbXUdDNPqlmWCvds0KvepeEB4hpl8j8WpzOC9nPAAe/ZVcjqsw1j
jYJktfgmnX3kdasr5SLMuZxMc4o2akHz48L8oG8+HjMNOskUxfjO8wX4HrgY X1YNFyFsC0TkitOpljwuLmNVLdA5RtfrZs3W/adPq2bcrWreWl8xbtJP5DOa
8Ls4ruDTDSs6ixZ8DOEasyHY/sAojpxotsgUQgNJfkmp+DUbd8TlpraSum3K IPTeRxMG9skKyUuYMwjv1uCHGiGq2vMLROUQmb9gkMDItG2kCmACB0mN6iNB
e3ZSBZvqE12f6pKRt5T6k8rRBFJ3LDOMI5DJiw0V6Y09R0oWiXgQryjtPVQ3 CnRzdRqX1jRwf/EIYkSfd54Y0PqyuV6oaq+kczRp4pCPk2ywWC9mv89APTuv
rq0Xa0Hpt8G/7LgrkvRsN3NMMbojopigEP07aylwFIV/88V/Zn7eKs8om0hp L4mkv9cDhM4JZZLWQIwMdpnS4af5ZhUb8hIAYyt46+kdMTc1QD7oPXp7zHxt
A++MDkLk/ef3EzmiL3wDkzvTx4rDYh7BuAXfKiROvzE4yhSOESfZL8evnmbP UZK9dcvkU7BCsGiBL2bFbhZGUn+0Z6abVis41g05TwNPmN/geIQIQuzONyWI
X8Bfu/998OjR/pMRh11PXxwePPpuLyW7/Z65ZfFZSDMN9z//6am9o3/DQXwD wr6qdNboedyvzbRZUGyLJYrPzGybsw1rNLhxEX5jWDintXEIdlv4SJM9Q0l0
kmA9hf89He8fPB7/fPSqf8e39g4idAA3FVcrjoFKl+VW+Qc15N/q5dM4ZCpu P62m6B7CHsXf1vWOqqWCiOaCgmO4Q9bQjY1kXwsB0durRmXbNAyYTz/FcZVD
Ox8N/pkoNW+xjAy23s81uMXIvId/fyHiQ/+QlipZMdHObLTiG7RPQcUy8xn5 XHS8F0nUjF4fi9Zp1ZJQHQTY4CqIWXN8VQMbm4vLCNJsEceLZSmVcpK4IBSU
nEQMAk6Z/kwvk040OXaOI8bnXl24klFxsxRLg0HckhhEwvfSC5xSWfiiUZCe iymRR2zUIvFI2geQwiVDZPlQClEtTb4Qrrd47W4E8U3x1rEHPOowDXEcCTPq
cxNAQxX+93XB1JrUNOUQbGAxbAXnUS7IAGPaxEiB8hCDm8OoGtV/3Ol7lXwh BEENVA1YUKKw4I8Kds418ojZYnI+lrgXzvjdFQv2OCsp4mcOvCdthWijrkj2
xTan2iDe8Tjj7+egA+fudBaQ9NzOglSYgkhzxwJhcRo5/VDa70IAFccOzUYf ziiQA2MTKGqkW1w3ytJoZngEJwww8BQjyQFzMKmC3TbeVAHLE15KCwlaqsvU
pfPB55vOCLeRIaqDuiF64ywZbxYqCX39GDwfDzSuPOouqaUW1uYuhBrp20eP 4TlJsAE+CGkkyS01JibuGPkMAUFkgNpsYsqsVlvLRbnqtGjQaztnIQ1Oky/i
DgTOrgnIuPL9bU9QkvmhT8HlZiNejlEvH94mcFtqG7ZE61sq2MG/zX23xual eXOeezSdvQGjMZLrkGqAaydu25kw2zHL9SgT7Bik0wkaW+qMe7ZaWlBJUoDx
1U+zrnwna4RlEGEFkqMG3lmKgodfSJsYD8amSBF1lcUdFJihkVlmvVxpicK+ RJkNEad65PsUzs1d3fZ25xxDFrQdiREH2zG3qTNqZCe85ha/IHkuUumFHaio
1HqA21oVCz9UKvbuj5V+nCQT4HCxhO8z3hzeMU5xDeiIaKfZ0KOPdiVbR4P1 UyyU8ijO/qm7gdst0uDhWmR6gOM/Kb7bM7+vLAtSCCGjDODJ6ciJJwUH9Xhw
G63admhOBi+bjLReZ6FoOE4/LT0ZPbOwpmcmOhlBHFkjkFQuTF+EsKTbxMD5 mpOvHS53mvc1p8cNB9MlFRlEULn4WmQKUUoTAE1kDZZ3L3cx81ZJchDMUZyK
QBfslS13bRcCsCyY+57fiz42VwZQsCT0a9Sau+pjZHmtq/LvGrlN655kQzsK 6rRzuLFDVCLCnt10ep1XXEiwEwwfqZda4qaBWxHnE67zupnRxFvobJCUXKss
cXtMEhr4MB2hMcJIk7O+JGmQ840hIMxutZCuTwwXoBinUnFjczb60HyxaUvS oFR0GJ2lkA5fp9nNelvMZovqrPkIZ5sc3urvhus3qbXHNNfq00bmKfIcQ8uY
5H5O8mlTt+3A3tARw7jQWkM1GCrrbCzIP4oCb3dNgt0gUZgtEA+Ye99gwx6k M47ptrjATivwRvwLmHyAsFBiaRNLK3pAy5jDJH4UljdKmeQIUINAS67MavBl
ZTCfeQdpcj+XTBRBaJKguNQnLpdYo0Gnnk8fNkVcpr4/CWfmionQpNXBr9ze PC3/6hwWNsAjcN5ymco6Ic968/qEJm+5JHOFT8mqWXneLpioPVr8PQHDmM9x
KurKdQ3+jqcN8XehGYkpNua6TN0GknptCim13VOM9cesWX6XLbUsxAoPPhef o4As3McglSKnhNnUYYnx7ujrr6+uriYwb+MKdJemnTTt+dddv11USIddfd3D
yfknsBurzRJfjkkdjDBVXDZ5sYYHMCkss5/HQUZEJ3lSDyua8miy5OyzJ9nu tf71QSDAw6cEQV1ivBgD5rRYnPZbod47qwZmzIQrKQZPxNSvxshdsT1QdpSi
+/Rn1IQ4AQpRhys4DPbwW5977ArMZ8lJADioq962DyCXeKBMvRVR5QpzrwJK Aurwhg8It65pcZLXUsKeEG0zyHLUMpXEBmMy9EobtCiEZzCm1fizyOe/BKfT
BUAjqyK/5NhOW9gVIRb1uVC4UCCqkIQhEggfyn6hY+w33I/cm4rdkXTJhtPG o8k3PvePi8WHVSWOmlutq4qAwqjRrL0L+zP8aqwlj+jAyEsoxUvUtm5AKR6x
cbjNGa4VBoj8w1OGJDMbu15gewzX1RGXhi+K7ZfraVtaSSn44LEcMbGoUDsk KQlFVM/oyo9bH+YU4yxRr16thTx9v6SrdLh/YYYPvmymRv+EqRr9v3euHhf7
HNLH7MdsX6mrk5NA46fsEegJKcBTJJRuCWGIVNL5p1J5O+ynuvitfOx75m2L dOb/OZPFUvv/X7uKgme5Kci4cx+hM3f3hvlH54CTqP/BGSCu+S/ZKW/9c6Rk
hx08ioR9yG1hD58zDdmS7McgxFRjGl5yWDkrb5nZIHRgR3eSPMVhVNeb6qhJ i264WXEiXEgPJbSFcnX5MHYS62ZfKHMGwH1jfl1bxbUTM9AJ1Tfpj6KDmcs7
99YaFLp4IkY8WYb8pRLqicC2lQSdg6gJ79I5cQlowy7R4HbEA+IzDF7Hv0pm Dv41AcyXphYLtESPYxi6JMT2wgQ7HdDQZoBtJiVEpYPoLqTUp+qEUhgGeqMD
yoHpUg3NjWKiJ46EK7YySChPzoFc+c46WZTeEW81MObXSmkjdfhWxdjZc/Z0 5SZy8M9GlbNboONczLkgV7qdgxiSQbe0DynSiO90kRKOyu8G+tLWmFN4mdWH
sWiAMBGe+dASi83DeevkE6TR9C/F5hRZtTyRScdYtrzT6DNmQOTcDrw70v3A jPGuBOFBt0OeiamJq2ZUb657HpKAjRYt4NoJyGxZD/XmEzPSTT1Tkg346rwy
DzXgKDrRJHyGtNatEnXABwvbgbTOeblkxVEisQ1WK+KscbSMjyQMg2WmHSx3 VT2aIi7O9lXkvBTW409fiQsqpKzu8IFZlxd5krRuJvkzYF0/BJ/zwDQ1lUPp
kGAeG8qawedqGMGDmkKFomFUStJTtlIx6EUGvtx0Wmk+Msy7juMEFgc/kJnh I3qeCrRT+wixQUWfikgW7HGg1E83L4l51OjwbKT7ElG6/MSNw+mwatSEL+EH
fQh/h8h7dnwAEyPBNDSfXd9NwsOUEeMtgA4WWz8+TiwsCJ5dfcdFaQmKmjA/ OJXsSW97rdKhXEUY1Ws3RDKLs9aABsge1fj3Sr6VJqDS8YlMHJRohnnLO8ou
68OHTCU6xL2e1NqiI/xrFdvM5A97TxBTUZ/vec9wPKvUL/YiD3ZESUkjsksi ZfjSQ9Feou2ccOl7XQ45Oo1PSU2+sGAuXbDgjSOO/sRjqZJ5DvKmpPdRErtq
oklvdV1y4yvOxFGXBRjHi/fv3546brHQ+vC4ROqUV4vYKkpmi9RxUuCmkUOK 4o5MhZLTuxqPuiXbBV6c1OlC71e5gvVECkQi3EbfUrBL0V7SBtX/Fe9PYefD
muBZZZE2a0iLCqhvrSo83r7UYbXCkJPm3girSV70qi5beCr+fErxwVGIV1Ms SrN1WaCOvC7WDWzxreaJaIpqOvtIztuslFG65ARsRXdYnzHNjwvzg+7R8Zhr
ZokQTEEgYOm+GuKUb1PnrR1xTpULffkSqehAIuoBptZst61dUgURgtCm2e6S 29CeogjLWbkoV+RChe9i164P+K7pPlrwVYRrzMZH9z2tMtxIBPNGNRUtVPmS
Wt4g3G6lCrfXf1OIY/2X2Z4hle44H5TyFj2+nVz6GgxDmIGRq2rTmF65zPHL gGQbtq6JkFeNVVWUlbz2mSbw8eLBY6ksGXlDdTip7NAlccd7hpFwMnmxmche
yHe3LUWjM0U669IvTt46b9pTe4HzRc2kVJp8tn48hTjOQYS7NRXqimYKDwkH +mKOpGaiYBA/PJ09FDeuaxYbSVgzGn3P9T7het5QgryfY4qQnBBHE4VI31ht
u7ZW43FfE5NW/ZHAT1Rbsm61ZIwXmeTOxzStXxq3YzatZj/qCa4tKDH5QFqo gR3Z/M1nP8zyrFO6eDZQfU1AzQmnuxCLOfH7ieLaJ4mPXFlos+IxMk0w6s5X
6jA+WjdUunuEdMOoluBFp8dH2W4ZtTbQplYc5r7EWB9V6O2xTIHBCMoLbANh rovhDwMWUmKV/fnpi6PiyU/wP/v/fu/Bg8NHI456nf50fO/BtwdppYLvfGnt
PyOznQJBPu7EsaJwHOAHhfa7ep7mTh7lidTwOn4C4WtD9EEOa6Ye8wEHDiFb R4cP72L1EGjiyY9H9kfD39wb/AaZOI/g/5+OD+89HP/h5MXwR98kPyJmpCnY
QSfUj7Dfm0wbfgfGl41swBnjPCItlGPlNJUKSaRUJ7V8ZZRL8gxw6Ak8ADKF 4Vj1JQpFObbdO2WT1thrp49P48iVOFD5jvBt4vZ5jfnWcAb/0JQLXMFz/N/P
DCu6VOYKmBH8JgzslNLwEqeh7CaGZzB7r51I3KGJLW0xUtGsQBsITg0UORa4 RGPtG+mICgKxT1xeQLw03RHIWmauJe8fWaqT4rV+po9JmcUSyyRTMY8BwYnS
EQbjxrJ+A10mpK86Gn1o2SnNmm50NUwCmDSKSr+pxqsc+4AjYgVRmT4fhblW YXKxPssnRVzh6M/H99ILnHJCeb4F2EZnJpiBspwK6OFnT16e4q27VP+CgBXr
rMzkyGCrw2EIlXriyMJLTX71dQL3dDgcZOMjkmCfdjY1eeI4aCUkwvskTM8l BSljTIIdSVLuYnA4CXOuCELqRhi1jJBMYvxFW3b9yHE/4/Gz+5dhFDoLiHCz
RV7gYKvn2NgEPHwS7VDfIWscklmuy5uLQkPwrV18VaI4FB/BlNAQ3UQIpxBq syDUDLC3uR6VsEiOnA6UDr5QUMZxHHPiR+l88EWnM+JoRoizp2mpXkWR9NdU
h3VvGGNJBzqCXAwGAHvFSFtX2ddDa2Qq6JwcVVgGAX48nT/Zu3eih7Hwibq1 GvQJ1tA+3mycjdtfUM1YpLVYCMvgNw8e3JOsLsWCxPwxrwcbJZkfGgouN2v0
jDzAkzI/RzKpqMeQ8DwDc728wDyqouUwtYXzPF+sBbMCRwx+Kwec/TgwbkNA cp/6/eGVA7cjy29H0LSjBFb8X/O7G0OkUmqy3axWXoOwzEuhjAAFI8MXRR3n
TLI38EI9Hdyuz7YKTbK3FTE/LSNQ1Sp1FCi0BLJDtV4v0Ig1La+kbIKjK5iP I5HPHsOpdIJCqQ/kaNss15qpdyhZjxew+auF7ypxpQz7Sh8nMV24ZWwtnxkf
p4sou7Fne/pkYI+wLmukkyjrjoqhZqResVVM2DcaUpUMHA76Wlpi07NEOucN Du+gTCFmaJSwytyZMtR0KllNyuYxdqrkoV4ZvJ2krcVVOesuKi0EzcnQ0ivS
izp36mE6puITfJdp+4bdOqQOGo4ohGpNsnc0HsrF1/Yh9ATLThNcNkd+ImJr F4rw7iWdjLAdWSLQrlyYoldhScudG8H5oAOclsHvbtoGoGRwYSN+Mzo7OT2O
G+qBUAQ0ptjnbNwPuUJkwq5bR04NyQDmxRhKSFFDLDYIzI+Cgxx0x7iJYx27 HNehNLlmoq8+RErYZlX/p0bR0jxgOdKO4o0eJoq6fmMrjo4UJ+NTdPO8s5I7
kpIvhe0kvRnK6goXi8diiaEw1OPEJChxj82x1MovDwW+r7QDXHbCbIrZUQRr y1yR3FXJ5OOIk1ZXwQrENNRyse1qkuZ+Vspp23Rd5nxon6FnqLqhKAz55tYz
PDFMmTia98RQ+TyUgn++l9IwOkePkgi6eZZl3RQPRhRxWRnMJZ8GXtNVW8Km 75uiMMht8QjX7CoM3opFzB5HLMmI7EZmmLfYUe4PNfMtEbgvCC+1kOslpirS
yuPlRYWbeFjLzeu54QimnBh3Il4QNzzkjXV8iBRxodFLFhq9BM+0HPRcPWNL zeeRHK2tOTehI+rvzTXTikolq1+4gCkBGDQ94QqMH0/A5X+FOiWiHZh3O7Uh
qQTs+nRH+Bhf6pSQggodp03sGOfPUC0Jexs6CchnGLElRz5zdhjAcyPG5fRW aOdr7XMhQpli5DXmoPQnjRUew/K/YmJ4apPxAKBErrZLfDnG2NHZv2IygfMN
z6Wrh+HFojmnHrS1twJSPwrNPzmENnQbzVfY+/bQ12gnDGFSTEaS/rVdKkxh NMAs/0ybHod8ECvq2bHs5pSmSa2zbU+K/bfpZ9hKitukGqZwIRzgWJ94KCHM
t5ZaB3JQ3PxkfnokG7eZBcOtIykLUxjmXrh0GVNNZ9y84PwzBwQStETIhVIT Z80hWbisV4OjHzCHcUeZyTKqfiDFGDQ3QvCMsiryJTt7usquCBXGmQsZGnmm
OzWiSNORPiGuJB9y7WrHeorCojX6o7SW+RKxG2TbclMNCvHIDHqI400sprKa KgFwYE2IYzkvdJX9iieSq4+ybZIuWR7BE0c+nOEsY7Te33xEIpnZ2A4D/SOf
u8/38AiWA61PYNrDWnhEI+t+PCO4lSpoAKY4sCvy+R7xRMgZSNviCzfT65Ul Y76RksJMFZFLXsd28OqQEK8P5slFE28WKnmJnfpQ/L441HIkyX2gwSw2EPw9
WPiQErtt4wDE7tKlRi6cJv608U5rObpsn3hqqiUhoS2P1p4mZMiIRsBwLlpw yRkUWCSkI9g3BWk+1kp8ZQfr4rfy5e+rqdjEjuyFJGR6bmdNmDnzei5Jjwwb
+I5etax45ZvAlttRJdZaYV6KBGbApR3CUB8DCyuSCrgelwal7m0+i0QpVEB4 mZgXwmuOV87uucIcErq4o1/SnoqjWi4z3VwKUYLzKcfWxJa0oB9MRKUnPZFH
aImZUuknJkWD+PixoglcVMgQKZj3trUHg1a260iHH51FHx1FukhVksc6+4AP LB6gKHtkJZHAsOmETvCssoW4RZbbfmc2Uj4rC/+nZuo5mDSV1VwRMGpxJNz1
2IkkJTQO4rDB908OHn75QjaO5NHpAVTXxuleX7fge054k9m24b5dFIbWIf2W KwNQ9Q5odLc7a3tR2F2M2FAOqVF+OCGrscLGzqBL+B8jrFaYDM8qbDkz5+H+
rYsRLSyJwFYBk4yQ0z4JAfaOeymgQC1LdlnF8FCMeSQhRCfxPBpBuPjw5dvX dTIMKjXeFT9X21MkjPRsYD0DjctendMYnZZ7PBDZSXkr390AcOtFrvCN0llD
RIbdMtJHf27y8fbhzuqG8CI/Vt6jmKkRcLLCY/LWbI8ww1RqqRd5WTOTMyDW S4QDXzOsGdJal/WSxUiNLHGYwo8zx440vqDQQ1YoiQoWmaQSYUwJR4gGGK56
f5ImNrQFc8o3M1pIUFtDCzPyNMyJSvFkwdfYbUVDYVj1NJLGcapnZoPDEVj9 GDzaNKTtG6LCBDpg0/eDlGRE4nV3l2JFwrxrP57BAuEAufKP9/DvERPenvdt
hvGU3FkjIvPt1VPy5fJssiCLtu1z6bgh6lUf/ah8lXFnCh+lLpu3X2u/1PH+ oo+YuuaRT/uR43jEaAU+BmhysTbkXcjCFeTL5+y5OMw790Vp7t9nmu5ccZ2E
0+okrwPyxo6BKdBIYZlr+CYKHqMKQfcFa0EUPhp/LilyUyxgNlP0uZO4x6+n hAJN419WsRZNFrK3DREk8OkrbyuOZyu1lP22B62ipmg+aSkRibPXwS64zinH
qwjRDDOCgYn3LX0d4ygZKk+VtcFFw8VMtX5SrIGYVo4gMZ9srhse8cDFYk4z f6mIFvTjp7dvX586rqDVebWAh1ULW+Ul0coxD7N2k1w6rdxYVPPYyouoFFea
RBFMld5tMUoxb2n24sONZjQ53CIhtuVzcWa2Lz3m/Oip0pFEBMGhI7DWJTjh JYdNerHHx3dK7JvoiVJEBIHoyaZeN3UHTeLnU3IbjoIbu9TaKooMQ1obVcoJ
w0Zt4P0oPYhgkh4YknRGGJHCG1oJi91kA8vw3cDwJ4hnjQwFyYd0lBsh0zd6 BaGmXDdirAtzX/AjkqSIhTEyDOgYunNJWl/wTc/KvhQrdUkFDTFmzpXLMk35
G8JsXISHEnQH9TYmn9W/WMP2JgJuKxkpR8CL9I772nr81MsiB1/Wcb9UKexM dDUdmS0It9LT5n1VXrvHt5OB34CKCDMwcqtG+0AJAVxhBUdGlrwtHx/dLG2F
glTc47zKClCEDIExr+skLuEtskmod6NA8CYQPuH8g9HMZm5n2mwcGaC4lum6 +E3+4tlr59V8qh11tmiY21FBQdaqJ4fHGWzffkPMFSKVQiPhgtcqutzvK6Kk
sBwYu4ibkfz3owdP7F3YZkP49gOA2e8np0ClrsnnhA7Uxt3aljBA73Vwk+yY bD4QLJWSJTedZkTzItOe865Oa6WaBHMUHyoiCHLBN7mWG8eYBEmgVY9u06Yl
T482hFf4bqoF003bcGk3hzThafVUPT8vH0Fu3xydvkVlfPTupT4MlbNLHgL+ LosTxGSgSIIXnT49KfbrqG6VVi9l7/cFugApCf2A9xSojiC4QEcQKlFS4Mkt
dknNuAYfomDrzUn47SEFrumkhcE5KXwVtp9I6sI5o3NBGcegeqxgcyvjFsHn 5L1Q7DkKVwEOyFdvL/Q+LZ005VlJ8TlugdIegi9CLmzm8PTuB/Ys241OaExW
uBikKSi2H4CgiUiLyuOG44uCOxT3DFmaQOtPaYLqGDPYtNSExqi5LMzIow+Y V5IaVph5+PKZ3R1wwziPFg5ZxlTWqFekOMVB22a2kVp7SRtg4BOsC3YVspDp
ynz4mYuXHuNRSKXtfPCing/LYJhX4fzgkgQ/S0eHmdBggqp0IacFll/to0os YpknYE5wVOjoqaW8OU5E3U8Me2/xVuvMuWPja9qhsKJigboQ3Bm46XjLjdA5
Hk3ZfkxLSjXTwm+xh1JZjc8Fv135yJFVcSENs2awBklP2+WrBUHMA2rIJ7VZ N5YVzBYR61h8owKIt7UyluphV+Uk4Pwjh/Wr1Xhd9heO0IQIl/ehKior4kEl
kxDVo+2FzHkXIquMJ01qdHq1Zrq6hxJ2pkVTfk/tQez3EoraPGAu/O725cTO nXaI4a1qmSPFPb7Rv04ALA67gwS3RMDvo9Im4VzMCE31R/C1ePA579NvOjju
hi+b4jboS2wT59a80idxV3ujsEHdozvfyMkXV4OTcFAfdG0ImdshdbW4qGjE JRauA4uftndIvZNVDnEu15fteaXe+c4uvwpS7Ir3aYqziH5E6NPghYeVbxn8
0nNy4uKMH8IgD+9n0x1ysLau0wZ2s4KqzW0viHFRcfmceeU1pfhngrKid3ru Thc6AhANOAtrAY4k1MFnO79KJjXcyWWFWWpg19MNVLx5I9IYs1OpHt/IY+8p
bvlcY7zLjVInQjIjySwDbaHRxygMqRZHjq/WRRWJB0lFogBeOGmA14sdYLLH LHQi04rSDOuJFKC81+cYZFUsM8a9cKbni40gCuGiwdFiQmbUE/TmEFSedA6C
bbCgwUDrc3skjbixYEYN/AFyrey3y5JR9c7nx/gApbdvvdEQoceArPsDLCpZ Q8kt4fZ9MFaqEHidEePX0gcVsZLohluXQNAo3psFKrOmrqnktbHHBWP29BAF
XI4/MVlFNerFgeDXeohdwuPXmj4vZGWSa0D9Kcm+R8uurvDL+QhCvTdggA4d PzAxzfYMtBKWaq0UkGcpsmIwMAlarAgYzo+6WiVER4i1ks1zakv26LzlDc/1
Ms49SwCcQyAoY0gOmB9lZaZOvHMfSbIU+6aUGEtQEA1xvqH0+GKQr8VR+JvK GJm6sPoIIzP1fbGamNB+wGWFYNpJ8Yb6Q9H6xjZCLVgOt2DEObIdMf+hpepM
DyXtJ8bgjENXNGfkXZzb0BdJoiykp5fEaaCTRkpQLJTOsNx53jMvCJ7AHuNr VQDMi6bOan7ONCJFdtM5MnJoH2DgjOFm5E3EbLBApixI9ayBxnW7m9i4lIAq
2pIgX9QXGNqi/sherDGRgY7xowfff48VCD4+ny4IviS4eymElmLoTkVCePv1 HCqpGlWvLnG5uC+WRBHdP06UgxpP2hyzYf3ykEP8Ugv9Fs+Ymrg4iYDnzwwB
Yh1Fq/Xv6BLo6RJ2eI81Qj7LVh2tpHdNhNAdku2QZKDmajI0m1JjeupUlPCu NfbmLZE+Pwm8J5++SjmNnaOmxLNu6+iZtsSWEYFcrwwqnu8FL+9WO9ypynnp
+IiCdRIaPl11Clv6ePVghyRa4UC9wRV37AP52WBdo+fF8Sf4Sg7UHQYypCND twqXF7MKXIDQZf2acnPcinFIDPMQWNb+IZrEZQvRWSu13mHJekqzWsuc6Bsc
qeIcHJ9SBRb4km7jMjMUZkibtI3CLBft1aOc20I/Nsl2T4l0KuVziaAXe7x7 AWl8RmrCtS0c1zboY0xBQ0oolKdoLiApcKByGdrQxXEAOY8YwjNYQ5euIToe
vIMFoknAFKFYKz/CSX9Z10rBMzQ67NVVzjwKHu8buCqK3WTSuxjMYY1tUoE3 q/YMD+mTxmsFqU2F6qBcSFv6Gc1akACxEqCeUOgE1cHmOLEtCGU4TJRRRDi3
HDO633CCiKtUYTAijYpaMa4zjqspllLWefBQ5lMBMEVFNkeB+d3VJipU5kpf JQ+AFFKPOKaC0KjK9bTbwjSG+RfCek5/oRtvXnGgml0ECawiBE0JGadqFUk8
bnQnGRuwq3Ow19Ym5Ug9TnhQXsp8Eee5VMbKUXddZ4/H+H6hHQrpG1IgJZbo kis1kb6rO7ZvHMsrcpk2aJ3SepZLBHmQtsv1q8j5I3PowejXUYPLiu4/OcAL
V+OquFiUFwZaxw2ic4qptl3gJwNBQgMMwc+rlS/6HspJaD1u0SabNtvloLjU Wa63ISv4LnSAh6DzZYCXBkZoSCAQkiliUPv0FbEkycVIp+Qzl1AeZJJZuJHy
23lSVlJw6EwXs72noqBcyqmX0BSGJQc5wbm1/KopD9jIdZdxZQCTC1S+ATPB oe5m0IX3IhibnRpOI4RaI7CztJYKo6LCdehbEY/Rzsa1khhpOCIk0OuLyh2+
d8lyCfvJth7ItUdJSkHrP3bW01BWKqL1IQGcgxNROHJFKIZAvOgoNaTFM6Zd JcNyIAb7NrDS95Q/u1F0mCZwMErediNXPsiCkSRvOcMnRSF/G/6inRWS1zwk
MXOn/dj3UZ8d/N/vHsp6SUChdS3CVDXROfBK9dH6VaekIjVNGHGiemmx1Ibb xUyt1JKVdG98wVhRCC7KQRvWaAxVtRjuslt4Ohx4EQ08coaRDCWjdvYOG9hL
yB+FgS84RC5gdI0jm5LRDfM1Chkdx3+dd359ykxLXooIYDNUzsAiQGwLzqwu jnOodsh+he8e3bv/+TOpQBJ6pyYoJ5kjxCHrTAs+ea06wNIm7uZNkVuNdDTX
fHKP4dPw/zSEcDoUjMgR6kdQ285ZRJnENrWDcgQ+o/KPCLkx4XK3UJ01yq7R LEm0wLQVdm82DSI5X5nV5y3h2QoYflufol7F4H50jCS+RieOP+pDePj4+euX
vx1LkzVJoEVPoaqYtlUWVbaY8YMMEKZYej4XOYqO1t0YicPeYtZIDw3nTinn VISiY6SQfm7C+LZxZ0VGeFFcRbbH4I5klyi8puzMUQmzTKny+pDfc2Z6shv8
lkZp5LzqZRViXk7pqkFAfel2vUXZE2GBmoQjbXqAlVuWKiYpktiZrjsKj61w j1JHjg4kl5VlvJHgvnLLM/JFDxIh40n5r7DgmXrMMHV1pPWCRfLMdnRIcqO2
yDv+YwNvkjERBMASUDZoKMbFyQTuGoh74zQdku/8G+gMEI5T7qYKctcUnVbP DMnk6lYRYf4OOuittk9qZtV1Q345l6M0986SlWeLYMgdJ68LvwYfxc6O1vFZ
CWmY1iUTPIFQQqgXrwowAOUr2mJZjtGIAzdN0iaYvfdIGVuGGkiX0Gwg00XD 1DRTLxHK1vaBKUSJFMg8wz/yiRto6WBKn2JQ4wGTeDc5X+ZYRcMl5wTrPxH1
xGVjm7a17pIVBwdzcYfMyy5EFg1gGw/LEkWkMsUhhNMmRycKntq2cKZDC9l9 bXB+mB5kJ59ib5dNPXOMx+ScJ2JICPYcLml6FyRZd4iNZZcTs7SXevgRXFwt
wjDAvjKarZKKRLWi7x2RccR0O9RsilHx50hIpMm9ULyNLpdmJsmmioa4ZVLm 5jRH5O7UXbzLoSlaMM1ffOnRnCaXXrSVbSZ0HNTN7SBzpwxE60iciGD9Eezr
64ZkkfON+jp4mozdMfXUhueaYSVBLAyAzXIrpEhslxicYd1asbFzLoFD3IuS Amz2vPYbuK9qj0KYpFeIRKwRh6T4iE48adcpyzIAlx3ABLGxkRIhQZSeAiqk
Yb4+GT8jCPLzogILYVzPx6cCn/Dby4qOj/QZ7iOd8aF0MZ9ecXLdmSD1NG+4 JUfvIy6qCFIlAJGq7JpVnOqifn7jMreJ6RRU4IV6U3EZaYVgPa9KMHzJn+xT
bJGpamblBcYXdNnKPhVTsr8oi2xbw/ljvU3IiaR7CgOc0BwbXl8ahwvwOovZ 9BPPFhlaiJah1BncVeZ1vTgyvNI2CdnL5DreBhJEXAHQrVkX7k3JqRODO1fK
yONiDXxXJRP5vEYO0+yUELugU5CyLw51Uxtyg/mNLLGSCQvMYYbfrOGyUQT3 BRcWBJ0dcWGuf39w95H9FRZjk2o3AQztT5VTrFPflnNCGnKFH39/h+75zk2K
JRDtckk7GNdvKJTacvN1YfOK6xRIduU1LsipHD9efpjJxXx98NNM2VJDloq/ p3yTdMEfw7+mxF49ui2TdLAfFFprpmok+h0Sdu6rFTpvotGewmYARf61D0m8
iMmR+hdS0IspZ9CuU34gQzeGRUZLAv76mmiXYLBhL2n9qymaEKK6+pyt3uCf Ojl9TS5l+9Sb0PBzRCztn7x5fqD9GTEGPOoHWPc1FdfM9kOx39tn4dtjcpjT
K5tuyH5ycuIpt13F/dCGMlm0FZSSaZRwMsH0/4ePeLDV0xRMXsZ5Ux1i8k2I 1e0vYE+bF23ccG3pdFK8M8gwezq6ZtNOJfJZMqKOAwoBl5qcCpGdJOSQC+ID
SM0ILa0DZ1J8BuCZHjseJn4TgN0g9hf19RhtVl5P2FCoAXIlySVP0dhHRFHB e6QSPZnWwFpuGhR7ijF02i2EB2k4Tdhsae+olfnwMxfvHvSBYaUL510lzTy/
rGZ2dEtQRlP5GIar+3G4GK7usZgeytZtBc/HM0IL5IjyZaHhfIpPiwoF09NM jcO8CgkUJ0n4WTo5LoSPGiSuC3E0UCcb78fiHdbW3YeUY0CjO/wWe7vVq/GZ
Q9n6wQtXIEU/mJEE7fBQ1LwsW/WnRkLjJd+Ak96qQ0JEhuENUgCBBpMvKbGv wMlX3lNl5WQI/WwYLoKbCz1g6wUh3gNyyQfVWRgRvTIG0OsVB9A52EOs0fGk
lOJZVT/0lR2aMBfc1Eh8YgPmc3afSlWAVAiZD7vmM1kGxeQQaLPALrsq/wH6 ScLmIPdYV/dY3N2SvMRE2+jGIryEHkfcavOA+vACwhNMOOsybaubwDexol1a
K2y6BSeClV5kcHm81vI9xo/R2+L5DZt7y57WalD/WJw+M1jMAwgukckTVPOi bU1b4jRLI/XhzkDHQSsXaEwNQpsDBWerZbFL2yXJZ2QkALXDpNlxIwwz8fY8
YxFH7TUaRzvQbiWPCKKPQSdlGUZB/IkIq4gPyWuqQaoZIR5Gt6b2L4iApipU /ULu5871WpAWbujN1Kg5CAWpVpxObV55RQCDmSC96J2+ooYM19gD8kNJW6E9
F0YqKj2imPDlJuqZ5lRig0jWILALMEIWHBamkVsiDapcn16WcEmGX4+DvaaP I0E0A66h3sc4EOEPQbLMDqtThwz1e0mGukBuOFiBz4s6YSLWXVDIQdMbUj3h
5CeSnZDkLnhd3XxRfFKqCeLl4aeABDHFhn9/Wvn1CuPtDMnyn01dtiM2Rkwz Oqp7CPOdQUdRiyHLUln8elEzzN/5yBzfw/T+3T+1JUpiWNidDLFWEZO0RCFN
+HX0xYxm4aiGVKvOLbgYme0CNcQ0X7FygN+FSmx/sHkAPKGRFRpHhsZLLFhX NRTEKOE3e6xfwo/bmWptpLOSuUEZxGQzoJ7YrHD4fJWh8Muos7nLyrnHCZY0
WJTNvqTP+FhgJoEAusEnY0gsei69Dl6mNaRj0l6QgMDnJYBqi6J2punHNkFm h8UyamlGkalXZvbE+vduK1sBx/BLYFoMQjHOthSXX2Q5vBz53CUjnWKOoljO
fkiZw7YOjl+YC8GTwVzzToH/B9MHZncDhkCz8R0d5cMC+A1MSM1xmxI6ZIig 2E9Gc0a32Jn1tNF2lLX09M04DXTdSFqMRfQZ1ljPien3gq8tg+48VhkRkNic
GWWPGd1D/gJh/RGjx1ChawgWLX3fAxcxvAiT+0EfJRAFU3T8A2Ev5dehb1xg ox8NdpvZ2xhBQYP7wd3vvsOsCB8USBcEXxJMyBTNS257p1tCiurow9qLTklR
deBmY3q5Vt7Ba67oBLlC0eDjwQdlIj2BuxK0LxqElG6ZGJIih4oZFBl+PZm0 0MDQKyYc8wGZkAzLZkKtpfZcUqZ1uLlDZIMKlkrXbDSPy0WkWwl/Fd9Twmhr
JKOjeG7DRHgicR/EGECd/jB4NQMjwMrxv0ab4Epo7cM8apkO6pGAC4g51ekR Vp28pN5Fnq1zKAsc6Jg4EZBtKj8fLHL02nj6EcbJXsHjQJF3Yni2nINbVHLT
CiaOij7udLdO+It37yjQy2HH22/09bdC4CSeggKiiNa1rVeXKEVclJWoFy7/ AoveTRyXhtoSyfR2U1uWIsYGhKQDeaK/mxT7p0RImPJ8RciPAz5D3mSDDUq4
oKo5PX8sEG06QMVsA0KBcY7li4DHsqMM/KlHT9dT9fwVdgjo/lgZCSm5lPaH GKHfrD/ApX/RNErNlu8hVuCsZx6YT93KPRd5h2A2OqLIdt6hSvwfcOvoycOJ
vHht2/IT95xh33S6SXxTVT+qwKVDDWpPvNrX2JUpZsTZeIlP1waHL2N/dpLF IjZwReLIvlTgjDHJsW9ttZS803v3ZV4Vg1OtSAWpMMi83kYsFswCwQWWJVwE
8SuQ1RkounoeUr6pd4D3L8o5gXjUknp3fPTm1avj18+Pn0fJLmdR8U1xwSgE mnoJ6tvGRD2pIhl3irYc7jefY3qm+ct88101xcMxvl8o6ULsiERJjQwuq/Gq
mYJjSuhlr4iwlcm6LN0N4cLi6VhhFK4L7laoBoiC/+IK0URZc5yT2QzKH6xy Ol/U5wbpR/kOCPyBY9P1gb8SNhTqY4jHXq89J0guIKIZw1WXHN9inz3xkg3o
jfGctjiQjWefk5WyyMGH0EQ2BdYYqWLdeq2TUlD18HvBVpU/b/5ti8aq0yc0 ac/pJKCJXs0OjkRUuZRzFYNsO5YddgvOrmUwT3kiR66/iBMWmH1mJRXcFowo
C02hEakApNaIpXNHSOfSgCGw8Yki61bToUaJyJg3GP17WzCpFShYUcLlXiMH JlUmnCxbGajUcmIpzbsf7mwgrey+iFaItuAcrIrKkW1CvgmqWIL7hiR6wcRc
fmI9F9rCoQ/ZtmRCgRfMAEZIxeWXnEkgJaFsaVyMT5EPvZQobsDBjNrIxWd3 ZvYoDQY6eoiy7d5///a+rJg4KjrXIXJWI62ZV6rdN8yKJXGpUcqIb9zvF0t+
qIxhDi+KcQyst8D2XES1G6q24zu42xqSBGos0mdMBpfM7tBeeZzJclr6RxMP u5siWFhag43kAnDYmMcpYWme01cIS9nP7LxJ7WN2motTRVifXJ4FbwJOyTfr
tM2vlaibXo+lOxLQELT4K22F+lZs5mRfXVJpmve7Y3KuRb5h9DFb23rMcHZO C4MecEEbkriWwFbHAlc5QVkJQtw5C2wT72lXkZCIM/dxlDGEZOI8cUclGBNi
gDKEaLIh56am5hWjoW/wfS0t+CJGT1h0TBT9UAp8ZU/3TV7tiMlw0JiFrzrG EpeKqRK8ixqhbJ2uU4Jy1qFxPAaSUy0945fcSyebfozEkq8xWqX3h3OnFO9L
zN4mS7ZFQVx0UUsSgVHwzOSG59z5ut/kIQSAtayVMPVvpWHJW2K2Q7BeU8pB nT9yf2VCGAl9MzvdhAeRpzxXBFzIU2vjOhlpVSLMK7OUYkkCx95005P3bY0d
IVZOMGOGcmpCVyaJcXTOMPvqtuHlohCgboQJbiAeB2ET2JvGZjxWX8sVCf2K 3/NDDgx7RmsQOI1QW6/IPm7jHGquIZlzsON0HZNV/SsID9gjp1y2HLZfW/Wa
L2opl1x57iM0PoEWDWbBLI+SwGR4G8fMNGBd9nnLwpDIs5MEVGAZN750Tt0v 3SfckppATUAJwi2hiLysQCuUcXTVsh6jZgcGnERqEEXgkTs2Xzbw86EuQfqM
aYTTlntBUX1n67dERCvF/QbQSQsWa8v0rqPIiEXXouYaxMheiCr5jCXAJwRV eqPr1lZf7dwFSxD2F+NBmdd9cF0aKDnenTVulZVJXSEEOZlAkX/W1nc1ldRI
vStlR3gSVVFQlFrDsMPr1Tut+5h+NPOc8kTcC/Wc7wrmPexPbvb53hxDIaJr GVRSPLKiUZeVUCjKF33viDQmJmajApGM2D9Dyh0NLoYsczTGNDJKilbUxR2T
Grnwi9JM8PVrzbT62hu9kFExIVsW6x2K99VgHC8E6R4+W1kIKRZTXJQYM+76 Mt+0tCc53qmvg9ak745ZCrc81wxxCRvDQOosD8QQIe4SPTSsnHIDlZykhygc
RbJYCO2RAHnU28sZCOLI4hH/RMhH1hM/gV8ITsXMFN+Q66jwd6M/tE1qaIWT ZU5++Wz8mGDRT6oVqAvjZj4+FSCHP2h283hHouHJ0znPh6z5KkvD/M54w6dl
7YBS7XYGyZhnNWZyBXxvUdzEmYbwbGdUtBy0kgi0iEtir2QeYavAsl0knERS y8mVTG02q8/R/6CLVw+p+5JzRrFsW+HV3/NdQmYnZc4YdIU6Wn6VqR8uwP4s
oNnA9kVzJrpaEzZoPwzBZ/c4/eynn+RNA0gYjKeiPTMsJu/J27CyXEVVBVx/ gqSM00nwXSuZzCcNkl4Xp4QiBvGC/K6xR9254wiHHKlmNfMrmLsNx6zutFEE
28v13m/jhhYlldamuGQQqx15yAQ082gnUw54PzxedWXGjuYL55+WBe8N7PIe QXaG9wnXMOet7ciEU/bHOI+CdrC8xoXdKneR30NM+2VGH0w4k1iFerN5iMn0
uIW10aStovnRLt3s0ukZKntRee6pflCTpLimXNpMfFwuXTc6rckWCKi90Zad hg+SU4z5yVDRUz45Q0+JaVBLQiP7FG6X4MLhRGmWrknqEGrT5ozV4GC6K/16
S5OJi9lym65AUxDFwpntDz75sl70BIWFOrCXnAidkdYVGrAeO1TcVYlnQXav CLhyDOSI66rjmehCMi+qDkrhR3DKmMPvX7xHhJUg5NNSbqmo5oQdEyJlC0Jw
HT9/XMeYZjoFXGipJYmzjwYRED5sIi2KRLds+3Oonxb/4R2MIQrrd8A/f4/2 a8e5Cg2DAk0xPA9dvw5Ub7IIFs3VGJVYXs/GVSgFSmVVJyPSqEvEqMEsmLZ3
/gdOCNE/sS+R/hnTnz/yP3a98tgLv/xj9t/Z7gxU/567uQexUSE3X5gMKP3z SxBJUxkMQ+h9P9x+lnslQOv6nYD+eEZogRyR1Cw0YkD+axGkoImaaag733lh
eaBz6ZfBC820C7jrd4MXDly/5cLPPcEYuvAPPGv4i0OU+/4VMq20np+fZnwU lyXHCBOooGIeUq+XdadG1khoH2UMOOmdWihEfRveIEkZqD35VBf7SknxDYSq
zMr8osmX6ZEAaqVbFD/uyLL7H7MI73xxW5O+QsqmXQMYrJLGr3zRp98Tzvux ZHPAxJ5z9UExlw240NlzKpkKksFkBnbFN7N0irksUIOBU3ZZ/w3kVzh0C447
VGos/CAUTlJoAzf4FvJP3vpsFBB7vek3hhom5BjIscS+puKxJJbZACDehrOF KxtKdnm81OI+wH56iuYXz2843DvOtGas+mZx+kxn4dpygpNkrgeVvGhnxF59
5VlYncuFzd8NaffQJzpyp/B47qMmX5R/Gz6gL5tmfEm/TM5mjdYWjPtS2xlj 9dXRCbRHyeOSaDBosyxDL4jBkFjzoqvyijKkGkauh94J3dum50xZF3oqIj1i
LBwuZOZlJX9Dd+0qrkYSiOTWc5iTUUpTr8szFqKTRcwrOEFwGXWkS00mc+Iz xPApMGqqlpT6QwEav2EXoIos2G1MPbe8H5RfP72o4ZECR09BKhwjN0jKQhLa
Y7N0et72Wt8afVv98i5oiD1T8iORRnWoWQ1K6gNPBPOeLS0HQZ+D6/DOkAJo 4GV180X1UYkxiEWIG4ENxIQg/vVpYtoLdMczMsyPuqZaIZa8F6MQfhl9tqVZ
RICTCJ2PZwpSOPlGSyx3I7+/bXDo+WRFREynjKF+wtTpsjf84pNwMnmOdQHk N0py1dR4i3dGFrBAZDEt1ywb4LuQLu7vNY/LJ4C0R+mRtoFBqveForNseCZt
B6gOy0WE+LWimsRpk74tjgE8l9yyyruow8PTgA/pznAxI4rd7oAE7aXOVDw2 5UOFoQZCDQcbjTG6aMcMam2ais6OOd5hCwT2R0F5W2i3MyW2du1kJhSWWeya
2dszObX0aHJpKTiOLf2Of+u0wj//CydWtitytBf/GlTv1hEN/unDhL/ufv5z YAiG2RBYG8w2HxX4P9B/YH63oAm0W1+GWQYWMHigSWos3WT4IZEFzSlb0Ggs
y8lm/qRHrT9Uxrecsulc3W0092+9FKb4vvnBvziN/OfOlsDW0dx1Gu2fO9sN 8giEpUi0HlM8Q92zqPL7avYIKka03vfalIAhTF709wQFla9DhddAPsFlQfVx
2+7/SnPiDo/5uvvvZnzc6UnqnX39/V4Mt16xqz6RdgtaoFGwN2zrhNNVzZy+ TQmE11zSFXKJm4PvB++miQQFHksQv6gVUjxmYkiVHEpmkGQ4etJsaZeO4rkN
ipXfB3snQcMo2ns2gMhnLnkpSUaT47wGNW33iE8zbUklYoxToX7yINB73HAM E+ELT3inRgYE+332aYZggJrjv0al4FIKoYR51PwhFCQBfxDX4KAmFNscZaPc
C87UDgp9ZXIBBMXsT0ER910zrClLwhMcRQITolytFwqP6JeGMGsjWV2Gi8ep 6tc64T+9eUNOYHZI3vxDnyIshFNiMCgIi4jAu2Z9gbuIM8USAcN5KZTKpxeQ
s6x42FqbyPiwgHQ29kgR0+gmPmSsdRkw8FwJNN8yqpTLcplflFURnxwcWc8X BcBNM8T91kFkSRWJ8gFx0HKiDNxqQKk3kPU8CtsFtILsHgkxu5SmiIx6LZD2
sec6GG9JPdcdn230jjU8kMWkmN3VFTa+7KEetsKyd1lwARgmjchO/fs6XyhZ I9d3YxN1uk1MVBVAKsGlGhzKT3zaJ/4xticyPJz1n/iIbrD8CjZsJ0Xs0YLd
pDQfDZj4iEVUTn9OmPHhHU07Qmso5pR671HgiEf5CrHDCobZFjoim2y8NJdu OgNh18xDVDg1EPD3i3pOgCFVpt48PXn14sXTl0+ePoniYc7C9NvqnLEOMglP
sVN79SBsfVJuqiOXwBs/gw3IbF/nAVPUCBDOUqDysiktF3j90tLjy1AsHsHB KeZXvCCOb6YXs7w8hESLJ2SNfrk+WF0hQSEKDYg1RFNlNXKOd3OWQDYBN8aT
bquRzwwrgv+IPLOFAwPD7RE2SDMVzjQMFF8R/vt8fXHhaZkwlG7B6jkxJqb7 2pxF1p992FayNbON0ES2FaY/+QJyu551kqGqpv7AAas70GuAuzy0avcJF0Rb
aOg9XQQzctsMd7bxyBDIp50PxYU9XZ9TTpIZdpif3iFmr+givDrFmDhsFiKX qYcqEEqoD9O5E+SdaUEX2PowkrWv6VqjWGVMNY+Gvs3j1MQYTHPhTLSRA1Ox
0X6aZC9zghITqpbap624iUNvnljhcLdn6okVU9f7BBj4aKHknI1iHmEmI6Sv mQvXYm4gu5ZMSPuCKsBYrDgrlCMMS8vVy4wB5ALRR4mLB2zMqIxrcn+bhB3m
GSgXj5oWRtT35ivfnv4iQbRASxCVxWurQvYT4bdwR3aOvBENb2/v5XBkikC2 HSN3R2bFBSjoIn72kFIe/4LrnCKxoXonfTQlu2j2jA5y90wU1LJWGheh+DYc
vag+0xnGc8UZ7XJBYCDF3ckbCC0dWvLc9MzA2m3SVMoxSBF0JxqDdHnBnSNC p3VzeQd6PWYUiWdDgOsvtHC54nCSk3VBWXPe+I4JxRbllnlFWeXWq4ajd4Qc
TbBXcu3Ed67OskFr+wYTG/+ImX0nS8AgGlEB00re1YTozeRdb1STA6zN6Cut cEI6bFSctqGCR6PcGHyxaYvQiCEWFkITuUC0aIoW3fAl2W2PSXlQx4VPh8bI
Adk3CclkDa+gf34gTMaHAGcBW6Xgu2Yf4AF7/t745wMjHd9qARsTfus1dzHW 37ZIDkZF/HlJIStBW/DclKY+hvMpyUkzBLu1XJtYblzKXL0mPj6EBra1XBei
72LtJh+75YK7fv7Q7fGVt/kL9s/tM3Xrny1RtDuPoG5usFe3//l3/RT9M5lM 6wRlJhtxey80axI8RysNI7RuFzov8gjqcZjgMeKeEIiBzWos42altjyRMMX4
/sX71U7/itv9bvEGd7dot9oKanW/khwMGhba2QYvWkShodT4lqJatnwX5T+0 XBuQ9ZQW7101PrQWdWbB7JQS4mQoHTvQ1I9dD2nWQpfIxJPQVChPYYzqkqpQ
WNscgxoNCgr6ipF95xsXaWw9mCg9a6iOmALSG/lRMJM4Q/GI8GluoQ5NTuFe Uw+nHVcRpATUzh+LiAWLS9UoZ7lPTEVq2lGkzKKR0XCCZKQ3RGmGRiPge4JS
hJTjgzHkgDCi1Wrd+T466V1u9xiNj2I2+Lj0pNwL1W/khWA/KQJKgBETv3pM 8pVdJLRESR3ktlavbH69Mrf2MK8AFT6nVBZfhYTTNxUzNg6nt/j0FZYkFVjq
+5IpoBErYe0gPUQJU53aPmjnn5ezdjvVINxGgwkurxw1XOPIh/M6YdbGtLl4 uJUHPysTBj+/0UisTwjSBxlAE+JosfQh118DavJCcPZh4MqfSG6Z6rxGJ3Kf
LUMUa1zpBYbPSnq2E2dLv7DnEBsWNPBjuKtTMhelFYmRr7iILhxuyepIAGyH y+PFbG2PGCijypDOgAJHFiH4R0Jasrz4EaxEMDBmJh+IDEk5VOZXTkuWhzJq
5YV6WxoSRQ04Loo52yBSGhrZrlfrRSV93DlxyuXUa9/tLdRyJlY4L/BbbjR1 xR4I134vS+M/azDOK+B/ix8nmjeEhTsjquXKlSChRTMS8ybzIFtBVuwjWSZy
iA3N/KgjkzxatjGccj4wn1LxEAljuDzbIlTEsuUJDUMKETfdtMnnVJTKw5I9 GM0yRxgVm+hpjeWgJpED7B5wcNovAO059Sahf57yCU23mGuo7MLacmrXKuQU
Rvy0xSeUF8ytI48qUZlIoFze5+pGNy5B+xeYOzcVitSqm6AD9PCnzv0OrTLE dINI8J0urodUU+7vYOfivt+TZiYgo0d7ZCRER4PXXasqRDOGK0ALg78NxUk8
phMPyCpuXvom4X/iUVCBOHPw+u5Qnnc3M4DSkV0yGqUURrHYXweyoDe7r/7n zgsTuElmRTMkoU4x8PQ2lROpZVIouVFDqLiqnH9NFGIuXTm6t0krCCC/0Y7z
d6/3hE2XksnwpFdaKhH3qLyBRwqF67XcBQ/QJhfpNpHP9pGEGz5Z0JHTeoW5 S9OJy9lxmcfAphC5xpmiEIZ80SwGW4W3dSBYeSb8S5r0aLB9bF5xTT6eBTnB
Uw9yId6skcvi2hv6oBRKlMCuIl8k5xVyWV8qz5WShyFcdJ0Z18DX43DgYwXN tv88uJ5R1HQXuFCQUeJpHwxiIAxswuXtRLzs+jvWkcV/fITRX2H2BP7zt6j6
8pId6bynJKiI0ntW+PTX/HniIlI7F0Nj+n7bl5hsJ37xm93X//O7l3vg3S2Z v+MgEf0Ta9rp35j+fuB/7Hv5cRC+/KH492J/BvL/wLmdfQod8K/d/Zd0KP37
6gce4+Px8NXw+9/Dr5Ej5rqcIcFsjMliwlTEoY2XxBuQ4xP0qS2dQLonwpux lCka/jn7oJl1QYH9Jvtg5vkdD34a7Ivcg7/jWcMvjnHbD5+QacXl/HRU8GUw
/yKmpOAMET4RXvqkg9QtB02g+yfHI50x7C6vhxa5qgSDHvHFszXjnQrrrdId q8vztlymlwKIlX5R/X4vf6nswZ2xEwWkLHJadIZ+cZSl6HDekKXUZ2EuIX+S
XG0tRZybzNdH6Xu2cNRSV27dYC0KINYNCLFrpIq0WjcuYfWYPC3X6VHPYT/D Yh1GUr1CrF0BiII2QMVOTIFKFCohykB2JZYQF4MlUcoyqHvr0BZaaqGhrhc2
k8PXh71ehtiKgTpnarQAD1w/EchJlb0Dbxakd+McPaFslX2HZx8pBCSiFeDs ipcT6ViHzidCBGsKb+UhpvKn+q/5e/mibccX9GVyJau/tmJImCrO6GRhfyFT
MC7PjI4hCG2W18izqNVo/JrdqGNRKHPaY/z28Jm4++DTvHgwkzbH2Y7UG+8g RStBHVprl3Hyk+Anr7l+OSCl9Pq6QGMhYVlUgzrpbxsuY5rqS+ayZ5ppLlN/
T8F6WSkgHRlIuL/SDtbevHj3bpQdH++Msp3n2N76DRxY/ha+Ntt5LYGpnXe6 zaslH9ftzKreB9lwYHKMxOGoVjXLPwmB4FVg3rSjVi0IcrAe3hiyAnULcDCh
isXMXkT1AXDdn4t2hwoPBm1yGN/swQMdHx18N44RB7gzopHePLRtw/JjCmE1 925NQRQno7QUeDfUJrC1cT3/rWyViGFrWFSVlaLhEKqPwhnl6eEFvB9QPLxD
+my6tutd+abiYAdIXsu0UxRdezHZ2SIbZL17mYCjklxu4nO+QTqIAQuuH9Es Imyw3bSJyzap+eUY2XPBBQ+9pbqrg+r7IdkZHmf0sdvP7KWDoVUV909O+kyu
aZxyd/9gf2+rjFDck17XbhcOO7E8Yb8k3+h2/rzD0DhUCDFvtZdA+0GMvB2H Lb2bXJqkjv1Lx/KPXFf490+4sop92U4H8dcge3f2KPs3BBR/2e/574arzfyl
RRyXYF/c9oFgtV5nOwHl6h+9E4SewjtwnSMZOE4aykm59S48Y2/bONsd0IiY d62/VcY3XLPpXN2uN3dufBSm+I754O+cRv67tSqwsze3nUb7d2vFYdfvv1Cf
SH8NT5HnCrQRM/FMed6mxSWg9ritABaFEHXhU/eU1Hx3XTOBRah/8Ngs/y3H uEUzX/b722kft2pJ7bMv/73fhjuf2FerSEvNLVBDOMgqO+GmVT1n5zUdFJ4E
wTjzVSeu/1vcxS5s6uw1HLT4ntd5oJfp3+WcEWS8/BDEdwcjdCDmPvLrec0E G6Ow8FkGus9E+JIPjerHWYMYn8gN76NOO2KL6PBUIKA0BXKPC1ZigppqRaE2
Mm2OxZbE8refM1ON6pmownXnhRI4E/MZk5uSmJREDsvFOXmo+sDXr4liGfH4 TikAoZijKojinHWGWWiJn4LdSaBS1OvNQgETuSwUZpgkPczwBTm1mRUy60u6
aLh1i01Ye7DnJHwqt0S8LXj/n3dCkfKpVJK27pDxHszIsH/ALTrf6Tmi6xIb ef8AupZrX9BpZsv1xJdNXHYwQOY5f2i+s2cp9+ayPK+JndbcII1UOIuN2B3u
1FymNTx/ptcb00q0NIkVse1s4b2lrYjeZLuig+jHHcL2Tjt0CUGyUvV9i1jj l9SI3fNhSG9lQ5O8parZ7e1iY9ge6+UrzIAXFSePYTyJNNj/3JQLJbeUKtYB
+dOuz/Hw0+P4NBr/O81LWInVxtO7sp9hLjw7hXs4STY3XYxDSgpTRRV8H4gt RB+xn4o2wLE0vsyj6UfYDbmhUmM+8iQx1PIFwowVKLPLl0R62nhpHt2hwQ7S
9r9H3wv3qvtLix0VMM79DcKs4e9i9tdkbzAVax3Ovv6n6kbbPKWQFU7y04yW SFgvpbBVT9Furw6FYpbxtKHTgz2SOSU1rhtlyMdstMsFNsI0+/ki5KxHYLGb
qakXXrQZtUwTDfJSNFrmGkYLQ81wrBo/eD94119kMv5qvDqNx0azWrbyHAaj UvULQ9Hgh1EWNs8g090Mg4TUhuEgRDZ1iwDjZ5vzc08jhX52i24viesxPVX5
ox6/AhsgJwi/FIe0ayS4KwW1wgigCswuZAEvuvFz9DzkKbsMY6SaZnXbKiJJ d/URFMntUutZ9yPtoJz23kMXznhzRmFLZgNipn2HuL6qjyDu5Hpib1pwaUYn
EC4An/yAAe5xCF0J79gv5+do02wtnsYSlhlRrs/WJC5oDKNPul6OsK8I1VAh a1I8x2TDEeNvqR7nmstRZGaLRRCsBPk86j6h4fcxMrDjQvY7q8vcx0L6yCDM
Sxi1LSu6qZ0emRPic5AyHCpBKIk7gslyy+K69V2MS+nWDdtQHiP1tVJI2lGD XOZ6VAw3IvI3I319+rP41wJPQpSjryVw2ZqEb+EXxRmSWbR81L0VxC4rguRm
SP4OUBXYOcdWuFok+XtL6efp5ZSK5F0hdNSm0V+vB5LxXhzXTvr6jh0qqQYJ 3P5MyBjPGIe+6wXBhhShJ+8gfHWoNXR9q4GD3ESzlCWRnOxOJAjJ+IprYYT8
3Empg0GqhcFbLyEd8Z68uZIqcz2+xdc5+c0ofem4Mag6L0082JHz+2rokBgZ Yi/2OlHC6S+niV+jfuOfqOC30hIM+BElMi3nbdWLwVTe9oeqjmARP/5kqP8O
cuamWBUknb7fkd3D9jh58OkB/BnB3/uH+4f498HhAf397eG39PfDw4f096PD 1UVSZ8Mr6J/vCL3xLgBfQI+p+Fezd9DAgf9t/Hmmp+MbtWOj3u985jaK/G00
R/T3d4ff0d/fH35Pfz8+fHw4cg8+PTl8Qv8+hD/497PDZ/T30eER/f388Dn9 4WSwOx647fBzP4+fvMmWsH83z9SNfztcbLfuQdNeo8vu/vtHbRj9m0wmf+fv
fXx4TH//dPjT4dDB8+749Pjdn46f946YP/c0rllpo0V/pqp31YaTbRpzPB6T VYf/gp/706LKeL/odmoOqpG/kADNj1j6Aw+qaCIgfcwWTRVzycyVOsD13zTt
94FG9ksy4sfkMbNnGcb1lt1gnOzP99ja52CRsTW+8EKHZSHfeYYIWfGiBYW6 21yH6i8KIvqSQYBnWxfJbL2eKIJrOJgmzBmiBkDk5yTGU7wkfCxciE+T2ziT
M2RumkAKEf8MZNjI3hJXQ1rZRCXbssbe9zGkBdt5+j3HNrV4RRIEmlm0il+C p8KexBibQHjS1XqjhYNzoWC3//4paiPVLN/k8NY8COlzZKlgqSzCVYBiE3dg
EXbCVcMkuxpX/EfR1OK9nxdqjm5z/d0wlfi+pKZzy4pNLYTAvB8NhMtYgVMo TMeTyawRWmF1I71QCYWd6kNoBZzVs243VSL8jHoTrGK5cDhNki/qTcIPjhF2
4Jjz0MORttEg3NBnmUiv7JSLRXGRLz748OSOAKPJ7lbSqkzb9fAqTmQEXK5+ sWvynHCcKgaqEDwp2MG+ySUFISEBksnW6LPslWVG+U5ivCwuqAvXXLJO4irb
klEpLKXVQCG99rivk3FnP4kb12b9uY/BndQ8iT58yr5hdjIJX0wvo+Q3TvXr 471D9TsNEaS6JxfVnHUSyTBNtNrLzQJ3rHD0U/o6ZmhvfFG7kBSaaOhMP/Sa
m79x6PN4DHf/xjd4DlyXrZDi9b6p/znEq0MfMQELeCWpmtLLxk0R2/ijsRAG y2gdY9023+9IXY8WbwxX3mdlZEp5gohGMjxe7NhdRAbmCRlDtBGP4LQt55Td
68bBJWbUZttT6E1+3ep4rpAVgcITcMTkEqD9z5Px88nH/B/ry1q5TYrZuK1K yt2SE0dcu9VH3DUYikc+WKZIYfe6vM81rR5jSglYYKjdJDri8lLIkxs/cu43
5N4ATcktyijsRoeSViCHbLdC5MvOUx0JsgBr/sTQdoY3JZjJTBr0DvQwAief qKUhpp34RdZJmVbZHMZ9zJy/mHXOjMK++pVnES4MEnVkl436KYlVvP2vApPR
5XBeg2I+umzQS4L1eYFtPpf5KHubg3ZCsOv0VV6tQbe/Ak1+CUbc26akyuDX q/0X//GblwfCDUyRZ2jphSZZxMU4r6W6wi32Un4HTWgBj/TAyNC93+HaYQu0
+NvT9WJRXuVgwr/CPH0FOq9etloH9jyHozV7VlR/wx7TDKFXViJsDgJygv1z ctqsMdTq0TFE7zXCUsqr1AeQYpASxFZkqZS8TtBORrKdKWsQ47/oSdOz7BxA
eG40Lar8S8ScCCMj4OTL+sK5P2a/+x0aO8czJIG+37LJ9LvfZW8XpFBhneor SzBiwcE850M3EBmUkeltL2z9JQ9QzEgqWGNIWd/uGosJj+KYX+2//I/fPD8A
kRqtR/LEt2zN+PhyDk+bE7REi601xmsaTZ9Qzyhit4LvVCNdVAkHSNAtCrUQ +2/JVELQjPfiw7jh+9/C18hBc1XPkC43hnMx/auhJCixBWl13NG9pGcjvBnL
MA7mu592NXJRr9hDZP6uGVpF47Lo5mPMthSw4uP970DPZ78UxWqcIx3ybZc/ TWJAC24W4Svh5U+qZN1w/YQaBmSQpDN2VgVblYxZQlGP+OHZhqFSlbVn6Rec
wsvBQ8iOjk4PHhwcBJXKBU3rJTUu3b336Nsne7c97OHXvftbvJznHo2Fckkt vi3poNvC51fpe3Yw7uJklnrMOtyCmHcgFLWRSNLU3zgh1gP6NN1nwJGHVRuf
K2UT3HzrAQ2b9ALWiPlAVxofg3HvP9zDi0/46Vu3JtlNzMMFNz34lm46WuRU Hb88HlRsxPISVChUPQp4DfuJQNqs4g1YurB/t85RC4h1Qy4CFekBAg+d8STv
h8FY4NhkYpqN3XsPnzyma48/rXIuZw8NiQSdRVbw0hcftnTXPt3F2b4xVe8Y 6JuQOoBub9gm07ztIf7w/2nsansTN4Lwd/8Ky/0Cko0gl7u8SKdqE7gm6oVE
Sjrh6wxaSFga4MbH/19hV9PTMAxD/wrS7lPSfLQ5ViBuXLmiCRBCGvQASPDv JGoVVVXlxG7jFkyEIeQuuv/emWdm12swKPmyCiz27uzuvO3MM3h22GlUZKqT
8XtO2qSt1EumdbWT2Y6T2LGtgLIxkGV90qSd2FuWIk6rOHSdOHOqEdieS34i pLoS/N0uH8NO//XvvJ91tSJZpLnLESMfrGalDWdnbBMpIBVx6s7FZBKHo1EU
IJON0Mn3A9sgbTD53yxsWbhCCLzlB0IkQic+SZFtIg4Dy5B8Wn7zbBV7j9Ya h9GQC3pfk+RyP5G+YTRW71U0sYuYZ34nZBdQv/sISQttWjqGl/X7dngQgHuH
tvZQoCyG8jC1pW7maMSsbMvOAaPzyrfxisBMMDqnk5Cfos90u15+N3KSL19p yOOLYgx0/8h2jUqHVDveMGf0XG71uy7FDUK7rhJIK2D0XfSiHfsC6rzbDyQu
1haBpeblHMwmHGLoG6HAnftVjki1rDLWcXp7fwZQb9b0/GgJGknKSCLGju0x YYYDmXpzZwBSizrFoIxzYnYGB4Pu5gYBUQI8/F1bwienkOlXO7egpoFE0TET
YQwJAwcFRtHkucQ42oQKN8UugO46dtG5ihjYIv58X2rFvhVFgJLdPqngUqCF aCJvu43oT0RCdZN67ZKCdIvWiZHSupZldOGw9TO94cPPQ311+zvFqJGj3aFn
DOvFcRzvarkXOMd/6LvMGjh7cW+egbZYwdpkZ2Sj8qoKz17XG6v9LZo5c9/1 dHcN0CcGShP3wjE9Tz/zq0CDwTcPI7E6KZDAeSQ4bqfBKVj7cj0XFIw6ZcKF
gNEIQmuqzqvc2bkS0YuouT/e1mHCB0RFPbGG7J4rBzds4F/RaGI499ABhNzb cLkpjWrVzCWqBNvf8mEmTutIOiYBy+8ZpzVazfavgsDbvtzd8IKxz442t/MJ
oBIyO9nKIf22HITkVaMEfMxx3MtL53JcOuvaQp8jkTsgD7GF24YDV51Y1RLM O6y0ot6Bv0sd6PAXVGr28lcdtlUtMB9yCzztQJn0ABRAsJVsnrROE+GXrwAN
37m4LubSjfkgCOHBy5s5v5LRjhx0FB2XyE3Ka+DzEI7k1STgv8fyCMcXPdOl zeH7rLItp98slBk/w6hL1fvJfVRnM99qumkVGIkDEQyHwYFUG51YYWEXoqk/
mA5MKyeXlEGc65ojTT0QKpu6Fc+nTb39jzrjr2oTVH0rLKmMg4Kyh0Zys7r8 SzJXO8G8knUCRVGBaiXQenbg8eL4sSFZPUPafI4Q+/u4ZGuQ9tEmu37HlmZB
bKq/f+Xc9VWeHozCNjOcOZd2a3ZXUccCRp3oBplT/8MMB+yehAEA U60eWMpZuXvbmMPEnnN/j9qC2h09xEQPh2kRHPY2TjQ687A2Mlj1/B/VcBiD
Iza5+IAGfEDTLNuSSAIIO98/P3ugvp3CTcXkPQ2xQIv51O1iiWYGiWlz5Aub
BVuPkQYY8gitz+Cu9Vd/KAn+9Ew464ht0LKo9DkSps6s+oVEfIrwfk0cqVaM
j1doSIuEB5WkVTFUeb5Mhmxg6FM6EtiIlGdrn5VAUlDAAHf/QQPsiv/c4uWJ
MS7PsSXAbW41p7dkwIXPVtgkrO2yAbqaxVwKBRlWjC+Gamv58tEnj9IEoA+a
pIP0hKJMsvxZQHuLfF25UsyF1h6nA6iP0fRbzTNdosKlzIP4Ahf88RNg/Qjz
Ox8R0KHTWdiSSa4A2V6dwq3STZ6JEkhupcv9iJBxTXsw2oQwpr2suOK2C7jD
HYy2Aom7LujFZUG5I6jl9KSyqbVOFs3BBu4wtYmD2MOJXuTPItVclSb/4PqC
o//ap7+Y2oEZGG4PzAHaD+YD2kNziPaj+Yj2k/mE9sgcoT02xyYO+q8n5gT/
G/rj9sycoT0352iHZoh2ZEZov5gvpk3ETEa3o8lvo+GWMLnfYLV8Lk+OD088
zqmpncoBdzHJJElgVbDy/BXKeXLH9rAA+NcjuhEjl8n89pNo8eIS8vSJH7LC
9YLAMs44VFZtZA1Hjdo0Sc9VAnSglrs1aFVqQmjZnUYqt66us2k8MIN95QMc
1DfK0zI8AqjKKu9XUrUuJaEY29b6Eb/ni7na5g+5VTZ3mfbBLkzzgV5Ppz40
N0oeke4etzjGhHvD1B/JTXS7Ty1uDUR0N0tgKhEpVfk/6fQv55CMNEoaerXF
twptcSFZyZ6OQFLZL0NkyeIyjbjR2EWBXSZLf0pSdjdso38z8BPlnjD1R7H8
wstePWe8DtffTO7x/lm2TVBG8f5ZXrMYWBeVYultzaptQkDfwTR6pPQ+6/1M
4XbIfh9tc+KcIcOp5WT0SlQnn2PZYnn2OQKWmHN813x+ka4rO84XxlKAU4Ik
T6pO2p8vk2Hvv/T76mluEVHyLKnKghE7iINKwTU43SCrbNpyfQtug3iLpYNJ
0pgDThNUVTvw0FZqRVkAh95IcSQWzZGWZylJ8uoHv5s+PX9asMlEC3jB1Utn
qf3iJiVOxvGyj1dpuUJ/4hFvV8T2n0jVu1kwSITtPOaet6vptHhJS/vhFV/w
lySV57NqLp8yzembYUqCOTzLy3+5xDZ9IzH5FvsoKGasY3O1IKGivUy1KE/s
gfsf7+AAGaKTAQA=
--> -->
</rfc> </rfc>
 End of changes. 335 change blocks. 
1971 lines changed or deleted 1567 lines changed or added

This html diff was produced by rfcdiff 1.48.