<?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 version 1.6.17 (Ruby 3.1.3) --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9369" docName="draft-ietf-quic-v2-10" obsoletes="" updates="" category="std" consensus="true" xml:lang="en" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.15.3 --> <front> <title abbrev="QUICv2">QUIC Version 2</title> <seriesInfoname="Internet-Draft" value="draft-ietf-quic-v2-10"/>name="RFC" value="9369"/> <author initials="M." surname="Duke" fullname="Martin Duke"> <organization>Google LLC</organization> <address> <email>martin.h.duke@gmail.com</email> </address> </author> <dateyear="2022" month="December" day="15"/>year="2023" month="May"/> <area>Transport</area> <workgroup>QUIC</workgroup> <abstract> <t>This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.</t><t>Note<t> Note that "version 2" is an informal name for this proposal that indicates it is the secondstandards-trackversion of QUICversion.to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossificationrisk.</t>risks.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> The latest revision of this draft can be found at <eref target="https://quicwg.org/quic-v2/draft-ietf-quic-v2.html"/>. Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-quic-v2/"/>. </t> <t> Discussion of this document takes place on the QUIC Working Group mailing list (<eref target="mailto:quic@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/quic/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/quic/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/quicwg/quic-v2"/>.</t> </note></front> <middle> <section anchor="introduction"> <name>Introduction</name> <t>QUIC version1<xref target="QUIC"/>1 <xref target="RFC9000"/> has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see <xreftarget="QUIC-INVARIANTS"/>).target="RFC8999"/>). If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytesalways beingthat are usually 0x00000001.</t> <t>In QUIC version 1, Initial packets are encrypted with the version-specificsaltsalt, as described in <xref section="5.2" sectionFormat="of"target="QUIC-TLS"/>.target="RFC9001"/>. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the version 1 key derivation and packet formats.</t> <t>Finally, <xreftarget="QUIC-VN"/> providestarget="RFC9368"/> describes two mechanismsforendpoints can use to negotiatethewhich QUIC version touse.select. The "incompatible" version negotiation method can support switching from any QUIC version to any other version with full generality, at the cost of an additionalround-tripround trip at the start of the connection. "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically.</t> <t>QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms. The changes provide an example of the minimum set of changes necessary to specify a new QUIC version. However, note that the choice of the version number on the wire is randomly chosen instead of "2", and the two bits that identify eachlong headerLong Header packet type are different from version 1; both of these properties are meant to combat ossification and are not strictly required of a new QUIC version.</t> <t>Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks.</t> </section> <section anchor="conventions"> <name>Conventions</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="differences-with-quic-version-1"> <name>Differences with QUIC Version 1</name> <t>Except for a few differences, QUIC version 2 endpoints <bcp14>MUST</bcp14> implement the QUIC version 1 specification as described in <xreftarget="QUIC"/>,target="RFC9000"/>, <xreftarget="QUIC-TLS"/>,target="RFC9001"/>, and <xreftarget="QUIC-RECOVERY"/>.target="RFC9002"/>. The remainder of this section lists the differences.</t> <section anchor="version-field"> <name>Version Field</name> <t>The Version field of long headers is 0x6b3343cf. This was generated by taking the first four bytes of the sha256sum of "QUICv2 version number".</t><ul empty="true"> <li> <t><strong>RFC Editor's Note:</strong> Please remove the sentence below prior to publication of a final version of this document.</t> </li> </ul> <t>This version number will not change in subsequent versions of this draft, unless there is a behavior change that breaks compatibility.</t></section> <section anchor="long-header-packet-types"> <name>Long Header Packet Types</name> <t>All version 2long headerLong Header packet types are different. The Type field values are:</t> <ul spacing="normal"> <li>Initial: 0b01</li> <li>0-RTT: 0b10</li> <li>Handshake: 0b11</li> <li>Retry: 0b00</li> </ul> </section> <section anchor="cryptography-changes"> <name>Cryptographychanges</name> <t>The values below were chosen randomly.</t>Changes</name> <section anchor="initial-salt"> <name>Initial Salt</name> <t>The salt used to derive Initial keys in <xref section="5.2" sectionFormat="of"target="QUIC-TLS"/>target="RFC9001"/> changes to:</t> <artwork><![CDATA[ initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9 ]]></artwork> <t>This is the first 20 bytes of the sha256sum of "QUICv2 salt".</t> </section> <section anchor="hkdf-labels"><name>HKDF<name>HMAC-based Key Derivation Function (HKDF) Labels</name><ul empty="true"> <li> <t><strong>RFC Editor's Note:</strong> Please ensure that the strings in quotes are not split up in a line break in this section.</t> </li> </ul><t>The labels used in <xreftarget="QUIC-TLS"/>target="RFC9001"/> to derive packet protection keys (Section <xref section="5.1" sectionFormat="bare"target="QUIC-TLS"/>),target="RFC9001"/>), header protection keys (Section <xref section="5.4" sectionFormat="bare"target="QUIC-TLS"/>),target="RFC9001"/>), Retry Integrity Tag keys (Section <xref section="5.8" sectionFormat="bare"target="QUIC-TLS"/>),target="RFC9001"/>), and key updates (Section <xref section="6.1" sectionFormat="bare"target="QUIC-TLS"/>)target="RFC9001"/>) change from"quic key""quic key" to"quicv2 key","quicv2 key", from"quic iv""quic iv" to"quicv2 iv","quicv2 iv", from"quic hp""quic hp" to"quicv2 hp","quicv2 hp", and from"quic ku""quic ku" to"quicv2 ku","quicv2 ku" to meet the guidance for new versions in Section <xref section="9.6" sectionFormat="bare"target="QUIC-TLS"/>target="RFC9001"/> of that document.</t> </section> <section anchor="retry-integrity-tag"> <name>Retry Integrity Tag</name> <t>The key and nonce used for the Retry Integrity Tag (<xref section="5.8" sectionFormat="of"target="QUIC-TLS"/>)target="RFC9001"/>) change to:</t> <artwork><![CDATA[ secret = 0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f key = 0x8fb4b01b56ac48e260fbcbcead7ccc92 nonce = 0xd86969bc2d7c6d9990efb04a ]]></artwork> <t>The secret is the sha256sum of "QUICv2 retry secret". The key and nonce are derived from this secret with the labels "quicv2 key" and "quicv2 iv", respectively.</t> </section> </section> </section> <section anchor="version-negotiation-considerations"> <name>Version Negotiation Considerations</name> <t>QUIC version 2 is not intended to deprecate version 1. Endpoints that support version 2 might continue support for version 1 to maximize compatibility with other endpoints. In particular, HTTP clients often use Alt-Svc <xref target="RFC7838"/> to discover QUIC support. As this mechanism does not currently distinguish between QUIC versions, HTTP servers <bcp14>SHOULD</bcp14> support multiple versions to reduce the probability of incompatibility and the cost associated with QUIC version negotiation or TCP fallback. For example, an origin advertising support for "h3" in Alt-Svc should support QUIC version11, as it was the original QUIC version used byHTTP/3, and thereforeHTTP/3; therefore, some clients will only support that version.</t> <t>Any QUIC endpoint that supports QUIC version 2 <bcp14>MUST</bcp14> send, process, and validate the version_information transport parameter specified in <xreftarget="QUIC-VN"/>target="RFC9368"/> to prevent version downgrade attacks.</t> <t>Note that version 2 meets the<xref target="QUIC-VN"/>definition in <xref target="RFC9368"/> of a compatible version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions <bcp14>SHOULD</bcp14> support compatible version negotiation to avoid a round trip.</t> <section anchor="compatible-negotiation-requirements"> <name>Compatible Negotiation Requirements</name> <t>Compatible version negotiation between versions 1 and 2followfollows the same requirements in either direction. This section uses the terms "original version" and "negotiated version" from <xreftarget="QUIC-VN"/>.</t>target="RFC9368"/>.</t> <t>If the server sends a Retry packet, it <bcp14>MUST</bcp14> use the original version. The client ignores Retry packets using other versions. The client <bcp14>MUST NOT</bcp14> use a different version in the subsequent Initial packet that contains the Retry token. The server <bcp14>MAY</bcp14> encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched, to enforce client compliance.</t> <t>QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1. After switching to a negotiated version after a Retry, the server <bcp14>MUST</bcp14> include the relevant transport parameters to validate that the server sent the Retry and the connection IDs used in the exchange, as described in <xref section="7.3" sectionFormat="of"target="QUIC"/>.</t>target="RFC9000"/>.</t> <t>The server cannot send CRYPTO frames until it has processed the client's transport parameters. The server <bcp14>MUST</bcp14> send all CRYPTO frames using the negotiated version.</t> <t>The client learns the negotiated version by observing the first long header Version field that differs from the original version. If the client receives a CRYPTO frame from the server in the original version,thatit indicates that the negotiated version is equal to the original version.</t> <t>Before the server is able to process transport parameters from the client, it might need to respond to Initial packets from the client. For these packets, the server uses the original version.</t> <t>Once the client has learned the negotiated version, it <bcp14>SHOULD</bcp14> send subsequent Initial packets using that version. The server <bcp14>MUST NOT</bcp14> discard its original version Initial receive keys until it successfully processes a Handshake packet with the negotiated version.</t> <t>Both endpoints <bcp14>MUST</bcp14> send Handshake and 1-RTT packets using the negotiated version. An endpoint <bcp14>MUST</bcp14> drop packets using any other version. Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate such packets.</t> <t>The client <bcp14>MUST NOT</bcp14> send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can accept 0-RTT and then process 0-RTT packets from the original version.</t> </section> </section> <section anchor="tls-resumption-and-newtoken-tokens"> <name>TLS Resumption and NEW_TOKEN Tokens</name> <t>TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them. Clients <bcp14>MUST NOT</bcp14> use a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection,orand viceversa.</t>versa. When a connection includes compatible version negotiation, any issued server tokens are considered to originate from the negotiated version, not the original one.</t> <t>Servers <bcp14>MUST</bcp14> validate the originating version of any session ticket or token and not accept one issued from a different version. A rejected ticket results in falling back to a full TLS handshake, without 0-RTT. A rejected token results in the client address remaining unverified, which limits the amount of data the server can send.</t> <t>After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than the original one.</t> </section> <section anchor="ossification-considerations"> <name>Ossification Considerations</name> <t>QUIC version 2 provides protection against some forms of ossification. Devices that assume that all long headers will encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets.</t> <t>However, many middleboxes, such as firewalls, focus on the first packet in a connection, which will often remain in the version 1 format due to the considerations above.</t> <t>Clients interested in combating middlebox ossification can initiate a connection using version 2 if they areeitherreasonably certain the server supportsit, orit and if they are willing to suffer a round-trip penalty if they are incorrect. In particular, a server that issues a session ticket for version 2 indicates an intent to maintain version 2 support while the ticket remains valid, even if support cannot be guaranteed.</t> </section> <section anchor="applicability"> <name>Applicability</name><t>This version of<t> QUIC version 2 provides no change from QUIC version 1relating tofor the capabilities available to applications. Therefore, allApplication LayerApplication-Layer Protocol Negotiation (ALPN)(<xref target="RFC7301"/>)<xref target="RFC7301"/> codepoints specified to operate over QUIC version 1 can also operate over this version of QUIC. In particular, both the "h3" <xreftarget="H3"/>target="RFC9114"/> and "doq" <xref target="RFC9250"/> ALPNs can operate over QUIC version 2.</t> <t>Unless otherwise stated, all QUIC extensions defined to work with version 1 also work with version 2.</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1.</t> <t>The mandatory version negotiation mechanism guards against downgrade attacks, but downgrades have no security implications, as the version properties are identical.</t> <t>Support for QUIC version 2 can help an observer to fingerprint both client and server devices.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name><t>This document requests that IANA add<t>IANA has added the followingentryentries to theQUIC version"QUIC Versions" registry maintained at<<eref target="https://www.iana.org/assignments/quic/quic.xhtml#quic-versions"/>>.</t><eref target="https://www.iana.org/assignments/quic" brackets="angle"/>.</t> <dl spacing="compact"> <dt>Value:</dt><dd> <t>0x6b3343cf</t> </dd><dd>0x6b3343cf</dd> <dt>Status:</dt><dd> <t>permanent</t> </dd><dd>permanent</dd> <dt>Specification:</dt><dd> <t>This Document</t> </dd><dd>RFC 9369</dd> <dt>Change Controller:</dt><dd> <t>IETF</t> </dd><dd>IETF</dd> <dt>Contact:</dt><dd> <t>QUIC WG</t> </dd><dd>QUIC WG</dd> </dl> <dl spacing="compact"> <dt>Value:</dt><dd> <t>0x709a50c4</t> </dd><dd>0x709a50c4</dd> <dt>Status:</dt><dd> <t>provisional</t> </dd><dd>provisional</dd> <dt>Specification:</dt><dd> <t>This Document</t> </dd><dd>RFC 9369</dd> <dt>Change Controller:</dt><dd> <t>IETF</t> </dd><dd>IETF</dd> <dt>Contact:</dt><dd> <t>QUIC WG</t> </dd> <dt>Note:</dt> <dd> <t>QUIC<dd>QUIC WG</dd> <dt>Notes:</dt> <dd>QUIC v2 draftcodepoint</t> </dd>codepoint</dd> </dl> </section> </middle> <back> <displayreferencetarget="H3"target="RFC9000" to="QUIC"/> <displayreference target="RFC9001" to="QUIC-TLS"/> <displayreference target="RFC9368" to="QUIC-VN"/> <displayreference target="RFC9002" to="QUIC-RECOVERY"/> <displayreference target="RFC9114" to="HTTP/3"/> <displayreference target="RFC8999" to="QUIC-INVARIANTS"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9002.xml"/> <referenceanchor="QUIC"> <front> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"> <organization/> </author> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"> <organization/> </author> <date month="May" year="2021"/> <abstract> <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t> </abstract> </front> <seriesInfo name="RFC" value="9000"/> <seriesInfo name="DOI" value="10.17487/RFC9000"/> </reference> <reference anchor="QUIC-TLS"> <front> <title>Using TLS to Secure QUIC</title> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"> <organization/> </author> <author fullname="S. Turner" initials="S." role="editor" surname="Turner"> <organization/> </author> <date month="May" year="2021"/> <abstract> <t>This document describes how Transport Layer Security (TLS) is used to secure QUIC.</t> </abstract> </front> <seriesInfo name="RFC" value="9001"/> <seriesInfo name="DOI" value="10.17487/RFC9001"/> </reference> <reference anchor="QUIC-VN">anchor="RFC9368" target="https://www.rfc-editor.org/info/rfc9368"> <front> <title>Compatible Version Negotiation for QUIC</title> <authorfullname="David Schinazi"initials="D."surname="Schinazi">surname="Schinazi" fullname="David Schinazi"> <organization>Google LLC</organization> </author> <authorfullname="Eric Rescorla"initials="E."surname="Rescorla">surname="Rescorla" fullname="Eric Rescorla"> <organization>Mozilla</organization> </author> <dateday="6" month="November" year="2022"/> <abstract> <t> QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-quic-version-negotiation-13"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"> <organization/> </author> <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="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"> <organization/> </author> <datemonth="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="QUIC-RECOVERY"> <front> <title>QUIC Loss Detection and Congestion Control</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"> <organization/> </author> <author fullname="I. Swett" initials="I." role="editor" surname="Swett"> <organization/> </author> <date month="May" year="2021"/> <abstract> <t>This document describes loss detection and congestion control mechanisms for QUIC.</t> </abstract>year="2023"/> </front> <seriesInfo name="RFC"value="9002"/>value="9368"/> <seriesInfo name="DOI"value="10.17487/RFC9002"/>value="10.17487/RFC9368"/> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references> <name>Informative References</name><reference anchor="H3"> <front> <title>HTTP/3</title> <author fullname="M. Bishop" initials="M." role="editor" surname="Bishop"> <organization/> </author> <date month="June" year="2022"/> <abstract> <t>The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.</t> </abstract> </front> <seriesInfo name="RFC" value="9114"/> <seriesInfo name="DOI" value="10.17487/RFC9114"/> </reference> <reference anchor="QUIC-INVARIANTS"> <front> <title>Version-Independent Properties of QUIC</title> <author fullname="M. Thomson" initials="M." surname="Thomson"> <organization/> </author> <date month="May" year="2021"/> <abstract> <t>This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol.</t> </abstract> </front> <seriesInfo name="RFC" value="8999"/> <seriesInfo name="DOI" value="10.17487/RFC8999"/> </reference> <reference anchor="RFC7838"> <front> <title>HTTP Alternative Services</title> <author fullname="M. Nottingham" initials="M." surname="Nottingham"> <organization/> </author> <author fullname="P. McManus" initials="P." surname="McManus"> <organization/> </author> <author fullname="J. Reschke" initials="J." surname="Reschke"> <organization/> </author> <date month="April" year="2016"/> <abstract> <t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t> </abstract> </front> <seriesInfo name="RFC" value="7838"/> <seriesInfo name="DOI" value="10.17487/RFC7838"/> </reference> <reference anchor="RFC7301"> <front> <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title> <author fullname="S. Friedl" initials="S." surname="Friedl"> <organization/> </author> <author fullname="A. Popov" initials="A." surname="Popov"> <organization/> </author> <author fullname="A. Langley" initials="A." surname="Langley"> <organization/> </author> <author fullname="E. Stephan" initials="E." surname="Stephan"> <organization/> </author> <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="RFC9250"> <front> <title>DNS over Dedicated QUIC Connections</title> <author fullname="C. Huitema" initials="C." surname="Huitema"> <organization/> </author> <author fullname="S. Dickinson" initials="S." surname="Dickinson"> <organization/> </author> <author fullname="A. Mankin" initials="A." surname="Mankin"> <organization/> </author> <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><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9114.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8999.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7838.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/> </references> </references> <section anchor="test-vectors"> <name>Sample Packet Protection</name> <t>This section shows examples of packet protection so that implementations can be verified incrementally. Samples of Initial packets from both the client and server plus a Retry packet are defined. These packets use an 8-byte client-chosen Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are included. All values are shown in hexadecimal.</t> <section anchor="keys"> <name>Keys</name> <t>The labels generated during the execution of the HKDF-Expand-Label function (that is, HkdfLabel.label) and part of the value given to the HKDF-Expand function in order to produce its output are:</t> <t>client in: 00200f746c73313320636c69656e7420696e00</t> <t>server in: 00200f746c7331332073657276657220696e00</t> <t>quicv2 key: 001010746c73313320717569637632206b657900</t> <t>quicv2 iv: 000c0f746c7331332071756963763220697600</t> <t>quicv2 hp: 00100f746c7331332071756963763220687000</t> <t>The initial secret is common:</t> <artwork><![CDATA[ initial_secret = HKDF-Extract(initial_salt, cid) = 2062e8b3cd8d52092614b8071d0aa1fb 7c2e3ac193f78b280e72d8f5751f6aba ]]></artwork> <t>The secrets for protecting client packets are:</t> <artwork><![CDATA[ client_initial_secret = HKDF-Expand-Label(initial_secret, "client in", "", 32) = 14ec9d6eb9fd7af83bf5a668bc17a7e2 83766aade7ecd0891f70f9ff7f4bf47b key = HKDF-Expand-Label(client_initial_secret, "quicv2 key", "", 16) = 8b1a0bc121284290a29e0971b5cd045d iv = HKDF-Expand-Label(client_initial_secret, "quicv2 iv", "", 12) = 91f73e2351d8fa91660e909f hp = HKDF-Expand-Label(client_initial_secret, "quicv2 hp", "", 16) = 45b95e15235d6f45a6b19cbcb0294ba9 ]]></artwork> <t>The secrets for protecting server packets are:</t> <artwork><![CDATA[ server_initial_secret = HKDF-Expand-Label(initial_secret, "server in", "", 32) = 0263db1782731bf4588e7e4d93b74639 07cb8cd8200b5da55a8bd488eafc37c1 key = HKDF-Expand-Label(server_initial_secret, "quicv2 key", "", 16) = 82db637861d55e1d011f19ea71d5d2a7 iv = HKDF-Expand-Label(server_initial_secret, "quicv2 iv", "", 12) = dd13c276499c0249d3310652 hp = HKDF-Expand-Label(server_initial_secret, "quicv2 hp", "", 16) = edf6d05c83121201b436e16877593c3a ]]></artwork> </section> <section anchor="sample-client-initial"> <name>Client Initial</name> <t>The client sends an Initial packet. The unprotected payload of this packet contains the following CRYPTO frame, plus enough PADDING frames to make a 1162-byte payload:</t> <artwork><![CDATA[ 060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868 04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578 616d706c652e636f6dff01000100000a 00080006001d00170018001000070005 04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400 0d0010000e0403050306030203080408 050806002d00020101001c0002400100 3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000 75300901100f088394c8f03e51570806 048000ffff ]]></artwork> <t>The unprotected header indicates a length of 1182 bytes: the 4-byte packet number, 1162 bytes of frames, and the 16-byte authentication tag. The header includes the connection ID and a packet number of 2:</t> <artwork><![CDATA[ d36b3343cf088394c8f03e5157080000449e00000002 ]]></artwork> <t>Protecting the payload produces an output that is sampled for header protection. Because the header uses a 4-byte packet number encoding, the first 16 bytes of the protected payload is sampled and then applied to the header as follows:</t> <artwork><![CDATA[ sample = ffe67b6abcdb4298b485dd04de806071 mask = AES-ECB(hp, sample)[0..4] = 94a0c95e80 header[0] ^= mask[0] & 0x0f = d7 header[18..21] ^= mask[1..4] = a0c95e82 header = d76b3343cf088394c8f03e5157080000449ea0c95e82 ]]></artwork> <t>The resulting protected packet is:</t> <artwork><![CDATA[ d76b3343cf088394c8f03e5157080000 449ea0c95e82ffe67b6abcdb4298b485 dd04de806071bf03dceebfa162e75d6c 96058bdbfb127cdfcbf903388e99ad04 9f9a3dd4425ae4d0992cfff18ecf0fdb 5a842d09747052f17ac2053d21f57c5d 250f2c4f0e0202b70785b7946e992e58 a59ac52dea6774d4f03b55545243cf1a 12834e3f249a78d395e0d18f4d766004 f1a2674802a747eaa901c3f10cda5500 cb9122faa9f1df66c392079a1b40f0de 1c6054196a11cbea40afb6ef5253cd68 18f6625efce3b6def6ba7e4b37a40f77 32e093daa7d52190935b8da58976ff33 12ae50b187c1433c0f028edcc4c2838b 6a9bfc226ca4b4530e7a4ccee1bfa2a3 d396ae5a3fb512384b2fdd851f784a65 e03f2c4fbe11a53c7777c023462239dd 6f7521a3f6c7d5dd3ec9b3f233773d4b 46d23cc375eb198c63301c21801f6520 bcfb7966fc49b393f0061d974a2706df 8c4a9449f11d7f3d2dcbb90c6b877045 636e7c0c0fe4eb0f697545460c806910 d2c355f1d253bc9d2452aaa549e27a1f ac7cf4ed77f322e8fa894b6a83810a34 b361901751a6f5eb65a0326e07de7c12 16ccce2d0193f958bb3850a833f7ae43 2b65bc5a53975c155aa4bcb4f7b2c4e5 4df16efaf6ddea94e2c50b4cd1dfe060 17e0e9d02900cffe1935e0491d77ffb4 fdf85290fdd893d577b1131a610ef6a5 c32b2ee0293617a37cbb08b847741c3b 8017c25ca9052ca1079d8b78aebd4787 6d330a30f6a8c6d61dd1ab5589329de7 14d19d61370f8149748c72f132f0fc99 f34d766c6938597040d8f9e2bb522ff9 9c63a344d6a2ae8aa8e51b7b90a4a806 105fcbca31506c446151adfeceb51b91 abfe43960977c87471cf9ad4074d30e1 0d6a7f03c63bd5d4317f68ff325ba3bd 80bf4dc8b52a0ba031758022eb025cdd 770b44d6d6cf0670f4e990b22347a7db 848265e3e5eb72dfe8299ad7481a4083 22cac55786e52f633b2fb6b614eaed18 d703dd84045a274ae8bfa73379661388 d6991fe39b0d93debb41700b41f90a15 c4d526250235ddcd6776fc77bc97e7a4 17ebcb31600d01e57f32162a8560cacc 7e27a096d37a1a86952ec71bd89a3e9a 30a2a26162984d7740f81193e8238e61 f6b5b984d4d3dfa033c1bb7e4f0037fe bf406d91c0dccf32acf423cfa1e70710 10d3f270121b493ce85054ef58bada42 310138fe081adb04e2bd901f2f13458b 3d6758158197107c14ebb193230cd115 7380aa79cae1374a7c1e5bbcb80ee23e 06ebfde206bfb0fcbc0edc4ebec30966 1bdd908d532eb0c6adc38b7ca7331dce 8dfce39ab71e7c32d318d136b6100671 a1ae6a6600e3899f31f0eed19e3417d1 34b90c9058f8632c798d4490da498730 7cba922d61c39805d072b589bd52fdf1 e86215c2d54e6670e07383a27bbffb5a ddf47d66aa85a0c6f9f32e59d85a44dd 5d3b22dc2be80919b490437ae4f36a0a e55edf1d0b5cb4e9a3ecabee93dfc6e3 8d209d0fa6536d27a5d6fbb17641cde2 7525d61093f1b28072d111b2b4ae5f89 d5974ee12e5cf7d5da4d6a31123041f3 3e61407e76cffcdcfd7e19ba58cf4b53 6f4c4938ae79324dc402894b44faf8af bab35282ab659d13c93f70412e85cb19 9a37ddec600545473cfb5a05e08d0b20 9973b2172b4d21fb69745a262ccde96b a18b2faa745b6fe189cf772a9f84cbfc ]]></artwork> </section> <section anchor="server-initial"> <name>Server Initial</name> <t>The server sends the following payload in response, including an ACK frame, a CRYPTO frame, and no PADDING frames:</t> <artwork><![CDATA[ 02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739 88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94 0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00 020304 ]]></artwork> <t>The header from the server includes a new connection ID and a 2-byte packet number encoding for a packet number of 1:</t> <artwork><![CDATA[ d16b3343cf0008f067a5502a4262b50040750001 ]]></artwork> <t>As a result, after protection, the header protection sample istakentaken, starting from the third protected byte:</t> <artwork><![CDATA[ sample = 6f05d8a4398c47089698baeea26b91eb mask = 4dd92e91ea header = dc6b3343cf0008f067a5502a4262b5004075d92f ]]></artwork> <t>The final protected packet is then:</t> <artwork><![CDATA[ dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698 baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17 f9af6e16886c61bfc703106fbaf3cb4c fa52382dd16a393e42757507698075b2 c984c707f0a0812d8cd5a6881eaf21ce da98f4bd23f6fe1a3e2c43edd9ce7ca8 4bed8521e2e140 ]]></artwork> </section> <section anchor="retry"> <name>Retry</name> <t>This shows a Retry packet that might be sent in response to the Initial packet in <xref target="sample-client-initial"/>. The integrity check includes the client-chosen connection ID value of 0x8394c8f03e515708, but that value is not included in the final Retry packet:</t> <artwork><![CDATA[ cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436 65dcc7b6 ]]></artwork> </section> <section anchor="chacha20-poly1305-short-header-packet"> <name>ChaCha20-Poly1305 Short Header Packet</name> <t>This example shows some of the steps required to protect a packet with a short header.This exampleIt uses AEAD_CHACHA20_POLY1305.</t> <t>In this example, TLS produces an application write secret from which a server uses HKDF-Expand-Label to produce four values: a key, anIV,Initialization Vector (IV), a header protection key, and the secret that will be used after keys are updated (this last value is not used further in this example).</t> <artwork><![CDATA[ secret = 9ac312a7f877468ebe69422748ad00a1 5443f18203a07d6060f688f30f21632b key = HKDF-Expand-Label(secret, "quicv2 key", "", 32) = 3bfcddd72bcf02541d7fa0dd1f5f9eee a817e09a6963a0e6c7df0f9a1bab90f2 iv = HKDF-Expand-Label(secret, "quicv2 iv", "", 12) = a6b5bc6ab7dafce30ffff5dd hp = HKDF-Expand-Label(secret, "quicv2 hp", "", 32) = d659760d2ba434a226fd37b35c69e2da 8211d10c4f12538787d65645d5d1b8e2 ku = HKDF-Expand-Label(secret, "quicv2 ku", "", 32) = c69374c49e3d2a9466fa689e49d476db 5d0dfbc87d32ceeaa6343fd0ae4c7d88 ]]></artwork> <t>The following shows the steps involved in protecting a minimal packet with an empty Destination Connection ID. This packet contains a single PING frame (that is, a payload of just 0x01) and has a packet number of 654360564. In this example, using a packet number of length 3 (that is, 49140 is encoded) avoids having to pad the payload of the packet; PADDING frames would be needed if the packet number is encoded on fewer bytes.</t> <artwork><![CDATA[ pn = 654360564 (decimal) nonce = a6b5bc6ab7dafce328ff4a29 unprotected header = 4200bff4 payload plaintext = 01 payload ciphertext = 0ae7b6b932bc27d786f4bc2bb20f2162ba ]]></artwork> <t>The resulting ciphertext is the minimum size possible. One byte is skipped to produce the sample for header protection.</t> <artwork><![CDATA[ sample = e7b6b932bc27d786f4bc2bb20f2162ba mask = 97580e32bf header = 5558b1c6 ]]></artwork> <t>The protected packet is the smallest possible packet size of 21 bytes.</t> <artwork><![CDATA[ packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba ]]></artwork> </section> </section> <sectionanchor="acknowledgments">anchor="acknowledgments" numbered="false" toc="default"> <name>Acknowledgments</name> <t>The author would like to thankChristian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa,<contact fullname="Christian Huitema"/>, <contact fullname="Lucas Pardue"/>, <contact fullname="Kyle Rose"/>, <contact fullname="Anthony Rossi"/>, <contact fullname="Zahed Sarker"/>, <contact fullname="David Schinazi"/>, <contact fullname="Tatsuhiro Tsujikawa"/>, andMartin Thomson<contact fullname="Martin Thomson"/> for their helpful suggestions.</t> </section><section anchor="changelog"> <name>Changelog</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> <section anchor="since-draft-ietf-quic-v2-09"> <name>since draft-ietf-quic-v2-09</name> <ul spacing="normal"> <li>Added note for provisional IANA registration</li> </ul> </section> <section anchor="since-draft-ietf-quic-v2-08"> <name>since draft-ietf-quic-v2-08</name> <ul spacing="normal"> <li>Updated IANA considerations in accordance with new constants</li> </ul> </section> <section anchor="since-draft-ietf-quic-v2-07"> <name>since draft-ietf-quic-v2-07</name> <ul spacing="normal"> <li>Generated new constants and test vectors</li> </ul> </section> <section anchor="since-draft-ietf-quic-v2-06"> <name>since draft-ietf-quic-v2-06</name> <ul spacing="normal"> <li>Clients <bcp14>MUST NOT</bcp14> use TLS resumption tickets across versions</li> <li>Servers <bcp14>SHOULD</bcp14> support multiple versions</li> <li>Clients <bcp14>SHOULD</bcp14> check path support for QUIC independently by version</li> <li>Minor editorial changes</li> </ul> </section> <section anchor="since-draft-ietf-quic-v2-05"> <name>since draft-ietf-quic-v2-05</name> <ul spacing="normal"> <li>Servers <bcp14>MUST</bcp14> use the negotiated version in Initials with CRYPTO frames.</li> <li>Clarified when clients "learn" the negotiated version as required in the VN draft.</li> <li>Comments from SECDIR review.</li> </ul> </section> <section anchor="since-draft-ietf-quic-v2-04"> <name>since draft-ietf-quic-v2-04</name> <ul spacing="normal"> <li>Clarified 0-RTT handling</li> <li>Editorial comments from Zahed Sarker.</li> </ul> </section> <section anchor="since-draft-ietf-quic-v2-03"> <name>since draft-ietf-quic-v2-03</name> <ul spacing="normal"> <li>a v2 session ticket is an indication of v2 support</li> <li>a v1-only extension is theoretically possible</li> <li>editorial fixes</li> </ul> </section> <section anchor="since-draft-ietf-quic-v2-02"> <name>since draft-ietf-quic-v2-02</name> <ul spacing="normal"> <li>Editorial comments from Lucas Pardue</li> </ul> </section> <section anchor="since-draft-ietf-quic-v2-01"> <name>since draft-ietf-quic-v2-01</name> <ul spacing="normal"> <li>Ban use of NEW_TOKEN tokens across versions</li> <li>version-info transport parameter required for all v2 endpoints</li> <li>Explicitly list known ALPN compatibility</li> </ul> </section> <section anchor="since-draft-ietf-quic-v2-00"> <name>since draft-ietf-quic-v2-00</name> <ul spacing="normal"> <li>Expanded requirements for compatible version negotiation</li> <li>Added test vectors</li> <li>Greased the packet type codepoints</li> <li>Random version number</li> <li>Clarified requirement to use QUIC-VN</li> <li>Banned use of resumption tokens across versions</li> </ul> </section> <section anchor="since-draft-duke-quic-v2-02"> <name>since draft-duke-quic-v2-02</name> <ul spacing="normal"> <li>Converted to adopted draft</li> <li>Deleted references to QUIC improvements</li> <li>Clarified status of QUIC extensions</li> </ul> </section> <section anchor="since-draft-duke-quic-v2-01"> <name>since draft-duke-quic-v2-01</name> <ul spacing="normal"> <li>Made the final version number TBD.</li> <li>Added ALPN considerations</li> </ul> </section> <section anchor="since-draft-duke-quic-v2-00"> <name>since draft-duke-quic-v2-00</name> <ul spacing="normal"> <li>Added provisional versions for interop</li> <li>Change the v1 Retry Tag secret</li> <li>Change labels to create full key separation</li> </ul> </section> </section></back><!-- ##markdown-source: H4sIAAAAAAAAA6186XIcyZHm/3iKWLTZDtkGVOd9YIaaQZNskSY2ySWhlvXK tG1xJZBCVWUpMwsghkY9yz7LPtl+HhF5FYpE79hSTQrIjMPDw/3zIzzy7OyM 9XW/Nuf8f/z59XP+i2m7utnyiAkpW3PrHt9GTDdqKzZopltR9We16auzf+xr dXYbnYUBU6I3V017f867XjN0i1m3l5u6o9H6+x06vn55+RMTrRHn/OSyFdtu 17T9Cbtr2purttnv8JjmOmG3Zrs354zz5WPO3Tgnf0GPenvF/0iv6flG1Gs8 J3L+gwhbNe0VPRetusbz677fdec//EDN6FF9a1ZDsx/owQ+ybe468wMN8AN1 vKr76730Q95d/eAXSq/WWGjXz0Z1TexYvtkPD1m0uu436xPGxL6/blpa2xn+ cl5vu3P+84q/2N8Y+8Dx+GfR9vV2eorBz/kfm+ZqbfibN8/tM+NWvbFNV9cr jcb/cUUPV6rZMLZt2o3osVaajTh4zj/89LwMgsD/fnb55uPwLGSs3lbzHq/i czvNM9ckDBP7q6673Vpgm19dXr7/IWaMnZ2dcSG7vhWqZ+zyuu44ZGW/Mdue dzuj6qo2nROu20G4Tvndda2uOdrWGg1rJda8b5atQmY+KbPrOejiXbMxvG/r 2xottemxzG7FX/cd3+3bXdMZGgsjYOlS9PxWtHWz73gD+asweo8BIVeqb9qO i63m5pNpVY1u/bUZZ9xChPvaNuZVi50g2aRZuFh3De9Me4ulCPzHerPZkShY 4miMTb2tN/sNV9die4VW2D6xvefVvt+30wxNZde4Yuxt09PkoPVkZMsJLUJs ud+KtZUGPwPe7NoGKyVOUbd6q2lhNFXPaPEgojOqweK6HksUre7OaFduFmxd 8Us0xFB9o5r1uEOaXxvQue9ogWxkyH4jTcsbjE00gLSIFkZT3dVoXm/ElTml R02rqUnj+FD/p1myvq27m5WTlU2t9dow9h1/ve3bRu+VbcGWe//5M/3+5Qu/ BrtBhmlpO82n3mxtg11Tb/uOplbrvSY0mG0k83RbPjVK7XckgjMG9dcY7uqa V3XVX3N5T1zE1hj0v+frBqNdG0ELetIZwz5//nerL6/f/nLx4fXF28uPz6AS RVmWX748hXig46edaWsSeeyOJwJ8BIda/HNqJY6GGBkbQlC3HYB333vKbkXX Q5n/3rR1fz/ICSReVGDiKTVpnYzT7kF2oDRizUg2HENl88lYDbB8xwjbhWi7 NYr1nbjvuDTEsOBT4P6E2JnX2wPlO8X21DQH30GETO+WY7aqvd/1EJc7QOR8 hjMvSYpDQnuGXdOmU20t0Rby8fnzR2M3mqeraFgeIdCXLyv+HtJIb0HU4aRW 2uqOgW5QvwZM80ZaRWztagGgmLcnSuqWmEqc6UZ8sdLhOYzJ+PN1jffslcFQ kFn+0Y7E3e8b03WQZ+DKxZWot19jOn/IdHac6SG/MffgA2DLgQrJgVsZd2Db gfU/1Vus7P4UPPpvliu/vH32+uzFamY/PItn+ATNgA7f1nZxd0Q7AU/dbTor E2arnYYQj4ZuDuwW24y3UHmHCSfgVrPZYXi5NieTLs1AcWNgvjRXAIJuvyP7 zTsIAkwqtq5qm43FvMMZ8Iw5CBkeWuGp9us1vzJb04o1ZB5aYrcRmwhNgIRg EqF1TROD6VDYrQae1Tu0Y1aXe5g+aug6bbdOwFb85PnDZSyw3awBUVvhVY/N ht4ZzAX9k/uer80twYa1PC1sflvb8Tva5evmjm/2ymkA8X9UevCG6bqqsNoO JtrZtvX96gDgIhKrjcF7B5p9fUUbNAdNWpMy7fahwWLHFjVJgNvOwRB5MSF2 mk8CVssMPPMmi3XGsnHoAD6SIgAJQZnTaugeHt8dGJJXzR0h5infjraMiFPX Ta3GSQ5Nydx6dIDHrW4263tMDhtOlq/rgbzU+SQ6scDJBhbLmsTZmj7rM4Aq I7AFc7z2ykWOosUrtxPkipB0TvD7r1xCIj2NnbWHQPCe9pu6jRvj3YnFttBu UCOsmjmpAP2tgaa2xlJ+hFeMXUAxBq10q/Aa1C3lZ2uMdshGW2W9qCO7zdBg 51CTCwIrqIxu7rZXraCt7nvwgbDlO/682d4StzA2eWfGQhL8Gkxy8vOfP16C yfb/+dt39ucPL0H4h5cv6OePry7evBl/YL7Fx1fv/vzmxfTT1PP5u59/fvn2 heuMp3zxiJ38fPGr21N+8u795et3by/enAwIPzmNxFssT0JAgObtrjVkb0TH Fgblx+fv/8//DhMCTRjjKAxhjP0vRZgn+OXu2mzdbM0WO+R+xXbfM7HbGdFa Fw0QpMSuht2G0YDR6qDZW+sLgXvf/5U487dz/m9S7cLkD/4BLXjxcODZ4qHl 2cMnDzo7Jh55dGSakZuL5wecXtJ78evi94Hvs4ckJS+8nkDzHTgvgkFEBy8n V1zwCuKtpx6nB979zPpYdk2SPNifmR80uA1etx64Dc4NPPU/OY/B4cJgLmnp v7z88OszF8pE5FGQoLcUIW0JFayaQ8Q674Ks6653Rn22CtKW78Yl/1SbtXYK Mzyq6BGNNQOcjkAs+JTJOE5iVdHEeHCHZTjDRpIrAaSCAlaLZFXddsTHfTv5 ndaaXYsozTpEEIR9Lug+AM8TkPgH/v33WCd/CcPYtP/ScYojzr//nvP3ayM6 u+rm1nhnl7whQLE0cJyAF3VjXfTdXq4Hx/wPDrAq8kHmUcpCJVc+rjvA8rsa 2gMU9JaD9gsxfwcknKFWN41GUfEp22/XMC+TbyVA3rW4Jdr8OBYdZWvETccH j6QmF8Ft0Rti/yuH9+8d3l8C7wFvF+v1TAq/Yhe6pWFwskID+A2+Feu9a3QO BBgc0nMeSETJ3/Pg7MPlJf0WBvjtFQQRO3dj7BN6/8H0lAVB68BS+5z85Qa4 vLu+H0yskys/kducO+KGN4KDUbTL/W50iT+SX217kodNfpum3bTupRlbAd67 Rxzu0dL3DZb4z3/+E7G/7fybHfgZRQbaaBNrU+VBIDIti7CMi1CazERZqZWs Sqkjo0vb2wmHd5OdfEfB75Bumu3EL/LVn178xN8IMKP7HUKOIJCi6sHl4GSG t1d23f/YN73fYxLNbgfBwYD7nYV7qP7WONkaDY9HhZXj7drS4Lg7ApDn28Rt L0/eBBOXLd+feJ6zOffDJfc/n/sJf7IRwLMTCVpPvjw9HWV1OSgbBl1safJ7 B7XySKG2uaLIkl2KqyWti2GL3zssmVUMw/Y7bf3oI6Nlv3flg95bF82m3Gjo E2K3/Q2iQr+fugjDNahvF+/x6+L19Y5es+E1fnUkz5rc7Jcz7NGEXHFjnExd 7WstCD3J5sGhYyOgQSwerrZcZb9rtU4jEMLMwJUU4GCfOPZp8teI9C1FA04u h5zTkT78yTe28ykbEHZQfJAI94o/YxxKrxKto6RIdFaEwlQiqSr8XKpIRUFU lmWRiDxLRapjFYdlEVVxUak8CbMoTFNTVoxIJfQoKpkALWWaCZUUgIygkkoq iHeulCoj5tZCTXWRlVkpVYRXmcYkgalkkIgBWGzKhkgcMlzHgKS1fHANTxyg L7kGzjOnuV4EBsWnkcdMhlf9ucw5Z3UmZAyRICUcMJQFaDa5DG9nwRi87g5R Siu84/0w9iNwIv8WDoqHcTi6lM+bsgcr/nIK42cRA5sG2tRX171Ne9TbvRmD chKQycUiqRafXFZuYU/t0n1oPvpsKwgU8A3BkNqvBaI7yvRyZRMnhOcgmaSQ X6z7s4+3Cirw78DqvIgLi5AIfjvVUFLFrtlTtOIXnWP6GKbCuzCODWrfkiWG j46+lAXa19017GJ/Z8x2wbrOUzMkgLyjPCx7s1/3NQW4o6pi6QjK9sqFzUBW KfzSIT5TvsM9EjYz6BMQousaVYsx1TUnY5ETAasvn7/nFUIJCauw4j9R/sVF 2gQ6aFBfke3RtxRhdpQqme/TyXV8AgM88hMRyB5uyNBkmZUjB7nurYNJlLqh YfUX1FmMgNfpUvSnw7pag+mMy2cM22ldOBseDfNZQVuGrXbwr8SuB4Jt/X34 MPqUzBjlEdz08HVqMhRslhL4bTxxoKTAcCBEoic2CPnaWW56MsS/vHV2GMpC Ye2oCseC3ynFPlMYY7zrPx8Qjo51gZzvK/iUBxuZaoVglh21qxq3pe7mfRZt IwtIjvmng+QySqGRFs16zYWKMi82sWaJGVJbg048yDqt2HGkcFmOURsO1OXI Kg9oELdNjdDbJd/o+GXnXPApwbZAvQ8uCUJWDZj3/MHwiyUOaxmpCy1PIygF 5Xkd2kMSWDsblSTB1BawNJ75hN/lPLizRxiWQabdAM0HHRlExWP6mBQdt/HE mYaZXFBe3PuvLk9Mkk0RizO8zgk8JYW0cr/3x0mjVs6PXJhTOV5fbSEI3WII cjcJFhZJ0iGN57oNeQc7iWBTXmtgrT+WmQVgy1S6kwuyFJQtmtwH1jc3xp8K +VX+fPErJfobfSRhjGkoDeeot11JTmbqPSRxHdm61s4Nd8I8wTjtgW6bnUut Owrriljpmhp9SjkuQxChxuFIYtc1eWUP86njvpPQHMMTaw3oANYdOPp0uFuJ 6A7On2CwKotBY3qbOvOHUsOFbedlwiaY2MBHm/xwRxB2rtasza3NLH6FuoGP UzJ1Erx+Tu5oqUZoeP1iClrolfnkfL3TRU6FLSLDfBUPDqIV9pkMAJ/svkHg +fMPv76/fOdORDEJuLemjaKTOQ/yRs82/V86dmx9SxEb7ITNwB1M0A25kofc 9kR6cUAw2HpZPrIxsIDuqGg4HXSh6SwtwJapHct0p1nd4CYe02aPCZ4IoJCp 7bkwm69jGsAv2e/L4XCnh6e549YfWRJgDsrtzsqP0sbYj87KzycGaQTCLmWs bPLlmPyNBLuFEa4x519STtq5Uui0tT8entMddHZekM+tuyYL1RiV9cgK3m2d uzYwmOTM7rSXsod8sRA8GDcSqgkF2SGhDmkXXs4DwSScJTdWtNqi3aEJGVfv 994F1KNidHtFXKbzrftRQ8hsjNki5hFvDD2OSvqPZLwPcql2eeM4FghCykg9 WN98TDau9GI7OXJ2PIvBy750hLewRPM45FrcQjKbUSSGNKedEWygAeDSIdYa 6hTurDsrBpu+ccGOPUYGY9kCkDs6UvPULFV93BfLgODRJU+iQX6iA2nm98Iu cjA6PhwfVexAbVf+iNge7HGhbBbcTs88CG9HrVpS9XUAoaCRDqM/GMSxu/FM 6e3Lv/x2+e5PL9/yS7KrlCVEo8507hy19qfwi5bWArts13j+7rFhYc9cGo7N 7IVdtD8btOvYrPzpeHfgbByQwG0SGdMyd+B7GKHM56Dz+dodPYvDUGFqd0pD 3tbKnWsK8GfguSVkZhRHZtpagdniSGa/QqY9KyBb5jev2VLaudsPqQDBHzhT 0BOo9t9BHbHGDQfsQ3RJDiijUI/mp3DPuQX2KJt263rQzFOr283eC8tyREvW bMAZ2AmtW5Ild3hBs+y3oMqGQUNVA51e+yBGbOCZWyEGh8QcYe0ZPXSFYjjr oTz09ufu+KlloaPJRqgLZrKN2HWDYB2xS0CAsUJoFHcw2or6u/nh6SOJkbGm YZYEHc43beBKEaPNKs+PZFf8hSH56Zz/idB9v/E+FLkXi/MaG/F673YWzjXt lE2eCtBmSfV5GQcRsV8LN5bbqbEMpt5S7Zkg+zmdjzQtxSrr+wGB5ise0W48 Tt/QVswKTE4dLsIMwoMxd1gSHlWN2nfDcbrzbAY3Gixjc+1yUuNCfZu+8STX h9UqLhznem/8XtMws+2CH9Hc0qYOQGEPaE3XO7fTHZZbCzAQf1DQYGvbRkCY aGQOwmcJMotX967myMV7rRFds4Unc8+VaSmKWURmQ0Ki7k+tWWmNXbH33Lu9 rcgQ/Eitx3wuSgnZvVpxGHk2T4OJYSrnrxGCdA/BcZ55i2Zendgym+1z5R4g vp8JDVoOMTn2au2QbsSdjQ3YLAp6a1ZXbIzhnZ8uKV8NVw5TGG217mK3o0M+ n9r6/J2Y//7l4EBvKDcb1Q8WfpaUP4R4xDFunwcpETs3sK2fuKUyW+9w+ln7 MZ4d8iCklxfTS/5G3MNAvx/KEudZhScXb96/fUqJbZtojIPwC50ZQIG9TzLl iaj8bef8EUpBskPTRCacKjnnjVxa8oATD5KglEixOE3pOoRQr+IvX1wiQTf/ OPFJ0DJKAzwmep2/8HViImzSn91JqPW17qi0p+sJVR1zXNJtqHfsXIrKLZGq Upc5ptAuiz18EVlZQLy3twcEj6WlfUHmXABG2O+GQRo6ogIUqvt52UxTHUbQ zn/bUClq3yBo/WbRkhVfyq18rZjllFFN1vjYeaJE5kgXlRkMsmaj3jm4LQt8 2Fh1TM7GLBl76KMIqgVZ72waVw7639Bx+RVVppAbbVNsg/WGq+FbaWeRLP9f X7y9eMD7ZaU0JblMN6TvbAe4Ag7cbT6M1A0NXVXWoX/HWnNVd/RygBaqmOnZ v/31b0+GOvW7u7sV7JJwVe8ArautTam5qnf6Z/WJqtS/m5ccdk//gBX8QifV 5+x8VukAtkFY9x09BWOxyxRssY/zag56Z1f5wq8ShsOBCngBSVuvTUtt7MUA Rs+E6umBXdpf/sg+n0O3hcLSn51Y90X1J18W5ORBKdJAJQtyCMSIeARs/58J sinl8cFt5GoaJiz6GsVU90zeoj0v+uiK8HzpwvvJ0fn8HV0tOPNl6gNGD3lN qkzqhoMF6wI9PITuGm+dhoobb7dJjqV1r4d8unIJVVua6CmyYx6N6w9E3BtC tlvvD5OhrrbCQZXF+yn+d8HElhdnVBnghztzJQ/shaGDn9FFnJJaRFPwqYjL RBVVEJs0TPOgAMnkDFr3Y2O09Semug3mc26gwFaEjC98dVdNSv0JIKLqjUUA Smn/iY7a5xUAUwGP3rdDgGk+AW2GcwJ6QHULZy8/7cCWM1u+gFhg63yaJ95R OOWvbnRlX67s2E99HfBUvWpJ5Ff1rUunHgzMhiEXhfY7B9UuQbHvd/ve16wM iebtOedBEAVBlSeZyuM4jOMoyOJMZWWWZiZP8FuZGSpUGXNUR/vkcZbmUZ7R v1Of6ZjUdgrxv0WnME/RNM6zmDpJdC5n3epb2ytQB1Mte5V5NutzvfMzfbNP kdMdF7uVvq5ldoYMpdwQECzLXvwp+MB0e5flybwo5pSrWj91F2I45ohMIWOl C51GQRllYSILkKEDIcJK2mac5yoysVBhGVd5IaMiMHmkiyrN07DKhHxwxN1Z C7SbauH9Rs7q7z3d7sVvS/I9cQ8E8smy2Sk/GQWEyjTxN46GlYWJUaXOjCwr nYuqiGWViiwrpApzkZvIr6wAqzMBBcqN0kFRhlUeVGVV5VUiqySXzFcCPKTl KOWnB2UeRFOYDTQVMhQBCIjCqEiiMhBRaYIyD2WKuZNUM1bfHl/4I5PZmhE7 17h+WklsojgNsVGiDLMsMGVQwtpd7/5Lc9jCk+V6klSWqQlTzKKzKgF/ZVgq qWQQlYkU5aNi4XX1oVi4F/9lsRgx4IFYBFEWaxnmRZTHIXY4LQpsfaLLWEIP 49KLRZArWUApAB8y1SJNRSF1graiUnGuwq+LxVHKHxGLSEuofJGFOgU7dRCG VVgaAS1MdSTyr4vFI5MdEQutw1gB/5KyVEGUlBrAE2Rp9HWxeGSOI2JhdJXp IFVFTJIehDKJMxMCzPK0jFXs0cIevjr1HSz15+86a77PvEX1c35ZpE/9weX2 wL4jyqVG+60XL0Nm6X7duAp8d+nMNmSLg8PJI52feJxy6xCYrb1a9f7ixYvX b/84HOrYqJcS1iwMs8i5AH4qL70BkD4JKjIj+GN0EMPcywp6mGZVGJU8LqE4 RSLiosySPDIqCaQsMjijOjZFVrAgqQC4SV4FmYhkViZFouwFpyRE0BjGkGM3 uBouPtmZ7I9kngqWhZnOAxjINDIwlNiRqrKtbMtAkMEq8BekQuKCEJYmLPxb sjopaMAYCmPQsKn9Gwbjnzgm64reUeJGgPWI80BGqlSCKIdVkAIKlpaV0VLk aaxNmIcVxLpKwRxlQp7qJDZlCajOE50nmD+SNDYGi8HBgAV6XFqCRyn+Zv51 gScFx6OC1hChoeUJWofEFEsWRohhqWFY0bY6+IOumBGrsL/k9Iv/uQCLqbd9 wkB5EJT2EV4d+m9BxqeeE+DN5dAXQ84yKHxttlfu0kYYFpErMD23ApkMAmVl 1ZUnQ7kgaVMZqhPEsRoGquc6zQ4gbB5HXHmt8GeEiztkiwNXdxNk8HyHCy4V j7xE63iIlo5wgMQyKY0XjMgxYXYRzp2LO13cDVG59/O8Y8md4rt6wAfFoyv2 o1FiqEnwr939ziW/BsptUhRTn85SimE2MtBmPx7ixIyM8UDEZn1crmI2N+Uv LXB0g71ygdAzXlUmyyV8IqUlTHwhkyLVMO7akJjmMBwb0d2g4cXLj2cvn//4 5Hp36md9+tdgtUr+5iwQDHgiAgXzWsABdNP+Nfgb/1/POA1AP/53Km6uhuY6 H1qFxWoVhVPTcD6qHzPyjW3Hx7d27DXK95Ren/PRJW0Hpjw2Mp8PfYxxbM45 ic5aGeCogDKYHC6H4mUWpLDMspJhlCtdUTk3oAmGuiwFOrOyKkWsdZJEqYCZ D8oyUlDUsDCgqtKSw7InAI8yT/IgjSo4hyoKgFURUCpX8MkigFWkkgoQFAGe 8iAvUpmXSYYpIpMWXKSlUGmkjchywBhaxjJN0ySNaOkhzERUxImJK5hbkRc6 xnoDHRYVIC8jS8HRKMoI/mDsk9wIAbRRMeyHItcDEKRkGUZRhRdVCOOaqbhE rFAKmFZgkgYCKDAiCctMhKGSRiSBqGRmqjRK4dvDoGC6LItSUykTywxhbQZI NomMc7St8hwuElzRWAuRIxAI4SnGqSwwfYG4pariGKsQJg1kWMD9SeIYwU4Q FUYrlSisr5A8E6WsVBRlSiQyAWgajK2wY9g6EYkYIAL6TCriSqZhFBeJjCqt C8QQOWxhlnITxJbV0oShAOE5/sBLiZMsiuJSa5ZVOYjDALBL8I1gLFUp0SeO 8zzWieRJpqNYwUVLDVzRQmUxzKWKYNkQqCDAYVJV2Lwsq1SCnohnYAFDjd0X ESydrnihElFCMKsw1HkFOdBKyjJQmYT/AiedwZgaUIX1m8TIoEJgh71OskBB Tssw4DpScZpio8B7iRgkgiQIIVIIe5QjqGJC5apKjM4xfoTwqxIF3OVMgIth IOKEyzjDDiAUDEVWYSVZKmDDYIdzxCkIHxjsMhgLsaWIDJ6ElHGRBhgA8RnE PObwGVKpUjAR1KkQ/iv2RMmkymGgE5OyRFch5EPAL4DgwgJHCpubKA35MtA3 HuYGAYOGJw8nA8qJmSC2SRkS2ZVMWKWrIsVb2kIITprnEo4JKA4DSJdIuYoj GRloTYnl5AJus5RBIYsEWgLxlgybgsAyVRD3NFICMXepC5kXwsDXzoucZ/BO wRDwWGArNTZKhwK6hfmiEqxgYaJDBHkhHI+qCBNsY6FyKHEcQblVWfIqtkqm shIMKrF/AaIh7IOUKfSpKlkJEQHLEw0/S5hCiAIAJXPsuEgEGfcwSIEqSsRh Cm8qgU+EXQGPlIEQQy2ZkBAESDYgJFcF9DdUwBydBMAC6EDIA4wNRy7GTFKT xxPmVQZvJI5SKfAIfEAgolUBmhAeYqux88CCCNIF7mjNIXiSSATiwSHEWhNg D1wtaAZiWQ1OJkWUpQbgaiQi8wp4SvgHdoRQ7wLyAP6qFH5hZgBy0Aqonswk on0jDLAIWA101UUCCYcmJGAFlDaHXkFXQuAp11mJkNLAcw0QLGkjZUI+I/4F 4oowZSoBcABiAooGNUAnB3BAhaECOSEBSRREMA4BeRBck5L0A8lFkUJ3hFIs J/0ISuw61EQUWQnXVQH4IV8CbqLgEIYISIlOZYF9zRPadQgmlhsXJgsZUA0h Kd6B9boCJ2MVSgmcg5rHeWU4GA0tL+EhArgwv4AiAjBgUgyAPQxYGGjgSR4g cpEJohUDvUoTAGkhhRZJxBEugR/QEbBWywCKIzV0tSKpQzQpWYyVp0WI/xDZ BwSW4BWIjGLAeRimPI+LADALN9lAcBOBJiaVYE0RGATsBuEDjJw2lGmqADCQ PsQQ0FppVAz2QCalxpyFTmOSEZUJrQDAuaINC2EjWaEJ50shc6wLeqjjsEDg RxsOvMtDDv6aTJD1MYhByioOYd8gCKWJsa06ZHFCoAfFLCrEJZHKywJGtAzA g7LI44BDm0UZRVA+GKMiSHWQRxKaCREHqlchQxwThamKNNiXQWiBXnERQ7ik BH6kAqFoleSasi8F8E1lFciAQQUGpALSrlmqIabA30jCBSjDEhsSJDEBXBVn AiGMQbiMqTRidGCbISlRiFkN5LNSmYnBB0QlOqhgXGJYhlxQngK7gfg3VOAw hznBoxDWrgoprwXlCUP8JKEBaVWUTAM1EpgwEKYqsjmCoCIOYb8Qi1UxjyF3 0HWTQzcrpRHB5cBKCcMJ0ZJpDJuVwNbEQLUcQgA9T2A3gfdJAvQtRMWlkHEa FZEAZpcUnlOWDYPDMmBZITAK2AmUhokPyNLkkFfwLwAcF1h6FPCyzMGpEBuQ kN+CeDEnNc4ihUWWmWQiLCS5D3gsM2B5UWIxeQR3AnEljPYUkfuvSPjYelFH 6QLvZdA8us5bX1HXmfmHTBClXzz/0xBTL6sKT/2lloPwegihozHStME01muf pJkNpkGDMjmsWZxLEeoQIoqFAnIK7Keu8rhkBTaAxBYPqjTLtEqTOJClIIQL MRanSNoGLIai2UUgq7EJCYJPhOfAWeBJUAgAPPAgTBCsigyPYOkLeHbAfNiY FBIhCVDgK2golwtkmYtjJ6/ZO90P6yl9XOau2x+LzKIjYeEY5vi7zA+it3Bw xMPREUfQTyaE3MoIcJZBZ4m9OcX3oSP0guhw/v2pLwmeQrHTeRg0P65xARBd bRJUEmS/aEHFr+Na++u61bNogdZzGD1lCMp1IWBO4YYhSgD7gbvGQJZhao10 wZNNPQIBseWhEbNIRj2+TPSaRenurvCRCMYGfwP3HhmWD+MKAZ/qyArYfAk5 uZuyKKOYgLDIoywmZ6sM0ziFGYMoplVewVVOMA66A3bCnMGjqGwOrYAvA39a wVyHAbBMVDGgT/FKpLCBERwkoBMsYhLlKTY1x/SgTkZMwSyiFxwRAdMV6ULp FHJcgINVFCrDtSgRkkj4zxVBBLAUnmJswGdomhIFS6QBNEehiQwQb4IMV3vv T/jsyd7BQZqN8V35rXRXued4MYTWy3Seq+4+ng70l+Lr8bKgujbqZvmFnOWZ 3FKj3BHV0dO4U/u5FFdFaVu5623jMdxQaOQEZ77K4Tyj+paw5AlEnM6PMqOK LMkUuVkmRkQY6ZJixjhjWQrXBJHwLEt6LfBfFJy9b9b3QK2Uf7ymU/7FxXG/ AcN3UdxG2Dqz4d5yb3bd9HGP+Vc3ho2yd+gE9cXoTq1sAmk2rs26XLy8ePHb 81cX+C8Kfnv/7s2vRJX79FI/a31qCwnHlI/Yzoto+B32brwTaWHCVXcN1UnM zvXwVHJ2YGi/PeAORc/R78bc22tqr3+hGief9FreQZ6SZn5iV9hLBWXSX0l1 kGfroOmg1V0L1vyJ/XjTmr5tNRcNf41139rKrnrJgKer+d3U4WRGqBjBdA7l z5OsgFuXlUkEp7sQsD4i9EcQaZLAKSlgQQTivgxmEFFDUSEaisjcfeNk6utn DtM5SAwM0VrDZYCkRmlCwa4IAB9VivjIGE+EKCgOLAWdSYrAUNiNyIoSDwL+ YRV962ji0bMIQd46vFeZa0H+qk2hwnx/6yziK4cP08I0nKg8C3QkAcKI6qMM YAo/IUUMiIhZDOd+EeL7MFBJFSJMLxBtomMGzE11KAuDhd3sfx8N9rb1kgYK N3Py+kys4WQlWQYPtChNUiKuzfRwqgqfWVcSMaOGgw0LITIAR6UDOLjgc1HM 7NTocDm9nvS53t4261sHTLODNeG+iDRdmbKlVGLLzGYHwPxqjYK/gOY7jScl UEmMSpUeo6PGbU0Ao5oAMT9p+fseChJ8CkJXGkA3Ho54JhlBHZy5xFanWc0a MWO/rGqfOvmkecyncoSkhCmyd0lsGax+6u75dYw+w+Gq+nZCLzLQHg7d6P96 eLjjSvylsbcCiK2u2nxJyzQfVa1W5s74L6B4dd9t+eGfZ9OS+RNfrvHUXx4/ aHioFlFRVRDkkh05U4AjREeUaMDGDPua6qbMp94ed4bjc1XvgFD2BZ4jGkH8 j4BEqijXeYEoBT9JRBMEL9H8SH9K9c6G8HfYh09FdnQhe0cVsnJtVvwdfZmC /FVyCW7q3c4aHDbAtr/aRvbkK/n+pVv4KK2jW1hS5gQsk9XkFsKuFjJU2bSi rzh8vMOmrA2VH/uVDO/t8ug4JFzus3s7TfF72fodv1A32+ZubfSVv2JKdLlP qnoZXNc33jcS2xv4AC1dKIdxe7WH2dyIU/5mr6Bc70Wr99CaP92D3A/wdk7Z xRbDbO/pt64+5f9TXGOlH0V7QydJL6AY+I0uAor/xNtL0Xd7uOYNv+z2f69v xJ1wNtJ9uBV0NZvOFYoTj+rWVhFW+zXv9ldXhCP20i6zbsr2yqybq/+XT/vM qsKGj/qg9+yzPr/zoz5wkwAb5MY+/KZvUNLXby406av9vpuvQhhK61yNoq87 dN8S+vZ4BY33Z+8X2M4HxeW1vV/TtO6rGxZ7fWBH3zOl7f7m+DmN/8exaGvR 1fkvJKS+uO6RsTIa6+htGPLN2unezngrR7XNVNbfofdwheWxTxTMJvJNnWO+ E1h/d1iaSt+z2tE3I+znEuRYVItRfq639OEBKzwUEozfGvrmSlM2o3Vxi/nY 9cOxfsB/JWxxcXNllyJ8iSF9bm38zMCJvb938rVxxczF9rHCL2+ZJdcO2mzc 5W/r7358+fzF6w/ocFubu8eEOGELotwNLbqkQxcD8OrlxK7FJHP1f2yOmOYQ VA16cBdg+Jivnmnl7Vjq7zqFZ/brC9OHbR2qNvCW3IcjR1hF+2lzq/rTo1sb sW8scI6Dj4wT0jg/+u8VYAkPb589EP7pMkzVHP20w7jdNglDRZqzr8YR2Z8o 5KlJyOljbZxwf2sL65dfMHmE9IC5sYT9ysriQwI08bevRI3wtwAOYAzdRDF6 5hC5701ONxLoM2D2G14HX0xbyOKMGv8ZVu4/PODYTSXcnuNzwDnO8kM20MfA DyTBfgiydffPuNCN/YqvbY2XL8zafmWxNeNnAIfPcdcbQn3/UYf5AjpbcT3e HZnuKjxCjZWnn4W/E780Ut5XvPzxxWpkv9/1ZfX8N2cIJtM1t1jjlyZo723t cLOjFQ1fnYMUhD49QV9S8vHn2MDXBdNXQSEBZBHp1h/Fk50hybYy838BL0rY RFBfAAA= --></rfc>