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.29 (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 initials="K." surname="Oku" fullname="Kazuho Oku">
<organization>Fastly</organization> <organization>Fastly</organization>
<address> <address>
<email>kazuhooku@gmail.com</email> <email>kazuhooku@gmail.com</email>
skipping to change at line 39 skipping to change at line 40
<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>Cloudflare</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="2025" month="November"/>
<area>SEC</area> <area>SEC</area>
<workgroup>tls</workgroup> <workgroup>tls</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<?line 67?> <?line 107?>
<!-- [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>.
b) RFC 6125 has been obsoleted by RFC 9525. May we replace RFC 6125
with RFC 9525?
c) Informative Reference RFC 5077 has been obsoleted by RFC 8446. We
recommend replacing RFC 5077 with RFC 8446. However, if RFC 5077 must be
referenced, we suggest mentioning RFC 8446 (e.g., RFC 5077 has been obsoleted
by RFC 8446). See Section 4.8.6 in the RFC Style Guide (RFC 7322).
d) FYI, RFCYYY1 (draft-ietf-tls-svcb-ech) will be updated during the XML stage.
-->
<!-- [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 ClientHello 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 146?>
<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 ClientHello messages, which leaks the target
domain for a given connection, is perhaps the most sensitive information domain for a given connection, is perhaps the most sensitive information
left unencrypted in TLS 1.3.</t> left unencrypted in TLS 1.3.</t>
<t>This document specifies a new TLS extension, called Encrypted Client He <t>This document specifies a new TLS extension called Encrypted Client Hel
llo lo
(ECH), that allows clients to encrypt their ClientHello to the TLS server. (ECH) that allows clients to encrypt their ClientHello to the TLS server.
This protects the SNI and other potentially sensitive fields, such as the This protects the SNI and other potentially sensitive fields, such as the
Application Layer Protocol Negotiation (ALPN) Application-Layer Protocol Negotiation (ALPN) list <xref target="RFC7301"/>. Co-
list <xref target="RFC7301"/>. Co-located servers with consistent externally vis located servers with consistent externally visible TLS
ible TLS
configurations and behavior, including supported versions and cipher suites 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.
skipping to change at line 149 skipping to change at line 177
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 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 ClientHello, referred to as the ClientHelloInner.
The client then constructs a public ClientHello, referred to as the The client then constructs a public ClientHello, referred to as the
ClientHelloOuter. The ClientHelloOuter contains innocuous values for ClientHelloOuter. The ClientHelloOuter contains innocuous values 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 loInner. (<xref target="encrypted-client-hello"/>), which carries the encrypted ClientHel loInner.
Finally, the client sends ClientHelloOuter to the server.</t> Finally, the client sends ClientHelloOuter to the server.</t>
skipping to change at line 198 skipping to change at line 226
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 269
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 ECHConfig.</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> ECHConfigContents.</t>
</dd> </dd>
<dt>maximum_name_length</dt> <dt>maximum_name_length:</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 ClientHello message. Each ECHConfigExtension
has a 2-octet type and opaque data value, where the data value is encoded has a 2-octet type and opaque data value, where the data value is encoded
with a 2-octet integer representing the length of the data, in network byte with a 2-octet integer representing the length of the data, in network byte
order. ECHConfigExtension values are described below (<xref 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>config_id:</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 ClientHello encryption. <xref target="confi g-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>public_key:</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 ClientHelloInner. </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 encrypting <t>The list of HPKE Key Derivation Function (KDF) and Authenticated En cryption with Associated Data (AEAD) identifier pairs clients can use for encryp ting
ClientHelloInner. See <xref target="real-ech"/> for how clients choose from this list.</t> ClientHelloInner. 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 ECHConfig values with corre sponding
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 ClientHello. This can impact performance when the client-facing server maintains
many known ECHConfig values. To avoid this, the client-facing server SHOULD many known ECHConfig values. To avoid this, the client-facing server SHOULD
allocate distinct <tt>config_id</tt> values for each ECHConfig in its known set. The allocate distinct <tt>config_id</tt> values for each ECHConfig in its known 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 ECHConfig.</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
skipping to change at line 364 skipping to change at line 392
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 D be <t>Any future information or hints that influence ClientHelloOuter SHOUL D be
specified as ECHConfig extensions. This is primarily because the outer specified as ECHConfig extensions. This is primarily because the outer
ClientHello exists only in support of ECH. Namely, it is both an envelope for ClientHello exists only in support of ECH. Namely, it is both an envelope for
the encrypted inner ClientHello and enabler for authenticated key mismatch the encrypted inner ClientHello and an enabler for authenticated key mismatch
signals (see <xref target="server-behavior"/>). In contrast, the inner ClientHel lo is the signals (see <xref target="server-behavior"/>). In contrast, the inner ClientHel lo is the
true ClientHello used upon ECH negotiation.</t> true ClientHello 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 ClientHelloOuter. When it does, it MUST also send the extension in
ClientHelloInner.</t> ClientHelloInner.</t>
<artwork><![CDATA[ <artwork><![CDATA[
skipping to change at line 402 skipping to change at line 430
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 ClientHello. The outer extension has the following
fields:</t> fields:</t>
<dl> <dl>
<dt>config_id</dt> <dt>config_id:</dt>
<dd> <dd>
<t>The ECHConfigContents.key_config.config_id for the chosen ECHConfig .</t> <t>The ECHConfigContents.key_config.config_id for the chosen ECHConfig .</t>
</dd> </dd>
<dt>cipher_suite</dt> <dt>cipher_suite:</dt>
<dd> <dd>
<t>The cipher suite used to encrypt ClientHelloInner. This MUST match a value <t>The cipher suite used to encrypt ClientHelloInner. This MUST match a value
provided in the corresponding <tt>ECHConfigContents.cipher_suites</tt> list.</t> provided in the corresponding <tt>ECHConfigContents.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 ding <t>The HPKE encapsulated key used by servers to decrypt the correspond ing
<tt>payload</tt> field. This field is empty in a ClientHelloOuter sent in respon se to <tt>payload</tt> field. This field is empty in a ClientHelloOuter sent in respon se 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 EncodedClientHelloInner structure, enc rypted
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[ <artwork><![CDATA[
struct { struct {
ECHConfigList retry_configs; ECHConfigList retry_configs;
} ECHEncryptedExtensions; } ECHEncryptedExtensions;
]]></artwork> ]]></artwork>
<t>The response is valid only when the server used the ClientHelloOuter. I f the <t>The response is valid only when the server used the ClientHelloOuter. I f 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 ECHConfigList structure containing one or more ECHConfig structu res, 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[ <artwork><![CDATA[
skipping to change at line 459 skipping to change at line 487
} ECHHelloRetryRequest; } ECHHelloRetryRequest;
]]></artwork> ]]></artwork>
<t>The value of ECHHelloRetryRequest.confirmation is set to <t>The value of ECHHelloRetryRequest.confirmation is set to
<tt>hrr_accept_confirmation</tt> as described in <xref 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 lloInner <t>Before encrypting, the client pads and optionally compresses ClientHe lloInner
into a EncodedClientHelloInner structure, defined below:</t> into an EncodedClientHelloInner structure, defined below:</t>
<artwork><![CDATA[ <artwork><![CDATA[
struct { struct {
ClientHello client_hello; ClientHello client_hello;
uint8 zeros[length_of_padding]; uint8 zeros[length_of_padding];
} EncodedClientHelloInner; } EncodedClientHelloInner;
]]></artwork> ]]></artwork>
<t>The <tt>client_hello</tt> field is computed by first making a copy of ClientHelloInner <t>The <tt>client_hello</tt> field is computed by first making a copy of ClientHelloInner
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 mat="of" target="RFC8446"/>. field uses the ClientHello structure defined in <xref section="4.1.2" sectionFor mat="of" target="RFC8446"/>.
In DTLS, it uses the ClientHello structured defined in In DTLS, it uses the ClientHello structured defined in
skipping to change at line 492 skipping to change at line 520
} ExtensionType; } ExtensionType;
ExtensionType OuterExtensions<2..254>; ExtensionType OuterExtensions<2..254>;
]]></artwork> ]]></artwork>
<t>OuterExtensions contains the removed ExtensionType values. Each value references <t>OuterExtensions contains the removed ExtensionType values. Each value references
the matching extension in ClientHelloOuter. The values MUST be ordered the matching extension in ClientHelloOuter. The values MUST be ordered
contiguously in ClientHelloInner, and the "ech_outer_extensions" extension MUST contiguously in ClientHelloInner, and the "ech_outer_extensions" extension MUST
be inserted in the corresponding position in EncodedClientHelloInner. be inserted in the corresponding position in EncodedClientHelloInner.
Additionally, the extensions MUST appear in ClientHelloOuter in the same Additionally, the extensions MUST appear in ClientHelloOuter in the same
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 ClientHelloOu
contains extensions A, D, B, C, E, F.</t> ter
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 EncodedClientHelloInner and MUST NOT appear in either ClientHelloOuter or
ClientHelloInner.</t> ClientHelloInner.</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 process. <t>The client-facing server computes ClientHelloInner by reversing this process.
First it parses EncodedClientHelloInner, interpreting all bytes after First, it parses EncodedClientHelloInner, 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 e <t>Next, it makes a copy of the <tt>client_hello</tt> field and copies t he
<tt>legacy_session_id</tt> field from ClientHelloOuter. It then looks for an <tt>legacy_session_id</tt> field from ClientHelloOuter. It then looks for 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 ClientHelloOuter. The server MUST
abort the connection with an "illegal_parameter" alert if any of the following abort the connection with an "illegal_parameter" alert if any of the following
are true:</t> are true:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Any referenced extension is missing in ClientHelloOuter.</t> <t>Any referenced extension is missing in ClientHelloOuter.</t>
</li> </li>
<li> <li>
skipping to change at line 526 skipping to change at line 554
</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 ClientHelloOuter corresponding to those in Oute rExtensions
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 ClientHelloOuter which decompresses to a much larger
ClientHelloInner. This is discussed further in <xref target="decompression-amp"/ >.</t> ClientHelloInner. This is discussed further in <xref target="decompression-amp"/ >.</t>
<t>Implementations SHOULD construct the ClientHelloInner in linear <t>Implementations SHOULD construct the ClientHelloInner 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 lloOuter (see <xref target="flow-clienthello-malleability"/>), ECH authenticates ClientHe lloOuter
by passing ClientHelloOuterAAD as the associated data for HPKE sealing by passing ClientHelloOuterAAD as the associated data for HPKE sealing
and opening operations. The ClientHelloOuterAAD is a serialized and opening operations. The ClientHelloOuterAAD is a serialized
skipping to change at line 552 skipping to change at line 580
<xref section="5.3" sectionFormat="of" target="RFC9147"/> for DTLS, which matche s the ClientHelloOuter except <xref section="5.3" sectionFormat="of" target="RFC9147"/> for DTLS, which matche s the ClientHelloOuter 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 Handshake structure's four-byte header in TLS nor twelve-byte header in
DTLS.</t> DTLS.</t>
</section> </section>
</section> </section>
<section anchor="client-behavior"> <section anchor="client-behavior">
<name>Client Behavior</name> <name>Client Behavior</name>
<t>Clients that implement the ECH extension behave in one of two ways: 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 r type do not ECH extension, as described in <xref target="grease-ech"/>. Clients of the latte r type do not
negotiate ECH. Instead, they generate a dummy ECH extension that is ignored by negotiate ECH. Instead, they generate a dummy ECH extension that is ignored by
the server. (See <xref target="dont-stick-out"/> for an explanation.) The client offers ECH the server. (See <xref target="dont-stick-out"/> for an explanation.) The client offers ECH
if it is in possession of a compatible ECH configuration and sends GREASE ECH if it is in possession of a compatible ECH configuration and sends GREASE ECH
(see <xref target="grease-ech"/>) otherwise.</t> (see <xref target="grease-ech"/>) otherwise.</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 server's <t>To offer ECH, the client first chooses a suitable ECHConfig from the server's
ECHConfigList. To determine if a given <tt>ECHConfig</tt> is suitable, it checks that ECHConfigList. To determine if a given <tt>ECHConfig</tt> is suitable, it checks that
skipping to change at line 633 skipping to change at line 661
<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 lloInner, it <t>When the client offers the "pre_shared_key" extension in ClientHe lloInner, it
SHOULD also include a GREASE "pre_shared_key" extension in ClientHelloOuter, SHOULD also include a GREASE "pre_shared_key" extension in ClientHelloOuter,
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 Pre-Shared Key (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 ClientHelloInner into the ClientHelloOuter.</t>
</li> </li>
<li> <li>
<t>When the client offers the "early_data" extension in ClientHelloI nner, it <t>When the client offers the "early_data" extension in ClientHelloI nner, it
MUST also include the "early_data" extension in ClientHelloOuter. This MUST also include the "early_data" extension in ClientHelloOuter. This
allows servers that reject ECH and use ClientHelloOuter to safely ignore any allows servers that reject ECH and use ClientHelloOuter to safely ignore 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 ClientHelloOuter. See <xref target="outer-clienthello"/> for addi tional
guidance.</t> guidance.</t>
<t>Finally, the client encrypts the EncodedClientHelloInner with the abo ve values, <t>Finally, the client encrypts the EncodedClientHelloInner with the abo ve values,
as described in <xref target="encrypting-clienthello"/>, to construct a ClientHe lloOuter. It as described in <xref target="encrypting-clienthello"/>, to construct a ClientHe lloOuter. 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>enc</tt> value, <t>Given an EncodedClientHelloInner, an HPKE encryption context and <t t>enc</tt> value,
and a partial ClientHelloOuterAAD, the client constructs a ClientHelloOuter as and a partial ClientHelloOuterAAD, the client constructs a ClientHelloOuter 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 EncodedClie ntHelloInner
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 ClientHelloOuterAAD with
an "encrypted_client_hello" extension. This extension value contains the outer an "encrypted_client_hello" extension. This extension value contains the outer
skipping to change at line 696 skipping to change at line 724
]]></artwork> ]]></artwork>
<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 ClientHelloOuter. The two values have the same length, so it is not necessary
to recompute length prefixes in the serialized structure.</t> to recompute length prefixes in the serialized structure.</t>
<t>Note this construction requires the "encrypted_client_hello" be 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 ClientHelloOuter'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 ClientHelloOuter. However, the client can send a "pre_shared_key" extension
in the ClientHelloInner. In this case, when resuming a session with the client, in the ClientHelloInner. 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
skipping to change at line 726 skipping to change at line 754
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 ClientHelloInner is encrypted without padding, then the leng th 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 ClientHello 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
skipping to change at line 791 skipping to change at line 819
<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 it has a length other than 8, the client aborts 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 ClientHelloIn ner 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> ClientHelloOuter 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 Hello. That <t>The client behaves as if it had sent ClientHelloInner as the Client Hello. That
is, it evaluates the handshake using the ClientHelloInner's preferences, and, is, it evaluates the handshake using the ClientHelloInner'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> ClientHelloInner as the first ClientHello.</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> ClientHello message as follows:</t>
skipping to change at line 813 skipping to change at line 852
<t>It computes a second ClientHelloInner based on the first Client HelloInner, as <t>It computes a second ClientHelloInner based on the first Client HelloInner, as
in <xref section="4.1.4" sectionFormat="of" target="RFC8446"/>. The ClientHelloI nner's in <xref section="4.1.4" sectionFormat="of" target="RFC8446"/>. The ClientHelloI nner'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 EncodedClientHelloInner as described in <xref tar get="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 ClientHelloOuterAAD message. Thi s 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 ClientHelloOuter unmodified or omitted. If not sensitive, the client MAY
copy updated extensions from the second ClientHelloInner for compression.</t> copy updated extensions from the second ClientHelloInner for compression.</t>
</li> </li>
<li> <li>
<t>It encrypts EncodedClientHelloInner as described in <t>It encrypts EncodedClientHelloInner as described in
<xref target="encrypting-clienthello"/>, using the second partial ClientHelloOut erAAD, to <xref target="encrypting-clienthello"/>, using the second partial ClientHelloOut erAAD, to
obtain a second ClientHelloOuter. It reuses the original HPKE encryption obtain a second ClientHelloOuter. It reuses the original HPKE encryption
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
skipping to change at line 848 skipping to change at line 887
<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>Clients can implement a new transport connection in a way that best
suits their deployment. For example, clients can reuse the same server suits their deployment. For example, clients can reuse the same server
IP address when establishing the new transport connection or they can IP address when establishing the new transport connection or they can
choose to use a different IP address if provided with options from choose to use a different IP address if provided with options from
DNS. ECH does not mandate any specific implementation choices when DNS. ECH does not mandate any specific implementation choices when
establishing this new connection.</t> establishing this new connection.</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.,
skipping to change at line 887 skipping to change at line 926
client reached a node with configuration A in the first connection and client reached a node with configuration A in the first connection and
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 "server_name" extension instead (see <xref target="server-behavior"/>). Then, cl
that offer ients that offer
ECH then authenticate the connection with the public name, as follows:</t> ECH 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 ECHConfig.contents.public_name. If invalid, it MUST abort the connection with
the appropriate alert.</t> the appropriate alert.</t>
</li> </li>
<li> <li>
<t>If the server requests a client certificate, the client MUST 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>
skipping to change at line 916 skipping to change at line 955
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> ECHConfig</tt>. <t>Prior to attempting a connection, a client SHOULD validate the <tt> ECHConfig</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 ECHConfig sou rce
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 ated <xref target="RFCYYY1"/>. Clients MUST limit any sharing of persisted ECH-relate d
state to connections that use the same ECHConfig source. Otherwise, it state to connections that use the same ECHConfig 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 ECHConfig
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 ClientHello 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 to exercise all supported configurations, but MAY be
held constant for successive connections to the same server in the same held constant for successive connections to the same server in the same
session.</t> session.</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 EncodedClientHelloInner 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 ClientHello in response to a HelloRetryRequest, the
client copies the entire "encrypted_client_hello" extension from the first client copies the entire "encrypted_client_hello" extension from the first
ClientHello. The identical value will reveal to an observer that the value of ClientHello. The identical value will reveal to an observer that the value of
"encrypted_client_hello" was fake, but this only occurs if there is a "encrypted_client_hello" was fake, but this only occurs if there is a
HelloRetryRequest.</t> HelloRetryRequest.</t>
<t>If the server sends an "encrypted_client_hello" extension in either <t>If the server sends an "encrypted_client_hello" extension in either
HelloRetryRequest or EncryptedExtensions, the client MUST check the extension HelloRetryRequest or EncryptedExtensions, the client MUST check the extension
syntactically and abort the connection with a "decode_error" alert if it is syntactically and abort the connection with a "decode_error" alert if it is
invalid. It otherwise ignores the extension. It MUST NOT save the invalid. It otherwise ignores the extension. It MUST NOT save the
"retry_configs" value in EncryptedExtensions.</t> "retry_configs" value in EncryptedExtensions.</t>
<t>Offering a GREASE extension is not considered offering an encrypted ClientHello <t>Offering a GREASE extension is not considered offering an encrypted ClientHello
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 ClientHelloOuter 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 back-end 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> ClientHelloInner, 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>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
skipping to change at line 1074 skipping to change at line 1124
<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 <t>If <tt>ECHClientHello.type</tt> is not a valid <tt>ECHClientHelloType</ tt>, then
the server MUST abort with an "illegal_parameter" alert.</t> 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 ClientHello, 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 ClientHello to process, so even the client's TLS
version preferences may have changed.</t> version preferences may have changed.</t>
<t>First, the server collects a set of candidate ECHConfig values. This list is <t>First, the server collects a set of candidate ECHConfig values. 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 ECHClientHello.config_id against identifiers of each know n ECHConfig
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>
skipping to change at line 1118 skipping to change at line 1168
]]></artwork> ]]></artwork>
<t>ClientHelloOuterAAD is computed from ClientHelloOuter as described in <t>ClientHelloOuterAAD is computed from ClientHelloOuter 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 ECHConfig. If
decryption fails, the server continues to the next candidate ECHConfig. decryption fails, the server continues to the next candidate ECHConfig.
Otherwise, the server reconstructs ClientHelloInner from Otherwise, the server reconstructs ClientHelloInner from
EncodedClientHelloInner, as described in <xref target="encoding-inner"/>. It the n stops EncodedClientHelloInner, as described in <xref target="encoding-inner"/>. It the n stops
iterating over the candidate ECHConfig values.</t> iterating over the candidate ECHConfig values.</t>
<t>Once the server has chosen the correct ECHConfig, it MAY verify that the value <t>Once the server has chosen the correct ECHConfig, it MAY verify that the value
in the ClientHelloOuter "server_name" extension matches the value of in the ClientHelloOuter "server_name" extension matches the value of
ECHConfig.contents.public_name, and abort with an "illegal_parameter" alert if ECHConfig.contents.public_name and abort with an "illegal_parameter" alert 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 ECHConfig id or keypair is used in multiple ECHConfigs with distinct public
names.</t> names.</t>
<t>Upon determining the ClientHelloInner, the client-facing server check s that the <t>Upon determining the ClientHelloInner, the client-facing server check s 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 ClientHelloInner to the appropriate backend server, which proceeds as in
<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 ClientHelloOuter
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 ClientHelloInner. The client-facing server forwards all other TLS
messages between the client and backend server unmodified.</t> messages between the client and backend server unmodified.</t>
<t>Otherwise, if all candidate ECHConfig values fail to decrypt the exte nsion, the <t>Otherwise, if all candidate ECHConfig values fail to decrypt the exte nsion, 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 ClientHelloOuter 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 ECHConfig structures with up-to-date
skipping to change at line 1164 skipping to change at line 1214
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>Sending 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 ClientHelloOuter. Instead, it continues with the ECHConfig selection from the
first ClientHelloOuter as follows:</t> first ClientHelloOuter as follows:</t>
<t>If the client-facing server accepted ECH, it checks the second Clie ntHelloOuter <t>If the client-facing server accepted ECH, it checks that the second ClientHelloOuter
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 ECHClientHello.cipher_suite and ECHClientHello.config_id are unchanged, and that
ECHClientHello.enc is empty. If not, it MUST abort the handshake with an ECHClientHello.enc is empty. If not, it MUST abort the handshake with an
"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 ECHClientHello.payload as a second mes sage with the
previous HPKE context:</t> previous HPKE context:</t>
<artwork><![CDATA[ <artwork><![CDATA[
EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,
ECHClientHello.payload) ECHClientHello.payload)
skipping to change at line 1198 skipping to change at line 1248
second ClientHello's ECHClientHello.payload value, if there is one. second ClientHello's ECHClientHello.payload 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 ECHConfig structures with up-to-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 ClientHell o 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. </t> server to include any information it requires to process the second ClientHello. </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 ClientHello, if the backend server negotiates TLS 1.3 or higher, then it MUST
confirm ECH acceptance to the client by computing its ServerHello as described confirm ECH acceptance to the client by computing its ServerHello as described
here.</t> here.</t>
<t>The backend server embeds in ServerHello.random a string derived from the inner <t>The backend server embeds in ServerHello.random a string derived from the inner
handshake. It begins by computing its ServerHello as usual, except the last 8 handshake. It begins by computing its ServerHello as usual, except the last 8
bytes of ServerHello.random are set to zero. It then computes the transcript bytes of ServerHello.random are set to zero. It then computes the transcript
skipping to change at line 1267 skipping to change at line 1327
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 enges <t>Beyond coordination difficulties, ECH deployments may also induce chall enges
for use cases of information that ECH protects. In particular, for use cases 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 ClientHello, including the SNI. It MAY attempt to use another server from the
DNS results, if one is provided.</t> DNS results, if one is provided.</t>
<t>In order to ensure that the retry mechanism works successfully 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 ClientHello containing only parameters it understands. Thus,
when presenting a certificate to the client or sending a ClientHello to the when presenting a certificate to the client or sending a ClientHello to the
server, the proxy will act as if connecting to the ClientHelloOuter server, the proxy will act as if connecting to the ClientHelloOuter
server_name, which SHOULD match the public name (see <xref target="real-ech"/>), without 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 1434
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
skipping to change at line 1379 skipping to change at line 1468
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 ClientHelloInner.
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>
skipping to change at line 1419 skipping to change at line 1508
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 ECHConfig 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> ECHConfig values based on the ECHClientHello.config_id 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
skipping to change at line 1528 skipping to change at line 1617
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 ClientHelloInner. Implementations should take such side channels into
consideration when reasoning about the privacy properties that ECH provides.</t> consideration when reasoning about the privacy properties that ECH provides.</t>
</section> </section>
<section anchor="related-privacy-leaks"> <section anchor="related-privacy-leaks">
<name>Related Privacy Leaks</name> <name>Related Privacy Leaks</name>
<t>ECH requires encrypted DNS to be an effective privacy protection 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
skipping to change at line 1561 skipping to change at line 1647
HelloRetryRequest is unencrypted.This means differences in cookies between 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 ServerHello.random with a value derived from the ClientHelloInner.random. (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, ServerHello.random colliding with the ServerHello.random 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>
skipping to change at line 1589 skipping to change at line 1675
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 ServerHello.random are used to implem ent
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, and because <t>Since servers process either ClientHelloInner or ClientHelloOuter, and because
ClientHelloInner.random is encrypted, it is not possible for an attacker to "cut ClientHelloInner.random is encrypted, it is not possible for an attacker 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> ClientHelloInner.</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>
skipping to change at line 1637 skipping to change at line 1723
(<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 ECHConfigList used by the server .</t>
</li> </li>
<li> <li>
<t>The attacker keeps per-connection state only. In particular, it does not <t>The attacker keeps per-connection state only. In particular, it does not
track endpoints across connections.</t> track endpoints across connections.</t>
</li> </li>
skipping to change at line 1748 skipping to change at line 1834
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 ClientHello is "example.com," and
the attacker replied with a Certificate for "test.com". If the client produces a the attacker replied with a Certificate for "test.com". If the client produces a
verification failure alert because of the mismatch faster than it would due to verification failure alert because of the mismatch faster than it would due to
the Certificate signature validation, information about the name leaks. Note the Certificate signature validation, information about the name leaks. Note
that the attacker can also withhold the CertificateVerify message. In that that the attacker can also withhold the CertificateVerify message. In that
scenario, a client which first verifies the Certificate would then respond scenario, a client which first verifies the Certificate would then respond
similarly and leak the same information.</t> similarly and leak the same information.</t>
<figure anchor="flow-diagram-client-reaction"> <figure anchor="flow-diagram-client-reaction">
<name>Client reaction attack</name> <name>Client Reaction Attack</name>
<artwork><![CDATA[ <artwork><![CDATA[
Client Attacker Server Client Attacker Server
ClientHello ClientHello
+ key_share + key_share
+ ech ------> (intercept) -----> X (drop) + ech ------> (intercept) -----> X (drop)
ServerHello ServerHello
+ key_share + key_share
{EncryptedExtensions} {EncryptedExtensions}
{CertificateRequest*} {CertificateRequest*}
skipping to change at line 1785 skipping to change at line 1871
To begin, the attacker intercepts and forwards a legitimate ClientHello with an To begin, the attacker intercepts and forwards a legitimate ClientHello 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 ClientHello in response based
on the contents of the first ClientHello and HelloRetryRequest exchange with the on the contents of the first ClientHello 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 ClientHello and the key share from the second
(attacker-controlled) ClientHello, the Certificate produced would leak the (attacker-controlled) ClientHello, the Certificate produced would leak the
client's chosen SNI to the attacker.</t> client's chosen SNI to the attacker.</t>
<figure anchor="flow-diagram-hrr-hijack"> <figure anchor="flow-diagram-hrr-hijack">
<name>HelloRetryRequest hijack attack</name> <name>HelloRetryRequest Hijack Attack</name>
<artwork><![CDATA[ <artwork><![CDATA[
Client Attacker Server Client Attacker Server
ClientHello ClientHello
+ key_share + key_share
+ ech ------> (forward) -------> + ech ------> (forward) ------->
HelloRetryRequest HelloRetryRequest
+ key_share + key_share
(intercept) <------- (intercept) <-------
ClientHello ClientHello
skipping to change at line 1837 skipping to change at line 1923
incorrectly apply parameters from ClientHelloOuter to the handshake.</t> incorrectly apply parameters from ClientHelloOuter 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 ClientHelloOuter, it modifies it such that the server will process the
resumption ticket with ClientHelloInner. If the server only accepts resumption resumption ticket with ClientHelloInner. If the server only accepts resumption
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 ClientHelloInner is for "example.com" but silently ignore the PSK
and continue when ClientHelloInner is for any other name. This introduces an and continue when ClientHelloInner is for any other name. This introduces an
oracle for testing encrypted SNI values.</t> oracle for testing encrypted SNI values.</t>
<figure anchor="tls-clienthello-malleability"> <figure anchor="tls-clienthello-malleability">
<name>Message flow for malleable ClientHello</name> <name>Message Flow for Malleable ClientHello</name>
<artwork><![CDATA[ <artwork><![CDATA[
Client Attacker Server Client Attacker Server
handshake and ticket handshake and ticket
for "example.com" for "example.com"
<--------> <-------->
ClientHello ClientHello
+ key_share + key_share
+ ech + ech
skipping to change at line 1874 skipping to change at line 1960
]]></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 ClientHelloInner and authenticating all inputs to the ClientHelloInner
(EncodedClientHelloInner and ClientHelloOuter) with the HPKE AEAD. See (EncodedClientHelloInner and ClientHelloOuter) with the HPKE AEAD. 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 ClientHelloOuter is not incorporated into
ClientHelloInner. ClientHelloInner. 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> ClientHello 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 ClientHelloOuter 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 ClientHelloOuter 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 ClientHelloOuter extension can be copied multiple t imes,
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, ClientHelloInner by including a large extension in ClientHelloOuter
of length L, and an OuterExtensions list referencing N copies of that 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 Al
ng registry erts" registry (defined in <xref target="RFC8446"/>), with the "DTLS-OK" column
for Alerts (defined in <xref target="RFC8446"/>), with the "DTLS-OK" column set set to
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>
skipping to change at line 1964 skipping to change at line 2048
</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> <!-- [rfced] We note that the following terms use fixed-width font
inconsistently. Please review these terms and let us know how we should update
or if there are any specific patterns that should be followed (e.g.,
fixed-width font used for field names, variants, etc.).
accept_confirmation
cipher_suite
ClientHello
ClientHelloInner
ClientHelloOuter
ClientHelloOuterAAD
config_id
ECHClientHello
ECHConfig
ECHConfig.contents.public_name
ECHConfigContents
ECHConfigList
EncodedClientHelloInner
inner
maximum_name_length
outer
payload
public_key
ServerHello.random
zeros
-->
<!-- [rfced] We note that these terms are used inconsistently. Please let us
know which form you prefer.
split-mode vs. Split Mode
GREASE vs. Grease (IANA Section)
-->
<!-- [rfced] FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers. Note that our
script did not flag any words in particular, but this should still be reviewed
as a best practice. -->
</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"/> <reference anchor="RFCYYY1" target="https://www.rfc-editor.org/info/rfcY
<date month="March" year="1997"/> YY1">
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. 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="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC7918">
<front>
<title>Transport Layer Security (TLS) False Start</title>
<author fullname="A. Langley" initials="A." surname="Langley"/>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<author fullname="B. Moeller" initials="B." surname="Moeller"/>
<date month="August" year="2016"/>
<abstract>
<t>This document specifies an optional behavior of Transport Layer
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="November"/>
<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>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
180.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
460.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
125.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
890.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
447.xml"/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <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 2192?>
<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 ClientHelloOuter 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 ClientHelloOuter.</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">
skipping to change at line 2436 skipping to change at line 2250
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 opy <t>Otherwise, the I-th extension of ClientHelloOuter has type E. C opy
it to the EncodedClientHelloInner and increment I.</t> it to the EncodedClientHelloInner 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 H4sIAER5F2kAA9y9a3cbx5Uu/L1+RQ+9zhKZALCoiy3RiTMUJdta1u2Icjxe
rMPrVwS70SSsbqANoEm1ZZ3ffvJalVVAk5S9H45i1xqRuBSqsrLy8uST4/HY mRyxATTIjoBupLtBCtHo/e3vvlbtqm6QVJIPZx2uNRMLaFTXdde+PPvZ4/HY
dWW3KJ5m71+eZsfVtNmsumKWHS3KouqyF8ViUbv8/Lwprm68ZFZPq3wJj5k1 dWW3LI6ydy9Os2fVrNmuu2KenSzLouqyn4rlsnb5dNoUl9c+Mq9nVb6CZuZN
+bwbl0U3H3eLdly0VTk+eOSmeVdc1M3madZ2M+fKVfM065p12x08ePDkwYFr vujGZdEtxt2yHRdtVY7vPXSzvCvO62Z7lLXd3FWb1bRojrLHjx48duUa/qtr
1+fLsm3Luuo2K3jMyfH7n1zeFPnT7PT4yF3XzceLpl6v4K5F6z4WG/jJDC6r Nm137+7dx3fvuXYzXZVtW9ZVt11Dk8+fvfvBbdZzaKI9cvW0rZcF/Sd+cpTd
uqKpim78HF/rXNvl1exDvqgreMamaN2qfJr9pauno6ytm64p5i3812aJ//FX u3vv4fjw0M3qqi2qdtNSa4WDDt93eVPkR9npsxN3VTcfzpt6s4avl637UGzh
5/J1d1k3T102dhn/Kav2aXY8yd4V7bRuFrn+nD/uuCmnvV/VzUVelf/IOxg8 k/mRc22XV/P3+bKuoLFt0bp1eZT9patno6ytm64pFi3813aF//FX5/JNd1E3
jmhWrAr4n6rTC4plXi6eZsXH5r+abr6cTOulS1/5yyR783Edv+2X/B/ry9r+ Ry4bZ/jHo37WlLPsbdHO6maZu4z/ygq68mzS+7xuzmFQ1bxYF/D/qk4/L1Z5
PH7VT3nbLTbJWz7STfXH9X9d4A8GX/Z6kp2uF4vyKq/iN74upx97v4pfeoSr uTzKig/NfzbdYjWZ1SsXv+bn/B+bizp7/WETvePnif2Imv8hb7vlNmn5A/28
X180+epykx3VVbtedGV1kb18eZSMpCqnl/UibyetPPD3KBU3DOtokh1Ost/q /rD5z3P8YOAFr8rZh+x0s1yWl3kVvePVpPc5vegEd0N93uTri212AkuwWXZl
ehaP6uiyKduuXl0WTXpBMrZFvZ7NFyA2yVCm+fV/XRb5CgZ6XnbtBCTGOVfV dZ69eHGSvL0qZxf1Mm8nrbTze9wlO7tyctGUbVevL4omO55kv9b1POrQyST9
zRLuvCpAALJ3Px0d7O8/kf/8/sn+46cgptXcXvPbi8P3v/08Pnn7p4f4z0x2 mPuzrDfzxRLWPXn9LL/6z4siX0PnpmXXTqqic85VdbPKu/KygAXN3v5wcu/w
zs6v715mL8srnIZTFMC8mWXj7OTt1cPsbd60RbNDV+fNRdE9zS67btU+/eab 8LH857ePDx/Jf/7222+HR9SeHJbvpfEndd21HQwemx08H3Q8squyu8ievjrN
dbOYtKtiOrm+zLvriwl8yzf3pnU1LVawgVZXD8cruhnvncH2eZq9yjfZwYOD TovmspwV2ZOymsNPWm40b86L7ii76Lp1e/T111dXV5NmMRsX87KrmwmM6+uy
ffjJ8dGL8WGVLzZt2dJY/GAOs9PN8rxegKTqBVk9z942sATTTQYfRPt4f/Jt WtRfw2fYE/pNWzRl0eLHR9IX6OdR5r/Psqevnx9lh3cnh98+ePTt1zIK+o7P
dl12l1s29A4/Mxny9fX1ZNpO6k+TfDpZf/xmVdSrRfENfPkU7pxML4urfPHN zav6ssBjSAeIPvdbm/7GOoE8309gA8wurvKm+4f/ot00vFi9bxawxvzVk6L6
an2+KNtvnh39Np5O24ODyWo2p8fxV7yur4rlOawlfMoB/Zy3oXxHFqTCb41n W74qq+xlr4HkDfDAk7K9qNf99pPPQ+svyw9F/G3SKJy/V9vzpqj6jSafh0bh
lzCQ3MgkLjzutabMh2/60wTEBkdz5zuOYsni641EOTcej7P8vO2afAri8/4S NH/Qb3kDwFa4K/MyL9v1MgdB9tObn585hytgttCvPx2/+/XH8fM3f35Az5sp
JhbU3nqJkzYDpdCU50Wb5dmymF6CVLZLeHD2vsmrdgW6J3uZb+CjT4vpuim7 lY7RLuXHXNhQe7+8fQHb//mbywfZm7yB1d1zAztj0ywn7bqYTa4u8u7qnLbG
TbYLq7CHy+EKXgEUn1wWgdYAHtS2+UWRrUGdNPA7EIYr+A+a32kGSnDCg1qW VyD4ZsUahO768sF4TT92fpVf5ltcYFp4kGDwbAe7Usayx/3IXpSXuH9PURLm
s9kCRngP9WFTz9ZT3A/Z53sl/vOLc4cLmOD1xaVf+c+f/wOk/PHDh999+ZLJ zXwPR/3s5KfxcZUvt23ZRnt/7zg73a6m9RJEnj6Q1YvsTQOHerbNYD7oJBxO
+9tsWbcdykp3WWTwBbP2Mv9YjOArpov1DIcHv3AyiGnRdOW8RL0+wp83RQaz 7vO+H74y9nZu/Vk7qT9O8tlk8+HrdVGvl8XX0L0Z/HIyuygu8+XX6810WbZf
BEOEX+aL7DrftPj515egBbK8yuoKxBnELe+6fPoRHwCruSjypspWKJpdkfnd Pzn5dTybtffuTdbzxY6dfW/HafGn4/DBw6/vP3zw6Ju730zuP3z4+P43d+mR
BmPPz+t1RwOBHVEV9EGT7D38e7XI4bOKTx1MJY3kNSgJB2oXx4K37p6+PtnL 3mRleycnp9mde/eOYKj1rCjoAOPIu4uCXpUdn7zMTp//eHp8gqJwUcAGgrNe
4IKiwvMERzEwqXAO8NhgDB9behNLOxxloDQq2ih5dgFbvzJjgNlos1XRXOYr V/Cv1XrTQY9ggvEfqw1IQ9g0IC9BJMw2TdltR9l6Pcnuf/NwfP/bx3s3H0iQ
vonmrMVXoZaw3wBfN+9g7Qq/wVAceAEmqfygIoDpJPmpimu6zn/CCCZrsYAH +k8uYPpyI5L1bmnKfPhHf56AYMU5vPUvTmIh25OyckAePH6cHhCQd+N3z96+
bDl8d0Eb7OEq5F0GF9bXbTal38MQa11eHG3ZRFMBv8RPwHfxqk54VKum7uBz PMVnno+fTvj+Ga+buitmsB/GoBykP3rz9vW7Zyfvnj0dn7567tx4PM7yKYrY
+QNhNmH9ZlmNi5yt4DdVV8JbNuarYeCLGZ6sa1xsus8drlYLXRIW/bfw2Hpa GYjrP/wH/PMvIAaL+V/hWpUJbuFSPoB/nsPWxW38F3MI/zqC1YH92ejDd1ra
L7LXYArAM3i1Dl++fb3nQGF0IJX/ibr32wf7X77A/q3Hixrlayaja1lhwWKA JBl8pkdjkrl3sIJ4AqFrl+UcdmpTgJZxWbRZV2d5ts7PC97Ley/gYs1+IWVk
TsNh0Aw1FQ3mqmzL8wV9jIMr5uXFuqE3tDT68+Iyvyrrxkpzu17hxoTn48P9 nh3e00Ye7k2cewXjgtflnZxvba7N9uB+W5Vd1lb5GmRV1+7JvimbbMmHr5XD
pdOSTpp2XXYF/cRd1tf4SZusKWArwyUwcfCYeolP4Zk2IgLzgDKAQp9XdbVZ 1+IecfBVU2Qwv7B1L4smX2ZpC9miqVd+DNw73IhLVJO6bFpgo/TMvbsuDPUH
4m5vi26S7b6G2XO0TOUSFCeuPI1xLMs/zeDILKeFmcogx2DwFA2+EWeBRcmp OJ3Fx3y1XpLqFOTD/nUyhl8+9i//+nD6aPpo9vBhMX0wLeaPF4f3H88e5w/u
MMMvs1mJc4AXzlHT5jBEGGdTgLEyGy9oBWBT4elU4gtg/+H3wPENF7pZOZ/D P15MD2eH08XDh998M/3m8PGgdDpw7tcCphhbBRUoI90OuxsvFc49jmhVw3jg
Hh6e0zB5Be4G3BnbVqQ//ZO97FfSYqRYQLqCegSjssgXrQiuziRcopNZXTj4 jDQoO2AyUDPUYyeCNBFgI2gEttOM2+Sl9RO0qmFWz4uKZhW/kdfoAlw/Ewcj
hDyDg7Arp2vQw/RimCGU0asSJmSUnYOimNUwB1XdySNla4uqmjf1kkQyWo4M OsP5nLZa3lvZPdOk80OBLeZOeARHLtqf/lxlenmMhi6DUTYsqke4gLYNXMtR
PhMWMMdFTvXM82K1qDe0MXGhRIxb/QQ3L/JuLRpvVrbTddvy9v78eeZvBRl2 9ocvvTC+h+07PcCTnH1zeO9hdpG3sIUKmGdRt+fZdEtfP3547+Eko31zVcg8
DnYmfhAODX4NtkexmMPazmGt6WPh82S30SBKtBtxgKKFw7ZU9ZSJelqCLQBz F/6HjqZZn/uTc7MDEC7+igyHlp55ePfbb6951aMHD76BV/2KE6l7JSysb8C/
V8Pi+HXqLhvS8rxVcZarYhFkyQXVKVP9/PVp9vd1gQKBEqTPkXk7eZvlsxnI Up7/qb7CMzPKykV4aLWhQxGWBKYO+t9uzs/xuEDbKI21XWwp2y8m55PRdR11
SFu0k+xFfY26feSCPsPb/Wq2/jX44xof8OL9+7ensqsfP3z88MuXUeZ/CZLy pqMH8ObTokBxji1lDyaPJt+ACKW9hQ+ddttlkf24AYGQ7eMH396/d+8A5n1+
zXNUPbLrHz96DGeRXPzgCV2Mm8/f8H9+PTmS3z85ePTgyxcnMmDHgLJpdB+Z kP3w2/ORKprZfmJDtZez6biYXRzASJdL6AIfGJinOVwcssX/6+UL3MHnxQRk
U2AE4EMWaBWD1iZxAAsQfQo8+leq2XHzL/NqYxRim12ifl+ikQsbVia/dbDL 5veJqHyzLPK2QHleNB3s320m5k+b7U+LbQ3zChdNK8ILtNkib+BplEJ86x/Q
aHng6DHTNGErC46yuikv4LpolVgyCtJFJbwKBL5eLuGcCKKsmz4nOQbjD4Xj rb5p6TK7Rk1t4Yezi0lGXXiHpxkMww1ObgZicNaUUxCGOcz27CKvynaF8/Ou
02YC5zr/rqiuyqauULzakVfPTUGjIhmHw3SZNxvYxii3JZws5QXs5gysp3KR yat2DZZW9iLfwhWp92G2D1oEvdgVrEHwibN69apoW5TNGzCk4HLFex5WPiP9
k5TUWX2unwf/mBW8EwpzvN9vvSgGIQ76MhxkkSUBqxv/+Mn+w+91HeFUg0X0 YIaDnPAVsirn8yXcVV/BZuyaer7hNfr0VYn//Ozc8RImYHN+4TWXT5/+A9YD
mlYEHK/HeacbV3JAtBO0ZcC5uMIhqF5+XszLqqR/O9oQYABl6Aa22c6rX0/f F/bz50ze37IoEtEDI5i3F/mHAjZaNVtu5rIUTjoxg7kuF3jNF3gJpfL8Kt+2
74z47+z1G/rvd8cgMe+On+N/n744fPnS/4decfriza8v4fdO/ivcefTm1avj OPyrC7CLYE1gZuEswk7Ouy6ffcAG4F6HhWsquEdAtcJLS08S9D2f1puOOgLH
18/5Zvhplvzo1eGfd1hgdt68fX/y5vXhyx2cFdIO/lBH9dDR2uO2a1ZNgZMH ueJNN8nwIoMDAsMqPnZkbUBDr0CrdWBwisqR7cPVegC3ACg3JEuhFwOTClYv
66vWIs3ks6O32f5DmDFxQWgX0KTufw+7wF1fFiKcdQVKmf9Jx1G+WoEBhc8A 9w368KGlN7G2BsY+mFQVbYk8O4djXZk+jPBqXRfNBcjDIL7RMi9JApgxwOgW
dQ0KfVV2Oe53eEMLZ1aVoVkGThX8EvUyKCE+c0HuCtkH9FZcvRFapvTbb0lx Haxd4RVE3A68AJN0/6AUg+mk/VMVV/RcGMIsXy7h9zu8E/ugzB7I5oZ/X7XZ
3cveXKGqLa5dMAro9C5p/CBVBR2ENVhDbL3B+FjLX6NpsaoX9QUqlnKxWKPR jL6m613eLrexnQi5GPBNvKYT7pMoMDw8mEu6EWpc4mxdo8ZYwlu2ZszQ7eUc
3JHog3Uycqyerwuya2AdwLyHX76qZ8UOT+opCG/HPyCrr0VDa4bHMWpcO3so vQgbXGr6nTter5eyIGPe+KBVdvWsXmavivMa2uC1On7x5tUBKAkwiZ8+/Qnt
s/MajR460kWDw/jvZe/9GJz7f+GPN+31z+/HQ39+37vun+kP+KeD1x08eLD/ 0vt3Dz9/Bj2uHi/rGckB7l3LkhD9IPA0jh7nB4wd7Mxl2ZbTJQ0GPSWL8nzT
9Pmzx0+f7sOf7dcNPU+Muj/QMP6I14lpPCk+5WgwoI/4Fc/rX8eug38cCMLX iAKKvZ8WF/llWTd2L7ebNR5LaF8uXX50VpJN3m7KrmBl5aK+wiFtUWtakzCp
jC/9yV3nT/+wwW5+vctfPP4pn5L3A0v/DL0D+PuoXp6DTprt8dJ9fprda0lM sZl6ha3wTJsNAvOAOwC3fF7V1XaFZ70tukm2jwqUo2UqUUHBdecJksWfZbOL
xigI7O3+aCVHl3uzAw4P6EvzK9aUqmZRgPHfrKO9kYDmPggj/ka0PGy1GgQP GsxnM5VhC4A4K0gc4izwRnK6leFLUDFxDlh1APGZQxehn3izNPPxklYAjhTe
zg7HVhRsgrrkQ7vsSCmzQeNfgUos2BH0IjUyQPY3oqB5GJO+UA7O5+/vOtWD qiW+AE4fjmez7FASzssF3RuDcxomr8CzgOdi14r0p39ykP1CMozECuyuIBwb
q/bPuy7ooOz+c+BXx/CH747EddufP97p3QNyqe++dQv8e9/97815FguweKTm aC5ftrJxdSbhEZ3M6tyJfgqiZrYBfZxejA4GUT2hT1MQE/Ma5qCqO2lSDrYI
j4qziH6QZVRwsSh7ldeTZP+bviCjYTkszOpVizBP3LsczUJ+BNpDKtMDFwc5 KlIScUtGy5HBMGEBUZvsSZmncAnXWzqWuFDelJEhuEWRdxuRd6DZzzZty4f7
t+/jQ8jKMJgJ8samWKDHHxvS2Tl8vT4lGiE637VLLPBk95BrQQ+kOYb9tkTz 06e5/ynsYefgYOKAsGvwddm1xXIBa7uAtabBwvDktFEnSvSXYQdFBodjqcIp
I6+6xWbkrWPrCzjvBoC/Atb5FDyp1n+FN37F9LDjLDY1f5r11x2+zhorPiYy E+G0Av0E5q7G61LXqbtoSMbzUcVZropl2EsuCE6ZavTY/H1DtiPuIG1H5u35
oXXBH7HphYuh7o2e/iM8367h8INrwLXSYWDgLh03Gs34ux3+0vGcpYmnik9E G1QDYY+0RTvxWocL0gx/7lez9a/Bj2ts4Kd3796cyql+9ODRg8+fR5n/EnbK
46rrrKHC4onbORcpkzvIX2jZPfFmqjgWZaIZ0Xsq+zIWjcSRBx29g0/i1eWm 109R9Mipf/TwEdxE8vDdx/QwHj7/g//9y/MT+f7xvYd3P392sgdsH3BvGtlH
LacSDAAnDfUczM1pUYBh0Uqka0zu4awQfxDMG5S4ZR18pzjgg9YmeDLgYpFm miAYg9jIEj2Da7ErqqJDhymqDGuV63j4V6g8BIHYZhco3Vfo9IMDK5PfuprV
XdDb0QUvOxIzEpfajHKUDc0bS2s8arYL0igKB0MoiOLc4eDDYPbQdm5pcKDI nhYuHjNNE/YRwEVWN+U5PBetEu+MgmRRiSo2mTxwS4StrIc+p30Meitujo/b
OcR5yYcW/TByeiW25Eq0XDUAg18ZQnc0urxt62lJp8Oy6HL02sH59KcPGUnw Cdzq/F1RXZZNXeH2akdePDcF9Yr2OFylq7zZwjHGfYuKe3kOpzkDK7pc5rRL
Gvhct255ZpZgS+nrWeCSN69bidTxW/wbXLKf4g9EK8sIr5uhsS37svd590lp alTwZHjwj3nBJ6EwlztYkboVwyYO8jJcY5EeAasbf/z48MG3uo5wp8Eiekkr
LPNOnO9iUVzQsqBa4U9kQxNcC/A6WnTixSF4+N0DjO2AhDj4CW6Gk9djuO3H Gxyfx3mnH67lgmgnqMmc1NUla60sl58Wi7Iq6d+ODgSoPxkreXsvfzl9BzYE
k/Hzic8atVfT8zE4dSIrGh1pRUpQGHqDajFdBJ7YFQYmxR0//dPRM5po9kRF /W/26jX999tnsGPePnuK/3360/GLF/4/9InTn17/8gK+d/Jf4Zcnr1++fPbq
402yN+Qgw7hLuHpj/UeM9JLDtqpbcoYn2U8wAjl87N4g3470zOAcgY4s9Ae0 Kf8YPs2Sj14e/7bHG2bv9Zt3z1+/On6xx7owSAd/paN46Gjt8dg164aUf1hf
KX4Duz0EOa5zjc61Xc6LmYvfyfuBVqsFQz0R4RFsA4ywgEW9xhBd7nW3EeYR 1RVpJp+cvMkOH8CMiXuWTgFN6uG3cArc1UUhm7OuQCjzP+k68oos3vog0Ndl
65yGLXTREub3J6D5JKog4+kuOcxpHsuiestTnfn9m3XHghS9i36Kj+5Iqsuq l+N5hzeAqXYFmiyI9El2DF+iXAYhxHcu7LtCzgG9FVdv5BX7+yS4vspeX6Ko
Ahmr1212lS/WBUmSC5FEH+5inw92z47Xxx94rB8uKUERLnW7nz/7i8Yi3XTR La5cUAro9i6p/7CrCroIa9CFWHeD/rGUv0LVYl0v63MULKDTb9DBQYZPAdrJ
ly97Guad5g2FOXAmiiEFIHPyU0mxr2ilYXhwTva+SZSQVy3v/T+yDg6J1vtD yLF4BvME1RpYhwuYqXn2sp4Xezypp7B5O/6AdL4W1Sx0NJDEtbOHe3ZRo9JD
8PPgouQcJHzq3D4caXPUav7YEg+bpKmmEDn+dFb4AK6NCZcYdESphJ1H+SV7 V7pIcOj/V9k73wfn/j/4s2Yk/f1+PPT3+95z/5N+wJ8OPnfv7t3Do6dPHh0d
QrH8DC0O7HL4v2Qlm+JvHG/DV0/CyNo1naHzNap4GUc7MBBYxOscjYkhQaPB HcLf7ueG2hOd7g/Uje/xOVGMJ+LRQBvkC9rrP8eGg28ONsKX9C/95Lbzp3+s
8Vylsixro5+RnLJDo8WHYYRkimkyP2D366rGcOa04DRcWJf7rURt23j3+qgH rpuv93nE4x/Y4sWlf4K2ATsRpyCT5ge8dJ+Osq9a2iZj3Ahstf3R7hxd7u0e
KtqC9AHMOE43PNBd+1fAS3cxqsdXw7NRL435d3k1LUDESFLhLJ8WxawNZov/ mDsgL81XLClVzOIGxn+zjPZKAir7sBnxG5HycNTQZoS7w7EWBYegLvnSLjsS
DgdXg96BexebSUZ6QCIqPO3FbCS2hCZTYx8CB7VuKXZzvnHmG8hnMWF2Pj9O yqzQ+FegEAt6BL1IlQwy+llAczcm/U05OJ+/v+1UD67a/9x2QQf37v8MfPUM
YBMXOTwTXyILW1eaGDC3w2Q2RQf6j4a8Xo27eowpuliR4efrOFkn74msa6jp /vjX0Xbd9ff9rd49sC/13TcegX9t3P/anGfxBhZ71PzpdpatH/YyCrh4K3uR
os4XKOfyUZRyaNdke+RRYBx/peZDGSJoSVwW1TiYVGWLU7EGzUhfTtEK3FBw 19vJ/pv+RkbFcngzq00tm3ni3uaoFnITqA/pnh54OOxz+z6+hOweBjVB3tgU
Ma7WBIyVpqhFI2K8Y72YwUxflgWpZBgIjQu/Dc+MfD4XCccIX/GJH5+pkYLr S7T3Y0U6m8LotZWoh2h61y7RwJPT4x2arM/BeVuh+pFX3XI78tqxtQWcNwPA
t8KToyBrz6dp2JTBJ8WGCx9sidXiH8YCwQlXupcCKsN2x1E02Z/voXhFC/CF XgHtfAaWVOtH4ZVfUT1sP9VHVFhr3eHrrLLiPSITWhf8iFUvXAw1b/T2J/cb
A3BgALTZi7e/HLPBHgwJY17AkYpX/Eiht8d40tJC9Q4njuHgCa9uqVFQZ3A5 ObTIJafdwLBT2m9UmvG7PR7peMG7iadqT2ed5kenDKUVz9reVLaYPE7GQsu2
D+os4+MA1tJ6q/Uq//u6yF6sPhZvaRi/FJs/7E8mB/93/7vx/h9/oIvWYGzv iddRxaooE7GIplPZ32BRNxyZz9E7+BpeX2zbciaeALDQUMjBxKCP8NOnVpxc
f0cX/VIsT2Y/xD7YN99wPI/PaRlv78bZ/F+78RDkP73z1hv9Zx+ranu/WRU/ Y7IN54UYg6Db4HYjF7UYTrGvB1VNMGPAviKxuqS3o/1ddrTHusIvKPdylA1N
JDdqlGwfxMPR7TxH2WfvF/qhZx9n8w/l7IfoNzy2LIe//O++0G9ON0uwApty Gm/VuNesFAzHr8mB4tzxYGMwe6g4t9Q5kOIcnbvgG4s+jCxecSu5EtVW9b7g
ekQZqFNMQP2w5R045seyqL1X0ISDbCx7v/HrJQL0AQQovmJoEJIS+8ApsT88 KIPXjl3sbVvPSroaVkWXo8kOlqe/ekhDgtfAcB06JvE95OSV1/NuS968adVf
lKV++Ec7engoT9+2IQ/Pb4Z4nzAEkS3UZH94kIjUl4FHbHtZNCLcJh+mMrh4 Sm/xb3DJYYoHiCqW2blujpq2HMre8O6QxFjlnVjexbI4p2VBmcJDZC0T7Aow
Bpf5p3K5Xn5ApMmHRVFddJe9wchU4SUk5o8e/fGHG77K2DA3fQL8L2bM2ptW OVq04MUaePDNXXTswA5xpHeiN1h2hDpAWtkLuOS9V7cIdwFj6xI9j2Jxn/75
GKRSAuY/pD9Px9qCEQ737/rnT+TOPfPMDEwK8CMefJoXD2ZP+2MhM40HpTd8 5AlNJxubItQm2WuygaF3JTy9tSYiBvXIJlvXLdm7UdDIngAy30iUDM4EiMFC
Scf9AysCtnZUPQT7LtYlnBgGW0cG456SeSj/0kMDFRpbAn2HBlUVqL7ZxN7o P6Ct/yuo5sGPcZWrA67tcl6yXExL3vW0Ji3o4slGHcFmJ7RP12zQC5d78Wy2
JIRHjm2uYYdZIXELfB7aprebjhNRxW1GmYPyokLtjieE0YIufCadlLkfP0Xh 7IjFSsNKuMgC8/1zEG7iOJD+dBfsxzTN8oa8oVVnvn+NQV72wqafYtMd7d2y
Z7W13UBR8tLIp/I/MO0MmrbDxKtYhBWGImh+xM7hK/lHclq7OE3MB+jHcsUJ qmAn1Zs2u8yXm4L2iwvOQu/RYrMOzsieF7nvua/vLyiCHh51+58++YfGsofp
MTLD+Nd0nnL2KKNU+jUhMmh8bEU6AhPxrGmyOV4GERvnVAjgCw4r3QQ4eFxv oc+fD9SPO8sb8mTgTBRDx1zm5IeS3FvRSkP34CrsjUlDZypA3vl/ZB3cA603
SkBTXFQvyxjwlklOTB7KfhPlQ/R94qBK7IXvJZ+tMrOtohifPTiTN15zqwAG eeDzYIXk7Ac8cu4Qbq0Fyi5/M4kRTbupJh84fjovvI82DBr3Adpqa4KDEVzC
FYCflZ1FCiJ6EDgKG7UhE1E04A7junuLj05nczLvovuCAg7/2NmbZJj+Z6OI XkK8f4YWB86yxhnDSjbF39ilhq+ehJ61G7omER2y1X60Ax2BRbyi8O3QRqPO
52V48Gdeq5/x8NVMJlMvBD8woAPeam9WYLoGtJqKY11dgMtJyDpc97zvXs6z 8Vyle1nWRoeRXKRDvSVcSUvX9zp02P2yrtFjOSs4QhjW5U4rjtk2Pr3esYHi
j1V9XZELgIJN/xrx1iSfjaA75wUn0evsH0VTw8Wd7lTOuy5X4HBkq3xGUAuw tCB5ADOO0w0Nuiv/CnjpPjru+GloG4NRY/4ur2YFbDHaqWtGRbRBM/HjcPB0
IeU/1V5Wn0d82TwEL2loPGhw1RHdw3nU4hMa2DwO2SvlfJQVk4vJyAWDnw2l TdH55XaSkRwQpwlPO0bjWF1Q/FhsJmCnNi25Z6ZbZ8ZAZknwpGd8SzyHQ1zk
63IxmyIOr6L70VCezeBuxNbwj2QWY4iGc0bZy5RhUEOna1v4BKZtUkxGfl3g 0Ca+RBa2rtT3b34Ok9kUHcg/6vJmPe7qMcEDIkGGw9d+4thhwLLX1Zt0XudL
cYRuLWYY+1ivyKwejBMEJyfMHbg6oMqXZRsCCJrUHrk0fZha5/ANTzM2WxFX 3OcyKIoqtJtGAmrG941fqZJQBidZ4npFMY4AsRanYgOSkUZODgk8UPAwrtYE
N+YPGuMXiAUrcBaPt9DcJLvcsMTlTGOydjrgweFko01EmsYqj3AGinMvwh5i VJKmqEUioktjs5zDTF+UBYlk6Aj1C8eGd0a+WMgORyde8ZGbz1QVwfVb481R
Jhi9QueYwCkuigxSZjO7KCr69zYw3CQ7BiN/4JXukhLnB+Ma5qIjs4KTpsGi kELn4zCssGBLsXrC11eim/jGeEMwIoh+Sz6TYe3iJJrsT1/h9ooW4DP72OCa
4FGNgnI0P8UVgOMCDhGJlIVH4QRdUIwbZqnF5RXtIFIocoHPIj2v2AJUmY5Q b7OfttOmnGdvWDb/DNf4s6BC7CMoi4OVRpswOgbdq4jmQifOu6Fbi/03eMGr
O5MbpijOaFKCFLcLL/04zHjwu27QXbcoQa9ZaPnAmxqTWudUP1zV6NEpuDdS SWok1xk8zr09y/iegEW2lmq9zv++KbKf1h8K7iF08A+Hk8m9/3P4zfjw++/o
aKjJbhJZ8EkN4qJkIF7hI5B0DT7WLmbwWSaZ/9ZyBh/pApIS5XRos7V0OspL oQ0o2off0EM/F6vn8+9i++vrr9mXxxc4xdKhw71fzhf/5C+P4WikP735l37k
VClNUMUv+dPeqy5GQxe8rnwFjjXL2CsPPtr95fjVnv102neE7xLc0Vmwkc/u z1Tsvduui++SX6qT7BC2jmPoFU1T9smbhb7z2Yf54n05/y76hjuX5fA//rvP
ZChkqaHgeAJYmOF9WwyG8B47eHOQyDzHzrsH9vWDWC4y2FX1y27lmXn+E+2O 9M3pdgV6YFPOTigAdYrxp+92vAP7/EjWtfcKmnPYGKveN37JZPe8h90TPzHU
w+PD53YSVnnZBPQgYsQw8IzLF1CqrvdC0TdNkS9M2DasX4u4NrQZBIqFGhxG CYmIveeI2B8eyGo/+N72Hhrl6dvV5eH5zRACHbog2wul3B/uJrvq80ATu14W
I/I8GHD3gdyWgK+whatpoQZjAvBDpanqEW4vQYP9g4EWvAda67365Qr/9RLG 9QjPyPuZdC6ewVX+sVxtVu8RF/l+WVTn3UWvMzJV+Ajt9IcPv//umlEZ/ea6
4r0aNNWDhXsWXTS41yjKJ3GBQWFoCWBXTGF6SBRIJeCnrCiuhR8mW0piNB7p IZww9q69boVhV4q//Lv087SvLajh8Pt93/5Efnlg2sxA3QBL4u7HRXF3ftTv
i+aehAQVgqSWdKtzQaglxSe1qMXlF5iPWWLcquW0RxxoOPFr3maf75kduDUF SzbzndIffE77/R3LAtaEVEIE3S8WJxwXBj1IOnPkjkh3NCAnlE8ozlhN6Ns0
wvoVD/1aTAQzl6zMRooHtDtJ49MgyK18Jz5EIDcyjSza6wYhiAufXylm/sHw KK5ALs4n9odOXHhk2+bqdpgX4rfA9lBxvVmvnIicbjOKHJTnFYp+vD6MJHRh
8msQOIKxNcVVaSLIdMighdB2mG4juA2K7ShrEZjuZRAvmcLhEaU/3XpFMdDs nHSN5r7/5IWf11axA2HJa6Nj5X9h3BnEbYeRV9EXK/RF0AyJFsRP8kdyl7s4
/fuXuIxkIOEWArVkZ2HMswCibaHeHQqbBkYpwYNhwJaTqvpjAU6bXSPTgNsL TszX64dyzRExUtL4a7ptOXzEsfQrAmRQB1nHdASE4mnTaHO8DrJxnNNtgEM4
LPwcDvtV0ZBtieOlc3CbpZFhcogEzxFWbXgh4AXwTVd1yfbSQE5PH8fL4LxG rvQcYO9xySkETZ5RfS5jqH8mUTFplc0qiojoC8VKFe8L/5ZMusrMt+7G+AbC
5bgbjMiaoSFUnxXR6SugRhkFgVxh1ziDlsoY+nOxwfPiqsxNRLLFnAoMxRtP qbz2mRv3YJACNK7sLBISUUtgSGxVx0x2o0F3GAPea4R4P9ureR/NG9zj8I+9
ddaANNdLSieiO+vsIOD4LdDeht+uQXQXUeQcrHLCmfcmBFO1nUZRqwIXB2OW g0kWIJQ8McO9P/OS/Yz7r2o0qYLBBYJuHbBme9MC8zUg2fyOrCvChOFXuPR5
+CkDX5hPmxpWL6Bh4zyoQc2dh6mawFkaW9EkanAFggcD4A9xUf7Jbvhkk/2z 3/5cZB+q+qoiGwE3N/1LoKZk1BF4Z1pwIL3O/lE0NTzc6Wnl2CthgrO1YAlB
ABuMYnH9IfqAJnyrkRrHgjTJ/sSXWeRhU9ABUs4lnS/bx6wiTo+IvoKqwpIO yZT/VIVajSIxdvPgwKSuca/Blkd8D8dSi4+ogXM/5LiUi1FGQDYXLALWpK7K
aI/jkKbxysOYKhyxjJ0nm9kBTanWrmI4mxpOhjnb6QTyyxduvq6m/J8UVIVB 5RyWck6tUYAbXg+/RnQNfyTTGMM0nDMSX+cMnRs6X7vcKDBvk2Iy8isD7VHa
ggOgoQB2xXDoeQhmgqL9/LkfQf3CWrJsmhrV3WcN4j2cHKAy8wBGg3K94QPI TzFHHwhj2oY9CcEMCpMHxhAI9FXZBheDRrZHLo0hpvo7DOIoY8UWMdZjHtEY
tuSv0M3Ix/PJ4evDCN7nyD7vzc+4zKsc3zYQmTXTxIeX84EOb6jzlc0aE9Lw RyA6rmBaPOhCA5RslMMal3N1zNr5gIbD/cbniMSNlSDhKhT7X/Z7cKugGwvt
uqhWoH1qH/Hq8M+CEsShoMjQ4cN5247MYIVMoqDQGQbqlKF8Bno+Z2wojoIM Z4KouMhFSPFNga/uBsRNsmdgBwy80l1Q+PzeuIbJ6Ei74NBpUCy4V6MgIc2n
a1HY5k3noD8+TrJfq0X5sUiGNKIsuDfUUe2dI5754oJP6SXWTHU1bMtzby6l uARwacBVIi6z0BTO0Dl5umGaWlxfERCyD2VjYFsk7BVhgGLTEXZncs0UxXFN
803xHQ7v4A6gWbksEexMp+k55gDYH90HgY2MtRD5CI8kY4jQ/pfF9CMJ3roK CpPigeG1H4cpD6bZNeLrBkHohQuvH1hcY5LtHPGHxxq9QQX8RkINpdl1mxbs
AFc/IuPykEOMBtHQdbbeBLGS5CeM/NGD43BiNHaRWXEGoz2EdZmvyaqwNTBo VgO8KBmNV3hfJD2DzdrVDIbLJPODLecwShfglLhTh45bS3ekvETl0gTl/ErG
QpVkVlPFQDVfsBHUS0TKUXpeaKiFpzXsb/sRartz9qZcoKKa5muZoRof6CJT 9k4FslhR+Rqsb95lLz0Iaf/nZy8P7Njp6BHOS/BHZ0FZPruVwpClCoPjGeDt
HVMlLWNPKcjE9ggbGeyfY7q0pK14XneXDHm4AkdmRbvUxSnXEi3GyBnAZWB8 DO/boTiE90S9N9eJzHRs4nuEX9/V5SLV3V8AcmL93DwtyMGIE/PDpmILZ//n
hcDw1piN7kqu/UD7F1xhUvCOwcxtttsKxAS15ljrE9BFQlQe2hRN3nZ87PVf pz+wmD7eoOuwKxmLZ6xRGtxxuAWf4jnaP352/DSa0HVeNgGRiLgz9GfjXgi4
yNFDB/ZZNJmsk9aYScR9WYUqFVgjd4+0ztaQYvDrPt/bkowGi7KGeUMwEDx/ V9fru4ivpsiXLNO82PItXdSohQi8C28EGJecjkE/vvcctwSlBYFA6SuLAU8z
IMN8p2y36ud+bpcyi3Io0oKQ9NMhgM9PdgCoygHHQa3kolovQ+B4eFC7HEfe yWCVtphdAwLxHwze4BPVWqvYL334rxfQF28qof4f1Oaz6KHBk0tuRXFEDG6s
G2W73z169O2jPQ0VR/kT523pVb5Z1PlM/eUwlMs89Vi97fzUWO48JhbR3Qd7 lkB7xQymh7YVCRgcytpg8ul8ilPIY4dRgxQfpMKaVD1vdS4ICaWYpxYvBfkC
I17Z3f09CU+Hr+EXD8bV+xfGGQgbRzcGG14TR9I5lE6DeWp/rNmHWxMpP6R3 wzwrdJS1HE2JPRvP/Zq32aevzHHeGVlhaY1KRC0qh5lLEY0CMbSHUv3hcCRa
bc3pxOkIWIxeXqF/lUx2Ly9nB0/z1xv88XLVhaTQF5u4CBNifSSaA7OcFIAj GSa2ISgemUU+JJyUsPRRm2Iu7RJM5gr2GyHjmuKyNB5rurFQ4Wg7gaSXtGtH
LUe/QcsFzOSqU/ig7Mj+De6MfuNv4IM+vZr8EFAxOEz9TA2Romqj+i44e1Wt WYuZWn4L4iMzuImiiKrbrDmt5t27F7iKpG/hYQQRZydhzJMAO9tixzvca+qI
2WoOPLPRECRHKzZAzFlGaT68gcvrFK0u9+oLksJCHmw6Fz3RdoPBGMnSJoHc pbARuh1bjtPqx4LENodGpgFPF9gMOagO66IhXRX7S5fqLr0lw5AT7TtH8Lfh
ELOe+It9hGaKQfjY0LXSJQ+1xWze5toaOODDgdSGGNRsdSrgUxH3sYc3EJmf dYAXwJgu65LVr4FIoTbHy+C8dGY/H/TIqrUhNJAV0VUuOEnpBeFm4dA4A8DK
RAGIM/X24cU2wlH40Azr+ZEPdETlKQH9EjuWZ7L4Z1EahfMnGM0jAUGzp39i GE10vsW757LMjQe0xRgOdMWrYnXWwGauVxSkRBPZ2U7AXV6g5IJvN7Bzl5Gn
thz49NAQxELQr98hIOIdhhtowPIGGbSNLdCZpWfaMQcO0/kMamwULnZs4NAE HrR8Aq73JgSjv516basCFwd9pDiUgRHms6aG1QsA2zi6aoB40zBVE7iXY6Wc
DMVyNYTSg4zRyZFsrJDAueHsCDZMgM3C4NA2FFm++8kDzp7zOAbjBUh0djTw tho8gXjEgCFEqJVv2Q3fknJ+lqDRkYuv30XvQIWxml3jeCNNsj/zYxbM2BR0
ScNu9MinTUz5hkz303AODalvH47JCL4iW6Q1impghOYc8ovOscPSFNbY+eHd FZULQQjI8TGriNMjW19xWmFJB4THsxAW8rLD6D3sIY2NMRtJAkGpurPCQpsa
MgBmI0OwC6XQLQPoyjaeKiNbvGixchsx5i4YAY6P63O0rjh8CItijM0P/uk7 LoYFq/2EG8yXbiHXG4hzdOJCJ8GeUO8Cm3bY9Tz4SEHOfvrU99h+ZiFZNk2N
oL8KihxGE8D5uniGevEqCkCZiFUwEkO8anR7wGokPvBAZDKRANdLUEhBD+pi 0u5TSIu5h7LMYyINcPaaAZCiyqPQw8gX/fPjV8cRYtCRtt+bn3GZVzm+bcDh
djJFR3rA1g7DkuIo3w58rgfnJSESuze2yfHI+79ihpQMuk6WxR9SHthO+kY8 a6aJ7y7nfSde7ecnmw2GueF1UfJBe2SbeHn8mwAPsSu4Zeju4WhwRzq1ojBx
856O8HaW+7qt5HOGXyP8crTTvIiT8JfHfzVy3xuekXrOcrDZ3ld19pmZROhA o9AVBuKU0YEGzb5guCn2grR0EdjmTVOQHx8m2S/VEpOg4y6NKLbutX4Ue1OE
J55dNs0HBrt9sJecDexzCYHIDh/DnaTE4jp3skYtuHgHZOJDA6Mom2Imgj3y SJ+f8yW9wvSxroZjOfWaVzrf5DJijxGeAJqVixLx03SZTjHmwObtIWzYSO8L
aAC/wLQ30IqlcjicdFry4o4QUXahENVHp78i+wROpxDoXUmb4RhaGPyewsVr vpTQJGlVlEBwUcw+cEJRFTCzvkfGgCL7GvWhoedsAgvCL8noGPmrB/vhRP/s
ZT/oHZls7dPvxyRIYOU/K+a4s0LAPDL1V/mslcQUxzYWG0qXcp1tHzxJVdz5 Iq3iDHp7DOuy2JBSYZNqUIMqSUWnJIRqsWQdqBf4lKt0Wqjvhqc1nG87CLUD
XY4Yj+jCHNINYhT5PHbCUnAMZnbbv3CW60M9/yAp3CBxw2MyQndmH38WzmbJ OFpULlFQzfKNzFCNDbpI7cfQTMtwVnJbsTrCOgab+xieLekoTuvugoEUl2AV
D5PqAKHCEtv8I6dJpvWKyp97E5FTeK3z2bczRJ1PNx8EMR3y5T5BTgYAYxbI remUujjEW6LCGBkWElhm4IaA+yItFpVpsK1JxjuGSLfZfivYFRScY816QJML
LwRLkPPYbIQFQ9VOSNCYIagUhYz206AR1oI8p2eX3S3PnMWRKn3oo8m38kiu sX6oVjR52/HN138n+yQdcnNEn5NY2mDwEo9mFXJfYJncVyR4djoqg5346asd
mPVo/KK1Jmf2wsN7/RPvw8fU64YTeZdFPuMIHg2nQlPxulhcFemvcbhssJ7R 8W/QKWuYOoQYQfsDQe1bBdhVRPfDyRTMlHuR1oQOAN0D2H5yCEBaDlghqicX
IuvMkSYDtY6VcPgLRkNKnvOsJwln6oiH5D7s+HcUqMVlWmDJehQI0grnHbRt 1WYV/NHDndpn9/TBKNv/5uHD+w8P1AMdhWWc16bX+XZZ53O1v0NXLvLUAvba
qaBvh3Xhqm678d/XoIHBycsXF3UDP122IxgNfEJR9XceykMfZw7qYAGfSWbu 85HR3blPvEv37x6MeGX3Dw/E6x1Gwy8edNf3H4wDG9Y9b3Q2fCZ20LOHnjpz
J4z2Iqq8BZsNQ+JwXs7WU0HBwM8k+h7tTzSL2vV525UdIhiMWyAuBiMiWnct ZD/WoMaN8Znv0l/tDBXFUQ5YjF64ov+UTHYv4mc7T/PX6/yz1boLsabPNh4S
yYbZmhG4PY9AjQUJU2MsFikklvWVFjs2xWrBkWUb9sMc2bbtLqlpPJYXojzJ JsRaSTQHZjnJpUeCjr5B5QU05arz8Dg+kf0fuDP6xv+A7/r0abJEQGJgN3WY
FgzGQRvZeypuIRf2dKuTP/AsdPFnDx7c5uJzYi2C9dHHB/PrDwcInHv4R9EN 6nVF6UZZY5gRK5LN5ojgtY26IJlasQ5irjOKHuIPOGdPMfDyW31BkqzInU3n
yW/jxDVNEVrV0QM1sUHpfz7MvDXCJzm5LDi127hfTIGCBNPpWDkv2MIB2xzH ore13bBzRwLAiXM4OMIn/mnv8ZmhZz9Wdu320lZtkpxXvHb6IfiGIMEhWjWr
ASZHvW452pXOvy+B2zL15tW6leCrCi2a77tOIPalYIu2rfnEHfqQuBYm2BAv ns7zEai5Zs28AX//JPJnnKnFDy+OPCaF9/WIqFe/SZT2EiA3sXV5Jst/FkVn
WY2+Ery3IyzQmsqncEMIKkGj3RIK5jSAHMZLtmoZv0HZjDA5BO5yvigmXU1K OCyD/kHaIqj79K/Nln2pHo+CAAz6+i2iMN6iy4E6LG/QTlsHA+zmcLM9Y19k
tElez4z0cJQ9G2VHdLov+ma180IQ3/NcbzseZT9JyvjW2Z9SDJuCm9Zhd1vm OqFBko3Cw47VHJqAIf+w+lF6QDW6PJKzFQJD11wfQZMJeFzoHGqIsp1vf/mA
mNfVh8LDdBYlTk1/VutmKHo2VDxC5z2Jp7A5kXtrjrFIAdNZT8CRYawd4eVE yec8esLYAuLwHQ0MadiYHvlgjMkL8fPtr6IhCe59MhmBZuSQtEZWDfTQXEV+
ObMZwRcoIIpflS/rNVnFCsAiGpXZbGJVdZTIxGzocom8dTMP2mqnl8WyuClJ 1dkbWZqMHTs/fFwGIHSkDnYhw7pl2F7ZxlNlNhcvWizfRoz0C3qA4xt7ijoW
L8d432phTUfuKX0m8wegOsYKGzzvy47j8u02sR+FfAepS1S2G2LkmaOwJJYF +yNhUYzK+d63vgcirCBXZDQBEgeMp6jntSI3lPFbBV0xeK1GN7utRmIKD7g6
6DcZtoTpN/4zGOKCol2NcdpiJxh3KftcgveLyk/RuAQ1D4bG4oPPpwf36zVi ky3gelEPSRVCecy2pshJjxPbYzRU7OtDahOPCUw8JfZw7NrII28GiypSMpw7
OEsyXmgW1Xbptpk+lHGoV6XGu7aaMHQIDJ4l5DUilwnnY/PK3bYZaEbmSP0z WRd/UXnIPEkcMdB7UsLrWu7LzpIPRX7J7pfrneZFbIW/PPqr2fi97pltz5ET
4hpKPHS0FKrnkbhYQVnoRRwiG3aN3/+vzC36apStSqqnqMYP4/Zwiv0uw7yJ 1t77ws62mYmjDqTi2UXTvGeM3Xv7yNnAQRdPiBzxMfySpFicP08aqUUu78Ge
PwNmcQqG2CSri8ETQO+NbjAPgnt6Ks1kxqYFPWGr13Hbw+ju95dpyHGgZs4u eN9AL8qmmMvOHnmcgV9gOhyoyVKiHU46LXlxS2QqW1IIJiQNQAGFguJTfPW+
BBm1NUVt0wfC8SuYono6XUcqXzS9k4pgo9spS3VFPlkVWNlI7iStzPb4Cn8B xOKwDy10/kCx6LWyKvQuTdb46fsxbSTQ9J8UCzxZwW0eqfvrnMl1YDXZxbHc
F2GuXkG8jq8f4TafIvNmD67HX8AW06ww/g0puCVagWQcDqhRn6EKzErzdUNq UhCWM3j7mE3KD0cE+82XjAeMYWDqmn0UGT52xlLgDQaM279w6Ox9vXgvkeGw
WBiW9HEwkjGMi9zMkwQpHeAl4v4Mem8lZgIrTI92Jai67P+s8xnGG6YZ/jtL 5Yb7ZHbdmW3+LFzPEnYm2QG7CrN38w8ceZnVa8qs7s1ETm62zof0zhDTPtu+
4de7ar5y7SecEhVhGqocDlWHux8mYi/DwAnonBy+vCq5NkpLvpuy/TgBy5/f F6R2iMP7wDvpAAyGIOMQ1EEOj7MmFrRVOyFBZAbnUuQ6OkydR5hm8pTaLrsb
OqZdG4H8Iq0sV9FYSH/OfFmVIAww/uLmgrTOVusGDIqCM/aHIY024L3yAn2+ 2pzHHitt9OHkvjTJybge61+0Vu/MfvKwYt/iHRhMvWk4OHhR5HP25FF3KlQX
l0dX8YA4U+XFwwMaYylZgtc790jps/TZZ46P+Y9FsfIleVyIrmHTs3Q9zpz4 r4rlZZF+jd1lrfWMFllnjkQZyHVMssMvGIUpwdOz3k44U2s8YAbgyL8lhy0u
E3PY7pI8o001XiIBXn5eIhKAqjoJ+mQShf36TId12jlrgfR3h4fPNepkgNyE 0xKz4SOHkCZP76F+S7mCeywM13Xbjf++AREMll6+PK8b+HTVjqA3MISi6h89
BsXJpOBsW+QLLX6vYaUpErbSMvbhOld8bikALgkVR8nUAW/9Fu/SE3Yih9J2 YjHr4dvhqCxhmKTpfkSvL6LZW9Da0DUON+Z8MxN8DXwmXvjogKJi1G6mbVd2
j5EuYyeUNx0Zw31X9I3kJzAA4jw6N4mkq9q9WcPRKTJTj8TaLEpeFoDchDcY CIwwtoHYGQy0aJ3y4Mw3jPztmQWqLoi7Gn2yyE6xqi81j9LzCDnr/sNQ2a7j
MGXIjJEdzza9x4Xf6PNmW3ze7S6vI5eXeKXYLnsmSeMAFoiJ+TxcO5wSlGdO LvFuvJeXIj1JGwzqQRtpfLrdQkjsaKelP9AW2vnzu3dvsvM5vhZBBmnwQQH7
mY6Q6fKp2oloKjtO8aJNBXs/esJQeDxE/H/IOLWz4XRt7n5mLHSRvSNYlEXd wz0E5T34XmRD8m0cDacpQr06alADHIQp4NusCeRr+DuyWnBqd5HKmMQIcarT
HCKnyLolE1t+zJsj2/353fHh6fGeUql9j2yK7tZhXGCwt9AIrU6JrCR4DVTw vTItWMUB7Rz7ATpHvWnZ65XOv8+u2zH15tV6lJjvaJf1BNu+FMzSrjWfuGPv
jH4YnzROs+MFwwB80SmN/0IHDipwvVxuknnkiW4FRbstDDcDQRmDGz79iFpJ GteECOvqJb3RJ5n3ToQFeFNyFh4IgTp4kip2CXM4QG7jFeu1DAqhqEaYHEKN
RJxwISB5Fefl97Jgm2oQGOt3y7kAEuDbsJJfiuqp4AFPD7gbi0r78BsOMmG8 OZ+Mk64mBdwkvmd6ejzKnvAEntAVv+wr185vhPh3T+mn8LNn3MAPEkG+cRVm
l6eRniZKyU7RHpPsXZeqbd/gy6UeGdSqX9Ubkv4c+GJkLOmMddnlMiyJySt1 5NMmZ6e13t2u84WNe894mNWixBnqT27dDHnShnJX6N6nXSpsUWTomtssksMU
oY+Nuyi8TzC/wN+GRpMgty0Qlajb+NFcNY6QFxZ3V3ocMqsKBCn76EsABlOg mSRQyjCWj/B4IqNZneAHFG7Fr8pX9Ya0Y4V3EVHLfD6xEjuKa3qKM5glhYS1
LjxzMg0pSsRcn4FEdcjmighjGMgvz3/6hpDFX/OoOGU4cuppJ8ViCjDf+hy5 s4tiVVwXspfbvK+9sMAjO1WJ9SRQigk+jejP5Kdvd23/UYh/kNhEobsl0p8F
/mySvUG7NXd+XnuFZWIUR0CMhWc+jXKnZUdkLi6FQ5N53QXXUYDOeXx37Znv bphEwwA5J/0Wt/3Wj4PhM7jFqzHOW2wO42ll60vwhFGGK2qZIO5B4Vi+9+H1
OADtWSqc5k5igD2V3lhJvWHoUQ5JzB6pRr9tn7MHE02A4YAYtJjUi/0bVnLA YIi9gg1HQ1lRvlFQYrpdOhCFIOp1qd6vnboM3QaDlwoZkMiXwgHavHI3nQaa
4xWEmTP3OpbcmHtClk/OnIAmM5kPQrIJIYKZSt41YDAGXcN12Qc4nxTlDsZi kgXSC404VZNo85I8omCZx5LKQjFih9mwlfzu3zK5aLVR+CpJ36IkQ/Tiw3X2
gHb6+nMlRUiwmT6qGh7L1Buhqk/UU2UWgEBnnICcbB0oVvAvuSxAVU7g2z4Q uwwDKYFTL47JEIt3dT54Fehvox+YhuA3PdlmQmWzglrYaX/c1Bj9+t1F6oAc
IlocdmBYQCcX1Y0UTaFZKxXqXteL+knyDGgEae4Jc0OUo2MPoYgCa1iVjkGf SNqzC0HabU0+3LRBuIcFr1TPZptI9ovId5J4bIQ8ha0uyTqrAu8b7TuJM7Ni
xSYauJ6vNx70MQQQ1b+my3LinEiEaxsLB+h0WicbWhJIrvAXwBTj83xe7y7Z vsYv4CEM3itM2PHzeM5nyBfYwwLyAFhzmhfG0CEJt0JtkJTEATnqI1aBvGmx
6NafMz1Bx2clsr7nbuI72RZv7Scz02WgGaW0lo+G5JXHNygunLTTJ84unsHP aUgOC4mTNgcdGUO3yN58nmCxA9xEzKBBM67EyGCF4dKuBFmX/e9NPkfHwyzD
Bc7rchuPXX18l/2YPS+88ejLtXcH9FyoGtmTaO505N/zY3ZadOvVM/j+0114 f2cpwHtf1VjOPYVroiKMQ5XD5erw8MNEHGToQQGZk8PIqzJfjuuFzypvyvbD
7mgrKR//2ekWLUaAd7J//jN78OnBA/zbv3SPo7asLMpISQg5L1g6W2xsryAy BCwAfuuYDm2EIIzEsjxFfSEBOvdpXYI4QEeMWwiUO1tvGlAsCo7gG2TYgBnL
VRDuf0NBbFUO31Kx33l9VZhd5h3QWbq5tsddA4SOwjoYGkHgVOSUp2H7IWe2 C/Tpqzx6ijvEYSu/OzxaMt4kKzB/Fx6JfZa2feb4qv9QFGufEsjp7upAPUvX
4IiPiU/Q1slNUNfHoa3nHgdraSr7AeloS+s4Mw4r/Y/Glf6HcEODcSXjctOg 48yJXbGA0y6RNDpT4xVS7OXTEpEBlFVKSCgTNeznhyI/5jpnIZB+d3z8VN1P
AklIKEEBsahD6Hraed128ty2E7jf+gOLLFF8HhHcif46RHd5Vn7Knk8eRi7O BihOUFOcTHLTtkW+1BT7GlaaXGJrTZYfzrPFdkvBc4nTOAquDljtN1iZntEa
Hm97pUrW9ZyZglmeefNwfrInR2EFpOyzDG8O4kO+McoQH+G404glv4i+iulX aZp2W470GBujfOhIKe6bpK8lWIGeEOehv4lTXaXu9QKOLpG5WiZWaVF+tIAT
OKpGOFaVJ89PS4wgMt+Hf+bppigV2f5mggdPTnG64vwrzz+XPRgrWlfUGNJz J/zBgC5DeoyceNbtPez8Wts322H77jZ9HZm+RF3FitkTiSAH8EDM/efB4OGS
GN9lcjeHs/huX2dGLCSFlFJk1Zp6LciDajGvWT8aL3sMqnLKWHnQlPyNakug oKBzSqaEVJpHqiiiyuw43otKVb6MWxhylAff/yjjMM+WY7e5+5GB1kX2lmBS
n8eWmEIIhswuUyl6phhVVCwsR/TzwcJ7Om0lfMVLxusFM7Ea4V7m91PXhlCX FoVzjLQlm5ZUbfmYD0e2/+PbZ8enzw6Ure1bJGx0N3bjHL2+hbpqdUpkJcF6
ITWbclgMv2NE0ZbsHD7to0YgCFlCkukLAW+spsUBzPNyIRE4Ckkr462aBB6s oIRrtMf4onEaKi8YFuCTXqn/59pxEIGb1WqbzCNPdCsA3V3+uDlslDGY47MP
hl8iR1z4Bi0WAbv4h4x3wjAiikTrtxuALaDBOGU6Q6W/szXN5bUXDk4WkQ4o KJVkixNOBHZexUH6gywop+oNxvzhciEABRgbMglIUj/lU+DtAb/GpNY+HIed
D1FR5+bOjyRBozMkHLky+cucpHvYzFy1HwXwEwE50GiCTcsGWoSbojyFGMcw Tej45Wmk1kQo2Sk6YB6/q1Kl7Wt8ueRDg1j1q3oNAoAdYAyUJZmxKbtcuiXO
zrenv8Rcfylr3aAwD4WMwFVM51amo/XzQfK6dUoSSLVXtjvwkXjpB9jgIFIX eWVH9E5yF/n5CfYXKOJQZxJUuMWlEjscN81Z6wiB4e3uSg9xZlGB+GfvhQk4
xQeiKqYOKtu1AcE6BkPot4lBkTeLzQeMVd1RBMKYY5vvDs8xrGHmeEgEHveL YXLYhTYnsxCuRDz3GeyoDuliEboMHfn56Q9fI9L4i5qKo4cjpxZ3ko+m4PWd
L0VE/6gXb8I6xnxeYE7VF87i82gIHHYjEF0MJFthgLLPT/1wcjDZfyDYolBZ 7cjzZ5PsNaqtufPz2stdE504QmUsPblqFEYtO+KLcSk6mrTrLtiOgnvO41/X
Xl5cdiEXT9meQVo5JOJA7a6tE0zNTxrurQrGy1LB+lTYvC231TBvHeOEnQKU nlyPPdGeJcNpECUG71Nmj92p13Q9iiaJ2iPZ8Dedc7VgzAQYDopBjUnN2L9h
tqZKOMzBIWAjuBrpCHVQF+tylnPaYSjD6Pu3UMTqJuAAxTvRNNKyygE2gQBb mgg0r6DM3CmFeUxZ4SMefOcEdJkJgRCyTQgZzFTyqQGFMcgazgu/h/NJ3u6g
igc1Ej59Caf3o/14ZjiOndCmjujxRoEkrVWEjAdI9o3sm/jWKN7i2bQGQtuh LAaop89/V1KGBKvpvauhWab+CImDIp4qswAEQuNQ5GRnR5FBYMUZBypyQkGK
AiP9COd+puhIfoPRd3fjnUMUNxrA21zrgVxJ3rpQrUw50m18dWzhUVj1JaXl e8J1i90ODA9o5KK4kZwsVGslQ97LehE/ScABlSANQmGQiIJ1bCAUkYMNs+LR
wkxs+arA/cnxDZhm+kaM0QQXGvw7IXOlK9dLNcQDda5wiWhohmI8XX4hP48U +bPcRh3X+/Xaiz6GBKL417hZTpwXyebaxQICMv0ds+sHF5NAdIU/AaYY2/MB
vXhYltlvyEOgQ/ROGD4ZaFBVQkZioSNcvqRQTqGmMJIxALv0ePyxrbaU0qEt vtvEpVt/z/Q2OraV7PUDdx3fyk6/UC+qmS4DzSjFt7w7JK880kFx4iSdPnKY
7AD+TEow+CFE/QM9zkS0zuxq3m/1VhslontQvCg+y3E82q0/UPB/HML0I5Q6 8Qw+F3ivy61fdv3hbfbH7GnhlUefEr4/IOdCQsqBeHVnI/+eP2anRbdZP4Hx
NIsu6wVVvxlyHoPzfSnxdefAC0oiSKb8W+xzicZK6WRLRC3awEBq18AytRWp n+5Du6OdvH/8t9ctW/QE72X/8z/Z3Y937+L/+pcesPfWuzvMxAn/L2g6O3Rs
vu5MS+/yUMAb7ATOvwtTP4U8+7JPqWmpKbziAw8e1oOpZrsv3r3bGzl1l6TD LyBCjYN/h4DYKRzuUy7htL4szCnzBug8PVy7/a8BT0deHfSMIIoqsslT9/2Q
Eh+7oTSiRebVPjgsPjC8k92qraa4v0jPbZHbiTsxIr5WCZ+jevYI48i5p199 MVuww8e4J+jo5Ma56/3R1nCPnbY0lX3HdHSktZ8Ze5X+W91K/00YokG3kjG5
0F/9qEplclrki90h1XGLx46xqOHdLt76iW901MvNwePPNP/FigB24nlZCVJl qVOBpCRkpMC2qIMLe9Z52fb8qa23c6f1FxZpotgeceiJ/DpGc3lefsyeTh5E
IJenGPZexg7Feu1zyeSBSJawTdKErv/YbEuKcOg1/UPiNotv+LT08IeQ9CKt Js4BH3tlY9b1nJuEXJ550zi37MlZWAApwS3DncP24coemyVTvmFba6LhL6JR
cBYt0Bm3ScGdtIXiFnM/giLzLMAm44UNJyUHEVWeO+nJxPxIosYRV19+KgIr Mf0LO9UI16r7yVPgEiOJzPfxbzzd5KQi3d9M8ODNKUZXHIfl+ec0CKNF64oa
Zig0sSxY4g4zRRr/oiTaU3I5boa/M4BLULcMoUFIDbuug/WhQoAclYemU3G/ RXoB/btIfs3eLP61T2EjFpRCUisyrnanDdWiXrN8NFb2GETljLHzICl5jKpL
dTf5EK3mxepl2RHPaS38TKopSOpgLLuxy7Anh7z4KegGfL5nLpDamNokXaJF UI2NzmIJhtQuk4d6poBVFCy8j+jzwdx+um3Fe8VLxusFM7Emi4jfTwWCQp6G
lllf4ZGJL479CnyctLcpmZ1j2ECz8Dh/iOeVpOducBVc3+aTQIv2jMD6Oylj JITKZTH8jhF5W7IpDO2DeiAIYkI70+cYXpurix1Y5OVSHHDkklZSXVUJPG4N
oKCxuu6G/Dm8lOmtkjC2lIze4sMhOYOpZRNT/hrJUhXlRnpbU/zaGYjCTbYH RyJXXBiDJo+AXvxdxidhGBtFW+vXaxAuIME4dDpHob+3M9zlpRd2ThaRLiiP
Fde/4Us1ohJgpp6ToK2p55DlQM/4XVdlvVBWoHAfxfVcYoCaavx4kdkdHHJ0 VVHj5tZN0kajOyRcuTL5q5x297CauW4/CPInQnSg0gSHlhW0CEFFgQpRjqGf
PAGRnEiyQHfycruBWlqckyWxVHVmlnDsHgrhp8fMAsxQyIvOhFIWw+723NGD b5piLKSImAq5/+b054OYYjAlyxvc3UM+JLAd08mW+Wn9BNEG3jlHCeDaS989
McVf6clwvjG7myvhz96wK/G2/dhaNkI5uIc9pH06wAMFDvOYI3jWiP/GxYTp GDU++h5OPOyx8+I90SNTVa3d4oEAH4Mu9Zv2RZE3y+17dF7dck+EPsdK4C3a
Q0IbiX8Yvd/B0eOCoRlUYYiQ9+8eZd8ejM9LsHXXlfQUUrotIb3PteTtfL5u MTRm5r5ITgAeIJ+qiAZTzwGFeY75osBgq0/SxfaoC+yHI3xdDDFbo8eyz4n9
KfH3AXPCRfcBvLezSfay/FhgGnYU6Em4YhTHxdqFvsBt/4KtsAVYubdCtMhs YHJvcnhXUEchj708v+hCkJ7CP4M8d8j9geJeyzWYpKDU/1sVjKWl9PiZMIhb
C3CJzdhHUMIhnaMJIWfAbzLNXClqyK5PPIOyhqA82DiKfThfmcR0gALA+Co9 sq1hIj1GETuFLu0MnbDfg33CZuOq6yMkSp1vynnOYYihmKOvGEMurOsQBeQA
EBKHOi2m+AzfmBCJ34KDRFX9ziBI3wr08pQQpKC6FXRKluhwPKQ1wCDVJ3Kb RV1J8y4HyAsCoCnu1Eg4/MW/3nf/4yXi2JlCpzzi6wukba0iZzx0sq90X8f/
SXN6yjU3aKhM/PEthQAfs35X0b51QSUckkELwCf2YvE1Wwwtw/Ek7HOKObUF Rv4Xz+414OoO6RnpGJz7kbwlu3FWoy9Q5tllca1CvMvUHoid5K0LycwSNDU/
qdKTKgJ2ef8W8Q0mFol0CXxKh4All0b1Mb1wIOCuFdrNAJFkFS4tkTFbflXO Nvx5rPGRm/UFRenCTOwYVWAcZX8HTDONEX02waQGe08oZOnJzUoV88DWy6/1
1mCV2qwg9X6kTomDrUsz6SSIk1w2xrtbtyPeYqkKHWBZQISajN60l+TPaM13 rhry+XT5uXweCX6xuCzT4JDFQJfqrcB90tEgqYT7xEJKOL1JMZ7Cg2F2xgAe
yDTpVwmwTSnnxev17ZOCAxX5M3Vj3+e3ZAUzCfL5bIMwHYawCmZdT4zg9Cqz 04P1xzYbU/KKdhAR+CspwecHl/V31JzxcJ3Z1bzT6k+t14h+g9uL/LXs16PD
BRzDaEhq5Bw9kcCxjpXQc7BZRZ+C30lRCXTIzhtQs5ghp0iUPg07T/Aewkan +h0FA8bBbT/CXYdq0kW9pOw4wwZkAMAvxN/uHFhFiUfJZIeLvi7eWUmtbIkX
YjG6v+xgS+Vv9if72E3u8mDnr7TXfyvO370/AnmYlXm4qc3+snNdnDfdFC+e RmsmSG4baKo2Y9XnpWlqXh4SfIPewPF4KQ5ALtD+3qdIteQcXvJ9B4318KvZ
juW//+pj6D7rn8/SeCrisBEpgDPLTFe4WF3d4dJjBYwifIQXFN9nDnbhQ8Lp /k9v3x6MnJpPUtKJb92QNtEiE2wfNBbfF97oblV3UzxgJOZ27NuJe262+EZ3
sETzYRLIEubGlLqAgRURe+MmXCKRCFqTVJrn4Tpxd51A4qFLJUkCrL6Jxowt +AKls4ceR8Y+ffVev/qjCpXJaZEv94dExw0WPPqmhk+7WO/PfW2lXqwOmj/T
EKN8wJC6vN/GVJ/BZrGi4rMSMqNq93oPHwzeswF2VY/v9uetsky+VEz+4G1O eBgLAjiJ07IS6MpAbE/R7b0IHm7rjQ8tk0UiUcM2CRu6frPZjpDh0Gv6l8RN
uQv3tai4rxnFoS/I5BzOdOgZIDSl6DnKKjwfYSARaa53H4xgMOPs+Z7g6M0O Ct/wZenRECEIRlLhLFqgM67MgidpB+UuxoIEXeZZiU0EDOt5S0wiykx3UgaK
dAfbXz8rZzTtWtCxfRC7RMUKdpECL4IxPvUNXcncrEzTzD0e4cvs99mT/sh8 6ZhEjCPgvvxYBJbOkIJiabfEPGZWNv6iJBpWMkGux8UzsEvQuAypQYgNm7KD
6LlsY/1/62RU2UuGAAp36ZAvGO0bZdT1EJeoZgoW6CVIzUtiLrpMuT9vLteS +aNCyBylj6ZTcad119kUrcbJ6lXZ4YtrYYNSQUGbDrqyH1sQB3LHi9kCVgDc
tnJaiyG5TBJ7MIrmeUMLgI9/nf2YfbsPq7S7i2u1v5f9P2AgMWMuztLrgbXj 6eYBSZqpTQwmWmOZ9DXemPTeyMzA5qSgTsncHcPqmUXN+Ts8ryRad42h4Poa
Clva5ekcbRuWct553kC49tsDIajmIjnvjzPfn/cGhZjXagbZn7xtNWxNB6lo n/hdtEoF5uZJegP5kNWSN1zU4aVMppV4tSWd9AaTDrkbTJ6bKPJXyN2qqDcS
hL5FqVs6r2xzZ9QyaCZK3N3hugQnNZgkvusxBeHJ+/bH2NjSaLdx9x5HADnN 2xrx11pE5H2yVa84Nw5fqg6WgD71lAVtTVWOLPF6xu+6LOulEhCF35GbzyXq
LoB1TsA7o5eHsyjBxhv78CmjN7QEsCnABhAwL8eWE/oBigbIaJOvCJ9MfZLO p0nWjxc554UbMHM815FcSLJAtzJ6u4E8W5yTFTFidWaWsO8eGeGnx8wCzFAI
WU6QiIjyuZh3ZqrCjHs4h3VHq+t5CJST9XjoA+Vgdd0QRXfusBf577EpReYt k86F4Ra98Pba0XsxRWPpxTDdmsPNifJnr9mQeNN+aC3/odzbw/bRId3fgSCH
UTCzN8/PsSmfHoofD2TJDJXd1sSQwfrbg96gQbERLTZ9heNKCYC9DakTOADo adURU2u2/9bF/O1Dmzba/qH3/gRHzQU9M0jC4DDv/3qU3b83npag6m4qqWKk
MlAQJAmLV5FIWdTGdgRfpYZQ7EVwzEa/1BrN+LR+5XxvOIT/Tm3tkAOQaOHZ 1F7CtJ9rLtx0sWkpDvgeQ8RF9x5st7NJ9qL8UGBUdhTYSzibFPvF0oVG4HaP
lqr61BuOq+oJbiSN5vjIszjvBeIvH3sV4c6s58++zllvInwx/MBE9CZq+GMH YCeKAVbujTA7MhkDPBIH8M0BGZI5Gh9yBgon08xZpIZ7+7kndFaPlMcgR54P
WBHsJzPc9GtI+Qn+WBUJRPNOqzfXcedeD3aMzIaN+TgaGHk7Sc8h5X7ewSqT 5zOWmH1Q8BhfJAdCHFGnxWSl4RsTXvMbYJEoqt8aROkbQWKeEqIURLeCUEkR
WfGhQMpAdXTsiwbW9N9nS4jX1tm17QUKvnYhnfcqo4XUcA/d3PYCaX5i2l5H HfaGtAYnpPJEfmainp7ezQ3qKRN/e0t+wIesX8W0r1xQZocE1AIOKhDrnO1Q
KQXIpRKr41As+fCkJQ/uh2DuwHOOClDLA6hWcnCEn+9FI7rrl/cbOhkfnsBY tAwFlFDdKQbV5qpKGawI6OXtW8Q7GN8k0inwLR0cmJwz1Qf5wo2Ax1Z4PgNi
zsSqRkOpJQp9a/P4p1EUiEsJWokj0QrNOAc+BEFMDDNUm4jdZpa3AoUl73XP kmU4jfiIoueX5XwDWqmNElK5SSrOOFgrNZPihTjLWDTcW3cbmBE6Y6kMHaBg
Mo0A00febw2TC7EzzkbMqxH7nmB/V7gCKxKgS6QlDyGmh5P9GMXl6Q/6h4GS QMSa9N5UtORhtGYcMk06KgG6KQW+WL2+YlMwoCJ7pm7s+/yZrGAmYYM+2SJs
YKXZn54Yxmwrt2oWm3phkv243GabJXdi7s0H0kVSwxr51+nYNV3M1mlaxBMj hxGtgmXXKyMYvcp8AfcwKpLqSUdLJHC+Y5L0AnRWEahgd5JXAg2yaQNyFiPm
3HrFQrIMBDi5E9JVMl0sUdRPUD/jayGsA0jioaf5abkJ3uk5+ekY19lWSDLm 5IjS1rAShnCzvXjzSjRG95c9rGv89eHkEAvYXdzb+ysd9l+L6dt3J7Af5mUe
BTfgNEw78bCJbGmSlj4ilO7cgyQ9Yob7xeaLIcibmQlKKUh6wbes8NZgyuzA ftRmf9m7KqZNN8OHZ2P57796n7pHAeTz1L+KwGxEDuDMMhMWLlZXd7j0mBmj
tvdqo9LSA3AOpw95IvEEM6WHftY8/uKuIGLCK23HWYSNe/sSjKQlHqeqBoU5 iB+hIcX3mZtd+JJwOizxfZgE0oS5FqYuYKBgxGK8CddItAWtSir1+nCduKBP
lA4TD3AbzW6KdeAJ4mS/9c0jcncx5+RgMiwrTKuMKewJcUK81/yiPtKTV1tS YPjQpZKgAWblRH3GqotRfGBIXt5pY2bRoLTYreKjFDKjqvd6Cx8U3rMBNlcP
dw60iIkMcuSL7BhuR24bPk0SRwSERPtgWoSQLyER/I2T7F0RZjEaAZFiM5hJ 9/YXrlJavlCQ/uDPnPIkHmq6cV80ikFfkM45HPnQS0BIUdFylFV4OkI/IlJr
y17T7UF5RTiQx5fl3+DXtD962HEFumzNNiftIUMyCTQGZfVjupibhC5V1gxg 798dZVjo/emB4OrNCXT3dr9+Xs5p2jXRY3cnpIR5uVAgRtDGZ76GbMZpjqFO
ShIXUXmGN7dSHT7JYjIJWw6E/BDagdCavfgosvWDb8Fg5NtwOqLb7bO8rS54 5wH38EX2++xxv2fe81y28QVw42RU2QuGBApT6pAtGJ0bZfD1kJcolwoW6AXs
NGkWET8+3rWoTXyn6PQgvmt0+iYzQUthI/uifzL9jQqDbjcT/Ak8cnFxrU7k mhfEbHSREo1en8Yllew0OUNim7TtQSta5A0tADb/Kvtjdv8QVml/H9fq8CD7
DcjZgSx3v4kLMxyYR3P8Mz79EbTa9ieSPVXcRfB7ATvQNSAOlG0KUb64xkUj X6AhMfMjztKrgbXj1Fs65ekc7eqWcuJ5WkF49v49ocTm5DlvjzMdoLcGhQfY
YQygjanZ4is7at1MO1k6BhAemal7UV3NylbL3HoGAIZNF+Wdab3uwkiYTIEw SgY5n3xs1WtNN6lIhL5KqUc6r2w9aZQyqCeK293hugQjNegkvtAy+eDJ+vbX
PnORD/l60SHlmBEwzryk2ZGeAA76Cy6UCAp1NOIdEUxkq42IlMwnDfvDxSll 2NgSd7dxNSFHgDkNLoB6TkA8I5eHgyhByRt79ymjOTQ1sClABxBwL/uWE2IC
dmRyi3+CjQNbqsuRgxlU9rL8h3SORGP0+yf7jwU/SAsQp5dQbbhEcPRDg+Qo 8gZIb5NRhCFTdaYp7xNkKaL4Lsahmcow47LRYd1R7XoaHOWkPh57RzmoXdd4
Zitq/tofl5AE0KAE14cClLayIWV5MwlExADnmP/hnDnUNN+MKPu002mv/24s 0Z077jn+e1RLkX5LjM9szXM7NuLTQ/XjhSyBobLbGRcy2H970Rt0KNa+xTqz
SZ6ydCciSeR26hgIQjSbFiwKwblEgTykLHR6C5TfEUY1hQbA/rrAEjiJGafF cF0p27BXInUCBwBeBhqCJGLxKhJjiyrZjuCsVKCKzQj22ehIrdaMrfVT6nvd
pa1shsUm1E/L8/SYOPE1fEyCOJSMoy5WpNgpxRDm1NgObohDMWyv+K2hBlpa ITx4qmyHGIB4C892pNun5nCcbk/wI6ltx1eexX0vEY/5yIsId2ZNfzZ2znoT
UkgJ9PY3Ma8qJlVoI52DaU51lnSOlAgHXy3qDT4kaaA9NS8ieyTkXHkwLoSG 4bPkByaiN1HDgx2gS7BDZvjpl9QBIDhkVSSQzVut3kL7nXs52DFSGw7mo6hj
GR/hO2Treb51TFo+jQshdZgdsXpjxs1noMzzy3kQE5pa5uRjW9A9f31KjZts ZO4kNZCUaHoPs07mxfsCKQXV0rEvGljTf51GIV5bZ9e25yn40oV03qyMFlL9
l4mKOnlRgZ920YtRwwjsK6fcVbhyydipvOXaDHmijKQDa0X9BYqce/0o1eac PfTjtudJ8xPT9ipcKWAu3bHaD8WWD09a0nDfB3MLVvU//Md4nP2lWcyK+V+z
4mpgbGFLsNBZFyaZKTIoZQ7SPPjEKUExNpypwCmc0nl4BQ+pGZsixEQtJy9s 54kdRAFl5jAhAbE3sB32fDlIR4fmT7gAW2RGQWl3VShPfNAE/uTcCbPYHmXu
r2EKdXqFBgoOtPxsA1uos5uOnhntD27PZjFE9oEE1JjW9UfT184nZKiDDRzr X953LrWzh/cduSEu8nX7Re/UChe9N7shC3/Hjs+w9jFfNZqYQWmqg3vh01fR
C/ulIxcMu8GPFMOnLQZvt/wCnRQBeSmPpoP0SWVaeItysFTIqWoxisMrDG3Y 2t92j/VLeRl3CcHgnHELjoaCeBRkEOsEtTXjcOMkjlZcdjRhcwYbDIE/ExUY
E8VrNKlC+3FzN/JeTePfeNhJiXw4Z9wdzhnei6S4yBAzakrOal+nbNHcpU+g LyhEzTPZXoHHMu/VTTOFHtMm77SGTId4MucjpjaJrXywdCrc62tazwtkmw/e
3FVVWRgEPoE2l7zBKCF5KjFxcag5muidlF03NyvsOFwsbkt8VfyUSQaWqRwv vAeTwxg/5wko+teucpGlcbbegY8Jb26U4TbIxYciTnTapTM/N7/NBwJzkj4c
ya+cZiPBi1z7kuvc2zDKmxGQH1GzvoGmhJwUplSFT7pgfTGsX9txLCNW1LV/ eTLSvmtgnu2ANH0qxhb20rRkGQjZcyuMscQUeUdRJUkdxpeChwcw3EOt+Wm5
iyI0sELrkrKAFda+SacYe74cagJUmAWiyXbb73sWcIfohKSNKjOtP3DBeiex DljrSy2QwqSzrWBwjMBuwTybdeLLIMKrSZpziiDGqYenemgSFwPOl0NgQzMT
9bZjG6CLvrsM7r6LJl9dmnZ7ouEvhyQsmIM+ReNfR4sT6m/g7KREPQg6mluJ qP5IHMeXIvFqd0qtwUbOequbpYec7QbjtDyPqCqYnE8/aR7nclv0NuHCduNZ
DeusDcvW/2HfDscbuLyWWlgIE05kaAvIcJsTwHWw8EDtyrM1/ubx825byrLk wrm9eQVGUguRY4KDezmkbBMhcxtNbgoq4QliVIV1gkQk+6I3iwZgaG6Y3xqx
wr+b+lro5qBlIUwckXqwfWWIcAbNLBoFfy2+ehRHxMa9Ai14eznfBEGfIkZs AhMi5XingVxt0rOIW3J99miJLQLbyGc3Ms6R7GNsTUJ0hEBFRWxWBOc6QT78
zs/3rNkIVslucWi4ALeiG0wB1TZ70HHiGFawqVcN1+aLFzfOUoeMAoJtEBcz DyfZ2yLMYtQDYidn0JimG6engwK4oPmML8q/wdd0PHqgfQUU7QzrJ3VBQ9gO
yL65KpFFtTrhRRy4ODJf5rXorACpw9Wr6oGHc6KTp0iXOIIceHq8GwbkPLtd BAbBJ2K+nus2XSqrGSiWhIiivBiv16YifJLFbB42DwsJOrT0pLUvsCkyqoIR
ujjsNYHxMeYApHf+A8ru8+f/AGP/u/2DR5asRdrETOsGtgd+j3Yu5TxrsHto xyjwmwBRItptW94oEtyfVACJm49PLQoTXwU8vYdvGwe4TkvQHORIketfTH+j
t4IjFiwv9IA+cQLfBDK/5zAm0sh8++TxdxL5+fz5txeH73/7eXzy9k8PQTSd jKybtQR/AY9cnNWsE3kNZHkATtCvzcPUEqZpdjTHlz+ihdv+RLJLAE8RfC+o
zC8l+6S3KrEtk7VxbvoWcZ3+ydurh2Ekk5h+p0AQ0lRQzgiFRGdNkps3iJkT EnoGtgPF9YI7NU4uUpcjI5djcrz4yY4qc9NJlsoNBARnAmUUV/Oy1fzC3v2P
bIhWbHGvMJ5zcvfIkjRuCm4d34ksQKvhnsRnt2eLVxx2tYJONJsQeVX0Yg61 /ulleWtitduQQiZTINTbnF1FRnV0RzkmZYxjXGkcqrcBB9VUF3IzhcMbcaWI
cdgTHb/EXvROnmg1ohizFkveuuCJ+ba1iZ/erybXSjuyshhWzLjJVpiUtYbb 2rJpXkQL58Oz/e7ilDJHNSnIP8DBgSPV5UiGDSJ7Vf4jD1U9v318+EhwmrQA
tyvqOyPvyY6KBgOPJF5N6SXhwBS94OaoaJS2wwxHKf172SrMy08GnpqoUAKi cSAPxYZLNo4ONOwcBcdFVX/7/RJyBuqUAChxA6UFiqT96rrZqxIePsfcG1Nm
iigkcUp4GTBgERm9amGALSaEMHwaoB+OwM2m5KMBuYuWq95ijoLiEHtDO9/S stPoPqY4pGVue8WX493kqWP3Iq7KPeoVet0QOqjZosI2Ly43j98LlfwC/3qE
FEQdmhLDxBQx3tT90zaOz5RUhCRFFCi2h2MhKhFYhvsckX6V3ZJ8IOiOJG6w B06BGHDGzjH/UBz0aWZvKwdiuQ3J69KeXhXPfQIlU1EOGkZYoYyEO8VzzJz6
/0Td8P743avTH5H/6+GTJ3RAUFIoo2Z/VLIjOjfIKw+EkAbiUsDk1d24LfCs i88NEVmGExa/NOSfS3kQST+/5kWkb2AAi87SFJRzynGlq6REKP56WW+xkaR4
JjSKIXt8+fxFtsjBiac1dYN0ZQeTbzkLhOro0eMnDygRhsc98TOyKMkj/T45 +sy8iFQS7geKP+6MC254BqP46uh6pe/sk6au4zpIDmxH9OoY3fTRPtN+uQi7
Ly5K8tWKoI6zw9OjkxMcDZmWcC/KLb+eOU87QpNl332bUVPe1piLkezHS0Qj hGaWiRFZHXRPX51SRS5b8aNi2xuTK7VGYgzQRhBlOeOK0pVL+k6pRVemyxPl
8MsiiG0u0oHvc/QCzfWLMUbgGny7DAk2L/xsF1sUZvcf3M8EGpndf3J/D7+i hR1YK6r1UORcwUn5ThfkwwR9q5ibZtCnzPQkhE+AzTzY4oxwL1uOCuEUzuhK
bN3Og087+J87D/57R45VaWNS41kr2JkNnzijaJbpJe4S3OMZuJNLbCZ5wwtH vIRGagYCCStUy4EiW2ea3MpepoGMA0E/38IJ6uyZozaj48GV9yxeyzZIqJhZ
2f3c/GB+nw3x+4f3nf/hT/f3tJsohbqjxU87Zsba2al2XpTws3zRivl0wj0q XX8wNQt98IuKCcHNvrQjHbmg2w0OUnSfthj8ueV26CQBy+/yaDpInFSmfLvI
MaNFhj6s/E/cruwoqAbTdO3wz+R0W0DpAlySStM7eWZz0aQouf2Zs6qm0w6W BstInUoWIze8vNDaSZFvTANYdB63t6NQVszEtfed0BOEq8bd4qrhs0hyi3Qx
pvFjjCNLIgckOeeFWHhTPQlgxHEphyhItNSEAyz0pOR+ZXWq9TRLS0UQmoKw I6XkuvY54lrIkGSoD1bdVlJZzAm2QIdL3mCEkLRKNGjs1o8mei/lOM7NCjt2
ugT2j6IMHJ9hPofDVN3sIi3KJZ4MOAmDbTHQyG/BifEBvIQxh7VIHDHVOpDY zYvlEj8VtzLJQDmV2yX5ymnkFwzJjU93z70ao5wlAWYTlWEcqDfJAXgKC/kA
g5G4HkZzCE7acdDpb57dKsT67XdQRNTRVsNGfotN7NmYify6URjrh84JDcyw F+Z2w/q1HXszYkFd+7coHAaz4y4o4lph3qFU7bHXy7EGm4XVIZpst/t3TwLG
hVnrGGjHEPemw3KRRuE4Hn6Wul7oSkj5n8NtkwTcLigpVs1Y86InuhHZQUwV E+2QtAhppqkeLijwtG29+tgGmKiv9IOn77zJ1xemjqJI+IuhHRY0Qh8O86+j
h74OuZEmOWKzSGi1zNBQRHpr2tR81msQNqfNlc7rusOep6vEvg3c92TcZad/ xQmpTnB1EigCNjpqXIka66waywbAcV8Vxx9ICXUsJyIsRJGuLYjOXXYA5yBD
OnpGqZFyWrxCx4xRXmDbwaPHJ6/HcJG17mgwLD8UfrrMtWghDB7vJNoYmA04 g74G2S4PnM9VcLvCwyUnXV5XYATuicpARHBxCIboUhaiQTWLusHDVVMj+MTG
RrvCTC3vKZy+KOiWfkeCHHHsuJ4juL8Iy+CbUMmS1qEG7rqpkdfcWEjaA1Bj veQ4eHu52IaNPkNA3oKb99zlCAzKbrBpOPm5oh+YXLVd6qDjID2sYFOvG+ZF
B9LqQVZggzaAPHfiAr9dG+uMeJsKepjmPG9NMMtpMCs9svEdtkivnBdEq0q2 EENunKU2GbkE27BdTCf7Gqv4FlXphBex7+LEjMxL0XkBuw5Xr6oHGuegMk+R
0BRbFcKGwHZtrMwC8bl3dRlHpK4ZmuYuiRm1fonfnv4ieEguN1lI9CefI2AZ LnEE7/DchNd0yHlmwaG1ybFc3JhdkN7+D5DGT5/+A/T9bw7vPbREOVKyZ1Y3
w6aUTFbLt84wh7ZEPDZ/J+8RKqKnegBsT8Qn5YaVT4XhS65JEdgtytT79y/b cDxwPFqTlmPaQe+h0wq2WNC80Aj6yGAJ48r8lh2ZSOFz//Gjb8T58+nTrz8d
PflWb8whg2FML+eIsTAQHIbaOmEshLvMb0N5gu9Pbaww7c8g8ZzxNF8x2R59 v/v1x/HzN39+AFvTyfxSYFXK5hLlNWkbU1NDijkSnr+5fBB6MompjwoEfM0E
nJTIIxsDPiqQCoWyKhRHyaqtUeEZ8Ck5yNSIhmvJJKTuxZnYIbGSRu2klDNS UY64U7TXJJB8zTZzgsPR5Diu28ZzThYfaZLGUsFD46vCBRg7/CYx2+3d4gWH
6whZGrKfpaORzxUoEoxNxNZqIooYhYMl2C8k6bmp+jYVWfkVWKm53SEq9CFY Xa0gE80ZRE4bfZi9bez4RNsv0Re9nSdSjejdrMaSty4YY74icWKq9zP5NamR
FhenRSydd+7+2IejpB79qTiWtl7bUMxr9eWG3Fl7ua1Zt3eEDMi27obc+1lb tCzGcDNItRU2a82f96Wj+rbIO9Kjos5Ak8RpKiU9HKii51z1FpXSdphdKuXg
KOJgvWEttHyfCjgXW3FK/PPi0BeTNzEoBB52iQMgXApGwnFWxRnCkpXEXEjt L1uF1PnJwFsTBUpArxF/J04JLwP6LCKlVzUM0MWEjIdvAzTFMTzVlHw1IG/U
Adv6IFOPJ/5cYnPozctiMw7162yrR73qRLt9LBCXAIK2WnvuEgIb/HL8Kn5N at1bzFEQHKJvaE1jmoKoWlaimJh80euKumbWt6OELrRTRIBiqT7eRCWC+PCc
wq+77VWhEO3l748Eji3hsyPnMfC8RIRmKD6tctuiN/A7ECCCGfxJfH0dglR9 I6qyskeSLwQ9kcrL9vjB48d0K1AsKCNQKOVEiaANm5TfTlAOsSNgxupu3BZ4
SKRlG2TFBurJj9eK5et+3S3jleGB+RRPMDlgTacBDuv5XN4A1qEfqx1Gfmks QRPcx5Brvnj6U7bMwXjnhXSDBHH3Jvc5+oNC6OGjx3cpAIaXPBFi8gaSNv3p
NHDoK2j/DlvHA3xo86T92DW8MgUbnKG1lKGQMimuWvDVsd4MUUqs7VsX4+5z mBbnJVloRRDC2fHpyfPn2B1SKOG3uFv5/Uwz2xFeL/vmfkY1llujJEY7Pl4Y
RANIz+VSeukSVbtWkXLzjXywB+HJkKF11+w4+zb956K7MpBI2J4tN5AtF6O6 6oFfDAHFcxoUDNDRCxRNISoYwZfw7dIlOLLw2T4Xibxz904m6NPszuM7BziM
SMN/ZWo8U4JeJ7FBCmKE9BK7bwnyNYYZtGJwuDQJ40uBBr4PpvNNKCcWFRwB snV7dz/u4X/u3f2vPblNpYhMvYL9K/CkLV80o2ie6S3uAqziOViRK6zned0b
7aTUpS2pIYwpPq5MfaIRHTLVhXe95cybodhPezpijo3QXFPQJFFlrUONlxKJ 4YPcfLC4wwr4neM7zn/4w50DLehKXu5o/dOqpbFUdiqVlyV8li9bUZuec51Q
ispqQw7UFEdyvBxPNwbYmNNte8/xqApRajveFSRbEUGh1G7jDqjQ3ucqhws0 3HKk4NdY/Zfm9CSIBFP47vg3MrYtaHcJpkilgZ08s/F+EpBcgs5ZEdNpFVFT
MxvpwI4+kjHDoq6dbocNih2VCab81mqZNDM+YkBRuyqFDtqeiuLNgnSvWmVf fDPG6iUeA9o700I0u5neANDjOF9GBCNqaMK7FuqCcs24OpV2Gp+lTBONPlgZ
UstJInoxv3TrhNJvsZES8qiguvd2bEslI+cDy3kWE+kGTJqj0WkSJzqE/MFE AkdIo9uO7y4fvmGadDaNluUKbwSchMGaJKjct2C8eN9dwlLE0iN2lmqyTWy5
Hvs25KCiwLABA1THMDYxrij56WMUMWerzwnf6XW0iNyKXlqR98M1PWHAST2N eJdbuSLIbse+pr95RrHg5rfjIGeoo8OGxRSX29iiMRP5Zb0wWg/dD+qQYc2y
Pjkb+mTHeVQZALlRgUBsmXF3H7ixwHxPf1on7qY5aJNJkEijTYJJ1tiRHS4R 1j7QkSG+U4c5OY1CnjzELzW50ISQFEuH5ybxs51TPKyas8RFC3Qrewdxa+zy
XvQaLio8w3AuBvqvU1ov+jRhA+boLhjQsgY+P9N/MQJk1xgXaQnk0DD3f8MB OuZipmSAzaNNq6mchpbTK9Emr7bewGZzWttqWtcd1p1dJ3ptqDtASl12+ueT
RudRryyYsgnw8MMeGbRHsVE6bhs4OZAffiQTB4+hwNizDdL7GCtXJzEZxwzr JxQVKWfFSzTIGEnHcILffvvt0Kp01BPePORzusg1LST0HHo0Jp4emAq4O7vC
g6tpJ7YOemkYr6W8i/GwBBUo7pE8FUPNMTaCO1GxMsPTOoSQxwsY7MJ/qQJ5 zCsfKJy7yNOWDiKB5ji2VqeYPlGENfAVwGQ965BkeNXUSChv1CItwqgOA6mx
lY1XmnXK6TebfM0nIJ6EVbyMGN6MLd2FOsu4iRQZHfC01YKWlKgYLloV1MPx IdO/xYtf2p24QCjYxgIjPqMCz6YJz1vjwXLqwUrvaXyHzYIsFwXx2JICNMNa
sc6iOKP2DiaDHINDmT1JYd2kXh89fomJiEuKENAQxnbZtgIEVb3aTAA8qTR3 kXAasFgeS7LAOO/tWwavqD2G+rhLHEWtX983pz8L4JQTepbi8skXiAhHXykF
N1Rp1dWrelFfgAmDAVNVPihIqwVCaq7hBKgXuK5ah9QaLEaSZao9vh5rSsaB kVXdrTOMna0Q8M7j5ANCJAWUcIGVofii3LLkqdBnyVk/gmvGDfXu3Yv2QMbq
ImTinhcrMbrqOI9ZLyQjdRYTZJ1lvqud4mW4087wq8H8LBgsnjyH+qWfEVUo NTikjIz5/BxRRAZGyZC9KBSR8Cvzbcj/8PXBjeqlhTFySjQfz/I1kxvS2ISC
tyoeyfx7uORd+wSz34COdkccoH0EPmK51O3i1j4pVcpdhlkqzdBtw+wVZJGb AMkusKVA4hTy1nA3SjBtg8LOgHvJKKYKQJysJ150v5uJjRNTlVQ3Sjk6NVGT
38Je6oiUNuQVksniIxVErCip8iPiITjjwqPbxmfTp5rJ3A59zU7LJcxLQ0Df N0P2o5SS8uEBxR2xWthaKUReIsMN4bUX2ui5yao3KW/5JWimuT0guueDgyzO
dIzxHLmbR5fdMjpe5MEOxjcAc3HeiLDCD0qxe7ALWkY5yz5gf1f2s0LcBgil /otYUW9derMPQkmt+FMxJm0+vOH01/TWLZmw9nHLCWB/EYIeu0pLcu1trV+J
fMAxZN8T6yO6S+gfMpAZM5JtK+a+ak7+hRUbebIlDiQli9BekitGBpkjg4xG nfXKtNAgfizgTmzFEPHtxe4uJstiKAg0doEdIDQKer9xVsUAwpSgRFVIdQFb
NoPNysdscHGEp4bdh+ExJsmo5CLsucjFgpXFsXztCt/eSIZ0MCcgDc+HaTDn ciJTKyceLrFl9OYl4gdg/TyqEijC7UOBcATYaOuNp4YhjMHPz17Gr0n4jHe9
+QNdwFZUGKMlWGp/g5rGrBTn4o8a/8SbURT253uD6sa5X1fEqIUTK2b/3Rwt KmT6vfj9ieLj2GV24nyOAS8RgRiKj+vclkgO/BmEg+CSCbR9fZ6HZNWId2UX
OufoSIrpzbeqbUPoKLkFqn/2pbXgV2MG0xmKc0XCciQSD3g/5a0F7Vjgbrpn UsU658l214zwq35iM+PBocF8hreXXK6mtAO78nz4bgDi0PfPDuO91P8ZShZo
bJk8ubeYBWA0J0K1rE9OVChkX9Phi6Qo5nPutxG8zNQoSHcstFk4Mh8TWvql UsQtjo7H9dDhsZAJqfI5Z5N9KdBlikpIGhpnhfj0Y6+CKAXZ7qOLvvYFggCk
XSwKrTQiPwTOvxknYENQWrt+kqW1wI7mJRq3lhXEQPTw4DTldwWY1jMp+TpC 5nUptYyJGV/TdLnoST5Y/vH5kJJ126A4Wzb9dtFWGQge7A6SG6CWi7FcJOG/
9nDpd262go+Oca4An2+YEZEwBKtLuE15CPhR9chMTWVK8lchrdZNL0fSwI7k MCKeKSGyE38gOS5CSImNtwRZHKMLWtE3XBp48alWA+OD6Xwd8rVFBEfwOkkl
039XS3X+R/zhFARLHuxNbXuTlhYiJZxfTa7UYYi1KcIw+U0fhYPZP8Xg/Voc aksqxGOyuyuTAGq2DqnpwnPfcrTNVDRIq2liXI1AXDOQJFHqskOJlxK3ishq
VJItDVQv6inlHFsxfFgRE5UKOQRiaLut0wZqdko8WVtD8hG+FF7rCC+mskCR Q9zTZJ+yjzzGGCPirViJmrfHLfMWZF5XUU8L/Q6ma3+9BNG7PFCeAYUlm7C9
IF4pwyfpsa6+p6vmXGL5zF0yg8qq2yOznGS/Vgt0FQW3G+LjA+wuVFPmgxG4 YuRsuvYbjJcXFPODW5ty3mgre8+Gy3GDs4v0tYDMjtwJkxsut2Pj7YnCgN5u
ZRpt1B0wfilbMKlGza1wiIm/Sxw6Hzqi/uXCQVVfabBtq/CPLIIByydYBG5W j5ljJwHYHBrJ+o20N7QyHn/PKgGDkYxK8OkTbyFT/mBc5lWe1ECQhKO3BR3I
rIbCJVCAReMg/FKpUpuktGxLoLgNjum+4/prEjXxkcNYI2U3tPExkT1b8xxW iEVTGAXw/RUaSJx6c46qOdlN4kIzqmtUZdbtsRK2pweJeek1hStFEIwYfNWu
VW7WAr9EkSgIz3O0fQIvvD+fUbsbr4W1di/+Dl9kbVB8TXmFz0Pvpf34zvUY S+Est6qEmP8gEtatMoLpBInrMyZBb91MZ1WIDaI0/97bsYaa9JxveefvM6lf
Yf2LEnidMoBO+7053u0m76UmHu2N/Tpua9VxAzOooR19A57Bv0g76ulHB6dM TeK20WkSr0OIjYBZMeac5ilYGTPU9UFp/xdWVquq3uZ9tIoUVKcofo0RJcoU
2EeHykVt4/fBBqdbyp+KtD+hJMvPMFl7Fg5BXIQwtRLwxtwXChp3DAuzh+Ym MC6u3m7AWT2NxpwNjdlxxFk6QIZnYLVbZVyLCn5YYGSsP6+TL9re4pO14UKJ
0uNSmD30dTbUm0apnMxd0Ly2tuomGRza0xOXlMN7NKOpve0XAWIwZjtj9e0F rzsyXsQXjqbWeYU3P86FH7SVrenQhLOa/eBgdcgZ9ZGs/osRTLxBT1JLcJCG
vr5xbAuuZ+tY/ZBfeLv+wZhpNbUAXsm6E4ExW9jcQcNsgJJTOCmOlHkNtjCi K1Q07Ip1HiHMO1NOAaoMWMiFJFuJoINLtJaoisFIJg6aIWfiky2SThnbQCcx
byX0sTrBB9xvBgSOTFj6Lt1mJdQlQSZ6oRgdXBIChyRHwgc7pHBaXhKtNiOl 6cccs9arWScaIpq26NmmCJUxSwVCKTaltIpO+RhFwnXT+ApAHSc428dL6OzS
UDlWIBzs8HRVbRaTL5aihvjImlhlrUgEJKFHFCAOElOnlfLKlh7dESXFykBp j1RBz8oZLbVlRWeYT75kCIi84YtRegxvxtLUQuhmbGvyIQ/4JlRd4NixaHua
GCYMTBw84ECPrfKS0OvaQMVD000WnmZPA1Eaw6Go00Ss5dT+6EvoViPYtKKj qtbDPLLMItes1romKwa9aZltD5ZNWCTQRSJOJDHjES4b/P0u25EV40WvVrwA
veppRUJrhmt4zhgjNFjKdec+Vc73qdIzqDR4co6z95uJwemihLVzjQzSCF2v 6zMNcg6l/3X1ul7W56D3oY9ZhQ/uo/USsUdXcG3WS1xWTY5rDWglCcfVPhUB
nDL5kH/JL/KPZ4s9rspIXkC7F6bhOm+47rhf+xugoR48HTv5SslqoxukZLeQ E53Ggbhm4p4Wa9FU6zjgWy8L5VuIWNvOMl+CUYFFXA1q+NWgs5MDLq/ShibI
zPQ4Z+9Gz+AGP8CPHck+/bEb+RNbKqmdPYO1Ce7WkBFTqfD+t/MVAE9uS621 aH5GhLZcWnskC+Cxpbeta83WFnonOmKq7WcrIOhNjVWuP5Uy+Nyqn6WyX93U
pa/fNvhAR4XOj6+2VhCEyZ5RnXY8fRF/Q0xaQzxaW1UwnTi4vtb2M41Jtk66 z16eIDlHWjhMHXEnhxBMMl18qcImK0pKk4n4Mc44H+6m/tlIswZ9dwOFs9Ny
RQJH94R2DDbUaspo1oN9c+9Ec/K7LMr2buHw0BHCKeH70qBTc4c9rvBaYcyF BRPTECw67WM8Se763mU39I5XebDk9jUwZpw35qDVTinKEc5By5hwOQnsJpAT
vfrYAhpa6rPjsm09REFf4W6eyEjNYMrWWPgBcRO0YShhMJmQuw36huot33o9 rWjAAZ4z76MNQIVE/4h+JbQkGWwa05NdK+a+aE7+iRUbeQ4wdr8li9BekAVL
61WUMV5A6PXJ0224F/lAzwF50Ho17uoxyhGH2tuQ68HJlpKzvqpXWYPpNH2W KpkjlYx6NofjKvestwyFP4mtruE+JnG75CEsEco5rJWF/HzpCt9c74ikMMdq
2PCGyZJsh4cAhdNPqS79I/UmRO1Ku/QQnEjsKMrmUVjLkwHkFnxk6AVxUZMu Df+MKYToaS1NEl+Fbm0C8fYPqKkjTN5BHtT4Bz6MIrI/fTUob5z7ZU1Ebzix
rJZl3TeAJJCIT0XeKOWcNllsND4e8Gysy0t2Vq5zj8ScDeVw3bryeSlJ2MFE Yi3dzj6li44upZiFf6fgNjyjEo6htPyQ8b3GWK8zRPwKGWb3LV7wfsZbC2+y
4XL5I8d8XYSo5Io7tQPQnUQudHNJzl259kx3MJswWMJs4BwSnEDiLxLojAur KOf0yFjyBnIKYNyEca8IarOeDGLoIQWbElmQq8eM5k4bAfFMQofUcEOdhWMZ
xdTpuGHsVKAI6Iv7LDLv2D5WYDhYRorWuUPkkvfbvfa68sbNPxwRg7lynOPz Mc2qX9klF4TxhghcgHMOVQdPvtaoJU0LlCuytGOuGgNmxJvTpCoWoFrPJT3u
1RvYQau9MT9g8kSo1QfY+v28DVdsmZ3kgUsaR93asML6dxGWLPkmS8qVsG1s BDnumyKhKZ14nyJHV7B9w9eJNDaYioNGoXWTUqrNXFVlgkNUIRDZzS5GUmWR
Pe6kvZRpa3JnzrRuoMbK9Woyd0C8UL1/8LcPMZwlnYJvc/S3B9ZAOn2PjpE3 tqcfV0vsEyc8cHIdJg17Vdv+SNMwkajQryanNbFhazJWTEzY+y5h9k8x4rER
yNIHwicS8R5i5G/4mj4z9Q0JEMP6WXax0YHBzmEH1rNWcGRKUqGqon19o2WV s548XerdX9YzCtO2ovmwHCaCHzIIRNF2O6cNpOyM6Nt2xjEiJC681hGyTvcC
MU7+//897767OOxjE2DJ9ciIBvbXPFXqQ5ay61vKQ8tJcCF81nbqvbJzkbs8 +c94pQzLqUcF+wrEGqWK92fukhlUqucexeok+6Vaoq0oCOcQVBjgHKIEPO/C
PLjgOYf13tId6XYHeoCUqacTEOaM1oIPhM/6oI67mfYGm7/FyHexZUn+fWSj wSPTaF35gIZMKaxJMmpAih1zPC4x6LzDDcOYnVCj1Zfqoty5+UcW64G5JrwF
tutzLjPpyM25xVB1NxmqN6k3W8dBxee+xCaFp0rFuwu23h202vbDwt1Gz7du rperhlgouDqifhDSq9RdmwQBbeGquFiTqRHl+msSlZqSu1j9i9cUmzL+UJuJ
1/mCLXpzvNBRbIzoAVfg/rZYoDT9ihB7cMRP3Cuwx+qBmoh/0Zr8X7Il/3ct H1ZVfqzZkIkgUbiipw78CGZ4fz6jokxeCGuiYzwOn/pv8I5NeYntofXSfnjr
SbQjhyJNw4dyXFC5TerzLpb6vtAwRMPLDH4zRvt3mDEimpFBf1XAkgOwykwp ejzF/kWj4eLgs34Fmbf7yXup1Ex7bVWZmwrKXMNXa8hwX4Np8E+S4XpS3MEp
6/LKRMCHQQ4cEdC6OaccZhlXWAgk+TJGxeNW6EKtHQwYLSLtGmrH6oIhHfbG E07codTasg0JmINVeHfkihVpFU2BF5xhePssXIK4CGFqJUyAAUPcaFzXLswe
JqpDKX1b0dYk5bYoI7LmsmcyET7dmbj4NtG54nZbd8p0pm3AMXEYJzyHV8Iz aptI2kzBiVCF3BDCGqHyfOGC5LWJaNftwaEzPXEJSYPHfZo85X7GJDpjdvOo
T7RbuHkr38x8ysypKeVY1AaUu6QoV2XS3CISU4dbVbRvCgtZnuPywCf0eXKp 35wM7asbt2B7to7FDxmGN8sf9HpWMwt1FpwC0Wqzgs11XswBKDnwlSJumW1j
XXXDhEYN5dj9SUJf7iyzktQ0treOipTSSDoB08OYstd5Vu+hkTS+vxrGq0Ms B03/TpopKxN8mOKmrEPvy79NRWTxdImPid4nOgfnzsAdyeGDwTI+DGWQ4LQN
N6K/DDxvjrg6USx7h4fwfnsgnx5pqu1j2uI+tetAp5mHE4JoInl5GMIH9Dxw 4ymmkOUH+zo8h1qbxZSgpUghvrEmVlYrdAMLIyBcEjuJ8eZKyY5LD4eJIomK
HbmSnvUa4+QnWUTEniwJqtHrptSPSgiN6TEDMzQQk+DFC3bZACsvmGQvfnn+ asGwYVjWkhLMQYyt85Jg/lrlx2P4DXKBZk/9UOrCIafTRHTlVP3ob9CdKrCp
0/gYMfSz8UusBd0VG0x+QbAjJM7vhYr4zXtqs6Grpbl7+44dvWBgbvRXj8Vu l0hH1XPdhHIhV9DOGD00mPJ262JqzhdT0yuoNMB7Dk70K97B5aIsygt1DFIP
Y5x/b0jMjm3QnL1F+B6XYJTtPNjxXiYqvVBM8AKJ/4QNmefSyBNb5HiJVgiw XS/1NBnIP2UV+eZZYY/TV5IX0OGFabjKG87R7udJBwytR5nHJr4SBVvfBsnY
/KwrfroWemsBQCxsQip4ws23R7E0mZRf77Nc+k1P9h9+H77p0eQJ+HYhNE0e HcxHPSbk2zFZuMEB+L4jBa2/dSNzYkfWubNXsFZq3ukxYn4flud2vgJCzO3I
3PA29ojwgOSLSSTnrIp9X6YQ93US9zXRiZqkp5aqBy+P9GEzOHwumnzmyexM S7c1FXZ1PnCkoe3jM9MVOGJCjpTTHk9fRHURs8sQudtOCUwXDq6vVf1MsZyd
93MNTwxsEfhtqES6ycse4IQ2HCSDZ1v/MUklRRKQHyEzQauwMJXVNlW2oMiE k24h09FvQo0Q62k1+UabweLOtyGE+V0WRch3sJ1oB+GO8LWT0KS5xRFXGLLQ
uz+P5Dmw+BHv3sC5+mzdeTYThE+gjvV6Ru6Wrlv9u2U/79pEj8SsyyRzb3A+ OMNRfWRBIC3VgnLZrjq3IK7wME+kp6YzZWv0+wBSCsIwpHqYOMjtOn1NlpvO
xDzsDCGnf0teGQ95UHiGFHd/TgdUN/Ivd1nsqt/tCB2KXuJG5EPgVvWeefU+ KTaUBIAZYyElH8jOBYuobiJVXRE70tBmPe7qMW4jdrS3IdKDky2peX1Jr1sN
aDNJQzTWu32HaH90+yEwUISSqHfkOR9Q8dkdVLxLVLyZhrtFOoKFu13bb+Fh ptPUAmO1GyZLYh0eNRUuP6Vf9U3qjxDnXHMpneCaSLQoCuaRT8vzJuQWr2Uo
/3c0/n5P5cNLsq9Q+3bOUtV/IqC34LRZwyFishzUAjgbQ98rkci7YFixlYRS L3FRk0rBlvnfFyklYI2PRF67yTlostyqezxAAFmUl2yqXOUeuTofinu7TeWj
9mFZPxXACLIFO0no76Q8FB4Iu0zBHLndnMqdNauna3panKMUO5bjQdTyghd6 UhKug4nC5fI3jhldhEDlzERVA9CYRIJ+80jOleMOTAU7Gy9YwWzgHBIEQ7wv
NGh9jwbyKAihEnPaFKAmCZCB9Et4N5hU4sz4T16WLbb5bp00Dpux2b5cwUu4 4uWM889F0+m4qPFM4BtoiU80iMwnto+vGPaUkZx17hjrG/jjXntRee3hH3aH
oyiooFawaIqIR9zUum1DnQVePubraFafFZuaGe7CeDG4jrHjjuhSiALND4Ox wVw5jvD5LBes8tZeGx0wUSIU6gMVJPy8DWe2mZPkwV7qRN1ZRMVadxH+LhmT
c8qNi+R0ME8LPLqLliqN1q3ybdXzpGNXzh05wDvA8G6bxqlduJU16ozA4Rz5 JYpLC0Rb/0fvypOyZ6bezq3J/LqBhLQB9jPYYyji3/ufD1HvJSWtb7L1d/vW
xoO2CvVN9sE4oKrmZktNhqBSiZeUUgjEDTyKBcZ06Hxdr9hF/fy5qsdtVQpX YIv64jEjr5SlDcIQiRESMwuuGU2fM/2aEIihoy27WPFAf+ewDetZPtg5JdFQ
P0Pw/Gye0CxhbDmaNXBMKmQeYLoPPFxDEGVETY9VX0Vtn7get1fKxSxLZAtg ldM+GdSy8Bg7//9+47tvMQ6b2YT0cj3ypoFDtkgl+5C27Pra8tByEs4K29rN
DQCpjuITJbNVwlrNijJK3IAMtCGxXO9CG+yoJ/W69dYr2Rx1Wnni4/VrbEaI CVl2LrKYhzsXjOew3jvKdt1sQw+QWPUEA8LDUWXwvvB5H9dxO/XeJDTsUPRd
hawzMM+4v7NAH3Hs6GIr76kmBORblyltc1qvVLBDKokYah+PrAYSq1xsxgZp rF2SiR/pqe1mysk5HZk6Nyir7jpl9ToZZ5NfKFPfZyaluF6hB3BB4buFVNt9
QO/R82PmG6iR/i0bpo2BBYI1C1wPFYcKGI77ye6bdlpUsLVrCvkFXh8v5LiN Y7ib2Aw37SZfslZv7hi6j40iPWAO3NnlDpRqdBHUEe75iXsJSlk9kEjyT6qU
CIjqLtY5aMOuKGTS6HKU1npaLyjFwkpFaBSKrKnP12zQoNgi5sMw5k1LE81q /yaF8t+rTqIyOeRsGr6Z4+zTXbs+7+Jd3980DNPwewbHjA7/PabXiGZk0GYV
N/CjpTjyoc+rn1XTZgjRdBIuajtHHeFASXP7pDEcIysYxlpqUIU75P11Hdg+ lOkAHjVThr+8MjfyMNCBvQKab+iU8y3jzBTBcl/E2QR4FLqQowgdRrVIy9va
/feyAqBUopLdion3Kkne0Otj7TotGtKrvTyPw77SlvDCk2/bFFHcOIlmi/gZ vrqgTYezsY2Sd0pf/7Y1cbkdwigFU75kilVQrC6aXAMUoYYzuioXTLFRrpAI
LKOgtM7C9aDcEPfHDPRK5M8iaUA6BlDEOWMueUsKqSRNvjADN3jyrgU2TGm/ pJgH7CRCYf5kcY/v+nNcrKY4SJiPPg0yVSdvmEapoVi1IsukkEXgc7Lkq8dD
scfTBd5Xz/NE+owGQalutQQWVDIpqJeMI0y1XGIkTLbHEmXhnN9dsG6Pq1oi v8oGfsUKA7yfyUtgcQb6IJGeVGJmAqHMnsgXPjaceERsVHjNJfNuFRYWb5SH
LtXAWdAUiHJps0R2RoHIEx+BisawE+YR490A7deEc9yeHSDZXw4mVYDAJiAo AmCYNY4OD29az2jS7uDXrlRscDpMs0rZ7KJKvlzqSFlQkwo10Yl2KNXkovqX
iOu/CVZKirYCL10as5sk6WmfIAuKxN3RaMoJbzzyOHPBBJRk2/oek1R5aR2X Fzksl7OkXZI1297YK5LfI6nuTY0x7bbzzPxDPWl8jUT07gfPd0SsGigEHbHA
g6SNxVs7Z6GOSgH88bw5TxOYzl6/o3I+Z34aXDuJPc6EkooZaUcDUfpePZZA 4vbv3bPC3e9hj3r7e5pO8/rRAD3zQLmoBxNCtGIBgtCF92ip4ToyQwNfAZyL
fKWNqmeWpAUVpDt8TwSPjxh6oxCeEORtG7Z3O+cYbydxJDILfI45S21wjCOo McmiYgrJkuCNc9WUOqiElJyaGZihAR8OL15QYQeYtUF7/ennpz+Mn2Gexnz8
XZRG9w2FpWs6JWhhRy6UriQuXynbJNoWmfBwJHKR9OGfFTTsGZAry18SEpyo ArON90VdlS8IpIXFL3qeNX7zgaq3aJoq0MG+Y08fGJgb/eqRqLicS9LrEjPc
AXhqWordSdsl3RxcpeNbo8qB5gOm6WbDT2njCRYt5eIjkcn+CHIORsgKvO5O G+xrbxG+xSUYZXt397xVjvdDSFj5CTklheWZ59LsJzZe8BHNQuH9s6mUqYwJ
jmEmnJHSFpiguI7R6dhQqkNUPQI93bZ1nbdZSKsTsBs5UxqimIATEacTjvKy BDTJJN5swlf5vKKq96N4N5kAaW9YLh3T48MH34YxPZw8Bls4ePLJ4h0+xj7r
ntGsW4hmUJPcMCcgJfQzWsv1Gn6dlsbqUTGbLYrz+hNsbNFeafV4L6DwBMMJ IAAfY37SBd9avrhacJM7cZMbb05Nu6eWzBq/H2lgc7inz5t87nkS8ZCpOBN3
vjaJ+53Cx39iViVHhXKceagb6itOMxhASVpjxSucGQuJDDMuRIN7xtp0gaZD zsARgW9Dttt1XokBXnfDbTOoBvSbSbJ1kvjFCBkvWsXQ6V5tU2ELgkzqb+TR
XkBFIHIitz1mVw8cJ2pS5jvgwW18+kUM7+TcfO+vIz0v6mldMbw/lLlwgZ4y fg4EkUTpOKCCPNl0niUHwSZ0kYVca/q1lM7r/1rO874Ni4mLv0xwDgYURZzW
ZviMQJQ0YHecqx5hacPN1HDDq85WGto64YYkDSZawEhQHHeuA9QhT4tlOJ/E znC9+rfklXEmDG6eIcHdn9MB0Y3M3l0WezVud4UOeXvxIPIlcKN4z7x4H1Qv
Xkv4binr6YREbNpjMOvl/w0KVm1T2Tx0pKTyrNw3gWZgb6QkAa5AOnLRDndA paohy92+7Xg4uvkSGEh0SsQ71ioYEPHZLUS8S0S8mYbbOYWCMbBb2u+opfCv
Ebi4ZBRmpruM2UDipBaaSVMfzKYPxta85gxA3buGsTTUFv5qcEca01HpJINy SPzDnsiHl2RfIPbtnKWiX+oPGPvWKg4RSeqgFMDZGBqveG5vA/jFcjBKBYm0
wTrZqYnnD2h+bjYYCpmMEheIEdjPuhwaTULv4NaRaZEw/ArbSJnwV9zE4l7k EZRkJTggrAaj30kGMjQIp0yhL7k9nMrJNq9nG2otDumKys+uMypbwws9GjRU
Pgtf3ud74v+EApwtDpj1t8iN0Y5CZE032MbaRz16lpFpqEQ/ouupLyI9H5OU RgNhJwScieVhcpyTeNFAtCq8G1Qqsfv8kFclWD4foENS/W/OFs5qDS/hqsAg
eM74bsZazuLAU0ZnxRwi0kNdufp1+am0n8t79EwNv4QbcCo5ltN0SuisTAsY glpB7mn+AKLMNm0bslLw8TE/R7P6pNjWzJwY+ovBCPS1d0TDQ9R6vhuMNFTa
U27WrfRDn4ElLRHn+H5lwUiLamj3RCcsajNDgeG9tCv5fBkhmaCJOCfMq4ID ZSQ9hHla4tVdtJTNtmmVx61eJFX3csVY1ugOb1O/vgs/ZYk6Jyw9Rwrwoq1C
ZHYn49GoxREWzKULFlxBYnRN3GXVynNQNjm9jwrx9CxwdFjlDGmvPSSJDs8S Dp1tGDtU1VwwrckQgSuupVLyprgIT7FE9xfdr5s1W/OfPlX1uK1K3l9fMWDR
e95GDRPQ98orWE/kICKqRnRtglmEB7Y+UL2vWD6FIgcbcJV5dgGuzgr8CxDx z+ZzmiX0xUezBoZJhcwWTCiDl2vwN42ocLnKq6h0G+d899IFmb2LdAFMmSDR
jYJktfgmnX3kdasr5SLMuZxMc4o2akHz48L8oG8+HjMNOskUxfjO8wX4HrgY UXyk2L/usFaDyIypN5AMLSouz7tQyj6qK7/x6VaidNRpoo4PcGywpChmS89B
8Ls4ruDTDSs6ixZ8DOEasyHY/sAojpxotsgUQgNJfkmp+DUbd8TlpraSum3K P+Mi7YIUxc6jO0L5dDWCIoNdpZTgaX5Xwca7RK7Y9t16kj/MBA3IDHqPXiBz
e3ZSBZvqE12f6pKRt5T6k8rRBFJ3LDOMI5DJiw0V6Y09R0oWiXgQryjtPVQ3 XwWRBHDZMDURrBAsWiATqditwuDlj/bgtLOigrNdk3s0EEb5XY7niHC77nyT
rq0Xa0Hpt8G/7LgrkvRsN3NMMbojopigEP07aylwFIV/88V/Zn7eKs8om0hp gzjsikJnjZ7H/VrP6iUFpVis+EzIpp5uWKXBjYsYGcPFOCuN66/dwkeaXBnK
A++MDkLk/ef3EzmiL3wDkzvTx4rDYh7BuAXfKiROvzE4yhSOESfZL8evnmbP NftpNcXCEH0ovrW2c1TXEcQ0F0Ebw0Wyhm5sJNNZ2GneXdWBR9YPmEUABV+V
X8Bfu/998OjR/pMRh11PXxwePPpuLyW7/Z65ZfFZSDMN9z//6am9o3/DQXwD SVmUvJdJuIteH8vXWdGQZO1FxhxWh7eUKp7Z3QbV4vJnNFtEAmK5KqUAHi4I
kmA9hf89He8fPB7/fPSqf8e39g4idAA3FVcrjoFKl+VW+Qc15N/q5dM4ZCpu RdO4zG0g7iKLFpkp0j6AKM4Zo8qHUuhKafKFdrrBu3cjMGsKlI49/jAwCnsG
Ox8N/pkoNW+xjAy23s81uMXIvId/fyHiQ/+QlipZMdHObLTiG7RPQcUy8xn5 MZJo1AnCBqgusKTEXIEJZeyOq+URs8XkfKxwL0z53QVL9zgNKGLpDcQYTYGw
nEQMAk6Z/kwvk040OXaOI8bnXl24klFxsxRLg0HckhhEwvfSC5xSWfiiUZCe oDZL9s4oUMRiEyhqpFtcFsdyKQ4Qyk0YFeA5KJID5mBSBThtvKeCUP+bYMsk
cxNAQxX+93XB1JrUNOUQbGAxbAXnUS7IAGPaxEiB8hCDm8OoGtV/3Ol7lXwh yS0wHqYOzkkS0PchRSNJbqk25YTPHnlYvoAo4J/ORINZtba2i1KZaY2UN3bS
xTan2iDe8Tjj7+egA+fudBaQ9NzOglSYgkhzxwJhcRo5/VDa70IAFccOzUYf QuaZJjzEE+c8A2U6ff3K6PmCKZBw8cRTOxfiMyY7Hg3ENHoZbIKJlnLInrSU
pfPB55vOCLeRIaqDuiF64ywZbxYqCX39GDwfDzSuPOouqaUW1uYuhBrp20eP VlRSA2A8UT5BRP4cOTyFe3FXt73lucDoBO1H4kzBdsx1av1j7G/uIuSBLwxO
DgTOrgnIuPL9bU9QkvmhT8HlZiNejlEvH94mcFtqG7ZE61sq2MG/zX23xual hS7Ya4qaxVJJceJ0n7JNHG6RFg+3IufiH/+mKGtPrl1ZlpwQE0YRwFPTkvtO
1U+zrnwna4RlEGEFkqMG3lmKgodfSJsYD8amSBF1lcUdFJihkVlmvVxpicK+ qqfp6eCsJl/iWK40715OTxsOpU1o6UVOufhWZCJJAumDIrIGy7uTq5h5jSQX
1HqA21oVCz9UKvbuj5V+nCQT4HCxhO8z3hzeMU5xDeiIaKfZ0KOPdiVbR4P1 CGYozvx02jnc1yEIEeHEbjq8zustJNcJCo/UPA1RmcCliPMJt3lZz2naLag1
G63admhOBi+bjLReZ6FoOE4/LT0ZPbOwpmcmOhlBHFkjkFQuTF+EsKTbxMD5 CEouxxTQJTqM1vIIh6/TZGK9LObzZTGtP8LRJi+3Ornh9k1qiTHXsTqyTaV5
QBfslS13bRcCsCyY+57fiz42VwZQsCT0a9Sau+pjZHmtq/LvGrlN655kQzsK StHG7FZcYKdFQyO6A0wAQPAmMXiJtRU9oPWPMQr1USjAKEeRIz41IiK5pqQB
cXtMEhr4MB2hMcJIk7O+JGmQ840hIMxutZCuTwwXoBinUnFjczb60HyxaUvS hPG8/Mk5JI/HE3DecNG9MmFXevvmhGaP6ny3ckiquvLETjBTe7T6e5nAWMwX
5H5O8mlTt+3A3tARw7jQWkM1GCrrbCzIP4oCb3dNgt0gUZgtEA+Ye99gwx6k uFVAGO5jVErxTsJxmTksh9weff311dXVBKZuXID2UjeTujn/uu22ywJpkYuv
ZTCfeQdpcj+XTBRBaJKguNQnLpdYo0Gnnk8fNkVcpr4/CWfmionQpNXBr9ze O7jYvz4I/Gj4lICbYRuCdowRcVowzrUtUPWdFz1zZsLV4oI/YpaFanHuig2D
KurKdQ3+jqcN8XehGYkpNua6TN0GknptCim13VOM9cesWX6XLbUsxAoPPhef vKU8ES4ajsPn5jUVTpJLctgYonEGeY6/c8oYg8EYeqmNV2TCRBdzWfxFZPRf
yfknsBurzRJfjkkdjDBVXDZ5sYYHMCkss5/HQUZEJ3lSDyua8miy5OyzJ9nu g+vp8eS+T/jjtQ1LS5Qwt1pcFQSZ0aVZhRcmYPjVWGu/0LGRl1B6lehubY9d
+/Rn1IQ4AQpRhys4DPbwW5977ArMZ8lJADioq962DyCXeKBMvRVR5QpzrwJK OqRkIMw4EwYW7uLWxzXFTEt0rNdr4dHez+k+HdjFZXfwZTM1+jdM1ej/3rl6
BUAjqyK/5NhOW9gVIRb1uVC4UCCqkIQhEggfyn6hY+w33I/cm4rdkXTJhtPG ku3Tyf/3TBYfmv+3dhWFzoamYMCp+xhdurs3zL86B5w5/S/OABGOf8lOeeef
cbjNGa4VBoj8w1OGJDMbu15gewzX1RGXhi+K7ZfraVtaSSn44LEcMbGoUDsk I01bFMRNxQlpITGTwBVKjOXj11GImz2inKcPd475bWl111YsQSe0z6RBihZm
HNLH7MdsX6mrk5NA46fsEegJKcBTJJRuCWGIVNL5p1J5O+ynuvitfOx75m2L LvA49FcHdF6eZncy+oGPYhi2pKF2whM665GU9tBqJm1D5YLoLqTTp+qEUtwF
hx08ioR9yG1hD58zDdmS7McgxFRjGl5yWDkrb5nZIHRgR3eSPMVhVNeb6qhJ NqEDpQJyBRYaEeXsFpA3F3McyJVuxx8jMOiS9uFEGu+dNlLBUfXdQF+aEvP6
99YaFLp4IkY8WYb8pRLqicC2lQSdg6gJ79I5cQlowy7R4HbEA+IzDF7Hv0pm Lgf1IWO7K1F00O2Q2GFmIqoDijeXbA6Jt0aHFlDsBKS1rIb684mI6KaeKasF
yoHpUg3NjWKiJ46EK7YySChPzoFc+c46WZTeEW81MObXSmkjdfhWxdjZc/Z0 fIUlIk0AIq5Q9VXkwBRG3E9fiQcqJIzucIFZjxc5krRcILkzYF0/BL9zzzI1
sWiAMBGe+dASi83DeevkE6TR9C/F5hRZtTyRScdYtrzT6DNmQOTcDrw70v3A xRLpI3qeqktT+4ioQTWfKuhl7HCg9Eu3yImZ0ujwbKP7Kjy6/ERFw+moatKE
DzXgKDrRJHyGtNatEnXABwvbgbTOeblkxVEisQ1WK+KscbSMjyQMg2WmHSx3 L+EHOJXsTW86LdWg1EAY1Ws2REGKs1aDBshe1fj3ynWVJoHS4YkMHJRlhujK
kGAeG8qawedqGMGDmkKFomFUStJTtlIx6EUGvtx0Wmk+Msy7juMEFgc/kJnh +8kuZfjSQ9Fbou2ccKp7TQ45HI1LSQ2+sGAuXbDgjCOu9sRhqTJ5AbImp/dR
fQh/h8h7dnwAEyPBNDSfXd9NwsOUEeMtgA4WWz8+TiwsCJ5dfcdFaQmKmjA/ 4rhq4o5MhZxTsGoPoiXbBV6clEJC51dewXoi0yCRMaNrKVilaC9pg+r+iven
68OHTCU6xL2e1NqiI/xrFdvM5A97TxBTUZ/vec9wPKvUL/YiD3ZESUkjsksi EOFhcc0yz1BFXmfrGrb4VrM6NFk0nX0kb60rZRvOOf1ZUR3Wb0zz48L8oHd0
oklvdV1y4yvOxFGXBRjHi/fv3546brHQ+vC4ROqUV4vYKkpmi9RxUuCmkUOK POYCJ7SnKMoyzZd5RR5U+C727PqA75puoiVfQrjGbHy039Eqw11E8GxUUNE+
muBZZZE2a0iLCqhvrSo83r7UYbXCkJPm3girSV70qi5beCr+fErxwVGIV1Ms lS8JN7Zh25oIW9VUVSVZyU2fa4IdLx48lsqSkTdU+5PK/lwSd7xnGPQmkxeb
ZokQTEEgYOm+GuKUb1PnrR1xTpULffkSqehAIuoBptZst61dUgURgtCm2e6S ieypzxbIISaqBXGH09lDcePaermRtDKjzXdc8hAu5g2lp/s5pijJCVEiUZD0
Wt4g3G6lCrfXf1OIY/2X2Z4hle44H5TyFj2+nVz6GgxDmIGRq2rTmF65zPHL rdUT2I/N33z2w8ynrVKJs4HqC6NpXjbdg1jRh99P9Mc+UXvk8kybFYeRaYJB
yHe3LUWjM0U669IvTt46b9pTe4HzRc2kVJp8tn48hTjOQYS7NRXqimYKDwkH dr4IWAyAYCSvSXQm5tGfn708yp7+BP+z/1/3Hj48fDziwNfpT8f3Hn5zkNLY
u7ZW43FfE5NW/ZHAT1Rbsm61ZIwXmeTOxzStXxq3YzatZj/qCa4tKDH5QFqo f+urBz8+fHQXa0hAE09/OLI/6v/mXu83SHh5BP//dHx479H4x5OX/R/dT35E
6jA+WjdUunuEdMOoluBFp8dH2W4ZtTbQplYc5r7EWB9V6O2xTIHBCMoLbANh VEQzsMOx9kcUjnJsu7fKNqzR11Yfn8XRK/Gf8h3h28Tt8wbzn+EM/ljnS1zB
PyOznQJBPu7EsaJwHOAHhfa7ep7mTh7lidTwOn4C4WtD9EEOa6Ye8wEHDiFb c/zfz0Rz7BtpiYIBMU9MPS8+mvYIZC0TnZLzj+zUSfZGP9PHpNZcjvVhqahD
QSfUj7Dfm0wbfgfGl41swBnjPCItlGPlNJUKSaRUJ7V8ZZRL8gxw6Ak8ADKF j89EuSe5HpolcCImaXTn43vpBU5JmDzbAWyjqYlloCz/+6ZgFm2qi3acrdS/
DCu6VOYKmBH8JgzslNLwEqeh7CaGZzB7r51I3KGJLW0xUtGsQBsITg0UORa4 IOjEckmKGJMkR5KUuxjcTYwFVUFI3QijlhGSOYy/aPK2GznuZzx+9v4yjEJn
EQbjxrJ+A10mpK86Gn1o2SnNmm50NUwCmDSKSr+pxqsc+4AjYgVRmT4fhblW AXFtdhaEGgH2NhclEtLGkdOB0sEXvsc4jGNO/CidD77odEa4UhxR9NQN1TLI
rMzkyGCrw2EIlXriyMJLTX71dQL3dDgcZOMjkmCfdjY1eeI4aCUkwvskTM8l kv5mIQXeJz5D+3izcc5sd0GFM5FUYimkfvcfPrwnmViKBYkZW970NkoyPzQU
RV7gYKvn2NgEPHwS7VDfIWscklmuy5uLQkPwrV18VaI4FB/BlNAQ3UQIpxBq XG7W5eU+9fvDKwduR1bejsBpS6mm+L/mdzeGSaWaX7OpKq9BwHVCREvIgx4o
h3VvGGNJBzqCXAwGAHvFSFtX2ddDa2Qq6JwcVVgGAX48nT/Zu3eih7Hwibq1 5ikgGb7IyjiPiFz2GFKlExTKQCAl2ma11uy6Q8lSvIDNXyx9V4mlpN9X+jiJ
jDzAkzI/RzKpqMeQ8DwDc728wDyqouUwtYXzPF+sBbMCRwx+Kwec/TgwbkNA 68ItY2u6zPlweAdlCjFDg0TLyYdKvHQqWU0azDxsVclDvTJ4O0lb6xUPjLrj
TLI38EI9Hdyuz7YKTbK3FTE/LSNQ1Sp1FCi0BLJDtV4v0Ig1La+kbIKjK5iP dGjpFemLCHjXkk5G2I4sEWhXLk3po7Ck+c6N4HzMAU5L73c3bQNQMrjADb8Z
p4sou7Fne/pkYI+wLmukkyjrjoqhZqResVVM2DcaUpUMHA76Wlpi07NEOucN nZ2c1kZu61CXWfPFqw+RErapyr9rEC3N2ZUj7Sjc6AGiqOvDhITqRyNFyvh0
izp36mE6puITfJdp+4bdOqQOGo4ohGpNsnc0HsrF1/Yh9ATLThNcNkd+ImJr 2kGSV8bjMTHjUko7MnaLwk1adwOLsNJA8+W2LUmW+znJZ03dtgOnQ3sM/ULF
G+qBUAQ0ptjnbNwPuUJkwq5bR04NyQDmxRhKSFFDLDYIzI+Cgxx0x7iJYx27 DQVhyAq3XnnfFIVAbotIuGZPYeRWbGH2NWJVPmQUMsO8xX5yP5bMcUTQviC6
kpIvhe0kvRnK6goXi8diiaEw1OPEJChxj82x1MovDwW+r7QDXHbCbIrZUQRr 1DouV5hgSPeex3I0tuoY10/3t+aaOTylntEvXMMyKr15BaaPJ7zyv0KNEvEO
PDFMmTia98RQ+TyUgn++l9IwOkePkgi6eZZl3RQPRhRxWRnMJZ8GXtNVW8Km TG6dWhC077X4s9CSzDDsGhM++nPG6o7hgK+YRZzaZDAAqJDVdoUvxwA7uvor
yuPlRYWbeFjLzeu54QimnBh3Il4QNzzkjXV8iBRxodFLFhq9BM+0HPRcPWNL Tvk/30ADzALPpU7icA9CRT0fld2a0jQpdbbtSbb/Lv0MW0lRm1TGEq6DAxzr
qQTs+nRH+Bhf6pSQggodp03sGOfPUC0Jexs6CchnGLElRz5zdhjAcyPG5fRW Uw8khPksOR4LV3XVO/gBcRh3lGkjI258oerXRAhBM8qqyJfs5GkLuyJUMmUh
z6Wrh+HFojmnHrS1twJSPwrNPzmENnQbzVfY+/bQ12gnDGFSTEaS/rVdKkxh 5GPkkSoEvYEVA47lvNBF9iueRy5AyZZJumTDGJ447uEMSxij9f7h4xHJzMZW
t5ZaB3JQ3PxkfnokG7eZBcOtIykLUxjmXrh0GVNNZ9y84PwzBwQStETIhVIT GGgfwznhRAPlCR36qeZafl6iuz6MJ5dMvFWo5iF26UP2x+xQS1Ukd4EGstg4
OzWiSNORPiGuJB9y7WrHeorCojX6o7SW+RKxG2TbclMNCvHIDHqI400sprKa 0DtSEiawgERLcG8K0HwslXLKDtXFb+WL31fasHkcg5eR8Oa5HdVCFkyhuSIN
u8/38AiWA61PYNrDWnhEI+t+PCO4lSpoAKY4sCvy+R7xRMgZSNviCzfT65Ul Mmxi4kcILzmunN1vmTkgdGVHv6T9FMezXG+quRCexOR35k7SwxNR40k35JGK
WPiQErtt4wDE7tKlRi6cJv608U5rObpsn3hqqiUhoS2P1p4mZMiIRsBwLlpw 1ydKEqkk+he2mjAGTokGR6tyigS3PR7YPsNJV/g/JZO8wXSphOZqcFGLIyGH
+I5etax45ZvAlttRJdZaYV6KBGbApR3CUB8DCyuSCrgelwal7m0+i0QpVEB4 rwws1bub0bnurL1FkXYxXEN5nFrZ2IRCxooYO3suoXiM4FlhMjxxr6XFXIQ7
aImZUuknJkWD+PixoglcVMgQKZj3trUHg1a260iHH51FHx1FukhVksc6+4AP 18kwqIJzm/1cbE+RE9LzcHUMLs47dUVjPFru7kAbJ+WOfHcDsK0TacL3SGuN
2IkkJTQO4rDB908OHn75QjaO5NHpAVTXxuleX7fge054k9m24b5dFIbWIf2W KxEJfLmwNkhrnZcrFh4l8rJhuj3OHDvP+FpCr1hmSr9zySimYSMQAwxXvQoe
rYsRLSyJwFYBk4yQ0z4JAfaOeymgQC1LdlnF8FCMeSQhRCfxPBpBuPjw5dvX ZRpS7A0hYAIWsKn2QTYyEvG6G0vhIWHetR/PYYFwgFwNxvvz94h7bs/7M9Ev
RIbdMtJHf27y8fbhzuqG8CI/Vt6jmKkRcLLCY/LWbI8ww1RqqRd5WTOTMyDW TF3zYKf9yFk8YnwCHwM0s1gD8m5jYfHxJVX2XBzaXfhSJQ8eMBP2UMGVhCwC
f5ImNrQFc8o3M1pIUFtDCzPyNMyJSvFkwdfYbUVDYVj1NJLGcapnZoPDEVj9 zeFfqlhzJqvY24MIDPj0lbcPx/NKrWO/7UGXKCmCT7pJxJPsNa8LrnDJIV8q
hvGU3FkjIvPt1VPy5fJssiCLtu1z6bgh6lUf/ah8lXFnCh+lLpu3X2u/1PH+ qwT9+OnduzenjmsqtV4Z4GGVwgp5SYRuTHas3SQ3TiP3FBW7tfIiKs6UJsNR
0+okrwPyxo6BKdBIYZlr+CYKHqMKQfcFa0EUPhp/LilyUyxgNlP0uZO4x6+n bXoVeHx8qYx6hd4nRUEQcJ7s6HVdttAkfj4jV+EouK7JLbNCPLyAwZB2RhVx
qwjRDDOCgYn3LX0d4ygZKk+VtcFFw8VMtX5SrIGYVo4gMZ9srhse8cDFYk4z Qj6o+daOGN3CLBX8iGQiYuWJAZJxDNS5JHsv+KPneZeLZbqiAncYJV+rwO0V
RBFMld5tMUoxb2n24sONZjQ53CIhtuVzcWa2Lz3m/Oip0pFEBMGhI7DWJTjh 2dbMNB2ZLRBW6Wnz/imv0ePbyaivQTGEGRi5qtY+UBoAFy/BkZH1buuGR3dK
w0Zt4P0oPYhgkh4YknRGGJHCG1oJi91kA8vw3cDwJ4hnjQwFyYd0lBsh0zd6 UyBkk794/sZ51Z7qCU2XNfMpKgzIWvLk5JjC9u02xDIhUik0Ei52rZ/K/b4i
G8JsXISHEnQH9TYmn9W/WMP2JgJuKxkpR8CL9I772nr81MsiB1/Wcb9UKexM Esj6AyFRKSdy02qqMy8y7Tnv3rSWqckZR/ER6sl/0Btc60xjHIIkUNWhq7Ru
glTc47zKClCEDIExr+skLuEtskmod6NA8CYQPuH8g9HMZm5n2mwcGaC4lum6 iHfiBHEYKJLgRafPTrL9MqplpJUr2eN9gW4/yiw/4D0FCiMILtANhLiT1HZy
sBwYu4ibkfz3owdP7F3YZkP49gOA2e8np0ClrsnnhA7Uxt3aljBA73Vwk+yY BXnPE3uLwlWAA/JluzO9T3MnTXkOUHyOW6Bkh+B/kMuaWTO9y4G9yXajEwBT
T482hFf4bqoF003bcGk3hzThafVUPT8vH0Fu3xydvkVlfPTupT4MlbNLHgL+ yt2YmBuOA13NZm/A/eI8PDikEec0lYoPp5gn1XVnwGHSBpj0BOOCPYXsYLpU
dknNuAYfomDrzUn47SEFrumkhcE5KXwVtp9I6sI5o3NBGcegeqxgcyvjFsHn 5gmYERwTunZKqWqN01B2E8OQm73TymPu2HiXdiipqFagDgQ3Bm453nAjdMeN
uBikKSi2H4CgiUiLyuOG44uCOxT3DFmaQOtPaYLqGDPYtNSExqi5LMzIow+Y Zf0Gykq1LLpR6cObWhlC9aCrYhKQ/ZGD+nU1XufdhSPwIELkfWiKqnZ4/Eir
ynz4mYuXHuNRSKXtfPCing/LYJhX4fzgkgQ/S0eHmdBggqp0IacFll/to0os 3WE0q1riyCCPb/SvE7CKw+4gkSzx2/v4s8klF8NBM/gRay0ee87v9BsOjnqO
Hk3ZfkxLSjXTwm+xh1JZjc8Fv135yJFVcSENs2awBklP2+WrBUHMA2rIJ7VZ hczAwqetHZLtZI1DXMt1eXNeqDe+tYuvQhS74n2Y4hyiHxHYNHjdYd0bBrzT
kxDVo+2FzHkXIquMJ01qdHq1Zrq6hxJ2pkVTfk/tQez3EoraPGAu/O725cTO ZY5wQwPGwtpwUrtdzvXQGpnMbyfXFOakgR1Pd0/29q3IYcxCpepsI4+2pyDQ
hi+b4jboS2wT59a80idxV3ujsEHdozvfyMkXV4OTcFAfdG0ImdshdbW4qGjE iUwqyjEs1pGBul6eY0hVgcsY5cJ5Xiw3gh6EKwbHyi5n3w/03BAqnnQNQj7J
0nNy4uKMH8IgD+9n0x1ysLau0wZ2s4KqzW0viHFRcfmceeU1pfhngrKid3ru 7eD2feBVKP69roiRaumBilZJasNNS3hnFOv1EpVYU99SctjYu4KReXqIAh0H
bvlcY7zLjVInQjIjySwDbaHRxygMqRZHjq/WRRWJB0lFogBeOGmA14sdYLLH toZfBroIy7JGyoWz7KgY9UviFWvDhXOjTlUJxhE2LWdTnNqS3bloeKtzZT6m
bbCgwUDrc3skjbixYEYN/AFyrey3y5JR9c7nx/gApbdvvdEQoceArPsDLCpZ Eiw+wrhMlVcszyX8HXBFIWp2kr2l/lBUvraNUAuWWS2YbI7sREx0aKjoURGQ
XI4/MVlFNerFgeDXeohdwuPXmj4vZGWSa0D9Kcm+R8uurvDL+QhCvTdggA4d 8aKfs3I/ZAqR+rppHRk1tAcwRMawMvIbYuZXIC0WSPqgOcaVmuvYlJTQKRwn
Ms49SwCcQyAoY0gOmB9lZaZOvHMfSbIU+6aUGEtQEA1xvqH0+GKQr8VR+JvK KcZUVpe4WNwXS2qIrh4nKkGJZ2yBea9+ecj1fanlXrPnTAScnUQI8+eG5Bl7
DyXtJ8bgjENXNGfkXZzb0BdJoiykp5fEaaCTRkpQLJTOsNx53jMvCJ7AHuNr 847IlZ8GCpNPX6UMws5RU+JDN21ZwmixYEQQl5WBv/Nt4CVdtcNxqhyUfqtw
2pIgX9QXGNqi/sherDGRgY7xowfff48VCD4+ny4IviS4eymElmLoTkVCePv1 1S6rtgWc3KAHU26MWxEGiRkeQsjaP8SMuMHKbsEyLQctV083VmrtEG3dEVDG
Yh1Fq/Xv6BLo6RJ2eI81Qj7LVh2tpHdNhNAdku2QZKDmajI0m1JjeupUlPCu 550mfNbCJG1DO8b4MzSBQjyKBgJS8UY8/5HNnB0HGPOIATq91XPp6qF7sWim
+IiCdRIaPl11Clv6ePVghyRa4UC9wRV37AP52WBdo+fF8Sf4Sg7UHQYypCND VGi+9lpAakOh+ieX0JZ+RvMVzr699NXbCV2gKsgcCbYVlgwhiVKEBF5rPPyk
qeIcHJ9SBRb4km7jMjMUZkibtI3CLBft1aOc20I/Nsl2T4l0KuVziaAXe7x7 fnpMMdeSB8Wto10WpjDMvdDAc34L3XGLgkPR7BBIgBMhLEqoN1WiSNKRPCmJ
vIMFoknAFKFYKz/CSX9Z10rBMzQ67NVVzjwKHu8buCqK3WTSuxjMYY1tUoE3 Tl1drl3tWE6RW7RGW5TWMl8hjIN0Wy4IRS4emUEPNr+OgFtWc//pAV7BcqH1
HDO633CCiKtUYTAijYpaMa4zjqspllLWefBQ5lMBMEVFNkeB+d3VJipU5kpf ubd7sAuPLWfZj3cE10sHCcDUPHZFPn1F/EZyB9Kx+MyVc3s5YhZJpKSku+hr
bnQnGRuwq3Ow19Ym5Ug9TnhQXsp8Eee5VMbKUXddZ4/H+H6hHQrpG1IgJZbo 4a2IsmbPhdPQn1baay2/pOKjqPwbOlDEJbSjaa3HRYqMSAR056IGh+/oUReI
V+OquFiUFwZaxw2ic4qptl3gJwNBQgMMwc+rlS/6HspJaD1u0SabNtvloLjU Rb4NRO8dpcVuFPClSRkMfbddGCrBYxFGko7c44CiKL6NaNFWCuloHmViplQK
23lSVlJw6EwXs72noqBcyqmX0BSGJQc5wbm1/KopD9jIdZdxZQCTC1S+ATPB iEoGNzY/VmCBi7LKIgHzzlalYvzKbhnpcNBZNOjI00WikizW+XtsYC/aKaFS
d8lyCfvJth7ItUdJSkHrP3bW01BWKqL1IQGcgxNROHJFKIZAvOgoNaTFM6Zd ILsMvn1878Hnz6TjSCSdGqAkYw74hhwyLZfkVeaAMpu4m7fC0DqkY9m5GNHC
MXOn/dj3UZ8d/N/vHsp6SUChdS3CVDXROfBK9dH6VaekIjVNGHGiemmx1Ibb 0hbYucEkIuS0xk/IQMKzFOD4tsBDWcU4ffR3JC5EJ/486kF4+PjFm1dUx6Fl
yB+FgS84RC5gdI0jm5LRDfM1Chkdx3+dd359ykxLXooIYDNUzsAiQGwLzqwu 0I9+biLytnFnZUN4ke8rn1GM1EiaiCJl8tYcjzDDlPeuD/m9ZiZnYFv/Weqv
fHKP4dPw/zSEcDoUjMgR6kdQ285ZRJnENrWDcgQ+o/KPCLkx4XK3UJ01yq7R 0RHMKeLMwCEBcA0tzMhXEEhEiue5v8JCYeoGwxTUkVSKVTkzH+yOZDhtGVnJ
vx1LkzVJoEVPoaqYtlUWVbaY8YMMEKZYej4XOYqO1t0YicPeYtZIDw3nTinn VaEiHvpecjs/Lm2TBlm0bZ8Dzg2xhnvvR+UpHxg3x1noQpLBx6+1I3V8/jRV
lkZp5LzqZRViXk7pqkFAfel2vUXZE2GBmoQjbXqAlVuWKiYpktiZrjsKj61w 1MuAvLF9YP5OEljmGf6Rz75A8wXT8hRIGg+XBLnJ2zKHKRruREnx2phzNngz
yDv+YwNvkjERBMASUDZoKMbFyQTuGoh74zQdku/8G+gMEI5T7qYKctcUnVbP TA8GJp4CaJd1OXcMqeSkJaI5CCYaLmYq9ZO8OYS3sgeJqdBzPfCIDC6WC5oh
CWmY1iUTPIFQQqgXrwowAOUr2mJZjtGIAzdN0iaYvfdIGVuGGkiX0Gwg00XD 8l7q7t3lnxT1lmYvvtxoRpPLLdrENpc5jsz2d4+5P3qidCQeQTDoCLd1AUb4
xGVjm7a17pIVBwdzcYfMyy5EFg1gGw/LEkWkMsUhhNMmRycKntq2cKZDC9l9 sFIb+KpKDyOYpBeGBJ0RSKQAh1bcYtfpwNJ9N9D9CUJbI0VB4iEdxUZI9Y3e
wjDAvjKarZKKRLWi7x2RccR0O9RsilHx50hIpMm9ULyNLpdmJsmmioa4ZVLm RgRSESJK8B1F3tZVnKSiLnvj/bZp5RQf4EV6y3XsPYLqRZGDLeu4Prpk2SdO
64ZkkfON+jp4mozdMfXUhueaYSVBLAyAzXIrpEhslxicYd1asbFzLoFD3IuS KrKeEOxCSS+4o8zrOvFLeI1sEnKPyQu8DUSFOP+gNLOa25kCUScGMq6cCS4s
Yb4+GT8jCPLzogILYVzPx6cCn/Dby4qOj/QZ7iOd8aF0MZ9ecXLdmSD1NG+4 B/ou4jJa//Xw7mP7KywQJaViApbZnyenUKWuyRcEFOTiOP62Dt3znZtkz/j2
bJGpamblBcYXdNnKPhVTsr8oi2xbw/ljvU3IiaR7CgOc0BwbXl8ahwvwOovZ aIN7hX9Nabl6aBvm2WCXJrRWz9Ty8/sj7NvXFfpiotGewmYAHf2Njy68Pjl9
yONiDXxXJRP5vEYO0+yUELugU5CyLw51Uxtyg/mNLLGSCQvMYYbfrOGyUQT3 Q95h+9Tb0PALBBztn7x9caD9GTGEO+oHmOwllaIc7IdCt7fPw7fH5Pumy9oQ
JRDtckk7GNdvKJTacvN1YfOK6xRIduU1LsipHD9efpjJxXx98NNM2VJDloq/ GQjRXbRxw1Wl00lByyC97Nlo600zk/BlzoA4jg0EWGlyKkRqkoBDOocP7GBK
iMmR+hdS0IspZ9CuU34gQzeGRUZLAv76mmiXYLBhL2n9qymaEKK6+pyt3uCf dGFaA2uSaXzrGQbBabcQoKPmJF+zpb3PVebDz1y8e9ClhYUknPd/1IvhbRzm
K5tuyH5ycuIpt13F/dCGMlm0FZSSaZRwMsH0/4ePeLDV0xRMXsZ5Ux1i8k2I VTicOL/Bz9LJcSY00CBtXQiJgfJYe8cU77CmbD+kDAEaqOG32HutrMZTQYNX
SM0ILa0DZ1J8BuCZHjseJn4TgN0g9hf19RhtVl5P2FCoAXIlySVP0dhHRFHB 3vlkpWSI4mwY74GbC51a6yUB1gPwyMfFWRgR1THGwMuKY+ActyGy5njSJN+y
rGZ2dEtQRlP5GIar+3G4GK7usZgeytZtBc/HM0IL5IjyZaHhfIpPiwoF09NM lzisq3ssnmvJOmJ+a/RNEeBBjyNutUWAbXgB4ekhnPWANsVN6JlYrc6thqYt
Q9n6wQtXIEU/mJEE7fBQ1LwsW/WnRkLjJd+Ak96qQ0JEhuENUgCBBpMvKbGv cZKkkflwY6BHoJHLM2b3oM2BgrPRItK57ZLmIlIwn9rJiYs6boRxIt5Up1/I
lOJZVT/0lR2aMBfc1Eh8YgPmc3afSlWAVAiZD7vmM1kGxeQQaLPALrsq/wH6 3dy6Tsu3wu28mRkFB7EcRcW50OaVV4QSmAtQi97pS1fIcI3+Lz+UrBPaMxIP
K2y6BSeClV5kcHm81vI9xo/R2+L5DZt7y57WalD/WJw+M1jMAwgukckTVPOi M+iYlmuVWCCHsH8gvWWLtZxDevm9JL1cMDMcd8DnRZUwwec2KOGg4/W5mnAd
YxFH7TUaRzvQbiWPCKKPQSdlGUZB/IkIq4gPyWuqQaoZIR5Gt6b2L4iApipU 1eeD6cqgn6iNMMArmf16UTJG3/kQG9/B9PadPzR1QGJM150BVqwspleZmMCk
F0YqKj2imPDlJuqZ5lRig0jWILALMEIWHBamkVsiDapcn16WcEmGX4+DvaaP 2gVig/BrPUovobBtTZUzUlTJuqDcXzIRUDmsKxw532Io9wZ02KF7yrknCQp0
5CeSnZDkLnhd3XxRfFKqCeLl4aeABDHFhn9/Wvn1CuPtDMnyn01dtiM2Rkwz CEdldNEBDaaszNSJge+dUbbCjCGGwIQWBFRMtxRdXw7ybznyoEsuOUUORZ+c
+HX0xYxm4aiGVKvOLbgYme0CNcQ0X7FygN+FSmx/sHkAPKGRFRpHhsZLLFhX s/eL5owusKn1ntFOlIX0zMo4DXTTSEKLReMZglfPY+k3gq/fgi461hURTFif
WJTNvqTP+FhgJoEAusEnY0gsei69Dl6mNaRj0l6QgMDnJYBqi6J2punHNkFm o3cMNprZ1hgLQdv64d1vv8V8Bu/iTxcEXxIsxhSHS254p1tCytbow9qLVtlM
fkiZw7YOjl+YC8GTwVzzToH/B9MHZncDhkCz8R0d5cMC+A1MSM1xmxI6ZIig 0KrQ2yWc8B4LkAzL5jCtpXJbBPMd2tshTkGVRaVrNirH5RnSrYS/iq8ooZ81
GWWPGd1D/gJh/RGjx1ChawgWLX3fAxcxvAiT+0EfJRAFU3T8A2Ev5dehb1xg q06eT+/yHqwPKAscyJQ4gY8NKT8fLG30xnj2EcbJ3r7jQG93YkiynIMLVLLK
deBmY3q5Vt7Ba67oBLlC0eDjwQdlIj2BuxK0LxqElG6ZGJIih4oZFBl+PZm0 AgPeTeyUhpQSifB2kVLmIr96JKI7CCUn2f4p0QimDF0RduOAz4+30mBzErJF
JKOjeG7DRHgicR/EGECd/jB4NQMjwMrxv0ab4Epo7cM8apkO6pGAC4g51ekR SDPLD3DXX9S1kqoN9Q5rVZZzD6bH3w08FTmAYBZa4q923kFKfB1w0eiJwwki
CiaOij7udLdO+It37yjQy2HH22/09bdC4CSeggKiiNa1rVeXKEVclJWoFy7/ om7F0ch+VNiLsb+xX02xkizRew9kPhVBU1SkdRQYJF5vI94J5m3gOq8S9gHl
oKo5PX8sEG06QMVsA0KBcY7li4DHsqMM/KlHT9dT9fwVdgjo/lgZCSm5lPaH PAeNbWPillTjiztFWw33mc8JnWquMV92V3X2aIzvFyK5EAMiEVIi5Uo1rorz
vHht2/IT95xh33S6SXxTVT+qwKVDDWpPvNrX2JUpZsTZeIlP1waHL2N/dpLF ZXlu8HmUoYCwHTgubRcYJ2EjoQqGCOr12nN4DAU2NLu3aJNjm+2zZ13y9zwj
8SuQ1RkounoeUr6pd4D3L8o5gXjUknp3fPTm1avj18+Pn0fJLmdR8U1xwSgE OZ0AtMiL+cGRiCiXsqQmxLNhyWGf4NxacvGU2XHkuos4wYDJYqqZL3y/Vt0l
mYJjSuhlr4iwlcm6LN0N4cLi6VhhFK4L7laoBoiC/+IK0URZc5yT2QzKH6xy nCdbeyfXIl0p/7of7Lwno+yuiNaHNuACzIjCkTFCjgiqDIK7huR4xjxaZu4o
jfGctjiQjWefk5WyyMGH0EQ2BdYYqWLdeq2TUlD18HvBVpU/b/5ti8aq0yc0 bQU6eogS7d7/+eaBrJd4JVrXItZVo6UDr1RDr5/FSkJSY40RIbjfLZasdhed
C02hEakApNaIpXNHSOfSgCGw8Yki61bToUaJyJg3GP17WzCpFShYUcLlXiMH r3CqBpPIBaCvsYZTetFhBl6hF2UnsvMWtI+7aeZMEaF0hrIieAtw6rxZXRhy
fmI9F9rCoQ/ZtmRCgRfMAEZIxeWXnEkgJaFsaVyMT5EPvZQobsDBjNrIxWd3 j7PZMLo1BJM6FqDJCcpHENzOWUiaOEjbggREnGFPWSQR/GPiPMVGIfgQIvuW
qIxhDi+KcQyst8D2XES1G6q24zu42xqSBGos0mdMBpfM7tBeeZzJclr6RxMP GqMShIsaodyatlUGcVaZcTwGTFOsPD2X3EUnm26MTJBvMPKkd4ZzpxS3Sz09
tM2vlaibXo+lOxLQELT4K22F+lZs5mRfXVJpmve7Y3KuRb5h9DFb23rMcHZO cmf1IhMx0TL51oS1kKe7V9dMd0JpfCQjrfqD+V+W+StJtNibbTpysa2xy3t+
gDKEaLIh56am5hWjoW/wfS0t+CJGT1h0TBT9UAp8ZU/3TV7tiMlw0JiFrzrG sIEIz+gIAoIJSB3UFONcZwKIDfjOcZqOyXj+FUQG7I1TriUO264pOs3BExZI
zN4mS7ZFQVx0UUsSgVHwzOSG59z5ut/kIQSAtayVMPVvpWHJW2K2Q7BeU8pB TXMmiAMhjVAsXhagAcoo2mJVjlGLAztNQi+IAPBoG5vVGkj0UG8g3UVdzWVj
IVZOMGOGcmpCVyaJcXTOMPvqtuHlohCgboQJbiAeB2ET2JvGZjxWX8sVCf2K a5a27oLlBjuE8YAsyi54Jw3oG+/KErdIZRJMCOtNlk7kgLVVUU2FMlL8lLmO
L2opl1x57iM0PoEWDWbBLI+SwGR4G8fMNGBd9nnLwpDIs5MEVGAZN750Tt0v jGXUWyWciVJF3zsi7YjZ06jYIiPrp8iLowHCkAuONpdGN0mpirq4Y1IWm4b2
aYTTlntBUX1n67dERCvF/QbQSQsWa8v0rqPIiEXXouYaxMheiCr5jCXAJwRV Iscs9XXQmvTdMZXglueaoSlhWxgQnGVqSNHcLtE4w7opfU/OiXSInVF241fP
vStlR3gSVVFQlFrDsMPr1Tut+5h+NPOc8kTcC/Wc7wrmPexPbvb53hxDIaJr x08Ixvy0qEBBGNeL8alAMPzxslvHewsNlZ3O+FDImS+vOEDvjKN7ljec/MjE
Grnwi9JM8PVrzbT62hu9kFExIVsW6x2K99VgHC8E6R4+W1kIKRZTXJQYM+76 Y/PyHB0Mumxln1kvOV8UibaVUf2t3iZcc1I+jEFSqI0Nry/1wwWInsV95HHC
RbJYCO2RAHnU28sZCOLI4hH/RMhH1hM/gV8ITsXMFN+Q66jwd6M/tE1qaIWT B76rkol8WiMpdXZKiF+QKcjBGrvLnTuOMMORIlYy/4G5y3DM6i8bRXBhZ2iZ
7YBS7XYGyZhnNWZyBXxvUdzEmYbwbGdUtBy0kgi0iEtir2QeYavAsl0knERS cP2G3LEtGWpKzhjnOtDelde4sE/l9vH7h2m5zOiDoWZSnxpSVPxDzHXXf5C8
oNnA9kVzJrpaEzZoPwzBZ/c4/eynn+RNA0gYjKeiPTMsJu/J27CyXEVVBVx/ Xswfhmqdsr0Z9khMVFoRctinWLsEww1nSbNoTeKFMI/WU1Z6g4Gu9OghgsoB
28v13m/jhhYlldamuGQQqx15yAQ082gnUw54PzxedWXGjuYL55+WBe8N7PIe jiOuOo7noQ3JtqgqKMMegR9jhr3/8C4PVnqQ7UpZn6JKEHZMiGrNCG2tHeeC
uIW10aStovnRLt3s0ukZKntRee6pflCTpLimXNpMfFwuXTc6rckWCKi90Zad MAziM0XmPMz8OgC8Qfwv66sxqqy8nnCgUALkynpOpqJRj4jxgkkqbe9WIIxm
S5OJi9lym65AUxDFwpntDz75sl70BIWFOrCXnAidkdYVGrAeO1TcVYlnQXav MhiGu/t+uP1BbpQAh+t2gu/jGaEFckQgs9SQADmoRYSC5mmmoWx954X8ldwf
HT9/XMeYZjoFXGipJYmzjwYRED5sIi2KRLds+3Oonxb/4R2MIQrrd8A/f4/2 THCCanhIjV6VrZpTI2FllDHgpLdqjxAzbXiDJFCgvuTTUuwrJQU38J2ShQET
/gdOCNE/sS+R/hnTnz/yP3a98tgLv/xj9t/Z7gxU/567uQexUSE3X5gMKP3z e85V/cQoNoBAZ8+pZBVIlpEZ2BXfydIp5ppAnQVO2WX5D5Bf4dAtOZisbCWD
eaBz6ZfBC820C7jrd4MXDly/5cLPPcEYuvAPPGv4i0OU+/4VMq20np+fZnwU y+OlFvcBQYJobPH8hsO940xrRqlvFqfPdBYuLCfYRuZiUMmLdkXstld3HJ1A
zMr8osmX6ZEAaqVbFD/uyLL7H7MI73xxW5O+QsqmXQMYrJLGr3zRp98Tzvux e5Q8qogGgzbKKvSCGAaJ1S66JK8oj6lmlHnonTCxbTrOZHWhpyLSI8YKn66i
VGos/CAUTlJoAzf4FvJP3vpsFBB7vek3hhom5BjIscS+puKxJJbZACDehrOF hmlOaToUgfEbdglKyJL9wtRzy8tB+e+zixIeyXD0FIXCMXKDpCYksQteVrdY
5VlYncuFzd8NaffQJzpyp/B47qMmX5R/Gz6gL5tmfEm/TM5mjdYWjPtS2xlj Fh+VuIJYfrgR2EBM2OFfnyaPvUR/O6O6/KhLquVhuXUxzOCX0edDmnWjNFRN
LBwuZOZlJX9Dd+0qrkYSiOTWc5iTUUpTr8szFqKTRcwrOEFwGXWkS00mc+Iz Xbf4ZOTnCkQTs3zNsgG+C+nc/l7zGHoCNCu6jvQMCkIpsspGX9I2PhQYSSCM
Y7N0et72Wt8afVv98i5oiD1T8iORRnWoWQ1K6gNPBPOeLS0HQZ+D6/DOkAJo b7DIGFWLdkuvgqWpjOyYhB02QOBmFEy2BWI7U+9q1z5mtl+Zw7YOZl+YC4Gk
RICTCJ2PZwpSOPlGSyx3I7+/bXDo+WRFREynjKF+wtTpsjf84pNwMnmOdQHk wVzzQYH/A80HZncLekCz9QWNZWABPwcapIbJTRYe0kzQjLK9jMYhj0A4hETn
B6gOy0WE+LWimsRpk74tjgE8l9yyyruow8PTgA/pznAxI4rd7oAE7aXOVDw2 MaUt1AWLir6vAI8wYETafadNCcrB5C1/R/BN+TrUTQ3UEFxsUx/X5D14zSVd
2dszObX0aHJpKTiOLf2Of+u0wj//CydWtitytBf/GlTv1hEN/unDhL/ufv5z IJe4Nfh28C6ZSEzgoQThi/oghVsmhvLIoVwGOYajJ42W9ugontswEb4whHdh
y8lm/qRHrT9Uxrecsulc3W0092+9FKb4vvnBvziN/OfOlsDW0dx1Gu2fO9sN DABXvxt8mrEVoOT4r1EluJQyJWEeNdMHxUiAFsQ1MqgJxSNHeSO3+rVO+E9v
2+7/SnPiDo/5uvvvZnzc6UnqnX39/V4Mt16xqz6RdgtaoFGwN2zrhNNVzZy+ 35Kjl52ON//Qp/AKHZQYCoqpIpbutl5f4C7inK5EvHAGCSXd6fVjsWyzAWp9
ipXfB3snQcMo2ns2gMhnLnkpSUaT47wGNW33iE8zbUklYoxToX7yINB73HAM 6w6yZIdEyIDYZTlRBkHVo7rrSXoehe0CWj92j4SQXEoiREa8Viz7gcutsWk6
C87UDgp9ZXIBBMXsT0ER910zrClLwhMcRQITolytFwqP6JeGMGsjWV2Gi8ep 2yamqYofld9SnA2lJz7tU/TKFHbirLfEh2uDvZexOTvJYu8V7NU5CLp6EUK+
s6x42FqbyPiwgHQ29kgR0+gmPmSsdRkw8FwJNN8yqpTLcplflFURnxwcWc8X qXGAv1+WC8IBqSL19tnJ65cvn716+uxpFOxyFljfFOcMZJApeEYBvewl0W8z
sec6GG9JPdcdn230jjU8kMWkmN3VFTa+7KEetsKyd1lwARgmjchO/fs6XyhZ 9ZflzCFoWTwda/TBdcHaCgkFkfNfLCGaKKuNczCbcf2DibIxJNTmFrLu7GOy
pDQfDZj4iEVUTn9OmPHhHU07Qmso5pR671HgiEf5CrHDCobZFjoim2y8NJdu klU52AhNZFNgmpKv6LbrWSeZpGrg91ytuv+89rfLF6s2nzA1NIX6owIWW/2V
sVN79SBsfVJuqiOXwBs/gw3IbF/nAVPUCBDOUqDysiktF3j90tLjy1AsHsHB zp0gJ0wDesDWB4qsVU2XGgUiYxZ4NO9tvqUmsWBSCmeMjRyYifVCOBCHBrJr
bquRzwwrgv+IPLOFAwPD7RE2SDMVzjQMFF8R/vt8fXHhaZkwlG7B6jkxJqb7 yYRQL6gBDLKKszc5jrCyLLqcz0+OD32UeHLAvowqqMZ3d0iuYUYwcnEMrLcg
aOg9XQQzctsMd7bxyBDIp50PxYU9XZ9TTpIZdpif3iFmr+givDrFmDhsFiKX /1xEnB4Sv+NfcKFRpBxUT6SPlwwumT2hvQw7E+W0XJLGHSgeDcfJ11x3gV6P
0X6aZC9zghITqpbap624iUNvnljhcLdn6okVU9f7BBj4aKHknI1iHmEmI6Sv 2T/izxDA+UstBa4Qm+RcXVB2mze7Y6qvZb5lADMr23rNcHSOQAFOmICNetPU
GSgXj5oWRtT35ivfnv4iQbRASxCVxWurQvYT4bdwR3aOvBENb2/v5XBkikC2 VIxoNDQGX9fZgi9i9IRFx0TODy1potUwfJFz22NSHNRl4ZOWMbK3zZJjURCz
vag+0xnGc8UZ7XJBYCDF3ckbCC0dWvLc9MzA2m3SVMoxSBF0JxqDdHnBnSNC XVRiSmAUPDO5KVvhfNpw0ghhaC0HJkz9GylA9YZ48hDv15RyUYiWE9SYoYia
TbBXcu3Ed67OskFr+wYTG/+ImX0nS8AgGlEB00re1YTozeRdb1STA6zN6Cut kJ9JYBxtM4y+ul2Qu8gDqAdhggeI+0HYBDamsbialdfyRMLg4vNiQMpT4rp3
Adk3CclkDa+gf34gTMaHAGcBW6Xgu2Yf4AF7/t745wMjHd9qARsTfus1dzHW 0PjwWdSZJXNGSviSEXLsMlN/ddknPwtdIsNOwk+hZoQxpXMq/Ew9nLVc249S
72LtJh+75YK7fv7Q7fGVt/kL9s/tM3Xrny1RtDuPoG5usFe3//l3/RT9M5lM RFt/JCJuKq4fo0ziPnUUqWJHkRKLpkXNaYyRvhAlAxpNgG8ISppX1o/QEiVi
/sX71U7/itv9bvEGd7dot9oKanW/khwMGhba2QYvWkShodT4lqJatnwX5T+0 kJNavbDD69W7rftpAajmOaWa+CqkhL4tmEWxP7nZp6+wNqjgTMeNPPhZmSr4
WNscgxoNCgr6ipF95xsXaWw9mCg9a6iOmALSG/lRMJM4Q/GI8GluoQ5NTuFe +Y3GWX36jj7IqJgQK4vlDrn7alCOlwKWD8NWTkNyxRTnJbqMu36eLeZSeyRA
hJTjgzHkgDCi1Wrd+T466V1u9xiNj2I2+Lj0pNwL1W/khWA/KQJKgBETv3pM HtVqdAbnN7Kgvz8TeJLlxA9gF4JRMTf5O2Q6KoLeyA+tEB5Km2V7IFS7vUFi
+5IpoBErYe0gPUQJU53aPmjnn5ezdjvVINxGgwkurxw1XOPIh/M6YdbGtLl4 /XmNcVzB71sgOBGvIcLbGREtF62EAS1AkbgwmZPYCrBsH+krkVdoPnB8UZ2J
LUMUa1zpBYbPSnq2E2dLv7DnEBsWNPBjuKtTMhelFYmRr7iILhxuyepIAGyH ntZ4DeoPQwjcAw4+++mn/ab+I/TFU96f6Rbz/+RtWFlOxKpCakDbi/TeaeMC
5YV6WxoSRQ04Loo52yBSGhrZrlfrRSV93DlxyuXUa9/tLdRyJlY4L/BbbjR1 RSVl56bQZthWe9LIBCTzaI/MguhQ8KprlYNovnD+aVnwt6FWiAduYXo1Sato
iA3N/KgjkzxatjGccj4wn1LxEAljuDzbIlTEsuUJDUMKETfdtMnnVJTKw5I9 fiSUKSad3qFyFrVqCaUgaogU15Szo4nSy6XrRrc16QIBtTfacXJpMnExWy67
Rvy0xSeUF8ytI48qUZlIoFze5+pGNy5B+xeYOzcVitSqm6AD9PCnzv0OrTLE GJgOIlc4UwbCkC/qZW+j8KYO5CfPhRFJUxMNWI8NKq6Sx7Mgp9f2nwfXMSya
phMPyCpuXvom4X/iUVCBOHPw+u5Qnnc3M4DSkV0yGqUURrHYXweyoDe7r/7n bgEXSiRK3OyDwQOEgU2k5JzIll1/xzq0+I9PMLoorN0B//w96vvvOR5E/8Q6
d6/3hE2XksnwpFdaKhH3qLyBRwqF67XcBQ/QJhfpNpHP9pGEGz5Z0JHTeoW5 c/o3pr/v+R/7XngchC+/z/4r25+D6D9wbmefQgf8a3f/JR1K/z4NFO3+PPig
Uw9yId6skcvi2hv6oBRKlMCuIl8k5xVyWV8qz5WShyFcdJ0Z18DX43DgYwXN mXYBd/1u8MGB53c8+Km3MYYe/APPGn5xjPu+/4RMK63np6OMr4J5mZ83+Sq9
8pId6bynJKiI0ntW+PTX/HniIlI7F0Nj+n7bl5hsJ37xm93X//O7l3vg3S2Z EkCsdMvij3vDV8reZ7cz5iu8bloChqEqqf/K5436M+G8HUvZykIxQu4kBTaM
6gce4+Px8NXw+9/Dr5Ej5rqcIcFsjMliwlTEoY2XxBuQ4xP0qS2dQLonwpux pKqEGLsC/wSlgCqRmPqRKGFCiIEMSyzpLRZLopkNYOqtN1s4o4Ujulza8N2Q
/yKmpOAMET4RXvqkg9QtB02g+yfHI50x7C6vhxa5qgSDHvHFszXjnQrrrdId dMcacT7JIZhTeD33UZM/lX8bvqAvmmZ8QV8md7M6awtGfanujD4Wdhcyj7Py
XG0tRZybzNdH6Xu2cNRSV27dYC0KINYNCLFrpIq0WjcuYfWYPC3X6VHPYT/D x6G5dhknNAlEcuc9zLEo5bzX5RkLV8oypiacILSMKoymKpO58Zn/mQvG73yt
k8PXh71ehtiKgTpnarQAD1w/EchJlb0Dbxakd+McPaFslX2HZx8pBCSiFeDs JNG6nSnQ+yAhDkzWkHga1aBmMSiRD7wRzHt2lJAFeQ6mw1vDK6AeAY4hdN6f
MC7PjI4hCG2W18izqNVo/JrdqGNRKHPaY/z28Jm4++DTvHgwkzbH2Y7UG+8g KUjhZIyWm+7aYgG2YK0npZUtElFg9WqdcuXiXveLj0Lp5BnbBZAfgDq8LyLE
T8F6WSkgHRlIuL/SDtbevHj3bpQdH++Msp3n2N76DRxY/ha+Ntt5LYGpnXe6 r92qiZ82qcLlGL5zwSUIvYk63D11+JDsDA8zotjtD+ygg9SYivsmZ3sut5Ze
isXMXkT1AXDdn4t2hwoPBm1yGN/swQMdHx18N44RB7gzopHePLRtw/JjCmE1 TS7NJse+peP4l24r/Ps33FjZvuyjg/hrEL07ezT414cJf9nv+e+Gm838pVet
+my6tutd+abiYAdIXsu0UxRdezHZ2SIbZL17mYCjklxu4nO+QTqIAQuuH9Es v1TGN9yy6Vzdrjd3bnwUpviO+eCfnEb+u7UmsLM3t51G+3drvWHX779QnbhF
aZxyd/9gf2+rjFDck17XbhcOO7E8Yb8k3+h2/rzD0DhUCDFvtZdA+0GMvB2H M1/2+9spH7dqSa2zL/+934Y7n9hXm0hLvy1RKTgY1nXC7apqzs6rOeg7CRhG
RRyXYF/c9oFgtV5nOwHl6h+9E4SewjtwnSMZOE4aykm59S48Y2/bONsd0IiY 0d7zAUQ+M9NLVjOqHNMaxLQ9Iz7MtCOUiD5ORfpJQyD3uHwkJpypHhSK1OSC
SH8NT5HnCrQRM/FMed6mxSWg9ritABaFEHXhU/eU1Hx3XTOBRah/8Ngs/y3H B4oJpIIg7ptmmFOWuCfYiwQqRLneLBUd0U8NYeJH0roMnY9TY1nRsL64mncL
wTjzVSeu/1vcxS5s6uw1HLT4ntd5oJfp3+WcEWS8/BDEdwcjdCDmPvLrec0E SKV6DxQxVXPiS8ZqlwEBz5lAix29SukwV/l5STSx5uaopcRYbLkO+ltSy3XP
Mm2OxZbE8refM1ON6pmownXnhRI4E/MZk5uSmJREDsvFOXmo+sDXr4liGfH4 Rxu9YQ0N8jYq5rc1hY0te6yXrRD1XRScAIZBI9JT/77Jl8o1KcWkAyI+IiKV
aLh1i01Ye7DnJHwqt0S8LXj/n3dCkfKpVJK27pDxHszIsH/ALTrf6Tmi6xIb 258DZnx5R9OOyBryOaXWe+Q44l6+ROSwYmF2uY5IJxuvzKM79NRePghrnxSb
1FymNTx/ptcb00q0NIkVse1s4b2lrYjeZLuig+jHHcL2Tjt0CUGyUvV9i1jj 6sgk8MrPYDVJ8nGw83FIFY1LNhk2MBvScoEaMM1evgj55hEa7KY0+8wQK/hB
+dOuz/Hw0+P4NBr/O81LWInVxtO7sp9hLjw7hXs4STY3XYxDSgpTRRV8H4gt 5JlNGxjobo/zQUqzcKRhIPmK0N/Tzfm5Z3ZCV7qFqudEupieo6H3dBHKyO1S
9r9H3wv3qvtLix0VMM79DcKs4e9i9tdkbzAVax3Ovv6n6kbbPKWQFU7y04yW 3FnHI0Ugn3XeFRfOdD2lmCST9DDJvUPIXtFFaHXyMbHbLHguo/M0yV7khCQm
qakXXrQZtUwTDfJSNFrmGkYLQ81wrBo/eD94119kMv5qvDqNx0azWrbyHAaj UC2VwlxzJYjePLHAgRUg50bZJfz3PgAGNlrIWmelmHuYSQ9pNAMZ51EJ2og/
ox6/AhsgJwi/FIe0ayS4KwW1wgigCswuZAEvuvFz9DzkKbsMY6SaZnXbKiJJ 34zyzenP4kQLzAZRZr0WnmU7Eb6FX2RTpJ5o+Hh7K4c9U4Sx7Xn1mRExniuO
EC4An/yAAe5xCF0J79gv5+do02wtnsYSlhlRrs/WJC5oDKNPul6OsK8I1VAh aJdLwgIp7E7eQGDpUODnujYD8bcJUylNIXnQnUgMkuUFl58IOcFeyLWqaNPf
Sxi1LSu6qZ0emRPic5AyHCpBKIk7gslyy+K69V2MS+nWDdtQHiP1tVJI2lGD kLZ9jYqNf6Jm30oTMIBGFMC0krdVIXozedsfqsqBJfP4k76O21cJSWUNr6B/
SP4OUBXYOcdWuFok+XtL6efp5ZSK5F0hdNSm0V+vB5LxXhzXTvr6jh0qqQYJ vidMxvsAZwFdpeBfzd9DAwf+t/HnAz0d36gBGxV+5zO3UdZvo+0mg93xwG2H
3Empg0GqhcFbLyEd8Z68uZIqcz2+xdc5+c0ofem4Mag6L0082JHz+2rokBgZ P/Tz+Mmb7AX7d/NM3fi3w4t26x7UzTX66u6/f9VO0b/JZPJP/l719C/4uT8t
cuamWBUknb7fkd3D9jh58OkB/BnB3/uH+4f498HhAf397eG39PfDw4f096PD XuHulu1OXUG17pcSg/kB623gSRXdYxm5hlLlW5JqpfZu+Q9N1jbXoHqDgoC+
R/T3d4ff0d/fH35Pfz8+fHw4cg8+PTl8Qv8+hD/497PDZ/T30eER/f388Dn9 ZGTfdOsiia0XE4VnDVsSs0h6JT9yZhLtKF4RPswt7KPJLdzzkLJ/MIYcEES0
fXx4TH//dPjT4dDB8+749Pjdn46f946YP/c0rllpo0V/pqp31YaTbRpzPB6T Wm+0UG8/yuv2n6HyUcwHm0tvyoOQ+0ZWCNalIqAEKDHxq8d0LplFGrESVg/S
94FG9ksy4sfkMbNnGcb1lt1gnOzP99ja52CRsTW+8EKHZSHfeYYIWfGiBYW6 S5Qg1anug3r+tJy3u9kK4WfUmWDyylXDGY58OW8SYm4Mm4vVMsTSxnleoPjA
M2RumkAKEf8MZNjI3hJXQ1rZRCXbssbe9zGkBdt5+j3HNrV4RRIEmlm0il+C cwIE7Oq+ExqpA5DFtcRfdcoHo8wkMfAVF9GFyy1ZHXGA7fF+oUKZhodRHY7L
EXbCVcMkuxpX/EfR1OK9nxdqjm5z/d0wlfi+pKZzy4pNLYTAvB8NhMtYgVMo YsE6iCSGRrrr5WaJe1Ro8SnXHNOpN752XMjkTLRwXuA3XK3qGMuj+V5HKnm0
4Jjz0MORttEg3NBnmUiv7JSLRXGRLz748OSOAKPJ7lbSqkzb9fAqTmQEXK5+ bGO45bxjPmXzIR7H8Hi2Y1MRUZfnRAwhRDx0syZfUEoqd0vOGFHcFh9xv2Bs
klEpLKXVQCG99rivk3FnP4kb12b9uY/BndQ8iT58yr5hdjIJX0wvo+Q3TvXr HalYmcqEHeXyPlc3enAJ2b/E2LnJT8SlpTgmN37k3O9QK0NoOvGArONKqK8T
m79x6PN4DHf/xjd4DlyXrZDi9b6p/znEq0MfMQELeCWpmtLLxk0R2/ijsRAG CinuBSWIM42vLzHlqXszAygd2SWjXkpeFG/7q8A39Hr/5X//7tWBEPJSMBla
68bBJWbUZttT6E1+3ep4rpAVgcITcMTkEqD9z5Px88nH/B/ry1q5TYrZuK1K eqmZEnHFy2uoqHBzvZJfQQNaJyM9JjJs70m4ZsiCjpzVa4ydepALUW+NsEpx
5N4ATcktyijsRoeSViCHbLdC5MvOUx0JsgBr/sTQdoY3JZjJTBr0DvQwAief ldr1KZQogV1FtkjOK+Sy/q6cKqsPQ7joOdOvgdFDKzBWAbO84IPWExGUQOnt
5XBeg2I+umzQS4L1eYFtPpf5KHubg3ZCsOv0VV6tQbe/Ak1+CUbc26akyuDX Kmz7FQ9ODESqB2N4UN/tGoeJdeJ4X++/+u/fvTgA227FRD/QjPfGw5jh+9/D
+NvT9WJRXuVgwr/CPH0FOq9etloH9jyHozV7VlR/wx7TDKFXViJsDgJygv1z 18gQc1XOkaE2RmQx4yqi0MYrYg3IsQVpddzS/aMnIrwZazliQApuEGET4YVP
eG40Lar8S8ScCCMj4OTL+sK5P2a/+x0aO8czJIG+37LJ9LvfZW8XpFBhneor SlDdcM2EYgFkdqQzNi2CHUqGKoGgR/zwfMNop8LaqvQLzrSWDM5tqFmv79lB
kRqtR/LEt2zN+PhyDk+bE7REi601xmsaTZ9Qzyhit4LvVCNdVAkHSNAtCrUQ couTmevxanH7YdKAMMNGgkgzdeP8VY/I01ydHncdlkR8fvzquFcOEes4UBVO
MA7mu592NXJRr9hDZP6uGVpF47Lo5mPMthSw4uP970DPZ78UxWqcIx3ybZc/ 9RXgdesnAkmtsrdgy8Le3TpHLSBcDSkDVIwHBDt0xvOpo9dBi+y5vX6jzMC2
wsvBQ8iOjk4PHhwcBJXKBU3rJTUu3b336Nsne7c97OHXvftbvJznHo2Fckkt hwhCajzbjyoehRSnAwZvD1+I2f7dj4vi7vxA6n3tSa7x/9/Y1fa0jQTh7/sr
K2UT3HzrAQ2b9ALWiPlAVxofg3HvP9zDi0/46Vu3JtlNzMMFNz34lm46WuRU fO4XkJJAAi0FtXcyJLTR0RQFdBWqKmSwC74LSRTHpBT1v9/MM7Prje2gIqGF
h8FY4NhkYpqN3XsPnzyma48/rXIuZw8NiQSdRVbw0hcftnTXPt3F2b4xVe8Y ZG3vrmfnbWeeCRmjoHiY2nB0xh+RAk0hJ958HI9bwWAQtoKwz4WyP5O4cpdI
Sjrh6wxaSFga4MbH/19hV9PTMAxD/wrS7lPSfLQ5ViBuXLmiCRBCGvQASPDv 3yAcqVsqHNu3mCZ+J2QHUL+rEEkHTfo4hpfs7trhQeq9OEQeX9jCQF8e2aZR
8XtO2qSt1EumdbWT2Y6T2LGtgLIxkGV90qSd2FuWIk6rOHSdOHOqEdieS34i 6ZBKjxrmjJ7LWr/PU/FzENnlgjgFx9rHTriBMKC4O4IgKQlrG2jQVdIA4hV1
IJON0Mn3A9sgbTD53yxsWbhCCLzlB0IkQic+SZFtIg4Dy5B8Wn7zbBV7j9Ya amFlnF9yq9vrbtcoJHQ3/y2S8JdTlunvytwMXgtPgrnAOtq1I0R/IhJs2y7f
tvZQoCyG8jC1pW7maMSsbMvOAaPzyrfxisBMMDqnk5Cfos90u15+N3KSL19p XTsjlaJxYqSdrmTEZUSru6c3fLhyqK+Sf6X+nGZWb9E9tjcN0F8MFP7tBCO6
1haBpeblHMwmHGLoG6HAnftVjki1rDLWcXp7fwZQb9b0/GgJGknKSCLGju0x n37m11gGh1/fjcTrpBgB54Fgux2ZI/D25WomiBVlyoMLx3JTGpT6mEs0MfVv
YQwJAwcFRtHkucQ42oQKN8UugO46dtG5ihjYIv58X2rFvhVFgJLdPqngUqCF eTMTq3VLOiLZys8ZxSWiTP0qYzzy5e4REy075Yi4nbPXQZlplLQnCXOQ45cP
DOvFcRzvarkXOMd/6LvMGjh7cW+egbZYwdpkZ2Sj8qoKz17XG6v9LZo5c9/1 gZd/6sCnyn43qYV9BtiZQKKCTDJAyko+TlwmevDjCwAzcwg+62rLyZPFGuN7
gNEIQmuqzqvc2bkS0YuouT/e1mHCB0RFPbGG7J4rBzds4F/RaGI499ABhNzb ROox1UvWgFr4+quwTEu+0NzR3EQS4iEQDN2elPYcW+Fh38u6Di2ZWc3r51WI
oBIyO9nKIf22HITkVaMEfMxx3MtL53JcOuvaQp8jkTsgD7GF24YDV51Y1RLM ExyJHIs4BcDOBrRc7EY2IPM5pM/7EOG8t0u2Aomsquz7NyicBU9e3LDUs3L4
37m4LubSjfkgCOHBy5s5v5LRjhx0FB2XyE3Ka+DzEI7k1STgv8fyCMcXPdOl Ym0OY7vtfZK11au3dE/TejhICrPfqWxwdOZhVdJRlR0clGgW3QM2uXi/Gt6v
mA5MKyeXlEGc65ojTT0QKpu6Fc+nTb39jzrjr2oTVH0rLKmMg4Kyh0Zys7r8 cZLUJJQAt85enp/dX09H8E/x8h4FeEGL2cQRtYQoY4mJUtKFTWktx0gDDHiE
bKq/f+Xc9VWeHozCNjOcOZd2a3ZXUccCRp3oBplT/8MMB+yehAEA 1llw2XjVV12Cb54JZ52va2uZ5XofiTxnzv1IIj9GvL5mguQFo9llGqIi4T5T
0rIYNTxdtvtsZuhdtiRmEfnL1kabAhBB8/7dSQcNcFv85RbdToxwuY+tt20T
pTlfJQFEe1KASFjzZQO0eGhxHRIkTDEkGMqcpctbf3l0TYDdoDk3yDfIpu0k
nQu4bpauclf3ONNC37QB9TaaS6tJo0sUlJR5EJPgSjt+NqsfNn7p4/c5LDmL
OjJOFb7aKwxYq5nkmSpGEiVdMkeI9GmiwbAKNUy0rIjftgu4wyVMtwxZuC6Y
xSU1uS2odeykkKi1VBbrgzVuMzVJh5aH5bxI5yLkXHkkf+P6cmT3xy79tKjt
Rt2I217UQ7sX7aHdj/bRvo5eo30TvUF7EB2gfRu9jVpm98dhdIj/I/rh9jg6
RnsSnaDtR320g2iA9jQ6jZokznhwMRj/M+jXZMtVhdXyvjx8u3/occ4PyG23
HHATk3z3R7sdfF18J5PgW/AlrcBAl2vLYEWi1H/PfqRJW40feok4YLKFBzn5
9HyCBwtZ6wmlXC6ho5zjKtmvjCa8chUMC6hmbPqLbOSQXP7lQiUW9XPOUVQu
OrnMMZeBsi6GBCJTHWRJtKQZ8FaS+oXs54sBD8iblqvByEHOtY8EpVUMr1HF
0PfY1PxJtZOo2gdR1DeuiIWpwHaU1ZTcXx27TTrCIeFYKr8+scjIaznEZoO3
xkAXNijBWTzgVtdiZhto+UZRvzU5CacKdcAm8zNdzHKDo44Xqad87RbhaQOl
CEmgHoaNT2Yj8WlWqJOV3ktpUgePqNVh87xsvjp/qiS/Bf1WReh2w0hPr4ZB
m8cr0gRCldh0rBYOzr5ubpiAVR/FmaOcdTKA0ZyTZlVC73XeKGJncLDX6wVb
If95sXwinvWhIG4fble3BDMh455ndRPHpm9pvYDt6KG86RHulCFwGiZU23JB
OGSnC3xsZ/H0rojv0tB3msKjBeBk4401eHe/XM7zo52d1WrVoZu304QRjzuz
xd1Ozv3uuNsOH2L3dl5l9hnXE33Gn6a6x7n6Jpf30YgEZHUjupYEvBhjJRS0
Bs27CkE2TpFWCCKTqOE2Y4LRp3kFCLkeFZdKEaDmOIFvskQjmxULo+G+SSaS
9PsklvpUK6QoVoq1iyzOHJw42XQMkGnXmHRUYDqhJpLDPwvwZtr0Ythxw/6J
M/g/2pfsahSXXMnkz8V/yNz1+ZU4SsTL7llsv0RolnwYTsekwGLgcg3fD5ts
dc8DDby0htAE2K3qpdEyYmtQFyowndvIA3vZXCPF1TdAeW0Gj4GYYpfCGZHG
UOAWoAfYAxlmKur2vEmtMb/JZ2qayzh0NaYn9isSoHxbKxi0Gs4ZRBmGD3Ug
ATzNRxStxjhtdzwPHS0k+kjv4sm1O9cJNaMEXguL9RfYUmnyFjs6AoH5GAbA
EEA8Ail3IxcwO2wv/SlJ0fCgvvbrUfEoXIeJ34pbLRh2yhnjYYga4qUevTzH
punJGH5/jp9Zpq9o/7aa51SfDvDIMIlOcDKb6xl35mjjpaOu9UlzBiGzo0ma
SLg7K0RCWmnyPgSiojs5LBXmRbzK7RgfGWEG3l7igLGedv01bPc7/8U/i/uZ
xYkivSOfZoxjRDxESkbiDAMczMI5lKFDNt8oWzrYOA3T4gRqdWEYD4OqdEAI
ANszWeDEBDkQ/Tgmkyj/xc+mT0/uF+yKopf3kTWXh9h+cR6TSsiJBLef4mmB
/sQZnj+RbnVP4uN8wekWtvOIe16QOMoe46n98BNzyimZN7OHfCaf8prTN/2Y
LJzgOJ3+GxMx0DeSuWSx4LisE1EZVz6TVbTRKBb1jg81/gdLALsS3JQBAA==
--> -->
</rfc> </rfc>
 End of changes. 125 change blocks. 
1497 lines changed or deleted 1070 lines changed or added

This html diff was produced by rfcdiff 1.48.