rfc9230.original.xml   rfc9230.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- [CS] updated by Chris 03/01/22 -->
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.26 (Ruby 3.0.3) --> <!-- 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" category="exp" tocInclude="true" sortRefs="true" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
symRefs="true" version="3"> -pauly-dprive-oblivious-doh-11" number="9230" submissionType="independent" categ
ory="exp" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes=
""
xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.12.2 --> <!-- xml2rfc v2v3 conversion 3.12.2 -->
<front> <front>
<title abbrev="Oblivious DoH">Oblivious DNS Over HTTPS</title> <title abbrev="Oblivious DoH">Oblivious DNS over HTTPS</title>
<seriesInfo name="Internet-Draft" value="draft-pauly-dprive-oblivious-doh-11 <seriesInfo name="RFC" value="9230"/>
"/>
<author initials="E." surname="Kinnear" fullname="Eric Kinnear"> <author initials="E." surname="Kinnear" fullname="Eric Kinnear">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>One Apple Park Way</street> <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> <country>United States of America</country>
</postal> </postal>
<email>ekinnear@apple.com</email> <email>ekinnear@apple.com</email>
</address> </address>
</author> </author>
<author initials="P." surname="McManus" fullname="Patrick McManus"> <author initials="P." surname="McManus" fullname="Patrick McManus">
<organization>Fastly</organization> <organization>Fastly</organization>
<address> <address>
<email>mcmanus@ducksong.com</email> <email>mcmanus@ducksong.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> <author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>One Apple Park Way</street> <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> <country>United States of America</country>
</postal> </postal>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Verma" fullname="Tanya Verma"> <author initials="T." surname="Verma" fullname="Tanya Verma">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<postal> <postal>
<street>101 Townsend St</street> <street>101 Townsend St</street>
<city>San Francisco</city> <city>San Francisco</city>
<region>California</region>
<code>94107</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>vermatanyax@gmail.com</email> <email>vermatanyax@gmail.com</email>
</address> </address>
</author> </author>
<author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <author initials="C.A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<postal> <postal>
<street>101 Townsend St</street> <street>101 Townsend St</street>
<city>San Francisco</city> <city>San Francisco</city>
<region>California</region>
<code>94107</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2022" month="February" day="17"/> <date year="2022" month="June"/>
<keyword>Internet-Draft</keyword>
<keyword>Privacy</keyword>
<keyword>DNS Privacy</keyword>
<keyword>DoH</keyword>
<keyword>ODoH</keyword>
<keyword>HPKE</keyword>
<abstract> <abstract>
<t>This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers <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 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 cli ent IP DNS operations by not allowing any one server entity to be aware of both the cli ent IP
address and the content of DNS queries and answers.</t> address and the content of DNS queries and answers.</t>
<t>This experimental protocol is developed outside the IETF and is publish ed here to <t>This experimental protocol has been developed outside the IETF and is p ublished here to
guide implementation, ensure interoperability among implementations, and enable guide implementation, ensure interoperability among implementations, and enable
wide-scale experimentation.</t> wide-scale experimentation.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>DNS Over HTTPS (DoH) <xref target="RFC8484"/> defines a mechanism to al low DNS messages to be <t>DNS over HTTPS (DoH) <xref target="RFC8484"/> defines a mechanism to al low DNS messages to be
transmitted in HTTP messages protected with TLS. This provides improved confiden tiality transmitted in HTTP messages protected with TLS. This provides improved confiden tiality
and authentication for DNS interactions in various circumstances.</t> and authentication for DNS interactions in various circumstances.</t>
<t>While DoH can prevent eavesdroppers from directly reading the contents of DNS exchanges, <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 reve aling clients cannot send DNS queries to and receive answers from servers without reve aling
their local IP address (and thus information about the identity or location of t he client) their local IP address (and thus information about the identity or location of t he client)
to the server.</t> to the server.</t>
<t>Proposals such as Oblivious DNS (<xref target="I-D.annee-dprive-oblivio <t>Proposals such as Oblivious DNS <xref target="I-D.annee-dprive-obliviou
us-dns"/>) increase privacy s-dns"/> increase privacy
by ensuring no single DNS server is aware of both the client IP address and the by ensuring that no single DNS server is aware of both the client IP address and
message the message
contents.</t> contents.</t>
<t>This document defines Oblivious DoH, an experimental protocol built on DoH that permits proxied <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 independen tly read resolution, in which DNS messages are encrypted so that no server can independen tly read
both the client IP address and the DNS message contents.</t> both the client IP address and the DNS message contents.</t>
<t>As with DoH, DNS messages exchanged over Oblivious DoH are fully-formed DNS messages. <t>As with DoH, DNS messages exchanged over Oblivious DoH are fully formed DNS messages.
Clients that want to receive answers that are relevant to the network they are o n without Clients that want to receive answers that are relevant to the network they are o n without
revealing their exact IP address can thus use the EDNS0 Client Subnet option <xr ef section="7.1.2" sectionFormat="comma" target="RFC7871"/> revealing their exact IP address can thus use the EDNS0 Client Subnet option (<x ref section="7.1.2" sectionFormat="comma" target="RFC7871"/>)
to provide a hint to the resolver using Oblivious DoH.</t> to provide a hint to the resolver using Oblivious DoH.</t>
<t>This mechanism is intended to be used as one mechanism for resolving pr ivacy-sensitive <t>This mechanism is intended to be used as one mechanism for resolving pr ivacy-sensitive
content in the broader context of DNS privacy.</t> content in the broader context of DNS privacy.</t>
<t>This experimental protocol is developed outside the IETF and is publish ed here to <t>This experimental protocol has been developed outside the IETF and is p ublished here to
guide implementation, ensure interoperability among implementations, and enable guide implementation, ensure interoperability among implementations, and enable
wide-scale experimentation. See <xref target="experiment"/> for more details abo ut the experiment.</t> wide-scale experimentation. See <xref target="experiment"/> for more details abo ut the experiment.</t>
<section anchor="specification-of-requirements"> <section anchor="specification-of-requirements">
<name>Specification of Requirements</name> <name>Specification of Requirements</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>SHOULD NOT</bcp14>",
only when, they "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in 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> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>This document defines the following terms:</t> <t>This document defines the following terms:</t>
<dl> <dl>
<dt> <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 Prox
y and Target to use for a given query.</t>
</dd>
<dt>
Oblivious Proxy: </dt> Oblivious Proxy: </dt>
<dd> <dd>
<t>An HTTP server that proxies encrypted DNS queries and responses bet <t>An HTTP server that proxies encrypted DNS queries and responses bet
ween a Client and an ween an Oblivious Client and an
Oblivious Target, and is identified by a URI template <xref target="RFC6570"/> ( Oblivious Target and is identified by a URI Template <xref target="RFC6570"/> (s
see <xref target="oblivious-request"/>). ee <xref target="oblivious-request"/>).
Note that this Oblivious Proxy is not acting as a full HTTP proxy, but is instea Note that this Oblivious Proxy is not acting as a full HTTP proxy but is instead
d a specialized a specialized
server used to forward oblivious DNS messages.</t> server used to forward Oblivious DNS messages.</t>
</dd> </dd>
<dt> <dt>
Oblivious Target: </dt> Oblivious Target: </dt>
<dd> <dd>
<t>An HTTP server that receives and decrypts encrypted Client DNS quer ies from an Oblivious Proxy, <t>An HTTP server that receives and decrypts encrypted Oblivious Clien t DNS queries from an Oblivious Proxy
and returns encrypted DNS responses via that same Proxy. In order to provide DNS responses, the Target 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> can be a DNS resolver, be co-located with a resolver, or forward to a resolver.< /t>
</dd> </dd>
</dl> </dl>
<t>Throughout the rest of this document, we use the terms Proxy and Target <t>Throughout the rest of this document, we use the terms "Client", "Proxy
to refer to an Oblivious ", and "Target" to refer to an Oblivious Client,
Proxy and Oblivious Target, respectively.</t> Oblivious Proxy, and Oblivious Target, respectively.</t>
</section> </section>
<section anchor="deployment-requirements"> <section anchor="deployment-requirements">
<name>Deployment Requirements</name> <name>Deployment Requirements</name>
<t>Oblivious DoH requires, at a minimum:</t> <t>Oblivious DoH requires, at a minimum:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>An Oblivious Proxy server, identified by a URI template.</li> <li>An Oblivious Proxy server, identified by a URI Template.</li>
<li>An Oblivious Target server. The Target and Proxy are expected to be non-colluding (see <li>An Oblivious Target server. The Target and Proxy are expected to be non-colluding (see
<xref target="security-considerations"/>).</li> <xref target="security-considerations"/>).</li>
<li>One or more Target public keys for encrypting DNS queries send to a Target via a Proxy <li>One or more Target public keys for encrypting DNS queries sent to a Target via a Proxy
(<xref target="publickey"/>). These keys guarantee that only the intended Target can decrypt Client queries.</li> (<xref target="publickey"/>). These keys guarantee that only the intended Target can decrypt Client queries.</li>
</ul> </ul>
<t>The mechanism for discovering and provisioning the Proxy URI template a <t>The mechanism for discovering and provisioning the Proxy URI Template a
nd Target public keys nd Target public keys
is out of scope of this document.</t> is out of scope for this document.</t>
</section> </section>
<section anchor="http-exchange"> <section anchor="http-exchange">
<name>HTTP Exchange</name> <name>HTTP Exchange</name>
<t>Unlike direct resolution, oblivious hostname resolution over DoH involv es three parties:</t> <t>Unlike direct resolution, oblivious hostname resolution over DoH involv es three parties:</t>
<ol spacing="normal" type="1"><li>The Client, which generates queries.</li > <ol spacing="normal" type="1"><li>The Client, which generates queries.</li >
<li>The Proxy, which receives encrypted queries from the Client and pass es them on to a Target.</li> <li>The Proxy, which receives encrypted queries from the Client and pass es them on to a Target.</li>
<li>The Target, which receives proxied queries from the Client via the P roxy and produces proxied <li>The Target, which receives proxied queries from the Client via the P roxy and produces proxied
answers.</li> answers.</li>
</ol> </ol>
<figure anchor="fig-doh-exchange"> <figure anchor="fig-doh-exchange">
<name>Obvlivious DoH Exchange</name> <name>Oblivious DoH Exchange</name>
<artwork><![CDATA[ <artwork><![CDATA[
--- [ Request encrypted with Target public key ] --> --- [ Request encrypted with Target public key ] -->
+---------+ +-----------+ +-----------+ +---------+ +-----------+ +-----------+
| Client +-------------> Oblivious +-------------> Oblivious | | Client +-------------> Oblivious +-------------> Oblivious |
| <-------------+ Proxy <-------------+ Target | | <-------------+ Proxy <-------------+ Target |
+---------+ +-----------+ +-----------+ +---------+ +-----------+ +-----------+
<-- [ Response encrypted with symmetric key ] --- <-- [ Response encrypted with symmetric key ] ---
]]></artwork> ]]></artwork>
</figure> </figure>
<section anchor="oblivious-request"> <section anchor="oblivious-request">
<name>HTTP Request</name> <name>HTTP Request</name>
<t>Oblivious DoH queries are created by the Client, and sent to the Prox y as HTTP <t>Oblivious DoH queries are created by the Client and are sent to the P roxy as HTTP
requests using the POST method. Clients are configured with a Proxy URI Template 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 T emplate and <xref target="RFC6570"/> and the Target URI. The scheme for both the Proxy URI T emplate and
the Target URI MUST be "https". The Proxy URI Template uses the Level 3 encoding the Target URI <bcp14>MUST</bcp14> be "https". The Proxy URI Template uses the L
defined in Section 1.2 of <xref target="RFC6570"/>, and contains two variables: evel 3 encoding
"targethost", defined in
which indicates the host name of the Target server; and "targetpath", <xref target="RFC6570" sectionFormat="of" section="1.2"/> and contains two varia
bles: "targethost",
which indicates the hostname of the Target server; and "targetpath",
which indicates the path on which the Target is accessible. Examples of which indicates the path on which the Target is accessible. Examples of
Proxy URI Templates are shown below:</t> Proxy URI Templates are shown below:</t>
<artwork><![CDATA[ <artwork><![CDATA[
https://dnsproxy.example/dns-query{?targethost,targetpath} https://dnsproxy.example/dns-query{?targethost,targetpath}
https://dnsproxy.example/{targethost}/{targetpath} https://dnsproxy.example/{targethost}/{targetpath}
]]></artwork> ]]></artwork>
<t>The URI Template MUST contain both the "targethost" and "targetpath" <t>The URI Template <bcp14>MUST</bcp14> contain both the "targethost" an
variables exactly d "targetpath" variables exactly
once, and MUST NOT contain any other variables. The variables MUST be within the once and <bcp14>MUST NOT</bcp14> contain any other variables. The variables <bcp
path 14>MUST</bcp14> be within the path
or query components of the URI. Clients MUST ignore configurations that do not c or query components of the URI. Clients <bcp14>MUST</bcp14> ignore configuration
onform s that do not conform
to this template. See <xref target="request-example"/> for an example request.</ t> to this template. See <xref target="request-example"/> for an example request.</ t>
<t>Oblivious DoH messages have no cache value since both requests and re <t>Oblivious DoH messages have no cache value, since both requests and r
sponses are esponses are
encrypted using ephemeral key material. Requests and responses MUST NOT be cache encrypted using ephemeral key material. Requests and responses <bcp14>MUST NOT</
d.</t> bcp14> be cached.</t>
<t>Clients MUST set the HTTP Content-Type header to "application/oblivio <t>Clients <bcp14>MUST</bcp14> set the HTTP Content-Type header to "appl
us-dns-message" ication/oblivious-dns-message"
to indicate that this request is an Oblivious DoH query intended for proxying. C lients to indicate that this request is an Oblivious DoH query intended for proxying. C lients
also SHOULD set this same value for the HTTP Accept header.</t> also <bcp14>SHOULD</bcp14> set this same value for the HTTP Accept header.</t>
<t>A correctly encoded request has the HTTP Content-Type header "applica tion/oblivious-dns-message", <t>A correctly encoded request has the HTTP Content-Type header "applica tion/oblivious-dns-message",
uses the HTTP POST method, and contains "targethost" and "targetpath" variables. If the Proxy 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 MUS T treat the fails to match the "targethost" and "targetpath" variables from the path, it <bc p14>MUST</bcp14> treat the
request as malformed. The Proxy constructs the URI of the Target with the "https " scheme, request as malformed. The Proxy constructs the URI of the Target with the "https " scheme,
using the value of "targethost" as the URI host, and the percent-decoded value o using the value of "targethost" as the URI host and the percent-decoded value of
f "targetpath" as the "targetpath" as the
URI path. Proxies MUST check that Client requests are correctly encoded, and MUS URI path. Proxies <bcp14>MUST</bcp14> check that Client requests are correctly e
T return a ncoded and <bcp14>MUST</bcp14> return a
4xx (Client Error) if the check fails, along with the Proxy-Status response head er 4xx (Client Error) if the check fails, along with the Proxy-Status response head er
with an "error" parameter of type "http_request_error" <xref target="I-D.ietf-ht with an "error" parameter of type "http_request_error" <xref target="RFC9209"/>.
tpbis-proxy-status"/>.</t> </t>
<t>Proxies MAY choose to not forward connections to non-standard ports. <t>Proxies <bcp14>MAY</bcp14> choose to not forward connections to non-s
In such cases, Proxies tandard ports. In such cases, Proxies
can indicate the error with a 403 response status code, along with a Proxy-Statu s response can indicate the error with a 403 response status code, along with a Proxy-Statu s response
header with an "error" parameter of type "http_request_denied", along with an ap propriate header with an "error" parameter of type "http_request_denied" and with an appro priate
explanation in "details".</t> explanation in "details".</t>
<t>If the Proxy cannot establish a connection to the Target, it can indi cate the error with a <t>If the Proxy cannot establish a connection to the Target, it can indi cate the error with a
502 response status code, along with a Proxy-Status response header with an "err or" parameter 502 response status code, along with a Proxy-Status response header with an "err or" parameter
whose type indicates the reason. For example, if DNS resolution fails, the error type might be whose type indicates the reason. For example, if DNS resolution fails, the error type might be
"dns_timeout", whereas if the TLS connection failed the error type might be "tls "dns_timeout", whereas if the TLS connection fails, the error type might be "tls
_protocol_error".</t> _protocol_error".</t>
<t>Upon receipt of requests from a Proxy, Targets MUST validate that the <t>Upon receipt of requests from a Proxy, Targets <bcp14>MUST</bcp14> va
request has the HTTP lidate that the request has the HTTP
Content-Type header "application/oblivious-dns-message" and uses the HTTP POST m ethod. Content-Type header "application/oblivious-dns-message" and uses the HTTP POST m ethod.
Targets can respond with a 4xx response status code if this check fails.</t> Targets can respond with a 4xx response status code if this check fails.</t>
</section> </section>
<section anchor="request-example"> <section anchor="request-example">
<name>HTTP Request Example</name> <name>HTTP Request Example</name>
<t>The following example shows how a Client requests that a Proxy, "dnsp roxy.example", <t>The following example shows how a Client requests that a Proxy, "dnsp roxy.example",
forwards an encrypted message to "dnstarget.example". The URI Template for the forward an encrypted message to "dnstarget.example". The URI Template for the
Proxy is "https://dnsproxy.example/dns-query{?targethost,targetpath}". The URI f or Proxy is "https://dnsproxy.example/dns-query{?targethost,targetpath}". The URI f or
the Target is "https://dnstarget.example/dns-query".</t> the Target is "https://dnstarget.example/dns-query".</t>
<artwork><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
:method = POST :method = POST
:scheme = https :scheme = https
:authority = dnsproxy.example :authority = dnsproxy.example
:path = /dns-query?targethost=dnstarget.example&targetpath=/dns-query :path = /dns-query?targethost=dnstarget.example&targetpath=/dns-query
accept = application/oblivious-dns-message accept = application/oblivious-dns-message
content-type = application/oblivious-dns-message content-type = application/oblivious-dns-message
content-length = 106 content-length = 106
<Bytes containing an encrypted Oblivious DNS query> <Bytes containing an encrypted Oblivious DNS query>
]]></artwork> ]]></sourcecode>
<t>The Proxy then sends the following request on to the Target:</t> <t>The Proxy then sends the following request on to the Target:</t>
<artwork><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
:method = POST :method = POST
:scheme = https :scheme = https
:authority = dnstarget.example :authority = dnstarget.example
:path = /dns-query :path = /dns-query
accept = application/oblivious-dns-message accept = application/oblivious-dns-message
content-type = application/oblivious-dns-message content-type = application/oblivious-dns-message
content-length = 106 content-length = 106
<Bytes containing an encrypted Oblivious DNS query> <Bytes containing an encrypted Oblivious DNS query>
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="oblivious-response"> <section anchor="oblivious-response">
<name>HTTP Response</name> <name>HTTP Response</name>
<t>The response to an Oblivious DoH query is generated by the Target. It MUST set the <t>The response to an Oblivious DoH query is generated by the Target. It <bcp14>MUST</bcp14> set the
Content-Type HTTP header to "application/oblivious-dns-message" for all successf ul responses. Content-Type HTTP header to "application/oblivious-dns-message" for all successf ul responses.
The body of the response contains an encrypted DNS message; see <xref target="en cryption"/>.</t> The body of the response contains an encrypted DNS message; see <xref target="en cryption"/>.</t>
<t>The response from a Target MUST set the Content-Type HTTP header to " <t>The response from a Target <bcp14>MUST</bcp14> set the Content-Type H
application/oblivious-dns-message" which TTP header to "application/oblivious-dns-message", and that same type
MUST be forwarded by the Proxy to the Client. A Client MUST only consider a resp <bcp14>MUST</bcp14> be used on all successful responses sent by the Proxy to the
onse which contains the Client. A Client <bcp14>MUST</bcp14> only consider a response that contains the
Content-Type header in the response before processing the payload. A response wi Content-Type header before processing the payload. A response without the approp
thout the appropriate header MUST be riate header <bcp14>MUST</bcp14> be
treated as an error and be handled appropriately. All other aspects of the HTTP response and error handling are treated as an error and be handled appropriately. All other aspects of the HTTP response and error handling are
inherited from standard DoH.</t> inherited from standard DoH.</t>
<t>Proxies forward responses from the Target to client, without any modi <t>Proxies forward responses from the Target to the Client, without any
fications to the body or status code. modifications to the body or status code.
The Proxy also SHOULD add a Proxy-Status response header with an "received-statu The Proxy also <bcp14>SHOULD</bcp14> add a Proxy-Status response header with a "
s" parameter indicating received-status" parameter indicating
that the status code was generated by the Target.</t> that the status code was generated by the Target.</t>
<t>Note that if a Client receives a 3xx status code and chooses to follo w a redirect, the subsequent request <t>Note that if a Client receives a 3xx status code and chooses to follo w a redirect, the subsequent request
MUST also be performed through a Proxy in order to avoid directly exposing reque sts to the Target.</t> <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 <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 4 and Client keys do not match, it is an authorization failure (HTTP status code 4
01; see Section 3.1 01; see <xref target="RFC7235" sectionFormat="of" section="3.1"/>). Otherwise, i
of <xref target="RFC7235"/>). Otherwise, if the Client's request is invalid, suc f the Client's request is invalid, such as in the case of decryption
h as in the case of decryption failure, wrong message type, or deserialization failure, this is a bad request (
failure, wrong message type, or deserialization failure, this is a bad request ( HTTP status code 400; see <xref target="RFC7231" sectionFormat="of" section="6.5
HTTP status code 400; .1"/>).</t>
see Section 6.5.1 of <xref target="RFC7231"/>).</t> <t>Even in the case of DNS responses indicating failure, such as SERVFAI
<t>Even in case of DNS responses indicating failure, such as SERVFAIL or L or NXDOMAIN, a successful HTTP response
NXDOMAIN, a successful HTTP response
with a 2xx status code is used as long as the DNS response is valid. This is ide ntical to how DoH <xref target="RFC8484"/> with a 2xx status code is used as long as the DNS response is valid. This is ide ntical to how DoH <xref target="RFC8484"/>
handles HTTP response codes.</t> handles HTTP response codes.</t>
</section> </section>
<section anchor="http-response-example"> <section anchor="http-response-example">
<name>HTTP Response Example</name> <name>HTTP Response Example</name>
<t>The following example shows a 2xx (Successful) response that can be s ent from a Target to <t>The following example shows a 2xx (Successful) response that can be s ent from a Target to
a Client via a Proxy.</t> a Client via a Proxy.</t>
<artwork><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
:status = 200 :status = 200
content-type = application/oblivious-dns-message content-type = application/oblivious-dns-message
content-length = 154 content-length = 154
<Bytes containing an encrypted Oblivious DNS response> <Bytes containing an encrypted Oblivious DNS response>
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="http-metadata"> <section anchor="http-metadata">
<name>HTTP Metadata</name> <name>HTTP Metadata</name>
<t>Proxies forward requests and responses between Clients and Targets as specified in <xref target="oblivious-request"/>. <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. Metadata sent with these messages could inadvertently weaken or remove Oblivious DoH privacy properties.
Proxies MUST NOT send any Client-identifying information about Clients to Target Proxies <bcp14>MUST NOT</bcp14> send any Client-identifying information about Cl
s, such as ients to Targets, such as
"Forwarded" HTTP headers <xref target="RFC7239"/>. Additionally, Clients MUST NO "Forwarded" HTTP headers <xref target="RFC7239"/>. Additionally, Clients <bcp14>
T include any private state in MUST NOT</bcp14> include any private state in
requests to Proxies, such as HTTP cookies. See <xref target="authentication"/> f or related discussion about requests to Proxies, such as HTTP cookies. See <xref target="authentication"/> f or related discussion about
Client authentication information.</t> Client authentication information.</t>
</section> </section>
</section> </section>
<section anchor="publickey"> <section anchor="publickey">
<name>Configuration and Public Key Format</name> <name>Configuration and Public Key Format</name>
<t>In order send a message to a Target, the Client needs to know a public key to use <t>In order to send a message to a Target, the Client needs to know a publ ic key to use
for encrypting its queries. The mechanism for discovering this configuration is for encrypting its queries. The mechanism for discovering this configuration is
out of scope of this document.</t> out of scope for this document.</t>
<t>Servers ought to rotate public keys regularly. It is RECOMMENDED that s <t>Servers ought to rotate public keys regularly. It is <bcp14>RECOMMENDED
ervers rotate keys </bcp14> that servers rotate keys
every day. Shorter rotation windows reduce the anonymity set of Clients that mig ht use every day. Shorter rotation windows reduce the anonymity set of Clients that mig ht use
the public key, whereas longer rotation windows widen the timeframe of possible compromise.</t> the public key, whereas longer rotation windows widen the time frame of possible compromise.</t>
<t>An Oblivious DNS public key configuration is a structure encoded, using TLS-style <t>An Oblivious DNS public key configuration is a structure encoded, using TLS-style
encoding <xref target="RFC8446"/>, as follows:</t> encoding <xref target="RFC8446"/>, as follows:</t>
<artwork><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
struct { struct {
uint16 kem_id; uint16 kem_id;
uint16 kdf_id; uint16 kdf_id;
uint16 aead_id; uint16 aead_id;
opaque public_key<1..2^16-1>; opaque public_key<1..2^16-1>;
} ObliviousDoHConfigContents; } ObliviousDoHConfigContents;
struct { struct {
uint16 version; uint16 version;
uint16 length; uint16 length;
select (ObliviousDoHConfig.version) { select (ObliviousDoHConfig.version) {
case 0x0001: ObliviousDoHConfigContents contents; case 0x0001: ObliviousDoHConfigContents contents;
} }
} ObliviousDoHConfig; } ObliviousDoHConfig;
ObliviousDoHConfig ObliviousDoHConfigs<1..2^16-1>; ObliviousDoHConfig ObliviousDoHConfigs<1..2^16-1>;
]]></artwork> ]]></sourcecode>
<t>The <tt>ObliviousDoHConfigs</tt> structure contains one or more <tt>Obl iviousDoHConfig</tt> structures in decreasing order of <t>The <tt>ObliviousDoHConfigs</tt> structure contains one or more <tt>Obl iviousDoHConfig</tt> structures in decreasing order of
preference. This allows a server to support multiple versions of Oblivious DoH a nd multiple sets of Oblivious DoH preference. This allows a server to support multiple versions of Oblivious DoH a nd multiple sets of Oblivious DoH
parameters.</t> parameters.</t>
<t>An <tt>ObliviousDoHConfig</tt> contains a versioned representation of a n Oblivious DoH configuration, <t>An <tt>ObliviousDoHConfig</tt> structure contains a versioned represent ation of an Oblivious DoH configuration,
with the following fields.</t> with the following fields.</t>
<dl> <dl>
<dt> <dt>
version </dt> version: </dt>
<dd> <dd>
<t>The version of Oblivious DoH for which this configuration is used. Clients MUST ignore any <t>The version of Oblivious DoH for which this configuration is used. Clients <bcp14>MUST</bcp14> ignore any
<tt>ObliviousDoHConfig</tt> structure with a version they do not support. The ve rsion of Oblivious DoH <tt>ObliviousDoHConfig</tt> structure with a version they do not support. The ve rsion of Oblivious DoH
specified in this document is <tt>0x0001</tt>.</t> specified in this document is <tt>0x0001</tt>.</t>
</dd> </dd>
<dt> <dt>
length </dt> length: </dt>
<dd> <dd>
<t>The length, in bytes, of the next field.</t> <t>The length, in bytes, of the next field.</t>
</dd> </dd>
<dt> <dt>
contents </dt> contents: </dt>
<dd> <dd>
<t>An opaque byte string whose contents depend on the version. For thi s <t>An opaque byte string whose contents depend on the version. For thi s
specification, the contents are an <tt>ObliviousDoHConfigContents</tt> structure .</t> specification, the contents are an <tt>ObliviousDoHConfigContents</tt> structure .</t>
</dd> </dd>
</dl> </dl>
<t>An <tt>ObliviousDoHConfigContents</tt> contains the information needed to encrypt a message under <t>An <tt>ObliviousDoHConfigContents</tt> structure contains the informati on needed to encrypt a message under
<tt>ObliviousDoHConfigContents.public_key</tt> such that only the owner of the c orresponding private <tt>ObliviousDoHConfigContents.public_key</tt> such that only the owner of the c orresponding private
key can decrypt the message. The values for <tt>ObliviousDoHConfigContents.kem_i d</tt>, key can decrypt the message. The values for <tt>ObliviousDoHConfigContents.kem_i d</tt>,
<tt>ObliviousDoHConfigContents.kdf_id</tt>, and <tt>ObliviousDoHConfigContents.a ead_id</tt> <tt>ObliviousDoHConfigContents.kdf_id</tt>, and <tt>ObliviousDoHConfigContents.a ead_id</tt>
are described in Section 7 of <xref target="HPKE"/>. The fields in this structur e are described in <xref target="RFC9180" sectionFormat="of" section="7"/>. The fi elds in this structure
are as follows:</t> are as follows:</t>
<dl> <dl>
<dt> <dt>
kem_id </dt> kem_id: </dt>
<dd> <dd>
<t>The HPKE KEM identifier corresponding to <tt>public_key</tt>. Clien ts MUST ignore any <t>The hybrid public key encryption (HPKE) key encapsulation mechanism (KEM) identifier corresponding to <tt>public_key</tt>. Clients <bcp14>MUST</bcp 14> ignore any
<tt>ObliviousDoHConfig</tt> structure with a key using a KEM they do not support .</t> <tt>ObliviousDoHConfig</tt> structure with a key using a KEM they do not support .</t>
</dd> </dd>
<dt> <dt>
kdf_id </dt> kdf_id: </dt>
<dd> <dd>
<t>The HPKE KDF identifier corresponding to <tt>public_key</tt>. Clien ts MUST ignore any <t>The HPKE key derivation function (KDF) identifier corresponding to <tt>public_key</tt>. Clients <bcp14>MUST</bcp14> ignore any
<tt>ObliviousDoHConfig</tt> structure with a key using a KDF they do not support .</t> <tt>ObliviousDoHConfig</tt> structure with a key using a KDF they do not support .</t>
</dd> </dd>
<dt> <dt>
aead_id </dt> aead_id: </dt>
<dd> <dd>
<t>The HPKE AEAD identifier corresponding to <tt>public_key</tt>. Clie nts MUST ignore any <t>The HPKE authenticated encryption with associated data (AEAD) ident ifier corresponding to <tt>public_key</tt>. Clients <bcp14>MUST</bcp14> ignore a ny
<tt>ObliviousDoHConfig</tt> structure with a key using an AEAD they do not suppo rt.</t> <tt>ObliviousDoHConfig</tt> structure with a key using an AEAD they do not suppo rt.</t>
</dd> </dd>
<dt> <dt>
public_key </dt> public_key: </dt>
<dd> <dd>
<t>The HPKE public key used by the Client to encrypt Oblivious DoH que ries.</t> <t>The HPKE public key used by the Client to encrypt Oblivious DoH que ries.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="encryption"> <section anchor="encryption">
<name>Protocol Encoding</name> <name>Protocol Encoding</name>
<t>This section includes encoding and wire format details for Oblivious Do H, as well <t>This section includes encoding and wire format details for Oblivious Do H, as well
as routines for encrypting and decrypting encoded values.</t> as routines for encrypting and decrypting encoded values.</t>
<section anchor="encoding"> <section anchor="encoding">
<name>Message Format</name> <name>Message Format</name>
<t>There are two types of Oblivious DoH messages: Queries (0x01) and Res ponses (0x02). <t>There are two types of Oblivious DoH messages: Queries (0x01) and Res ponses (0x02).
Both messages carry the following information:</t> 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> <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 which MUST contain all zeros.</li> <li>Padding of arbitrary length, which <bcp14>MUST</bcp14> contain all zeros.</li>
</ol> </ol>
<t>They are encoded using the following structure:</t> <t>They are encoded using the following structure:</t>
<artwork><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
struct { struct {
opaque dns_message<1..2^16-1>; opaque dns_message<1..2^16-1>;
opaque padding<0..2^16-1>; opaque padding<0..2^16-1>;
} ObliviousDoHMessagePlaintext; } ObliviousDoHMessagePlaintext;
]]></artwork> ]]></sourcecode>
<t>Both Query and Response messages use the <tt>ObliviousDoHMessagePlain text</tt> format.</t> <t>Both Query and Response messages use the <tt>ObliviousDoHMessagePlain text</tt> format.</t>
<artwork><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
ObliviousDoHMessagePlaintext ObliviousDoHQuery; ObliviousDoHMessagePlaintext ObliviousDoHQuery;
ObliviousDoHMessagePlaintext ObliviousDoHResponse; ObliviousDoHMessagePlaintext ObliviousDoHResponse;
]]></artwork> ]]></sourcecode>
<t>An encrypted <tt>ObliviousDoHMessagePlaintext</tt> is carried in a <t <t>An encrypted <tt>ObliviousDoHMessagePlaintext</tt> parameter is carri
t>ObliviousDoHMessage</tt> ed in an <tt>ObliviousDoHMessage</tt>
message, encoded as follows:</t> message, encoded as follows:</t>
<artwork><![CDATA[ <sourcecode name="" type="tls-presentation"><![CDATA[
struct { struct {
uint8 message_type; uint8 message_type;
opaque key_id<0..2^16-1>; opaque key_id<0..2^16-1>;
opaque encrypted_message<1..2^16-1>; opaque encrypted_message<1..2^16-1>;
} ObliviousDoHMessage; } ObliviousDoHMessage;
]]></artwork> ]]></sourcecode>
<t>The <tt>ObliviousDoHMessage</tt> structure contains the following fie lds:</t> <t>The <tt>ObliviousDoHMessage</tt> structure contains the following fie lds:</t>
<dl> <dl>
<dt> <dt>
message_type </dt> message_type: </dt>
<dd> <dd>
<t>A one-byte identifier for the type of message. Query messages use <tt>message_type</tt> 0x01, and Response <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> messages use <tt>message_type</tt> 0x02.</t>
</dd> </dd>
<dt> <dt>
key_id </dt> key_id: </dt>
<dd> <dd>
<t>The identifier of the corresponding <tt>ObliviousDoHConfigContent s</tt> key. This is computed as <t>The identifier of the corresponding <tt>ObliviousDoHConfigContent s</tt> key. This is computed as
<tt>Expand(Extract("", config), "odoh key id", Nh)</tt>, where <tt>config</tt> i s the ObliviousDoHConfigContents structure <tt>Expand(Extract("", config), "odoh key id", Nh)</tt>, where <tt>config</tt> i s the <tt>ObliviousDoHConfigContents</tt> structure
and <tt>Extract</tt>, <tt>Expand</tt>, and <tt>Nh</tt> are as specified by the H PKE cipher suite KDF corresponding to and <tt>Extract</tt>, <tt>Expand</tt>, and <tt>Nh</tt> are as specified by the H PKE cipher suite KDF corresponding to
<tt>config.kdf_id</tt>.</t> <tt>config.kdf_id</tt>.</t>
</dd> </dd>
<dt> <dt>
encrypted_message </dt> encrypted_message: </dt>
<dd> <dd>
<t>An encrypted message for the Oblivious Target (for Query messages ) or Client (for Response messages). <t>An encrypted message for the Oblivious Target (for Query messages ) or Client (for Response messages).
Implementations MAY enforce limits on the size of this field depending on the si ze of plaintext DNS Implementations <bcp14>MAY</bcp14> enforce limits on the size of this field, dep ending on the size of plaintext DNS
messages. (DNS queries, for example, will not reach the size limit of 2^16-1 in practice.)</t> messages. (DNS queries, for example, will not reach the size limit of 2^16-1 in practice.)</t>
</dd> </dd>
</dl> </dl>
<t>The contents of <tt>ObliviousDoHMessage.encrypted_message</tt> depend on <tt>ObliviousDoHMessage.message_type</tt>. <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 o In particular, <tt>ObliviousDoHMessage.encrypted_message</tt> is an encryption o
f a <tt>ObliviousDoHQuery</tt> f an <tt>ObliviousDoHQuery</tt> message
if the message is a Query, and <tt>ObliviousDoHResponse</tt> if the message is a if the message is a Query and an encryption of <tt>ObliviousDoHResponse</tt> if
Response.</t> the message is a Response.</t>
</section> </section>
<section anchor="encryption-and-decryption-routines"> <section anchor="encryption-and-decryption-routines">
<name>Encryption and Decryption Routines</name> <name>Encryption and Decryption Routines</name>
<t>Clients use the following utility functions for encrypting a Query an d decrypting <t>Clients use the following utility functions for encrypting a Query an d decrypting
a Response as described in <xref target="odoh-client"/>.</t> a Response as described in <xref target="odoh-Client"/>.</t>
<t>encrypt_query_body: Encrypt an Oblivious DoH query.</t> <ul spacing="normal">
<artwork><![CDATA[ <li>encrypt_query_body: Encrypt an Oblivious DoH query.</li>
</ul>
<sourcecode name="" type="pseudocode"><![CDATA[
def encrypt_query_body(pkR, key_id, Q_plain): def encrypt_query_body(pkR, key_id, Q_plain):
enc, context = SetupBaseS(pkR, "odoh query") enc, context = SetupBaseS(pkR, "odoh query")
aad = 0x01 || len(key_id) || key_id aad = 0x01 || len(key_id) || key_id
ct = context.Seal(aad, Q_plain) ct = context.Seal(aad, Q_plain)
Q_encrypted = enc || ct Q_encrypted = enc || ct
return Q_encrypted return Q_encrypted
]]></artwork> ]]></sourcecode>
<t>decrypt_response_body: Decrypt an Oblivious DoH response.</t> <ul spacing="normal">
<artwork><![CDATA[ <li>decrypt_response_body: Decrypt an Oblivious DoH response.</li>
</ul>
<sourcecode name="" type="pseudocode"><![CDATA[
def decrypt_response_body(context, Q_plain, R_encrypted, resp_nonce): def decrypt_response_body(context, Q_plain, R_encrypted, resp_nonce):
aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce) aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce)
aad = 0x02 || len(resp_nonce) || resp_nonce aad = 0x02 || len(resp_nonce) || resp_nonce
R_plain, error = Open(key, nonce, aad, R_encrypted) R_plain, error = Open(key, nonce, aad, R_encrypted)
return R_plain, error return R_plain, error
]]></artwork> ]]></sourcecode>
<t>The <tt>derive_secrets</tt> function is described below.</t> <t>The <tt>derive_secrets</tt> function is described below.</t>
<t>Targets use the following utility functions in processing queries and producing <t>Targets use the following utility functions in processing queries and producing
responses as described in <xref target="odoh-target"/>.</t> responses as described in <xref target="odoh-target"/>.</t>
<t>setup_query_context: Set up an HPKE context used for decrypting an Ob <ul spacing="normal">
livious DoH query.</t> <li>setup_query_context: Set up an HPKE context used for decrypting an O
<artwork><![CDATA[ blivious DoH query.</li>
</ul>
<sourcecode name="" type="pseudocode"><![CDATA[
def setup_query_context(skR, key_id, Q_encrypted): def setup_query_context(skR, key_id, Q_encrypted):
enc || ct = Q_encrypted enc || ct = Q_encrypted
context = SetupBaseR(enc, skR, "odoh query") context = SetupBaseR(enc, skR, "odoh query")
return context return context
]]></artwork> ]]></sourcecode>
<t>decrypt_query_body: Decrypt an Oblivious DoH query.</t> <ul spacing="normal">
<artwork><![CDATA[ <li>decrypt_query_body: Decrypt an Oblivious DoH query.</li>
</ul>
<sourcecode name="" type="pseudocode"><![CDATA[
def decrypt_query_body(context, key_id, Q_encrypted): def decrypt_query_body(context, key_id, Q_encrypted):
aad = 0x01 || len(key_id) || key_id aad = 0x01 || len(key_id) || key_id
enc || ct = Q_encrypted enc || ct = Q_encrypted
Q_plain, error = context.Open(aad, ct) Q_plain, error = context.Open(aad, ct)
return Q_plain, error return Q_plain, error
]]></artwork> ]]></sourcecode>
<t>derive_secrets: Derive keying material used for encrypting an Oblivio <ul spacing="normal">
us DoH response.</t> <li>derive_secrets: Derive keying material used for encrypting an Oblivi
<artwork><![CDATA[ ous DoH response.</li>
</ul>
<sourcecode name="" type="pseudocode"><![CDATA[
def derive_secrets(context, Q_plain, resp_nonce): def derive_secrets(context, Q_plain, resp_nonce):
secret = context.Export("odoh response", Nk) secret = context.Export("odoh response", Nk)
salt = Q_plain || len(resp_nonce) || resp_nonce salt = Q_plain || len(resp_nonce) || resp_nonce
prk = Extract(salt, secret) prk = Extract(salt, secret)
key = Expand(odoh_prk, "odoh key", Nk) key = Expand(odoh_prk, "odoh key", Nk)
nonce = Expand(odoh_prk, "odoh nonce", Nn) nonce = Expand(odoh_prk, "odoh nonce", Nn)
return key, nonce return key, nonce
]]></artwork> ]]></sourcecode>
<t>The <tt>random(N)</tt> function returns <tt>N</tt> cryptographically secure random bytes <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> f unction returns from a good source of entropy <xref target="RFC4086"/>. The <tt>max(A, B)</tt> f unction returns
<tt>A</tt> if <tt>A &gt; B</tt>, and <tt>B</tt> otherwise.</t> <tt>A</tt> if <tt>A &gt; B</tt>, and <tt>B</tt> otherwise.</t>
<t>encrypt_response_body: Encrypt an Oblivious DoH response.</t> <ul spacing="normal">
<artwork><![CDATA[ <li>encrypt_response_body: Encrypt an Oblivious DoH response.</li>
</ul>
<sourcecode name="" type="pseudocode"><![CDATA[
def encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce): def encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce):
aad = 0x02 || len(resp_nonce) || resp_nonce aad = 0x02 || len(resp_nonce) || resp_nonce
R_encrypted = Seal(aead_key, aead_nonce, aad, R_plain) R_encrypted = Seal(aead_key, aead_nonce, aad, R_plain)
return R_encrypted return R_encrypted
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="odoh-client"> <section anchor="odoh-Client">
<name>Oblivious Client Behavior</name> <name>Oblivious Client Behavior</name>
<t>Let <tt>M</tt> be a DNS message (query) a Client wishes to protect with Oblivious DoH. <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 Tar get with When sending an Oblivious DoH Query for resolving <tt>M</tt> to an Oblivious Tar get with
<tt>ObliviousDoHConfigContents</tt> <tt>config</tt>, a Client does the following :</t> <tt>ObliviousDoHConfigContents</tt> <tt>config</tt>, a Client does the following :</t>
<ol spacing="normal" type="1"><li>Create an <tt>ObliviousDoHQuery</tt> str <ol spacing="normal" type="1"><li>Creates an <tt>ObliviousDoHQuery</tt> st
ucture, carrying the message M and padding, to produce Q_plain.</li> ructure, carrying the message M and padding, to produce Q_plain.</li>
<li>Deserialize <tt>config.public_key</tt> to produce a public key pkR o <li>Deserializes <tt>config.public_key</tt> to produce a public key pkR
f type <tt>config.kem_id</tt>.</li> of type <tt>config.kem_id</tt>.</li>
<li>Compute the encrypted message as <tt>Q_encrypted = encrypt_query_bod <li>Computes the encrypted message as <tt>Q_encrypted = encrypt_query_bo
y(pkR, key_id, Q_plain)</tt>, dy(pkR, key_id, Q_plain)</tt>,
where <tt>key_id</tt> is as computed in <xref target="encryption"/>. Note also t hat <tt>len(key_id)</tt> outputs the length of <tt>key_id</tt> where <tt>key_id</tt> is as computed in <xref target="encryption"/>. Note also t hat <tt>len(key_id)</tt> outputs the length of <tt>key_id</tt>
as a two-byte unsigned integer.</li> as a two-byte unsigned integer.</li>
<li>Output an ObliviousDoHMessage message <tt>Q</tt> where <tt>Q.message _type = 0x01</tt>, <tt>Q.key_id</tt> carries <tt>key_id</tt>, <li>Outputs an <tt>ObliviousDoHMessage</tt> message <tt>Q</tt>, where <t t>Q.message_type = 0x01</tt>, <tt>Q.key_id</tt> carries <tt>key_id</tt>,
and <tt>Q.encrypted_message = Q_encrypted</tt>.</li> and <tt>Q.encrypted_message = Q_encrypted</tt>.</li>
</ol> </ol>
<t>The Client then sends <tt>Q</tt> to the Proxy according to <xref target ="oblivious-request"/>. <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"/>, 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 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 validate <tt>R_plain.padding</tt> (as all zeros) a nonce) and produce R_plain. Clients <bcp14>MUST</bcp14> validate <tt>R_plain.p adding</tt> (as all zeros)
before using <tt>R_plain.dns_message</tt>.</t> before using <tt>R_plain.dns_message</tt>.</t>
</section> </section>
<section anchor="odoh-target"> <section anchor="odoh-target">
<name>Oblivious Target Behavior</name> <name>Oblivious Target Behavior</name>
<t>Targets that receive a Query message Q decrypt and process it as follow s:</t> <t>Targets that receive a Query message Q decrypt and process it as follow s:</t>
<ol spacing="normal" type="1"><li>Look up the <tt>ObliviousDoHConfigConten <ol spacing="normal" type="1"><li>Look up the <tt>ObliviousDoHConfigConten
ts</tt> according to <tt>Q.key_id</tt>. If no such key exists, ts</tt> information according to <tt>Q.key_id</tt>. If no such key exists,
the Target MAY discard the query, and if so, it MUST return a 401 (Unauthorized) the Target <bcp14>MAY</bcp14> discard the query, and if so, it <bcp14>MUST</bcp1
response 4> return a 401 (Unauthorized) response
to the Proxy. Otherwise, let <tt>skR</tt> be the private key corresponding to th is public key, to the Proxy. Otherwise, let <tt>skR</tt> be the private key corresponding to th is public key,
or one chosen for trial decryption.</li> 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>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>Compute <tt>Q_plain, error = decrypt_query_body(context, Q.key_id, Q .encrypted_message)</tt>.</li>
<li>If no error was returned, and <tt>Q_plain.padding</tt> is valid (all zeros), resolve <li>If no error was 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 <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> 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, <li>Create an <tt>ObliviousDoHResponseBody</tt> structure, carrying the message <tt>M</tt> and padding,
to produce <tt>R_plain</tt>.</li> to produce <tt>R_plain</tt>.</li>
<li>Create a fresh nonce <tt>resp_nonce = random(max(Nn, Nk))</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>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, a ead_nonce, resp_nonce)</tt>. <li>Compute <tt>R_encrypted = encrypt_response_body(R_plain, aead_key, a ead_nonce, resp_nonce)</tt>.
The <tt>key_id</tt> field used for encryption carries <tt>resp_nonce</tt> in ord er for Clients to The <tt>key_id</tt> field used for encryption carries <tt>resp_nonce</tt> in ord er for Clients to
derive the same secrets. Also, the <tt>Seal</tt> function is that which is assoc iated with the derive the same secrets. Also, the <tt>Seal</tt> function is the function that i s associated with the
HPKE AEAD.</li> HPKE AEAD.</li>
<li>Output an <tt>ObliviousDoHMessage</tt> message <tt>R</tt> where <tt> R.message_type = 0x02</tt>, <li>Output an <tt>ObliviousDoHMessage</tt> message <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> <tt>R.key_id = resp_nonce</tt>, and <tt>R.encrypted_message = R_encrypted</tt>.< /li>
</ol> </ol>
<t>The Target then sends <tt>R</tt> in a 2xx (Successful) response to the Proxy; see <xref target="oblivious-response"/>. <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 Clien t as the HTTP response The Proxy forwards the message <tt>R</tt> without modification back to the Clien t as the HTTP response
to the Client's original HTTP request. In the event of an error (non 2xx status code), the to the Client's original HTTP request. In the event of an error (non-2xx status code), the
Proxy forwards the Target error to the Client; see <xref target="oblivious-respo nse"/>.</t> Proxy forwards the Target error to the Client; see <xref target="oblivious-respo nse"/>.</t>
</section> </section>
<section anchor="compliance"> <section anchor="compliance">
<name>Compliance Requirements</name> <name>Compliance Requirements</name>
<t>Oblivious DoH uses HPKE for public key encryption <xref target="HPKE"/> . <t>Oblivious DoH uses HPKE for public key encryption <xref target="RFC9180 "/>.
In the absence of an application profile standard specifying otherwise, a compli ant In the absence of an application profile standard specifying otherwise, a compli ant
Oblivious DoH implementation MUST support the following HPKE cipher suite:</t> Oblivious DoH implementation <bcp14>MUST</bcp14> support the following HPKE ciph
<ul spacing="normal"> er suite:</t>
<li>KEM: DHKEM(X25519, HKDF-SHA256) (see <xref target="HPKE"/>, Section <dl spacing="normal">
7.1)</li> <dt>KEM:</dt><dd>DHKEM(X25519, HKDF-SHA256) (see <xref target="RFC9180"
<li>KDF: HKDF-SHA256 (see <xref target="HPKE"/>, Section 7.2)</li> sectionFormat="comma" section="7.1"/>)</dd>
<li>AEAD: AES-128-GCM (see <xref target="HPKE"/>, Section 7.3)</li> <dt>KDF:</dt><dd>HKDF-SHA256 (see <xref target="RFC9180" sectionFormat="
</ul> comma" section="7.2"/>)</dd>
<dt>AEAD:</dt><dd>AES-128-GCM (see <xref target="RFC9180" sectionFormat=
"comma" section="7.3"/>)</dd>
</dl>
</section> </section>
<section anchor="experiment"> <section anchor="experiment">
<name>Experiment Overview</name> <name>Experiment Overview</name>
<t>This document describes an experimental protocol built on DoH. The purp ose of this <t>This document describes an experimental protocol built on DoH. The purp ose of this
experiment is to assess deployment configuration viability and related performan ce experiment is to assess deployment configuration viability and related performan ce
impacts on DNS resolution by measuring key performance indicators such as resolu tion impacts on DNS resolution by measuring key performance indicators such as resolu tion
latency. Experiment participants will test various parameters affecting service operation latency. Experiment participants will test various parameters affecting service operation
and performance, including mechanisms for discovery and configuration of DoH Pro xies and performance, including mechanisms for discovery and configuration of DoH Pro xies
and Targets, as well as performance implications of connection reuse and pools w here and Targets, as well as performance implications of connection reuse and pools w here
appropriate. The results of this experiment will be used to influence future pro tocol appropriate. The results of this experiment will be used to influence future pro tocol
design and deployment efforts related to Oblivious DoH, such as Oblivious HTTP design and deployment efforts related to Oblivious DoH, such as Oblivious HTTP
<xref target="OHTP"/>. Implementations of DoH that are not involved in the <xref target="I-D.ietf-ohai-ohttp"/>. Implementations of DoH that are not involv ed in the
experiment will not recognize this protocol and will not participate in the expe riment. experiment will not recognize this protocol and will not participate in the expe riment.
It is anticipated that use of Oblivious DoH and the duration of this experiment to be widespread.</t> It is anticipated that the use of Oblivious DoH will be widespread and that this experiment will be of long duration.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Oblivious DoH aims to keep knowledge of the true query origin and its c ontents known only to Clients. <t>Oblivious DoH aims to keep knowledge of the true query origin and its c ontents known only to Clients.
As a simplified model, consider a case where there exists two Clients C1 and C2, As a simplified model, consider a case where there exist two Clients C1 and C2,
one proxy P, and one Proxy P, and
one Target T. Oblivious DoH assumes an extended Dolev-Yao style attacker which c one Target T. Oblivious DoH assumes an extended Dolev-Yao style attacker <xref t
an observe all arget="Dolev-Yao"/> that can observe all
network activity and can adaptively compromise either P or T, but not C1 or C2. Note that compromising 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. O nce compromised, both P and T is equivalent to collusion between these two parties in practice. O nce compromised,
the attacker has access to all session information and private key material. (Th is generalizes to the attacker has access to all session information and private key material. (Th is generalizes to
arbitrarily many Clients, Proxies, and Targets, with the constraints that not al arbitrarily many Clients, Proxies, and Targets, with the constraints that (1)&nb
l Targets and Proxies sp;not all Targets and Proxies
are simultaneously compromised, and at least two Clients are left uncompromised. are simultaneously compromised and (2)&nbsp;at least two Clients are left uncomp
) The attacker is romised.) The attacker is
prohibited from sending Client identifying information, such as IP addresses, to prohibited from sending Client-identifying information, such as IP addresses, to
Targets. (This would Targets. (This would
allow the attacker to trivially link a query to the corresponding Client.)</t> 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, <t>In this model, both C1 and C2 send Oblivious DoH queries Q1 and Q2, res pectively, through P to T,
and T provides answers A1 and A2. The attacker aims to link C1 to (Q1, A1) and C 2 to (Q2, A2), respectively. and T provides answers A1 and A2. The attacker aims to link C1 to (Q1, A1) and C 2 to (Q2, A2), respectively.
The attacker succeeds if this linkability is possible without any additional int eraction. (For example, The attacker succeeds if this linkability is possible without any additional int eraction. (For example,
if T is compromised, it could return a DNS answer corresponding to an entity it controls, and then observe if T is compromised, it could return a DNS answer corresponding to an entity it controls and then observe
the subsequent connection from a Client, learning its identity in the process. S uch attacks are out of the subsequent connection from a Client, learning its identity in the process. S uch attacks are out of
scope for this model.)</t> scope for this model.)</t>
<t>Oblivious DoH security prevents such linkability. Informally, this mean s:</t> <t>Oblivious DoH security prevents such linkability. Informally, this mean s:</t>
<ol spacing="normal" type="1"><li>Queries and answers are known only to Cl ients and Targets in possession of the corresponding <ol spacing="normal" type="1"><li>Queries and answers are known only to Cl ients and Targets in possession of the corresponding
response key and HPKE keying material. In particular, Proxies know the origin an d destination response key and HPKE keying material. In particular, Proxies know the origin an d destination
of an oblivious query, yet do not know the plaintext query. Likewise, Targets kn ow only the oblivious of an oblivious query, yet do not know the plaintext query. Likewise, Targets kn ow only the oblivious
query origin, i.e., the Proxy, and the plaintext query. Only the Client knows bo th the plaintext query origin, i.e., the Proxy, and the plaintext query. Only the Client knows bo th the plaintext
query contents and destination.</li> query contents and destination.</li>
<li>Target resolvers cannot link queries from the same Client in the abs ence of unique per-Client <li>Target resolvers cannot link queries from the same Client in the abs ence of unique per-Client
keys.</li> keys.</li>
</ol> </ol>
<t>Traffic analysis mitigations are outside the scope of this document. In particular, this document <t>Traffic analysis mitigations are outside the scope of this document. In particular, this document
does not prescribe padding lengths for ObliviousDoHQuery and ObliviousDoHRespons does not prescribe padding lengths for <tt>ObliviousDoHQuery</tt> and <tt>Oblivi
e messages. ousDoHResponse</tt> messages.
Implementations SHOULD follow the guidance for choosing padding length in <xref Implementations <bcp14>SHOULD</bcp14> follow the guidance in <xref target="RFC84
target="RFC8467"/>.</t> 67"/> for choosing padding length.</t>
<t>Oblivious DoH security does not depend on Proxy and Target indistinguis hability. Specifically, an <t>Oblivious DoH security does not depend on Proxy and Target indistinguis hability. Specifically, an
on-path attacker could determine whether a connection a specific endpoint is use on-path attacker could determine whether a connection to a specific endpoint is
d for oblivious or used for oblivious or
direct DoH queries. However, this has no effect on confidentiality goals listed direct DoH queries. However, this has no effect on the confidentiality goals lis
above.</t> ted above.</t>
<section anchor="denial-of-service"> <section anchor="denial-of-service">
<name>Denial of Service</name> <name>Denial of Service</name>
<t>Malicious clients (or Proxies) can send bogus Oblivious DoH queries t o targets as a Denial-of-Service <t>Malicious Clients (or Proxies) can send bogus Oblivious DoH queries t o Targets as a Denial-of-Service
(DoS) attack. Target servers can throttle processing requests if such an event o ccurs. Additionally, (DoS) attack. Target servers can throttle processing requests if such an event o ccurs. Additionally,
since Targets provide explicit errors upon decryption failure, i.e., if cipherte xt decryption fails since Targets provide explicit errors upon decryption failure, i.e., if cipherte xt decryption fails
or if the plaintext DNS message is malformed, Proxies can throttle specific clie nts in response to or if the plaintext DNS message is malformed, Proxies can throttle specific Clie nts in response to
these errors. In general, however, Targets trust Proxies to not overwhelm the Ta rget, and it is these errors. In general, however, Targets trust Proxies to not overwhelm the Ta rget, and it is
expected that Proxies either implement some form of rate limiting or client auth entication to limit expected that Proxies implement either some form of rate limiting or client auth entication to limit
abuse; see <xref target="authentication"/>.</t> abuse; see <xref target="authentication"/>.</t>
<t>Malicious Targets or Proxies can send bogus answers in response to Ob livious DoH queries. Response <t>Malicious Targets or Proxies can send bogus answers in response to Ob livious DoH queries. Response
decryption failure is a signal that either the Proxy or Target is misbehaving. C lients can choose to decryption failure is a signal that either the Proxy or Target is misbehaving. C lients can choose to
stop using one or both of these servers in the event of such failure. However, a s above, malicious stop using one or both of these servers in the event of such failure. However, a s noted above, malicious
Targets and Proxies are out of scope for the threat model.</t> Targets and Proxies are out of scope for the threat model.</t>
</section> </section>
<section anchor="proxy-policies"> <section anchor="proxy-policies">
<name>Proxy Policies</name> <name>Proxy Policies</name>
<t>Proxies are free to enforce any forwarding policy they desire for Cli ents. For example, they can choose <t>Proxies are free to enforce any forwarding policy they desire for Cli ents. For example, they can choose
to only forward requests to known or otherwise trusted Targets.</t> 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 <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 RECOMMEND queries to unknown Targets. To mitigate this linkability vector, it is <bcp14>RE
ED that Proxies pool COMMENDED</bcp14> that Proxies pool
and reuse connections to Targets. Note that this benefits performance as well as and reuse connections to Targets. Note that this benefits performance as well as
privacy since privacy, since
queries do not incur any delay that might otherwise result from Proxy-to-Target connection establishment.</t> queries do not incur any delay that might otherwise result from Proxy-to-Target connection establishment.</t>
</section> </section>
<section anchor="authentication"> <section anchor="authentication">
<name>Authentication</name> <name>Authentication</name>
<t>Depending on the deployment scenario, Proxies and Targets might requi re authentication before use. <t>Depending on the deployment scenario, Proxies and Targets might requi re authentication before use.
Regardless of the authentication mechanism in place, Proxies MUST NOT reveal any Client Regardless of the authentication mechanism in place, Proxies <bcp14>MUST NOT</bc p14> reveal any Client
authentication information to Targets. This is required so Targets cannot unique ly identify authentication information to Targets. This is required so Targets cannot unique ly identify
individual Clients.</t> individual Clients.</t>
<t>Note that if Targets require Proxies to authenticate at the HTTP- or application-layer before use, <t>Note that if Targets require Proxies to authenticate at the HTTP or application layer before use,
this ought to be done before attempting to forward any Client query to the Targe t. This will allow this ought to be done before attempting to forward any Client query to the Targe t. This will allow
Proxies to distinguish 401 Unauthorized response codes due to authentication fai Proxies to distinguish 401 (Unauthorized) response codes due to authentication f
lure from ailure from
401 Unauthorized response codes due to Client key mismatch; see <xref target="ob 401 response codes due to Client key mismatch; see <xref target="oblivious-respo
livious-response"/>.</t> nse"/>.</t>
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes changes to the "Multipurpose Internet Mail Extensio ns (MIME) and Media Types" registry. <t>This document makes changes to the "Media Types" registry.
The changes are described in the following subsection.</t> The changes are described in the following subsection.</t>
<section anchor="oblivious-doh-message-media-type"> <section anchor="oblivious-doh-message-media-type">
<name>Oblivious DoH Message Media Type</name> <name>Oblivious DoH Message Media Type</name>
<t>This document registers a new media type, "application/oblivious-dns- message".</t> <t>This document registers a new media type, "application/oblivious-dns- message".</t>
<t>Type name: application</t> <dl spacing="normal">
<t>Subtype name: oblivious-dns-message</t> <dt>Type name:</dt><dd>application</dd>
<t>Required parameters: N/A</t> <dt>Subtype name:</dt><dd>oblivious-dns-message</dd>
<t>Optional parameters: N/A</t> <dt>Required parameters:</dt><dd>N/A</dd>
<t>Encoding considerations: This is a binary format, containing encrypte <dt>Optional parameters:</dt><dd>N/A</dd>
d DNS <dt>Encoding considerations:</dt><dd>This is a binary format, containing
requests and responses encoded as ObliviousDoHMessage values, as defined encrypted DNS
in <xref target="encoding"/>.</t> requests and responses encoded as <tt>ObliviousDoHMessage</tt> values, as define
<t>Security considerations: See this document. The content is an encrypt d
ed DNS in <xref target="encoding"/>.</dd>
message, and not executable code.</t> <dt>Security considerations:</dt><dd>See this document. The content is a
<t>Interoperability considerations: This document specifies format of n encrypted DNS
conforming messages and the interpretation thereof; see <xref target="encoding"/ message, and not executable code.</dd>
>.</t> <dt>Interoperability considerations:</dt><dd>This document specifies the
<t>Published specification: This document.</t> format of
<t>Applications that use this media type: This media type is intended conforming messages and the interpretation thereof; see <xref target="encoding"/
>.</dd>
<dt>Published specification:</dt><dd>This document</dd>
<dt>Applications that use this media type:</dt><dd>This media type is in
tended
to be used by Clients wishing to hide their DNS queries when to be used by Clients wishing to hide their DNS queries when
using DNS over HTTPS.</t> using DNS over HTTPS.</dd>
<t>Additional information: N/A</t> <dt>Additional information:</dt><dd>N/A</dd>
<t>Person and email address to contact for further information: See <dt>Person and email address to contact for further information:</dt><dd
Authors' Addresses section</t> >See the
<t>Intended usage: COMMON</t> Authors' Addresses section.</dd>
<t>Restrictions on usage: N/A</t> <dt>Intended usage:</dt><dd>COMMON</dd>
<t>Author: Tommy Pauly <eref target="mailto:tpauly@apple.com">tpauly@app <dt>Restrictions on usage:</dt><dd>N/A</dd>
le.com</eref></t> <dt>Author:</dt><dd>Tommy Pauly (tpauly@apple.com)</dd>
<t>Change controller: IETF</t> <dt>Change controller:</dt><dd>IETF</dd>
<t>Provisional registration? (standards tree only): No</t> <dt>Provisional registration? (standards tree only):</dt><dd>No</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="acknowledgments">
<name>Acknowledgments</name>
<t>This work is inspired by Oblivious DNS <xref target="I-D.annee-dprive-o
blivious-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> </middle>
<back> <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> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8
484">
<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 ge
tting 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/rfc2
119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. 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/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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/rfc6
570">
<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 describi
ng a range of Uniform Resource Identifiers through variable expansion. This spec
ification defines the URI Template syntax and the process for expanding a URI Te
mplate 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.ie
tf.org/archive/id/draft-ietf-httpbis-proxy-status-08.txt">
<front>
<title>The Proxy-Status HTTP Response Header Field</title>
<author fullname="Mark Nottingham">
<organization>Fastly</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> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8484.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-proxy-stat xml"/>
us-08"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
</reference> xml"/>
<reference anchor="RFC7235" target="https://www.rfc-editor.org/info/rfc7 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6570.
235"> xml"/>
<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="R
eschke">
<organization/>
</author>
<date month="June" year="2014"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on- level protocol for distributed, collaborative, hypermedia information system
s. 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/rfc7
231">
<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="R
eschke">
<organization/>
</author>
<date month="June" year="2014"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless \%applica
tion- level protocol for distributed, collaborative, hypertext information syste
ms. This document defines the semantics of HTTP/1.1 messages, as expressed by r
equest methods, request header fields, response status codes, and response heade
r fields, along with the payload of messages (metadata and body content) and mec
hanisms for content negotiation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7231"/>
<seriesInfo name="DOI" value="10.17487/RFC7231"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<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 Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over
the Internet in a way that is designed to prevent eavesdropping, tampering, and
message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="HPKE" target="https://www.ietf.org/archive/id/draft-i
rtf-cfrg-hpke-12.txt">
<front>
<title>Hybrid Public Key Encryption</title>
<author fullname="Richard L. Barnes">
<organization>Cisco</organization>
</author>
<author fullname="Karthik Bhargavan">
<organization>Inria</organization>
</author>
<author fullname="Benjamin Lipp">
<organization>Inria</organization>
</author>
<author fullname="Christopher A. Wood">
<organization>Cloudflare</organization>
</author>
<date day="2" month="September" year="2021"/>
<abstract>
<t> This document describes a scheme for hybrid public-key encry
ption
(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) <!-- draft-ietf-httpbis-proxy-status (AUTH48) (RFC 9209) -->
in the IRTF. <reference anchor='RFC9209' target="https://www.rfc-editor.org/info/rfc9209">
<front>
<title>The Proxy-Status HTTP Response Header Field</title>
<author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
<organization />
</author>
<author initials='P' surname='Sikora' fullname='Piotr Sikora'>
<organization />
</author>
<date year='2022' month='June'/>
</front>
<seriesInfo name="RFC" value="9209"/>
<seriesInfo name="DOI" value="10.17487/RFC9209"/>
</reference>
<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"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-hpke-12"/>
</reference>
<reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4
086">
<front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd">
<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 t
hat foil pattern analysis attempts. However, the security of these systems is d
ependent on generating secret quantities for passwords, cryptographic keys, and
similar quantities. The use of pseudo-random processes to generate secret quant
ities 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 wh
ole 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 techni
ques for generating such quantities. It recommends the use of truly random hard
ware 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 hard
ware solution is not available, and it gives examples of how large such quantiti
es need to be for some applications. This document specifies an Internet Best C
urrent Practices for the Internet Community, and requests discussion and suggest
ions 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/rfc8
467">
<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 Mechanism
s for DNS (EDNS(0)) but does not specify the actual padding length for specific
applications. This memo lists the possible options ("padding policies"), discus
ses the implications of each option, and provides a recommended (experimental) o
ption.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8467"/>
<seriesInfo name="DOI" value="10.17487/RFC8467"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.annee-dprive-oblivious-dns" target="https://www.i
etf.org/archive/id/draft-annee-dprive-oblivious-dns-00.txt">
<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 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 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> <!-- draft-annee-dprive-oblivious-dns (Expired) -->
</abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.annee-d
</front> prive-oblivious-dns.xml"/>
<seriesInfo name="Internet-Draft" value="draft-annee-dprive-oblivious-
dns-00"/>
</reference>
<reference anchor="RFC7871" target="https://www.rfc-editor.org/info/rfc7
871">
<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 G
aast">
<organization/>
</author>
<author fullname="D. Lawrence" initials="D." surname="Lawrence">
<organization/>
</author>
<author fullname="W. Kumari" initials="W." surname="Kumari">
<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 origin
ated 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>
</front>
<seriesInfo name="RFC" value="7871"/>
<seriesInfo name="DOI" value="10.17487/RFC7871"/>
</reference>
<reference anchor="RFC7239" target="https://www.rfc-editor.org/info/rfc7
239">
<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 allow
s proxy components to disclose information lost in the proxying process, for exa
mple, the originating IP address of a request or IP address of the proxy on the
user-agent-facing interface. In a path of proxying components, this makes it po
ssible 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 administrat
or 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-i
etf-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 encry
pted 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> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7871.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7239.
<seriesInfo name="Internet-Draft" value="draft-ietf-ohai-ohttp-01"/> xml"/>
</reference>
<!-- draft-ietf-ohai-ohttp (I-D Exists) (Used full xml entry to fix author initi
als) -->
<reference anchor="I-D.ietf-ohai-ohttp">
<front>
<title>Oblivious HTTP</title>
<author fullname="Martin Thomson">
<organization>Mozilla</organization>
</author>
<author fullname="Christopher A. Wood" surname="Wood" initials="C.A.">
<organization>Cloudflare</organization>
</author>
<date month="February" day="15" year="2022" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ohai-ohttp-01" />
</reference>
<reference anchor="Dolev-Yao" target="https://www.cs.huji.ac.il/~dolev/pubs/dole
v-yao-ieee-01056650.pdf">
<front>
<title>On the Security of Public Key Protocols</title>
<author fullname="Danny Dolev" surname="Dolev" initials="D">
<organization/>
</author>
<author fullname="Andrew C. Yao" surname="Yao" initials="A. C.">
<organization/>
</author>
<date month="March" year="1983"/>
</front>
<seriesInfo name="DOI" value="10.1109/TIT.1983.1056650"/>
<refcontent>IEEE Transactions on Information Theory, Vol. IT-29, No. 2</refcon
tent>
</reference>
</references> </references>
</references> </references>
<section anchor="use-of-generic-proxy-services"> <section anchor="use-of-generic-proxy-services">
<name>Use of Generic Proxy Services</name> <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 <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 s ystems are undesirable query origins from their contents. However, there are several reasons why such s ystems are undesirable
in comparison Oblivious DoH:</t> as contrasted with Oblivious DoH:</t>
<ol spacing="normal" type="1"><li>Tor is meant to be a generic connection- <ol spacing="normal" type="1"><li>Tor is meant to be a generic connection-
level anonymity system, and incurs higher latency costs level anonymity system, and it incurs higher latency costs
and protocol complexity for the purpose of proxying individual DNS queries. In c ontrast, Oblivious DoH and protocol complexity for the purpose of proxying individual DNS queries. In c ontrast, Oblivious DoH
is a lightweight protocol built on DoH, implemented as an application-layer prox y, that can be enabled is a lightweight protocol built on DoH, implemented as an application-layer prox y, that can be enabled
as a default mode for users which need increased privacy.</li> as a default mode for users that need increased privacy.</li>
<li>As a one-hop proxy, Oblivious DoH encourages connection-less proxies <li>As a one-hop proxy, Oblivious DoH encourages connectionless proxies
to mitigate Client query correlation to mitigate Client query correlation
with few round-trips. In contrast, multi-hop systems such as Tor often run secur with few round trips. In contrast, multi-hop systems such as Tor often run secur
e connections (TLS) end-to-end, e connections (TLS) end to end,
which means that DoH servers could track queries over the same connection. Using a fresh DoH connection 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> per query would incur a non-negligible penalty in connection setup time.</li>
</ol> </ol>
</section> </section>
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>This work is inspired by Oblivious DNS <xref target="I-D.annee-dprive-o
blivious-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> </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> </rfc>
 End of changes. 132 change blocks. 
922 lines changed or deleted 420 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/