<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version1.7.291.7.30 (Ruby3.4.4)2.5.9) --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tls-esni-25" category="std" consensus="true" submissionType="IETF" number="9849" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion3.28.13.31.0 --> <link href="https://datatracker.ietf.org/doc/draft-ietf-tls-esni-25" rel="prev"/> <front> <title abbrev="TLS Encrypted Client Hello">TLS Encrypted Client Hello</title> <seriesInfoname="Internet-Draft" value="draft-ietf-tls-esni-25"/>name="RFC" value="9849"/> <author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <organization>Independent</organization> <address> <email>ekr@rtfm.com</email> </address> </author> <authorinitials="K." surname="Oku" fullname="Kazuhofullname="奥 一穂" asciiFullname="Kazuho Oku"> <organization>Fastly</organization> <address> <email>kazuhooku@gmail.com</email> </address> </author> <author initials="N." surname="Sullivan" fullname="Nick Sullivan"> <organization>Cryptography Consulting LLC</organization> <address> <email>nicholas.sullivan+ietf@gmail.com</email> </address> </author> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood"><organization>Cloudflare</organization><organization>Apple</organization> <address> <email>caw@heapingbits.net</email> </address> </author> <dateyear="2025" month="June" day="14"/>year="2026" month="February"/> <area>SEC</area> <workgroup>tls</workgroup><keyword>Internet-Draft</keyword><abstract> <?line67?>109?> <!-- [rfced] References a) Regarding [WHATWG-IPV4], this reference's date is May 2021. The URL provided resolves to a page with "Last Updated 12 May 2025". Note that WHATWG provides "commit snapshots" of their living standards and there are several commit snapshots from May 2021 with the latest being from 20 May 2021. For example: 20 May 2021 (https://url.spec.whatwg.org/commit-snapshots/1b8b8c55eb4bed9f139c9a439fb1c1bf5566b619/#concept-ipv4-parser) We recommend updating this reference to the most current version of the WHATWG Living Standard, replacing the URL with the more general URL to the standard (https://url.spec.whatwg.org/), and adding a "commit snapshot" URL to the reference. Current: [WHATWG-IPV4] WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May 2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>. d) FYI, RFCYYY1 (draft-ietf-tls-svcb-ech) will be updated during the XML stage. OK. --> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <t>This document describes a mechanism in Transport Layer Security (TLS) for encrypting aClientHello<tt>ClientHello</tt> message under a server public key.</t> </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> <middle> <?line72?>142?> <section anchor="intro"> <name>Introduction</name> <t>Although TLS 1.3 <xref target="RFC8446"/> encrypts most of the handshake, including the server certificate, there are several ways in which an on-path attacker can learn private information about the connection. The plaintext Server Name Indication (SNI) extension inClientHello<tt>ClientHello</tt> messages, which leaks the target domain for a given connection, is perhaps the most sensitive information left unencrypted in TLS 1.3.</t> <t>This document specifies a new TLSextension,extension called Encrypted Client Hello(ECH),(ECH) that allows clients to encrypt theirClientHello<tt>ClientHello</tt> to the TLS server. This protects the SNI and other potentially sensitive fields, such as theApplication LayerApplication-Layer Protocol Negotiation (ALPN) list <xref target="RFC7301"/>. Co-located servers with consistent externally visible TLS configurations and behavior, including supported versions and cipher suites and how they respond to incoming client connections, form an anonymity set. (Note that implementation-specific choices, such as extension ordering within TLS messages or division of data into record-layer boundaries, can result in different externally visible behavior, even for servers with consistent TLS configurations.) Usage of this mechanism reveals that a client is connecting to a particular service provider, but does not reveal which server from the anonymity set terminates the connection. Deployment implications of this feature are discussed in <xref target="deployment"/>.</t> <t>ECH is not in itself sufficient to protect the identity of the server. The target domain may also be visible through other channels, such as plaintext client DNS queries or visible server IP addresses. However, encrypted DNS mechanisms such as DNS over HTTPS <xref target="RFC8484"/>, DNS over TLS/DTLS <xref target="RFC7858"/> <xref target="RFC8094"/>, and DNS over QUIC <xref target="RFC9250"/> provide mechanisms for clients to conceal DNS lookups from network inspection, and many TLS servers host multiple domains on the same IP address. Private origins may also be deployed behind a common provider, such as a reverse proxy. In such environments, the SNI remains the primary explicit signal available to observers to determine the server's identity.</t> <t>ECH is supported in TLS 1.3 <xref target="RFC8446"/>, DTLS 1.3 <xref target="RFC9147"/>, and newer versions of the TLS and DTLS protocols.</t> </section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name> <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. All TLS notation comes from <xref section="3" sectionFormat="comma" target="RFC8446"/>.</t> </section> <section anchor="overview"> <name>Overview</name> <t>This protocol is designed to operate in one of two topologies illustrated below, which we call "Shared Mode" and "Split Mode". These modes are described in the following section.</t> <section anchor="topologies"> <name>Topologies</name> <figure anchor="shared-mode"> <name>Shared Mode Topology</name> <artwork><![CDATA[ +---------------------+ | | | 2001:DB8::1111 | | | Client <-----> | private.example.org | | | | public.example.com | | | +---------------------+ Server (Client-Facing and Backend Combined) ]]></artwork> </figure> <t>InShared Mode,shared mode, the provider is the origin server for all the domains whose DNS records point to it. In this mode, the TLS connection is terminated by the provider.</t> <figure anchor="split-mode"> <name>Split Mode Topology</name> <artwork><![CDATA[ +--------------------+ +---------------------+ | | | | | 2001:DB8::1111 | | 2001:DB8::EEEE | Client <----------------------------->| | | public.example.com | | private.example.org | | | | | +--------------------+ +---------------------+ Client-Facing Server Backend Server ]]></artwork> </figure> <t>InSplit Mode,split mode, the provider is not the origin server for private domains. 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 terminates the TLS connection with the client. Importantly, the service provider does not have access to the plaintext of the connection beyond the unencrypted portions of the handshake.</t> <t>In the remainder of this document, we will refer to the ECH-service provider as the "client-facing server" and to the TLS terminator as the "backend server". These are the same entity inShared Mode,shared mode, but inSplit Mode,split mode, the client-facing and backend servers are physically separated.</t> <t>See <xref target="security-considerations"/> for more discussion about the ECH threat model and how it relates to the client, client-facing server, and backend server.</t> </section> <section anchor="encrypted-clienthello-ech"> <name>Encrypted ClientHello (ECH)</name> <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 use ECH must publish this configuration, using the key associated with the client-facing server. This document defines the ECH configuration's format, but delegates DNS publication details to <xref target="RFC9460"/>. See <xreftarget="ECH-IN-DNS"/>target="RFCYYY1"/> for specifics about how ECH configurations are advertised in SVCB and HTTPS records. Other delivery mechanisms are also possible. For example, the client may have the ECH configuration preconfigured.</t> <t>When a client wants to establish a TLS session with some backend server, it constructs a privateClientHello,<tt>ClientHello</tt>, referred to as theClientHelloInner.<tt>ClientHelloInner</tt>. The client then constructs a publicClientHello,<tt>ClientHello</tt>, referred to as theClientHelloOuter.<tt>ClientHelloOuter</tt>. TheClientHelloOuter<tt>ClientHelloOuter</tt> contains innocuous values for sensitive extensions and an "encrypted_client_hello" extension (<xref target="encrypted-client-hello"/>), which carries the encryptedClientHelloInner.<tt>ClientHelloInner</tt>. Finally, the client sendsClientHelloOuter<tt>ClientHelloOuter</tt> to the server.</t> <t>The server takes one of the following actions:</t> <ol spacing="normal" type="1"><li> <t>If it does not support ECH or cannot decrypt the extension, it completes the handshake withClientHelloOuter.<tt>ClientHelloOuter</tt>. This is referred to as rejecting ECH.</t> </li> <li> <t>If it successfully decrypts the extension, it forwards theClientHelloInner<tt>ClientHelloInner</tt> to the backend server, which completes the handshake. This is referred to as accepting ECH.</t> </li> </ol> <t>Upon receiving the server's response, the client determines whether or not ECH was accepted (<xref target="determining-ech-acceptance"/>) and proceeds with the handshake accordingly. When ECH is rejected, the resulting connection is not usable by the client for application data. Instead, ECH rejection allows the client to 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 the same anonymity set are indistinguishable from one another. Moreover, it should 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 goals.</t> </section> </section> <section anchor="ech-configuration"> <name>Encrypted ClientHello Configuration</name> <t>ECH usesHPKEHybrid Public Key Encryption (HPKE) for public key encryption <xreftarget="HPKE"/>.target="RFC9180"/>. The ECH configuration is defined by the following <tt>ECHConfig</tt> structure.</t> <artwork><![CDATA[ opaque HpkePublicKey<1..2^16-1>; uint16 HpkeKemId; // Defined inRFC9180RFC 9180 uint16 HpkeKdfId; // Defined inRFC9180RFC 9180 uint16 HpkeAeadId; // Defined inRFC9180RFC 9180 uint16 ECHConfigExtensionType; // Defined in Section 11.3 struct { HpkeKdfId kdf_id; HpkeAeadId aead_id; } HpkeSymmetricCipherSuite; struct { uint8 config_id; HpkeKemId kem_id; HpkePublicKey public_key; HpkeSymmetricCipherSuite cipher_suites<4..2^16-4>; } HpkeKeyConfig; struct { ECHConfigExtensionType type; opaque data<0..2^16-1>; } ECHConfigExtension; struct { HpkeKeyConfig key_config; uint8 maximum_name_length; opaque public_name<1..255>; ECHConfigExtension extensions<0..2^16-1>; } ECHConfigContents; struct { uint16 version; uint16 length; select (ECHConfig.version) { case 0xfe0d: ECHConfigContents contents; } } ECHConfig; ]]></artwork> <t>The structure contains the following fields:</t> <dl><dt>version</dt><dt>version:</dt> <dd> <t>The version of ECH for which this configuration is used. The version is the same as the code point for the "encrypted_client_hello" extension. Clients MUST ignore any <tt>ECHConfig</tt> structure with a version they do not support.</t> </dd><dt>length</dt><dt>length:</dt> <dd> <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 parse the specific version ofECHConfig.</t><tt>ECHConfig</tt>.</t> </dd><dt>contents</dt><dt>contents:</dt> <dd> <t>An opaque byte string whose contents depend on the version. For this specification, the contents are an <tt>ECHConfigContents</tt> structure.</t> </dd> </dl> <t>The <tt>ECHConfigContents</tt> structure contains the following fields:</t> <dl><dt>key_config</dt><dt>key_config:</dt> <dd> <t>A <tt>HpkeKeyConfig</tt> structure carrying the configuration information associated with the HPKE public key (an "ECH key"). Note that this structure contains the <tt>config_id</tt> field, which applies to the entireECHConfigContents.</t><tt>ECHConfigContents</tt>.</t> </dd><dt>maximum_name_length</dt><dt><tt>maximum_name_length</tt>:</dt> <dd> <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 does not 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> </dd><dt>public_name</dt><dt>public_name:</dt> <dd> <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, as described in <xref target="rejected-ech"/>.</t> </dd> <dt/> <dd> <t>See <xref target="auth-public-name"/> for how the client interprets and validates the public_name.</t> </dd><dt>extensions</dt><dt>extensions:</dt> <dd> <t>A list of ECHConfigExtension values that the client must take into consideration when generating aClientHello<tt>ClientHello</tt> message. Each ECHConfigExtension 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 order. ECHConfigExtension values are described below (<xref target="config-extensions"/>).</t> </dd> </dl> <t>The <tt>HpkeKeyConfig</tt> structure contains the following fields:</t> <dl><dt>config_id</dt><dt><tt>config_id</tt>:</dt> <dd> <t>A one-byte identifier for the given HPKE key configuration. This is used by clients to indicate the key used forClientHello<tt>ClientHello</tt> encryption. <xref target="config-ids"/> describes how client-facing servers allocate this value.</t> </dd><dt>kem_id</dt><dt>kem_id:</dt> <dd> <t>The HPKE Key Encapsulation Mechanism (KEM) identifier corresponding to <tt>public_key</tt>. Clients MUST ignore any <tt>ECHConfig</tt> structure with a key using a KEM they do not support.</t> </dd><dt>public_key</dt><dt><tt>public_key</tt>:</dt> <dd> <t>The HPKE public key used by the client to encryptClientHelloInner.</t><tt>ClientHelloInner</tt>.</t> </dd><dt>cipher_suites</dt><dt>cipher_suites:</dt> <dd> <t>The list of HPKEKDFKey Derivation Function (KDF) andAEADAuthenticated Encryption with Associated Data (AEAD) identifier pairs clients can use for encryptingClientHelloInner.<tt>ClientHelloInner</tt>. See <xref target="real-ech"/> for how clients choose from this list.</t> </dd> </dl> <t>The client-facing server advertises a sequence of ECH configurations to clients, serialized as follows.</t> <artwork><![CDATA[ ECHConfig ECHConfigList<4..2^16-1>; ]]></artwork> <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 versions of ECH and multiple sets of ECH parameters.</t> <section anchor="config-ids"> <name>Configuration Identifiers</name> <t>A client-facing server has a set of knownECHConfig values,<tt>ECHConfig</tt> values with corresponding 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 up to a TTL or longer.</t> <t><xref target="client-facing-server"/> describes a trial decryption process for decrypting theClientHello.<tt>ClientHello</tt>. This can impact performance when the client-facing server maintains many knownECHConfig<tt>ECHConfig</tt> values. To avoid this, the client-facing server SHOULD allocate distinct <tt>config_id</tt> values for eachECHConfig<tt>ECHConfig</tt> in its known set. The RECOMMENDED strategy is via rejection sampling, i.e., to randomly select <tt>config_id</tt> repeatedly until it does not match any knownECHConfig.</t><tt>ECHConfig</tt>.</t> <t>It is not necessary for <tt>config_id</tt> values across different client-facing servers to be distinct. A backend server may be hosted behind two different client-facing servers with colliding <tt>config_id</tt> values without any performance impact. Values may also be reused if the previousECHConfig<tt>ECHConfig</tt> is no longer in the known set.</t> </section> <section anchor="config-extensions"> <name>Configuration Extensions</name> <t>ECH configuration extensions are used to provide room for additional functionality as needed. The format is as defined in <xref target="ech-configuration"/> and mirrors <xref section="4.2" sectionFormat="of" target="RFC8446"/>. However, ECH configuration extension types are maintained by IANA as described in <xref target="config-extensions-iana"/>. ECH configuration extensions follow the same interpretation rules as TLS extensions: extensions MAY appear 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 can be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.</t> <t>Clients MUST parse the extension list and check for unsupported mandatory extensions. If an unsupported mandatory extension is present, clients MUST ignore the <tt>ECHConfig</tt>.</t> <t>Any future information or hints that influenceClientHelloOuter<tt>ClientHelloOuter</tt> SHOULD be specified asECHConfig<tt>ECHConfig</tt> extensions. This is primarily because the outerClientHello<tt>ClientHello</tt> exists only in support of ECH. Namely, it is both an envelope for the encrypted innerClientHello<tt>ClientHello</tt> and an enabler for authenticated key mismatch signals (see <xref target="server-behavior"/>). In contrast, the innerClientHello<tt>ClientHello</tt> is the trueClientHello<tt>ClientHello</tt> used upon ECH negotiation.</t> </section> </section> <section anchor="encrypted-client-hello"> <name>The "encrypted_client_hello" Extension</name> <t>To offer ECH, the client sends an "encrypted_client_hello" extension in theClientHelloOuter.<tt>ClientHelloOuter</tt>. When it does, it MUST also send the extension inClientHelloInner.</t> <artwork><![CDATA[<tt>ClientHelloInner</tt>.</t> <t>~~ enum { encrypted_client_hello(0xfe0d), (65535) } ExtensionType;]]></artwork>~~</t> <t>The payload of the extension has the following structure:</t> <artwork><![CDATA[ enum { outer(0), inner(1) } ECHClientHelloType; struct { ECHClientHelloType type; select (ECHClientHello.type) { case outer: HpkeSymmetricCipherSuite cipher_suite; uint8 config_id; opaque enc<0..2^16-1>; opaque payload<1..2^16-1>; case inner: Empty; }; } ECHClientHello; ]]></artwork> <t>The outer extension uses the <tt>outer</tt> variant and the inner extension uses the <tt>inner</tt> variant. The inner extension has an empty payload, which is included because TLS servers are not allowed to provide extensions in ServerHello which were not included inClientHello.<tt>ClientHello</tt>. The outer extension has the following fields:</t> <dl><dt>config_id</dt><dt><tt>config_id</tt>:</dt> <dd> <t>TheECHConfigContents.key_config.config_id<tt>ECHConfigContents.key_config.config_id</tt> for the chosenECHConfig.</t><tt>ECHConfig</tt>.</t> </dd><dt>cipher_suite</dt><dt><tt>cipher_suite</tt>:</dt> <dd> <t>The cipher suite used to encryptClientHelloInner.<tt>ClientHelloInner</tt>. This MUST match a value provided in the corresponding <tt>ECHConfigContents.cipher_suites</tt> list.</t> </dd><dt>enc</dt><dt>enc:</dt> <dd> <t>The HPKE encapsulatedkey,key used by servers to decrypt the corresponding <tt>payload</tt> field. This field is empty in aClientHelloOuter<tt>ClientHelloOuter</tt> sent in response to HelloRetryRequest.</t> </dd><dt>payload</dt><dt>payload:</dt> <dd> <t>The serialized and encryptedEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> structure, encrypted using HPKE as described in <xref target="real-ech"/>.</t> </dd> </dl> <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 EncryptedExtensions message, as described in <xref target="client-facing-server"/>, with the following payload:</t><artwork><![CDATA[<t>~~ struct { ECHConfigList retry_configs; } ECHEncryptedExtensions;]]></artwork>~~</t> <t>The response is valid only when the server used theClientHelloOuter.<tt>ClientHelloOuter</tt>. If the server sent this extension in response to the <tt>inner</tt> variant, then the client MUST abort with an "unsupported_extension" alert.</t> <dl><dt>retry_configs</dt><dt>retry_configs:</dt> <dd> <t>AnECHConfigList<tt>ECHConfigList</tt> structure containing one or moreECHConfig<tt>ECHConfig</tt> structures, 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 configurations".</t> </dd> </dl> <t>Finally, when the client offers the "encrypted_client_hello", if the payload is the <tt>inner</tt> variant and the server responds with HelloRetryRequest, it MUST include an "encrypted_client_hello" extension with the following payload:</t><artwork><![CDATA[<t>~~ struct { opaque confirmation[8]; } ECHHelloRetryRequest;]]></artwork>~~</t> <t>The value of ECHHelloRetryRequest.confirmation is set to <tt>hrr_accept_confirmation</tt> as described in <xref target="backend-server-hrr"/>.</t> <t>This document also defines the "ech_required" alert, which the client MUST send when it offered an "encrypted_client_hello" extension that was not accepted by the server. (See <xref target="alerts"/>.)</t> <section anchor="encoding-inner"> <name>Encoding the ClientHelloInner</name> <t>Before encrypting, the client pads and optionally compressesClientHelloInner<tt>ClientHelloInner</tt> intoa EncodedClientHelloInneran <tt>EncodedClientHelloInner</tt> structure, defined below:</t><artwork><![CDATA[<t>~~ struct { ClientHello client_hello; uint8 zeros[length_of_padding]; } EncodedClientHelloInner;]]></artwork>~~</t> <t>The <tt>client_hello</tt> field is computed by first making a copy ofClientHelloInner<tt>ClientHelloInner</tt> and setting the <tt>legacy_session_id</tt> field to the empty string. In TLS, this field uses theClientHello<tt>ClientHello</tt> structure defined in <xref section="4.1.2" sectionFormat="of" target="RFC8446"/>. In DTLS, it uses theClientHello structured<tt>ClientHello</tt> structure defined in <xref section="5.3" sectionFormat="of" target="RFC9147"/>. This does not include Handshake structure's four-byte header in TLS, nor twelve-byte header in DTLS. The <tt>zeros</tt> field MUST be all zeroes of length <tt>length_of_padding</tt> (see <xref target="padding"/>).</t> <t>Repeating large extensions, such as "key_share" with post-quantum algorithms, betweenClientHelloInner<tt>ClientHelloInner</tt> andClientHelloOuter<tt>ClientHelloOuter</tt> can lead to excessive size. To reduce the size impact, the client MAY substitute extensions which it knows will be duplicated inClientHelloOuter.<tt>ClientHelloOuter</tt>. It does so by removing and replacing extensions fromEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> with a single "ech_outer_extensions" extension, defined as follows:</t><artwork><![CDATA[<t>~~ enum { ech_outer_extensions(0xfd00), (65535) }ExtensionType;ExtensionType;</t> <artwork><![CDATA[ ExtensionType OuterExtensions<2..254>; ~~ ]]></artwork> <t>OuterExtensions contains the removed ExtensionType values. Each value references the matching extension inClientHelloOuter.<tt>ClientHelloOuter</tt>. The values MUST be ordered contiguously inClientHelloInner,<tt>ClientHelloInner</tt>, and the "ech_outer_extensions" extension MUST be inserted in the corresponding position inEncodedClientHelloInner.<tt>EncodedClientHelloInner</tt>. Additionally, the extensions MUST appear inClientHelloOuter<tt>ClientHelloOuter</tt> in the same relative order. However, there is no requirement that they be contiguous. For example, OuterExtensions may contain extensions A, B, and C, whileClientHelloOuter<tt>ClientHelloOuter</tt> contains extensions A, D, B, C, E, and F.</t> <t>The "ech_outer_extensions" extension can only be included inEncodedClientHelloInner,<tt>EncodedClientHelloInner</tt> and MUST NOT appear in eitherClientHelloOuter<tt>ClientHelloOuter</tt> orClientHelloInner.</t><tt>ClientHelloInner</tt>.</t> <t>Finally, the client pads the message by setting the <tt>zeros</tt> field to a byte string whose contents are all zeros and whose length is the amount of padding to add. <xref target="padding"/> describes a recommended padding scheme.</t> <t>The client-facing server computesClientHelloInner<tt>ClientHelloInner</tt> by reversing this process.FirstFirst, it parsesEncodedClientHelloInner,<tt>EncodedClientHelloInner</tt>, interpreting all bytes after <tt>client_hello</tt> as padding. If any padding byte is non-zero, the server MUST abort the connection with an "illegal_parameter" alert.</t><t>Next<t>Next, it makes a copy of the <tt>client_hello</tt> field and copies the <tt>legacy_session_id</tt> field fromClientHelloOuter.<tt>ClientHelloOuter</tt>. It then looks for an "ech_outer_extensions" extension. If found, it replaces the extension with the corresponding sequence of extensions in theClientHelloOuter.<tt>ClientHelloOuter</tt>. The server MUST abort the connection with an "illegal_parameter" alert if any of the following are true:</t> <ul spacing="normal"> <li> <t>Any referenced extension is missing inClientHelloOuter.</t><tt>ClientHelloOuter</tt>.</t> </li> <li> <t>Any extension is referenced in OuterExtensions more than once.</t> </li> <li> <t>"encrypted_client_hello" is referenced in OuterExtensions.</t> </li> <li> <t>The extensions inClientHelloOuter<tt>ClientHelloOuter</tt> corresponding to those in OuterExtensions do not occur in the same order.</t> </li> </ul> <t>These requirements prevent an attacker from performing a packet amplificationattack,attack by crafting aClientHelloOuter<tt>ClientHelloOuter</tt> which decompresses to a much largerClientHelloInner.<tt>ClientHelloInner</tt>. This is discussed further in <xref target="decompression-amp"/>.</t> <t>Implementations SHOULD construct theClientHelloInner<tt>ClientHelloInner</tt> in linear time. Quadratic time implementations (such as may happen via naive copying) create adenial of servicedenial-of-service risk. <xref target="linear-outer-extensions"/> describes a linear-time procedure that may be used for this purpose.</t> </section> <section anchor="authenticating-outer"> <name>Authenticating the ClientHelloOuter</name> <t>To prevent a network attacker from modifying the <tt>ClientHelloOuter</tt> while keeping the same encrypted <tt>ClientHelloInner</tt> (see <xref target="flow-clienthello-malleability"/>), ECH authenticatesClientHelloOuter<tt>ClientHelloOuter</tt> by passingClientHelloOuterAAD<tt>ClientHelloOuterAAD</tt> as the associated data for HPKE sealing and opening operations. TheClientHelloOuterAAD<tt>ClientHelloOuterAAD</tt> is a serializedClientHello<tt>ClientHello</tt> structure, defined in <xref section="4.1.2" sectionFormat="of" target="RFC8446"/> for TLS and <xref section="5.3" sectionFormat="of" target="RFC9147"/> for DTLS, which matches theClientHelloOuter<tt>ClientHelloOuter</tt> except 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 include Handshake structure's four-byte header in TLS nor twelve-byte header in DTLS.</t> </section> </section> <section anchor="client-behavior"> <name>Client Behavior</name> <t>Clients that implement the ECH extension behave in one of two ways: either they offer a real ECH extension, as described in <xreftarget="real-ech"/>;target="real-ech"/>, or they send a Generate Random Extensions And Sustain Extensibility (GREASE) <xref target="RFC8701"/> ECH extension, as described in <xref target="grease-ech"/>. Clients of the latter type do not 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 if it is in possession of a compatible ECH configuration and sends GREASE ECH (see <xref target="grease-ech"/>) otherwise.</t> <section anchor="real-ech"> <name>Offering ECH</name> <t>To offer ECH, the client first chooses a suitableECHConfig<tt>ECHConfig</tt> from the server'sECHConfigList.<tt>ECHConfigList</tt>. To determine if a given <tt>ECHConfig</tt> is suitable, it checks that it supports the KEM algorithm identified by <tt>ECHConfig.contents.kem_id</tt>, at least one KDF/AEAD algorithm identified by <tt>ECHConfig.contents.cipher_suites</tt>, and the version of ECH indicated by<tt>ECHConfig.contents.version</tt>.<tt>ECHConfig.version</tt>. Once a suitable configuration is found, the client selects the cipher suite it will use for encryption. It MUST NOT choose a cipher suite or version not advertised by the configuration. If no compatible configuration is found, then the client SHOULD proceed as described in <xref target="grease-ech"/>.</t> <t>Next, the client constructs theClientHelloInner<tt>ClientHelloInner</tt> message just as it does a standardClientHello,<tt>ClientHello</tt>, with the exception of the following rules:</t> <ol spacing="normal" type="1"><li> <t>It MUST NOT offer to negotiate TLS 1.2 or below. This is necessary to ensure the backend server does not negotiate a TLS version that is incompatible with ECH.</t> </li> <li> <t>It MUST NOT offer to resume any session for TLS 1.2 and below.</t> </li> <li> <t>If it intends to compress any extensions (see <xref target="encoding-inner"/>), it MUST order those extensions consecutively.</t> </li> <li> <t>It MUST include the "encrypted_client_hello" extension of type <tt>inner</tt> as described in <xref target="encrypted-client-hello"/>. (This requirement is not applicable when the "encrypted_client_hello" extension is generated as described in <xref target="grease-ech"/>.)</t> </li> </ol> <t>The client then constructsEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> as described in <xref target="encoding-inner"/>. It also computes an HPKE encryption context and <tt>enc</tt> value as:</t><artwork><![CDATA[<t>~~ pkR = DeserializePublicKey(ECHConfig.contents.public_key) enc, context = SetupBaseS(pkR, "tls ech" || 0x00 || ECHConfig)]]></artwork>~~</t> <t>Next, it constructs a partialClientHelloOuterAAD<tt>ClientHelloOuterAAD</tt> as it does a standardClientHello,<tt>ClientHello</tt>, with the exception of the following rules:</t> <ol spacing="normal" type="1"><li> <t>It MUST offer to negotiate TLS 1.3 or above.</t> </li> <li> <t>If it compressed any extensions inEncodedClientHelloInner,<tt>EncodedClientHelloInner</tt>, it MUST copy the corresponding extensions fromClientHelloInner.<tt>ClientHelloInner</tt>. The copied extensions additionally MUST be in the same relative order as inClientHelloInner.</t><tt>ClientHelloInner</tt>.</t> </li> <li> <t>It MUST copy the legacy_session_id field fromClientHelloInner.<tt>ClientHelloInner</tt>. This allows the server to echo the correct session ID for TLS 1.3's compatibility mode (see <xref section="D.4" sectionFormat="of" target="RFC8446"/>) when ECH is negotiated. Note that compatibility mode is not used in DTLS 1.3, but following this rule will produce the correct results for both TLS 1.3 and DTLS 1.3.</t> </li> <li> <t>It MAY copy any other field from theClientHelloInner<tt>ClientHelloInner</tt> exceptClientHelloInner.random.<tt>ClientHelloInner.random</tt>. Instead,Itit MUST generate a freshClientHelloOuter.random<tt>ClientHelloOuter.random</tt> using a secure random number generator. (See <xref target="flow-client-reaction"/>.)</t> </li> <li> <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 different value in the "server_name" extension, risk breaking the retry 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-server"/>.</t> </li> <li> <t>When the client offers the "pre_shared_key" extension inClientHelloInner,<tt>ClientHelloInner</tt>, it SHOULD also include a GREASE "pre_shared_key" extension inClientHelloOuter,<tt>ClientHelloOuter</tt>, generated in the manner described in <xref target="grease-psk"/>. The client MUST NOT use this extension to advertise a PSK to the client-facing server. (See <xref target="flow-clienthello-malleability"/>.) When the client includes a GREASE "pre_shared_key" extension, it MUST also copy the "psk_key_exchange_modes" from theClientHelloInner<tt>ClientHelloInner</tt> into theClientHelloOuter.</t><tt>ClientHelloOuter</tt>.</t> </li> <li> <t>When the client offers the "early_data" extension inClientHelloInner,<tt>ClientHelloInner</tt>, it MUST also include the "early_data" extension inClientHelloOuter.<tt>ClientHelloOuter</tt>. This allows servers that reject ECH and useClientHelloOuter<tt>ClientHelloOuter</tt> to safely ignore any early data sent by the client per <xref section="4.2.10" sectionFormat="comma" target="RFC8446"/>.</t> </li> </ol> <t>The client might duplicate non-sensitive extensions in both messages. However, implementations need to take care to ensure that sensitive extensions are not offered in theClientHelloOuter.<tt>ClientHelloOuter</tt>. See <xref target="outer-clienthello"/> for additional guidance.</t> <t>Finally, the client encrypts theEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> with the above values, as described in <xref target="encrypting-clienthello"/>, to construct aClientHelloOuter.<tt>ClientHelloOuter</tt>. It sends this to theserver,server and processes the response as described in <xref target="determining-ech-acceptance"/>.</t> <section anchor="encrypting-clienthello"> <name>Encrypting the ClientHello</name> <t>Given anEncodedClientHelloInner,<tt>EncodedClientHelloInner</tt>, an HPKE encryption context and <tt>enc</tt> value, and a partialClientHelloOuterAAD,<tt>ClientHelloOuterAAD</tt>, the client constructs aClientHelloOuter<tt>ClientHelloOuter</tt> as follows.</t> <t>First, the client determines the length L of encryptingEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> with the selected HPKE AEAD. This is typically the sum of the plaintext length and the AEAD tag length. The client then completes theClientHelloOuterAAD<tt>ClientHelloOuterAAD</tt> with an "encrypted_client_hello" extension. This extension value contains the outer variant ofECHClientHello<tt>ECHClientHello</tt> with the following fields:</t> <ul spacing="normal"> <li> <t><tt>config_id</tt>, the identifier corresponding to the chosenECHConfig<tt>ECHConfig</tt> structure;</t> </li> <li> <t><tt>cipher_suite</tt>, the client's chosen cipher suite;</t> </li> <li> <t><tt>enc</tt>, as given above; and</t> </li> <li> <t><tt>payload</tt>, a placeholder byte string containing L zeros.</t> </li> </ul> <t>If configuration identifiers (see <xref target="ignored-configs"/>) are to be ignored, <tt>config_id</tt> SHOULD be set to a randomly generated byte in the firstClientHelloOuter<tt>ClientHelloOuter</tt> and, in the event of a HelloRetryRequest (HRR), MUST be left unchanged for the secondClientHelloOuter.</t><tt>ClientHelloOuter</tt>.</t> <t>The client serializes this structure to construct theClientHelloOuterAAD.<tt>ClientHelloOuterAAD</tt>. It then computes the final payload as:</t><artwork><![CDATA[<t>~~ final_payload = context.Seal(ClientHelloOuterAAD, EncodedClientHelloInner)]]></artwork>~~</t> <t>Including <tt>ClientHelloOuterAAD</tt> as the HPKE AAD binds the <tt>ClientHelloOuter</tt> to the <tt>ClientHelloInner</tt>, thus preventing attackers from modifying <tt>ClientHelloOuter</tt> while keeping the same <tt>ClientHelloInner</tt>, as described in <xref target="flow-clienthello-malleability"/>.</t> <t>Finally, the client replaces <tt>payload</tt> with <tt>final_payload</tt> to obtainClientHelloOuter.<tt>ClientHelloOuter</tt>. The two values have the same length, so it is not necessary to recompute length prefixes in the serialized structure.</t> <t>Note this construction requires the "encrypted_client_hello" be computed after all other extensions. This is possible because theClientHelloOuter's<tt>ClientHelloOuter</tt>'s "pre_shared_key" extension is eitheromitted,omitted or uses a random binder (<xref target="grease-psk"/>).</t> </section> <section anchor="grease-psk"> <name>GREASE PSK</name> <t>When offering ECH, the client is not permitted to advertise PSK identities in theClientHelloOuter.<tt>ClientHelloOuter</tt>. However, the client can send a "pre_shared_key" extension in theClientHelloInner.<tt>ClientHelloInner</tt>. In this case, when resuming a session with the client, the backend server sends a "pre_shared_key" extension in its ServerHello. This would appear to a network observer as if the server were sending this extension without solicitation, which would violate the extension rules described in <xref target="RFC8446"/>. When offering a PSK inClientHelloInner,<tt>ClientHelloInner</tt>, clients SHOULD send a GREASE "pre_shared_key" extension in theClientHelloOuter<tt>ClientHelloOuter</tt> to make it appear to the network as if the extension were negotiated properly.</t> <t>The client generates the extension payload by constructing an <tt>OfferedPsks</tt> structure (see <xref section="4.2.11" sectionFormat="comma" target="RFC8446"/>) as follows. For each PSK identity advertised in theClientHelloInner,<tt>ClientHelloInner</tt>, the client generates a random PSK identity with the same length. It also generates a random, 32-bit, unsigned integer to use as the <tt>obfuscated_ticket_age</tt>. Likewise, for each inner PSK binder, the client generates a random string of the same length.</t> <t>Per the rules of <xref target="real-ech"/>, the server is not permitted to resume a 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 client MUST abort the handshake with an "illegal_parameter" alert.</t> </section> <section anchor="padding"> <name>Recommended Padding Scheme</name> <t>If theClientHelloInner<tt>ClientHelloInner</tt> is encrypted without padding, then the length of the <tt>ClientHelloOuter.payload</tt> can leak information about <tt>ClientHelloInner</tt>. In order to preventthisthis, the <tt>EncodedClientHelloInner</tt> structure has a padding field. This section describes a deterministic mechanism for computing the required amount of padding based on the following observation: individual extensions can reveal sensitive information through their length. Thus, each extension in the innerClientHello<tt>ClientHello</tt> may require different amounts of padding. This padding may be fully determined by the client's configuration or may require server input.</t> <t>By way of example, clients typically support a small number of application profiles. For instance, a browser might support HTTP with ALPN values ["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 extension across all application profiles. The target padding length of mostClientHello<tt>ClientHello</tt> extensions can be computed in this way.</t> <t>In contrast, clients do not know the longest SNI value in the client-facing server's anonymity set without server input. Clients SHOULD use theECHConfig's<tt>ECHConfig</tt>'s <tt>maximum_name_length</tt> field as follows, whereLM is the <tt>maximum_name_length</tt> value.</t> <ol spacing="normal" type="1"><li> <t>If theClientHelloInner<tt>ClientHelloInner</tt> contained a "server_name" extension with a name of length D, add max(0,LM - D) bytes of padding.</t> </li> <li> <t>If theClientHelloInner<tt>ClientHelloInner</tt> did not contain a "server_name" extension (e.g., if the client is connecting to an IP address), addLM + 9 bytes of padding. This is the length of a "server_name" extension with anL-byteM-byte name.</t> </li> </ol> <t>Finally, the client SHOULD pad the entire message as follows:</t> <ol spacing="normal" type="1"><li> <t>Let L be the length of theEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> with all the padding computed so far.</t> </li> <li> <t>Let N = 31 - ((L - 1) % 32) and add N bytes of padding.</t> </li> </ol> <t>This rounds the length ofEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> up to a multiple of 32 bytes, reducing the set of possible lengths across all clients.</t> <t>In addition to paddingClientHelloInner,<tt>ClientHelloInner</tt>, clients and servers will also need to pad all other handshake messages that have sensitive-length fields. For example, if a client proposes ALPN values inClientHelloInner,<tt>ClientHelloInner</tt>, the server-selected value will be returned in an EncryptedExtension, so that handshake message also needs to be padded using TLS record layer padding.</t> </section> <section anchor="determining-ech-acceptance"> <name>Determining ECH Acceptance</name> <t>As described in <xref target="server-behavior"/>, the server may either accept ECH and useClientHelloInner<tt>ClientHelloInner</tt> or reject it and useClientHelloOuter.<tt>ClientHelloOuter</tt>. This is determined by the server's initial message.</t> <t>If the message does not negotiate TLS 1.3 or higher, the server has rejected ECH. Otherwise, it is either a ServerHello or HelloRetryRequest.</t> <t>If the message is a ServerHello, the client computes <tt>accept_confirmation</tt> as described in <xref target="backend-server"/>. If this value matches the last 8 bytes of <tt>ServerHello.random</tt>, the server has accepted ECH. Otherwise, it has rejected ECH.</t> <t>If the message is a HelloRetryRequest, the client checks for the "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 with a "decode_error" alert. Otherwise, the client computes <tt>hrr_accept_confirmation</tt> as described in <xref target="backend-server-hrr"/>. If this value matches the extension payload, the server has accepted ECH. Otherwise, it has rejected ECH.</t> <t>If the server accepts ECH, the client handshakes withClientHelloInner<tt>ClientHelloInner</tt> as described in <xref target="accepted-ech"/>. Otherwise, the client handshakes withClientHelloOuter<tt>ClientHelloOuter</tt> as described in <xref target="rejected-ech"/>.</t> <!-- [rfced] In the following sentence, does "length other than 8" refer 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"> <name>Handshaking with ClientHelloInner</name> <t>If the server accepts ECH, the client proceeds with the connection as in <xref target="RFC8446"/>, with the following modifications:</t> <t>The client behaves as if it had sentClientHelloInner<tt>ClientHelloInner</tt> as theClientHello.<tt>ClientHello</tt>. That is, it evaluates the handshake using theClientHelloInner's<tt>ClientHelloInner</tt>'s preferences, and, when computing the transcript hash (<xref section="4.4.1" sectionFormat="of" target="RFC8446"/>), it usesClientHelloInner<tt>ClientHelloInner</tt> as the firstClientHello.</t><tt>ClientHello</tt>.</t> <t>If the server responds with a HelloRetryRequest, the client computes the updatedClientHello<tt>ClientHello</tt> message as follows:</t> <ol spacing="normal" type="1"><li> <t>It computes a secondClientHelloInner<tt>ClientHelloInner</tt> based on the firstClientHelloInner,<tt>ClientHelloInner</tt>, as in <xref section="4.1.4" sectionFormat="of" target="RFC8446"/>. TheClientHelloInner's<tt>ClientHelloInner</tt>'s "encrypted_client_hello" extension is left unmodified.</t> </li> <li> <t>It constructsEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> as described in <xref target="encoding-inner"/>.</t> </li> <li> <t>It constructs a second partialClientHelloOuterAAD<tt>ClientHelloOuterAAD</tt> message. This message MUST be syntactically valid. The extensions MAY be copied from the originalClientHelloOuter unmodified,<tt>ClientHelloOuter</tt> unmodified or omitted. If not sensitive, the client MAY copy updated extensions from the secondClientHelloInner<tt>ClientHelloInner</tt> for compression.</t> </li> <li> <t>It encryptsEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> as described in <xref target="encrypting-clienthello"/>, using the second partialClientHelloOuterAAD,<tt>ClientHelloOuterAAD</tt>, to obtain a secondClientHelloOuter.<tt>ClientHelloOuter</tt>. It reuses the original HPKE encryption context computed in <xref target="real-ech"/> and uses the empty string for <tt>enc</tt>. </t> <t> The HPKE context maintains a sequence number, so this operation internally uses a fresh nonce for each AEAD operation. Reusing the HPKE context avoids an attack described in <xref target="flow-hrr-hijack"/>.</t> </li> </ol> <t>The client then sends the secondClientHelloOuter<tt>ClientHelloOuter</tt> to the server. However, as above, it uses the secondClientHelloInner<tt>ClientHelloInner</tt> for preferences, and both theClientHelloInner<tt>ClientHelloInner</tt> messages for the transcript hash. Additionally, it checks the resulting ServerHello for ECH acceptance as in <xref target="determining-ech-acceptance"/>. If the ServerHello does not also indicate ECH acceptance, the client MUST terminate the connection with an "illegal_parameter" alert.</t> </section> <section anchor="rejected-ech"> <name>Handshaking with ClientHelloOuter</name> <t>If the server rejects ECH, the client proceeds with the handshake, authenticating forECHConfig.contents.public_name<tt>ECHConfig.contents.public_name</tt> as described in <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 configurations. It MUST NOT treat this as a secure signal to disable ECH.</t> <t>If the server supplied an "encrypted_client_hello" extension in its EncryptedExtensions message, the client MUST check that it is syntactically 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 the False Start optimization <xref target="RFC7918"/> for this handshake. If both authentication and the handshake complete successfully, the client MUST perform the processing described below and then abort the connection with an "ech_required" alert before sending any application data to the server.</t> <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 regard the ECH configuration as securely replaced by the server. It SHOULD retry the handshake with a new transportconnection,connection using the retry configurations supplied by the server.</t> <t>Clients can implement a new transport connection in a way that best suits their deployment. For example, clients can reuse the same server IP address when establishing the new transport connection or they can choose to use a different IP address if provided with options from DNS. ECH does not mandate any specific implementation choices when establishing this new connection.</t> <t>The retry configurations are meant to be used for retried connections. Further use of retry configurations could yield a tracking vector. In settings where the client will otherwise already let the server track the client, e.g., because the client will send cookies to the server in parallel connections, using the retry configurations for these parallel connections does not introduce a new tracking vector.</t> <t>If none of the values provided in "retry_configs" contains a supported version, the server did not supply an "encrypted_client_hello" extension in its EncryptedExtensions message, or an earlier TLS version was negotiated, the client can regard ECH as securely disabled by the server, and it SHOULD retry the handshake with a new transport connection and ECH disabled.</t> <t>Clients SHOULD NOT accept "retry_config" in response to a connection initiated in response to a "retry_config". Sending a "retry_config" in this situation is a signal that the server is misconfigured, e.g., the server might have multiple inconsistent configurations so that the client reached a node with configuration A in the first connection and 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 has securely disabled ECH.</t> <t>If a client does not retry, it MUST report an error to the calling application.</t> </section> <section anchor="auth-public-name"> <name>Authenticating for the Public Name</name> <t>When the server rejects ECH, it continues with the handshake using the plaintext "server_name" extension instead (see <xref target="server-behavior"/>). Clients that offer ECH then authenticate the connection with the publicname,name as follows:</t> <ul spacing="normal"> <li> <t>The client MUST verify that the certificate is valid forECHConfig.contents.public_name.<tt>ECHConfig.contents.public_name</tt>. If invalid, it MUST abort the connection with the appropriate alert.</t> </li> <li> <t>If the server requests a client certificate, the client MUST respond with an empty Certificate message, denoting no client certificate.</t> </li> </ul> <t>In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity <xreftarget="RFC6125"/>.target="RFC9525"/>. Clients that incorporate DNS names and IP addresses into the same syntax (e.g. <xref section="7.4" sectionFormat="of" target="RFC3986"/> and <xref target="WHATWG-IPV4"/>) MUST reject names that would be interpreted as IPv4 addresses. Clients that enforce this by checkingECHConfig.contents.public_name<tt>ECHConfig.contents.public_name</tt> 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 it for the origin. The TLS implementation MUST NOT report such connections as successful to the application. It additionally MUST ignore all session tickets 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 implemented, for 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>. Clients SHOULD ignore any <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-TERMS"/>).target="RFC9499"/>). That is, to be 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> <ul spacing="normal"> <li> <t>the sequence does not begin or end with an ASCII dot, and</t> </li> <li> <t>all labels are at most 63 octets.</t> </li> </ul> <t>Clients additionally SHOULD ignore the structure if the final LDH label either consists of all ASCII digits(i.e.(i.e., '0' through '9') or is "0x" or "0X" followed by some, possibly empty, sequence of ASCII hexadecimal digits(i.e.(i.e., '0' through '9', 'a' through 'f', and 'A' through 'F'). This avoids public_name values that may be interpreted as IPv4 literals.</t> </section> <section anchor="impact-of-retry-on-future-connections"> <name>Impact of Retry on Future Connections</name> <t>Clients MAY use information learned from a rejected ECH for future connections to avoid repeatedly connecting to the same server and being forced to retry. However, they MUST handle ECH rejection for those connections as if it were a fresh connection, rather than enforcing the single retry limit from <xref target="rejected-ech"/>. The reason for this requirement is that if the server sends a "retry_config" and then immediately rejects the resulting connection, it is most likely misconfigured. However, if the server sends a "retry_config" and then the client tries to use that to connect some time later, it is possible that the server has changed its configuration again and is now trying to recover.</t> <t>Any persisted information MUST be associated with theECHConfig<tt>ECHConfig</tt> source used to bootstrap the connection, such as a DNS SVCB ServiceMode record <xreftarget="ECH-IN-DNS"/>.target="RFCYYY1"/>. Clients MUST limit any sharing of persisted ECH-related state to connections that use the sameECHConfig<tt>ECHConfig</tt> source. Otherwise, it might become possible for the client to have the wrong public name for the server, making recovery impossible.</t> <t>ECHConfigs learned from ECH rejection can be used as a tracking vector. Clients SHOULD impose the same lifetime and scope restrictions that they apply to other server-based tracking vectors such as PSKs.</t> <t>In general, the safest way for clients to minimize ECH retries is to comply with any freshness rules (e.g., DNS TTLs) imposed by the ECH configuration.</t> </section> </section> <section anchor="grease-ech"> <name>GREASE ECH</name> <t>The GREASE ECH mechanism allows a connection betweenandan ECH-capable client 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> <section anchor="client-greasing"> <name>Client Greasing</name> <t>If the client attempts to connect to a server and does not have anECHConfig<tt>ECHConfig</tt> structure available for the server, it SHOULD send a GREASE <xref target="RFC8701"/> "encrypted_client_hello" extension in the firstClientHello<tt>ClientHello</tt> as follows:</t> <ul spacing="normal"> <li> <t>Set the <tt>config_id</tt> field to a random byte.</t> </li> <li> <t>Set the <tt>cipher_suite</tt> field to a supported HpkeSymmetricCipherSuite. The selection SHOULD vary to exercise all supported configurations, but MAY be held constant for successive connections to the same server in the same session.</t> </li> <li> <t>Set the <tt>enc</tt> field to arandomly-generatedrandomly generated valid encapsulated public key output by the HPKE KEM.</t> </li> <li> <t>Set the <tt>payload</tt> field to arandomly-generatedrandomly generated string of L+C bytes, where C is the ciphertext expansion of the selected AEAD scheme and L is the size of theEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> the client would compute when offering ECH, padded according to <xref target="padding"/>.</t> </li> </ul> <t>If sending a secondClientHello<tt>ClientHello</tt> in response to a HelloRetryRequest, the client copies the entire "encrypted_client_hello" extension from the firstClientHello.<tt>ClientHello</tt>. The identical value will reveal to an observer that the value of "encrypted_client_hello" was fake, but this only occurs if there is a HelloRetryRequest.</t> <t>If the server sends an "encrypted_client_hello" extension in either HelloRetryRequest or EncryptedExtensions, the client MUST check the extension syntactically and abort the connection with a "decode_error" alert if it is invalid. It otherwise ignores the extension. It MUST NOT save the "retry_configs" value in EncryptedExtensions.</t> <t>Offering a GREASE extension is not considered offering an encryptedClientHello<tt>ClientHello</tt> for purposes of requirements in <xref target="real-ech"/>. In particular, the client MAY offer to resume sessions established without ECH.</t> <!-- [rfced] It seems that "client" was intended to be "clients" (plural) 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"> <name>Server Greasing</name> <t><xref target="config-extensions-iana"/> describes a set of Reserved extensions which will never be registered. These can be used by servers to "grease" the contents of the ECH configuration, as inspired by <xref target="RFC8701"/>. This helps ensure clients process ECH extensions correctly. When constructing ECH configurations, servers SHOULD randomly select from reserved values with the high-order bit clear.Correctly-implemented clientCorrectly implemented clients will ignore those extensions.</t> <t>The reserved values with the high-order bit set are mandatory, as defined in <xref target="config-extensions"/>. Servers SHOULD randomly select from these values and include them in extraneous ECH configurations.Correctly-implementedCorrectly implemented clients will ignore these configurations because they do not recognize the mandatory extension. Servers SHOULD ensure that any client using these configurations encounters a warning or error message. This can be accomplished in several ways, including:</t> <ul spacing="normal"> <li> <t>By giving the extraneous configurations distinctive config IDs or public names, and rejecting the TLS connection or inserting an application-level warning message when these are observed.</t> </li> <li> <t>By giving the extraneous configurations an invalid public key and a public name not associated with theserver,server so that the initialClientHelloOuter<tt>ClientHelloOuter</tt> will not be decryptable and the server cannot perform the recovery flow described in <xref target="rejected-ech"/>.</t> </li> </ul> </section> </section> </section> <section anchor="server-behavior"> <name>Server Behavior</name> <t>As described in <xref target="topologies"/>, servers can play two roles, either as the client-facing server or as theback-endbackend server. Depending on the server role, the <tt>ECHClientHello</tt> will be different:</t> <ul spacing="normal"> <li> <t>A client-facing server expectsaan <tt>ECHClientHello.type</tt> of <tt>outer</tt>, and proceeds as described in <xref target="client-facing-server"/> to extract aClientHelloInner,<tt>ClientHelloInner</tt>, if available.</t> </li> <li> <t>A backend server expectsaan <tt>ECHClientHello.type</tt> of <tt>inner</tt>, and proceeds as described in <xref target="backend-server"/>.</t> </li> </ul> <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 "illegal_parameter" alert. Similarly, in split mode, a backend server which receives a <tt>ClientHello</tt> with <tt>ECHClientHello.type</tt> of <tt>outer</tt> MUST abort with an "illegal_parameter" alert.</t> <t>In shared mode, a server plays both roles, first decrypting the <tt>ClientHelloOuter</tt> and then using the contents of the <tt>ClientHelloInner</tt>. A shared mode server which receives a <tt>ClientHello</tt> with <tt>ECHClientHello.type</tt> of <tt>inner</tt> MUST abort with an "illegal_parameter" alert, because such a <tt>ClientHello</tt> should never be received directly from the network.</t> <t>If <tt>ECHClientHello.type</tt> is not a valid <tt>ECHClientHelloType</tt>, then the server MUST abort with an "illegal_parameter" alert.</t> <t>If the "encrypted_client_hello" is not present, then the server completes the handshake normally, as described in <xref target="RFC8446"/>.</t> <section anchor="client-facing-server"> <name>Client-Facing Server</name> <t>Upon receiving an "encrypted_client_hello" extension in an initialClientHello,<tt>ClientHello</tt>, the client-facing server determines if it will acceptECH,ECH prior to negotiating any other TLS parameters. Note that successfully decrypting the extension will result in a newClientHello<tt>ClientHello</tt> to process, so even the client's TLS version preferences may have changed.</t> <t>First, the server collects a set of candidateECHConfig<tt>ECHConfig</tt> values. This list is determined by one of the two following methods:</t> <ol spacing="normal" type="1"><li> <t>CompareECHClientHello.config_id<tt>ECHClientHello.config_id</tt> against identifiers of each knownECHConfig<tt>ECHConfig</tt> and select the ones that match, if any, as candidates.</t> </li> <li> <t>Collect all knownECHConfig<tt>ECHConfig</tt> values as candidates, with trial decryption below determining the final selection.</t> </li> </ol> <t>Some uses of ECH, such as local discovery mode, may randomize theECHClientHello.config_id<tt>ECHClientHello.config_id</tt> since it can be used as a tracking vector. In such cases, the second method SHOULD be used for matching theECHClientHello<tt>ECHClientHello</tt> to a knownECHConfig.<tt>ECHConfig</tt>. See <xref target="ignored-configs"/>. Unless specified by the application profile or otherwise externally configured, implementations MUST use the first method.</t> <t>The server then iterates over the candidateECHConfig<tt>ECHConfig</tt> values, attempting to decrypt the "encrypted_client_hello" extension as follows.</t> <t>The server verifies that theECHConfig<tt>ECHConfig</tt> supports the cipher suite indicated by theECHClientHello.cipher_suite<tt>ECHClientHello.cipher_suite</tt> and that the version of ECH indicated by the client matches theECHConfig.version.<tt>ECHConfig.version</tt>. If not, the server continues to the next candidateECHConfig.</t><tt>ECHConfig</tt>.</t> <t>Next, the server decryptsECHClientHello.payload,<tt>ECHClientHello.payload</tt>, using the private key skR corresponding toECHConfig,<tt>ECHConfig</tt>, as follows:</t><artwork><![CDATA[<t>~~ context = SetupBaseR(ECHClientHello.enc, skR, "tls ech" || 0x00 || ECHConfig) EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, ECHClientHello.payload)]]></artwork> <t>ClientHelloOuterAAD~~</t> <t><tt>ClientHelloOuterAAD</tt> is computed fromClientHelloOuter<tt>ClientHelloOuter</tt> as described in <xref target="authenticating-outer"/>. The <tt>info</tt> parameter to SetupBaseR is the concatenation "tls ech", a zero byte, and the serializedECHConfig.<tt>ECHConfig</tt>. If decryption fails, the server continues to the next candidateECHConfig.<tt>ECHConfig</tt>. Otherwise, the server reconstructsClientHelloInner<tt>ClientHelloInner</tt> fromEncodedClientHelloInner,<tt>EncodedClientHelloInner</tt>, as described in <xref target="encoding-inner"/>. It then stops iterating over the candidateECHConfig<tt>ECHConfig</tt> values.</t> <t>Once the server has chosen the correctECHConfig,<tt>ECHConfig</tt>, it MAY verify that the value in theClientHelloOuter<tt>ClientHelloOuter</tt> "server_name" extension matches the value ofECHConfig.contents.public_name,<tt>ECHConfig.contents.public_name</tt> and abort with an "illegal_parameter" alert if 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. The server MUST be careful not to unnecessarily reject connections if the sameECHConfig<tt>ECHConfig</tt> id or keypair is used in multiple ECHConfigs with distinct public names.</t> <t>Upon determining theClientHelloInner,<tt>ClientHelloInner</tt>, the client-facing server checks that the message includes a well-formed "encrypted_client_hello" extension of type <tt>inner</tt> and that it does not offer TLS 1.2 or below. If either of these checks fails, the client-facing server MUST abort with an "illegal_parameter" alert.</t> <t>If these checks succeed, the client-facing server then forwards theClientHelloInner<tt>ClientHelloInner</tt> to the appropriate backend server, which proceeds as in <xref target="backend-server"/>. If the backend server responds with a HelloRetryRequest, the client-facing server forwards it, decrypts the client's secondClientHelloOuter<tt>ClientHelloOuter</tt> using the procedure in <xref target="client-facing-server-hrr"/>, and forwards the resulting secondClientHelloInner.<tt>ClientHelloInner</tt>. The client-facing server forwards all other TLS messages between the client and backend server unmodified.</t> <t>Otherwise, if all candidateECHConfig<tt>ECHConfig</tt> values fail to decrypt the extension, the client-facing server MUST ignore the extension and proceed with the connection usingClientHelloOuter,<tt>ClientHelloOuter</tt> with the following modifications:</t> <ul spacing="normal"> <li> <t>If sending a HelloRetryRequest, the server MAY include an "encrypted_client_hello" extension with a payload of 8 random bytes; see <xref target="dont-stick-out"/> for details.</t> </li> <li> <t>If the server is configured with any ECHConfigs, it MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or moreECHConfig<tt>ECHConfig</tt> structures with up-to-date keys. Servers MAY supply multipleECHConfig<tt>ECHConfig</tt> values of different versions. This allows a server to support multiple versions at once.</t> </li> </ul> <t>Note that decryption failure could indicate a GREASE ECH extension (see <xref target="grease-ech"/>), so it is necessary for servers to proceed with the connection and rely on the client to abort if ECH was required. In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (<xref target="misconfiguration"/>). Instead, servers can measure occurrences of the "ech_required" alert to detect this case.</t> <section anchor="client-facing-server-hrr"> <name>Sending HelloRetryRequest</name> <t>After sending or forwarding a HelloRetryRequest, the client-facing server does not repeat the steps in <xref target="client-facing-server"/> with the secondClientHelloOuter.<tt>ClientHelloOuter</tt>. Instead, it continues with theECHConfig<tt>ECHConfig</tt> selection from the firstClientHelloOuter<tt>ClientHelloOuter</tt> as follows:</t> <t>If the client-facing server accepted ECH, it checks that the secondClientHelloOuter<tt>ClientHelloOuter</tt> also contains the "encrypted_client_hello" extension. If not, it MUST abort the handshake with a "missing_extension" alert. Otherwise, it checks thatECHClientHello.cipher_suite<tt>ECHClientHello.cipher_suite</tt> andECHClientHello.config_id<tt>ECHClientHello.config_id</tt> are unchanged, and thatECHClientHello.enc<tt>ECHClientHello.enc</tt> is empty. If not, it MUST abort the handshake with an "illegal_parameter" alert.</t> <t>Finally, it decrypts the newECHClientHello.payload<tt>ECHClientHello.payload</tt> as a second message with the previous HPKE context:</t><artwork><![CDATA[<t>~~ EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, ECHClientHello.payload)]]></artwork> <t>ClientHelloOuterAAD~~</t> <t><tt>ClientHelloOuterAAD</tt> is computed as described in <xref target="authenticating-outer"/>, but using the secondClientHelloOuter.<tt>ClientHelloOuter</tt>. If decryption fails, the client-facing server MUST abort the handshake with a "decrypt_error" alert. Otherwise, it reconstructs the secondClientHelloInner<tt>ClientHelloInner</tt> from the newEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> as described in <xref target="encoding-inner"/>, using the secondClientHelloOuter<tt>ClientHelloOuter</tt> for any referenced extensions.</t> <t>The client-facing server then forwards the resultingClientHelloInner<tt>ClientHelloInner</tt> to the backend server. It forwards all subsequent TLS messages between the client and backend server unmodified.</t> <t>If the client-facing server rejected ECH, or if the firstClientHello<tt>ClientHello</tt> did not include an "encrypted_client_hello" extension, the client-facing server proceeds with the connection as usual. The server does not decrypt the secondClientHello's ECHClientHello.payload<tt>ClientHello</tt>'s <tt>ECHClientHello.payload</tt> value, if there is one. Moreover, if the server is configured with any ECHConfigs, it MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or moreECHConfig<tt>ECHConfig</tt> structures with up-to-date keys, as described in <xref target="client-facing-server"/>.</t> <t>Note that a client-facing server that forwards the firstClientHello<tt>ClientHello</tt> cannot include its own "cookie" extension if the backend server sends a 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 server to include any information it requires to process the secondClientHello.</t><tt>ClientHello</tt>.</t> <!-- [rfced] May we rephrase the following text for an improved sentence 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 anchor="backend-server"> <name>Backend Server</name> <t>Upon receipt of an "encrypted_client_hello" extension of type <tt>inner</tt> in aClientHello,<tt>ClientHello</tt>, if the backend server negotiates TLS 1.3 or higher, then it MUST confirm ECH acceptance to the client by computing its ServerHello as described here.</t> <t>The backend server embeds inServerHello.random<tt>ServerHello.random</tt> a string derived from the inner handshake. It begins by computing its ServerHello as usual, except the last 8 bytes ofServerHello.random<tt>ServerHello.random</tt> are set to zero. It then computes the transcript hash forClientHelloInner<tt>ClientHelloInner</tt> up to and including the modified ServerHello, as described in <xref section="4.4.1" sectionFormat="comma" target="RFC8446"/>. Let transcript_ech_conf denote the output. Finally, the backend server overwrites the last 8 bytes of theServerHello.random<tt>ServerHello.random</tt> with the following string:</t><artwork><![CDATA[<t>~~ accept_confirmation = HKDF-Expand-Label( HKDF-Extract(0, ClientHelloInner.random), "ech accept confirmation", transcript_ech_conf, 8)]]></artwork>~~</t> <t>where HKDF-Expand-Label is defined in <xref section="7.1" sectionFormat="comma" target="RFC8446"/>, "0" indicates a string of Hash.length bytes set to zero, and Hash is the hash function used to compute the transcript hash. In DTLS, the modified version of HKDF-Expand-Label defined in <xref section="5.9" sectionFormat="comma" target="RFC9147"/> is used instead.</t> <t>The backend server MUST NOT perform this operation if it negotiated TLS 1.2 or below. Note that doing so would overwrite the downgrade signal for TLS 1.3 (see <xref section="4.1.3" sectionFormat="comma" target="RFC8446"/>).</t> <section anchor="backend-server-hrr"> <name>Sending HelloRetryRequest</name> <t>When the backend server sends HelloRetryRequest in response to theClientHello,<tt>ClientHello</tt>, it similarly confirms ECH acceptance by adding a confirmation signal to its HelloRetryRequest. But instead of embedding the signal in the HelloRetryRequest.random (the value of which is specified by <xref target="RFC8446"/>), it sends the signal in an extension.</t> <t>The backend server begins by computing HelloRetryRequest as usual, except that it also contains an "encrypted_client_hello" extension with a payload of 8 zero bytes. It then computes the transcript hash for the firstClientHelloInner,<tt>ClientHelloInner</tt>, denoted ClientHelloInner1, up to and including the modified HelloRetryRequest. Let transcript_hrr_ech_conf denote the output. Finally, the backend server overwrites the payload of the "encrypted_client_hello" extension with the following string:</t><artwork><![CDATA[<t>~~ hrr_accept_confirmation = HKDF-Expand-Label( HKDF-Extract(0, ClientHelloInner1.random), "hrr ech accept confirmation", transcript_hrr_ech_conf, 8)]]></artwork>~~</t> <t>In the subsequent ServerHello message, the backend server sends theaccept_confirmation<tt>accept_confirmation</tt> value as described in <xref target="backend-server"/>.</t> </section> </section> </section> <section anchor="deployment"> <name>Deployment Considerations</name> <t>The design of ECH as specified in this document necessarily requires changes to client, client-facing server, and backend server. Coordination between client-facing and backend server requires care, as deployment mistakes can lead to compatibility issues. These are discussed in <xref target="compat-issues"/>.</t> <t>Beyond coordination difficulties, ECH deployments may also induce challenges for use cases of information that ECH protects. In particular, use cases which depend on this unencrypted information may no longer work as desired. This is elaborated upon in <xref target="no-sni"/>.</t> <section anchor="compat-issues"> <name>Compatibility Issues</name> <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 plaintext extension.ThusThus, server operators SHOULD ensure servers understand a given set of ECH keys before advertising them. Additionally, servers SHOULD retain support for anypreviously-advertisedpreviously advertised keys for the duration of their validity.</t> <t>However, in more complex deployment scenarios, this may be difficult to fully guarantee.ThusThus, this protocol was designed to be robust in case of 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> <section anchor="misconfiguration"> <name>Misconfiguration and Deployment Concerns</name> <t>It is possible for ECH advertisements and servers to become inconsistent. This 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 loses its ECH keys, or if a deployment of ECH must be rolled back on the server.</t> <t>The retry mechanism repairs inconsistencies, provided the TLS server has a certificate for the public name. If server and advertised keys mismatch, the server will reject ECH and respond with "retry_configs". If the server does not understand the "encrypted_client_hello" extension at all, it will ignore it as required by <xref section="4.1.2" sectionFormat="of" target="RFC8446"/>. Provided the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described in <xref target="rejected-ech"/>.</t> <t>Unless ECH is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to using unencrypted ClientHellos, as this allows a network attacker to disclose the contents of thisClientHello,<tt>ClientHello</tt>, including the SNI. It MAY attempt to use another server from the DNS results, if one is provided.</t> <t>In order to ensure that the retry mechanism workssuccessfullysuccessfully, servers SHOULD ensure that every endpoint which might receive a TLS connection is provisioned with an appropriate certificate for the public name. This is especially important during periods of server reconfiguration when different endpoints might have different configurations.</t> </section> <section anchor="middleboxes"> <name>Middleboxes</name> <!--[rfced] How may we update this sentence to make it clear whether 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 with TLS-terminating proxies even in cases where the server supports ECH but the proxy does not, as detailed below.</t> <t>The proxy must ignore unknownparameters,parameters and generate its ownClientHello<tt>ClientHello</tt> containing only parameters it understands. Thus, when presenting a certificate to the client or sending aClientHello<tt>ClientHello</tt> to the server, the proxy will act as if connecting to theClientHelloOuter<tt>ClientHelloOuter</tt> server_name, which SHOULD match the public name (see <xreftarget="real-ech"/>),target="real-ech"/>) without echoing the "encrypted_client_hello" extension.</t> <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 in <xref target="rejected-ech"/> or result in a connection failure. A proxy which is not authoritative for the public name cannot forge a signal to disable ECH.</t> </section> </section> <section anchor="no-sni"> <name>Deployment Impact</name> <t>Some use cases which depend on information ECH encrypts may break with the deployment of ECH. The extent of breakage depends on a number of external factors, including, for example, whether ECH can be disabled, whether or not the party disabling ECH is trusted to do so, and whether or not client implementations will fall back to TLS without ECH in the event of disablement.</t> <t>Depending on implementation details and deployment settings, use cases which depend on plaintext TLS information may require fundamentally different approaches to continue working. For example, in managed enterprise settings, one approach may be to disable ECH entirely via group policy and for client implementations to honor this action. Server deployments which depend on SNI -- e.g., for load balancing -- may no longer function properly without updates; the nature of those updates is out of scope of this specification.</t> <t>In the context of <xref target="rejected-ech"/>, another approach may be to intercept and decrypt client TLS connections. The feasibility of alternative solutions is specific to individual deployments.</t> </section> </section> <section anchor="compliance"> <name>Compliance Requirements</name> <t>In the absence of an application profile standard specifying otherwise, a compliant ECH application MUST implement the following HPKE cipher suite:</t> <ul spacing="normal"> <li> <t>KEM: DHKEM(X25519, HKDF-SHA256) (see <xref section="7.1" sectionFormat="of"target="HPKE"/>)</t>target="RFC9180"/>)</t> </li> <li> <t>KDF: HKDF-SHA256 (see <xref section="7.2" sectionFormat="of"target="HPKE"/>)</t>target="RFC9180"/>)</t> </li> <li> <t>AEAD: AES-128-GCM (see <xref section="7.3" sectionFormat="of"target="HPKE"/>)</t>target="RFC9180"/>)</t> </li> </ul> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This section contains security considerations for ECH.</t> <section anchor="goals"> <name>Security and Privacy Goals</name> <t>ECH considers two types of attackers: passive and active. Passive attackers can read packets from the network, but they cannot perform any sort of active behavior such as probing servers or querying DNS. A middlebox that filters based on plaintext packet contents is one example of a passive attacker. In contrast, active attackers can also write packets into the network for malicious purposes, such as interfering with existing connections, probing servers, and querying DNS. In short, an active attacker corresponds to the conventional threat model <xref target="RFC3552"/> for TLS 1.3 <xref target="RFC8446"/>.</t> <t>Passive and active attackers can exist anywhere in the network, including between the client and client-facing server, as well as between the client-facing and backend servers when running ECH inSplit Mode.split mode. However, forSplit Modesplit mode in particular, ECH makes two additional assumptions:</t> <ol spacing="normal" type="1"><li> <t>The channel between each client-facing and each backend server is authenticated such that the backend server only accepts messages from trusted client-facing servers. The exact mechanism for establishing this authenticated channel is out of scope for this document.</t> </li> <li> <t>The attacker cannot correlate messages between a client and client-facing 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 their server name or IP address, with a client's encryptedClientHelloInner.<tt>ClientHelloInner</tt>. Correlation could occur through timing analysis of messages across the client-facing server, or via examining the contents of messages sent between client-facing and backend servers. The exact mechanism for preventing this sort of correlation is out of scope for this document.</t> </li> </ol> <t>Given this threat model, the primary goals of ECH are as follows.</t> <ol spacing="normal" type="1"><li> <t>Security preservation. Use of ECH does not weaken the security properties of TLS without ECH.</t> </li> <li> <t>Handshake privacy. TLS connection establishment to a server name within an anonymity set is indistinguishable from a connection to any other server name within the anonymity set. (The anonymity set is defined in <xref target="intro"/>.)</t> </li> <li> <t>Downgrade resistance. An attacker cannot downgrade a connection that attempts to use ECH to one that does not use ECH.</t> </li> </ol> <t>These properties were formally proven in <xref target="ECH-Analysis"/>.</t> <t>With regards to handshake privacy, client-facing server configuration determines the size of the anonymity set. For example, if a client-facing server uses distinctECHConfig<tt>ECHConfig</tt> values for each server 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 anonymity set where possible. This means client-facing servers should use the sameECHConfig<tt>ECHConfig</tt> for as many server names as possible. An attacker can distinguish two server names that have differentECHConfig<tt>ECHConfig</tt> values based on theECHClientHello.config_id<tt>ECHClientHello</tt>.<tt>config_id</tt> value.</t> <t>This also means public information in a TLS handshake should be consistent across server names. For example, if a client-facing server 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 contents of the unencrypted handshake message. Similarly, if a backend origin reuses KeyShare values, then that provides a unique identifier for that server.</t> <t>Beyond these primary security and privacy goals, ECH also aims to hide, to some extent, the fact that it is being used at all. Specifically, the GREASE ECH 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 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"/> for details.</t> </section> <section anchor="plaintext-dns"> <name>Unauthenticated and Plaintext DNS</name> <t>ECH supports delivery of configurations through the DNS using SVCB or HTTPSrecords,records without requiring any verifiable authenticity or provenance information <xreftarget="ECH-IN-DNS"/>.target="RFCYYY1"/>. This means that any attacker which can inject DNS responses or poison DNS caches, which is a common scenario in client access networks, can supply clients with fake ECH configurations (so 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, no encryption scheme can work because the attacker can replace the IP address, thus blocking client connections, or substitute a unique IP address for each DNS name that was looked up. Thus, using DNS records without additional authentication does not make the situation significantly worse.</t> <t>Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but encrypted DNS transport is also a defense against DNS attacks by attackers on the local network, which is a common case whereClientHello<tt>ClientHello</tt> and SNI encryption are desired. Moreover, as noted in the introduction, SNI encryption is less useful without encryption of DNS queries in transit.</t> </section> <section anchor="client-tracking"> <name>Client Tracking</name> <t>A malicious client-facing server could distribute unique, per-clientECHConfig<tt>ECHConfig</tt> structures as a way of tracking clients across subsequent connections. On-path adversaries which know about these unique keys could also track clients in this way by observing TLS connection attempts.</t> <t>The cost of this type of attack scales linearly with the desired number of target clients. Moreover, DNS caching behavior makes targeting individual users for extended periods of time, e.g., using per-clientECHConfig<tt>ECHConfig</tt> structures delivered via HTTPS RRs with high TTLs, challenging. Clients can help mitigate this problem by flushing any DNS orECHConfig<tt>ECHConfig</tt> state upon changing networks (this may not be possible if clients use the operating system resolver rather than doing their own resolution).</t><t>ECHConfig<t><tt>ECHConfig</tt> rotation rate is also an issue for non-malicious servers, which may want to rotate keys frequently to limit exposure if the key is compromised. Rotating too frequently limits the client anonymity set. In practice, servers which service many server names and thus have high loads are the best candidates to be client-facing servers and so anonymity sets will typically involve many connections even with fairly fast rotation intervals.</t> </section> <section anchor="ignored-configs"> <name>Ignored Configuration Identifiers and Trial Decryption</name> <t>Ignoring configuration identifiers may be useful in scenarios where clients and client-facing servers do not want to reveal information about the client-facing server in the "encrypted_client_hello" extension. In such settings, clients send a randomly generatedconfig_id<tt>config_id</tt> in theECHClientHello.<tt>ECHClientHello</tt>. Servers in these settings must perform trial decryption since they cannot identify the client's chosen ECH key using theconfig_id<tt>config_id</tt> value. As a result, ignoring configuration identifiers may exacerbate DoS attacks. Specifically, an adversary may send maliciousClientHello<tt>ClientHello</tt> messages, i.e., those which will not decrypt with any known ECH key, in order to force wasteful decryption. Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the potential damage caused by such attacks.</t> <t>Unless specified by the application using (D)TLS or externally configured, implementations MUST NOT use this mode.</t> </section> <section anchor="outer-clienthello"> <name>Outer ClientHello</name> <t>Any information that the client includes in theClientHelloOuter<tt>ClientHelloOuter</tt> is visible to passive observers. The client SHOULD NOT send values in theClientHelloOuter<tt>ClientHelloOuter</tt> which would reveal a sensitiveClientHelloInner<tt>ClientHelloInner</tt> property, such as the true server name. It MAY send values associated with the public name in theClientHelloOuter.</t><tt>ClientHelloOuter</tt>.</t> <t>In particular, some extensions require the client send a server-name-specific value in theClientHello.<tt>ClientHello</tt>. These values may reveal information about the true server name. For example, the "cached_info"ClientHello<tt>ClientHello</tt> extension <xref target="RFC7924"/> can contain the hash of a previously observed server certificate. The client SHOULD NOT send values associated with the true server name in theClientHelloOuter.<tt>ClientHelloOuter</tt>. It MAY send such values in theClientHelloInner.</t><tt>ClientHelloInner</tt>.</t> <t>A client may also use different preferences in different contexts. For example, it may send different ALPN lists to different servers or in different application contexts. A client that treats this context as sensitive SHOULD NOT send context-specific values inClientHelloOuter.</t><tt>ClientHelloOuter</tt>.</t> <t>Values which are independent of the true server name, or other information the client wishes to protect, MAY be included inClientHelloOuter.<tt>ClientHelloOuter</tt>. If they match the correspondingClientHelloInner,<tt>ClientHelloInner</tt>, they MAY be compressed as described in <xref target="encoding-inner"/>. However, note that the payload length reveals information about which extensions are compressed, so inner extensions which only sometimes match the corresponding outer extension SHOULD NOT be compressed.</t> <t>Clients MAY include additional extensions inClientHelloOuter<tt>ClientHelloOuter</tt> to avoid signaling unusual behavior to passive observers, provided the choice of value and value itself are not sensitive. See <xref target="dont-stick-out"/>.</t> </section> <section anchor="inner-clienthello"> <name>Inner ClientHello</name> <t>Values which depend on the contents ofClientHelloInner,<tt>ClientHelloInner</tt>, such as the true server name, can influence how client-facing servers process this message. In particular, timing side channels can reveal information about the contents ofClientHelloInner.<tt>ClientHelloInner</tt>. Implementations should take such side channels into consideration when reasoning about the privacy properties that ECH provides.</t> </section> <section anchor="related-privacy-leaks"> <name>Related Privacy Leaks</name> <t>ECH requires encrypted DNS to be an effective privacy protection mechanism. However, verifying the server's identity from the Certificate message, particularly when using the X509 CertificateType, may result in additional network traffic that may reveal the server identity. Examples of this traffic may include requests for revocation information, such asOCSPOnline Certificate Status Protocol (OCSP) orCRLCertificate Revocation List (CRL) traffic, or requests for repository information, such as authorityInformationAccess. It may also include implementation-specific traffic for additional information sources as part of verification.</t> <t>Implementations SHOULD avoid leaking information that may identify the server. 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 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 SHOULD take steps to minimize or protect such requests during certificate validation.</t> <t>Attacks that rely on non-ECH traffic to infer server identity in an ECH connection are out of scope for this document. For example, a client that connects to a particular host prior to ECH deployment may later resume a connection to that same host after ECH deployment. An adversary that observes this can deduce that the ECH-enabled connection was made to a host that the client previously connected to and which is within the same anonymity set.</t> </section> <section anchor="cookies"> <name>Cookies</name> <t><xref section="4.2.2" sectionFormat="of" target="RFC8446"/> defines a cookie value that servers may send in HelloRetryRequest for clients to echo in the secondClientHello.<tt>ClientHello</tt>. While ECH encrypts the cookie in the secondClientHelloInner,<tt>ClientHelloInner</tt>, the backend server's HelloRetryRequest isunencrypted.Thisunencrypted. This means differences in cookies between backend servers, such as lengths or cleartext components, may leak information about the server identity.</t> <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 statefully, thus not sending cookies, or by using the same cookie construction for all backend servers.</t> <t>Note that, if the cookie includes a key name, analogous to <xref section="4" sectionFormat="of" target="RFC5077"/>, this may leak information if different backend servers issue cookies with different key names at the time of the connection. In particular, if the deployment operates inSplit Mode,split mode, the backend servers may not share cookie encryption keys. Backend servers may mitigate thisbyeither by handling key rotation with trialdecryption,decryption or by coordinating to match key names.</t> </section> <section anchor="attacks-exploiting-acceptance-confirmation"> <name>Attacks Exploiting Acceptance Confirmation</name> <t>To signal acceptance, the backend server overwrites 8 bytes of itsServerHello.random<tt>ServerHello.random</tt> with a value derived from theClientHelloInner.random.<tt>ClientHelloInner.random</tt>. (See <xref target="backend-server"/> for details.) This behavior increases the likelihood of theServerHello.random<tt>ServerHello.random</tt> colliding with theServerHello.random<tt>ServerHello.random</tt> of a previous session, potentially reducing the overall security of the protocol. However, the remaining 24 bytes provide enough entropy to ensure this is not a practical avenue of attack.</t> <t>On the other hand, the probability that two 8-byte strings are the same is non-negligible. This poses a modest operational risk. Suppose the client-facing server terminates the connection (i.e., ECH is rejected or bypassed): if the last 8 bytes of itsServerHello.random<tt>ServerHello.random</tt> coincide with the confirmation signal, then the client will incorrectly presume acceptance and proceed as if the backend server terminated the connection. However, the probability of a false positive occurring for a given connection is only 1 in 2^64. This value is smaller than the probability of network connection failures in practice.</t> <t>Note that the same bytes of theServerHello.random<tt>ServerHello.random</tt> are used to implement downgrade protection for TLS 1.3 (see <xref section="4.1.3" sectionFormat="comma" target="RFC8446"/>). These mechanisms do not interfere because the backend server only signals ECH acceptance in TLS 1.3 or higher.</t> </section> <section anchor="comparison-against-criteria"> <name>Comparison Against Criteria</name> <t><xref target="RFC8744"/> lists several requirements for SNI encryption. In this section, were-iteratereiterate these requirements and assess the ECH design against them.</t> <section anchor="mitigate-cut-and-paste-attacks"> <name>Mitigate Cut-and-Paste Attacks</name> <t>Since servers process eitherClientHelloInner<tt>ClientHelloInner</tt> orClientHelloOuter,<tt>ClientHelloOuter</tt>, and becauseClientHelloInner.random<tt>ClientHelloInner</tt>.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 fromClientHelloInner.</t><tt>ClientHelloInner</tt>.</t> </section> <section anchor="avoid-widely-shared-secrets"> <name>Avoid Widely Shared Secrets</name> <t>This design depends upon DNS as a vehicle for semi-static public key distribution. Server operators may partition their private keys however they see fit provided each server behind an IP address has the corresponding private key to decrypt a key. Thus, when one ECH key is provided, sharing is optimally bound by the number of hosts that share an IP address. Server operators may further limit sharing of private keys by publishing different DNS records containingECHConfig<tt>ECHConfig</tt> values with different public keys using a short TTL.</t> </section> <section anchor="sni-based-denial-of-service-attacks"> <name>SNI-Based Denial-of-Service Attacks</name> <t>This design requires servers to decryptClientHello<tt>ClientHello</tt> messages withECHClientHello<tt>ECHClientHello</tt> extensions carrying valid digests. Thus, it is possible for an attacker to force decryption operations on the server. This attack is bound by the number of valid transport connections an attacker can open.</t> </section> <section anchor="dont-stick-out"> <name>Do Not Stick Out</name> <t>As a means of reducing the impact of network ossification, <xref target="RFC8744"/> recommends SNI-protection mechanisms be designed in such a way that network operators do not differentiate connections using the mechanism from connections not using the mechanism. To that end, ECH is designed to resemble a standard TLS handshake as much as possible. The most obvious difference is the extension itself: as long as middleboxes ignore it, as required by <xref target="RFC8446"/>, the rest of the handshake is designed to look very much as usual.</t> <t>The GREASE ECH protocol described in <xref target="grease-ech"/> provides a low-risk way to evaluate the deployability of ECH. It is designed to mimic the real ECH protocol (<xref target="real-ech"/>) without changing the security properties of the handshake. The underlying theory is that if GREASE ECH is deployable without triggering middlebox misbehavior, and real ECH looks enough like GREASE ECH, then ECH should be deployable as well. Thus, the strategy for mitigating network ossification is to deploy GREASE ECH widely enough to disincentivize differential treatment of the real ECH protocol by the network.</t> <t>Ensuring that networks do not differentiate between real ECH and GREASE ECH may 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 GREASE ECH. This specification aims to provide a baseline security level that most deployments can achieveeasily,easily while providing implementations enough flexibility to achieve stronger security where possible. Minimally, real ECH is designed to be indifferentiable from GREASE ECH for passive adversaries with following capabilities:</t> <ol spacing="normal" type="1"><li> <t>The attacker does not know theECHConfigList<tt>ECHConfigList</tt> used by the server.</t> </li> <li> <t>The attacker keeps per-connection state only. In particular, it does not track endpoints across connections.</t> </li> </ol> <t>Moreover, real ECH and GREASE ECH are designed so that the following features do not noticeably vary to the attacker, i.e., they are not distinguishers:</t> <ol spacing="normal" type="1"><li> <t>the code points of extensions negotiated in the clear, and their order;</t> </li> <li> <t>the length of messages; and</t> </li> <li> <t>the values of plaintext alert messages.</t> </li> </ol> <t>This leaves a variety of practical differentiators out-of-scope. including, though not limited to, the following:</t> <ol spacing="normal" type="1"><li> <t>the value of the configuration identifier;</t> </li> <li> <t>the value of the outer SNI;</t> </li> <li> <t>the TLS version negotiated, which may depend on ECH acceptance;</t> </li> <li> <t>client authentication, which may depend on ECH acceptance; and</t> </li> <li> <t>HRR issuance, which may depend on ECH acceptance.</t> </li> </ol> <t>These can be addressed with more sophisticated implementations, but some mitigations require coordination between the client and server, and even across different client and server implementations. These mitigations are out-of-scope for this specification.</t> </section> <section anchor="maintain-forward-secrecy"> <name>Maintain Forward Secrecy</name> <t>This design does not provide forward secrecy for the innerClientHello<tt>ClientHello</tt> because the server's ECH key is static. However, the window of exposure is bound by the key lifetime. It is RECOMMENDED that servers rotate keys regularly.</t> </section> <section anchor="enable-multi-party-security-contexts"> <name>Enable Multi-party Security Contexts</name> <t>This design permits servers operating inSplit Modesplit mode to forward connections directly to backend origin servers. The client authenticates the identity of the backend origin server, thereby allowing the backend origin server to hide behind the client-facing server without the client-facing server decrypting and reencrypting the connection.</t> <t>Conversely, if the DNS records used for configuration are authenticated, e.g., via DNSSEC, spoofing a client-facing server operating inSplit Modesplit mode is not possible. See <xref target="plaintext-dns"/> for more details regarding plaintext DNS.</t> <t>Authenticating theECHConfig<tt>ECHConfig</tt> structure naturally authenticates the included public name. This also authenticates any retry signals from the client-facing server because the client validates the server certificate against the public name before retrying.</t> </section> <section anchor="support-multiple-protocols"> <name>Support Multiple Protocols</name> <t>This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification. Thus, it is compatible with multiple application and transport protocols. By encrypting the entireClientHello,<tt>ClientHello</tt>, this design additionally supports encrypting the ALPN extension.</t> </section> </section> <section anchor="padding-policy"> <name>Padding Policy</name> <t>Variations in the length of theClientHelloInner<tt>ClientHelloInner</tt> ciphertext could leak information about the corresponding plaintext. <xref target="padding"/> describes a RECOMMENDED padding mechanism for clients aimed at reducing potential information leakage.</t> </section> <section anchor="active-attack-mitigations"> <name>Active Attack Mitigations</name> <t>This section describes the rationale for ECH properties and mechanics as defenses against active attacks. In all the attacks below, the attacker is on-path between the target client and server. The goal of the attacker is to learn private information about the innerClientHello,<tt>ClientHello</tt>, such as the true SNI value.</t> <section anchor="flow-client-reaction"> <name>Client Reaction Attack Mitigation</name> <t>This attack uses the client's reaction to an incorrect certificate as an oracle. The attacker intercepts a legitimateClientHello<tt>ClientHello</tt> and replies with a ServerHello, Certificate, CertificateVerify, and Finished messages, wherein the Certificate message contains a "test" certificate for the domain name it wishes to query. If the client decrypted the Certificate and failed verification (or leaked information about its verification process by a timing side channel), the attacker learns that its test certificate name was incorrect. As an example, suppose the client's SNI value in its innerClientHello<tt>ClientHello</tt> is "example.com," and 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 the Certificate signature validation, information about the name leaks. Note that the attacker can also withhold the CertificateVerify message. In that scenario, a client which first verifies the Certificate would then respond similarly and leak the same information.</t><figure anchor="flow-diagram-client-reaction"> <name>Client reaction attack</name> <artwork><![CDATA[<t>~~ Client Attacker Server ClientHello + key_share + ech------>------> (intercept)----->-----> X(drop)(drop)</t> <figure anchor="flow-diagram-client-reaction"> <name>Client Reaction Attack</name> <artwork><![CDATA[ ServerHello + key_share {EncryptedExtensions} {CertificateRequest*} {Certificate*} {CertificateVerify*} <------ Alert ------> ~~ ]]></artwork> </figure><t>ClientHelloInner.random<t><tt>ClientHelloInner.random</tt> prevents this attack. In particular, since the attacker does not have access to this value, it cannot produce the right transcript and handshake keys needed for encrypting the Certificate message. Thus, the client will fail to decrypt the Certificate and abort the connection.</t> </section> <section anchor="flow-hrr-hijack"> <name>HelloRetryRequest Hijack Mitigation</name> <t>This attack aims to exploit server HRR state management to recover information about a legitimateClientHello<tt>ClientHello</tt> using its own attacker-controlledClientHello.<tt>ClientHello</tt>. To begin, the attacker intercepts and forwards a legitimateClientHello<tt>ClientHello</tt> with an "encrypted_client_hello" (ech) extension to the server, which triggers a legitimate HelloRetryRequest in return. Rather than forward the retry to the client, the attacker attempts to generate its ownClientHello<tt>ClientHello</tt> in response based on the contents of the firstClientHello<tt>ClientHello</tt> and HelloRetryRequest exchange with the result that the server encrypts the Certificate to the attacker. If the server used the SNI from the firstClientHello<tt>ClientHello</tt> and the key share from the second (attacker-controlled)ClientHello,<tt>ClientHello</tt>, the Certificate produced would leak the client's chosen SNI to the attacker.</t><figure anchor="flow-diagram-hrr-hijack"> <name>HelloRetryRequest hijack attack</name> <artwork><![CDATA[<t>~~ Client Attacker Server ClientHello + key_share + ech------>------> (forward)------->-------> HelloRetryRequest + key_share (intercept)<-------<-------</t> <figure anchor="flow-diagram-hrr-hijack"> <name>HelloRetryRequest Hijack Attack</name> <artwork><![CDATA[ ClientHello + key_share' + ech' -------> ServerHello + key_share {EncryptedExtensions} {CertificateRequest*} {Certificate*} {CertificateVerify*} {Finished} <------- (process server flight) ~~ ]]></artwork> </figure> <t>This attack is mitigated by using the same HPKE context for bothClientHello<tt>ClientHello</tt> messages. The attacker does not possess the context's keys, so it cannot generate a valid encryption of the second innerClientHello.</t><tt>ClientHello</tt>.</t> <t>If the attacker could manipulate the secondClientHello,<tt>ClientHello</tt>, it might be possible for the server to act as an oracle if it required parameters from the firstClientHello<tt>ClientHello</tt> to match that of the secondClientHello.<tt>ClientHello</tt>. For example, imagine the client's original SNI value in the innerClientHello<tt>ClientHello</tt> is "example.com", and the attacker's hijacked SNI value in its innerClientHello<tt>ClientHello</tt> is "test.com". A server which checks these for equality and changes behavior based on the result can be used as an oracle to learn the client's SNI.</t> </section> <section anchor="flow-clienthello-malleability"> <name>ClientHello Malleability Mitigation</name> <t>This attack aims to leak information about secret parts of the encryptedClientHello<tt>ClientHello</tt> by adding attacker-controlled parameters and observing the server's response. In particular, the compression mechanism described in <xref target="encoding-inner"/> references parts of a potentially attacker-controlledClientHelloOuter<tt>ClientHelloOuter</tt> to constructClientHelloInner,<tt>ClientHelloInner</tt>, or a buggy server may incorrectly apply parameters fromClientHelloOuter<tt>ClientHelloOuter</tt> to the handshake.</t> <t>To begin, the attacker first interacts with a server to obtain a resumption ticket for a given test domain, such as "example.com". Later, upon receipt of aClientHelloOuter,<tt>ClientHelloOuter</tt>, it modifies it such that the server will process the resumption ticket withClientHelloInner.<tt>ClientHelloInner</tt>. If the server only accepts resumption PSKs that match the server name, it will fail the PSK binder check with an alert whenClientHelloInner<tt>ClientHelloInner</tt> is for "example.com" but silently ignore the PSK and continue whenClientHelloInner<tt>ClientHelloInner</tt> is for any other name. This introduces an oracle for testing encrypted SNI values.</t> <t>~~ Client Attacker Server</t> <figure anchor="tls-clienthello-malleability"> <name>MessageflowFlow formalleableMalleable ClientHello</name> <artwork><![CDATA[Client Attacker Serverhandshake and ticket for "example.com" <--------> ClientHello + key_share + ech + ech_outer_extensions(pre_shared_key) + pre_shared_key --------> (intercept) ClientHello + key_share + ech + ech_outer_extensions(pre_shared_key) + pre_shared_key' --------> Alert -or- ServerHello ... Finished <-------- ~~ ]]></artwork> </figure> <t>This attack may be generalized to any parameter which the server varies by server name, such as ALPN preferences.</t> <t>ECH mitigates this attack by only negotiating TLS parameters fromClientHelloInner<tt>ClientHelloInner</tt> and authenticating all inputs to theClientHelloInner (EncodedClientHelloInner<tt>ClientHelloInner</tt> (<tt>EncodedClientHelloInner</tt> andClientHelloOuter)<tt>ClientHelloOuter</tt>) with the HPKE AEAD. See <xref target="authenticating-outer"/>. The decompression process in <xref target="encoding-inner"/> forbids "encrypted_client_hello" in OuterExtensions. This ensures the unauthenticated portion ofClientHelloOuter<tt>ClientHelloOuter</tt> is not incorporated intoClientHelloInner.<tt>ClientHelloInner</tt>. An earlier iteration of this specification only encrypted and authenticated the "server_name" extension, which left the overallClientHello<tt>ClientHello</tt> vulnerable to an analogue of this attack.</t> </section> <section anchor="decompression-amp"> <name>ClientHelloInner Packet Amplification Mitigation</name> <t>Client-facing servers must decompress EncodedClientHelloInners. A malicious attacker may craft a packet which takes excessive resources to decompress or may be much larger than the incoming packet:</t> <ul spacing="normal"> <li> <t>If looking up aClientHelloOuter<tt>ClientHelloOuter</tt> extension takes time linear in the number of extensions, the overall decoding process would take O(M*N) time, where M is the number of extensions inClientHelloOuter<tt>ClientHelloOuter</tt> and N is the size of OuterExtensions.</t> </li> <li> <t>If the sameClientHelloOuter<tt>ClientHelloOuter</tt> extension can be copied multiple times, an attacker could cause the client-facing server to construct a largeClientHelloInner<tt>ClientHelloInner</tt> by including a large extension inClientHelloOuter,<tt>ClientHelloOuter</tt> of lengthL,L and an OuterExtensions list referencing N copies of that extension. The client-facing server would then use O(N*L) memory in response to O(N+L) bandwidth from the client. Insplit-mode,split mode, anO(N*L) sizedO(N*L)-sized packet would then be transmitted to the backend server.</t> </li> </ul> <t>ECH mitigates this attack by requiring that OuterExtensions be referenced in order, that duplicate references be rejected, and by recommending that client-facing servers use a linear scan to perform decompression. These requirements are detailed in <xref target="encoding-inner"/>.</t> </section> </section> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <section anchor="update-of-the-tls-extensiontype-registry"> <name>Update of the TLS ExtensionType Registry</name> <t>IANAis requested to createhas created the following entries in the existingregistry for"TLS ExtensionType Values" registry (defined in <xref target="RFC8446"/>):</t> <ol spacing="normal" type="1"><li><t>encrypted_client_hello(0xfe0d),<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 to"Yes".</t>"Y".</t> </li> <li><t>ech_outer_extensions(0xfd00),<t>ech_outer_extensions (0xfd00), with the "TLS 1.3" column values set to "CH", "DTLS-Only" column set to "N", "Recommended" column set to"Yes","Y", and the "Comment" column set to "Only appears in inner CH."</t> </li> </ol> </section> <section anchor="alerts"> <name>Update of the TLS Alert Registry</name> <t>IANAis requested to createhas created an entry,ech_required(121)ech_required (121) in the existing "TLS Alerts" registryfor Alerts(defined in <xref target="RFC8446"/>), with the "DTLS-OK" column set to "Y".</t> </section> <section anchor="config-extensions-iana"> <name>ECH Configuration Extension Registry</name> <t>IANAis requested to createhas created a new"ECHConfig"TLS ECHConfig Extension" registry in a new "TLS Encrypted Client Hello (ECH) Configuration Extensions"page.registry group. New registrationsneed towill list the following attributes:</t> <dl spacing="compact"> <dt>Value:</dt> <dd> <t>The two-byte identifier for the ECHConfigExtension, i.e., the ECHConfigExtensionType</t> </dd> <dt>Extension Name:</dt> <dd> <t>Name of the ECHConfigExtension</t> </dd> <dt>Recommended:</dt> <dd> <t>A "Y" or "N" value indicating if theextension isTLSWGWorking Group recommends that the extension be supported. This column is assigned a value of "N" unless explicitly requested. Adding a valuewith a valueof "Y" requires Standards Action <xref target="RFC8126"/>.</t> </dd> <dt>Reference:</dt> <dd> <t>The specification where the ECHConfigExtension is defined</t> </dd> <dt>Notes:</dt> <dd> <t>Any notes associated with the entry</t> </dd> </dl> <t>New entries in the"ECHConfig"TLS ECHConfig Extension" registry are subject to the Specification Required registration policy (<xref section="4.6" sectionFormat="comma" target="RFC8126"/>), with the policies described in <xref section="17" sectionFormat="comma" target="RFC8447"/>. IANA[shall add/has added]has added the following note to theTLS"TLS ECHConfigExtensionExtension" registry:</t> <t>Note: The role of the designated expert is described in RFC 8447. The designated expert <xref target="RFC8126"/> ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide morein depthin-depth reviews, but their approval should not be taken as an endorsement of the extension.</t> <t>This document defines several Reserved values for ECH configuration extensions to be used for "greasing" as described in <xref target="server-greasing"/>.</t> <t>The initial contents for this registry consists of multiple reservedvalues,values with the following attributes, which are repeated for each registration:</t> <dl spacing="compact"> <dt>Value:</dt> <dd> <t>0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, 0xFAFA</t> </dd> <dt>Extension Name:</dt> <dd> <t>RESERVED</t> </dd> <dt>Recommended:</dt> <dd> <t>Y</t> </dd> <dt>Reference:</dt> <dd><t>This document</t><t>RFC 9849</t> </dd> <dt>Notes:</dt> <dd><t>Grease entries.</t><t>GREASE entries</t> </dd> </dl> </section> </section> </middle> <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"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7918.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9180.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9525.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8447.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <referenceanchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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 protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. 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</title> <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 Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</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 Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, 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 exception 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</title> <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 protocol 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 "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They 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 privacy.</t> </abstract> </front> <seriesInfo name="RFC" value="9460"/> <seriesInfo name="DOI" value="10.17487/RFC9460"/> </reference> <reference anchor="ECH-IN-DNS">anchor="RFCYYY1" target="https://www.rfc-editor.org/info/rfcYYY1"> <front> <title>Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings</title> <author initials="B." surname="Schwartz" fullname="Benjamin M.Schwartz" initials="B. M." surname="Schwartz"> <organization>Meta Platforms, Inc.</organization>Schwartz"> <organization/> </author> <authorfullname="Mike Bishop"initials="M."surname="Bishop"> <organization>Akamai Technologies</organization>surname="Bishop" fullname="Mike Bishop"> <organization/> </author> <authorfullname="Erik Nygren"initials="E."surname="Nygren"> <organization>Akamai Technologies</organization>surname="Nygren" fullname="Erik Nygren"> <organization/> </author> <dateday="12" month="February" year="2025"/> <abstract> <t> To use TLS Encrypted ClientHello (ECH) the client needs to learn 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 encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated 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 derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key 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 Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates 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 between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services 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): Definitions 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 the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document 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 constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations 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 describing the conditions under which new values should be assigned, as well as when 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 Considerations 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 5226.</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 IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.</t> <t>This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.</t> </abstract>year="2025" month="December"/> </front> <seriesInfo name="RFC"value="8447"/>value="YYY1"/> <seriesInfo name="DOI"value="10.17487/RFC8447"/>value="10.17487/RFCYYY1"/> </reference></references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="WHATWG-IPV4" target="https://url.spec.whatwg.org/#concept-ipv4-parser"> <front> <title>URLLiving Standard- IPv4 Parser</title> <author><organization/><organization>WHATWG</organization> </author> <date year="2021" month="May"/> </front> <refcontent>WHATWG Living Standard</refcontent> </reference> <reference anchor="ECH-Analysis" target="https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf"> <front> <title>A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello</title><author> <organization/> </author> <date year="2022" month="November"/> </front> </reference> <reference anchor="RFC7301"> <front> <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title> <author fullname="S. Friedl" initials="S." surname="Friedl"/> <author fullname="A. Popov" initials="A." surname="Popov"/> <author fullname="A. Langley" initials="A." surname="Langley"/> <author fullname="E. Stephan" initials="E." surname="Stephan"/> <date month="July" year="2014"/> <abstract> <t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t> </abstract> </front> <seriesInfo name="RFC" value="7301"/> <seriesInfo name="DOI" value="10.17487/RFC7301"/> </reference> <reference anchor="RFC8484"> <front> <title>DNS Queries over HTTPS (DoH)</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <author fullname="P. McManus" initials="P." surname="McManus"/> <date month="October" year="2018"/> <abstract> <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP 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)</title> <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 (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities 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 profiles for DNS over TLS and provides advice on performance considerations to minimize 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 applications 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 the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.</t> <t>This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism 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 confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking 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) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, 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 ensure 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"/><authorfullname="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 characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; 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 protocols, 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 clarifications. 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</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>surname="Bhargavan"> <organization>Inria</organization> </author> <authorfullname="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 Community, 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>initials="V." surname="Cheval"> <organization>Inria</organization> </author> <authorfullname="C. Huitema"initials="C."surname="Huitema"/>surname="Wood"> <organization>Cloudflare</organization> </author> <datemonth="July" year="2020"/> <abstract> <t>This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents requirements for future TLS-layer solutions.</t> <t>In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises.</t> </abstract>year="2022" month="November"/> </front> <seriesInfoname="RFC" value="8744"/> <seriesInfoname="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 certification authorities (CAs). This information can be of considerable size, particularly 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 servervalue="10.1145/3548606.3559360"/> <refcontent>CCS '22: Proceedings ofcached information, thereby enablingtheserver to omit already 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 Server-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 session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained 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 extensions2022 ACM SIGSAC Conference on Computer anda DNS Resource Record 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"/>Communications Security, pp. 365-379</refcontent> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.kazuho-protected-sni.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8701.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8744.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7924.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml"/> </references> </references> <?line2017?>2144?> <section anchor="linear-outer-extensions"><name>Linear-time<name>Linear-Time Outer Extension Processing</name> <t>The following procedure processes the "ech_outer_extensions" extension (see <xref target="encoding-inner"/>) in linear time, ensuring that each referenced extension in theClientHelloOuter<tt>ClientHelloOuter</tt> is included at most once:</t> <ol spacing="normal" type="1"><li> <t>Let I be initialized to zero and N be set to the number of extensions inClientHelloOuter.</t><tt>ClientHelloOuter</tt>.</t> </li> <li> <t>For each extension type, E, in OuterExtensions: </t> <ul spacing="normal"> <li> <t>If E is "encrypted_client_hello", abort the connection with an "illegal_parameter" alert and terminate this procedure.</t> </li> <li> <t>While I is less than N and the I-th extension ofClientHelloOuter<tt>ClientHelloOuter</tt> does not have type E, increment I.</t> </li> <li> <t>If I is equal to N, abort the connection with an "illegal_parameter" alert and terminate this procedure.</t> </li> <li> <t>Otherwise, the I-th extension ofClientHelloOuter<tt>ClientHelloOuter</tt> has type E. Copy it to theEncodedClientHelloInner<tt>EncodedClientHelloInner</tt> and increment I.</t> </li> </ul> </li> </ol> </section> <section numbered="false" anchor="acknowledgements"> <name>Acknowledgements</name> <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 protection of the ECH key.Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, Nick Sullivan, Martin Thomson, and David Benjamin<contact fullname="Richard Barnes"/>, <contact fullname="Christian Huitema"/>, <contact fullname="Patrick McManus"/>, <contact fullname="Matthew Prince"/>, <contact fullname="Nick Sullivan"/>, <contact fullname="Martin Thomson"/>, and <contact fullname="David Benjamin"/> also provided important ideas and contributions.</t> </section><section anchor="change-log"> <name>Change Log</name> <ul empty="true"> <li> <t><strong>RFC Editor's Note:</strong> Please remove this section prior 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 ClientHelloOuterAAD (#410)</t> </li> <li> <t>Allow clients to send a dummy PSK and early_data in ClientHelloOuter 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> <!-- ##markdown-source:H4sIAAAAAAAAA8y9a3PcyJE2+r1+BZaKEyLt7h6RI81IGo93KYozYoxur6jx rMPrVwS70SSsbqANoEm1ZZ3ffvJalVVAk5S9H45i1xqRuBSqsrLy8uST4/HY dWW3KJ5m71+eZsfVtNmsumKWHS3KouqyF8ViUbv8/Lwprm68ZFZPq3wJj5k1 +bwbl0U3H3eLdly0VTk+eOSmeVdc1M3madZ2M+fKVfM065p12x08ePDkwYFr 1+fLsm3Luuo2K3jMyfH7n1zeFPnT7PT4yF3XzceLpl6v4K5F6z4WG/jJDC6r uqKpim78HF/rXNvl1exDvqgreMamaN2qfJr9pauno6ytm64p5i3812aJ//FX 5/J1d1k3T102dhn/Kav2aXY8yd4V7bRuFrn+nD/uuCmnvV/VzUVelf/IOxg8 jmhWrAr4n6rTC4plXi6eZsXH5r+abr6cTOulS1/5yyR783Edv+2X/B/ry9r+ PH7VT3nbLTbJWz7STfXH9X9d4A8GX/Z6kp2uF4vyKq/iN74upx97v4pfeoSr X180+epykx3VVbtedGV1kb18eZSMpCqnl/UibyetPPD3KBU3DOtokh1Ost/q ehaP6uiyKduuXl0WTXpBMrZFvZ7NFyA2yVCm+fV/XRb5CgZ6XnbtBCTGOVfV zRLuvCpAALJ3Px0d7O8/kf/8/sn+46cgptXcXvPbi8P3v/08Pnn7p4f4z0x2 zs6v715mL8srnIZTFMC8mWXj7OTt1cPsbd60RbNDV+fNRdE9zS67btU+/eab dbOYtKtiOrm+zLvriwl8yzf3pnU1LVawgVZXD8cruhnvncH2eZq9yjfZwYOD ffjJ8dGL8WGVLzZt2dJY/GAOs9PN8rxegKTqBVk9z942sATTTQYfRPt4f/Jt dl12l1s29A4/Mxny9fX1ZNpO6k+TfDpZf/xmVdSrRfENfPkU7pxML4urfPHN an2+KNtvnh39Np5O24ODyWo2p8fxV7yur4rlOawlfMoB/Zy3oXxHFqTCb41n lzCQ3MgkLjzutabMh2/60wTEBkdz5zuOYsni641EOTcej7P8vO2afAri8/4S JhbU3nqJkzYDpdCU50Wb5dmymF6CVLZLeHD2vsmrdgW6J3uZb+CjT4vpuim7 TbYLq7CHy+EKXgEUn1wWgdYAHtS2+UWRrUGdNPA7EIYr+A+a32kGSnDCg1qW s9kCRngP9WFTz9ZT3A/Z53sl/vOLc4cLmOD1xaVf+c+f/wOk/PHDh999+ZLJ +9tsWbcdykp3WWTwBbP2Mv9YjOArpov1DIcHv3AyiGnRdOW8RL0+wp83RQaz BEOEX+aL7DrftPj515egBbK8yuoKxBnELe+6fPoRHwCruSjypspWKJpdkfnd BmPPz+t1RwOBHVEV9EGT7D38e7XI4bOKTx1MJY3kNSgJB2oXx4K37p6+PtnL 4IKiwvMERzEwqXAO8NhgDB9behNLOxxloDQq2ih5dgFbvzJjgNlos1XRXOYr vonmrMVXoZaw3wBfN+9g7Qq/wVAceAEmqfygIoDpJPmpimu6zn/CCCZrsYAH bDl8d0Eb7OEq5F0GF9bXbTal38MQa11eHG3ZRFMBv8RPwHfxqk54VKum7uBz +QNhNmH9ZlmNi5yt4DdVV8JbNuarYeCLGZ6sa1xsus8drlYLXRIW/bfw2Hpa L7LXYArAM3i1Dl++fb3nQGF0IJX/ibr32wf7X77A/q3Hixrlayaja1lhwWKA TsNh0Aw1FQ3mqmzL8wV9jIMr5uXFuqE3tDT68+Iyvyrrxkpzu17hxoTn48P9 pdOSTpp2XXYF/cRd1tf4SZusKWArwyUwcfCYeolP4Zk2IgLzgDKAQp9XdbVZ 4m5vi26S7b6G2XO0TOUSFCeuPI1xLMs/zeDILKeFmcogx2DwFA2+EWeBRcmp MMMvs1mJc4AXzlHT5jBEGGdTgLEyGy9oBWBT4elU4gtg/+H3wPENF7pZOZ/D Hh6e0zB5Be4G3BnbVqQ//ZO97FfSYqRYQLqCegSjssgXrQiuziRcopNZXTj4 hDyDg7Arp2vQw/RimCGU0asSJmSUnYOimNUwB1XdySNla4uqmjf1kkQyWo4M PhMWMMdFTvXM82K1qDe0MXGhRIxb/QQ3L/JuLRpvVrbTddvy9v78eeZvBRl2 DnYmfhAODX4NtkexmMPazmGt6WPh82S30SBKtBtxgKKFw7ZU9ZSJelqCLQBz V8Pi+HXqLhvS8rxVcZarYhFkyQXVKVP9/PVp9vd1gQKBEqTPkXk7eZvlsxnI SFu0k+xFfY26feSCPsPb/Wq2/jX44xof8OL9+7ensqsfP3z88MuXUeZ/CZLy zXNUPbLrHz96DGeRXPzgCV2Mm8/f8H9+PTmS3z85ePTgyxcnMmDHgLJpdB+Z U2AE4EMWaBWD1iZxAAsQfQo8+leq2XHzL/NqYxRim12ifl+ikQsbVia/dbDL aHng6DHTNGErC46yuikv4LpolVgyCtJFJbwKBL5eLuGcCKKsmz4nOQbjD4Xj 02YC5zr/rqiuyqauULzakVfPTUGjIhmHw3SZNxvYxii3JZws5QXs5gysp3KR k5TUWX2unwf/mBW8EwpzvN9vvSgGIQ76MhxkkSUBqxv/+Mn+w+91HeFUg0X0 mlYEHK/HeacbV3JAtBO0ZcC5uMIhqF5+XszLqqR/O9oQYABl6Aa22c6rX0/f 74z47+z1G/rvd8cgMe+On+N/n744fPnS/4decfriza8v4fdO/ivcefTm1avj 18/5Zvhplvzo1eGfd1hgdt68fX/y5vXhyx2cFdIO/lBH9dDR2uO2a1ZNgZMH 66vWIs3ks6O32f5DmDFxQWgX0KTufw+7wF1fFiKcdQVKmf9Jx1G+WoEBhc8A dQ0KfVV2Oe53eEMLZ1aVoVkGThX8EvUyKCE+c0HuCtkH9FZcvRFapvTbb0lx 3cveXKGqLa5dMAro9C5p/CBVBR2ENVhDbL3B+FjLX6NpsaoX9QUqlnKxWKPR 3JHog3Uycqyerwuya2AdwLyHX76qZ8UOT+opCG/HPyCrr0VDa4bHMWpcO3so s/MajR460kWDw/jvZe/9GJz7f+GPN+31z+/HQ39+37vun+kP+KeD1x08eLD/ 9Pmzx0+f7sOf7dcNPU+Muj/QMP6I14lpPCk+5WgwoI/4Fc/rX8eug38cCMLX jC/9yV3nT/+wwW5+vctfPP4pn5L3A0v/DL0D+PuoXp6DTprt8dJ9fprda0lM xigI7O3+aCVHl3uzAw4P6EvzK9aUqmZRgPHfrKO9kYDmPggj/ka0PGy1GgQP zg7HVhRsgrrkQ7vsSCmzQeNfgUos2BH0IjUyQPY3oqB5GJO+UA7O5+/vOtWD q/bPuy7ooOz+c+BXx/CH747EddufP97p3QNyqe++dQv8e9/97815FguweKTm j4qziH6QZVRwsSh7ldeTZP+bviCjYTkszOpVizBP3LsczUJ+BNpDKtMDFwc5 t+/jQ8jKMJgJ8samWKDHHxvS2Tl8vT4lGiE637VLLPBk95BrQQ+kOYb9tkTz I6+6xWbkrWPrCzjvBoC/Atb5FDyp1n+FN37F9LDjLDY1f5r11x2+zhorPiYy oXXBH7HphYuh7o2e/iM8367h8INrwLXSYWDgLh03Gs34ux3+0vGcpYmnik9E 46rrrKHC4onbORcpkzvIX2jZPfFmqjgWZaIZ0Xsq+zIWjcSRBx29g0/i1eWm LacSDAAnDfUczM1pUYBh0Uqka0zu4awQfxDMG5S4ZR18pzjgg9YmeDLgYpFm XdDb0QUvOxIzEpfajHKUDc0bS2s8arYL0igKB0MoiOLc4eDDYPbQdm5pcKDI OcR5yYcW/TByeiW25Eq0XDUAg18ZQnc0urxt62lJp8Oy6HL02sH59KcPGUnw Gvhct255ZpZgS+nrWeCSN69bidTxW/wbXLKf4g9EK8sIr5uhsS37svd590lp LPNOnO9iUVzQsqBa4U9kQxNcC/A6WnTixSF4+N0DjO2AhDj4CW6Gk9djuO3H k/Hzic8atVfT8zE4dSIrGh1pRUpQGHqDajFdBJ7YFQYmxR0//dPRM5po9kRF 402yN+Qgw7hLuHpj/UeM9JLDtqpbcoYn2U8wAjl87N4g3470zOAcgY4s9Ae0 KX4Duz0EOa5zjc61Xc6LmYvfyfuBVqsFQz0R4RFsA4ywgEW9xhBd7nW3EeYR 65yGLXTREub3J6D5JKog4+kuOcxpHsuiestTnfn9m3XHghS9i36Kj+5Iqsuq Ahmr1212lS/WBUmSC5FEH+5inw92z47Xxx94rB8uKUERLnW7nz/7i8Yi3XTR ly97Guad5g2FOXAmiiEFIHPyU0mxr2ilYXhwTva+SZSQVy3v/T+yDg6J1vtD 8PPgouQcJHzq3D4caXPUav7YEg+bpKmmEDn+dFb4AK6NCZcYdESphJ1H+SV7 QrH8DC0O7HL4v2Qlm+JvHG/DV0/CyNo1naHzNap4GUc7MBBYxOscjYkhQaPB 8Vylsixro5+RnLJDo8WHYYRkimkyP2D366rGcOa04DRcWJf7rURt23j3+qgH KtqC9AHMOE43PNBd+1fAS3cxqsdXw7NRL435d3k1LUDESFLhLJ8WxawNZov/ DgdXg96BexebSUZ6QCIqPO3FbCS2hCZTYx8CB7VuKXZzvnHmG8hnMWF2Pj9O YBMXOTwTXyILW1eaGDC3w2Q2RQf6j4a8Xo27eowpuliR4efrOFkn74msa6jp os4XKOfyUZRyaNdke+RRYBx/peZDGSJoSVwW1TiYVGWLU7EGzUhfTtEK3FBw Ma7WBIyVpqhFI2K8Y72YwUxflgWpZBgIjQu/Dc+MfD4XCccIX/GJH5+pkYLr t8KToyBrz6dp2JTBJ8WGCx9sidXiH8YCwQlXupcCKsN2x1E02Z/voXhFC/CF A3BgALTZi7e/HLPBHgwJY17AkYpX/Eiht8d40tJC9Q4njuHgCa9uqVFQZ3A5 D+os4+MA1tJ6q/Uq//u6yF6sPhZvaRi/FJs/7E8mB/93/7vx/h9/oIvWYGzv f0cX/VIsT2Y/xD7YN99wPI/PaRlv78bZ/F+78RDkP73z1hv9Zx+ranu/WRU/ JDdqlGwfxMPR7TxH2WfvF/qhZx9n8w/l7IfoNzy2LIe//O++0G9ON0uwApty ekQZqFNMQP2w5R045seyqL1X0ISDbCx7v/HrJQL0AQQovmJoEJIS+8ApsT88 lKV++Ec7engoT9+2IQ/Pb4Z4nzAEkS3UZH94kIjUl4FHbHtZNCLcJh+mMrh4 Bpf5p3K5Xn5ApMmHRVFddJe9wchU4SUk5o8e/fGHG77K2DA3fQL8L2bM2ptW GKRSAuY/pD9Px9qCEQ737/rnT+TOPfPMDEwK8CMefJoXD2ZP+2MhM40HpTd8 Scf9AysCtnZUPQT7LtYlnBgGW0cG456SeSj/0kMDFRpbAn2HBlUVqL7ZxN7o JIRHjm2uYYdZIXELfB7aprebjhNRxW1GmYPyokLtjieE0YIufCadlLkfP0Xh Z7W13UBR8tLIp/I/MO0MmrbDxKtYhBWGImh+xM7hK/lHclq7OE3MB+jHcsUJ MTLD+Nd0nnL2KKNU+jUhMmh8bEU6AhPxrGmyOV4GERvnVAjgCw4r3QQ4eFxv SkBTXFQvyxjwlklOTB7KfhPlQ/R94qBK7IXvJZ+tMrOtohifPTiTN15zqwAG FYCflZ1FCiJ6EDgKG7UhE1E04A7junuLj05nczLvovuCAg7/2NmbZJj+Z6OI 52V48Gdeq5/x8NVMJlMvBD8woAPeam9WYLoGtJqKY11dgMtJyDpc97zvXs6z j1V9XZELgIJN/xrx1iSfjaA75wUn0evsH0VTw8Wd7lTOuy5X4HBkq3xGUAuw IeU/1V5Wn0d82TwEL2loPGhw1RHdw3nU4hMa2DwO2SvlfJQVk4vJyAWDnw2l 63IxmyIOr6L70VCezeBuxNbwj2QWY4iGc0bZy5RhUEOna1v4BKZtUkxGfl3g cYRuLWYY+1ivyKwejBMEJyfMHbg6oMqXZRsCCJrUHrk0fZha5/ANTzM2WxFX N+YPGuMXiAUrcBaPt9DcJLvcsMTlTGOydjrgweFko01EmsYqj3AGinMvwh5i Jhi9QueYwCkuigxSZjO7KCr69zYw3CQ7BiN/4JXukhLnB+Ma5qIjs4KTpsGi 4FGNgnI0P8UVgOMCDhGJlIVH4QRdUIwbZqnF5RXtIFIocoHPIj2v2AJUmY5Q O5MbpijOaFKCFLcLL/04zHjwu27QXbcoQa9ZaPnAmxqTWudUP1zV6NEpuDdS aKjJbhJZ8EkN4qJkIF7hI5B0DT7WLmbwWSaZ/9ZyBh/pApIS5XRos7V0OspL VClNUMUv+dPeqy5GQxe8rnwFjjXL2CsPPtr95fjVnv102neE7xLc0Vmwkc/u ZChkqaHgeAJYmOF9WwyG8B47eHOQyDzHzrsH9vWDWC4y2FX1y27lmXn+E+2O w+PD53YSVnnZBPQgYsQw8IzLF1CqrvdC0TdNkS9M2DasX4u4NrQZBIqFGhxG I/I8GHD3gdyWgK+whatpoQZjAvBDpanqEW4vQYP9g4EWvAda67365Qr/9RLG 4r0aNNWDhXsWXTS41yjKJ3GBQWFoCWBXTGF6SBRIJeCnrCiuhR8mW0piNB7p i+aehAQVgqSWdKtzQaglxSe1qMXlF5iPWWLcquW0RxxoOPFr3maf75kduDUF wvoVD/1aTAQzl6zMRooHtDtJ49MgyK18Jz5EIDcyjSza6wYhiAufXylm/sHw 8msQOIKxNcVVaSLIdMighdB2mG4juA2K7ShrEZjuZRAvmcLhEaU/3XpFMdDs /fuXuIxkIOEWArVkZ2HMswCibaHeHQqbBkYpwYNhwJaTqvpjAU6bXSPTgNsL LPwcDvtV0ZBtieOlc3CbpZFhcogEzxFWbXgh4AXwTVd1yfbSQE5PH8fL4LxG 5bgbjMiaoSFUnxXR6SugRhkFgVxh1ziDlsoY+nOxwfPiqsxNRLLFnAoMxRtP ddaANNdLSieiO+vsIOD4LdDeht+uQXQXUeQcrHLCmfcmBFO1nUZRqwIXB2OW +CkDX5hPmxpWL6Bh4zyoQc2dh6mawFkaW9EkanAFggcD4A9xUf7Jbvhkk/2z ABuMYnH9IfqAJnyrkRrHgjTJ/sSXWeRhU9ABUs4lnS/bx6wiTo+IvoKqwpIO aI/jkKbxysOYKhyxjJ0nm9kBTanWrmI4mxpOhjnb6QTyyxduvq6m/J8UVIVB ggOgoQB2xXDoeQhmgqL9/LkfQf3CWrJsmhrV3WcN4j2cHKAy8wBGg3K94QPI tuSv0M3Ix/PJ4evDCN7nyD7vzc+4zKsc3zYQmTXTxIeX84EOb6jzlc0aE9Lw uqhWoH1qH/Hq8M+CEsShoMjQ4cN5247MYIVMoqDQGQbqlKF8Bno+Z2wojoIM a1HY5k3noD8+TrJfq0X5sUiGNKIsuDfUUe2dI5754oJP6SXWTHU1bMtzby6l 803xHQ7v4A6gWbksEexMp+k55gDYH90HgY2MtRD5CI8kY4jQ/pfF9CMJ3roK AFc/IuPykEOMBtHQdbbeBLGS5CeM/NGD43BiNHaRWXEGoz2EdZmvyaqwNTBo QpVkVlPFQDVfsBHUS0TKUXpeaKiFpzXsb/sRartz9qZcoKKa5muZoRof6CJT HVMlLWNPKcjE9ggbGeyfY7q0pK14XneXDHm4AkdmRbvUxSnXEi3GyBnAZWB8 hcDw1piN7kqu/UD7F1xhUvCOwcxtttsKxAS15ljrE9BFQlQe2hRN3nZ87PVf yNFDB/ZZNJmsk9aYScR9WYUqFVgjd4+0ztaQYvDrPt/bkowGi7KGeUMwEDx/ IMN8p2y36ud+bpcyi3Io0oKQ9NMhgM9PdgCoygHHQa3kolovQ+B4eFC7HEfe G2W73z169O2jPQ0VR/kT523pVb5Z1PlM/eUwlMs89Vi97fzUWO48JhbR3Qd7 I17Z3f09CU+Hr+EXD8bV+xfGGQgbRzcGG14TR9I5lE6DeWp/rNmHWxMpP6R3 bc3pxOkIWIxeXqF/lUx2Ly9nB0/z1xv88XLVhaTQF5u4CBNifSSaA7OcFIAj LUe/QcsFzOSqU/ig7Mj+De6MfuNv4IM+vZr8EFAxOEz9TA2Romqj+i44e1Wt 2WoOPLPRECRHKzZAzFlGaT68gcvrFK0u9+oLksJCHmw6Fz3RdoPBGMnSJoHc ELOe+It9hGaKQfjY0LXSJQ+1xWze5toaOODDgdSGGNRsdSrgUxH3sYc3EJmf RAGIM/X24cU2wlH40Azr+ZEPdETlKQH9EjuWZ7L4Z1EahfMnGM0jAUGzp39i thz49NAQxELQr98hIOIdhhtowPIGGbSNLdCZpWfaMQcO0/kMamwULnZs4NAE DMVyNYTSg4zRyZFsrJDAueHsCDZMgM3C4NA2FFm++8kDzp7zOAbjBUh0djTw ScNu9MinTUz5hkz303AODalvH47JCL4iW6Q1impghOYc8ovOscPSFNbY+eHd MgBmI0OwC6XQLQPoyjaeKiNbvGixchsx5i4YAY6P63O0rjh8CItijM0P/uk7 oL8KihxGE8D5uniGevEqCkCZiFUwEkO8anR7wGokPvBAZDKRANdLUEhBD+pi djJFR3rA1g7DkuIo3w58rgfnJSESuze2yfHI+79ihpQMuk6WxR9SHthO+kY8 856O8HaW+7qt5HOGXyP8crTTvIiT8JfHfzVy3xuekXrOcrDZ3ld19pmZROhA J55dNs0HBrt9sJecDexzCYHIDh/DnaTE4jp3skYtuHgHZOJDA6Mom2Imgj3y aAC/wLQ30IqlcjicdFry4o4QUXahENVHp78i+wROpxDoXUmb4RhaGPyewsVr ZT/oHZls7dPvxyRIYOU/K+a4s0LAPDL1V/mslcQUxzYWG0qXcp1tHzxJVdz5 XY4Yj+jCHNINYhT5PHbCUnAMZnbbv3CW60M9/yAp3CBxw2MyQndmH38WzmbJ D5PqAKHCEtv8I6dJpvWKyp97E5FTeK3z2bczRJ1PNx8EMR3y5T5BTgYAYxbI LwRLkPPYbIQFQ9VOSNCYIagUhYz206AR1oI8p2eX3S3PnMWRKn3oo8m38kiu mPVo/KK1Jmf2wsN7/RPvw8fU64YTeZdFPuMIHg2nQlPxulhcFemvcbhssJ7R IuvMkSYDtY6VcPgLRkNKnvOsJwln6oiH5D7s+HcUqMVlWmDJehQI0grnHbRt qaBvh3Xhqm678d/XoIHBycsXF3UDP122IxgNfEJR9XceykMfZw7qYAGfSWbu J4z2Iqq8BZsNQ+JwXs7WU0HBwM8k+h7tTzSL2vV525UdIhiMWyAuBiMiWnct yYbZmhG4PY9AjQUJU2MsFikklvWVFjs2xWrBkWUb9sMc2bbtLqlpPJYXojzJ FgzGQRvZeypuIRf2dKuTP/AsdPFnDx7c5uJzYi2C9dHHB/PrDwcInHv4R9EN yW/jxDVNEVrV0QM1sUHpfz7MvDXCJzm5LDi127hfTIGCBNPpWDkv2MIB2xzH ASZHvW452pXOvy+B2zL15tW6leCrCi2a77tOIPalYIu2rfnEHfqQuBYm2BAv WY2+Ery3IyzQmsqncEMIKkGj3RIK5jSAHMZLtmoZv0HZjDA5BO5yvigmXU1K tElez4z0cJQ9G2VHdLov+ma180IQ3/NcbzseZT9JyvjW2Z9SDJuCm9Zhd1vm mNfVh8LDdBYlTk1/VutmKHo2VDxC5z2Jp7A5kXtrjrFIAdNZT8CRYawd4eVE ObMZwRcoIIpflS/rNVnFCsAiGpXZbGJVdZTIxGzocom8dTMP2mqnl8WyuClJ L8d432phTUfuKX0m8wegOsYKGzzvy47j8u02sR+FfAepS1S2G2LkmaOwJJYF 6DcZtoTpN/4zGOKCol2NcdpiJxh3KftcgveLyk/RuAQ1D4bG4oPPpwf36zVi OEsyXmgW1Xbptpk+lHGoV6XGu7aaMHQIDJ4l5DUilwnnY/PK3bYZaEbmSP0z 4hpKPHS0FKrnkbhYQVnoRRwiG3aN3/+vzC36apStSqqnqMYP4/Zwiv0uw7yJ PwNmcQqG2CSri8ETQO+NbjAPgnt6Ks1kxqYFPWGr13Hbw+ju95dpyHGgZs4u BBm1NUVt0wfC8SuYono6XUcqXzS9k4pgo9spS3VFPlkVWNlI7iStzPb4Cn8B F2GuXkG8jq8f4TafIvNmD67HX8AW06ww/g0puCVagWQcDqhRn6EKzErzdUNq WBiW9HEwkjGMi9zMkwQpHeAl4v4Mem8lZgIrTI92Jai67P+s8xnGG6YZ/jtL 4de7ar5y7SecEhVhGqocDlWHux8mYi/DwAnonBy+vCq5NkpLvpuy/TgBy5/f OqZdG4H8Iq0sV9FYSH/OfFmVIAww/uLmgrTOVusGDIqCM/aHIY024L3yAn2+ l0dX8YA4U+XFwwMaYylZgtc790jps/TZZ46P+Y9FsfIleVyIrmHTs3Q9zpz4 E3PY7pI8o001XiIBXn5eIhKAqjoJ+mQShf36TId12jlrgfR3h4fPNepkgNyE BsXJpOBsW+QLLX6vYaUpErbSMvbhOld8bikALgkVR8nUAW/9Fu/SE3Yih9J2 j5EuYyeUNx0Zw31X9I3kJzAA4jw6N4mkq9q9WcPRKTJTj8TaLEpeFoDchDcY MGXIjJEdzza9x4Xf6PNmW3ze7S6vI5eXeKXYLnsmSeMAFoiJ+TxcO5wSlGdO mY6Q6fKp2oloKjtO8aJNBXs/esJQeDxE/H/IOLWz4XRt7n5mLHSRvSNYlEXd HCKnyLolE1t+zJsj2/353fHh6fGeUql9j2yK7tZhXGCwt9AIrU6JrCR4DVTw jH4YnzROs+MFwwB80SmN/0IHDipwvVxuknnkiW4FRbstDDcDQRmDGz79iFpJ RJxwISB5Fefl97Jgm2oQGOt3y7kAEuDbsJJfiuqp4AFPD7gbi0r78BsOMmG8 l6eRniZKyU7RHpPsXZeqbd/gy6UeGdSqX9Ubkv4c+GJkLOmMddnlMiyJySt1 oY+Nuyi8TzC/wN+GRpMgty0Qlajb+NFcNY6QFxZ3V3ocMqsKBCn76EsABlOg LjxzMg0pSsRcn4FEdcjmighjGMgvz3/6hpDFX/OoOGU4cuppJ8ViCjDf+hy5 /mySvUG7NXd+XnuFZWIUR0CMhWc+jXKnZUdkLi6FQ5N53QXXUYDOeXx37Znv OADtWSqc5k5igD2V3lhJvWHoUQ5JzB6pRr9tn7MHE02A4YAYtJjUi/0bVnLA 4xWEmTP3OpbcmHtClk/OnIAmM5kPQrIJIYKZSt41YDAGXcN12Qc4nxTlDsZi gHb6+nMlRUiwmT6qGh7L1Buhqk/UU2UWgEBnnICcbB0oVvAvuSxAVU7g2z4Q IlocdmBYQCcX1Y0UTaFZKxXqXteL+knyDGgEae4Jc0OUo2MPoYgCa1iVjkGf xSYauJ6vNx70MQQQ1b+my3LinEiEaxsLB+h0WicbWhJIrvAXwBTj83xe7y7Z 6NafMz1Bx2clsr7nbuI72RZv7Scz02WgGaW0lo+G5JXHNygunLTTJ84unsHP Bc7rchuPXX18l/2YPS+88ejLtXcH9FyoGtmTaO505N/zY3ZadOvVM/j+0114 7mgrKR//2ekWLUaAd7J//jN78OnBA/zbv3SPo7asLMpISQg5L1g6W2xsryAy VRDuf0NBbFUO31Kx33l9VZhd5h3QWbq5tsddA4SOwjoYGkHgVOSUp2H7IWe2 4IiPiU/Q1slNUNfHoa3nHgdraSr7AeloS+s4Mw4r/Y/Glf6HcEODcSXjctOg AklIKEEBsahD6Hraed128ty2E7jf+gOLLFF8HhHcif46RHd5Vn7Knk8eRi7O Hm97pUrW9ZyZglmeefNwfrInR2EFpOyzDG8O4kO+McoQH+G404glv4i+iulX OKpGOFaVJ89PS4wgMt+Hf+bppigV2f5mggdPTnG64vwrzz+XPRgrWlfUGNJz GN9lcjeHs/huX2dGLCSFlFJk1Zp6LciDajGvWT8aL3sMqnLKWHnQlPyNakug n8eWmEIIhswuUyl6phhVVCwsR/TzwcJ7Om0lfMVLxusFM7Ea4V7m91PXhlCX ITWbclgMv2NE0ZbsHD7to0YgCFlCkukLAW+spsUBzPNyIRE4Ckkr462aBB6s hl8iR1z4Bi0WAbv4h4x3wjAiikTrtxuALaDBOGU6Q6W/szXN5bUXDk4WkQ4o D1FR5+bOjyRBozMkHLky+cucpHvYzFy1HwXwEwE50GiCTcsGWoSbojyFGMcw zrenv8Rcfylr3aAwD4WMwFVM51amo/XzQfK6dUoSSLVXtjvwkXjpB9jgIFIX xQeiKqYOKtu1AcE6BkPot4lBkTeLzQeMVd1RBMKYY5vvDs8xrGHmeEgEHveL L0VE/6gXb8I6xnxeYE7VF87i82gIHHYjEF0MJFthgLLPT/1wcjDZfyDYolBZ Xl5cdiEXT9meQVo5JOJA7a6tE0zNTxrurQrGy1LB+lTYvC231TBvHeOEnQKU tqZKOMzBIWAjuBrpCHVQF+tylnPaYSjD6Pu3UMTqJuAAxTvRNNKyygE2gQBb igc1Ej59Caf3o/14ZjiOndCmjujxRoEkrVWEjAdI9o3sm/jWKN7i2bQGQtuh AiP9COd+puhIfoPRd3fjnUMUNxrA21zrgVxJ3rpQrUw50m18dWzhUVj1JaXl wkxs+arA/cnxDZhm+kaM0QQXGvw7IXOlK9dLNcQDda5wiWhohmI8XX4hP48U vXhYltlvyEOgQ/ROGD4ZaFBVQkZioSNcvqRQTqGmMJIxALv0ePyxrbaU0qEt 7AD+TEow+CFE/QM9zkS0zuxq3m/1VhslontQvCg+y3E82q0/UPB/HML0I5Q6 NIsu6wVVvxlyHoPzfSnxdefAC0oiSKb8W+xzicZK6WRLRC3awEBq18AytRWp vu5MS+/yUMAb7ATOvwtTP4U8+7JPqWmpKbziAw8e1oOpZrsv3r3bGzl1l6TD Eh+7oTSiRebVPjgsPjC8k92qraa4v0jPbZHbiTsxIr5WCZ+jevYI48i5p199 0F/9qEplclrki90h1XGLx46xqOHdLt76iW901MvNwePPNP/FigB24nlZCVJl IJenGPZexg7Feu1zyeSBSJawTdKErv/YbEuKcOg1/UPiNotv+LT08IeQ9CKt cBYt0Bm3ScGdtIXiFnM/giLzLMAm44UNJyUHEVWeO+nJxPxIosYRV19+KgIr Zig0sSxY4g4zRRr/oiTaU3I5boa/M4BLULcMoUFIDbuug/WhQoAclYemU3G/ dTf5EK3mxepl2RHPaS38TKopSOpgLLuxy7Anh7z4KegGfL5nLpDamNokXaJF lllf4ZGJL479CnyctLcpmZ1j2ECz8Dh/iOeVpOducBVc3+aTQIv2jMD6Oylj oKCxuu6G/Dm8lOmtkjC2lIze4sMhOYOpZRNT/hrJUhXlRnpbU/zaGYjCTbYH Fde/4Us1ohJgpp6ToK2p55DlQM/4XVdlvVBWoHAfxfVcYoCaavx4kdkdHHJ0 PAGRnEiyQHfycruBWlqckyWxVHVmlnDsHgrhp8fMAsxQyIvOhFIWw+723NGD McVf6clwvjG7myvhz96wK/G2/dhaNkI5uIc9pH06wAMFDvOYI3jWiP/GxYTp Q0IbiX8Yvd/B0eOCoRlUYYiQ9+8eZd8ejM9LsHXXlfQUUrotIb3PteTtfL5u KfH3AXPCRfcBvLezSfay/FhgGnYU6Em4YhTHxdqFvsBt/4KtsAVYubdCtMhs C3CJzdhHUMIhnaMJIWfAbzLNXClqyK5PPIOyhqA82DiKfThfmcR0gALA+Co9 EBKHOi2m+AzfmBCJ34KDRFX9ziBI3wr08pQQpKC6FXRKluhwPKQ1wCDVJ3Kb SXN6yjU3aKhM/PEthQAfs35X0b51QSUckkELwCf2YvE1Wwwtw/Ek7HOKObUF qdKTKgJ2ef8W8Q0mFol0CXxKh4All0b1Mb1wIOCuFdrNAJFkFS4tkTFbflXO 1mCV2qwg9X6kTomDrUsz6SSIk1w2xrtbtyPeYqkKHWBZQISajN60l+TPaM13 yDTpVwmwTSnnxev17ZOCAxX5M3Vj3+e3ZAUzCfL5bIMwHYawCmZdT4zg9Cqz BRzDaEhq5Bw9kcCxjpXQc7BZRZ+C30lRCXTIzhtQs5ghp0iUPg07T/Aewkan YjG6v+xgS+Vv9if72E3u8mDnr7TXfyvO370/AnmYlXm4qc3+snNdnDfdFC+e juW//+pj6D7rn8/SeCrisBEpgDPLTFe4WF3d4dJjBYwifIQXFN9nDnbhQ8Lp sETzYRLIEubGlLqAgRURe+MmXCKRCFqTVJrn4Tpxd51A4qFLJUkCrL6Jxowt EKN8wJC6vN/GVJ/BZrGi4rMSMqNq93oPHwzeswF2VY/v9uetsky+VEz+4G1O uQv3tai4rxnFoS/I5BzOdOgZIDSl6DnKKjwfYSARaa53H4xgMOPs+Z7g6M0O dAfbXz8rZzTtWtCxfRC7RMUKdpECL4IxPvUNXcncrEzTzD0e4cvs99mT/sh8 6LlsY/1/62RU2UuGAAp36ZAvGO0bZdT1EJeoZgoW6CVIzUtiLrpMuT9vLteS tnJaiyG5TBJ7MIrmeUMLgI9/nf2YfbsPq7S7i2u1v5f9P2AgMWMuztLrgbXj Clva5ekcbRuWct553kC49tsDIajmIjnvjzPfn/cGhZjXagbZn7xtNWxNB6lo hL5FqVs6r2xzZ9QyaCZK3N3hugQnNZgkvusxBeHJ+/bH2NjSaLdx9x5HADnN LoB1TsA7o5eHsyjBxhv78CmjN7QEsCnABhAwL8eWE/oBigbIaJOvCJ9MfZLO WU6QiIjyuZh3ZqrCjHs4h3VHq+t5CJST9XjoA+Vgdd0QRXfusBf577EpReYt UTCzN8/PsSmfHoofD2TJDJXd1sSQwfrbg96gQbERLTZ9heNKCYC9DakTOADo MlAQJAmLV5FIWdTGdgRfpYZQ7EVwzEa/1BrN+LR+5XxvOIT/Tm3tkAOQaOHZ lqr61BuOq+oJbiSN5vjIszjvBeIvH3sV4c6s58++zllvInwx/MBE9CZq+GMH WBHsJzPc9GtI+Qn+WBUJRPNOqzfXcedeD3aMzIaN+TgaGHk7Sc8h5X7ewSqT WfGhQMpAdXTsiwbW9N9nS4jX1tm17QUKvnYhnfcqo4XUcA/d3PYCaX5i2l5H KQXIpRKr41As+fCkJQ/uh2DuwHOOClDLA6hWcnCEn+9FI7rrl/cbOhkfnsBY zsSqRkOpJQp9a/P4p1EUiEsJWokj0QrNOAc+BEFMDDNUm4jdZpa3AoUl73XP Mo0A00febw2TC7EzzkbMqxH7nmB/V7gCKxKgS6QlDyGmh5P9GMXl6Q/6h4GS YKXZn54Yxmwrt2oWm3phkv243GabJXdi7s0H0kVSwxr51+nYNV3M1mlaxBMj 3HrFQrIMBDi5E9JVMl0sUdRPUD/jayGsA0jioaf5abkJ3uk5+ekY19lWSDLm BTfgNEw78bCJbGmSlj4ilO7cgyQ9Yob7xeaLIcibmQlKKUh6wbes8NZgyuzA tvdqo9LSA3AOpw95IvEEM6WHftY8/uKuIGLCK23HWYSNe/sSjKQlHqeqBoU5 lA4TD3AbzW6KdeAJ4mS/9c0jcncx5+RgMiwrTKuMKewJcUK81/yiPtKTV1tS dw60iIkMcuSL7BhuR24bPk0SRwSERPtgWoSQLyER/I2T7F0RZjEaAZFiM5hJ y17T7UF5RTiQx5fl3+DXtD962HEFumzNNiftIUMyCTQGZfVjupibhC5V1gxg ShIXUXmGN7dSHT7JYjIJWw6E/BDagdCavfgosvWDb8Fg5NtwOqLb7bO8rS54 NGkWET8+3rWoTXyn6PQgvmt0+iYzQUthI/uifzL9jQqDbjcT/Ak8cnFxrU7k DcjZgSx3v4kLMxyYR3P8Mz79EbTa9ieSPVXcRfB7ATvQNSAOlG0KUb64xkUj YQygjanZ4is7at1MO1k6BhAemal7UV3NylbL3HoGAIZNF+Wdab3uwkiYTIEw PnORD/l60SHlmBEwzryk2ZGeAA76Cy6UCAp1NOIdEUxkq42IlMwnDfvDxSll dmRyi3+CjQNbqsuRgxlU9rL8h3SORGP0+yf7jwU/SAsQp5dQbbhEcPRDg+Qo Zitq/tofl5AE0KAE14cClLayIWV5MwlExADnmP/hnDnUNN+MKPu002mv/24s SZ6ydCciSeR26hgIQjSbFiwKwblEgTykLHR6C5TfEUY1hQbA/rrAEjiJGafF pa1shsUm1E/L8/SYOPE1fEyCOJSMoy5WpNgpxRDm1NgObohDMWyv+K2hBlpa UkgJ9PY3Ma8qJlVoI52DaU51lnSOlAgHXy3qDT4kaaA9NS8ieyTkXHkwLoSG GR/hO2Treb51TFo+jQshdZgdsXpjxs1noMzzy3kQE5pa5uRjW9A9f31KjZts l4mKOnlRgZ920YtRwwjsK6fcVbhyydipvOXaDHmijKQDa0X9BYqce/0o1eac 4mpgbGFLsNBZFyaZKTIoZQ7SPPjEKUExNpypwCmc0nl4BQ+pGZsixEQtJy9s r2EKdXqFBgoOtPxsA1uos5uOnhntD27PZjFE9oEE1JjW9UfT184nZKiDDRzr C/ulIxcMu8GPFMOnLQZvt/wCnRQBeSmPpoP0SWVaeItysFTIqWoxisMrDG3Y E8VrNKlC+3FzN/JeTePfeNhJiXw4Z9wdzhnei6S4yBAzakrOal+nbNHcpU+g 3FVVWRgEPoE2l7zBKCF5KjFxcag5muidlF03NyvsOFwsbkt8VfyUSQaWqRwv ya+cZiPBi1z7kuvc2zDKmxGQH1GzvoGmhJwUplSFT7pgfTGsX9txLCNW1LV/ iyI0sELrkrKAFda+SacYe74cagJUmAWiyXbb73sWcIfohKSNKjOtP3DBeiex 9bZjG6CLvrsM7r6LJl9dmnZ7ouEvhyQsmIM+ReNfR4sT6m/g7KREPQg6mluJ DeusDcvW/2HfDscbuLyWWlgIE05kaAvIcJsTwHWw8EDtyrM1/ubx825byrLk wr+b+lro5qBlIUwckXqwfWWIcAbNLBoFfy2+ehRHxMa9Ai14eznfBEGfIkZs zs/3rNkIVslucWi4ALeiG0wB1TZ70HHiGFawqVcN1+aLFzfOUoeMAoJtEBcz yL65KpFFtTrhRRy4ODJf5rXorACpw9Wr6oGHc6KTp0iXOIIceHq8GwbkPLtd ujjsNYHxMeYApHf+A8ru8+f/AGP/u/2DR5asRdrETOsGtgd+j3Yu5TxrsHto t4IjFiwv9IA+cQLfBDK/5zAm0sh8++TxdxL5+fz5txeH73/7eXzy9k8PQTSd zC8l+6S3KrEtk7VxbvoWcZ3+ydurh2Ekk5h+p0AQ0lRQzgiFRGdNkps3iJkT bIhWbHGvMJ5zcvfIkjRuCm4d34ksQKvhnsRnt2eLVxx2tYJONJsQeVX0Yg61 cdgTHb/EXvROnmg1ohizFkveuuCJ+ba1iZ/erybXSjuyshhWzLjJVpiUtYbb tyvqOyPvyY6KBgOPJF5N6SXhwBS94OaoaJS2wwxHKf172SrMy08GnpqoUAKi iigkcUp4GTBgERm9amGALSaEMHwaoB+OwM2m5KMBuYuWq95ijoLiEHtDO9/S FEQdmhLDxBQx3tT90zaOz5RUhCRFFCi2h2MhKhFYhvsckX6V3ZJ8IOiOJG6w /0Td8P743avTH5H/6+GTJ3RAUFIoo2Z/VLIjOjfIKw+EkAbiUsDk1d24LfCs JjSKIXt8+fxFtsjBiac1dYN0ZQeTbzkLhOro0eMnDygRhsc98TOyKMkj/T45 Ly5K8tWKoI6zw9OjkxMcDZmWcC/KLb+eOU87QpNl332bUVPe1piLkezHS0Qj 8MsiiG0u0oHvc/QCzfWLMUbgGny7DAk2L/xsF1sUZvcf3M8EGpndf3J/D7+i bN3Og087+J87D/57R45VaWNS41kr2JkNnzijaJbpJe4S3OMZuJNLbCZ5wwtH 2f3c/GB+nw3x+4f3nf/hT/f3tJsohbqjxU87Zsba2al2XpTws3zRivl0wj0q MaNFhj6s/E/cruwoqAbTdO3wz+R0W0DpAlySStM7eWZz0aQouf2Zs6qm0w6W pvFjjCNLIgckOeeFWHhTPQlgxHEphyhItNSEAyz0pOR+ZXWq9TRLS0UQmoKw ugT2j6IMHJ9hPofDVN3sIi3KJZ4MOAmDbTHQyG/BifEBvIQxh7VIHDHVOpDY g5G4HkZzCE7acdDpb57dKsT67XdQRNTRVsNGfotN7NmYify6URjrh84JDcyw hVnrGGjHEPemw3KRRuE4Hn6Wul7oSkj5n8NtkwTcLigpVs1Y86InuhHZQUwV h74OuZEmOWKzSGi1zNBQRHpr2tR81msQNqfNlc7rusOep6vEvg3c92TcZad/ OnpGqZFyWrxCx4xRXmDbwaPHJ6/HcJG17mgwLD8UfrrMtWghDB7vJNoYmA04 RrvCTC3vKZy+KOiWfkeCHHHsuJ4juL8Iy+CbUMmS1qEG7rqpkdfcWEjaA1Bj B9LqQVZggzaAPHfiAr9dG+uMeJsKepjmPG9NMMtpMCs9svEdtkivnBdEq0q2 0BRbFcKGwHZtrMwC8bl3dRlHpK4ZmuYuiRm1fonfnv4ieEguN1lI9CefI2AZ w6aUTFbLt84wh7ZEPDZ/J+8RKqKnegBsT8Qn5YaVT4XhS65JEdgtytT79y/b PflWb8whg2FML+eIsTAQHIbaOmEshLvMb0N5gu9Pbaww7c8g8ZzxNF8x2R59 nJTIIxsDPiqQCoWyKhRHyaqtUeEZ8Ck5yNSIhmvJJKTuxZnYIbGSRu2klDNS 6whZGrKfpaORzxUoEoxNxNZqIooYhYMl2C8k6bmp+jYVWfkVWKm53SEq9CFY FhenRSydd+7+2IejpB79qTiWtl7bUMxr9eWG3Fl7ua1Zt3eEDMi27obc+1lb KOJgvWEttHyfCjgXW3FK/PPi0BeTNzEoBB52iQMgXApGwnFWxRnCkpXEXEjt Adv6IFOPJ/5cYnPozctiMw7162yrR73qRLt9LBCXAIK2WnvuEgIb/HL8Kn5N wq+77VWhEO3l748Eji3hsyPnMfC8RIRmKD6tctuiN/A7ECCCGfxJfH0dglR9 SKRlG2TFBurJj9eK5et+3S3jleGB+RRPMDlgTacBDuv5XN4A1qEfqx1Gfmks NHDoK2j/DlvHA3xo86T92DW8MgUbnKG1lKGQMimuWvDVsd4MUUqs7VsX4+5z RANIz+VSeukSVbtWkXLzjXywB+HJkKF11+w4+zb956K7MpBI2J4tN5AtF6O6 SMN/ZWo8U4JeJ7FBCmKE9BK7bwnyNYYZtGJwuDQJ40uBBr4PpvNNKCcWFRwB 7aTUpS2pIYwpPq5MfaIRHTLVhXe95cybodhPezpijo3QXFPQJFFlrUONlxKJ ispqQw7UFEdyvBxPNwbYmNNte8/xqApRajveFSRbEUGh1G7jDqjQ3ucqhws0 MxvpwI4+kjHDoq6dbocNih2VCab81mqZNDM+YkBRuyqFDtqeiuLNgnSvWmVf UstJInoxv3TrhNJvsZES8qiguvd2bEslI+cDy3kWE+kGTJqj0WkSJzqE/MFE Hvs25KCiwLABA1THMDYxrij56WMUMWerzwnf6XW0iNyKXlqR98M1PWHAST2N Pjkb+mTHeVQZALlRgUBsmXF3H7ixwHxPf1on7qY5aJNJkEijTYJJ1tiRHS4R XvQaLio8w3AuBvqvU1ov+jRhA+boLhjQsgY+P9N/MQJk1xgXaQnk0DD3f8MB RudRryyYsgnw8MMeGbRHsVE6bhs4OZAffiQTB4+hwNizDdL7GCtXJzEZxwzr g6tpJ7YOemkYr6W8i/GwBBUo7pE8FUPNMTaCO1GxMsPTOoSQxwsY7MJ/qQJ5 lY1XmnXK6TebfM0nIJ6EVbyMGN6MLd2FOsu4iRQZHfC01YKWlKgYLloV1MPx sc6iOKP2DiaDHINDmT1JYd2kXh89fomJiEuKENAQxnbZtgIEVb3aTAA8qTR3 N1Rp1dWrelFfgAmDAVNVPihIqwVCaq7hBKgXuK5ah9QaLEaSZao9vh5rSsaB ImTinhcrMbrqOI9ZLyQjdRYTZJ1lvqud4mW4087wq8H8LBgsnjyH+qWfEVUo tyoeyfx7uORd+wSz34COdkccoH0EPmK51O3i1j4pVcpdhlkqzdBtw+wVZJGb 38Je6oiUNuQVksniIxVErCip8iPiITjjwqPbxmfTp5rJ3A59zU7LJcxLQ0Df dIzxHLmbR5fdMjpe5MEOxjcAc3HeiLDCD0qxe7ALWkY5yz5gf1f2s0LcBgil fMAxZN8T6yO6S+gfMpAZM5JtK+a+ak7+hRUbebIlDiQli9BekitGBpkjg4xG NoPNysdscHGEp4bdh+ExJsmo5CLsucjFgpXFsXztCt/eSIZ0MCcgDc+HaTDn +QNdwFZUGKMlWGp/g5rGrBTn4o8a/8SbURT253uD6sa5X1fEqIUTK2b/3Rwt OufoSIrpzbeqbUPoKLkFqn/2pbXgV2MG0xmKc0XCciQSD3g/5a0F7Vjgbrpn bJk8ubeYBWA0J0K1rE9OVChkX9Phi6Qo5nPutxG8zNQoSHcstFk4Mh8TWvql XSwKrTQiPwTOvxknYENQWrt+kqW1wI7mJRq3lhXEQPTw4DTldwWY1jMp+TpC 9nDpd262go+Oca4An2+YEZEwBKtLuE15CPhR9chMTWVK8lchrdZNL0fSwI7k 039XS3X+R/zhFARLHuxNbXuTlhYiJZxfTa7UYYi1KcIw+U0fhYPZP8Xg/Voc VJItDVQv6inlHFsxfFgRE5UKOQRiaLut0wZqdko8WVtD8hG+FF7rCC+mskCR IF4pwyfpsa6+p6vmXGL5zF0yg8qq2yOznGS/Vgt0FQW3G+LjA+wuVFPmgxG4 ZRpt1B0wfilbMKlGza1wiIm/Sxw6Hzqi/uXCQVVfabBtq/CPLIIByydYBG5W rIbCJVCAReMg/FKpUpuktGxLoLgNjum+4/prEjXxkcNYI2U3tPExkT1b8xxW VW7WAr9EkSgIz3O0fQIvvD+fUbsbr4W1di/+Dl9kbVB8TXmFz0Pvpf34zvUY Yf2LEnidMoBO+7053u0m76UmHu2N/Tpua9VxAzOooR19A57Bv0g76ulHB6dM 2EeHykVt4/fBBqdbyp+KtD+hJMvPMFl7Fg5BXIQwtRLwxtwXChp3DAuzh+Ym 0uNSmD30dTbUm0apnMxd0Ly2tuomGRza0xOXlMN7NKOpve0XAWIwZjtj9e0F vr5xbAuuZ+tY/ZBfeLv+wZhpNbUAXsm6E4ExW9jcQcNsgJJTOCmOlHkNtjCi byX0sTrBB9xvBgSOTFj6Lt1mJdQlQSZ6oRgdXBIChyRHwgc7pHBaXhKtNiOl UDlWIBzs8HRVbRaTL5aihvjImlhlrUgEJKFHFCAOElOnlfLKlh7dESXFykBp GCYMTBw84ECPrfKS0OvaQMVD000WnmZPA1Eaw6Go00Ss5dT+6EvoViPYtKKj veppRUJrhmt4zhgjNFjKdec+Vc73qdIzqDR4co6z95uJwemihLVzjQzSCF2v nDL5kH/JL/KPZ4s9rspIXkC7F6bhOm+47rhf+xugoR48HTv5SslqoxukZLeQ zPQ4Z+9Gz+AGP8CPHck+/bEb+RNbKqmdPYO1Ce7WkBFTqfD+t/MVAE9uS621 pa/fNvhAR4XOj6+2VhCEyZ5RnXY8fRF/Q0xaQzxaW1UwnTi4vtb2M41Jtk66 RQJH94R2DDbUaspo1oN9c+9Ec/K7LMr2buHw0BHCKeH70qBTc4c9rvBaYcyF vfrYAhpa6rPjsm09REFf4W6eyEjNYMrWWPgBcRO0YShhMJmQuw36huot33o9 61WUMV5A6PXJ0224F/lAzwF50Ho17uoxyhGH2tuQ68HJlpKzvqpXWYPpNH2W 2PCGyZJsh4cAhdNPqS79I/UmRO1Ku/QQnEjsKMrmUVjLkwHkFnxk6AVxUZMu rJZl3TeAJJCIT0XeKOWcNllsND4e8Gysy0t2Vq5zj8ScDeVw3bryeSlJ2MFE 4XL5I8d8XYSo5Io7tQPQnUQudHNJzl259kx3MJswWMJs4BwSnEDiLxLojAur xdTpuGHsVKAI6Iv7LDLv2D5WYDhYRorWuUPkkvfbvfa68sbNPxwRg7lynOPz 1RvYQau9MT9g8kSo1QfY+v28DVdsmZ3kgUsaR93asML6dxGWLPkmS8qVsG1s Pe6kvZRpa3JnzrRuoMbK9Woyd0C8UL1/8LcPMZwlnYJvc/S3B9ZAOn2PjpE3 yNIHwicS8R5i5G/4mj4z9Q0JEMP6WXax0YHBzmEH1rNWcGRKUqGqon19o2WV MU7+//897767OOxjE2DJ9ciIBvbXPFXqQ5ay61vKQ8tJcCF81nbqvbJzkbs8 PLjgOYf13tId6XYHeoCUqacTEOaM1oIPhM/6oI67mfYGm7/FyHexZUn+fWSj tutzLjPpyM25xVB1NxmqN6k3W8dBxee+xCaFp0rFuwu23h202vbDwt1Gz7du 1/mCLXpzvNBRbIzoAVfg/rZYoDT9ihB7cMRP3Cuwx+qBmoh/0Zr8X7Il/3ct SbQjhyJNw4dyXFC5TerzLpb6vtAwRMPLDH4zRvt3mDEimpFBf1XAkgOwykwp 6/LKRMCHQQ4cEdC6OaccZhlXWAgk+TJGxeNW6EKtHQwYLSLtGmrH6oIhHfbG JqpDKX1b0dYk5bYoI7LmsmcyET7dmbj4NtG54nZbd8p0pm3AMXEYJzyHV8Iz T7RbuHkr38x8ysypKeVY1AaUu6QoV2XS3CISU4dbVbRvCgtZnuPywCf0eXKp XXXDhEYN5dj9SUJf7iyzktQ0treOipTSSDoB08OYstd5Vu+hkTS+vxrGq0Ms N6K/DDxvjrg6USx7h4fwfnsgnx5pqu1j2uI+tetAp5mHE4JoInl5GMIH9Dxw HbmSnvUa4+QnWUTEniwJqtHrptSPSgiN6TEDMzQQk+DFC3bZACsvmGQvfnn+ 0/gYMfSz8UusBd0VG0x+QbAjJM7vhYr4zXtqs6Grpbl7+44dvWBgbvRXj8Vu Y5x/b0jMjm3QnL1F+B6XYJTtPNjxXiYqvVBM8AKJ/4QNmefSyBNb5HiJVgiw /KwrfroWemsBQCxsQip4ws23R7E0mZRf77Nc+k1P9h9+H77p0eQJ+HYhNE0e 3PA29ojwgOSLSSTnrIp9X6YQ93US9zXRiZqkp5aqBy+P9GEzOHwumnzmyexM 93MNTwxsEfhtqES6ycse4IQ2HCSDZ1v/MUklRRKQHyEzQauwMJXVNlW2oMiE uz+P5Dmw+BHv3sC5+mzdeTYThE+gjvV6Ru6Wrlv9u2U/79pEj8SsyyRzb3A+ xDzsDCGnf0teGQ95UHiGFHd/TgdUN/Ivd1nsqt/tCB2KXuJG5EPgVvWeefU+ aDNJQzTWu32HaH90+yEwUISSqHfkOR9Q8dkdVLxLVLyZhrtFOoKFu13bb+Fh /3c0/n5P5cNLsq9Q+3bOUtV/IqC34LRZwyFishzUAjgbQ98rkci7YFixlYRS 9mFZPxXACLIFO0no76Q8FB4Iu0zBHLndnMqdNauna3panKMUO5bjQdTyghd6 NGh9jwbyKAihEnPaFKAmCZCB9Et4N5hU4sz4T16WLbb5bp00Dpux2b5cwUu4 oyiooFawaIqIR9zUum1DnQVePubraFafFZuaGe7CeDG4jrHjjuhSiALND4Ox c8qNi+R0ME8LPLqLliqN1q3ybdXzpGNXzh05wDvA8G6bxqlduJU16ozA4Rz5 xoO2CvVN9sE4oKrmZktNhqBSiZeUUgjEDTyKBcZ06Hxdr9hF/fy5qsdtVQpX P0Pw/Gye0CxhbDmaNXBMKmQeYLoPPFxDEGVETY9VX0Vtn7get1fKxSxLZAtg DQCpjuITJbNVwlrNijJK3IAMtCGxXO9CG+yoJ/W69dYr2Rx1Wnni4/VrbEaI hawzMM+4v7NAH3Hs6GIr76kmBORblyltc1qvVLBDKokYah+PrAYSq1xsxgZp QO/R82PmG6iR/i0bpo2BBYI1C1wPFYcKGI77ye6bdlpUsLVrCvkFXh8v5LiN CIjqLtY5aMOuKGTS6HKU1npaLyjFwkpFaBSKrKnP12zQoNgi5sMw5k1LE81q N/CjpTjyoc+rn1XTZgjRdBIuajtHHeFASXP7pDEcIysYxlpqUIU75P11Hdg+ /feyAqBUopLdion3Kkne0Otj7TotGtKrvTyPw77SlvDCk2/bFFHcOIlmi/gZ LKOgtM7C9aDcEPfHDPRK5M8iaUA6BlDEOWMueUsKqSRNvjADN3jyrgU2TGm/ scfTBd5Xz/NE+owGQalutQQWVDIpqJeMI0y1XGIkTLbHEmXhnN9dsG6Pq1oi LtXAWdAUiHJps0R2RoHIEx+BisawE+YR490A7deEc9yeHSDZXw4mVYDAJiAo iOu/CVZKirYCL10as5sk6WmfIAuKxN3RaMoJbzzyOHPBBJRk2/oek1R5aR2X g6SNxVs7Z6GOSgH88bw5TxOYzl6/o3I+Z34aXDuJPc6EkooZaUcDUfpePZZA fKWNqmeWpAUVpDt8TwSPjxh6oxCeEORtG7Z3O+cYbydxJDILfI45S21wjCOo XZRG9w2FpWs6JWhhRy6UriQuXynbJNoWmfBwJHKR9OGfFTTsGZAry18SEpyo AXhqWordSdsl3RxcpeNbo8qB5gOm6WbDT2njCRYt5eIjkcn+CHIORsgKvO5O jmEmnJHSFpiguI7R6dhQqkNUPQI93bZ1nbdZSKsTsBs5UxqimIATEacTjvKy ntGsW4hmUJPcMCcgJfQzWsv1Gn6dlsbqUTGbLYrz+hNsbNFeafV4L6DwBMMJ vjaJ+53Cx39iViVHhXKceagb6itOMxhASVpjxSucGQuJDDMuRIN7xtp0gaZD XkBFIHIitz1mVw8cJ2pS5jvgwW18+kUM7+TcfO+vIz0v6mldMbw/lLlwgZ4y ZviMQJQ0YHecqx5hacPN1HDDq85WGto64YYkDSZawEhQHHeuA9QhT4tlOJ/E Xkv4binr6YREbNpjMOvl/w0KVm1T2Tx0pKTyrNw3gWZgb6QkAa5AOnLRDndA Ebi4ZBRmpruM2UDipBaaSVMfzKYPxta85gxA3buGsTTUFv5qcEca01HpJINy wTrZqYnnD2h+bjYYCpmMEheIEdjPuhwaTULv4NaRaZEw/ArbSJnwV9zE4l7k Pgtf3ud74v+EApwtDpj1t8iN0Y5CZE032MbaRz16lpFpqEQ/ouupLyI9H5OU eM74bsZazuLAU0ZnxRwi0kNdufp1+am0n8t79EwNv4QbcCo5ltN0SuisTAsY U27WrfRDn4ElLRHn+H5lwUiLamj3RCcsajNDgeG9tCv5fBkhmaCJOCfMq4ID ZHYn49GoxREWzKULFlxBYnRN3GXVynNQNjm9jwrx9CxwdFjlDGmvPSSJDs8S e95GDRPQ98orWE/kICKqRnRtglmEB7Y+UL2vWD6FIgcbcJV5dgGuzgr8CxDx jYJktfgmnX3kdasr5SLMuZxMc4o2akHz48L8oG8+HjMNOskUxfjO8wX4HrgY 8Ls4ruDTDSs6ixZ8DOEasyHY/sAojpxotsgUQgNJfkmp+DUbd8TlpraSum3K e3ZSBZvqE12f6pKRt5T6k8rRBFJ3LDOMI5DJiw0V6Y09R0oWiXgQryjtPVQ3 rq0Xa0Hpt8G/7LgrkvRsN3NMMbojopigEP07aylwFIV/88V/Zn7eKs8om0hp A++MDkLk/ef3EzmiL3wDkzvTx4rDYh7BuAXfKiROvzE4yhSOESfZL8evnmbP X8Bfu/998OjR/pMRh11PXxwePPpuLyW7/Z65ZfFZSDMN9z//6am9o3/DQXwD kmA9hf89He8fPB7/fPSqf8e39g4idAA3FVcrjoFKl+VW+Qc15N/q5dM4ZCpu Ox8N/pkoNW+xjAy23s81uMXIvId/fyHiQ/+QlipZMdHObLTiG7RPQcUy8xn5 nEQMAk6Z/kwvk040OXaOI8bnXl24klFxsxRLg0HckhhEwvfSC5xSWfiiUZCe cxNAQxX+93XB1JrUNOUQbGAxbAXnUS7IAGPaxEiB8hCDm8OoGtV/3Ol7lXwh xTan2iDe8Tjj7+egA+fudBaQ9NzOglSYgkhzxwJhcRo5/VDa70IAFccOzUYf pfPB55vOCLeRIaqDuiF64ywZbxYqCX39GDwfDzSuPOouqaUW1uYuhBrp20eP DgTOrgnIuPL9bU9QkvmhT8HlZiNejlEvH94mcFtqG7ZE61sq2MG/zX23xual 1U+zrnwna4RlEGEFkqMG3lmKgodfSJsYD8amSBF1lcUdFJihkVlmvVxpicK+ 1HqA21oVCz9UKvbuj5V+nCQT4HCxhO8z3hzeMU5xDeiIaKfZ0KOPdiVbR4P1 G63admhOBi+bjLReZ6FoOE4/LT0ZPbOwpmcmOhlBHFkjkFQuTF+EsKTbxMD5 QBfslS13bRcCsCyY+57fiz42VwZQsCT0a9Sau+pjZHmtq/LvGrlN655kQzsK cXtMEhr4MB2hMcJIk7O+JGmQ840hIMxutZCuTwwXoBinUnFjczb60HyxaUvS 5H5O8mlTt+3A3tARw7jQWkM1GCrrbCzIP4oCb3dNgt0gUZgtEA+Ye99gwx6k ZTCfeQdpcj+XTBRBaJKguNQnLpdYo0Gnnk8fNkVcpr4/CWfmionQpNXBr9ze KurKdQ3+jqcN8XehGYkpNua6TN0GknptCim13VOM9cesWX6XLbUsxAoPPhef yfknsBurzRJfjkkdjDBVXDZ5sYYHMCkss5/HQUZEJ3lSDyua8miy5OyzJ9nu +/Rn1IQ4AQpRhys4DPbwW5977ArMZ8lJADioq962DyCXeKBMvRVR5QpzrwJK BUAjqyK/5NhOW9gVIRb1uVC4UCCqkIQhEggfyn6hY+w33I/cm4rdkXTJhtPG cbjNGa4VBoj8w1OGJDMbu15gewzX1RGXhi+K7ZfraVtaSSn44LEcMbGoUDsk HNLH7MdsX6mrk5NA46fsEegJKcBTJJRuCWGIVNL5p1J5O+ynuvitfOx75m2L hx08ioR9yG1hD58zDdmS7McgxFRjGl5yWDkrb5nZIHRgR3eSPMVhVNeb6qhJ 99YaFLp4IkY8WYb8pRLqicC2lQSdg6gJ79I5cQlowy7R4HbEA+IzDF7Hv0pm yoHpUg3NjWKiJ46EK7YySChPzoFc+c46WZTeEW81MObXSmkjdfhWxdjZc/Z0 sWiAMBGe+dASi83DeevkE6TR9C/F5hRZtTyRScdYtrzT6DNmQOTcDrw70v3A DzXgKDrRJHyGtNatEnXABwvbgbTOeblkxVEisQ1WK+KscbSMjyQMg2WmHSx3 kGAeG8qawedqGMGDmkKFomFUStJTtlIx6EUGvtx0Wmk+Msy7juMEFgc/kJnh fQh/h8h7dnwAEyPBNDSfXd9NwsOUEeMtgA4WWz8+TiwsCJ5dfcdFaQmKmjA/ 68OHTCU6xL2e1NqiI/xrFdvM5A97TxBTUZ/vec9wPKvUL/YiD3ZESUkjsksi oklvdV1y4yvOxFGXBRjHi/fv3546brHQ+vC4ROqUV4vYKkpmi9RxUuCmkUOK muBZZZE2a0iLCqhvrSo83r7UYbXCkJPm3girSV70qi5beCr+fErxwVGIV1Ms ZokQTEEgYOm+GuKUb1PnrR1xTpULffkSqehAIuoBptZst61dUgURgtCm2e6S Wt4g3G6lCrfXf1OIY/2X2Z4hle44H5TyFj2+nVz6GgxDmIGRq2rTmF65zPHL yHe3LUWjM0U669IvTt46b9pTe4HzRc2kVJp8tn48hTjOQYS7NRXqimYKDwkH u7ZW43FfE5NW/ZHAT1Rbsm61ZIwXmeTOxzStXxq3YzatZj/qCa4tKDH5QFqo 6jA+WjdUunuEdMOoluBFp8dH2W4ZtTbQplYc5r7EWB9V6O2xTIHBCMoLbANh PyOznQJBPu7EsaJwHOAHhfa7ep7mTh7lidTwOn4C4WtD9EEOa6Ye8wEHDiFb QSfUj7Dfm0wbfgfGl41swBnjPCItlGPlNJUKSaRUJ7V8ZZRL8gxw6Ak8ADKF DCu6VOYKmBH8JgzslNLwEqeh7CaGZzB7r51I3KGJLW0xUtGsQBsITg0UORa4 EQbjxrJ+A10mpK86Gn1o2SnNmm50NUwCmDSKSr+pxqsc+4AjYgVRmT4fhblW rMzkyGCrw2EIlXriyMJLTX71dQL3dDgcZOMjkmCfdjY1eeI4aCUkwvskTM8l RV7gYKvn2NgEPHwS7VDfIWscklmuy5uLQkPwrV18VaI4FB/BlNAQ3UQIpxBq h3VvGGNJBzqCXAwGAHvFSFtX2ddDa2Qq6JwcVVgGAX48nT/Zu3eih7Hwibq1 jDzAkzI/RzKpqMeQ8DwDc728wDyqouUwtYXzPF+sBbMCRwx+Kwec/TgwbkNA TLI38EI9Hdyuz7YKTbK3FTE/LSNQ1Sp1FCi0BLJDtV4v0Ig1La+kbIKjK5iP p4sou7Fne/pkYI+wLmukkyjrjoqhZqResVVM2DcaUpUMHA76Wlpi07NEOucN izp36mE6puITfJdp+4bdOqQOGo4ohGpNsnc0HsrF1/Yh9ATLThNcNkd+ImJr G+qBUAQ0ptjnbNwPuUJkwq5bR04NyQDmxRhKSFFDLDYIzI+Cgxx0x7iJYx27 kpIvhe0kvRnK6goXi8diiaEw1OPEJChxj82x1MovDwW+r7QDXHbCbIrZUQRr PDFMmTia98RQ+TyUgn++l9IwOkePkgi6eZZl3RQPRhRxWRnMJZ8GXtNVW8Km yuPlRYWbeFjLzeu54QimnBh3Il4QNzzkjXV8iBRxodFLFhq9BM+0HPRcPWNL qQTs+nRH+Bhf6pSQggodp03sGOfPUC0Jexs6CchnGLElRz5zdhjAcyPG5fRW z6Wrh+HFojmnHrS1twJSPwrNPzmENnQbzVfY+/bQ12gnDGFSTEaS/rVdKkxh t5ZaB3JQ3PxkfnokG7eZBcOtIykLUxjmXrh0GVNNZ9y84PwzBwQStETIhVIT OzWiSNORPiGuJB9y7WrHeorCojX6o7SW+RKxG2TbclMNCvHIDHqI400sprKa u8/38AiWA61PYNrDWnhEI+t+PCO4lSpoAKY4sCvy+R7xRMgZSNviCzfT65Ul WPiQErtt4wDE7tKlRi6cJv608U5rObpsn3hqqiUhoS2P1p4mZMiIRsBwLlpw +I5etax45ZvAlttRJdZaYV6KBGbApR3CUB8DCyuSCrgelwal7m0+i0QpVEB4 aImZUuknJkWD+PixoglcVMgQKZj3trUHg1a260iHH51FHx1FukhVksc6+4AP 2IkkJTQO4rDB908OHn75QjaO5NHpAVTXxuleX7fge054k9m24b5dFIbWIf2W rYsRLSyJwFYBk4yQ0z4JAfaOeymgQC1LdlnF8FCMeSQhRCfxPBpBuPjw5dvX RIbdMtJHf27y8fbhzuqG8CI/Vt6jmKkRcLLCY/LWbI8ww1RqqRd5WTOTMyDW f5ImNrQFc8o3M1pIUFtDCzPyNMyJSvFkwdfYbUVDYVj1NJLGcapnZoPDEVj9 hvGU3FkjIvPt1VPy5fJssiCLtu1z6bgh6lUf/ah8lXFnCh+lLpu3X2u/1PH+ 0+okrwPyxo6BKdBIYZlr+CYKHqMKQfcFa0EUPhp/LilyUyxgNlP0uZO4x6+n qwjRDDOCgYn3LX0d4ygZKk+VtcFFw8VMtX5SrIGYVo4gMZ9srhse8cDFYk4z RBFMld5tMUoxb2n24sONZjQ53CIhtuVzcWa2Lz3m/Oip0pFEBMGhI7DWJTjh w0Zt4P0oPYhgkh4YknRGGJHCG1oJi91kA8vw3cDwJ4hnjQwFyYd0lBsh0zd6 G8JsXISHEnQH9TYmn9W/WMP2JgJuKxkpR8CL9I772nr81MsiB1/Wcb9UKexM glTc47zKClCEDIExr+skLuEtskmod6NA8CYQPuH8g9HMZm5n2mwcGaC4lum6 sBwYu4ibkfz3owdP7F3YZkP49gOA2e8np0ClrsnnhA7Uxt3aljBA73Vwk+yY T482hFf4bqoF003bcGk3hzThafVUPT8vH0Fu3xydvkVlfPTupT4MlbNLHgL+ dknNuAYfomDrzUn47SEFrumkhcE5KXwVtp9I6sI5o3NBGcegeqxgcyvjFsHn uBikKSi2H4CgiUiLyuOG44uCOxT3DFmaQOtPaYLqGDPYtNSExqi5LMzIow+Y ynz4mYuXHuNRSKXtfPCing/LYJhX4fzgkgQ/S0eHmdBggqp0IacFll/to0os Hk3ZfkxLSjXTwm+xh1JZjc8Fv135yJFVcSENs2awBklP2+WrBUHMA2rIJ7VZ kxDVo+2FzHkXIquMJ01qdHq1Zrq6hxJ2pkVTfk/tQez3EoraPGAu/O725cTO hi+b4jboS2wT59a80idxV3ujsEHdozvfyMkXV4OTcFAfdG0ImdshdbW4qGjE 0nNy4uKMH8IgD+9n0x1ysLau0wZ2s4KqzW0viHFRcfmceeU1pfhngrKid3ru bvlcY7zLjVInQjIjySwDbaHRxygMqRZHjq/WRRWJB0lFogBeOGmA14sdYLLH bbCgwUDrc3skjbixYEYN/AFyrey3y5JR9c7nx/gApbdvvdEQoceArPsDLCpZ XI4/MVlFNerFgeDXeohdwuPXmj4vZGWSa0D9Kcm+R8uurvDL+QhCvTdggA4d Ms49SwCcQyAoY0gOmB9lZaZOvHMfSbIU+6aUGEtQEA1xvqH0+GKQr8VR+JvK DyXtJ8bgjENXNGfkXZzb0BdJoiykp5fEaaCTRkpQLJTOsNx53jMvCJ7AHuNr 2pIgX9QXGNqi/sherDGRgY7xowfff48VCD4+ny4IviS4eymElmLoTkVCePv1 Yh1Fq/Xv6BLo6RJ2eI81Qj7LVh2tpHdNhNAdku2QZKDmajI0m1JjeupUlPCu +IiCdRIaPl11Clv6ePVghyRa4UC9wRV37AP52WBdo+fF8Sf4Sg7UHQYypCND qeIcHJ9SBRb4km7jMjMUZkibtI3CLBft1aOc20I/Nsl2T4l0KuVziaAXe7x7 vIMFoknAFKFYKz/CSX9Z10rBMzQ67NVVzjwKHu8buCqK3WTSuxjMYY1tUoE3 HDO633CCiKtUYTAijYpaMa4zjqspllLWefBQ5lMBMEVFNkeB+d3VJipU5kpf bnQnGRuwq3Ow19Ym5Ug9TnhQXsp8Eee5VMbKUXddZ4/H+H6hHQrpG1IgJZbo V+OquFiUFwZaxw2ic4qptl3gJwNBQgMMwc+rlS/6HspJaD1u0SabNtvloLjU 23lSVlJw6EwXs72noqBcyqmX0BSGJQc5wbm1/KopD9jIdZdxZQCTC1S+ATPB d8lyCfvJth7ItUdJSkHrP3bW01BWKqL1IQGcgxNROHJFKIZAvOgoNaTFM6Zd MXOn/dj3UZ8d/N/vHsp6SUChdS3CVDXROfBK9dH6VaekIjVNGHGiemmx1Ibb yB+FgS84RC5gdI0jm5LRDfM1Chkdx3+dd359ykxLXooIYDNUzsAiQGwLzqwu fHKP4dPw/zSEcDoUjMgR6kdQ285ZRJnENrWDcgQ+o/KPCLkx4XK3UJ01yq7R vx1LkzVJoEVPoaqYtlUWVbaY8YMMEKZYej4XOYqO1t0YicPeYtZIDw3nTinn lkZp5LzqZRViXk7pqkFAfel2vUXZE2GBmoQjbXqAlVuWKiYpktiZrjsKj61w yDv+YwNvkjERBMASUDZoKMbFyQTuGoh74zQdku/8G+gMEI5T7qYKctcUnVbP CWmY1iUTPIFQQqgXrwowAOUr2mJZjtGIAzdN0iaYvfdIGVuGGkiX0Gwg00XD xGVjm7a17pIVBwdzcYfMyy5EFg1gGw/LEkWkMsUhhNMmRycKntq2cKZDC9l9 wjDAvjKarZKKRLWi7x2RccR0O9RsilHx50hIpMm9ULyNLpdmJsmmioa4ZVLm 64ZkkfON+jp4mozdMfXUhueaYSVBLAyAzXIrpEhslxicYd1asbFzLoFD3IuS Yb4+GT8jCPLzogILYVzPx6cCn/Dby4qOj/QZ7iOd8aF0MZ9ecXLdmSD1NG+4 bJGpamblBcYXdNnKPhVTsr8oi2xbw/ljvU3IiaR7CgOc0BwbXl8ahwvwOovZ yONiDXxXJRP5vEYO0+yUELugU5CyLw51Uxtyg/mNLLGSCQvMYYbfrOGyUQT3 JRDtckk7GNdvKJTacvN1YfOK6xRIduU1LsipHD9efpjJxXx98NNM2VJDloq/ iMmR+hdS0IspZ9CuU34gQzeGRUZLAv76mmiXYLBhL2n9qymaEKK6+pyt3uCf K5tuyH5ycuIpt13F/dCGMlm0FZSSaZRwMsH0/4ePeLDV0xRMXsZ5Ux1i8k2I SM0ILa0DZ1J8BuCZHjseJn4TgN0g9hf19RhtVl5P2FCoAXIlySVP0dhHRFHB rGZ2dEtQRlP5GIar+3G4GK7usZgeytZtBc/HM0IL5IjyZaHhfIpPiwoF09NM Q9n6wQtXIEU/mJEE7fBQ1LwsW/WnRkLjJd+Ak96qQ0JEhuENUgCBBpMvKbGv lOJZVT/0lR2aMBfc1Eh8YgPmc3afSlWAVAiZD7vmM1kGxeQQaLPALrsq/wH6 K2y6BSeClV5kcHm81vI9xo/R2+L5DZt7y57WalD/WJw+M1jMAwgukckTVPOi YxFH7TUaRzvQbiWPCKKPQSdlGUZB/IkIq4gPyWuqQaoZIR5Gt6b2L4iApipU F0YqKj2imPDlJuqZ5lRig0jWILALMEIWHBamkVsiDapcn16WcEmGX4+DvaaP 5CeSnZDkLnhd3XxRfFKqCeLl4aeABDHFhn9/Wvn1CuPtDMnyn01dtiM2Rkwz +HX0xYxm4aiGVKvOLbgYme0CNcQ0X7FygN+FSmx/sHkAPKGRFRpHhsZLLFhX WJTNvqTP+FhgJoEAusEnY0gsei69Dl6mNaRj0l6QgMDnJYBqi6J2punHNkFm fkiZw7YOjl+YC8GTwVzzToH/B9MHZncDhkCz8R0d5cMC+A1MSM1xmxI6ZIig GWWPGd1D/gJh/RGjx1ChawgWLX3fAxcxvAiT+0EfJRAFU3T8A2Ev5dehb1xg deBmY3q5Vt7Ba67oBLlC0eDjwQdlIj2BuxK0LxqElG6ZGJIih4oZFBl+PZm0 JKOjeG7DRHgicR/EGECd/jB4NQMjwMrxv0ab4Epo7cM8apkO6pGAC4g51ekR CiaOij7udLdO+It37yjQy2HH22/09bdC4CSeggKiiNa1rVeXKEVclJWoFy7/ oKo5PX8sEG06QMVsA0KBcY7li4DHsqMM/KlHT9dT9fwVdgjo/lgZCSm5lPaH vHht2/IT95xh33S6SXxTVT+qwKVDDWpPvNrX2JUpZsTZeIlP1waHL2N/dpLF 8SuQ1RkounoeUr6pd4D3L8o5gXjUknp3fPTm1avj18+Pn0fJLmdR8U1xwSgE mYJjSuhlr4iwlcm6LN0N4cLi6VhhFK4L7laoBoiC/+IK0URZc5yT2QzKH6xy jfGctjiQjWefk5WyyMGH0EQ2BdYYqWLdeq2TUlD18HvBVpU/b/5ti8aq0yc0 C02hEakApNaIpXNHSOfSgCGw8Yki61bToUaJyJg3GP17WzCpFShYUcLlXiMH fmI9F9rCoQ/ZtmRCgRfMAEZIxeWXnEkgJaFsaVyMT5EPvZQobsDBjNrIxWd3 qIxhDi+KcQyst8D2XES1G6q24zu42xqSBGos0mdMBpfM7tBeeZzJclr6RxMP tM2vlaibXo+lOxLQELT4K22F+lZs5mRfXVJpmve7Y3KuRb5h9DFb23rMcHZO gDKEaLIh56am5hWjoW/wfS0t+CJGT1h0TBT9UAp8ZU/3TV7tiMlw0JiFrzrG zN4mS7ZFQVx0UUsSgVHwzOSG59z5ut/kIQSAtayVMPVvpWHJW2K2Q7BeU8pB IVZOMGOGcmpCVyaJcXTOMPvqtuHlohCgboQJbiAeB2ET2JvGZjxWX8sVCf2K L2opl1x57iM0PoEWDWbBLI+SwGR4G8fMNGBd9nnLwpDIs5MEVGAZN750Tt0v aYTTlntBUX1n67dERCvF/QbQSQsWa8v0rqPIiEXXouYaxMheiCr5jCXAJwRV vStlR3gSVVFQlFrDsMPr1Tut+5h+NPOc8kTcC/Wc7wrmPexPbvb53hxDIaJr Grnwi9JM8PVrzbT62hu9kFExIVsW6x2K99VgHC8E6R4+W1kIKRZTXJQYM+76 RbJYCO2RAHnU28sZCOLI4hH/RMhH1hM/gV8ITsXMFN+Q66jwd6M/tE1qaIWT 7YBS7XYGyZhnNWZyBXxvUdzEmYbwbGdUtBy0kgi0iEtir2QeYavAsl0knERS oNnA9kVzJrpaEzZoPwzBZ/c4/eynn+RNA0gYjKeiPTMsJu/J27CyXEVVBVx/ 28v13m/jhhYlldamuGQQqx15yAQ082gnUw54PzxedWXGjuYL55+WBe8N7PIe uIW10aStovnRLt3s0ukZKntRee6pflCTpLimXNpMfFwuXTc6rckWCKi90Zad S5OJi9lym65AUxDFwpntDz75sl70BIWFOrCXnAidkdYVGrAeO1TcVYlnQXav HT9/XMeYZjoFXGipJYmzjwYRED5sIi2KRLds+3Oonxb/4R2MIQrrd8A/f4/2 /gdOCNE/sS+R/hnTnz/yP3a98tgLv/xj9t/Z7gxU/567uQexUSE3X5gMKP3z eaBz6ZfBC820C7jrd4MXDly/5cLPPcEYuvAPPGv4i0OU+/4VMq20np+fZnwU zMr8osmX6ZEAaqVbFD/uyLL7H7MI73xxW5O+QsqmXQMYrJLGr3zRp98Tzvux VGos/CAUTlJoAzf4FvJP3vpsFBB7vek3hhom5BjIscS+puKxJJbZACDehrOF 5VlYncuFzd8NaffQJzpyp/B47qMmX5R/Gz6gL5tmfEm/TM5mjdYWjPtS2xlj LBwuZOZlJX9Dd+0qrkYSiOTWc5iTUUpTr8szFqKTRcwrOEFwGXWkS00mc+Iz Y7N0et72Wt8afVv98i5oiD1T8iORRnWoWQ1K6gNPBPOeLS0HQZ+D6/DOkAJo RICTCJ2PZwpSOPlGSyx3I7+/bXDo+WRFREynjKF+wtTpsjf84pNwMnmOdQHk B6gOy0WE+LWimsRpk74tjgE8l9yyyruow8PTgA/pznAxI4rd7oAE7aXOVDw2 2dszObX0aHJpKTiOLf2Of+u0wj//CydWtitytBf/GlTv1hEN/unDhL/ufv5z y8lm/qRHrT9Uxrecsulc3W0092+9FKb4vvnBvziN/OfOlsDW0dx1Gu2fO9sN 2+7/SnPiDo/5uvvvZnzc6UnqnX39/V4Mt16xqz6RdgtaoFGwN2zrhNNVzZy+ ipXfB3snQcMo2ns2gMhnLnkpSUaT47wGNW33iE8zbUklYoxToX7yINB73HAM C87UDgp9ZXIBBMXsT0ER910zrClLwhMcRQITolytFwqP6JeGMGsjWV2Gi8ep s6x42FqbyPiwgHQ29kgR0+gmPmSsdRkw8FwJNN8yqpTLcplflFURnxwcWc8X sec6GG9JPdcdn230jjU8kMWkmN3VFTa+7KEetsKyd1lwARgmjchO/fs6XyhZ pDQfDZj4iEVUTn9OmPHhHU07Qmso5pR671HgiEf5CrHDCobZFjoim2y8NJdu sVN79SBsfVJuqiOXwBs/gw3IbF/nAVPUCBDOUqDysiktF3j90tLjy1AsHsHB bquRzwwrgv+IPLOFAwPD7RE2SDMVzjQMFF8R/vt8fXHhaZkwlG7B6jkxJqb7 aOg9XQQzctsMd7bxyBDIp50PxYU9XZ9TTpIZdpif3iFmr+givDrFmDhsFiKX 0X6aZC9zghITqpbap624iUNvnljhcLdn6okVU9f7BBj4aKHknI1iHmEmI6Sv GSgXj5oWRtT35ivfnv4iQbRASxCVxWurQvYT4bdwR3aOvBENb2/v5XBkikC2 vag+0xnGc8UZ7XJBYCDF3ckbCC0dWvLc9MzA2m3SVMoxSBF0JxqDdHnBnSNC TbBXcu3Ed67OskFr+wYTG/+ImX0nS8AgGlEB00re1YTozeRdb1STA6zN6Cut Adk3CclkDa+gf34gTMaHAGcBW6Xgu2Yf4AF7/t745wMjHd9qARsTfus1dzHW 72LtJh+75YK7fv7Q7fGVt/kL9s/tM3Xrny1RtDuPoG5usFe3//l3/RT9M5lM /sX71U7/itv9bvEGd7dot9oKanW/khwMGhba2QYvWkShodT4lqJatnwX5T+0 WNscgxoNCgr6ipF95xsXaWw9mCg9a6iOmALSG/lRMJM4Q/GI8GluoQ5NTuFe hJTjgzHkgDCi1Wrd+T466V1u9xiNj2I2+Lj0pNwL1W/khWA/KQJKgBETv3pM +5IpoBErYe0gPUQJU53aPmjnn5ezdjvVINxGgwkurxw1XOPIh/M6YdbGtLl4 LUMUa1zpBYbPSnq2E2dLv7DnEBsWNPBjuKtTMhelFYmRr7iILhxuyepIAGyH 5YV6WxoSRQ04Loo52yBSGhrZrlfrRSV93DlxyuXUa9/tLdRyJlY4L/BbbjR1 iA3N/KgjkzxatjGccj4wn1LxEAljuDzbIlTEsuUJDUMKETfdtMnnVJTKw5I9 Rvy0xSeUF8ytI48qUZlIoFze5+pGNy5B+xeYOzcVitSqm6AD9PCnzv0OrTLE phMPyCpuXvom4X/iUVCBOHPw+u5Qnnc3M4DSkV0yGqUURrHYXweyoDe7r/7n d6/3hE2XksnwpFdaKhH3qLyBRwqF67XcBQ/QJhfpNpHP9pGEGz5Z0JHTeoW5 Uw9yId6skcvi2hv6oBRKlMCuIl8k5xVyWV8qz5WShyFcdJ0Z18DX43DgYwXN 8pId6bynJKiI0ntW+PTX/HniIlI7F0Nj+n7bl5hsJ37xm93X//O7l3vg3S2Z 6gce4+Px8NXw+9/Dr5Ej5rqcIcFsjMliwlTEoY2XxBuQ4xP0qS2dQLonwpux /yKmpOAMET4RXvqkg9QtB02g+yfHI50x7C6vhxa5qgSDHvHFszXjnQrrrdId XG0tRZybzNdH6Xu2cNRSV27dYC0KINYNCLFrpIq0WjcuYfWYPC3X6VHPYT/D k8PXh71ehtiKgTpnarQAD1w/EchJlb0Dbxakd+McPaFslX2HZx8pBCSiFeDs MC7PjI4hCG2W18izqNVo/JrdqGNRKHPaY/z28Jm4++DTvHgwkzbH2Y7UG+8g T8F6WSkgHRlIuL/SDtbevHj3bpQdH++Msp3n2N76DRxY/ha+Ntt5LYGpnXe6 isXMXkT1AXDdn4t2hwoPBm1yGN/swQMdHx18N44RB7gzopHePLRtw/JjCmE1 +my6tutd+abiYAdIXsu0UxRdezHZ2SIbZL17mYCjklxu4nO+QTqIAQuuH9Es aZxyd/9gf2+rjFDck17XbhcOO7E8Yb8k3+h2/rzD0DhUCDFvtZdA+0GMvB2H RRyXYF/c9oFgtV5nOwHl6h+9E4SewjtwnSMZOE4aykm59S48Y2/bONsd0IiY SH8NT5HnCrQRM/FMed6mxSWg9ritABaFEHXhU/eU1Hx3XTOBRah/8Ngs/y3H wTjzVSeu/1vcxS5s6uw1HLT4ntd5oJfp3+WcEWS8/BDEdwcjdCDmPvLrec0E Mm2OxZbE8refM1ON6pmownXnhRI4E/MZk5uSmJREDsvFOXmo+sDXr4liGfH4 aLh1i01Ye7DnJHwqt0S8LXj/n3dCkfKpVJK27pDxHszIsH/ALTrf6Tmi6xIb 1FymNTx/ptcb00q0NIkVse1s4b2lrYjeZLuig+jHHcL2Tjt0CUGyUvV9i1jj +dOuz/Hw0+P4NBr/O81LWInVxtO7sp9hLjw7hXs4STY3XYxDSgpTRRV8H4gt 9r9H3wv3qvtLix0VMM79DcKs4e9i9tdkbzAVax3Ovv6n6kbbPKWQFU7y04yW qakXXrQZtUwTDfJSNFrmGkYLQ81wrBo/eD94119kMv5qvDqNx0azWrbyHAaj ox6/AhsgJwi/FIe0ayS4KwW1wgigCswuZAEvuvFz9DzkKbsMY6SaZnXbKiJJ EC4An/yAAe5xCF0J79gv5+do02wtnsYSlhlRrs/WJC5oDKNPul6OsK8I1VAh Sxi1LSu6qZ0emRPic5AyHCpBKIk7gslyy+K69V2MS+nWDdtQHiP1tVJI2lGD SP4OUBXYOcdWuFok+XtL6efp5ZSK5F0hdNSm0V+vB5LxXhzXTvr6jh0qqQYJ 3Empg0GqhcFbLyEd8Z68uZIqcz2+xdc5+c0ofem4Mag6L0082JHz+2rokBgZ cuamWBUknb7fkd3D9jh58OkB/BnB3/uH+4f498HhAf397eG39PfDw4f096PD R/T3d4ff0d/fH35Pfz8+fHw4cg8+PTl8Qv8+hD/497PDZ/T30eER/f388Dn9 fXx4TH//dPjT4dDB8+749Pjdn46f946YP/c0rllpo0V/pqp31YaTbRpzPB6T 94FG9ksy4sfkMbNnGcb1lt1gnOzP99ja52CRsTW+8EKHZSHfeYYIWfGiBYW6 M2RumkAKEf8MZNjI3hJXQ1rZRCXbssbe9zGkBdt5+j3HNrV4RRIEmlm0il+C EXbCVcMkuxpX/EfR1OK9nxdqjm5z/d0wlfi+pKZzy4pNLYTAvB8NhMtYgVMo 4Jjz0MORttEg3NBnmUiv7JSLRXGRLz748OSOAKPJ7lbSqkzb9fAqTmQEXK5+ klEpLKXVQCG99rivk3FnP4kb12b9uY/BndQ8iT58yr5hdjIJX0wvo+Q3TvXr m79x6PN4DHf/xjd4DlyXrZDi9b6p/znEq0MfMQELeCWpmtLLxk0R2/ijsRAG 68bBJWbUZttT6E1+3ep4rpAVgcITcMTkEqD9z5Px88nH/B/ry1q5TYrZuK1K 5N4ATcktyijsRoeSViCHbLdC5MvOUx0JsgBr/sTQdoY3JZjJTBr0DvQwAief 5XBeg2I+umzQS4L1eYFtPpf5KHubg3ZCsOv0VV6tQbe/Ak1+CUbc26akyuDX +NvT9WJRXuVgwr/CPH0FOq9etloH9jyHozV7VlR/wx7TDKFXViJsDgJygv1z eG40Lar8S8ScCCMj4OTL+sK5P2a/+x0aO8czJIG+37LJ9LvfZW8XpFBhneor kRqtR/LEt2zN+PhyDk+bE7REi601xmsaTZ9Qzyhit4LvVCNdVAkHSNAtCrUQ MA7mu592NXJRr9hDZP6uGVpF47Lo5mPMthSw4uP970DPZ78UxWqcIx3ybZc/ wsvBQ8iOjk4PHhwcBJXKBU3rJTUu3b336Nsne7c97OHXvftbvJznHo2Fckkt K2UT3HzrAQ2b9ALWiPlAVxofg3HvP9zDi0/46Vu3JtlNzMMFNz34lm46WuRU h8FY4NhkYpqN3XsPnzyma48/rXIuZw8NiQSdRVbw0hcftnTXPt3F2b4xVe8Y Sjrh6wxaSFga4MbH/19hV9PTMAxD/wrS7lPSfLQ5ViBuXLmiCRBCGvQASPDv 8XtO2qSt1EumdbWT2Y6T2LGtgLIxkGV90qSd2FuWIk6rOHSdOHOqEdieS34i IJON0Mn3A9sgbTD53yxsWbhCCLzlB0IkQic+SZFtIg4Dy5B8Wn7zbBV7j9Ya tvZQoCyG8jC1pW7maMSsbMvOAaPzyrfxisBMMDqnk5Cfos90u15+N3KSL19p 1haBpeblHMwmHGLoG6HAnftVjki1rDLWcXp7fwZQb9b0/GgJGknKSCLGju0x YQwJAwcFRtHkucQ42oQKN8UugO46dtG5ihjYIv58X2rFvhVFgJLdPqngUqCF DOvFcRzvarkXOMd/6LvMGjh7cW+egbZYwdpkZ2Sj8qoKz17XG6v9LZo5c9/1 gNEIQmuqzqvc2bkS0YuouT/e1mHCB0RFPbGG7J4rBzds4F/RaGI499ABhNzb oBIyO9nKIf22HITkVaMEfMxx3MtL53JcOuvaQp8jkTsgD7GF24YDV51Y1RLM 37m4LubSjfkgCOHBy5s5v5LRjhx0FB2XyE3Ka+DzEI7k1STgv8fyCMcXPdOl mA5MKyeXlEGc65ojTT0QKpu6Fc+nTb39jzrjr2oTVH0rLKmMg4Kyh0Zys7r8 bKq/f+Xc9VWeHozCNjOcOZd2a3ZXUccCRp3oBplT/8MMB+yehAEAH4sIAHnyjGkAA9y963IbSZIu+D+eIodlayK7AZSoS5Wk6q4ZilJ1yUq3I6q6 pqynj5QEEmS2ACQ6M0EKrdHY2r7L+XHe4DzQru1rrF8jPCIDJNXdP3aXZjNd AhKRcfXwy+efj8dj19f9onpUvH1+UjxdTdvtuq9mxfGirlZ98WO1WDSuPD1t q4srH5k101W5hGZmbTnvx3XVz8f9ohtX3aoe37nvpmVfnTXt9lHR9TO32ixP q/ZR8fDBvYeuXsN/9e2m6+/cvv3w9h3XbU6XddfVzarfrqHJZ0/f/uA26xk0 0T1yzWnXLCr6T/zkUXHn9p1vxvCzabPqqlW36ai1ykGH77qyrcpHxcnTY3fZ tB/O2mazhq8XnftQbeGT2SPnur5czd6Vi2YFjW2rzq3rR8Wf+mY6Krqm7dtq 3sF/bZf4H392rtz05037yBXjAv941E/belq8qbpp0y5KV/BfvYKuPJ0MPm/a MxjUalatK/h/q14/r5ZlvXhUVB/af2v7+XIybZZOXzPfLBb0Kn24KB49Kv6v //E/iv/zf/3v//f//D/Cx2U3rWEAP5V/25w3xasPm+i1P5Rdv9gmb/xAzzYf Nv92hh9EL+bxvaynH4oT6EN9Ua6i8b2cDD6nFx3jLmnO2nJ9vi2OYWk2i75e nRXPnx8nb1/V0/NmUXaTTtr5Le6enV05Pm/rrm/W51VbHE2KX5pmFnXoeJJ+ TP05Wq8XVfLmaXn5b+dVuYZ+ndZ9N1lVvXNu1bTLsq8vaK7f/HB85/Dwofzn tw8PH8COof+G/7wtqzGru/WihL394+ufnjpXr+ZJE7/++ushPyuH7XvpyeOm 6bseJgn7kD1fdLyKy7o/L568PClOqvainlbF43o1g5903GjZnlX9o+K879fd o6+/vry8nLTz6bia1X3TTmD8X2OfvobPsCf0m65q66rDj3VLQT8fFf77onjy 6tmj4vD25PDbew++/VpGQd/xuXtSTSs8xngA79Pn/mjQ39jvSVqXx7BRpueX Zdv/zX/RbVpe1ME3fr8Xj6vVX8plvSpeDBpI3gAPPK6782Y9bD/5PLT+ov5Q xd8mjcL5fbk9a6vVsNHk89AoSIMP+i18/cuPR29/+cP42es/3qO5MdMkL6Md yo+5sEn2fn7zHLb+s9cX94rXZQsrtucyq71pF5NuXU0nl+dlf3lGy/0VCMNp tQZBvL64N17Tj51fuRflFheNFhOkGjzbw06TddvjfhTP6wvckycoHct2tocj eXr84/hoVS62Xd1F+3nvqDjZLk+bBYhBfaBo5sXrFg70dFvAgaDdfTi5y3s5 f43s7dzO027SfJyU08nmw9frqoGz/DV0bwq/nEzPq4ty8fV6c7qou68fH/8y nk67O3cm69nc7NaXzYXfrXd2nAC/4w/v3f/67v17D765/c3k7v37D+9+c5se GUxWsXd8fFLcunPnEQy1mVYVHUoceX9e0auKo+MXxcmzP5wcHaMYnFewKeD8 Niv413K96aFHMMH4j+UGJCFIDZCVcMynm7but6NivZ4Ud7+5P7777cO96w/Z T3AEzmH6SiOO9b5p6zL/oz9OQKjiHN74F8exgBWJv2g2s/kCblyVkPcePkwl JMiw8dunb16c4DPPxk8mfPeM123TV1PYD2NQGNIfvX7z6u3T47dPn4xPXj5z bjweF+Upis0pyOvf/Qv8808g2qrZn+GqlQnu4KI+gH+ewdbFbfwncwj/PILV gf3Z6sO3OtokBXymR2Pi3sIC4gGEnl3UM9iobQWKx0XVFX1TlMW6PKt4K+89 hzu1+Jn0k1lxeEfbuL83ce4lDAveVvZyvLW5rtiDq21Z90W3KtcgfvpuT7ZN 3RYLPnudnL0Ot4iDr9qqgOmFnXtRteWiSFso5m2z9EPg3uE+XKDm1BenFTZK z9y57fxIix/gcFYfy+V6QdpUEA/7V4kYfvnYv/zrw9MHpw+m9+9Xp/dOq9nD +eHdh9OH5b27D+enh9PD0/n9+998c/rN4cOscDpw7pcKphhbBa2oIHUPuxuv FM49jmjZwHjgiLQoOmAyUFnUUydyNJFfI2gEdtOU2+Sl9RO0bGBWz6oVzSp+ I6/RBbh6Jg5GdITLGe20crCye6ZJ54cCm+OYB/DIRbszqHJ6dYxyV8GoyAvq Ea6fbQOXclT87kuvi++hg7OD4odfn41UhSn2E+2+u5iejqvp+QFM5WIBG4zX DY7BDMSXzPS/v3iOE3mGI3710wSO7/fJqX29qMquQtFStT3M5bYQ7bwr9k+r bQOTCzKvk4MEylJVtvA0ngi+gA7ogtl0JFev0II6+OH0fFJQF97izgK7ZbPE TQRHctrWp3Awy2IJQypXdbeElxRv23LVrcEQKJ6XW5DWKpqLfbjQ6MWu4suM V/+90dveQ1Ndh5JiA5o+SHq8dGC7FnRZTXGYE5Zny3o2A/3UfQVit2+b2WaK F0Hx6asa//nZuaMFTMHm7Nxfo58+/Qssy4N79775/LmQHnR8MOQgwBhm3Xn5 oRrBOKaLzUxWxEknpjDb9RzvnAolYipdLstthxNweQ4KOqwKzC1sDTgxZd+X 0w/YAFwysHTtCqQa3PMoQVX1hb6Xp82mp47A7lpVNKBJgWIVziEMq/rYkzoL Db0EtcmBRST3X7EPcv4AZBLctHSyoRfZaQXDjHsHvfjQ0btYeQB7FFT8FW2L sjgDTXxlejFCSb+u2nM4n0GcoPFYo9JuRwHjm/ewepXXV3BL8BJM0j2Exwom lPbQqrqk58IgpuViAb9PNR/HGv4+6FYHssHh35ddMaWv6bqRt8vtEE+FyBV8 F6/rpCioW3Kl8ghhQklINbjOxbpBHaaGF23DsB30fDFDW3eD682/Q7NJVmXM +x/0HLCNm0XxEgx6aIMX7Oj565cHcG91vfv06V/RVLp7+/DzZ9AsmvGimZJM 4O51LHbRWoencdpwikClxs5c1F19uuDRwBPz+mzTikqEvT+tzsuLumnthu42 azyd0L7cA/zotCYLsdvUfcX353lziUPa4kW+JpnSYDPNElvhyTZ7BOYBNwHu +3LVrLZLPPJd1U+KfbzTHa1UjXcmLj1PkKz/tACDFow0M5VhF4BUq0g04izw XnK6m+FLUHpwDvg2A1FaQhehn3gxtrPxglYAzhVK+hpfAEcQxwPGNQrEWT2n 2yU3p2byKjwOeDR2rQh2Kp7+yUHxMwkyki2wu4KMbKG5ctHJ3tWZhEd0Mldn TlQmkDfTDWiI9GI0Y0Ubgj6dgqyYNTAHq6aXJuVsi7QivQV3erQcBQwTFhAV nIGoeQIXfrOlk4kL5ZVrGYKbV2W/EaEHuuZ003V8vj99mvmfwh52Ds4mDgi7 Bl/XfVct5rC2c1hrGiwMT04bdaJGrw52UASxnEtSKVk+FSKflqBqwdw1eHXq OvXnLQl6Pqo4y6tqEfaSC9JTphr9An/dkDWDO0jbkXl79ho1E9gjXdVNih+b SxTvIxcEGv7cr2bnX4MfN9jAj2/fvj4p+FQ/uPfg3ufPo8J/CTvl6yd4WuXU P7j/AK4jefj2Q3oYD5//wX/7+dmxfP/wzv3bnz872QO2D7g3jfgj7QTME2xk gX6qtai6q6pHtx5qDmsV7Xj4l6hDBInYFeco4JfogoIDK5PfOThltDxw+5hp mrDVCrdZ09Zn8Fy0SrwzKpJFNWp9pIXDRRG2sh76kvYx6FK4OT5uJ3C183fV 6qJumxVur27kxXNbUa9oj8N9uizbLRxj3LeoS9ZncJoLsOvqRUm7pCmaUx0e /GNW8UmozA0Pdo1uxbCJg7wMN1mkTMDqxh8/PLz3ra4jXGuwiF7SygbH53He 6YdruSC6CaozYPNeYBdULj+p5vWqpn87OhCgAxWs6+29+PnkLei19L/Fy1f0 32+ewo558/QJ/vfJj0fPn/v/0CdOfnz183P43sl/hV8ev3rx4unLJ/xj+LRI Pnpx9Oseb5i9V6/fPnv18uj5Hs4KSQd/q6N46Gnt8di167bCyYP1VZWRZvLx 8evi8B7MmHgM6RTQpB5+C6fAXZ5XsjmbFQhl/iddR16fxYsfBPq67ks87/AG sB4uQaEFkT4pjuBLlMsghPjOhX1XyTmgt+LqjVA9pW/vkuD6qnh1gaK2uhRd RRcHdwL0H3ZVRRdhA+oQK3DQP5byl6BYNOtm0ZyhYAH9foMmd09bHxSUkWPx fFmRZgPrcA4zNSteNLNqjyf1BDZvzx+Q4tehpoW2L0lcO3u4Z+cN6j10pYsE h/5/Vbz1fXDuv/7rv6xlQ3+/Hef+fjt47j/TD/jT7HN3bt8+fPTk8YNHjw7h b/dzufbEn/U76sb3+JwoxxOxsdES+YL2hs+x8eCbg33wJf1LP7np/Okfq+zm 630e8fgHNq5x5R+jfcBerVMQSbMDWrlPj4qvOtokY9wGbLr93u4bXeztHlg8 KC35K3ya5aQKWdy++G+W0F5FQG0ftiJ+IzIeDhoajnBzONah4Ag0NV/ZdU8i mdUZ/wpRPUWLoBepigE7fyvimbsxGWzJ7Gz+9qYTnV2z/7zpcmZ37n9mvnoK f/zraLPu+vv+Ru/O7Ep997UH4B8b9z8250W8fcUiNX+6mWXj+52Mwi3eyF7c DfYxfZPfxqhU5reyGtWylSfuTYkqITeBupDu6MzDYZfb9/EFZHcwqAjyxrZa oMEfK9HFKQxeW4l6iJZ34xLtOzk73r/GuhyctiWqHuWqX2xHXjO2doDzJgDY KqCZT8GK6vwovOIraoftp7qJKmusO3ydVVS8S2RC64IfsdqFi6Gmjd78I7zb yLFFTjvtBgZB0n6jwozf7fFIx3PeTDxVfBvKr3GKdNZQXPHE7Z3KJpNfkK3Q sWniVVQxKupELqLlVA/3WNQTR9Zz9A6+hdfn266eiiMADDSUcjA3J1UFSkUn rq4xmYazSmxBUG1wx5HTVOym2N+DmiZYMWBeUX8W9HY0v+uetllf+TXlXo6K 3Lzxbo17zTpBPkhKLhTnjrKNweyh3txR50CMc7jonG8s+jAyeMWx5GrUWtX/ gqMMnjt2+nZdM63pblhWfYkWOxie/u4hBQleA8N16J7E9yxBj9LX84ZL3rzp 1HVKb/FvcMl5igc4KSJnlJuhoi3ncjC8WyQ0lmUvhne1qM5oWVCs8BBZyQSz AiyODg14MQbufXMb/TqwQxypnegYlh2h/o9O9gIu+eDVHWIywNa6QO+jGNwn fzx+TNPJtqbItUnxikxg6F0NT2+thYhRJjLJ1k1H5m4UxrAngKw3kibZmQBJ WOkHtPV/Ac08uDEuS3XBdX3JS1aKZcm7ntakA1U82agj2OwESenbDTrhSi+h I/fdiGVLy1q4SAP7xDMQce179h1In/pz9maapnlTXtuys0+8wuDje/bIDj/H F/S0i+vVCvZUs+mKi3KxqWjnuOAs9a4ttu/gtOx5+fuOe/zunIK74VG3/+mT f2gsu5ke+vz5QH2607IllwbOSPBW5Obmh5o8XdGqQwfhZsyMS0M7Kk7e+n8U PVwMnbd/4PNgkpTsFHzk3CFcY3OUZP6qEoua9lZDXnH8dFZ5n20YOO4KNNzW hGCiaL69lXg35RcJzrZGwsKattVf2MOGL5+EvnUbujkRkrDVnnSZrsBSXlKA Mb/tqIM8X+nuljXSoSS3a66/BH3o6E5fhy67n9cNujCnFYexwtrc6sRT28Xn 2Xs6UMBWJCFg1nHKoUF36V8BL91HTx4/DW1jpGrM35WraQVbjXbsmgP3XVBX /DgcPN1QAHmxnRQkGcSLwhNfzUaiQyi8KbYcsFObjvw1p1tnxkCWSnCtF3xv PIMjXZXQJr5ElrZZaTzA/Bwms616kIjU5c163DdjimBHog2Hr/3EscOAZb+r e+msKRe412VQFGnoNq0E2owzHL9StaEOXrPEF4uCHXFJHU7FBmQljZw8FHio 4GFcrQmoyG3ViIxEH8dmMYOZPq8rEtLQEeoXjg1vkXI+lz2OXr3qIzdfqHKC 67fGu6QiLc/HZliFwZZihYUvtERb8Y3xhmDQCv2WnCh5feM4muxPX+H2ihbg Mzvd4OLvih+3p209K16zpP4JLvanQanYR+AYBzGNfmG0DrppEXGGXp23uXuM HTp45auVaqTXe3ice/u+4FsDFtkYr826/OumKn5cf6i4g9C/3x1OJnf+++E3 48Pvv6OHNqB8H35DD/1ULZ/NvotNsq+/Zt8e3+jQ3QL7O/jlbP53/vIITkb6 0+t/6Qf+VOXe2+26+i75pTrNDmHnOAYH0SwVn7yl6DtffJjN39Wz76JvuHNF Cf/jv/tM35xsl6AYtvX0mAJSJxiP+m7HO7DPD2RZB6+gOYd9sRx845dMNs87 2DzxE7lOSITsHUfIfndPVvve97b30ChP364u5+e3QOBu6IJsLxRyv7ud7KrP mSZ2vSzqER6Rd1PpXDyDy/Jjvdws3yEa792iWp3154POyFThI7TT79///rsr RmXUnKuGcMzosO6qFYZdKf7z79LP0752oJfD7/d9+xP55YFpswCNA0yL2x/n 1e3Zo2FfiqnvlP7gc9rv70gUsC6k8iFogLEw4TAxaELSl0fuEemQBoaD0gmF GSsJQxsHhRVIxdnE/tCJT49s3VI9EbNKXBnYHqqw12uXE5HSXUGBhPpshYIf Lw8jB10YJ12ipe8/OeVnjVXtQFTy0uhY+V8YhgZh22MgVjTGFbonaIZEB+In +SO5yV0cNubL9UO95gAZKWn8Nd21HE2i0DrqO+wQ2IqW6Qirw9OmwWezDma8 MATdBziIo5UeBOw/LjrFpMlZqs8VjFAvJEwm7bKhRSESfaXYreKS4d+Skbcy PdDtGN9AZHxc9cy1uzCIARpX8T6SElFLYFBsVcdM9qNBfBiT3muEeD/bq3kf zRzc5fCPvYNJEWB+PDH53r/3ov0991/VaFIFg1MEHT1g32bmBWbsfUa6vff7 slmdIdQPv8MNUA6t0nnxYdVcrshSwC1O/xJEJBl4BOs5rTi63hR/q9oGHu71 zHJAlqCrxVowb6Boyn+qUq3GkZjAZfBsUte422DhI/KHA6zVR9TCuR9yaOr5 qKgmZ5ORC1YBa1OX9WIGyzmj1ijqDa+HXyPqhj+SqYyxG84Zsa9zhi4Pna9d zhWYt0k1GfnVgfYoY6WaoWeEQW95/0IwhcLkgUEEUn1Zd8HxoOHukUsDi6kO D4N4VLByi1DgMY9ojCMQPVeALh6JoVFLNtBhjeuZemztfEDD4ZLjs0RCh+V5 eh+KL0D2fHC2oHML7WjCrbjIcUhBT4FZXgWWmxRPwRrIvNSdU1T9zriB6ehJ yeCIatAvuF+jICnNp7gIcHnAlSKutNAUztEZOcFhojpcYRETshNla2BbJPQV eIDC0xGkZ3LFJMXhToqe4pHh1R+HSQ8G2hVC7BpxaGQMryFYXmOS8QwFgAdb vUsFGEfCDaXaVRsX7FeDyKgZq1d5LyU9g83GKxpMmEnhB1zPYKQuAC5xv+YO XUf3pbxGpdMEJT7qwHp8qfdiT5VrsMN5r73w+KT9n56+OLCjpwNIEDCBJr0P evP7GykPRao8OJ4D3tTwvh1KhH1R1H9ztchsx+a+RwDm3F8u0uT9VSBn18/P k4ockDg5P2xWbPDs//TkBxbYRxt0K/Y1Q/WMbUoDPAp34hM8T/tHT4+eRJO6 Lus2YBYRlob+btwRAR3rMr0XUdZW5YLlmxdhvq3zBrUSwX/h7QAjk3OS9fR7 33JHgFsQDZRxMc/4okkeq+TFhBAQjn9jdAefrc5YyX79w389h6540wntAa9G v4+eyZ5gcjSKWyK7uTrC9FVTmBzaWiRocCDrgCLnUyouIo8vRo1SvJKKelJ1 vdOZIKCUQqI6vB7kCwwDLdFt1nG0JfZzPPNr3hWfvjJHemfkhaU2qhONKB/R cEVICgbRHk31mMOx6GSg2IrAfGQe+aAwkn7h4zrVTNolHM0lbDiCzrXVRW08 2XR7ofLR9YJfr2nfjooOk4v8FsRHpnAnRWFXt1lzKsjbt89xHUn3Qo8yCDo7 DWOeBtjZFmPe415T1ywFltAN2XEwVz8WvHYkU2Ui8ISBHVGCIrGuWtJescd0 xe7SYgoMS9Hec4SQ27UW8AoY10VTszqWiSdqg7wUzstp9v1Bn6yqG8IGRYUX u30hwymlJwSvhcPjDE6rYNDR2RZvoou6NH7RDmM90BmvnDVFC5u6WVIwEy1n exvi3V6hBINvN7CDF5EPH3R/ArlnJgVDxb16c1cVLhL6TumyG46ynLYNrGJA 4sZxWIPYOw3TNYF7OlbUacvBEwhcDGBDxGT5ll3+zpRztAAtj1x/wy56xyqM 1uwdx9tpUvyRH7Oox7aia6meC5xAjlG0kjhBcggU0hWWNSNInobAkZcjRhdi 32lsptlYEwhN1agVQdo2cEXM2RggiGG5cHO56kCwo3sXOglWhnoe2OjDrpfB ewoy99OnoS/3MwvMum0blHyf1Gd4b3IH5ZqHTxqM7RUDIOWVR6GHkq/9Z0cv jyJwoSMbYDA/47pclfi2jCvYTBPfYs77VbwxwE+2GwyJw+uiVIXukW3ixdGv glHEruCmoXuII8c96dkK2MStQtcZCFYGEhrg+5yRqdgL0txFdJs3nYIU+TAp fl4tMCs37tKI4vDeEkDxd4po6rMzvq6XmP3UN3AwT70mls43uZPYm4RngGbl vEaoNV2spxiNYKP3ELOzrB4Y/CyhSdKwKNfgvJp+4BSkVYDX+h4Zs4qsbtSN cs/ZhBdEapIhMvKXEPbDiT7aRxoGiqgjWJf5hhQMm4SDulRNSjvlK6zmC9aG MoFRuVZPK/Xr8MTaM24HotYBx5LqBYqrabmRWWqwTZcYAxi66Rj/So4tVlBY 62BXAAZxazqQp01/ztCLC7CX1nRWXRwKrlGDTAwOCUEz2EMQgZFmiyo2WN4k 7x2jqrtivxO8C4rQsSZKoDmGAEFUNNqy6/kezL2VPZcOaSeSb0hEbTDEicd0 FVJmYMncVySEdjo0gx356asd0XLQNRuYQEQnQfuZAPiNwvEqrnOBZwp6yk1J a0PHge4FfENyJEB2Zi0U0aCr1WYZPNf5fu2zI/tgVOx/c//+3fsH6quOAjhO 9ex1uV005Uwt9NCV8zK1kb1e/Sjo9Nwj3q77tw9GvLz7hwfiHQ9j4ddm3frD B+MAiHXjh+cm+EzsyGdPPnXmkf1Ygx/XxnG+S3+1M6QUR0NgKQZhjeFTMteD yKDtPM3foPNPl+s+xKQ+27hJmBBjPdEUmMUkpx8JvYaF1QWInHLVK55RTuXw B+49feN/wPd++jRZKCA1sJc6SvXNopSjZDO4ilXC2dQSvMJRMyQTLNZHzNVG QUb8AdPlKHRefqsvGCQ6cnfT2RhsbbfL/ZN3r0+Cz3xiXdLiFZpiFCBVgd/b bebbtll2Xh27wlfBtwaJENG4WSl1PsteDTprCOaGEPk83qtPAF4d+VUq7xMS 0a/elShzJgB1YvvzvWyF91FEh0M56Euk7YI6Ue467dj36jEsCNqg798gcuMN uiWoy/IO7bZ1QsDeNsCnp+y6HExqkGuj8LhjFYgmIedRVm/LAPBGl0ly1kJA 6YrrJGg5AdoLWwO1R9neN7+MwCR0HnNh7ARxEI8yQ8qb3CMfwjHpJX7G9VrK yXPvuikIaSPHpTOSK9PBcC35VWe/ZW3Sfuzs8JHJAvBIVexDtnbH0L+6i6fK bC9uKJZ3I0YLBr3A8f19ipoX+y5hUYw6+s63vgcirSK3ZTQDEj281r9FDqtr PVyj611cIzGWM47RZBu4QaxEso5QRrMtKpLTI8z2GEcVewWRuMNjChOPij0g uzbzyBvKopzUjA5P1sZfXh6BT5JHTPiBrPDal/uy8+SDmF9wAuTCp2kRU+JP D/5sNv+gd2Hrc6yFtfqhwLNNFuLQA8n4/rxt3zE275195H3mqIunRA75GH5J cizOxScN1WKg92BHvGuhF3VbzWRvjzxCwS8vHQ/UbCljD6ecFry6IbKV7SwE IZJOoEBEQf8pUntf4nfYhw46f6Co9kY5GopUzLMNQN+PaRuB7v+4muPJCg72 yABYl0wcA4vJDpDFlgK3nAqcQ3tSqjkF7W9w1XiwGYazdu+kCDFnJy0F7WCc ufsTx9veNfN3ElAOmy7fp7Dv3tvW34drWoLVJDtgX2EicPmBIzXTZk1J2pm5 KMkV1/tA4HtEyE+37wT3HWL4PmhP2gADKchsBCWRw+qsnRkdNrIQg+AMDqjI vXSYOpgwc+UJtV73X9KqC63en9yVNjm51ycPVJ1VSIsfPTLZN3gLxtNsWo4p nlfljN191J8VapCX1eKiSr/G/grUnBZaJ4/kGQh3TNvDLxjEKVHX94Pd8F5N 9QA3gJP/hjy7uFILzK6PvEaajL2HOi/lzeyxRFw3XT/+6wbkMFiA5eKsaeHT ZTeC3sAQqlVmU9BpykHl4cwsYKik/H5EBzEC4ztQ4tCTDtfnbDMVkA58Jm77 6KyiltRtTru+7hFXYQwHMUIYp9E55dmZbRg8PLQZvPYg3m104CLnxbK50PRM z4TkrKcQ42u7T74EzPGSXogwJfUw6AtdpALqtguRtEe73ACZptAJMLt9+zon AIflIuQhDT9oZL+7g9i+e9+zmEi+jIPpNEUY+4za04gIQRL4amsDyRj+jgwZ nNqdfDU200J88HTNnFas74C6jj0BBaTZdOwcG24+n7u3Y/LN6/VQMaHSLqMK DkDda293rfvEHXlfumZYWN8wKZM+gT1zNixanHK/8GgIYkId5eJF5giCXNFL VncZXUKhkDBFBEFzPtcnXVWK1klw0PT1aFQ85kk8pnt/kdO6nd8S8S+f0I/h h0+5iR8kAH3tWkzJEU7eUWvmu90nDZv3DvUwt1WNs5Sb4qbNO91yaTGkFNCu FWIqsoXNNRdJZwpvEsYlDxAkkJ9IbtY1+AHFb/GrymWzIcVZ8WJEBzObTawc j4KjngcO5koxZt30vFpWV8X95aLPqTYsAsmQVU45ibdi9lAryjU5+bvdh2EU wickSlEUb4leaE7e7lgBAcknfRev/9aPhfE4uN1XY5y72GLG08sGmgAVo3xa VEPhEgBtZPHOR+qDrfYSth4NZknJTEHH6XepSBTBaNa1Osx2Kjp8Q+SvGrIy kZuF47zlyl13MmhS5khlNOK8ULyTNN1rYLy4WHZZVEfsZdtlTL/9p0wwGnYU AUvywyinEd3/cMn9psBYjL8kZnFYh5itYQT5K0J/Hf3ENAW/Gkg7E28jVsHf 7DZTrmuMfv32PPVcZrMD7XKQCtyQ9zdtEq5ogUE10+mmtfeBXANOcp2N4Kfo 1wWZcatAN0f7TwLWrL+v8Qt4CHEAikN2/Dye+CmyFQ6BhjIE1qxmlbGJSN4t UWMkRTIrV33gK1BGzTctyWahjtIGoTNj6BoZp88SyHfAsIjBlO5bkVs1hhlX GHvta5B+xX/blDP0UkwL/HeRIsn3Vd3lpFe4PFYEmliVSPCGogCm46BAdwtI oBJGv6rLxbiZ+4z2tu4+TMBS4LeO6QBHEMVIUMtT1BcSqDOfPSYABvTauLkg xov1pgW1o2I4gIGcZaxeWiWwesvoKe4Qx738HvFwzHirLMFannvAd+auZyXg Q1WtfeYh59nvTjZ1Yn/M4dxLKI7O1niJ7H7laY0wA0piJYiVCT3mklEdJqKX LBAG3x4dPXmv/iqDSSc8K04o+Xa7qlxofn8Dq00+tLVm6u9I7qWWa4GLibfZ 7bAfRzc1Sz3HM9JE7bY06TG2XvkAkvqcsWHllKI9te6dxxknPnmVxFeLPLpa ZmrDWIVGGdoCKJ1gDRk9h3QcOf1sB3iM+5XWcrHDWt5tLDsylok8i5W2xxKQ DpiEmH3QI8/DtUEx7JTOCRk9H6kiiWq149AxKlzlIm4h52MPYYNRwbGiLQeB S/cHRnVXxRtCYFlwzxFyp2w6UsflYz4mxf4f3jw9Onl6oHxx3yJlpLu2G2fo LK7Uw6tTIisJFgbKDYJ78MXjNOpeMc7AZ9lS/8+04yAMN8vlNplHnuhOcMC7 HHkz2ChjMN6nH1A+ySYn+AnsvBXH+w+KoLiqExkTluu5IB5gbEhmILwClLyB Nwn8GrNohygf9lChv5inkVoT8WSn6ICZBC9rlbuv8OWSgA0C1q/qFWAC9psx EpfkxqbuKbnXevWVodF7110SJCBcYSCqQ11KIOgJkEyb53R5RNfwlne1R1Oz wECotffdBDgy+fpCm5NpCHwidBxt6R6ZaxEhDR356ckPXyOg+YuaigOQI6fW eZIGp0j5tB15DObkFeqxpfNTOsiUEyU5wnYsPLNrFIKteyKscSn2mtTtPpiV gqku4183ntmPvdeeo8Np2CVOEKAMIrtJr+h6FIMS7Ucy76874mrUmAkw7Bc7 FCe1b/+CCSnwAgV7lk5JvVO6DB8n4SsnYNZM4ITwckICYaaTDw1oj0HUcB76 HZxT8pAHvTFASH2+vRJBJBhQ744NzTL5SEhVFOm0MotA0DaOYk52dhQZC5ac 16ASJ9RouCNku9jtwCmBti9KG8n/Qg1XMvK9qBfpkwQqUBvS0BXGlijEx/ZC FfniMAsf/UOLbdRxvV6vvOdjoCFKf422lcSzkWywXewjINLfMuN88EIJ9Ff4 Gk65jIwPC94kot35a2aw2bGtZL8fuKvYXq5wHA2ioelC0JxSZMz7SsqVR0oo Ep1E3EcOT76HzwU47Erjwl1/eFP8vnhSeQXSJ6HvZ2RlSHs5EAfwdORf8/vi pOo368cwASf70O5oJ/Ug/+31iw6dxnvFf/5ncfvj7dv4v/6lB+To9V4QM3FC QAyKzk5V2wuJwPz/zxESOwXEXcpdPG0uKnPSvEU6Sw/YVa7agM4jlw86TRCU FRnqA39/1r6t2B9kPBd0hErjCfYObGvPx/5dmtCcJzs63NrXgt1O/6F+p/+A e3qX38la4tSxQJAS8l9ghzTB6z3tvZx79sSWo7nV+QuMlFJsj0j9RJYdoQ09 qz8WTyb3InvngEWAUkPrus5MMjDPv2mcW/bEMCyMlG2XAdVhG3Hli82COeiw rTUVBqiiUTH1DHvdCDOr+8rz8RIbisz40a884eTDIjPATPGOm1QsMHj/4MsJ 51u8N0q17kGjV8+hj+fp7+nc6e996hzxsFSSxlFwmThtqhF9myWmMcDHIDyn jNEH2ckjVQ0DDT9WyxSVkNPlTBasRizwLXu8m+jzLL8A3b/i3uKF41WDuViT icTvpyo6ISNEklHl+si/Y0SOmOIUhvZBnRMEVaH96XMbr8wUxg7My3ohHjry XSvPryoJHgeHI5FLL4xB01RASf6u4POQx1nRBvvlCqQMyDOOvs7wFtjbHSsL sgy7J8tIV5ZHvai9c/NG2ZdAF0u4iGUBliXBK/IK6Lr7ICiiCB+CqhQcX1bb IkQWRTZEbYaevj75KWY6TDn7shs651EC+zGdX5mQzs8I7dmdk5Kgt73g3YNB 4qPv4KDDtjqr3hFJM1WbukouEFpkh7v9uu1Qle1i+w5dWTfeCqHnsT54k5Ys i5q5MJLNj2fHZ0aiBZVnj+vKeYVBWp8ZjC1SN9g3R0C9GKe2Rk/mkKP73uTO 5PC2gJdCCn19dt6HAD8FibJ0e0g+ghJfy0eYzKPUL7yqGJpLmflTYTS3XF95 Pj+GJztFQF0RXmE/CHuLzSZWV0jIxzrb1LOSAxW5+KQvZEMvuhqNQI5RVJ00 1TPDnRCwUXG3RlJXQLzvuQAB3iOOHSx0yCPiwMAc1ykAxyMxh3r4VSR05JPx FGMZR3jI/khH4dwfyHtyFWRr9AUaPjsxrtGTd9nh2RhL2bmQRy2BVvNzQ+XH KiA5YJ9TVC/Mx86xBUJUdojAdNNI0ZcT7G0wBoXhlp7cLFVjD3zC/GLvwiFf UF+eyeeR/BdzzNIe5s0JumFvhBmUrgbpJTQsFpzC+VQKHFU1xnrsMzBPnxUw tmmgksa0gw/BX1eDJIDg1P6OGrT5AHZVb3X6Y+tcot/gViOPLnv96PB+RwGD cXDsj3AHot503iwoLc8QFBls8XPxyDsHRlPieDIp6qLGi/9Wcjo7oqnRug6S VAfKq02W9elwmhNYhuzioERwJF8KGJCTNHcKKMYt6Y4XfBdCcwNwbLH/45s3 ByOntpXUnuJbeebzMzokrM0B0eJ7xJvmnSp0CgmMRN/OHTxxz8x23+hun6PU 9shm6xOgb97pN79XKTM5qcrFfuYN1xn66MPKn3w28p/5GlBXxs5YJMCJPq1X GaZTicRldBkVoP35xgekyUyRKGOXhBkz+XPFjhBjFt41uDauUwnzV6hHUoRQ GdPKRuvznivI4GnayQqMMSPBq3kCZRMpw/rYEruIUuOdFKxijigR6ojnrz9W gT405LlYPjCxnZkwjr+oiR+WLJOrYfcMEhOwL0NyEKLDdm42dVW4o6PM1eFk 3OrcVaZGpxG1Zln3+OpGSKpUYNDGg87sx2bFgdz8Ys2gqfDpK/OAZOY0JloT rbNM+xpvUHpvZHtgc1L8p2YikV2qm0Xh+Xu9XElk7wqDwmX0QXXNaF0NzAmU HApyOauZb8izw2uZ5ytxgkse6zXWHpJImAQ7UfUvkVpWMXQkwhUpoLWTyEll q3RxUh6+VH0wAdXqmRO6hqoyWab4gt91UTcL5UUKvyOPoEtUU8MYEC80m415 Y8iTMMn1JIt0I4u4z6b44rwsibCrNzOF/feoCj9FZiZglkJgdSYkvOi4t1eQ 3pMpqkvviNOtOeacsf/+FRsbr7sPnSVplHs8b0Md0n0eOHuYCx4Ru+YYbF1M Or9b3Gf6789y1GDQP4NUDD724a9Hxd0749MalODNSmovKfOYFAhQBvjmdL7p KG74DsPKVf8OLDw4V8/rDxVGckeBToWTWbFfLGdoBG73CHYiH2DtXgsBJfNC wCNx0N8ck5z00aCSM5A6mWhOYTUE4c8867Q6rTy+OfKUOJ8cxRSJguH4ImkQ ApA6LSYJDt+YELBfA7FEof3GIFRfC6rzhBCqIMQV1Eqq6S7vSWdwRipX5Icm YOr55/Lie+Jvc8lB+FAMS7DmPPDPVhqHCziqwPVzgwQg4eJTRKtNkJXyXRFQ zFvAiJIwDkxkdeA7O3g5OUVrCBuGmwGPrtCRBuwly3Ia8SOKt1/Usw3oqDa4 SGUyqahktsxrIUUXcZax/ra3+zYwI3TKUkma5YFAzJv039Ti5IF0ZiQyUTou gcopW7/YxL7aVDCrIiunae37/LlcwVzCJn28RbgP42MFJ69XRzCIlYIDbmRU LdXhjtZJIKfH3Ow5aLEiVsEiJc8FmmmnLUhbJCsil5W2hkU8hDbu+euXokG6 P+1hYeavDyeHWHrv/M7en+nA/1Kdvnl7DDtiVpfhR13xp73L6rTtp/jwdCz/ /WfvevcQgnKWumAR6o2wA5xZpujC5eqbHhcf828UKSRcqfg+c8cLgRNOh2Xo D5NAmjFX8dQFDCyRWEl4QHsSbUOrpEqtQVwpLkgUqEZ0sSS6gNk/Ua+xYmQU SMhJzVtdTIAaFBi7WXw4Q+bUa8LB9kcsT453ViHk/upV5s0XCv7P/swpleOh ZjnnRKQY+xVpofkwiV4Hwt+KBqWsxZMReh2RCnz/9gi6My6eHAha35xDd+eq DszqGU2+JpPs7sY+0dSCmqRIjqCjT30V3IKzK0Ol0QPu44vit8XDYd+8t7ru 4qvg2ulYFS8YUii0rjkrMTo/SjnsUTNR1hYs0nPYO8+JcOk85US9LmVM6vFp 6oeERGn7g440L1taBHzBy+L3xd1DWKn9fSx2f3hQ/G+gLzE9Jc7Ty8z6cdYv nfd0lnZ3TIn7PPshPH33jjB5c7qet9aZtdBbikJcbKWEnFQ+wOrppntVpENO ydTjXa5sXWyUOag5irve4eoEEzZoKb5gNPnuyTb319rYMo53cVkkR5A7DUqA yk5wPiOld4VgguI39q5WBoVoQmJbgVYgMGEsqDUgRyBvgfQ3GUcYNBWaOuXd gsRJFBbGIDZzLhZcADusPqpiT4JznVTKI+9cB1XsCs+7c0eDcMGAASrSeYmm mm19bsdGizK5AnhFS1ip7q+IKpmcAnv5G6QpVvLFqrlwhSlJslcudRIzaDGD MUGeMzXyDS+nKt+OoLFUb4vNC/br6GitNo2tDfP6B90hfHmqhIe4gaZq7cj5 T43lOOefkExSrY8vQYsiXyCu84EXFu69dQwI4mAwET5VPzMRg4nKDzbD2GCH zDDWLyljQPjKVZVgQG+0enPtd+klYs+obzicD6KOkRmUFHBSfuw9zGaZVe8q ZD1UC8i+KLOm/ziXQ7y2zq7twIfwpQvpvLkZLaR6g+jH3cDX5iemG5bo8ui7 dM9qTxSpnp+2pOmch+YGlPC/+5fxuPhTO59Wsz8XzxILiULSTKVCQmIvsyX2 fJFLRwfnX3ERtkjQglLvslKS+6AZ/Ktzx0y7+8j9w1vPpSZ4fuuRh+K8XHdf 8kot0TF4scvZ/jv2fDEef8/3jWZ5UD4s/iTdC5i0ZJf+pptsWIjM+FEITOeM 13CUi/hRLEJMFlTdjC+OM0I68ebRfM0Yq5DdzAOdmG4phOAzDWCFZ7McVH4z xSuHzd7qDK0PMXrORkyzErsAwARa4XZf06KeI1d+cPfdmxzGODxPg5G7gZUp bRCaez84+zH9zrXi3MbE+GykOVS7lOln5tdlLpqnOcuRu2MwghA3IiMhzc6K 0YrDTDBdEgIN3QjDLOFI3mNUK1MH8+Xg5AxKPNeen56robu+cATpUTrvCjjH EO4WLLhpL24PIuSapImuCI489dBXj3ziqsflIgtgfG/mA/UiCQH54ipeK0/Z PtgOWm916wyQuX0+0CuziVqESTP1U+fhMzdHiRP4bDdMJpznm6zESOo8cmAx v7tN1jjRSnfRNKdYFZ4ohmlYv0lUMkBUa1ERDBEPs3Qj7GBCZCFvNR6sTXpG dFsqgN1gYrDAhvIJlYyhJGMaW5MoH+FbUVObVsErTxgS/8NJ8aYKMxn1gHjW GZWmuc7pSaE4MKhG4/P6L/A1HZVBioAila7AByS1T0PkD0QIYTFiRqGrt18q yRmLlsaY4mwcr/6mIn5SxDQjNu0LeUO0vKY1Q7Apsr+CvceI8+vwViL2bVve dhKAoVQ3iZuPzzAKF1/+PL2tbxpGuEqX0AToSNcbXlp/oUyw63UJf0WPXJxS zWfkOlT0EJ0wrD7EPBemcfZSxwoCIpK74VSy/wBPE3wvIBV6BjYEhQaDLzZO aVJvJaOjYyK/+MmeKpLTiZaKFAQ2ZxJoFFyzmmu15iwDdG4v6hvTwN2ExDKZ AqER55wusr6jW8sxjWQcJEsDWYMtmNVmXUgIFT5yhK8iFMwmlxGJnY/wDruL U8o826RH/wBHBw5VXyKlN4juZf23MtQu/fbh4QMBg9ICxJFAFB0u2Tg60LBz FHUXVTce9ksYIqhTgtDEDZQWYJL2V1fN3iphDXRMAnLKvHsKEsBkirSY76DM dLybPN3tXsStuUe9QicdYhI1PVWY88VD52GBoWJh4JKPYMcpogPO2BnmPeKn mXTiTg7EYhsy5qU9vTCe+dRNps3M2k9Yg43EOwWDzJz6C9DlSDfDCYtfGpLe peSJ5Lxf8SLSPDD6RWfpFFR3yq6ly6RGqP960WyxkaRo/NS8iFQT7gfGFrgz LvjuGdPiq8Lr1b6zT5ovj+sg2bdYOY6yBEKo0LRfz8MuoZllGkdWD92TlydU ccxWMFmxgY4pnVoLMsaBIy6znnLd7JVL+k5JTJemyxNlss2sFdWtqEquTaXc rHNyd4LeVc1MM+iCZn4UAjjAZs62OCX4zJbDSTiFU7oUL6ARTPx5tlKaqo4j TLaaNvmgvUwDGQeCfraFE9TbM0dtRseDawta8JdtkKA106b5YCoz+rgZFUmC u31hRzpyQcfLDlK0n67K/twSSvSS6uV3eTQdJE5WplC9yAbLop1KFiM3vLzQ mlCRE02jXnQetzejfFbQxZX3nXAihKvG3eCq4bNIcou0MSOl5Lr22elaqpFk qI9w3VRSWdAKtkCHS95ghJC0StxsHAOIJnov5WQuzQo79uGLBRM/FbcyKUA9 ldsl+cpp0BgMy41PtC+9GqNEKQGnExWazFTU5Og9RZF8RAwzymH9up59HbGg bvxbFE+DGXjnFKhdYYaj1CCy18uRxqmFSiKabLf7d48DYBStkbTUaqH5JC6o 8LRtvfrYBcypr1uEp++sLdfnpk6kSPjz3A4LGqGPnvnX0eKE3Cq4OglRARsd Na5EjXVWjWUT4GiojOMPpFA8FkUREqRI1xZw6C5LgDOfoUFfWW2Xl84nQbhd MeWaUzuvKpKih4OWhXCMxOLC6pXhQMpqWdQLHu1KSj8Hd9l4kHsHL6/n27DP pwjpm3PznmwdYUXFtUYN51uv6CcmO26XPug4tA9L2DbrlukYxJYbF6lZRh7D LuwX082hyiquR9U64UXsxDg2Y/NidFbBtsPlWzWZxjkMzZOkaxxBQzxb4hUd cp7nMLc6JVbBG7N30jsBAijy06d/Qban+3fuW3oeqT80bVo4HzgeLbvLMfCg +NBxBWMsqF5oBX1kiIXxcX7LHk4kDrr78ME34gX69OmXH4/e/vKH8bPXf7wH e9PJ/FIQVioDE0M3qRunpiAWUzM8e31xL/RkEhMuVQgYmwo+HbGraLDVUX2K /EZzguLRNDwuRcezTkYfKZPGWMHT4wvdBVg8/Cax3e314mWHXa8gFs05RB4d fZgdb+wNRfMvURm9qSeCjQjmrNJSdi7YY77scmKtD6kDNH2SFC1GgzPQtRPq bU3W95WwhubIW1Klos5Ak8S2KrVIHGijZ1zYF/XSLs9qlZYMqDuF5PnJwIsT hUpAvxGjKE4JLwO6LSK9V5UMUMeEAIgvBLTGMY7V1nw7IF/Vcj1YzFEQHaJy aOFmDq7Y4iyJbmIyU6+qWVuYHVookwztFBGiWHuQN1GNIEA86YjLXNlDyXeC nkllhHt47+FDuhgoZFQQrJQyrUTUhk3Kbyfoh5gSMGNNP+4qvKMJJGSoPp8/ +bFYlGC/00K6LDPdncldjhChFLr/4OFtCpXhNU/cnLx/pEl/OE6rs5pstCpI 4eLo5PjZM+wNqZTwW9ys/Hpmvu0J7ld8c7egKtKdUROjDR+vC/XAr4Ug6zmr Csbn6AUKvBAljDBP+HbpEpxY+Gyfy17eun2rEPhqcevhrQMcRt25vdsf9/A/ 927/+55cqFL6plnC9hVE05ZvmlE0zfQWdw528QzsyCXWKb3qjfBBaT6Y32IV /NbRLec//OHWgZaqJX93tPxpNdZYLDsVy4saPisXnShOz7j6Ke44UvEbrGtM c3ocJIIp43f0K5nbFvW7AGNkpcGesrDQAJKPXFDPWQnTa2VUU040hvglPgPa O6eV6HZTvQCgx3HqjchF1NGE7i1UOuXad00q7DSSSykrGoewIgROkIbBHV9e PpjDPO5sHC3qJV4IOAnZCiqo3ndgvnjvXcKOxMIjdpdq1k5su3inW70kxG/P 3qa/eDaz4Oq34yB3qKPDhqUhF9vYpjET+WW9MGoPXQ/qkmHlstE+0JEhwlWH yT2toqM8KjA1utCIkKxNh+cm8bSdUWxsNWOBizboVvYOwtzY6XXExVnJBJtF m1azQw0nqNejI3nfbGC7Oa3Kddo0PdbSXSeqbSiRQHpdcfLH48cUG6mn1Qs0 yhh6x9CDX3/99dBqddQX3j7kdzovNbck9B26NCZmIJgMuDz7yswsHymcvcjb NhxGguRxbLOeYhZGFdbBVzCTNW1C3uJl2yDnvdGMtKCkug2kKogswRbvfml3 QrVouUNdLDTicyr4bprysjN+LKd+rPSqxnfYxMp6XhGZLulAU6x7CScCK/6x NAuE+N7KZaSLWmWolLvEXdT5FX598pPgVDkvaCGOn3KOkHL0mFJgWXXepsAY 2hIx8zxOPiTEhUBZG1jRii/LLUufFXouOXlIING4pd6+fd4dyFi9EodslTGf oCN2ykBmGdIhhZ0SfmW+DUkkvvq50b60ikdJFE3jablmckUam/AcILMGthRI o0ICHO5HCaptUOAZTDCZxlS1iDP/xJfu9zMRgWLGk6pHKT2oZn7yZij+IMWv fJBAQUqsGXZWEpGvyFBQeA2GNnoZJeyb7LnyAtTT0h4R3fXBURanEkaUrDcu IZoD2qQG/YlYlTbZ3pQb0JzZLdmy9nFLOGB/EcIfu2pkclVxLcSJ3fU6tdAw fqzgbuzEHvHtxY4vJuhimAg0do4dIKwK+sFxXsUOwtyiRGVIdQJbFaNQYyce LtFyDOYlIh9gNT2qcSgC7kOFAAXYbOuN56Ih1MFPT1/Er0nolHe9KiQNPv/t sQLq2Hl27HyKAi8RwRqqj+vSFn4OFB2EjOBqDrSFn+uvJTlH3Cy7ESzWUU9m vKaaXw7zpRlIDk2WU7zF5Jo1dSfYredDeTnQw/uhtzaPDVNvaKimoHkVNzhA HvVDR8gNoHfqYZmCOs6YZ4pSSFYbp5b4rGavkCjt2e4jjL73OcICpJ53LRWa ia5fM3+5OkuZLWD5LKdy3TRIznbOsF20XDLBhN1BcwPlcjHai2T9F0bIC2Vl duIeJC9GCDGxKZdAkmO0QSeah0sDMT5rKzM+mM5XIQ1cRHEEwpN8pK6mukEm aXy1g7f+PantQrzfcfzNFFpI64FipI0gXlOQKBEpgEPJlxLIiujqQiTUpLOy 1zyGJiMmrlqK0rfHLfMmZH5ZUVYr/Q4mbH+9ABG8OFASA0Uzm0C+ouhsDvhr jKBXFAWEG5wS6Ggze0eHK3GLs8/0lcDPHrljJlZcbMfG+RMFBr0dHzPYTgwe 2jdSDBvprmnFA40ZoGTUg0+feBOZegzjulyVSVEGyVl6U9GRjFg8haoA379C g4kzd85QUSc7SjxqRo2NauW6PVbI9vQoMT2+SPgBpmDEgKxuXQt1ulUqxB0A QmHdKRWZTpB4QmMu9s5NdVaFMSHiDhi8HYu/Sc/5tnf+XpOC3CRyW50m8UKE aAmYGGNOkj4Fi2OKej8o8P/Aympl2Ju8j1aRwuwU128wxpS6vAa7AWf1JBpz kRuz4xi0dIAM0UCptyy4bBb8sMJY2XBeJ1+0vcVFawOIEnF3ZMiIaxzNrrMV agA4F37QVrqmQxPubHaLgwUiZ9THtoYvRsjxBj1LHQFEWi6X0bJn1nkUMe9M OQWoOGB9GZJsNcIQLtByomIKI5k4aIaci4+3yGxl7ASdxKQfM0yDX0170RTh K3J0U9DKmKgCrBT7UlpFH32MK+Eyb3wJoKYTfO/jBXR24UeqwGjlrpbKuKI1 zCZfMgTE4vDVKD2GN2OBbWGQM3Y2uZQzvgpVGDiaLFqfZrnlqJRIapGzVmt2 k0WD/rXCtggLJ9QU6DQRt5IY9QilDQEAV+xIp/HCV0tvgC2aBj5z+YN9s24W zRlof+h1VvGDO2m9QDzSJVyczQIXVjPrOgNkSSJ0TavpCzElzsQ9qdaisDZx DLhZVMrgMKCHk8KRijXiSlX5N4PyTh45tSdDQxOkVn9P6bVcHXwk8+8Bpzct zc1mF7oqeiLIzTJ/zoPlyrWxUnagG/W0DgUUr+7pIMuQfCUdnKeeqJtDUCaZ ML5XYZdVNeXYJBoY54xd0z8bfdZA8G78cHFSL2FiWkJLp32MJ8ld3bvimt7x Omfrhl+BbsZ5I3oW3ymFPsJB6BgsLkeBfQZypBUimKfRY7dtQC8kKki2Xhds GtOTXSvmvmhO/o4VG3mWMfbGpQV7z8mUJa3MkVZGPZvBgZWr1huIwsvEple+ j0kkL3kIC5tyBuzK4oC+dIWvr7xEYpijt4bTxpRr9CSaJv9vhZ5uQvYOD6gp gkzOQh7U+Ac+jCKzP32VlTjO/bwmKjmcWDGZbmak0l1H91JaDmCn7DbMphKj oeT+kDW+xvivMxUBFEnM/ly85f2cdxb1ZMHP6aGxRBDkG8BgCsNhEesW7zhi /iE9mzJdkAPIjOdWFyH0TLaH1JZD1YVDHDG1q1/dBdeo8fYI3IIzDmBb977W 1yWVC7QsMrpjDhyDc8QL1GQ7VqBjzySr7hiJ9tvBzTcxXkYKvOAbDD8oEuRg vg7ah7H3lDJyZqo3E1RiFaKU/fR8JNUgaaP60XXEZ3HMwyd/4qBpr3nbn2k+ J9Ii+nXl/Ce2c01SiwkZe5cmrMIJBkM2YuWT+0sd/4tmSlHcTtQglslEH0T2 gejd7orJA5k7JZK4nUGOCKwLL3YEvtNdQW41XjHDreqBw76KclZ7QfeWG8yj 0k4PyF0nxc+rBRqQAoQOUYcMrxHl7XnPDh4hzvDyGi9iP1JCbZKVGrNijx2P Taw874fDWGcvFGyNfHTlURhZRAgmpfBWuFrWGvqi4AGJekKIsFr37yBWaItq xRWlTP0ql1mbSeyW5ztanY9XlMIy7tKoAmCuQhYnUybiRdGNnqzwI9jouXmN 6kd58ezzJOPRBBJiA5Fs6wtsE82b7sMbN+BLNi8bZQueT4elbt7sJ2+mmjjd leVvrqt8cwVjrqHjfQW2w99Jx2uIebPTxry8O+tN+vzNHZWEdySZVWn1T81m xqj4+3BN4lKE+ZWoAsYYcdNxFb4whaiRIoE0xTJCbXVDSxsJmmdzF2SyzWG7 aj/mz/nEJUQQHjNqE6kzSZfoubmK5/36DGtfqbkDQ7VzLJjIjLyJZEI36Wpq 0dICdCCyb1bHuShNdCBqjpmluF3m9thZUmAnxZWVFj66cX36og8C3KTGszjI xDVFbxQNhZNw4C7luEO28hDjISS+baOAikxkqcIuEs/j1hUxPWnNWG5BHUys LFcECBZyQNAldhJD1iulYK49qiYKRCo4BqOOUcVFyl0H8bYua8oY0NJEPh3A wB9o/tSBpb4f8lZNRMNOFZWrSVZTWHKo9kjH1zPshGInl9DQGF07mD9343pw zteD0yuqNih+jmsMi/bB1aPsznP1KVIP3SCPNRnI32VN+eZZzY9zYZIX0EGG abgs21m3w/o1eFyPWY+dA0pfbL0iJHl3MC4N+JlvRpvhskPwvUdKXH8nR0bI zmR2Zy9orTy909/EzEIs5+2cBcCZ25nubus/7BpAYGlDq8mnuysKxUQtKVU+ nsKIUyPmtSGCuStkMl1FuMpWTTQlf3ZOvQVhR78JlU2ss9YkMW3y5aqzFShS PprfFFGwfQfFinYRbg1f9AkNoRscdoU2C8E0HNoHFlHSURkrV+yq2QuiC4/1 RHpqOlN3xh4IqKcgGEMCiQmm3KzTVyTP6ZxiQ0kcmQEbUpyCbGSwopo2UewV AiRNbdbjvhnjZmJ/fRcCRjjdkvPn5X5mw8GUmlJmrKPDhEnQxEOxwnWotLC+ Uf0RAqgbLgUU3BuJlkVRQfKMeVKG0oLADAUnLmxS+dhWKPBVVwmp40OaV251 jr4stupmD7hCFuw1GzaXpYfEznIBdLdZ+fCWxP1gonDJ/P1jRhdBWznpURUD NECxjIB5pOTCdwemBJ8NOyxhNnAOCc0h/hvxlcap7aL79FygeSpIELTgJxqN 5lM7hGrk/W0kcZ07wjoM/sg3XmReKQDyLjWYK8ehQp89g0XquiujDCbchOI9 W+vCFi/MpM1F58kjyNQde0XZF2sJRtC+ZGSWsi4teW29J5lLUEq5mUpBNyYW 7DMpbxkaNthrKPDf+Z/naACTMt3X+wiu8tLBdvVFb0ZeXRs0SgA55KjEBIYr xjRkd78irGLIcus+VknIg7rDXeAJRdjJJWFWld0+79QS/wTvwP8nTPahdZk3 zQlG5gasUdljN0+lfU6fdkN9OreoBOPCtnZzVda9i2zsHd0z5rZZ910lyK63 ujMcWhlhgWh0VCi8n302hI7czAwwORQ7DQKXRJTRMRDpst3mlDOCejKKrlFo 3VUK7VWSz2bcEEGAT4cawoiFl8AFlfAGsm73feKuo1vcdJtywbq/uYHotjbK ds5sQKLDnZKCK+1FuErQBCbuBahuTSaH5e9UPP9Jauc/W+lElTPnqsrf3nHm 6679X/bx/s9tHsaE+L2D48Zgwh7ze0SzkrVyBdaaAcAWSjpYrsyNnYdVsCdB sx2dks8VnBYjEPLzOJEBD0UfMiShw6g8aQ1f21cXdO5wRrZR7lDti/x2Jv63 SzS9T9GbL5gKFhSw87bU4EcoWI0uzzmzfNRL5CKpZgGsicibf7VAy7fDWa6W pzhMJCHPcDZTWfaWuZxaio0rmE2KcQRSKcMTe5T7UZH5EesS0AEmUIH1yXZC AkmpAFV+2OKxfOGD0YkjxYah11wJ8EZxaHFjeewBRnXTcHR+73pmlW4HIfhK JQgn5LTLlFcvKmHMVZuUrzUptRMdbYcCTu6uf8JKh0Vzlj5Msne7a/tFAn0k 9cypMWYKd76sQL4vrS8BiQGD4ESPKGADoaEjzloi1Rtev1J6wEMuVTHwJKKm B6MMp3Sm/tW9CaFpsYJC6MQ7NO5wNZkugu8EzgeZFFE9iGRh8Aq6bGsdVsKl zm7G3CxlnD+8hF7PzTCCg4r7409Pfhg/xWSR2fg5pj7vi04rXxBADEt4pHMp bz5QHRjNWQVY2Hfs6QOZydGvHrAWzPksgx4xMb/B3Q4W4VtcglGxd3vPG/J4 WYSkmR+R41KoqXkuzY5iGwcf0UwY3kGblfKmMZeBprnE2034M5+tiidwukfx bjIR2MGwXDqmh4f3vg1juj95COZzCAaQiZw/zD7nIUAuY9bUOV9hvlpc8LM7 8bMbB1BDe6eR3B6/H2lgM7i0z9py5lkb8ZipUBMPUOaIwLch6+4qR0aGjt4w 7WR1gmEzSbZQGgJ5P0L6jU7he7pZu1TogjiTAiJltKEDYSVRTGY0kseb3rP2 IL6FLrWQ+U2/lnqAw1+Lt3TfxtckRlAngAqDxyIWbmc4aP1bypXxPGS3T058 D2c1I8CRjbwvYhfIzS7TnJsYjyJfBdeK+MKL+Ly+qcUaWfbOBrLrcHT9RZBJ tUpEPJZZyIj54gZi3iVi3kzEzXxIwULYKe93VIH4R2T+4UDow0uKLxD8dsoS 4S9FE4zha9WHiLQ1KwfoZsxWvRCH703QxljNRskpkcaC0rwEcoTFbPQ7yYaG BuGcKb6mtMdTWeJmzXRDrcWxYbEB2MtGVXd4oUdZy2WUiVohxk1MEZNvnQSb MsGu8G5QrMQU9ENe1mAKfYAOSTnDGZs8yzW8hMsegxDqBDCo+QsIa9t0XciK wcfH/BzN6uNq2zCXY+gvxjDQRd8TKxCR/fluMMRRqaCRhhHmaYHXd9VRNt2m U2a5Zp6UESwV3tmgF71LwwEu/JRl6oyg/BxgwMt2FbL4bMPYoVXD1d/aAuG/ 4nmqJW+L6wdVC/SQ0R27WbOJ/+nTqhl3q5r311eMk/Sz+YxmCV340ayBkbJC pg0muMELNjijRlSdXeVVVIeOk+0HCYtMJ0b6ACZskOioPhKEQHdYp3FoBvQb dIfWTZfnnSessw5tLtSoKiwpHk2aKOTjIhuskopZ2zPQ0bgSvUBUsfPooVCG Xw28yGCXKU15ml9WsTUvAS82hbeedhBzUQPEg96jV8jMF3UkAVy3zJQEKwSL FshNVuxrYeT0R3twumm1grPdkAc18Ff5XY7niCDD7mxTgjzsq0pnjZ7H/dpM mwXFslis+EzMtjndsFqDGxfhNoYdclobr2C3hY80uTPUovbTaqqdIcxRnG5d 76hMJchpruQ2hotkDd3YSLa1sOW8vWwCs60fMIsAitsqt7Moei+SKBm9Ppav 06olyToIqMF9EFO8eLZ5G4uL67fRbBEhiWXPlDp+uCAUhOPKvYFHjCxbZMlI +wCiuGRILB9KIVClyRci7Bbv3o0gvCm+OvYAx8Bx7AnNSKJRJwhaoLrAghKD BW9UsIeukUfMFpPzscS9cMrvrli6x1lIEW9wIOloK0QXdUWyd0aBtBabQFEj 3eJ6PpbeMcNvN2FAgefDSA6Yg0kVrLZxqQo4nvBRWsHNUjCmXs9JggXwkUgj SW6oNpUECR/5jABBYIDubGLIrFtb80WJ1bSYy2s7ZyHtTZMt4nlznhMznb1h zfdyzoxMuHbiu50JDRuzL48yEY9B+pygr6XAs2dRpQWVpAQYT5TJELFRRw5Q 4YLc1W1vfM4xbkHbkehbsB1zmzqjS7IHuo/wCr7YOVXgYC8qKhYL5eeJU43q buB7i9R4uBaZDuDoV8Vze77vlaXsCXFklAE8OR158qTymx4PzqnyRZvlTvMO 5/S44WC6hClfBJWLr0WmtqS0ANBE1mB+93IXM8mSZCLBHMWpp047hxs7hCYi rNl1p9d5xYUEO8HukSeoJU4VuBVxPuE6r5sZTbyFygZJyTWkAipFh9FZauPw dZrNrLfFbLaoTpuPcLbJ661Ob7h+kxpoTL+sjm2kSSL3MbSMOeKYXosL7LT0 acS3gMkGCAMlSjExt6IHtH40TOJHoSSjFEkOAzUIrOSSmAZPxtPyr84hnT0e gbOW6wXWCdPTm9fHNHlUuryTU7JqVp5kCiZqjxZ/T8Av5nPcKCAL9zFSpUgp Ydx0WNu5e/T115eXlxOYt3EFukvTTpr27Ouu3y4qpGmuvu7hWv/6ILC14VOC mC4xaIxRc1osTvOtUO+dVQNbZsIV7oI7YupXY+Qu2SgoO0pJ4QroOHRuXXPw JI+lhD0h2maQ5ahlKmkNBmbolTZyUQgpXkyj8SeRz38OnqeHk7s+0ZCrdIdV JU6aG62rioDCqNGsvQsrMfxqrKVo6MDISyilS9S2bkB1HZI+EKpcCP0Ld3Hr Y51ioSXq1au1kHrvl3SVDvcvzPDBl83U6J8wVaP/987V42Kfzvw/Z7JYav// a1dRBC03BRmf7kP06O7eMP/oHHDG9j84A8SB/iU75a1/jpRs0Q03K058C+mg BLlQbi4fy04C3uwQZY4AuG/Mr2uruHZiBjqhoCb9UXQwc3nHEcAmIPrSPGbB l+hxDEOXBNheaEunA87UDLrNpICodBDdhZT6VJ1Qvr1AZ3SgXESuwtonopzd ACLnYo4FudLtHMS4DLqlfVyRRnyri5RwVH430Je2xhzCi6w+ZIx3Ja4Ouh3y SkxNcDWjenPB6ZD0a7RoAdNOQGbLeqhLn5iQruuZkmrAV1jR0sQg4qJZX0Ue TKHo/fSVuKBCiuoOH5h1eZEnSesZkj8D1vVDcDwPTFNT0ZE+ouepMja1jzgb VPSpuF/BHgdK9XTzkmgyjQ7PRrovDKTLT1w4nP6qRk34En6AU8nu9LbX6hHK TYShvXZDjKg4aw1ogOxWjX+vZFtpwikdn8jEQYlmmLa8o+xChi89FO0l2s4J x7vX5ZBQ0viU1OQLC+bSBQveOOKOTzyWKpnnIG9Keh8lrasm7shUKDmdq/HQ W7Jd4MVJdSb0fpUrWE+kPCR2aPQtBbsU7SVtUP1f8f4UNj6sAFqXBerI62Ld wBbfal6IpqSms49Mss1K6Y9LTrhWiId1HNP8uDA/6B4dj7nmCu0pCrOcloty RS5U+C527fqo75ruowVfRbjGbHx039Eqw41EsG5UU9FClS8JTbZh65rYY9VY VUVZmVafacIeLx48lsqSkTdUh5PKDl0Sd7xnGA4nkxebieyqL+ZIYiYKBpGZ 09lDceO6ZrGRBDWj0fdchxGu5w0lxPs5pjDJMXEyUZz0jdUW2JHN33z2wyxP O+U2ZwPV12rTHHC6C7HIEL+f+Jh9UvjIlYU2Kx4j0wRD73xdshgDwYhfk1BN FKg/PX3xqHjyI/zP/r/fuX//8OGIQ18nPx7duf/NQUqr/60vefzw8MFtrGoB TTz54ZH90fA3dwa/QebNR/D/T8aHdx6M/3D8Yviju8mPiAlpCnY4ViOJ4lGO bfdOqY81ANvp49M4fCUOVL4jfJu4fV5jfjWcwT805QJX8Az/9zNxLvtGOqJ+ QAAUc+GLl6Z7BLKWGVfJ+0eW6qR4rZ/pY1L+rsTytVRkYsCmovSXXKLN8kcR sTX68/G99AKnHFCeXwG20akJZqAs/+umYlpvKtV2VCzVvyCIxXpByhgzNkeS lLsYHE6MEFVBSN0Io5YRkkmMv2jLrh857mc8fnb/MpZCZwFhbnYWhIoB9jbX SRLWyJHTgdLBF8rJOI5jTvwonQ++6HRGuHgdEQQ1LRVXKJL+FiHF3idUQ/t4 s3H2bX9OtTyRxmIhrIJ379+/I1lcCgiJ+WJeDzZKMj80FFxu1ujlPvX7wysH bkdW347IaUcJq/i/5nfXxkmlwGC7Wa28BmFpngLnPUUkwxdFHecfkc8eY6p0 gkJdCuRk2yzXmpl3KFmO57D5q4XvKnGjDPtKHyeBXbhlbI2ZGR8O76BMcWZo lLDK3JnywHQqWU3K5i12quShXhm8naStDeoZRt1xOrT0ivRVDbx7SScjbEeW CLQrF6YYU1jScudGcD7oAKdl8LvrtgEoGVxwh9+Mzk5OhyPHdSgZrZnnqw+R ErZZ1X/VKFqa9ytH2lG80WNFUdeHCQn1mEYKlvEpuXmeWcmVZW7IhdSbZAgX RZy0FAhWhqWhlottV5M097NSTtum6zLnQ/sMPUPVDUVhyC+3nnnfFIVBbgpK uGJXYfBWLGL2OGKpQGQzMsO8wY5yf6iZX4kQfkF4qYVcLzE1kW4+D+dobS00 LvHu780104hKhaWfubBmVA/0EowfT7jlf4U6JUIemGc7tSFo52tNaiE+mWLk Neac9CeNFR5DSb9iQnNqk/EAoESutkt8OcbY0dm/YvKAsw00wJT0XH0lDvkg YNSzYdnNKU2TWmfbnhT7b9PPsJUUvEm1NeFCOMCxPvF4QpjPmkOycFmvBkc/ AA/jjjJzZUTVL5UDNEFCQI2yKvIlO3u6yq4IVXGZC/kZeaYqAXBgAYMjOS90 lf2CJ5KrYrJtki5ZHsYTRz6c4ShjyN7ffEQimdnYDgP9I59TTtRTnhoil6yO 7eDVISFeH8yTiybeLFSKETv1ofh9cai1M5L7QINZbCD4e5LTKLCiRUfYbwrS fKyV6MoO1sVv5cvfl/6w2R3ZC0mY+9zOAiZz5vFckh4ZNjIxLYTXHK2c3XOF OSR0cUe/pD0VR7VcZrq5RJ8E51NOrYmtv0A/mIhKT3oij1g8QFEKyUoigWHT CXfhKZHtaNFQkeW235mNlE/Nwv+pmWoOJk1lNVeqi1ocCVf9yqBUvQMa3e3O 2l4UdhcjNtTuaZQPTshprLCxM+gSsskIqxUmw7MIW4LOebh/nQyDCkx3xU/V 9gTZKT37V89o47JX5zRGp+UeD8R1UovJdzeg3HqRK3yjdNbQEuHA1wxrhrTW Zb1kMVIjKxym7OPMsSONLyj0kBWmMj3Xs2IKOEI0wHDVw+AhpyFN3xATJtAB m64fpCTDEq+6uxQrEuZd+/EMFggHyGVqvId/j5jv9rxvE33E1DWPfNqPHMcj RivwMUCTi7Uh70IWbiBf62XPxWHeua+gcu8e03LnKsEkpBNoGv+8irVospC9 bYgggU9feVtxPFuppey3PWgVNUXzSUuJSJu9DnbO9Tc5/ksVn6AfP759+/rE cbmnzqsFPKxa2CkviEaOeZe1m+TSaeXGolq8Vl5EdaPSVDls0os9Pr5U5X2F nihFRBCSnmzqdVN30CR+PiW34Si4sclFs0R4vCDDkMZGlXJCQagp140Y68Jc F/yIZCpiIYwM4zmG7lyS2xd807OyL8VKXVL1PYyZc5mtTFM+Z01HZquXrfS0 eV+V1+7x7WTgN6AiwgyM3KrRPlBWAFdUwZGRJW/Lmkc3S1shfpO/ePbaeTWf Ch2dLhrmclRQkLXqyeFxCtu33xBThUil0Ei44LW6K/f7kigomw8ES6WMyU2n adG8yLTnvKvTWqkmyxzFRyh3/0Fvci2DjTEJkkCrHt2mTUvcFceIyUCRBC86 eXpc7NdRkSWtqsne73N0AVIm+gHvKVAdQXCBjiDUoaTAk1vIe6HYcxSuAhyQ rype6H1aOmnKs5Dic9wC5T4EX4Rc2MzZ6d0P7Fm2G53QmKyuJAWXMP3w5TO7 O+CGcR4tHFKNS5pMhYtTHJQKzzP+MGkDDHyCdcGuQtYxXSzzBMwJjgodPbWU 3caJqPuJYest3mpRNHdkfE07FFZULFAXgjsDNx1vuRE658aygtmKVx2Lb1QA 8bZWhlI97KqcBLB/5LB+tRqvy/7cEZoQMfM+VEVlRDyopNMOMbxVLXOktMc3 +tcJgMVhd5DQlgj3fVTaZJ2LGaH5/gi+Fg8+J3/6TQfHvcQqa2Dx0/YO+Xey yiHO5fqyPavUO9/Z5VdBil3xPk1xFtGPCH0avPCw8i0j4OlCRwCiAWdh4Top Ly9nO79KJj/cyWWFqWpg19MNVLx5I9IYU1SpeNzIA/ApLHQs04rSDOuHFKC8 12cYZFUsM8a9cKbni40gCuGiwdFiVmbUE/TmEFSedA6CQ8kt4fZ9MFaqDnid EePX0gcVsZLthluXQNAo3psFKrOmCKckt7HHBWP29BAFPzA7zfYMtBKWaq0U NmcpsmIwMAlaLF8Xzo+6WiVER4i1ks1zakv26LzlDc/FA5mqsPoIIzPFaLF6 mHB/wGWFYNpJ8Yb6Q9H6xjZCLVjOtmDEObIdMf+hpWpMVQDMi6bOan7ONCJF dtM5MnJoH2DgjOFm5E3ElLBAnixI9ayBxvWkm9i4lIAqHCqpElWvLnC5uC+W NBHdP06UgxpP2hxTYv3ykEP8QqvSFs+Yirg4joDnzwzhNPbmLZE8PwnkJ5++ SjmMnaOmxLNu2rLk1WLLiECuVwYVz/eCl3erHe5U5bj0W4XLiVkFLkDosn5N uTluRDskhnkILGv/EE3isoXnrJVa77BkPYVZrWVN9A2OgDQ+LTXh1hZOaxv0 MaagISEUilM0F5AEOPC5DG3o4iiAnEcM4RmsoUvXEB2PVXuKh/RJ47WC1KZC dVAupC39jGYtSIBYCVBPKHSCijZznNgWgDJEJkorIhzbkgdACqlHHFP1YlTl etptYRrD/AtBPae/0I03rzhQzS6CBFYRgqaEjFO1iiQeyZWaSN7VHds3juUV uUwbtE5pPcslgjxI2+V6VeT8kTn0YPSrqMBlRfefHOCFLNfbkAV8AMrw2HO+ BfC24OruIAkIwmQzGOGQE0eS3Ih0PD5zod9BCpnFGSnx6W6qXHgvorDZm+E0 NKjFADvLX6n4KapQh04VcRXtbFxLhpFqI9IB3b2o1eFbMhwHYqlvA/18T9mz G4WFaeYGw+NtN3J1giwKSbKWM2xSFOu3cS/aUiFrzWNRzNRKxVNJ9sYXjBV+ 4KLks2ExxlA+i3Euu6Wmw4EX0cAjLxgJT7JmZ++wgb3kHIeyhuxQ+PbhnXuf P5PuIzF3aoIykjk0HNLNtLKTV6cDHm3irt8UudVIR3PFkkQLTFth92bT6JHT ikQhYQnPVgDv20IU9SpG9aNHJHEyOvH4UR/Cw0fPX7+kahMdQ4T0cxO/t407 KyvCi3xf+cxiVEfSShRXU3bmqIRZpkR5fcjvOTM92Q3+RykYRweypAg1A40E 8JVbnpGvbpAIGc++f4mVzdRVhjmrIylxq5JntqNDkhS1ZSwml7GKmPF38D5v tX3SL6uuG7LLuRx3ufeSrDxXBGPtOHVd2DX4KHZ2tI7PouaXeolQtrYPzBVK lEDmGf6Rz9hAEwdz+RR8Gg+YxLtJ9jLHKhoueSVY8Yk4boPXw/QgO/kUdLto 6pljICYnOxE/QjDkcEnTuyBJt0NQLPuamI691MOPqOJqMac5Ij+n7uJdnkxR f2n+4kuP5jS59KKtbFOg42hubgeZO2UgWkfiPQSzj/Be52Cs59XewHxVe/jB JL1CJFSNACQFRnTiQrtKS5YBuOwAJgiKjZQIiZ70FEkh9Th6HzFRRVgqQYZU Zdes4hwXdfAbX7nNSKdoAi/Um4rrRSv26nlVgsXruMy7JOgnLi2ysBAmQzkz uKvM63rxYHhtbRLSlslnvA0UiLgCoFSzEtybwlbHBnCuhAsuLAh6OeLyX/9+ //ZD+yssbCVlbQIK2p8qpyCnvi3nBDHkUj7+/g7d852bFE/5JumCI4Z/TRm9 enRbpuhgByi01kzVOvQ7JOzcVyv02kSjPYHNABr8ax+LeHV88pp8yfapN6Hh 5whV2j9+8/xA+zNi8HfUDzDra6qime2Hgr63z8K3R+Qpp6vbcCAIaV60ccO1 pdNJgc4gw+zp6JpNO5WQZ8lQOo4kBEBqcipEdpKQQyaID+yKSvRkWgNrsmk0 7CkGz2m3EBCk4fxgs6W9h1bmw89cvHvQ+YUlLZz3kTTz/DYO8yoUUJwd4Wfp +KgQ4mmQuC4E0ECdbLwDi3dYW3cfUnIBDevwW+ztVq/Gp4IjX3kXlZWTIeaz YZwIbi50fa0XBHUPkCUfTWdhROTKGDmvVxw55ygP0UPHkyaZmoOkY13dI/Fz S9YSM2qj/4qAEnoccavNA9zDCwjPLOGsr7StrkPdxIp2abU1bYnzK43UhzsD PQatXKAxMQhtDhScrda/Lm2XJJGRIQDUTkns13EjjC/xhjz9Qu7nzvVaeRZu 6M3UqDmIAalWnEdtXnlJyIKZQLzonb50hgzX2APyQ8lXoT0j0TODqqHexwAQ IQ5BqswOy1CH1PQ7SWq6YG04SoHPizphQtVdUMhB0xsSPeE6ql8IE51BR1GL IctRWfxyXjO+3/mQHN/D9P7dP7W1SGI82K0MrVYRs7NEsUw1FMQo4Td7kF/C jtuZsmyks5K5QanDZDOgntiscPh8laHwy6izucvKuccJiDQHwjJqaUaRqVdm 9sT69/4qW+rGEEtgPgxiME63FJBfZBm8HDnbJRWdgo2iWM7YQUZzRrfYqXWx 0XaUtfTkzTgNdN1IPoyF8hnOWM+I6feCLyKDfjxWGRGJ2JyhAw12m9nbGDpB g/v+7W+/xXQIHw1IFwRfEkzIFMZL/nqnW0Kq5+jD2otO2VDQwNArJhzzAYuQ DMumQK2lyFxSDHa4uUNIg8qiStdsGI/rQqRbCX8V31PCZ2tWndyj3jeeLWgo CxzImDgDkG0qPx8scvTaePoRxsnuwKNAkHdsWLacg1tUktICh951DJeG2BKp 9HYTW5YixgZ0pAN5or+bFPsnREeYsnxFkI8DPkPeZIMNSoAYId+sP8Clf940 SsyW7yGW2qxnHpFP3co9F3mHYDY6Ish23pNKxB9w6+jJw4kiLnCF4Mi+VMSM Mcmxb221lITTO/dkXhV8U61IBakwurzeRvQVTP/AxWolTgSaegnq28aEO6n0 GHeKthzuN59ceqqJy3zzXTbFgzG+XwjpQtCIREmN1C2r8ao6W9RnBuJHiQ6I +IFj0/WBvRI2FOpjCMRerz0ZSC4SoqnCVZcc32KfXfCSBuhJz+kkoIlezQ4e iahyKeMqRtd2LDvsFpxdy1+eskSOXH8eZyow7cxKSrUtGEpMqkw4WbYEUKl1 w1KSdz/c2UBa2X0RrRBtwTlYFZUj24R8E1SaBPcNSfSCGbnM7FH+C3T0EGXb nf/+zT1ZMXFUdK5DyKyGWDOvVLtvmA5L4lLDkxHbuN8vlvp2N0GwcLQGG8kF xLAxj1O60jyjr9CVsp/ZeZPaB+s0CaeKQD65BAveBJyLb9YXBj1ggjbscC2h rI4Ep3KMshKEuHMW0Sbe064iIRGn7OMoY+zIxHnGjkrAJcQjLqVRJWoXNUJp Ol2n9OSsQ+N4DBanWnqqL7mXjjf9GGklX2OYSu8P504o0Jc6f+T+yoQwEvLm V6HUvU55rtS4UKfWxnUy0vJDmFBmucSSzI296aYn79saO77nhxyo9YzWIDga IbZekX3cxsnTXCwy52DH6Toiq/oXEB6wR064ODpsv7bqNa1PmCU1c5oQEgRY QhF5UYFWKOPoqmU9Rs0ODDiJ1CB8wEN2bKJsIOZDXYL0GfVG160ts9q5c5Yg 7C/GgzKv++C6NBhyvDtr3Cork7NC0HEygSL/rC3kakqmkTKobHhkRaMuKzFQ lC/63hFpTMzIRpUgGap/ilw7GlUM6eVojGlIlBStqIs7JmW+aWlPcqBTXwet Sd8d0xNuea4Z2xI2hsHSWQKIITTcJXpoWDklBSo5Ow/hN8qb/PLZ+DHhoZ9U K1AXxs18fCIIDn/Q7ObxjkRDkKdzno9V81WWxved8YZPy5azKpnTbFafof9B F68ecvYl54yC2LaUq7/nu4TFTuqZMdoKdbT8KlM/XMD7WehIGeeR4LtWMplP GqS8Lk4IPgziBdldY4+6c0cRADlSzWomVjB3G45Z3WmjCHvsDOETrmHOW9uR Cae0j3ECBe1geY0Lu1XuIr+HmO/LjD6YcCajCvVm8xCz6A0fJKcYE5OhoqdE coaXEvOflgRD9rnbLgGEw4nS9FyTzSGcps0pq8HBdFfy9RBw5RjIIy6gjmei C1m8qDoodx/hKGPyvn/xHhFWgpBIS0mloooTdkwIkS0Iuq0d5xo0jAY0Ve88 Zv0qNL1JH1g0l2NUYnk9G1ehFCiVU52MSKMuEZUG01/a3i1BJE1lMIyd9/1w +1nSlYCp63ci+eMZoQVyxE6z0IgB+a9FkIImaqah7nznhVaWHCPMnIKKeci5 XtadGlkj4XuUMeCkd2qhEOdteINkY6D25HNc7CsltzcwqZLNARN7xmUGxVw2 qEJnz6mkKEjqkhnYJd/M0ikmsUANBk7ZRf03kF/h0C047qw0KNnl8VKL+wD7 6SmaXzy/4XDvONOaquqbxekznYVrywlAkkkeVPKinRF79dVXRyfQHiUPSKLB oM2yDL0g6kKiy4uuyktKjWoYsh56Jzxvm55TZF3oqYj0iArD576oqVpSzg8F aPyGXYAqsmC3MfXcEn5QYv30vIZHChw9BalwjNwgKQtJaIOX1c0X1UdlxCD6 IG4ENhAzgfjXpxlpL9Adz5AwP+qaKoVY1l6MQvhl9GmWZt0ou1Vz4i3QGem/ AoPFtFyzbIDvQp64v9c8IJ+Q0R6eR9oGBqneFwrLsuGZtJUPFYYaCC4cbDQG 56IdMyiqaUo3O2Z4hy0QaB8F3m0x3c4U2Nq1k5lJWGaxa4IhGGZD8Gww23xU 4P9A/4H53YIm0G59vWUZWADfgSapsXST2ocMFjSnbEGjscgjEHoi0XpM6Qx1 z6LK78vWI5oYYXrfaVMChjAJ0d8RBlS+DqVcA+sE1//UxzUXEF5zQVfIBW4O vh+8myYSFHgsQfyiVkjxmIlhU3IomUGS4ehJs6VdOornNkyELzvhnRoZ9Ot3 2acZggFqjv8alYILKYMS5lETh1CQBPxBXIGDmlBQc5SGcqNf64T/+OYNOYHZ IXn9D31usDBNicGgICxiAO+a9TnuIk4RSwQMJ6RQDp9eQBYAN83Q9lsHkWVT JK4HBEDLiTJwqwGX3kDW8yhsF9AKsnskxOxSfiIy6rU82g9c3Y1N1Ok2MVFV AKkEl1pwKD/xaZ/xx9ieyPBw1n/iI7rB8ivYsJ0UsUcLdusMhF0zD1Hh1EDA 3y/qOQGGVJl68/T41YsXT18+efokioc5i89vqzPGOsgkPKWYX/GCyL2ZV8wS 8hASLZ6QNfrl+mB1hcyEKDQg1hBNldXIOd7N6QHZzNsYT2qTFVl/9mFbSdPM NkIT2VaY9+TLx+161klqqpr6Awes7kCvAe7y0KrdJyQQbaUeqsAkoT5M546R cKYFXWDrw0jWvqZrjWKVMcc8Gvo2gVMzYjC/hVPQRg5MxWYuJIu5gexaMmHr C6oAY7HidFCOMCwtSS9TBZALRB8lEh6wMaMirsn9bTJ1mHCM3B2ZFRegoIuI 2UMuefwLrnKKjIbqnfTRlOyi2TM6SNozUVBLV2lchOLbcJzPzXUd6PWYSiSe DUGsv9AK5YrDSU7WOaXLeeM7ZhJblFsmFGWVW68ajt4RcsAJ27BRcdqGyh2N cmPwpaYtQiOGWFgITeQC0ZIpWm3D1163PSblQR0XPg8aI3/bIjkYFRHnJWWs BG3Bc1OawhjO5yInzRDs1pJswuS/liJXr4mID6GBbS3Xheg6QZnJRtzeC7+a BM/RSsMIrduFzos8gnocJniMuCcEYmCzGou4WaktTyQUMT7JBmQ95cN7V40P rUWdWTAtpYQ4GUrHDjT1Y9dDfrXQJTLxJDQV6lIYo7qkGtTUw2nHNQQp87Tz xyKiv+IaNUpW7jNSkZN2FCmzaGQ0nBkZ6Q1RfqHRCPieoFx8pRUJLVE2B7mt 1SubX6/MrT3MK0CFzymHxVch0/RNxVSNw+ktPn2FBUkFljpu5cHPSoHBz280 EuszgfRBBtCEOFosfcj114CavBCcfRi4EieSW6Y6q9GJ3OcSeDFN2yMGyqgu pDOgwJFFCP6RkJYsL34AKxEMjJlJBCJDUg6V+ZXTguWhiFqxB8K138vy988a jPMK+N/ix4nfDWHhzohquXIlSGjRjES5yQTIVpAV+8iSieRFs8wRRsUmelpj OahJ5AC7Bxyc9gtAe069Seifp0RC0y0mGSq7sLac07UKOQXdIBJ8q4sLIdWU 9DvYubjv96SZCcjo0R4ZCdHR4HXXcgrRjOEK0MLgb0NVEo/zwsxtklnRDEmo Uww8vU3lRGp9FMpq1BAqrionXhN3mEtXju5t0goCyG+04/zSdOJydlzkMdAo RK5x5iaEIZ83i8FW4W0dmFWeCfGSZjsabB+bV1yRj2dBTrDtPw+uZxQ13QUu lGOUeNoHgxgIA5twcTsRL7v+jnRk8R8fYfRXmD2B//wtqv7vOEhE/8SKdvo3 pr/v+R/7Xn4chC+/L/692J+B/D9wbmefQgf8a3f/JR1K/z5lSoZ/zj5oZl1Q YL/JPph5fseDnwb7Ivfg73jW8Isj3PbDJ2RacTk/PSr4MpjV5VlbLtNLAcRK v6h+v5e/VPbgztiJAlL6OK02w2CW1Jvl01D9mXDeqqUEaOEvIeeSAh9GUsNC TF9Bi4JqQCVPTK1KlDAh5EBGJlYTF+sl0dAyEHzr3RZyaiGjrhc2pJeT71iN zmdFBNMKr+ghwPLH+i/5S/q8bcfn9GVyP6vztmJ8mGrR6HFh5yETRitNHZpu F3EmlIApr7iLOTqlJPu6QGOhYllUg5LpbxuuaJoqT+bmZ7Jprlh/xaslK9ft zK3eB0FxYBKOxPuoJjYLQ4mH4L1g3rSjbC1IdTAl3hjKAvURcGSh9z5OgRcn o7REeNdUKLBlcj0LrmyViGdrWF+VNaThEKqPwhzlSeIFyR8gPbxDIqCw3bSJ /zap/OUY5nPOZQ+92bqrg+oIIkEaHmcostvP7KWDoYkV909O+kzuML2oXJqq jv1Lx/KP3F3490+4v4p92U4H8dcgiHf2KPs3RBd/2e/575p7zvylF6+/YsbX 3LnpXN2sN7eufRSm+Jb54O+cRv67sV6wszc3nUb7d2MtYtfvv1C5uEEzX/b7 m6kiN2pJjbUv/73fhjuf2FcTSQvOLVBDOMhqPuGmVaVn5zUdtJ8EKKMY8VkG x890+JIcjerHaYOAn8gn70NQOwKN6P1UVKA0BXKPy1ZitppqRaFCTilooZip KojinKmGKWmJ04J9S6BS1OvNQtETuZQU5pkkPcywBjk1oBU/6wu7eWcB+plr X9ZpZov2xJdNXHww4Oc5mWi+s2cpA+eyPKuJo9bcII3UOYst2h2+mNSi3fMx SW9yQ5O8parZzY1kY+Ue6eUr/IDnFWeSYXCJNNi/bsqFUlxKQeuAqI84UEUb 4MAaX+bR9CMGh3xSqWUfuZUYd/kCMceKmtnlWCI9bbw0j+7QYAc5JayXUgyr J2PBq0OhpGU8begBYfdkTkmNq0cZCjIb+nKBkzBNhT4PCewRcuy6vP3C8DX4 YZSFTTrIdDdDJyEVYjgikc3jIvT46ebszJNJodPdQt1LYnxMT1X+XX2ES3K7 1HrW/Ug7KKe9d9eFM96cUgyTOYGYb98hyK/qI7w7+aHYtRb8m9HJmhTPMfNw xGBcqsq55qIUmdliEQQrQQ6Quk/I+H3ADOy4kArP6jL3sZA+MiIzl8YelcSN 6PzNSF+f/CTOtkCaECXsayFctibhW/hFcYrMFi0fdW8Fsf+K8LmZGADTMsYz xnHwekEYIoXryTsIbB0qDl3damAiN6Et5Uokj7sTCUIyvuKKGCHZ2Iu9TpRw +stp4leo3/gnKviNtASDhESJTMt5U/ViMJU3/aGqI1jKjz8Z6r9DdZHU2fAK +uc7gnK8CygY0GMq/tXsHTRw4H8bf57p6fha7dio9zufuYkifxNNOBnsjgdu Ovzcz+Mnr7Ml7N/1M3Xt3w5/24170LRX6LK7//5RG0b/JpPJ3/l71eG/4Of+ tKgy3i+6nZqDauQvJFrzAxYAwYMqmghIH7NFU8Vc0nSlGnD9N80BN9eh+ouC iL5gRODp1kUyW68nCucaQqYJE4ioARA5PYn3FC8JHxgX+tPkNs4krbAnMQYq ELh0td5o+eBcXNjtv3+K2kg1yzc5vDUPQi4dWSpYMItAFqDYxB0Y0/FkSmvE WVjdSC9UgmSn+hBaAaf1rNtNmAg/o94Eq1guHM6Z5It6k7CEY7hd7Jo8QRzn jYEqBE8KkLBvchlCyE6AlLI1+ix7pZxR8pMYPIsL6sI1l6yTuMr2eO9QFU9D B6nuyUU1Z51E0k0TrfZis8AdK0z9lMuO6dobX9ouZIgmGjpzEb3mYlpHWL3N 9ztS16PFG8OV91npmVLSICKTDI8XO3YXMYN5WsYQesQjOG3LOaW6crfkxBHj bvURdw3G5ZEVlvlS2L0u73NNq8eY8gMWGHc3WY+4vBT/5MYfOfcb1NIQ4E5k I+ukWKtsDuM+ZuZfTEFnXmFfA8tzCRcGljqyy0b9lCwr3v6Xgdbo1f6L//jN ywNhCKYwNLT0QjMu4pKcV/Je4RZ7Kb+DJrSMR3pgZOje73DlsAVnOW3WGHf1 UBni+hphQeVV6gNIAUkJfCuyVEpeJ2gnI9lOlUKIwWD0pOlZdg6gJRixgGKe 86EbiAxKz/S2F7b+kgcoZiSVrTHUrG93jcXESnHMr/Zf/sdvnh+A/bdkXiFo xnvxYdzw/W/haySkuaxnSJobY7uYBNbwE5TYgrQ67uhe0rMR3oxFJzGgBTeL kJfw8ie1sq65fkIlAzJI0hk7rYKtSsYsQapH/PBsw7ipytqz9AvO5Zbc0G3h k630PTt4d3EySz1mHW5BTEIQotpIJGkecJwd69F9mvszIMzD2o3Pjl4eDeo2 YpEJKheqHgW8hv1EIIdW8QYsXdi/W+eoBQS+ITGBivSAh4fOeKp39E1INUC3 N2yTOd/2EIxIbRf7UV2mkDF1wEjw/P1Y7N/+OK9uzw6kLtmeJDLvIQ3CZrlS bDsSnXAZqT3M4/nxzZtR8fTp3qjYe4JlvV/BzeV/ws8Wey/Fe7X3RhexmtmH KNUAnvt1jzIYclo6dW92+7Z2jy7AK7uI/dsbUUev7tmuXkmXguONxkxP9oPn Xq3YDQK7rmN+KyLs+3Gyt2NfkDrv9wNcl2SGEz91ujOIXwseGtHMeCfm/uGd w4N0g9CkOGr8RlvCTidP0086NhfmgCF1KARi/m2/Ef+fxq6sp20gCL/7V1jp C0hxRLhBQtVCQhsJUhRQK1RVlSFWcRscFCeEQ/z3znwzezhxELyssB17rzl3 5ptwIBK3m/i1S3LSLWoHRkrrXJbRxcb6dwbdh5+HntXt7xSjSsL2Gr1jfVUH w8lAgeJW3Kf36bWwFjQYfJUYidVJmQROKgG5HUaHYO3T+VggMXz+hIvnckPq etXMZa1Ey3eZmInTuintk4Dl7/RTD12z/KsoCrYvP254wdhnR5vb+YQdcFru d+APqQYdf0G95iCZ1QFdeYF5k1n4aYfQpASQA85WUntSnzPCH58BIJpj+Vll m46eLa4Zv8OoSzX4yXXDpzZfau5pGRkJChFAh/am1BwdWGFhF6KqP0tmV/2E BYXrBJeixKwVgO5ZAc4L8mNDsnyAtDlqIBD4dsrWIO2jRXb9gS3Ngqac3bCU s3L3sjKGgaXzcI/astprSsQ0Hw7gItpuLVA0HuZuLaSzKv3veWyM9h6bXEyg ERNoOhwuSSRBhx2/Pz5LUM+HcFPx9B7GWKDJeOR2sYQ2Y4ppc2QTmxLr+0gd jLmH1mdwVfurnzoFvwITzjpiK3OZl/oeiVlnVv1IIj5FrL9mkZQzBsvLNaRF woMK0qoYsDybJh02MPQtaxLliPxna58VgFVQ9AB3/kEdXBf/uQXPE2Nc3mML gdtEa851GQIdfjjDJmFtlw3Q2X2TC6Ig3YrBxlBzLZvehtOjcwIECM3YQa5C XiTD7EEQfPNsXrqCzLlWICcC1NdoLq4mnU5R51LGQXyBy/6E2bBhuPlVCA/o oOoshskgU7TsoFrhUgGnwESJJNHSJYI0kH5Ne7CxiGdMe1lBxu0j4A5XMNpy ZPG6oBeXEuVIUIvqSX1Ta51Mqp2NHDHViYNmABo9yR5EqrlaTSHhhoJj42mD /prUtk3bcLtpNtFumS2022Yb7Y7ZQbtrdtHumT20+2bfNKONpwNzgP8N/XF7 bI7RnpgTtB3TQds1XbSn5tTUiZhB97I7+N7tLAmT6wVWy3R5sL99EHBOzfNU DriKSSZJAquCleczKOfJFdvDgubve3QhRi5P8+sn0eLFJRToE2+ywn5BYBkP OW5WbWSNTW3UaZKBqwRQQTVna9Cq1ITQ4juVvG5dXWfTBMgG79UScLjfKFLL WAmYVVZ5z0jV6kl2Mbat9SO+ZJOx2uY3mVU2V5n20SqA87YeT6chTjcKH5Hu 3qxxjAn3hqnflZPoep9aszYQ0Z0sgak0SKnK/qSj384h2dCQaejVFuwqtiWG ZCVb2gPJa+/FSJnFYRpxo76LAusl03BIUnw3rpv/auAnij5h6Ldi+cW9lh8z Pofjb57u/vujrBug9OLjo/zGYmCelwqstzSqugEBigfDaJHS+6DnM7nbIe/7 aKsD53QZzjMno1eiOpmOZYtlw6MGgMWc49vz+Uk6L20/HxlYAU4JkjypOmk/ 95JO61/6MrsbW3iUbJiURc7wHcRBpewanG6QVTaH2Z+C27D6fOowkzTmgHMG VdWOAugVrygL+tArKY7EojnS8jglSV6+8bfp6sndhE0mWsCvXMP0PrU3LlLi ZBwve3ueFjM8Tzzi9ZzY/h2pehcTjiq2D/f5ycvZaJQ/poW9eM4H/AVJ5fF9 OZarPOd0p5OSYI6Ps+IvF9qmOxKgb4GQuBAK7TSuGSSzaA9TLeRT2Yr+A5uf Ht5bkAEA --> </rfc>