<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!-- [CS] updated by Chris 03/01/22 -->

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.26 (Ruby 3.0.3) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-pauly-dprive-oblivious-doh-11" number="9230" submissionType="independent" category="exp" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes=""
xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.12.2 -->
  <front>
    <title abbrev="Oblivious DoH">Oblivious DNS Over over HTTPS</title>
    <seriesInfo name="Internet-Draft" value="draft-pauly-dprive-oblivious-doh-11"/> name="RFC" value="9230"/>
    <author initials="E." surname="Kinnear" fullname="Eric Kinnear">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino, California 95014</city>
          <city>Cupertino</city>
	  <region>California</region>
	   <code>95014</code>
          <country>United States of America</country>
        </postal>
        <email>ekinnear@apple.com</email>
      </address>
    </author>
    <author initials="P." surname="McManus" fullname="Patrick McManus">
      <organization>Fastly</organization>
      <address>
        <email>mcmanus@ducksong.com</email>
      </address>
    </author>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino, California 95014</city>
          <city>Cupertino</city>
	  <region>California</region>
	  <code>95014</code>
          <country>United States of America</country>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="T." surname="Verma" fullname="Tanya Verma">
      <organization>Cloudflare</organization>
      <address>
        <postal>
          <street>101 Townsend St</street>
          <city>San Francisco</city>
	  <region>California</region>
          <code>94107</code>
          <country>United States of America</country>
        </postal>
        <email>vermatanyax@gmail.com</email>
      </address>
    </author>
    <author initials="C. A." initials="C.A." surname="Wood" fullname="Christopher A. Wood">
      <organization>Cloudflare</organization>
      <address>
        <postal>
          <street>101 Townsend St</street>
          <city>San Francisco</city>
	  <region>California</region>
          <code>94107</code>
          <country>United States of America</country>
        </postal>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <date year="2022" month="February" day="17"/>
    <keyword>Internet-Draft</keyword> month="June"/>

<keyword>Privacy</keyword>
<keyword>DNS Privacy</keyword>
<keyword>DoH</keyword>
<keyword>ODoH</keyword>
<keyword>HPKE</keyword>

    <abstract>
      <t>This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers
via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of
DNS operations by not allowing any one server entity to be aware of both the client IP
address and the content of DNS queries and answers.</t>
      <t>This experimental protocol is has been developed outside the IETF and is published here to
guide implementation, ensure interoperability among implementations, and enable
wide-scale experimentation.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>DNS Over over HTTPS (DoH) <xref target="RFC8484"/> defines a mechanism to allow DNS messages to be
transmitted in HTTP messages protected with TLS. This provides improved confidentiality
and authentication for DNS interactions in various circumstances.</t>
      <t>While DoH can prevent eavesdroppers from directly reading the contents of DNS exchanges,
clients cannot send DNS queries to and receive answers from servers without revealing
their local IP address (and thus information about the identity or location of the client)
to the server.</t>
      <t>Proposals such as Oblivious DNS (<xref target="I-D.annee-dprive-oblivious-dns"/>) <xref target="I-D.annee-dprive-oblivious-dns"/> increase privacy
by ensuring that no single DNS server is aware of both the client IP address and the message
contents.</t>
      <t>This document defines Oblivious DoH, an experimental protocol built on DoH that permits proxied
resolution, in which DNS messages are encrypted so that no server can independently read
both the client IP address and the DNS message contents.</t>
      <t>As with DoH, DNS messages exchanged over Oblivious DoH are fully-formed fully formed DNS messages.
Clients that want to receive answers that are relevant to the network they are on without
revealing their exact IP address can thus use the EDNS0 Client Subnet option <xref (<xref section="7.1.2" sectionFormat="comma" target="RFC7871"/> target="RFC7871"/>)
to provide a hint to the resolver using Oblivious DoH.</t>
      <t>This mechanism is intended to be used as one mechanism for resolving privacy-sensitive
content in the broader context of DNS privacy.</t>
      <t>This experimental protocol is has been developed outside the IETF and is published here to
guide implementation, ensure interoperability among implementations, and enable
wide-scale experimentation. See <xref target="experiment"/> for more details about the experiment.</t>
      <section anchor="specification-of-requirements">
        <name>Specification of Requirements</name>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>This document defines the following terms:</t>
      <dl>
        <dt>
Oblivious Client:  </dt>
        <dd>
          <t>A client that sends DNS queries to an Oblivious Target, through an Oblivious Proxy. The Client is responsible for selecting the combination of Proxy and Target to use for a given query.</t>
        </dd>
        <dt>
Oblivious Proxy:  </dt>
        <dd>
          <t>An HTTP server that proxies encrypted DNS queries and responses between a an Oblivious Client and an
Oblivious Target, Target and is identified by a URI template Template <xref target="RFC6570"/> (see <xref target="oblivious-request"/>).
Note that this Oblivious Proxy is not acting as a full HTTP proxy, proxy but is instead a specialized
server used to forward oblivious Oblivious DNS messages.</t>
        </dd>
        <dt>
Oblivious Target:  </dt>
        <dd>
          <t>An HTTP server that receives and decrypts encrypted Oblivious Client DNS queries from an Oblivious Proxy, Proxy
and returns encrypted DNS responses via that same Proxy. In order to provide DNS responses, the Target
can be a DNS resolver, be co-located with a resolver, or forward to a resolver.</t>
        </dd>
      </dl>
      <t>Throughout the rest of this document, we use the terms Proxy "Client", "Proxy", and Target "Target" to refer to an Oblivious
Proxy Client,
Oblivious Proxy, and Oblivious Target, respectively.</t>
    </section>
    <section anchor="deployment-requirements">
      <name>Deployment Requirements</name>
      <t>Oblivious DoH requires, at a minimum:</t>
      <ul spacing="normal">
        <li>An Oblivious Proxy server, identified by a URI template.</li> Template.</li>
        <li>An Oblivious Target server. The Target and Proxy are expected to be non-colluding (see
<xref target="security-considerations"/>).</li>
        <li>One or more Target public keys for encrypting DNS queries send sent to a Target via a Proxy
(<xref target="publickey"/>). These keys guarantee that only the intended Target can decrypt Client queries.</li>
      </ul>
      <t>The mechanism for discovering and provisioning the Proxy URI template Template and Target public keys
is out of scope of for this document.</t>
    </section>
    <section anchor="http-exchange">
      <name>HTTP Exchange</name>
      <t>Unlike direct resolution, oblivious hostname resolution over DoH involves three parties:</t>
      <ol spacing="normal" type="1"><li>The Client, which generates queries.</li>
        <li>The Proxy, which receives encrypted queries from the Client and passes them on to a Target.</li>
        <li>The Target, which receives proxied queries from the Client via the Proxy and produces proxied
answers.</li>
      </ol>
      <figure anchor="fig-doh-exchange">
        <name>Obvlivious
        <name>Oblivious DoH Exchange</name>
        <artwork><![CDATA[
     --- [ Request encrypted with Target public key ] -->
+---------+             +-----------+             +-----------+
| Client  +-------------> Oblivious +-------------> Oblivious |
|         <-------------+   Proxy   <-------------+  Target   |
+---------+             +-----------+             +-----------+
    <-- [   Response encrypted with symmetric key   ] ---
]]></artwork>
      </figure>
      <section anchor="oblivious-request">
        <name>HTTP Request</name>
        <t>Oblivious DoH queries are created by the Client, Client and are sent to the Proxy as HTTP
requests using the POST method. Clients are configured with a Proxy URI Template
<xref target="RFC6570"/> and the Target URI. The scheme for both the Proxy URI Template and
the Target URI MUST <bcp14>MUST</bcp14> be "https". The Proxy URI Template uses the Level 3 encoding
defined in Section 1.2 of
<xref target="RFC6570"/>, target="RFC6570" sectionFormat="of" section="1.2"/> and contains two variables: "targethost",
which indicates the host name hostname of the Target server; and "targetpath",
which indicates the path on which the Target is accessible. Examples of
Proxy URI Templates are shown below:</t>
        <artwork><![CDATA[
https://dnsproxy.example/dns-query{?targethost,targetpath}
https://dnsproxy.example/{targethost}/{targetpath}
]]></artwork>
        <t>The URI Template MUST <bcp14>MUST</bcp14> contain both the "targethost" and "targetpath" variables exactly
once,
once and MUST NOT <bcp14>MUST NOT</bcp14> contain any other variables. The variables MUST <bcp14>MUST</bcp14> be within the path
or query components of the URI. Clients MUST <bcp14>MUST</bcp14> ignore configurations that do not conform
to this template. See <xref target="request-example"/> for an example request.</t>
        <t>Oblivious DoH messages have no cache value value, since both requests and responses are
encrypted using ephemeral key material. Requests and responses MUST NOT <bcp14>MUST NOT</bcp14> be cached.</t>
        <t>Clients MUST <bcp14>MUST</bcp14> set the HTTP Content-Type header to "application/oblivious-dns-message"
to indicate that this request is an Oblivious DoH query intended for proxying. Clients
also SHOULD <bcp14>SHOULD</bcp14> set this same value for the HTTP Accept header.</t>
        <t>A correctly encoded request has the HTTP Content-Type header "application/oblivious-dns-message",
uses the HTTP POST method, and contains "targethost" and "targetpath" variables. If the Proxy
fails to match the "targethost" and "targetpath" variables from the path, it MUST <bcp14>MUST</bcp14> treat the
request as malformed. The Proxy constructs the URI of the Target with the "https" scheme,
using the value of "targethost" as the URI host, host and the percent-decoded value of "targetpath" as the
URI path. Proxies MUST <bcp14>MUST</bcp14> check that Client requests are correctly encoded, encoded and MUST <bcp14>MUST</bcp14> return a
4xx (Client Error) if the check fails, along with the Proxy-Status response header
with an "error" parameter of type "http_request_error" <xref target="I-D.ietf-httpbis-proxy-status"/>.</t> target="RFC9209"/>.</t>
        <t>Proxies MAY <bcp14>MAY</bcp14> choose to not forward connections to non-standard ports. In such cases, Proxies
can indicate the error with a 403 response status code, along with a Proxy-Status response
header with an "error" parameter of type "http_request_denied", along "http_request_denied" and with an appropriate
explanation in "details".</t>
        <t>If the Proxy cannot establish a connection to the Target, it can indicate the error with a
502 response status code, along with a Proxy-Status response header with an "error" parameter
whose type indicates the reason. For example, if DNS resolution fails, the error type might be
"dns_timeout", whereas if the TLS connection failed fails, the error type might be "tls_protocol_error".</t>
        <t>Upon receipt of requests from a Proxy, Targets MUST <bcp14>MUST</bcp14> validate that the request has the HTTP
Content-Type header "application/oblivious-dns-message" and uses the HTTP POST method.
Targets can respond with a 4xx response status code if this check fails.</t>
      </section>
      <section anchor="request-example">
        <name>HTTP Request Example</name>
        <t>The following example shows how a Client requests that a Proxy, "dnsproxy.example",
forwards
forward an encrypted message to "dnstarget.example". The URI Template for the
Proxy is "https://dnsproxy.example/dns-query{?targethost,targetpath}". The URI for
the Target is "https://dnstarget.example/dns-query".</t>
        <artwork><![CDATA[
        <sourcecode name="" type="http-message"><![CDATA[
:method = POST
:scheme = https
:authority = dnsproxy.example
:path = /dns-query?targethost=dnstarget.example&targetpath=/dns-query
accept = application/oblivious-dns-message
content-type = application/oblivious-dns-message
content-length = 106

<Bytes containing an encrypted Oblivious DNS query>
]]></artwork>
]]></sourcecode>

        <t>The Proxy then sends the following request on to the Target:</t>
        <artwork><![CDATA[
        <sourcecode name="" type="http-message"><![CDATA[
:method = POST
:scheme = https
:authority = dnstarget.example
:path = /dns-query
accept = application/oblivious-dns-message
content-type = application/oblivious-dns-message
content-length = 106

<Bytes containing an encrypted Oblivious DNS query>
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="oblivious-response">
        <name>HTTP Response</name>
        <t>The response to an Oblivious DoH query is generated by the Target. It MUST <bcp14>MUST</bcp14> set the
Content-Type HTTP header to "application/oblivious-dns-message" for all successful responses.
The body of the response contains an encrypted DNS message; see <xref target="encryption"/>.</t>
        <t>The response from a Target MUST <bcp14>MUST</bcp14> set the Content-Type HTTP header to "application/oblivious-dns-message" which
MUST "application/oblivious-dns-message", and that same type
<bcp14>MUST</bcp14> be forwarded used on all successful responses sent by the Proxy to the Client. A Client MUST <bcp14>MUST</bcp14> only consider a response which that contains the
Content-Type header in the response before processing the payload. A response without the appropriate header MUST <bcp14>MUST</bcp14> be
treated as an error and be handled appropriately. All other aspects of the HTTP response and error handling are
inherited from standard DoH.</t>
        <t>Proxies forward responses from the Target to client, the Client, without any modifications to the body or status code.
The Proxy also SHOULD <bcp14>SHOULD</bcp14> add a Proxy-Status response header with an a "received-status" parameter indicating
that the status code was generated by the Target.</t>
        <t>Note that if a Client receives a 3xx status code and chooses to follow a redirect, the subsequent request
MUST
<bcp14>MUST</bcp14> also be performed through a Proxy in order to avoid directly exposing requests to the Target.</t>
        <t>Requests that cannot be processed by the Target result in 4xx (Client Error) responses. If the Target
and Client keys do not match, it is an authorization failure (HTTP status code 401; see Section 3.1
of <xref target="RFC7235"/>). target="RFC7235" sectionFormat="of" section="3.1"/>). Otherwise, if the Client's request is invalid, such as in the case of decryption
failure, wrong message type, or deserialization failure, this is a bad request (HTTP status code 400; see Section 6.5.1 of <xref target="RFC7231"/>).</t> target="RFC7231" sectionFormat="of" section="6.5.1"/>).</t>
        <t>Even in the case of DNS responses indicating failure, such as SERVFAIL or NXDOMAIN, a successful HTTP response
with a 2xx status code is used as long as the DNS response is valid. This is identical to how DoH <xref target="RFC8484"/>
handles HTTP response codes.</t>
      </section>
      <section anchor="http-response-example">
        <name>HTTP Response Example</name>
        <t>The following example shows a 2xx (Successful) response that can be sent from a Target to
a Client via a Proxy.</t>
        <artwork><![CDATA[
        <sourcecode name="" type="http-message"><![CDATA[
:status = 200
content-type = application/oblivious-dns-message
content-length = 154

<Bytes containing an encrypted Oblivious DNS response>
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="http-metadata">
        <name>HTTP Metadata</name>
        <t>Proxies forward requests and responses between Clients and Targets as specified in <xref target="oblivious-request"/>.
Metadata sent with these messages could inadvertently weaken or remove Oblivious DoH privacy properties.
Proxies MUST NOT <bcp14>MUST NOT</bcp14> send any Client-identifying information about Clients to Targets, such as
"Forwarded" HTTP headers <xref target="RFC7239"/>. Additionally, Clients MUST NOT <bcp14>MUST NOT</bcp14> include any private state in
requests to Proxies, such as HTTP cookies. See <xref target="authentication"/> for related discussion about
Client authentication information.</t>
      </section>
    </section>
    <section anchor="publickey">
      <name>Configuration and Public Key Format</name>
      <t>In order to send a message to a Target, the Client needs to know a public key to use
for encrypting its queries. The mechanism for discovering this configuration is
out of scope of for this document.</t>
      <t>Servers ought to rotate public keys regularly. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that servers rotate keys
every day. Shorter rotation windows reduce the anonymity set of Clients that might use
the public key, whereas longer rotation windows widen the timeframe time frame of possible compromise.</t>
      <t>An Oblivious DNS public key configuration is a structure encoded, using TLS-style
encoding <xref target="RFC8446"/>, as follows:</t>
      <artwork><![CDATA[
        <sourcecode name="" type="tls-presentation"><![CDATA[
struct {
   uint16 kem_id;
   uint16 kdf_id;
   uint16 aead_id;
   opaque public_key<1..2^16-1>;
} ObliviousDoHConfigContents;

struct {
   uint16 version;
   uint16 length;
   select (ObliviousDoHConfig.version) {
      case 0x0001: ObliviousDoHConfigContents contents;
   }
} ObliviousDoHConfig;

ObliviousDoHConfig ObliviousDoHConfigs<1..2^16-1>;
]]></artwork>
]]></sourcecode>
      <t>The <tt>ObliviousDoHConfigs</tt> structure contains one or more <tt>ObliviousDoHConfig</tt> structures in decreasing order of
preference. This allows a server to support multiple versions of Oblivious DoH and multiple sets of Oblivious DoH
parameters.</t>
      <t>An <tt>ObliviousDoHConfig</tt> structure contains a versioned representation of an Oblivious DoH configuration,
with the following fields.</t>
      <dl>
        <dt>
version
version:  </dt>
        <dd>
          <t>The version of Oblivious DoH for which this configuration is used. Clients MUST <bcp14>MUST</bcp14> ignore any
<tt>ObliviousDoHConfig</tt> structure with a version they do not support. The version of Oblivious DoH
specified in this document is <tt>0x0001</tt>.</t>
        </dd>
        <dt>
length
length:  </dt>
        <dd>
          <t>The length, in bytes, of the next field.</t>
        </dd>
        <dt>
contents
contents:  </dt>
        <dd>
          <t>An opaque byte string whose contents depend on the version. For this
specification, the contents are an <tt>ObliviousDoHConfigContents</tt> structure.</t>
        </dd>
      </dl>
      <t>An <tt>ObliviousDoHConfigContents</tt> structure contains the information needed to encrypt a message under
<tt>ObliviousDoHConfigContents.public_key</tt> such that only the owner of the corresponding private
key can decrypt the message. The values for <tt>ObliviousDoHConfigContents.kem_id</tt>,
<tt>ObliviousDoHConfigContents.kdf_id</tt>, and <tt>ObliviousDoHConfigContents.aead_id</tt>
are described in Section 7 of <xref target="HPKE"/>. target="RFC9180" sectionFormat="of" section="7"/>. The fields in this structure
are as follows:</t>
      <dl>
        <dt>
kem_id
kem_id:  </dt>
        <dd>
          <t>The HPKE KEM hybrid public key encryption (HPKE) key encapsulation mechanism (KEM) identifier corresponding to <tt>public_key</tt>. Clients MUST <bcp14>MUST</bcp14> ignore any
<tt>ObliviousDoHConfig</tt> structure with a key using a KEM they do not support.</t>
        </dd>
        <dt>
kdf_id
kdf_id:  </dt>
        <dd>
          <t>The HPKE KDF key derivation function (KDF) identifier corresponding to <tt>public_key</tt>. Clients MUST <bcp14>MUST</bcp14> ignore any
<tt>ObliviousDoHConfig</tt> structure with a key using a KDF they do not support.</t>
        </dd>
        <dt>
aead_id
aead_id:  </dt>
        <dd>
          <t>The HPKE AEAD authenticated encryption with associated data (AEAD) identifier corresponding to <tt>public_key</tt>. Clients MUST <bcp14>MUST</bcp14> ignore any
<tt>ObliviousDoHConfig</tt> structure with a key using an AEAD they do not support.</t>
        </dd>
        <dt>
public_key
public_key:  </dt>
        <dd>
          <t>The HPKE public key used by the Client to encrypt Oblivious DoH queries.</t>
        </dd>
      </dl>
    </section>
    <section anchor="encryption">
      <name>Protocol Encoding</name>
      <t>This section includes encoding and wire format details for Oblivious DoH, as well
as routines for encrypting and decrypting encoded values.</t>
      <section anchor="encoding">
        <name>Message Format</name>
        <t>There are two types of Oblivious DoH messages: Queries (0x01) and Responses (0x02).
Both messages carry the following information:</t>
        <ol spacing="normal" type="1"><li>A DNS message, which is either a Query or Response, depending on context.</li>
          <li>Padding of arbitrary length length, which MUST <bcp14>MUST</bcp14> contain all zeros.</li>
        </ol>
        <t>They are encoded using the following structure:</t>
        <artwork><![CDATA[
        <sourcecode name="" type="tls-presentation"><![CDATA[
struct {
   opaque dns_message<1..2^16-1>;
   opaque padding<0..2^16-1>;
} ObliviousDoHMessagePlaintext;
]]></artwork>
]]></sourcecode>
        <t>Both Query and Response messages use the <tt>ObliviousDoHMessagePlaintext</tt> format.</t>
        <artwork><![CDATA[
        <sourcecode name="" type="tls-presentation"><![CDATA[
ObliviousDoHMessagePlaintext ObliviousDoHQuery;
ObliviousDoHMessagePlaintext ObliviousDoHResponse;
]]></artwork>
]]></sourcecode>
        <t>An encrypted <tt>ObliviousDoHMessagePlaintext</tt> parameter is carried in a an <tt>ObliviousDoHMessage</tt>
message, encoded as follows:</t>
        <artwork><![CDATA[
        <sourcecode name="" type="tls-presentation"><![CDATA[
struct {
   uint8  message_type;
   opaque key_id<0..2^16-1>;
   opaque encrypted_message<1..2^16-1>;
} ObliviousDoHMessage;
]]></artwork>
]]></sourcecode>
        <t>The <tt>ObliviousDoHMessage</tt> structure contains the following fields:</t>
        <dl>
          <dt>
message_type
message_type:  </dt>
          <dd>
            <t>A one-byte identifier for the type of message. Query messages use <tt>message_type</tt> 0x01, and Response
messages use <tt>message_type</tt> 0x02.</t>
          </dd>
          <dt>
key_id
key_id:  </dt>
          <dd>
            <t>The identifier of the corresponding <tt>ObliviousDoHConfigContents</tt> key. This is computed as
<tt>Expand(Extract("", config), "odoh key id", Nh)</tt>, where <tt>config</tt> is the ObliviousDoHConfigContents <tt>ObliviousDoHConfigContents</tt> structure
and <tt>Extract</tt>, <tt>Expand</tt>, and <tt>Nh</tt> are as specified by the HPKE cipher suite KDF corresponding to
<tt>config.kdf_id</tt>.</t>
          </dd>
          <dt>
encrypted_message
encrypted_message:  </dt>
          <dd>
            <t>An encrypted message for the Oblivious Target (for Query messages) or Client (for Response messages).
Implementations MAY <bcp14>MAY</bcp14> enforce limits on the size of this field field, depending on the size of plaintext DNS
messages. (DNS queries, for example, will not reach the size limit of 2^16-1 in practice.)</t>
          </dd>
        </dl>
        <t>The contents of <tt>ObliviousDoHMessage.encrypted_message</tt> depend on <tt>ObliviousDoHMessage.message_type</tt>.
In particular, <tt>ObliviousDoHMessage.encrypted_message</tt> is an encryption of a an <tt>ObliviousDoHQuery</tt> message
if the message is a Query, Query and an encryption of <tt>ObliviousDoHResponse</tt> if the message is a Response.</t>
      </section>
      <section anchor="encryption-and-decryption-routines">
        <name>Encryption and Decryption Routines</name>
        <t>Clients use the following utility functions for encrypting a Query and decrypting
a Response as described in <xref target="odoh-client"/>.</t>
        <t>encrypt_query_body: target="odoh-Client"/>.</t>
        <ul spacing="normal">
        <li>encrypt_query_body: Encrypt an Oblivious DoH query.</t>
        <artwork><![CDATA[ query.</li>
	</ul>
        <sourcecode name="" type="pseudocode"><![CDATA[
def encrypt_query_body(pkR, key_id, Q_plain):
  enc, context = SetupBaseS(pkR, "odoh query")
  aad = 0x01 || len(key_id) || key_id
  ct = context.Seal(aad, Q_plain)
  Q_encrypted = enc || ct
  return Q_encrypted
]]></artwork>
        <t>decrypt_response_body:
]]></sourcecode>
        <ul spacing="normal">
        <li>decrypt_response_body: Decrypt an Oblivious DoH response.</t>
        <artwork><![CDATA[ response.</li>
	</ul>
        <sourcecode name="" type="pseudocode"><![CDATA[
def decrypt_response_body(context, Q_plain, R_encrypted, resp_nonce):
  aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce)
  aad = 0x02 || len(resp_nonce) || resp_nonce
  R_plain, error = Open(key, nonce, aad, R_encrypted)
  return R_plain, error
]]></artwork>
]]></sourcecode>
        <t>The <tt>derive_secrets</tt> function is described below.</t>
        <t>Targets use the following utility functions in processing queries and producing
responses as described in <xref target="odoh-target"/>.</t>
        <t>setup_query_context:
        <ul spacing="normal">
        <li>setup_query_context: Set up an HPKE context used for decrypting an Oblivious DoH query.</t>
        <artwork><![CDATA[ query.</li>
	</ul>
        <sourcecode name="" type="pseudocode"><![CDATA[
def setup_query_context(skR, key_id, Q_encrypted):
  enc || ct = Q_encrypted
  context = SetupBaseR(enc, skR, "odoh query")
  return context
]]></artwork>
        <t>decrypt_query_body:
]]></sourcecode>
        <ul spacing="normal">
        <li>decrypt_query_body: Decrypt an Oblivious DoH query.</t>
        <artwork><![CDATA[ query.</li>
	</ul>
        <sourcecode name="" type="pseudocode"><![CDATA[
def decrypt_query_body(context, key_id, Q_encrypted):
  aad = 0x01 || len(key_id) || key_id
  enc || ct = Q_encrypted
  Q_plain, error = context.Open(aad, ct)
  return Q_plain, error
]]></artwork>
        <t>derive_secrets:
]]></sourcecode>
        <ul spacing="normal">
        <li>derive_secrets: Derive keying material used for encrypting an Oblivious DoH response.</t>
        <artwork><![CDATA[ response.</li>
	</ul>
        <sourcecode name="" type="pseudocode"><![CDATA[
def derive_secrets(context, Q_plain, resp_nonce):
  secret = context.Export("odoh response", Nk)
  salt = Q_plain || len(resp_nonce) || resp_nonce
  prk = Extract(salt, secret)
  key = Expand(odoh_prk, "odoh key", Nk)
  nonce = Expand(odoh_prk, "odoh nonce", Nn)
  return key, nonce
]]></artwork>
]]></sourcecode>
        <t>The <tt>random(N)</tt> function returns <tt>N</tt> cryptographically secure random bytes
from a good source of entropy <xref target="RFC4086"/>. The <tt>max(A, B)</tt> function returns
<tt>A</tt> if <tt>A &gt; B</tt>, and <tt>B</tt> otherwise.</t>
        <t>encrypt_response_body:
        <ul spacing="normal">
        <li>encrypt_response_body: Encrypt an Oblivious DoH response.</t>
        <artwork><![CDATA[ response.</li>
	</ul>
        <sourcecode name="" type="pseudocode"><![CDATA[
def encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce):
  aad = 0x02 || len(resp_nonce) || resp_nonce
  R_encrypted = Seal(aead_key, aead_nonce, aad, R_plain)
  return R_encrypted
]]></artwork>
]]></sourcecode>
      </section>
    </section>
    <section anchor="odoh-client"> anchor="odoh-Client">
      <name>Oblivious Client Behavior</name>
      <t>Let <tt>M</tt> be a DNS message (query) a Client wishes to protect with Oblivious DoH.
When sending an Oblivious DoH Query for resolving <tt>M</tt> to an Oblivious Target with
<tt>ObliviousDoHConfigContents</tt> <tt>config</tt>, a Client does the following:</t>
      <ol spacing="normal" type="1"><li>Create type="1"><li>Creates an <tt>ObliviousDoHQuery</tt> structure, carrying the message M and padding, to produce Q_plain.</li>
        <li>Deserialize
        <li>Deserializes <tt>config.public_key</tt> to produce a public key pkR of type <tt>config.kem_id</tt>.</li>
        <li>Compute
        <li>Computes the encrypted message as <tt>Q_encrypted = encrypt_query_body(pkR, key_id, Q_plain)</tt>,
where <tt>key_id</tt> is as computed in <xref target="encryption"/>. Note also that <tt>len(key_id)</tt> outputs the length of <tt>key_id</tt>
as a two-byte unsigned integer.</li>
        <li>Output
        <li>Outputs an ObliviousDoHMessage <tt>ObliviousDoHMessage</tt> message <tt>Q</tt> <tt>Q</tt>, where <tt>Q.message_type = 0x01</tt>, <tt>Q.key_id</tt> carries <tt>key_id</tt>,
and <tt>Q.encrypted_message = Q_encrypted</tt>.</li>
      </ol>
      <t>The Client then sends <tt>Q</tt> to the Proxy according to <xref target="oblivious-request"/>.
Once the Client receives a response <tt>R</tt>, encrypted as specified in <xref target="odoh-target"/>,
it uses <tt>decrypt_response_body</tt> to decrypt <tt>R.encrypted_message</tt> (using <tt>R.key_id</tt> as
a nonce) and produce R_plain. Clients MUST <bcp14>MUST</bcp14> validate <tt>R_plain.padding</tt> (as all zeros)
before using <tt>R_plain.dns_message</tt>.</t>
    </section>
    <section anchor="odoh-target">
      <name>Oblivious Target Behavior</name>
      <t>Targets that receive a Query message Q decrypt and process it as follows:</t>
      <ol spacing="normal" type="1"><li>Look up the <tt>ObliviousDoHConfigContents</tt> information according to <tt>Q.key_id</tt>. If no such key exists,
the Target MAY <bcp14>MAY</bcp14> discard the query, and if so, it MUST <bcp14>MUST</bcp14> return a 401 (Unauthorized) response
to the Proxy. Otherwise, let <tt>skR</tt> be the private key corresponding to this public key,
or one chosen for trial decryption.</li>
        <li>Compute <tt>context = setup_query_context(skR, Q.key_id, Q.encrypted_message)</tt>.</li>
        <li>Compute <tt>Q_plain, error = decrypt_query_body(context, Q.key_id, Q.encrypted_message)</tt>.</li>
        <li>If no error was returned, returned and <tt>Q_plain.padding</tt> is valid (all zeros), resolve
<tt>Q_plain.dns_message</tt> as needed, yielding a DNS message M. Otherwise, if an error
was returned or the padding was invalid, return a 400 (Client Error) response to the Proxy.</li>
        <li>Create an <tt>ObliviousDoHResponseBody</tt> structure, carrying the message <tt>M</tt> and padding,
to produce <tt>R_plain</tt>.</li>
        <li>Create a fresh nonce <tt>resp_nonce = random(max(Nn, Nk))</tt>.</li>
        <li>Compute <tt>aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce)</tt>.</li>
        <li>Compute <tt>R_encrypted = encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce)</tt>.
The <tt>key_id</tt> field used for encryption carries <tt>resp_nonce</tt> in order for Clients to
derive the same secrets. Also, the <tt>Seal</tt> function is the function that which is associated with the
HPKE AEAD.</li>
        <li>Output an <tt>ObliviousDoHMessage</tt> message <tt>R</tt> <tt>R</tt>, where <tt>R.message_type = 0x02</tt>,
<tt>R.key_id = resp_nonce</tt>, and <tt>R.encrypted_message = R_encrypted</tt>.</li>
      </ol>
      <t>The Target then sends <tt>R</tt> in a 2xx (Successful) response to the Proxy; see <xref target="oblivious-response"/>.
The Proxy forwards the message <tt>R</tt> without modification back to the Client as the HTTP response
to the Client's original HTTP request. In the event of an error (non 2xx (non-2xx status code), the
Proxy forwards the Target error to the Client; see <xref target="oblivious-response"/>.</t>
    </section>
    <section anchor="compliance">
      <name>Compliance Requirements</name>
      <t>Oblivious DoH uses HPKE for public key encryption <xref target="HPKE"/>. target="RFC9180"/>.
In the absence of an application profile standard specifying otherwise, a compliant
Oblivious DoH implementation MUST <bcp14>MUST</bcp14> support the following HPKE cipher suite:</t>
      <ul
      <dl spacing="normal">
        <li>KEM: DHKEM(X25519,
        <dt>KEM:</dt><dd>DHKEM(X25519, HKDF-SHA256) (see <xref target="HPKE"/>, Section 7.1)</li>
        <li>KDF: HKDF-SHA256 target="RFC9180" sectionFormat="comma" section="7.1"/>)</dd>
        <dt>KDF:</dt><dd>HKDF-SHA256 (see <xref target="HPKE"/>, Section 7.2)</li>
        <li>AEAD: AES-128-GCM target="RFC9180" sectionFormat="comma" section="7.2"/>)</dd>
        <dt>AEAD:</dt><dd>AES-128-GCM (see <xref target="HPKE"/>, Section 7.3)</li>
      </ul> target="RFC9180" sectionFormat="comma" section="7.3"/>)</dd>
      </dl>
    </section>
    <section anchor="experiment">
      <name>Experiment Overview</name>
      <t>This document describes an experimental protocol built on DoH. The purpose of this
experiment is to assess deployment configuration viability and related performance
impacts on DNS resolution by measuring key performance indicators such as resolution
latency. Experiment participants will test various parameters affecting service operation
and performance, including mechanisms for discovery and configuration of DoH Proxies
and Targets, as well as performance implications of connection reuse and pools where
appropriate. The results of this experiment will be used to influence future protocol
design and deployment efforts related to Oblivious DoH, such as Oblivious HTTP
<xref target="OHTP"/>. target="I-D.ietf-ohai-ohttp"/>. Implementations of DoH that are not involved in the
experiment will not recognize this protocol and will not participate in the experiment.
It is anticipated that the use of Oblivious DoH will be widespread and the duration of that this experiment to will be widespread.</t> of long duration.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Oblivious DoH aims to keep knowledge of the true query origin and its contents known only to Clients.
As a simplified model, consider a case where there exists exist two Clients C1 and C2, one proxy Proxy P, and
one Target T. Oblivious DoH assumes an extended Dolev-Yao style attacker which <xref target="Dolev-Yao"/> that can observe all
network activity and can adaptively compromise either P or T, but not C1 or C2. Note that compromising
both P and T is equivalent to collusion between these two parties in practice. Once compromised,
the attacker has access to all session information and private key material. (This generalizes to
arbitrarily many Clients, Proxies, and Targets, with the constraints that not (1)&nbsp;not all Targets and Proxies
are simultaneously compromised, compromised and at (2)&nbsp;at least two Clients are left uncompromised.) The attacker is
prohibited from sending Client identifying Client-identifying information, such as IP addresses, to Targets. (This would
allow the attacker to trivially link a query to the corresponding Client.)</t>
      <t>In this model, both C1 and C2 send an Oblivious DoH queries Q1 and Q2, respectively, through P to T,
and T provides answers A1 and A2. The attacker aims to link C1 to (Q1, A1) and C2 to (Q2, A2), respectively.
The attacker succeeds if this linkability is possible without any additional interaction. (For example,
if T is compromised, it could return a DNS answer corresponding to an entity it controls, controls and then observe
the subsequent connection from a Client, learning its identity in the process. Such attacks are out of
scope for this model.)</t>
      <t>Oblivious DoH security prevents such linkability. Informally, this means:</t>
      <ol spacing="normal" type="1"><li>Queries and answers are known only to Clients and Targets in possession of the corresponding
response key and HPKE keying material. In particular, Proxies know the origin and destination
of an oblivious query, yet do not know the plaintext query. Likewise, Targets know only the oblivious
query origin, i.e., the Proxy, and the plaintext query. Only the Client knows both the plaintext
query contents and destination.</li>
        <li>Target resolvers cannot link queries from the same Client in the absence of unique per-Client
keys.</li>
      </ol>
      <t>Traffic analysis mitigations are outside the scope of this document. In particular, this document
does not prescribe padding lengths for ObliviousDoHQuery <tt>ObliviousDoHQuery</tt> and ObliviousDoHResponse <tt>ObliviousDoHResponse</tt> messages.
Implementations SHOULD <bcp14>SHOULD</bcp14> follow the guidance in <xref target="RFC8467"/> for choosing padding length in <xref target="RFC8467"/>.</t> length.</t>
      <t>Oblivious DoH security does not depend on Proxy and Target indistinguishability. Specifically, an
on-path attacker could determine whether a connection to a specific endpoint is used for oblivious or
direct DoH queries. However, this has no effect on the confidentiality goals listed above.</t>
      <section anchor="denial-of-service">
        <name>Denial of Service</name>
        <t>Malicious clients Clients (or Proxies) can send bogus Oblivious DoH queries to targets Targets as a Denial-of-Service
(DoS) attack. Target servers can throttle processing requests if such an event occurs. Additionally,
since Targets provide explicit errors upon decryption failure, i.e., if ciphertext decryption fails
or if the plaintext DNS message is malformed, Proxies can throttle specific clients Clients in response to
these errors. In general, however, Targets trust Proxies to not overwhelm the Target, and it is
expected that Proxies either implement either some form of rate limiting or client authentication to limit
abuse; see <xref target="authentication"/>.</t>
        <t>Malicious Targets or Proxies can send bogus answers in response to Oblivious DoH queries. Response
decryption failure is a signal that either the Proxy or Target is misbehaving. Clients can choose to
stop using one or both of these servers in the event of such failure. However, as noted above, malicious
Targets and Proxies are out of scope for the threat model.</t>
      </section>
      <section anchor="proxy-policies">
        <name>Proxy Policies</name>
        <t>Proxies are free to enforce any forwarding policy they desire for Clients. For example, they can choose
to only forward requests to known or otherwise trusted Targets.</t>
        <t>Proxies that do not reuse connections to Targets for many Clients may allow Targets to link individual
queries to unknown Targets. To mitigate this linkability vector, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that Proxies pool
and reuse connections to Targets. Note that this benefits performance as well as privacy privacy, since
queries do not incur any delay that might otherwise result from Proxy-to-Target connection establishment.</t>
      </section>
      <section anchor="authentication">
        <name>Authentication</name>
        <t>Depending on the deployment scenario, Proxies and Targets might require authentication before use.
Regardless of the authentication mechanism in place, Proxies MUST NOT <bcp14>MUST NOT</bcp14> reveal any Client
authentication information to Targets. This is required so Targets cannot uniquely identify
individual Clients.</t>
        <t>Note that if Targets require Proxies to authenticate at the HTTP- HTTP or application-layer  application layer before use,
this ought to be done before attempting to forward any Client query to the Target. This will allow
Proxies to distinguish 401 Unauthorized (Unauthorized) response codes due to authentication failure from
401 Unauthorized response codes due to Client key mismatch; see <xref target="oblivious-response"/>.</t>
      </section>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document makes changes to the "Multipurpose Internet Mail Extensions (MIME) and Media "Media Types" registry.
The changes are described in the following subsection.</t>
      <section anchor="oblivious-doh-message-media-type">
        <name>Oblivious DoH Message Media Type</name>
        <t>This document registers a new media type, "application/oblivious-dns-message".</t>
        <t>Type name: application</t>
        <t>Subtype name: oblivious-dns-message</t>
        <t>Required parameters: N/A</t>
        <t>Optional parameters: N/A</t>
        <t>Encoding considerations: This
    <dl spacing="normal">
        <dt>Type name:</dt><dd>application</dd>
        <dt>Subtype name:</dt><dd>oblivious-dns-message</dd>
        <dt>Required parameters:</dt><dd>N/A</dd>
        <dt>Optional parameters:</dt><dd>N/A</dd>
        <dt>Encoding considerations:</dt><dd>This is a binary format, containing encrypted DNS
requests and responses encoded as ObliviousDoHMessage <tt>ObliviousDoHMessage</tt> values, as defined
in <xref target="encoding"/>.</t>
        <t>Security considerations: See target="encoding"/>.</dd>
        <dt>Security considerations:</dt><dd>See this document. The content is an encrypted DNS
message, and not executable code.</t>
        <t>Interoperability considerations: This code.</dd>
        <dt>Interoperability considerations:</dt><dd>This document specifies the format of
conforming messages and the interpretation thereof; see <xref target="encoding"/>.</t>
        <t>Published specification: This document.</t>
        <t>Applications target="encoding"/>.</dd>
        <dt>Published specification:</dt><dd>This document</dd>
        <dt>Applications that use this media type: This type:</dt><dd>This media type is intended
to be used by Clients wishing to hide their DNS queries when
using DNS over HTTPS.</t>
        <t>Additional information: N/A</t>
        <t>Person HTTPS.</dd>
        <dt>Additional information:</dt><dd>N/A</dd>
        <dt>Person and email address to contact for further information: See information:</dt><dd>See the
Authors' Addresses section</t>
        <t>Intended usage: COMMON</t>
        <t>Restrictions section.</dd>
        <dt>Intended usage:</dt><dd>COMMON</dd>
        <dt>Restrictions on usage: N/A</t>
        <t>Author: Tommy usage:</dt><dd>N/A</dd>
        <dt>Author:</dt><dd>Tommy Pauly <eref target="mailto:tpauly@apple.com">tpauly@apple.com</eref></t>
        <t>Change controller: IETF</t>
        <t>Provisional (tpauly@apple.com)</dd>
        <dt>Change controller:</dt><dd>IETF</dd>
        <dt>Provisional registration? (standards tree only): No</t> only):</dt><dd>No</dd>
    </dl>
      </section>
    </section>
    <section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This work is inspired by Oblivious DNS <xref target="I-D.annee-dprive-oblivious-dns"/>. Thanks to all of the
authors of that document. Thanks to
Nafeez Ahamed,
Elliot Briggs,
Marwan Fayed,
Frederic Jacobs,
Tommy Jensen,
Jonathan Hoyland,
Paul Schmitt,
Brian Swander,
Erik Nygren, and
Peter Wu
for the feedback and input.</t>
    </section>
  </middle>
  <back>

    <displayreference target="RFC9180" to="HPKE"/>
    <displayreference target="I-D.annee-dprive-oblivious-dns" to="OBLIVIOUS-DNS"/>
    <displayreference target="I-D.ietf-ohai-ohttp" to="OHTP"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
<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"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6570.xml"/>

<!-- draft-ietf-httpbis-proxy-status (AUTH48) (RFC 9209) -->
<reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8484">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author>
            <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="RFC2119" target="https://www.rfc-editor.org/info/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" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <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="RFC6570" target="https://www.rfc-editor.org/info/rfc6570">
          <front>
            <title>URI Template</title>
            <author fullname="J. Gregorio" initials="J." surname="Gregorio">
              <organization/>
            </author>
            <author fullname="R. Fielding" initials="R." surname="Fielding">
              <organization/>
            </author>
            <author fullname="M. Hadley" initials="M." surname="Hadley">
              <organization/>
            </author>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="D. Orchard" initials="D." surname="Orchard">
              <organization/>
            </author>
            <date month="March" year="2012"/>
            <abstract>
              <t>A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6570"/>
          <seriesInfo name="DOI" value="10.17487/RFC6570"/>
        </reference>
        <reference anchor="I-D.ietf-httpbis-proxy-status" target="https://www.ietf.org/archive/id/draft-ietf-httpbis-proxy-status-08.txt"> anchor='RFC9209' target="https://www.rfc-editor.org/info/rfc9209">
<front>
<title>The Proxy-Status HTTP Response Header Field</title>
<author fullname="Mark Nottingham">
              <organization>Fastly</organization> initials='M' surname='Nottingham' fullname='Mark Nottingham'>
<organization />
</author>
<author fullname="Piotr Sikora">
              <organization>Google</organization>
            </author>
            <date day="13" month="October" year="2021"/>
            <abstract>
              <t>   This document defines the Proxy-Status HTTP field to convey the
   details of intermediary response handling, including generated
   errors.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-proxy-status-08"/>
        </reference>
        <reference anchor="RFC7235" target="https://www.rfc-editor.org/info/rfc7235">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding">
              <organization/>
            </author>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems.  This document defines the HTTP Authentication framework.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7235"/>
          <seriesInfo name="DOI" value="10.17487/RFC7235"/>
        </reference>
        <reference anchor="RFC7231" target="https://www.rfc-editor.org/info/rfc7231">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding">
              <organization/>
            </author>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke">
              <organization/> initials='P' surname='Sikora' fullname='Piotr Sikora'>
<organization />
</author>
<date month="June" year="2014"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t>
            </abstract> year='2022' month='June'/>
</front>
<seriesInfo name="RFC" value="7231"/> value="9209"/>
<seriesInfo name="DOI" value="10.17487/RFC7231"/> value="10.17487/RFC9209"/>
</reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <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

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7235.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

<!-- draft-irtf-cfrg-hpke (Published / RFC 9180) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9180.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8467.xml"/>

      </references>
      <references>
        <name>Informative References</name>

<!-- draft-annee-dprive-oblivious-dns (Expired) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.annee-dprive-oblivious-dns.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7239.xml"/>

<!-- draft-ietf-ohai-ohttp (I-D Exists) (Used full xml entry 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> fix author initials) -->
<reference anchor="HPKE" target="https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-12.txt"> anchor="I-D.ietf-ohai-ohttp">
   <front>
            <title>Hybrid Public Key Encryption</title>
            <author fullname="Richard L. Barnes">
              <organization>Cisco</organization>
            </author>
            <author fullname="Karthik Bhargavan">
              <organization>Inria</organization>
            </author>
      <title>Oblivious HTTP</title>
      <author fullname="Benjamin Lipp">
              <organization>Inria</organization> fullname="Martin Thomson">
	 <organization>Mozilla</organization>
      </author>
      <author fullname="Christopher A. Wood"> Wood" surname="Wood" initials="C.A.">
	 <organization>Cloudflare</organization>
      </author>
      <date day="2" month="September" year="2021"/>
            <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 which
   authenticates possession of a pre-shared key, and two optional ones
   which authenticate possession of a KEM private key.  HPKE works for
   any combination of an asymmetric key encapsulation mechanism (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 key agreement, HKDF, and SHA2.

   This document is a product of the Crypto Forum Research Group (CFRG)
   in the IRTF.

              </t>
            </abstract> month="February" day="15" year="2022" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-hpke-12"/>
        </reference>
        <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
              <organization/>
            </author>
            <author fullname="J. Schiller" initials="J." surname="Schiller">
              <organization/>
            </author>
            <author fullname="S. Crocker" initials="S." surname="Crocker">
              <organization/>
            </author>
            <date month="June" year="2005"/>
            <abstract>
              <t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts.  However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities.  The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult.  This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities.  It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications.  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="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC8467" target="https://www.rfc-editor.org/info/rfc8467">
          <front>
            <title>Padding Policies for Extension Mechanisms for DNS (EDNS(0))</title>
            <author fullname="A. Mayrhofer" initials="A." surname="Mayrhofer">
              <organization/>
            </author>
            <date month="October" year="2018"/>
            <abstract>
              <t>RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications.  This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8467"/>
          <seriesInfo name="DOI" value="10.17487/RFC8467"/> value="draft-ietf-ohai-ohttp-01" />
</reference>
      </references>
      <references>
        <name>Informative References</name>
<reference anchor="I-D.annee-dprive-oblivious-dns" target="https://www.ietf.org/archive/id/draft-annee-dprive-oblivious-dns-00.txt"> anchor="Dolev-Yao" target="https://www.cs.huji.ac.il/~dolev/pubs/dolev-yao-ieee-01056650.pdf">
  <front>
            <title>Oblivious DNS - Strong Privacy for DNS Queries</title>
            <author fullname="Annie Edmundson">
              <organization>Princeton University</organization>
            </author>
            <author fullname="Paul Schmitt">
              <organization>Princeton University</organization>
            </author>
            <author fullname="Nick Feamster">
              <organization>Princeton University</organization>
            </author>
            <author fullname="Allison Mankin">
              <organization>Salesforce</organization>
            </author>
            <date day="2" month="July" year="2018"/>
            <abstract>
              <t>   Recognizing the privacy vulnerabilities associated with DNS queries,
   a number of standards have been developed and services deployed that
   that encrypt a user's DNS queries to the recursive resolver and thus
   obscure them from some network observers and from
    <title>On the user's Internet
   service provider.  However, these systems merely transfer trust to a
   third party.  We argue that no single party should be able to
   associate DNS queries with a client IP address that issues those
   queries.  To this end, this document specifies Oblivious DNS (ODNS),
   which introduces an additional layer Security of obfuscation between clients
   and their queries.  To accomplish this, ODNS uses its own
   authoritative namespace; the authoritative servers for the ODNS
   namespace act as recursive resolvers for the DNS queries that they
   receive, but they never see the IP addresses for the clients that
   initiated these queries.  The ODNS experimental protocol is
   compatible with existing DNS infrastructure.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-annee-dprive-oblivious-dns-00"/>
        </reference>
        <reference anchor="RFC7871" target="https://www.rfc-editor.org/info/rfc7871">
          <front>
            <title>Client Subnet in DNS Queries</title>
            <author fullname="C. Contavalli" initials="C." surname="Contavalli">
              <organization/>
            </author>
            <author fullname="W. van der Gaast" initials="W." surname="van der Gaast">
              <organization/>
            </author> Public Key Protocols</title>
    <author fullname="D. Lawrence" initials="D." surname="Lawrence"> fullname="Danny Dolev" surname="Dolev" initials="D">
     <organization/>
    </author>
    <author fullname="W. Kumari" initials="W." surname="Kumari"> fullname="Andrew C. Yao" surname="Yao" initials="A. C.">
     <organization/>
    </author>
    <date month="May" year="2016"/>
            <abstract>
              <t>This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached.  Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.</t>
            </abstract> month="March" year="1983"/>
  </front>
  <seriesInfo name="RFC" value="7871"/>
          <seriesInfo name="DOI" value="10.17487/RFC7871"/>
        </reference>
        <reference anchor="RFC7239" target="https://www.rfc-editor.org/info/rfc7239">
          <front>
            <title>Forwarded HTTP Extension</title>
            <author fullname="A. Petersson" initials="A." surname="Petersson">
              <organization/>
            </author>
            <author fullname="M. Nilsson" initials="M." surname="Nilsson">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy value="10.1109/TIT.1983.1056650"/>
  <refcontent>IEEE Transactions on the user-agent-facing interface.  In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.</t>
              <t>This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7239"/>
          <seriesInfo name="DOI" value="10.17487/RFC7239"/>
        </reference>
        <reference anchor="OHTP" target="https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-01.txt">
          <front>
            <title>Oblivious HTTP</title>
            <author fullname="Martin Thomson">
              <organization>Mozilla</organization>
            </author>
            <author fullname="Christopher A. Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="15" month="February" year="2022"/>
            <abstract>
              <t>   This document describes a system for the forwarding of encrypted HTTP
   messages.  This allows a client to make multiple requests of a server
   without the server being able to link those requests to the client or
   to identify the requests as having come from the same client.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ohai-ohttp-01"/> Information Theory, Vol. IT-29, No. 2</refcontent>
</reference>
      </references>
    </references>
    <section anchor="use-of-generic-proxy-services">
      <name>Use of Generic Proxy Services</name>
      <t>Using DoH over anonymizing proxy services such as Tor can also achieve the desired goal of separating
query origins from their contents. However, there are several reasons why such systems are undesirable
in comparison
as contrasted with Oblivious DoH:</t>
      <ol spacing="normal" type="1"><li>Tor is meant to be a generic connection-level anonymity system, and it incurs higher latency costs
and protocol complexity for the purpose of proxying individual DNS queries. In contrast, Oblivious DoH
is a lightweight protocol built on DoH, implemented as an application-layer proxy, that can be enabled
as a default mode for users which that need increased privacy.</li>
        <li>As a one-hop proxy, Oblivious DoH encourages connection-less connectionless proxies to mitigate Client query correlation
with few round-trips. round trips. In contrast, multi-hop systems such as Tor often run secure connections (TLS) end-to-end, end to end,
which means that DoH servers could track queries over the same connection. Using a fresh DoH connection
per query would incur a non-negligible penalty in connection setup time.</li>
      </ol>
    </section>
    <section anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>This work is inspired by Oblivious DNS <xref target="I-D.annee-dprive-oblivious-dns"/>. Thanks to all of the
authors of that document. Thanks to
<contact fullname="Nafeez Ahamed"/>,
<contact fullname="Elliot Briggs"/>,
<contact fullname="Marwan Fayed"/>,
<contact fullname="Jonathan Hoyland"/>,
<contact fullname="Frederic Jacobs"/>,
<contact fullname="Tommy Jensen"/>,
<contact fullname="Erik Nygren"/>,
<contact fullname="Paul Schmitt"/>,
<contact fullname="Brian Swander"/>, and
<contact fullname="Peter Wu"/>
for their feedback and input.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIACaADmIAA9U97XIbx5H/5ynmqKo7sg5ASFqSbdpyQonUSbEoUSQVJ5W6
Ewa7A2CLi11kZ0EKVpRnuWe5J7v+mo9dgJTspCp3qYolYXdmenr6u3t6h8Oh
aou2tEd6582kLG6KeuX0yetL/ebGNvrF1dX55Y4yk0ljb4508kb9QuV1VpkF
jMwbM22HS7Mq18N82RQ3dlj7N4d5PR8eHKjctPZIZfDfWd2sj7T9sFSqWDZH
um1Wrj3c3/92/1Bd2/Vt3eRH+mXV2qay7fAE51bKtabK35uyrmC9tXVqWRzp
P7d1NtCubtrGTh38bb3Av/ynUmbVzuvmSGk9hP9rXVTuSJ+O9I9FVVnT0G8M
+2lTZJ2f62Z2pI+Xy9ICENmIfnOwgG1h/5WVR+emudY/mTU9zooWdvRstbRN
W1T1QD8zZTGtm6ow+ttH+wcP+a16VbW49XdV0dpcX7aADKfrqT5eWIDC0Ft2
YYoS0HPNIP3O4HKjrF5093I+0mfZmalWLtnLuWlhnuvOE9rOc+Pacp3Ov8gW
+Mrv8lV27epqtrnC1QjmW8konv+qXizWya//N1DVEuHdhSjYxh9sszDpNky1
NsmvtI1nZb3Kp6VpbGcbB/sHsO3bytkKwUj2cGkq/bwxVVa4rP7lUN/g8i1C
8uF3M/xpE/RnI3080j/VdZ4A/2zeFK6tl3PgzvTpP2UTmbn93dyaZVHNJkXr
RsCwSg2HQ20msLbJ4F9X88JpkBSrha1anVuXNcUEJjR62dTAv3Wp27lptSnL
+tbprCzgPafbWs+L3MIzWzT65bk2ed5Y52DktKkXJKHg33UJeHTqpqDpPqwB
EG2rrFkvEXZ8qQ5iTO+C0NrTC5jFzKwbaQKtWMDAG5gW5ZbJ1rBTReOAQk1b
1JXTk7WuaoEQF4BD0yCHtLMNTg7wAi4R4onV5haQj9ia1O0coZcdwRaUbAHG
5/ykBiEHj+BtXPEvK8Cv5cemcrewsZHgD4QlPEMMmjLiDRFrb2wJoOa6XrVO
EKZfnl49p2ngjeUKJLGbwxtAMfC4VrMVvgf7Li3NiJscwC7cCp4XKHdp75Oi
xG2ZBUiH3tsganF2W5lJadUtTDd0mQFWT+DE90ZMDIsiz+E99QClelODyMGH
SnW1jBzPx4//cvH82TcPv3n46RNsb1pURCwLm81NVbgF4plOgnDmD5Oxr4Dm
KrcoWjz8oqJ54yuIN5vho9sCzubq1aWQABIA7CHQQo4nM4Vf4GANIkHRkYBK
wV8y2poGmUUQEMJMxpQCa96YhhRkVjRA86i2Movn+NO8AATBFoFpKlgSDg6O
3hogvRwQDngTys6LBqAs10DeJkdyS0jFeVqxHxAdsKuB8hwD0yKVEo+n5IT4
gp9gUguK2VMWr8UU7AghQEAaoYIdVzPFfFfWcKwJ9+ldpt0VbhUwsGBcmAkO
RjgZaUA2NQ+mxwBzZIQ9BQDhP3ltwMw5bL92pnTarbK5Nk53DZHdjx9/+3J4
MoL9WbvFvqjcp097AE8GCHPW87ECriWaRhRWtXbwJx4ATCh8Cyd/D7fqPrcK
HSl/FKNN2cbE2jGSkFPuYN/JqiiB+SsiCpKB8BYQLxHkh8LmigTcivkTSOt2
XgB+OmSP4Ed552qeB7fLe0RaK6rcLoEqYHmhKvUF202W0cmWj5lYeGsdUDxJ
5ixyO1ggOKerEuxDpBoRzUESq2de6iP0twYgAiLpUyyrCZiosaW9kZcQVNA6
YDRe49/X9ALgVChaBYoWTWI/AK+m+0UMEUGvHAvPUwBtXzNE+nI1gdlBGRAh
AyGCbPr6m68PBvrSEs/rr0cHo8NPn5CqRY6AtJoXETqvpWABBKODF09DUbqh
RkJk54Aj1igAV45MgRonvofih2fGSYXmh8D8rmgBaZ5KkWwQiElTmxzpAX/+
EFSOjPv/rmbgMCwcTvwZVAciaFHDUrltwVZxiZCK78HGHzzQl0ubFdMiSqsL
+5cVSGF8wyFqrAa/RKNj4vTO2bvLq50B/6lfv6G/X5y+fffy4vQE/3754vjV
q/AXJW9cvnjz7tVJ/Fsc+ezN2dnp6xMeDL/qzk9q5+z4TzuMiJ0351cv37w+
frXDx5oKH0NIR3oh1IJ+aYlslLe4SCE+fXb+P/998FCU7OHBwbeAKdG4B1+j
xr0FHcer1RVIC/4nMpYC+xr8EZwF1C+wzbIAKsEjArk9B+OSDh4QCmr+CuVY
VZf1bH2XkMRzmNbeogKIF+5Iqcgc52jNHSlwL0SNi0BjOUny0fUsvdR+AtZY
AgHBvyYgHKwFoD1Ls3mVLHVlmpltB56SWYVNQf6i4Wf0u4uXAB8QJtjBgqvH
j77eB1ztOiK7qIoaoBvrgPr2Ruo1GBsMLR1Ub2e4ENmUIETQokQTB+Uj75VM
2QEoiJblgWtBaMMbDgkVpNnPoBsEHyQd4OCB3EGXwal1VGe0ddXGhu9Crohd
xmNuCcMpqgWNKcbJlgA52tvkQPFRtKum6h9WPCC03WlhB/4NDxyBoQgWBAqs
RKx2hhFRyk4UynC0vTtewQB/yuohmSHe6DPJYxAQHmtoI4UnJA2bejWbe4EB
T1q2YhJSHuhbG5QGEbAcLW6aAWMtNuVtpPhR8c1NOsQ9onIBkYuS+YE+scuy
XhP7dCVTV8c2/AxZskWLuaiKxWoBXDXEc+4TIB/54F5yH/WHyrbEdNNX4Qho
K7KphiUsWdoskqq6GoImKVdkzxLbgBf58aOzGdhn7RoeVqhVxOEi/hlSBMEL
cVmFtEyG0tiRgBeawllTeiQbmM5UxiGNGYYPFgaDkieCeXAt3IezPOtsZcCH
aK3wLglBMmy9UpYZkeSEOTxHyOoj1hhdVZ2jfw04Y/cxZ5p2sFlv4DPuOrIm
oaNk3wpIEOkSyBGmXNoNuiSSIa4+FYtMqXdVWVxbcS10alZGeTGvXYshhuQx
W3JIW0V1g7yBcrsB3CxN08JWgbYOmAoYBQMxUWe2wrOE1wNODvk9lgvyWpA0
UTR0JEobJmacGXL/4dcFWnjJ+Y7UVykxbswv9vSds7MIsgn/LslNjUMx6BF9
8r/97W8UBdHo3f6ZmBIlRNwGO5j9s9P/CQN+UP8+9P/7d53+L/5+7xP1Vw92
53eYOWHUu5/8Fcb7/33feQvXZAxseSKb0TD+74VfVgbEaUAdy/M+7tx6sbAY
zCS8acLckPD+8Ug/mBYzCit7l0NTBPvJzpvJTSoQPf3vfCIzj3jCn9XHB5tq
uy9Qg0EBAgidy5ZlZJvQO9KKs9HYFwpytJiSiZ2Y/vTCG7AaYWvzOh9p7/bQ
AhhymIFtHDRVFAlXIhJUx/zwnpocDbzITOAy4BBLYif4eZtz4XDVHa7JpAV5
vTNv26XbSVi2O3QlfKhfoV+gv8LTq1G2KzbvyNb0DhK4RyijUtAZb+iLGDBu
NHhvFDZBM98d6Z2WIEJ5BPYvszL4sGify7L4iMKhPrTQ0UvfsbHMsyxNO79j
FnxEriI9S6bBwEAGzO8KAGgEZGTQLcHYi9pEBp8eW8ATcJJuj1g+EAqPfvOb
vHJkzo0sT4M/DJGy1h9/Gzc6iNB+unvoxzjgk/8HD8EVSe10zonOU9AcaSHF
7waq4kGwq1yuVV1llk/MuzxhToqEthiKDsOYaOIsnqaQqMUZxYUUUCdhAeZa
gAjwwa2W9xB5g8YXs6pOeETisqSh85oMaXxUNwsOLsEBBhNGfENhxaGgUhxE
is3QD1peGPWFQIhvzM0NWjKg+TPaYLmyGFTKLGM28HrX/cBQfJRtLAfsEhm0
AR8bhdsCoARklSMvm/pTBKyjPYuL5wBkBz3Osp1KEu4Ze/7DqzUYB3NrxIre
wfyI+Li/6UTPhrLFHUSeZ5HEdZGdEVtUelNErqNxhDj1cfhwhArcxFqL28ug
wlRk7TMWcVQA/xg4D2wqBhwDTnC0jURESczYPEA0N+7+fX/BpgcqSDOaJhHQ
PTH1hXwDzss0ylw1peADYBbOOftlDBjMFHwAlnrLp92iKsLfvX5BfbMwJUfW
UqGNZnXbrLLWeb7qCUzSNAQSS3zRHQOtosbiM4JxXbDjlCS/gjZa2ibDYwDj
mM6qP5w3ycMVDscfRgRw4YkdgMiumQLF1IncRWKgRxCJdGJvUxv18MMHvSuj
T5umbvZ0IXFomp3OBQaWGHcKeCC8DTHntXKBBYWaFOvlSu9YnG8HrWAgYuBe
wiqSHaHxvQD7Xl4DzYfh68K20yE+nxRuSEwydLTOp08cBOf9H/8JAKxrR+Ec
lGzeR4XDrKzkGehRNaSkOD5b1k3ryGumEHpmyEOWOZUEgT1fg7GFgHkz4+H+
V3GnDJFGrHZwY7ZjRgmf/VLMgM8JRvVOdwk4tSXgZQnkD6YOuJClqTgkB3pj
R8J4O4CrlL982gNmNRSBBFAjprxZ5v2CotX3I0M92j/81djQn8MGmCF0sIiQ
ri2CqQsMZD6vG6+RBkivIaDB/pgQbQSbploUs3mL6a8dEGzv22JhwUHcQS/I
4rye7q9eXaaowblsftdcwK6le+9jwELKgPt3sFN2rJbkgwbG5BiQd/AY4cLO
IAKKPNEpdqsAV79SgBPv3ynDR8qDggfPJxUsbJQR2w6bMQZKKhEVo00fQgxD
8CX61gXbYjG+6Y0MNBPR076N4ciAQE5veATu9I0/UFQiCUgNR5vCJ2lQx8Mg
lrJhFKuDjlUo6laFQOTOr7dVk/lh2tSf6M3bBStOvCPu9BEfl35Ch6eOxIl5
omkOdcQFPZgpeKL7YKojMuWf6DhtAu6TjdX/NW7gSRyiDFseT/Rnac5nV4bE
Mr9kQGmrGYF6sP9Yqe+frlEAiIXBsaHkZLtpUALyh2jp8/FhTpriXf2Qumex
vhA8+lX47iJwC8L/P2Ev8rGwfjcYwD8KDwfx0IvgptavCwGvEB+QuJR+2XYs
9K6MIyB+kYXOTktZoppHB3W6KqOjMCKAJ3W+9lZeAD7YsB0MJRmC7zTnMnxA
ta7IKulgQCS88HfH8fh7t0UuuPKuosi5iE0h9ToJvYz0sZegNIwCtT6MzMF8
hpq9+xhr6B+CACquaRg2sVP0OEHOUCBAbOGlWZe1yXHxuIDUTuDzxIDxE8um
VCsBJMOHQBoXNRfsdw5/oipORpdrWAPOmZ1rQwmB4B8TgsP6lCKl6Wge4gNw
OosKRlIFF1d6eFORs87e3PTGZfQ2g9MRUxiZD+7KTtHrX9R5SJk6fzRMe02q
SkeJrEr9QJPnX2xGSRw3F3s5NS/FiuKKFTEuUkV+a+5mTpXk6EDhJxrZJ8D0
V2AgpNORP0jWueOkGxUiIbVxaJ1NM7eaOJS+UbszadP+J+QiSRVEy3mmEOwr
krSXuamLPFYDgT1cu0Swu65Yh91cdCwJsYsngYb7+0d8r0qqENjiK0Wp4t1Z
ybUhCuRVSphI/IW8WzKwOUwg+uNnE2xNTPvvcrYxwejD/QOWPT5c+NXoQIVw
4deHXz2iDM0b5IPbwrFVHMXAv3XCE0VFpuYgFBIJV6M/hMwjCRssPhOIgKgb
NOuDEQUigTKDuXUUlentYMB2Ie5RT0yMRGzb2P53Kt3Y49Gj0YFOt3ZAiS51
emPJxfFQdtOjkcIjDH57l6cXf3h+/PIVAvz6jydvzo5fvh5gnjhqh46sEA9W
H/bIunChyoScHLHKU0DwHUKuL5v0iXIsEMNiTSzIA5WYlu8pFmyuJ7Bwya45
LQ/Enr7feGbody/DFvcSHS2Ej1RPUfmuymprZdKUj3Cdt0AFI0/04f7+P8JG
efTwF9oofh89M+UMPF9wn8w2qb01YOhLHkJ6ISQSHVVrcLkLR+m3li+MlF+T
0ejDI87GcGhWr0qcweQ3tmm5tuzWmmuLIgyAWdQ3tmcu+QrbJVX+tJQX7MR9
MMhJuVvUMAz9UPLTVNm7WXMYCsdqv8PAHWrnubcjdlKbxPkyrsOvvoWt6uM8
L3BGMKvA7+rEVRGeosrKFYn+NW+gZQ2DHrxKZbHsJHInrZnV9TVuVMLQ3SJS
iUI3tiT1hEnilXNhd8onP7uVpwkWKNf7LI2KcyKeU44/2jUGFOBVsHBjxlup
UF3ByE5dSBNiJUl+tLI2pz1eV6TukpQm/AiiQ/WS8VjE6FO/+v5sOPvZnS0U
Tn0uw30phauoPbnMoqYzSQsEGjtblaZBU+olqYeksEoqTmQWGUzpdXuDNn1u
YNQlaDA0MuhxQUWFVY4yCNT9KuPokanqar1APwltYYC0U8rI0RREEFmPAbgY
m0F5u20JrHZj5YXxnGkjyS6wASgrRVkTEG6gETFGXvUkSXJAfdSieqCY8IpL
Rzl+yuHeq1eXYGOtS0pZUEIvyPOHjylt50QuO3EjeSr9EZO6q6JqDx7Doov3
Rf5d+ks+7f1igBP9T/XSAKkIyO8B5O8PRqPD/zp4PDz44Tv1Ke4MRAiTutjv
7ju1bX08UdhquhzLZPrF2RJLIHY3Zx3JwD2eDa9CoELe/7C/v39wdA8YoTyW
Fvi0FeTvkrRS+HHLe66z+eDrj7e8OU7OMbg3dVIzs2VQMoaMIzSIgArxoFkg
1FO1pIolIAArql5uZphQJVaDiFtiyFkvwIAsUDcL7shF6VX+goQJrznbbr6i
gjnvmJa3Ah5dWL8YJYIAWufrQHHmDR+9Q/8DFSL90b4AVVjmuLTMq444hcn/
2twRSjCfM94iu8iU2p6/BB2i7j8VH5n0i1NJs5jYgvTRvdCpjnbv1ojC38dM
zmPYLTOFbJb/QVXmE7RYBt7XrLBamDAEQzyhc+WgMC6+jxtAVHJ8O1xW4Lpz
zfvwIHOQGyHzsGZSG9ymFx0M4WsbLXi+S9B2J93Ed9MIQMeQQOXGlWqiwBKF
uKow73PPvKMotsas+LtlY/VtJUmQueStKAAdarZbq0hIJ9Vkbbxr4HPp5YqN
vvt2OGK5Ox7cCy6L4jEnzO57UST0WBkqoU5qiEPhu/gyL85/PH1CCa6mnQ6z
aTMbzpfXFk0rsuOJuwIxhiOjiTv6hDcgBImz6h9Pz2J9YtPDHxzYOMH+38tx
eAysBQ2tu43zAEbCXwfGk+f/HBhh3e0wytGlQB6fHp/8M6CseOXtcMYlU1AT
02Xl+gVXKZdurdUig/jc31w4DVbMgySwKSXpTuhYDHwXipiIN26LhgKRaDz7
GwTIgf3LPWCp2bJUBo3IVUul7T1bOCmjltuJMS8ubvCZiJtgrHtQOAiN2Mfy
/tua4hNblKz3yo70W6lZ2wVBf7BHi18ExxB/PNwbqadYsBI9OdM0655OTAQk
F3kep9FiX2CJV0YKjlDSwhT888sNRPyTcVH5mycjnOzc5Pwz6OtmUrSNgaHi
OPPMncolDHj/bJtaSmvX/tYT4TEWKkToA0lusVJFa2GmVHbTMbkSg5SB/H7/
TmtUju28NAXtTQw2wi6jI0V/RLgvGh/fN9lYqE+iE/e92gGKFv7uy9/34Anw
x2l44jMAFkw7YmuYra+PVaAZf2KfdSK+0R5X75He00MBsQCirXMm8WEAfOvJ
bj27u2xsD/02G3ub9Qg7SUFGAwlt8SEZR4ng9aVOFFYC8g+KnumlQyLjdMYx
OiIHgw5Fqc+8fogKixAmAjYBZKtJcq8BBTPF2B+6nyu5YTQ+/bAEsHZPP9CV
792dnYEYxXsDvVPn9ZykeYH1Hq/ne2NxfvU4Ew1SME7v8bASqwHtFlkJZpK1
vUHzej7WYldEO1g0CGmXrKCL825VwLmgCu1rQiVQeUsJULhBVmz+bmbg/eFu
3JfYxSfdE95DUSlKjR5viAmQ0y+71+GoOMiiZM7AYi/oqqjY1q74OcZJiCS7
0jd9ZxnkAIj0QEMjvZtcoRiwFvOVKLcFiGDU3uAtShEbzUZA4JzMZSgGlnQZ
GpzHPWar9ObyNhYbbaB3nPgNW0d0CH2E0Sy6j5BhtGfwxYsUaTbUe4/d0XRk
YyUZB3/MFEOhR1vMaH+MY71tlH/Kav80ro3znITshL4QWyLWeXqdEQUPvEE3
J6erSqrC+oZHooSiAaIiFMgmHdP+40fk1iHn+ygBLNO9p0z3e8zvHXmw70iH
i77K7VRvDt5dXl8MRIgP9Nv3RIp72KYF3h2E26lPwMloV8unxtlLHsJihCtG
9uB1Y7B0AUWi/utf0XTY5Un38J8i87TOcCpveFxaU+7CuLguvPH2fWTjJwgE
js+wQ4YUEiYvsKoQTL734XZBihzeJlKaeOQeL1un2BU4A3gDfRHX5lth7yus
xSZ8kZFPkUT6Gz3AUg2Lt+PfO4zrtG7LnMk0KRoPPRqT5/hT/Ce8feEn4XTz
E/1myYgf6EqKxBG9Cdh7EZHdwYna7YI8DvTM9449dVJpPdp/ksf4En4gaRTy
9+n1UL7eg9yQVGpvZwaufCFmcEiUQs2C2SOkVL1a4rmzghESJt+FYt028QQ+
wzBbFth1XY6JqBWuYYKFw0gpVW9jpYtdYjK3jZ/kkGRUl9JT3r+TzPtb2Rwc
ifGu3XwZU9+957d9+vSsT3RKtJm1eylvb5Jklxpxw/hvXB1P0Nfqx+PtOHpf
wvpfzp+IEn4x2QrYO+A97/L5+QXQsLrGjTlTMlpoti/h6WVzDQO86YbjB7Io
zod2Gz4l+w6XfA/vJ0ZdWNjLnztepcf4cpWgPwqORBo0MLxe7L7eSwSBv0E8
fj3WhO161pjlHFPPJeZdMjTPeSBHL5XkfWd1jU0xVmgv1aiP2qZeriWn8XD/
m8c+SDVemA+7xwP9dMuyanxMynx8rH/QT72l+XTMtTm3nIHxqq6nFe5UlVtI
Y+sUu0FsbhP4m1rhF8rzVPmxfty6ioj1oDWDSO/pxgfJLsW2fWrnBn5osMYu
sS2UegVkPT4bx3vb3lDaJZGxF+txbrGvhJOb4NjBhwNNvUYaP/lCyK2syJZQ
t2kGrt6v6kvuRdwXRx0H52UQ4czrfl8DDp08o8qvjWA2G5fRtRlwIMZHMzw6
zuTuKwUjBoIFSj8Kl1NE5SSUqwS/qhOaToZ10rdgXIUS/eD5cCCZ5n3Gfh5X
iW84PKAyxxsW1BeZfGO8kkdOID9hczzxK0kBd6oRNVVrUQ0VxdjHiYIY45Vo
GMj4l0gSOhwyu6IGC+1tzQ75qnLFjK8ptnaG14xgq29ohg45RAcibHn8duzd
17cdR0Q0F/qkb0d+UxwecQEO7ogAL2z4I11lNpbaSx/1jEW+uH73rmkGLqwP
495RzfGmkmz1ZoVbqJ0ZX4wHyRFvqRNJraGBKlouuh9vtWYJSJ/RGF9s8792
OXIHDz22jAPnRGRVcgnbS55eXDrcKhj758IkMLVxMWi4p6SW068nbycRwPGo
K7tECvRll2w+GqFpv4zgbvkDfRv2L3tBQxQL5DrxLyC8V3V9jSbkRkiwL3M6
Rx2pjCr0sOUTpp+Qqe2HwrVukFbjY+QAqy6o2QX8/JfovoJqc3W8XeYvUGFl
nt59V/lCPrDRYh1ZSoGd4rwSpTpYmCTXqeZBSma4FKGXdaBoRVIVgZdCMYOd
YRqRW6y1ZG7Fwr2OVBpHK/dO09mjCf+2QYV7XSk33rAg7zNjv2RmPhm5YoRJ
AsKuv7Hm14uU66vsgIQD/Q58ZxIV3k9pF+mJc5gDvcbID/v+qUo96xdQ+gpk
lcKkJXwlwBC8oaIyIYv9u2pFO4JpdI/q8wGIpyQpPqcBUU+nOlAlysxz87iz
nJ4CSGJ1gkkZbB44ULEv0d57XZH12qeBf4Bn3ZvxYquK/LV23phLqoPi5Gjf
hkOCKRevfeLocSwxnoYAJNpW4vhwaA+LjWSjWIaO4oGEE5qIXQedG7b5ZJBx
rs6K2G0Hi+1D/rGnZLeH28OZXwQ1e7FFzR5imtsrDjzVuEHhrC0qB9672FSx
vjY0UbEXY85n3FNomhC6vzqx5QrJp7T6Pdze6tA27lPK6tOSej0xeAM2vfGg
k7tyG5I4VEODqJ4VlQmFv3ypHW+GkglHTSfrKAD0LmCtXw+8N0juh3XAFmTJ
fcF06fuxQFWKi2VZYDfMThMj0K1ZeLLRgYMsDKIgulke7daEyqUEAZeRXZqJ
w/Il2WdSuotiY4ptOMNtCLZxSOTUUUIa7WFqewB1G9TJJRgphuqGozbSDdSI
6cfTsyN98gL+2P3j4aNHB98O9IsfT54PL18cHz56vOdbismOOl0G93D4yfOj
dMA97x/i+8h3R/Dfy+HB4TfD/3h2ds+Ar/bwmE5DbzxqzXpT2FvMR8fOevd0
9P2SRpfsby9XzbJ2IWOh4jgSKrWmVj9UQOQ7X3XLrG6K0DiQSp+5gFYuViAp
KTgpk3GCpHeJdoI2mpHOoOQExWG+3L5uYjfSOFThMlW2HqVo4txDsTRIzZQo
afFGgO8DG4vbtJlOLfd7w0q6AinUNxkmvyCBYyBlCRR08rWzrlM8u/bdCRK0
4O0BoFJ/8Tsp/A6lCvhnZ8OLwB6Uo0luCDd2JfeLlnVdOhbIKrmlxIfJ90hc
SD8lh0no8D0sqbvEtFwRb05XlFT1NIJtCsElk1xFOHQ7neLN9nDAMEWvAGOz
ZSzdJf748bdvXlydU10Sd6en6/f13BTwn7ZdokPZT68J9kKfUUx4SeMrqaaz
qr85Topl9axC17uVdsJM91xHIi8FMqHKcZbGSR/Kl3Jxxr+TMxgrZpLNkkoc
nyfH3sc8N17DKmK3xJavJIMvpd8alown/daAwe/qxNYXyKZYcCG4tUuqBi9t
PgtteMCQE9dC9BA7GEmJLI2ppD6u9vbHCNvKGu2IFsnjBF1oy0F6oY+Kcdkk
aOm/7OVQVYw3Y54d0ILPDgfkRtAlYX1OFoHCH0R9XY36CHUOhJlIMGllclKX
9mb4JwN+FVZEa9O2oJKtL/3Eir16QhWx6Goq34MWk583Xi7hSyY3S+7ll9Rs
+7KZc7S5r7jTIxIJbACtskMJdvB9Fj8K0xXUauacb3RQ+Q1oUrDQ5cSpxx6V
hforIHxpA3EkLds6KVpNgYEIVs4+Y9gqXs/nTkjSdVujVO7dQRD3Nrp5saHN
LqkKvn+HoSkyNH3FT1Hiq+GiR+xXMdAduRUqdrmbCeauxe6Upuzxbov0ICTR
h02ZCiw8NpWFc+6gX9wvmKIERdB2aAgHlnYKrFclA0Z7JOoCZkBnwaN5MUlu
WErsUay1O+6tRImV9rQfJBdYPNpu8YKN4lbnnVNBuwvQXVD0uywqIDphOrHI
un623JfdU2weYbdhZi6ipcAy/uLN9ro6/Zbfe3vY7U85CFcYz2kLHOC6ii3V
ffPmYx5/LH0Aw2a8QKF9ADDw1923BwN4f88DRj/BuseHe/3mmJ2p6NYbXlTx
3RtwTm8moFz2dyfSe6wm3P5JO7nDGaSdOLAC4MqXvQQSwmYidAkq+MZoaPCG
N2MdVGtArdFpHKYiShfa5gRhonoXSNOGHZzU8K3ngHSbyl+2CX3XfYstDjeN
9CVRG6GIaZtv1ii+WTOVSmwmCaSR7ul7teD71YtRlCAWXQsi7pKJgZpZAw44
tPU2ybl6SkAgtmqBzj01FFO18+JmW7VSSN2S0MGxZHL3MnXk+qTlIf7CGV1l
ohLtqKmAYME8Y4OMnYfYHlMiZmsbWo6FGWJBDWdB9avi2rIn4bdD78aq8NAH
NlWWQFEjOxpEzzJpqtRf4Y2fyl/FrfCKRmjxFt5Xvsear6rv7pJ88ngdmL+m
4a8OE0tutMyk4ICXcRv+1qoqqHbSNkN+BwvQqG4TjDBwbgEAU64dUgmw3Uzs
D6HL0Fj8jmtf/aPsPFWUfiFLqxGXJESyOCHQK+D1KRjd6cKbRKeS/vR9S1Eu
scv9bwQZu52TPY1r0BVxqvHvAMBxdL5P9fhr8ovvYLewl1gJtdFbGD0VPEhY
2c0DN4Ze5sSPBui4GlKzjiAmWWbl6JIsiopsKinhTWSN8dH/DKRWvqwL9sxC
lCnyRd0oaSublmHrF/Wtpf7CdEhoSGAclBwgqQZOP7ChZzV+/6GEDWHuYQL+
DZdIndgK479ACpfsMil1BiMy/sSGyI1dAEjYeo9sLlJlk3q2cndoM1SU8UKs
kWWG9XTol9k9qS/3BGmBRfx9Qf5mAJj5bdlpERGug2JMnQRv5UMuGZys6102
Vdw+0MsI3+caO1/BDiXMAkjHlksxAh6vgbO4gLU4zEDyofeew5C6VKJ16v7S
urTQOy5Kx84OAyl4hBdVGgpTbGQytMSkYvEN8FY4U0HImOC3vsIq0uEMvVmg
wjLtOyG5CaQ6FbtJo9XnB4sJHSIy2tXc9XRBfanQGqXyRL7c5r900btLS5YH
vKTMBGjbB7H6t3RHKdX5rUSi69Oc13RdNN1xYSFW824esVzXBMfYyFeSZNMx
/Yf+Q2i4BIbJhHJWSfdFAi50lFP46SjJhMldQVIarGCdDSRe9AKGRM4CVsLd
xjG3DpCIGEFqizmeWB46tTxQ3FM3Q7Y/iOV5X+c1TocVkOkUU2w+TXdAuAgW
LTgJUJK4xUFruW5inVzhCF5mt7savRWRg5FUUtAbl+vl3jPdaw9BQqbk0A/c
JT1V0rakHELpte7zCKJPVCQeEPxjLd82CvwiljEKexAOK1OqRIatKgYseA5X
tderdtMEvgEQ6sb36Ni4DO3Bx1iPNO6/G/bUQaWFJsDyU/p2TRJbSkNOcvef
RF7Yg2AJfls1dJhABWad3p2OCJd2JWSIcN+Yth76buxRc4VGgPH7Hsddnv/4
oMffSp30a6WTGJTLbIWxvCgcUzuVoZTW+33pEhLPoM0u7AyoqkRfWqzZ3svJ
N2AqlNUYBNzojsCfs0n6I6i7mwN0jssX7guk9K2gpDMengLbbuU6uK4qUl2M
1HSb5vgpPAISyZ4Ahk5ayF0MkY+SoPwQThxEWsQVBiGK5Go/GHI5yip5A3Sy
XXDFXfLdi4iRri/sG3GxS43BOGIwlQCamFGU9E5z3r2uJTpf2d7eUnGNtKm+
cIrYQwfFNrXP+WwO5eXx6+PN2F0BNvVGWH5hrlEx8UfCPDJ2zugitgTf/Sc2
9RmAjyWA+PEgnHL37OXZKbvfZzYvjMZGWW4HGyoAqhrxu/3cGxdEe3ex0JfN
fLOKBz0t6Mtr4jr9jfCi5Djqyt4Cm+Cb3KfnC1qLoeuBaUP+eGLyvlKXq0kb
H23v6qIuPL/EOP6Rfv2bYzDdlxI32HgSrh12g6lHgQmNnoADxgVpcPKDtD9M
pz2buqPDS3KValuxEt8tHHBJMzVkV76eiq8VfqIWGuJs9KG8tLbveCUXObr3
JgTMcMcLwaR2rB9gdhTEVrqAqZf9Lz5tRU44dl985PwlzHqqpMd3Efs1xc+V
ha8eiejDEHE9TdraxY2fh09Vde6f9yDAK+XLJDUSwvES4/BUKMPiD+knvFTy
Ca9J1PNY0SjyK/nIZfoFE/zukvRg7n7EEsFKQ1bxmibT3jmQocRk6Rud4Ttn
FB4GKsuoo7Cerho2n9MZ4OTVMQku92/oqnBw0t+U5TOs+NIlIP9IowXx5jUy
Cd7/FyMBVpfHBBDP1/l2rP6+/8nWH5R6xl9ykMhYaWEIfl+MzCr+VIopvQQi
cH+rd30aF/0Ka8l824Nla5SVx5lPT4TPeFFQtbmWbyotia3hVLqtU77gY4PI
D6a6DkFx1ufyzWFR72QCRvaR19VrM7X2Z308N+huqdOyLIBbnjbFbOYG4GSA
Mqv0c1CI8PA5wIdfXNW/N1k9gceMwt9b/I7rQP0eMALrVGCMr0vAw0AhcvVl
NscPYA4UTAoPL2FCmAWWaopr/Xo9a+T7XkAp2Nvmp5XypjhAllPZAXle1XLV
yvc78UdE6TtORv0HencAFhvq4jADgt8xuYJUJ3KVzjg/c68D/8khfDWEwK9q
/kIhFXWabF5YqUBh4z2nsAD5DBaFLF1fSiNmMSxVNPEjhWnswd+ddvgDERD2
WUb+WjMUbg3KZcFaDLs9wLr0tTnsx1YvYNUC2amjtOSrNzV9QRKDnd5KMez4
oqMc7NFhSZ/ISNoE0YLi3qLd60AGzJAVJbkMg13LuduQSaRyBPuBrrf4Kq2Y
Qvcd9xMvIRUm5JITXxls1N5tF0LaqEQj9taSKbs1az+IbnZoYblpwslny9Iu
bPztvpzrb0EXGTTh0dmjfYBcxI+PUkINS9jCRzzz5MuEePkcR+N12jk4r7JK
145AAb9qpDFZgnvnv+DDLfi9b9SxFCmqXLJRQMmmKZgZTQ3UMASptuzjj5rZ
ECSedlJyrqdwiLpZVf5eQuo/7V69utzDgBq6LhZZlvdOEXPGG4cBJcxEkTq8
mRHjsPWNuP8Uh42Tj/Q7aQzBtW/S+kaeKtC7sttb6dtGHhd1ka/sDAiAMiPg
BZmSswiJS0W1ldSHaqT+F1EyzCgwfgAA

-->
</rfc>