rfc9458.original.xml   rfc9458.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.26 (Ruby 2.6. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
10) --> docName="draft-ietf-ohai-ohttp-10" number="9458" submissionType="IETF" category=
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft "std"
-ietf-ohai-ohttp-08" category="std" consensus="true" tocInclude="true" sortRefs= consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obs
"true" symRefs="true" version="3"> oletes=""
<!-- xml2rfc v2v3 conversion 3.17.0 --> xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.18.1 -->
<front> <front>
<title>Oblivious HTTP</title> <title>Oblivious HTTP</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ohai-ohttp-08"/> <seriesInfo name="RFC" value="9458"/>
<author initials="M." surname="Thomson" fullname="Martin Thomson"> <author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization> <organization>Mozilla</organization>
<address> <address>
<email>mt@lowentropy.net</email> <email>mt@lowentropy.net</email>
</address> </address>
</author> </author>
<author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2023" month="March" day="15"/> <date year="2024" month="January" />
<area>Security</area> <area>Security</area>
<workgroup>Oblivious HTTP Application Intermediation</workgroup> <workgroup>Oblivious HTTP Application Intermediation</workgroup>
<keyword>privacy</keyword>
<keyword>proxy</keyword>
<keyword>partitioning</keyword>
<keyword>tunnel</keyword>
<abstract> <abstract>
<t>This document describes a system for forwarding encrypted HTTP messages <t>This document describes Oblivious HTTP, a protocol for forwarding encrypted H
. TTP messages.
This allows a client to make multiple requests to an origin server without that Oblivious HTTP allows a client to make multiple requests to an origin server wit
server being able hout that server
to link those requests to the client or to identify the requests as having come being able to link those requests to the client or to identify the requests as h
from the same client, while placing only limited trust in the nodes used to forw aving come from the
ard the messages.</t> same client, while placing only limited trust in the nodes used to forward the m
essages.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/"/>.
</t>
<t>
Discussion of this document takes place on the
Oblivious HTTP Application Intermediation Working Group mailing list (<e
ref target="mailto:ohai@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/ohai/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ohai/"/
>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ietf-wg-ohai/oblivious-http"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>An HTTP request reveals information about the client's identity to the <t>HTTP requests reveal information about client identities to servers. Wh
server. ile the
Some of that information is in the request content, and therefore under the cont actual content of the request message is under the control of the client, other
rol information that is more difficult to control can still be used to identify the
of the client. However, the source IP address of the underlying connection revea client.</t>
ls <t>Even where an IP address is not directly associated with an individual,
information that the client has only limited control over.</t> the
<t>Even where an IP address is not directly associated with an individual, requests made from it can be correlated over time to assemble a profile of
the requests client behavior. In particular, connection reuse improves performance but
made from it can be correlated over time to assemble a profile of client behavio provides servers with the ability to link requests that share a connection.</t>
r. In <t>In particular, the source IP address of the underlying connection revea
particular, connection reuse improves performance, but provides servers with ls
the ability to correlate requests that share a connection.</t> identifying information that the client has only limited control over. While
<t><iref item="Client"/><xref target="dfn-client" format="none">Client</xr client-configured HTTP proxies can provide a degree of protection against IP
ef>-configured HTTP proxies can provide a degree of protection against IP address tracking, they present an unfortunate trade-off: if they are used withou
address tracking, and systems like virtual private networks and the Tor network t
<xref target="DMS2004"/> provide additional options for clients.</t> TLS, the contents of communication are revealed to the proxy; if they are used
<t>However, even when IP address tracking is mitigated using one of these with TLS, a new connection needs to be used for each request to ensure that the
techniques, each request origin server cannot use the connection as a way to correlate requests,
needs to be on a completely new TLS connection to avoid the connection itself be incurring significant performance overheads.</t>
ing used <t>To overcome these limitations, this document defines Oblivious HTTP, a
to correlate behavior. This imposes considerable performance and efficiency over protocol
heads, due for encrypting and sending HTTP messages from a client to a gateway. This uses a
to the additional round trip to the server (at a minimum), additional data excha trusted relay service in a manner that mitigates the use of metadata such as IP
nged, and address and connection information for client identification, with reasonable
additional CPU cost of cryptographic computations.</t> performance characteristics. This document describes:</t>
<t>To overcome these limitations, this document defines Oblivious HTTP, a <ol spacing="normal" type="1"><li>
protocol for <t>an algorithm for encapsulating binary HTTP messages <xref target="B
encrypting and sending HTTP messages from a client to a gateway through a truste INARY"/> using Hybrid
d relay Public Key Encryption (HPKE) <xref target="HPKE"/> to protect their contents,</t
service. In particular, the protocol in this document describes:</t> >
<ol spacing="normal" type="1"><li>an algorithm for encapsulating binary HT </li>
TP messages <xref target="BINARY"/> using Hybrid <li>
Public Key Encryption (HPKE; <xref target="HPKE"/>) to protect their contents,</ <t>a method for forwarding <xref target="dfn-enc-req" format="none">En
li> capsulated Requests</xref> between <xref target="dfn-client" format="none">Clien
<li>a method for forwarding these encapsulated messages between clients ts</xref> and an
and an <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> throu
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none gh a trusted <xref target="dfn-relay" format="none">Oblivious Relay Resource</xr
">Oblivious Gateway Resource</xref> through a trusted <iref item="Oblivious Rela ef> using
y Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xr HTTP, and</t>
ef> using </li>
HTTP, and</li> <li>
<li>requirements for how the <iref item="Oblivious Gateway Resource"/><x <t>requirements for how the Oblivious Gateway Resource handles Encapsu
ref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> handles lated Requests and produces <xref target="dfn-enc-res" format="none">Encapsulate
encapsulated HTTP d Responses</xref> for the Client.</t>
messages and produces encapsulated responses for the client.</li> </li>
</ol> </ol>
<t>The combination of encapsulation and relaying ensures that <iref item=" <t>The combination of encapsulation and relaying ensures that Oblivious Ga
Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious teway
Gateway Resource</xref> Resource never sees the Client's IP address and that the Oblivious Relay
never sees the client's IP address and the <iref item="Oblivious Relay Resource" Resource never sees plaintext HTTP message content.</t>
/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> never s <t>Oblivious HTTP allows connection reuse between the Client and Oblivious
ees Relay
plaintext HTTP message content.</t> Resource, as well as between that relay and the Oblivious Gateway Resource, so t
<t>Oblivious HTTP allows connection reuse between the client and <iref ite his
m="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious R
elay
Resource</xref>, as well as between that relay and the <iref item="Oblivious Gat
eway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resou
rce</xref>, so this
scheme represents a performance improvement over using just one request in each scheme represents a performance improvement over using just one request in each
connection. With limited trust placed in the <iref item="Oblivious Relay Resour connection. With limited trust placed in the Oblivious Relay Resource (see
ce"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> (see <xref target="security"/>), Clients are assured that requests are not uniquely a
<xref target="security"/>), <iref item="Clients"/><xref target="dfn-client" form ttributed to
at="none">Clients</xref> are assured that requests are not uniquely attributed t
o
them or linked to other requests.</t> them or linked to other requests.</t>
</section> </section>
<section anchor="overview"> <section anchor="overview">
<name>Overview</name> <name>Overview</name>
<t>An Oblivious HTTP <iref item="Client"/><xref target="dfn-client" format ="none">Client</xref> must initially know the following:</t> <t>An Oblivious HTTP <xref target="dfn-client" format="none">Client</xref> must initially know the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The identity of an <iref item="Oblivious Gateway Resource"/><xref ta <li>
rget="dfn-gateway" format="none">Oblivious Gateway Resource</xref>. This might <t>The identity of an <xref target="dfn-gateway" format="none">Oblivio
include some us Gateway Resource</xref>. This might include some
information about what Target Resources the <iref item="Oblivious Gateway Resour information about what <xref target="dfn-target" format="none">Target Resources<
ce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> /xref> the Oblivious Gateway Resource
supports.</li> supports.</t>
<li>The details of an HPKE public key for the <iref item="Oblivious Gate </li>
way Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resour <li>
ce</xref>, <t>The details of an HPKE public key for the Oblivious Gateway Resourc
e,
including an identifier for that key and the HPKE algorithms that are used including an identifier for that key and the HPKE algorithms that are used
with that key.</li> with that key.</t>
<li>The identity of an <iref item="Oblivious Relay Resource"/><xref targ </li>
et="dfn-relay" format="none">Oblivious Relay Resource</xref> that will accept re <li>
lay requests <t>The identity of an <xref target="dfn-relay" format="none">Oblivious
carrying an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format Relay Resource</xref> that will accept relay requests
="none">Encapsulated Request</xref> as its content and forward the content in carrying an <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>
these requests to a particular <iref item="Oblivious Gateway Resource"/><xref ta as its content and forward the content in
rget="dfn-gateway" format="none">Oblivious Gateway Resource</xref>. Oblivious H these requests to a particular Oblivious Gateway Resource. Oblivious HTTP
TTP uses a one-to-one mapping between Oblivious Relay and Gateway Resources; see
uses a one-to-one mapping between <iref item="Oblivious Relay and Gateway Resour <xref target="proxy-state"/> for more details.</t>
ces"/><xref target="dfn-relay" format="none">Oblivious Relay and Gateway Resourc </li>
es</xref>; see
<xref target="proxy-state"/> for more details.</li>
</ul> </ul>
<t>This information allows the <iref item="Client"/><xref target="dfn-clie <t>This information allows the Client to send HTTP requests to the Oblivio
nt" format="none">Client</xref> to send HTTP requests to the <iref item="Oblivio us
us Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource for forwarding to a Target Resource. The Oblivious Gateway
Gateway Resource</xref> for forwarding to a <iref item="Target Resource"/><xref Resource does not learn the Client's IP address or any other identifying
target="dfn-target" format="none">Target Resource</xref>. The <iref item="Obliv information that might be revealed from the Client at the transport layer, nor
ious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gatew does the Oblivious Gateway Resource learn which of the requests it receives are
ay from the same Client.</t>
Resource</xref> does not learn the client's IP address or any other identifying
information that might be revealed from the client at the transport layer, nor
does the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" for
mat="none">Oblivious Gateway Resource</xref> learn which of the requests it rece
ives are
from the same <iref item="Client"/><xref target="dfn-client" format="none">Clien
t</xref>.</t>
<figure anchor="fig-overview"> <figure anchor="fig-overview">
<name>Overview of Oblivious HTTP</name> <name>Overview of Oblivious HTTP</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="480" width="560" viewBox="0 0 560 480" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="480" width="560" viewBox="0 0 560 480" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">
<path d="M 8,48 L 8,96" fill="none" stroke="black"/> <path d="M 8,48 L 8,96" fill="none" stroke="black"/>
<path d="M 48,96 L 48,464" fill="none" stroke="black"/> <path d="M 48,96 L 48,464" fill="none" stroke="black"/>
<path d="M 88,48 L 88,96" fill="none" stroke="black"/> <path d="M 88,48 L 88,96" fill="none" stroke="black"/>
<path d="M 152,48 L 152,96" fill="none" stroke="black"/> <path d="M 152,48 L 152,96" fill="none" stroke="black"/>
<path d="M 192,96 L 192,464" fill="none" stroke="black"/> <path d="M 192,96 L 192,464" fill="none" stroke="black"/>
<path d="M 240,48 L 240,96" fill="none" stroke="black"/> <path d="M 240,48 L 240,96" fill="none" stroke="black"/>
skipping to change at line 229 skipping to change at line 233
| | Response ] | | | | Response ] | |
| Relay |<-------------------+ | | Relay |<-------------------+ |
| Response | | | | Response | | |
| [+ Encapsulated | | | | [+ Encapsulated | | |
| Response ] | | | | Response ] | | |
|<----------------+ | | |<----------------+ | |
| | | | | | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In order to forward a request for a <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref> to the <iref item="Obl ivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gat eway <t>In order to forward a request for a <xref target="dfn-target" format="n one">Target Resource</xref> to the <xref target="dfn-gateway" format="none">Obli vious Gateway
Resource</xref>, the following steps occur, as shown in <xref target="fig-overvi ew"/>:</t> Resource</xref>, the following steps occur, as shown in <xref target="fig-overvi ew"/>:</t>
<ol spacing="normal" type="1"><li>The <iref item="Client"/><xref target="d <ol spacing="normal" type="1"><li>
fn-client" format="none">Client</xref> constructs an HTTP request for a <iref it <t>The <xref target="dfn-client" format="none">Client</xref> construct
em="Target Resource"/><xref target="dfn-target" format="none">Target Resource</x s an HTTP request for a Target Resource.</t>
ref>.</li> </li>
<li>The <iref item="Client"/><xref target="dfn-client" format="none">Cli <li>
ent</xref> encodes the HTTP request in a binary HTTP message and then <t>The Client encodes the HTTP request in a binary HTTP message and th
encapsulates that message using HPKE and the process from <xref target="request" en
/>.</li> encapsulates that message using HPKE and the process from <xref target="request"
<li>The <iref item="Client"/><xref target="dfn-client" format="none">Cli />.</t>
ent</xref> sends a POST request to the <iref item="Oblivious Relay Resource"/><x </li>
ref target="dfn-relay" format="none">Oblivious Relay Resource</xref> with the <li>
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca <t>The Client sends a POST request to the <xref target="dfn-relay" for
psulated Request</xref> as the content of that message.</li> mat="none">Oblivious Relay Resource</xref> with the
<li>The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" <xref target="dfn-enc-req" format="none">Encapsulated Request</xref> as the cont
format="none">Oblivious Relay Resource</xref> forwards this request to the Obliv ent of that message.</t>
ious Gateway </li>
resource.</li> <li>
<li>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatew <t>The Oblivious Relay Resource forwards this request to the Oblivious
ay" format="none">Oblivious Gateway Resource</xref> receives this request and re Gateway
moves Resource.</t>
the HPKE protection to obtain an HTTP request.</li> </li>
<li>
<t>The Oblivious Gateway Resource receives this request and removes
the HPKE protection to obtain an HTTP request.</t>
</li>
</ol> </ol>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" <t>The Oblivious Gateway Resource then handles the HTTP request. This typi
format="none">Oblivious Gateway Resource</xref> then handles the HTTP request. cally
This typically involves making an HTTP request using the content of the Encapsulated Request. O
involves making an HTTP request using the content of the <iref item="Encapsulate nce the
d Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> Oblivious Gateway Resource has an HTTP response for this request, the following
. Once the steps occur to return this response to the Client:</t>
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none <ol spacing="normal" type="1"><li>
">Oblivious Gateway Resource</xref> has an HTTP response for this request, the f <t>The Oblivious Gateway Resource encapsulates the HTTP response follo
ollowing wing the
steps occur to return this response to the client:</t>
<ol spacing="normal" type="1"><li>The <iref item="Oblivious Gateway Resour
ce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>
encapsulates the HTTP response following the
process in <xref target="response"/> and sends this in response to the request f rom the process in <xref target="response"/> and sends this in response to the request f rom the
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob Oblivious Relay Resource.</t>
livious Relay Resource</xref>.</li> </li>
<li>The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" <li>
format="none">Oblivious Relay Resource</xref> forwards this response to the <ire <t>The Oblivious Relay Resource forwards this response to the Client.<
f item="Client"/><xref target="dfn-client" format="none">Client</xref>.</li> /t>
<li>The <iref item="Client"/><xref target="dfn-client" format="none">Cli </li>
ent</xref> removes the encapsulation to obtain the response to the original <li>
request.</li> <t>The Client removes the encapsulation to obtain the response to the
original
request.</t>
</li>
</ol> </ol>
<t>This interaction provides authentication and confidentiality protection between <t>This interaction provides authentication and confidentiality protection between
the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> a the Client and the Oblivious Gateway, but importantly not between the Client and
nd the Oblivious Gateway, but importantly not between the <iref item="Client"/>< the Target Resource. While the Target Resource is a distinct HTTP resource from
xref target="dfn-client" format="none">Client</xref> and the Oblivious Gateway Resource, they are both logically under the control of the
the <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Oblivious Gateway, since the Oblivious Gateway Resource can unilaterally dictate
Resource</xref>. While the <iref item="Target Resource"/><xref target="dfn-targ the responses returned from the Target Resource to the Client. This arrangement
et" format="none">Target Resource</xref> is a distinct HTTP resource from
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="
none">Oblivious Gateway Resource</xref>, they are both logically under the contr
ol of the
Oblivious Gateway, since the <iref item="Oblivious Gateway Resource"/><xref targ
et="dfn-gateway" format="none">Oblivious Gateway Resource</xref> can unilaterall
y dictate
the responses returned from the <iref item="Target Resource"/><xref target="dfn-
target" format="none">Target Resource</xref> to the <iref item="Client"/><xref t
arget="dfn-client" format="none">Client</xref>. This arrangement
is shown in <xref target="fig-overview"/>.</t> is shown in <xref target="fig-overview"/>.</t>
<section anchor="applicability"> <section anchor="applicability">
<name>Applicability</name> <name>Applicability</name>
<t>Oblivious HTTP has limited applicability. Imporantly, it requires ex <t>Oblivious HTTP has limited applicability. Importantly, it requires e
picit xplicit
support from a willing <iref item="Oblivious Relay Resource"/><xref target="dfn- support from a willing <xref target="dfn-relay" format="none">Oblivious Relay Re
relay" format="none">Oblivious Relay Resource</xref> and <iref item="Oblivious G source</xref> and <xref target="dfn-gateway" format="none">Oblivious Gateway Res
ateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Res ource</xref>,
ource</xref>,
thereby limiting the use of Oblivious HTTP for generic applications; thereby limiting the use of Oblivious HTTP for generic applications;
see <xref target="server-responsibilities"/> for more information.</t> see <xref target="server-responsibilities"/> for more information.</t>
<t>Many uses of HTTP benefit from being able to carry state between requ <t>Many uses of HTTP benefit from being able to carry state between requ
ests, ests, such
such as with cookies (<xref target="COOKIES"/>), authentication (<xref section=" as with cookies <xref target="COOKIES"/>, authentication (<xref section="11" sec
11" sectionFormat="of" target="HTTP"/>), tionFormat="of" target="HTTP"/>), or even
or even alternative services (<xref target="RFC7838"/>). Oblivious HTTP removes alternative services <xref target="RFC7838"/>. Oblivious HTTP removes linkage a
linkage t the
at the transport layer, which is only useful for an application transport layer, which is only useful for an application that does not carry
that does not carry state between requests.</t> state between requests.</t>
<t>Oblivious HTTP is primarily useful where privacy risks associated wit <t>Oblivious HTTP is primarily useful where the privacy risks associated
h possible with
stateful treatment of requests are sufficiently large that the cost of deploying possible stateful treatment of requests are sufficiently large that the cost of
this protocol can be justified. Oblivious HTTP is simpler and less costly than deploying this protocol can be justified. Oblivious HTTP is simpler and less
more robust systems, like Prio (<xref target="PRIO"/>) or Tor (<xref target="DMS costly than more robust systems, like Prio <xref target="PRIO"/> or Tor <xref ta
2004"/>), which can rget="DMS2004"/>, which
provide stronger guarantees at higher operational costs.</t> can provide stronger guarantees at higher operational costs.</t>
<t>Oblivious HTTP is more costly than a direct connection to a server. Some costs, <t>Oblivious HTTP is more costly than a direct connection to a server. Some costs,
like those involved with connection setup, can be amortized, but there are like those involved with connection setup, can be amortized, but there are
several ways in which Oblivious HTTP is more expensive than a direct request:</t > several ways in which Oblivious HTTP is more expensive than a direct request:</t >
<ul spacing="normal"> <ul spacing="normal">
<li>Each request requires at least two regular HTTP requests, which co <li>
uld <t>Each request requires at least two regular HTTP requests, which c
increase latency.</li> ould
<li>Each request is expanded in size with additional HTTP fields, increase latency.</t>
encryption-related metadata, and AEAD expansion.</li> </li>
<li>Deriving cryptographic keys and applying them for request and <li>
response protection takes non-negligible computational resources.</li> <t>Each request is expanded in size with additional HTTP fields,
encryption-related metadata, and Authenticated Encryption with Associated Data
(AEAD) expansion.</t>
</li>
<li>
<t>Deriving cryptographic keys and applying them for request and
response protection takes non-negligible computational resources.</t>
</li>
</ul> </ul>
<t>Examples of where preventing the linking of requests might justify th ese costs <t>Examples of where preventing the linking of requests might justify th ese costs
include:</t> include:</t>
<ul spacing="normal"> <dl>
<li>DNS queries. DNS queries made to a recursive resolver reveal info <dt>DNS queries:</dt>
rmation <dd>
about the requester, particularly if linked to other queries.</li> <t>DNS queries made to a recursive resolver reveal information about
<li>Telemetry submission. Applications that submit reports about thei the
r usage to requester, particularly if linked to other queries.</t>
their developers might use Oblivious HTTP for some types of moderately </dd>
sensitive data.</li> <dt>Telemetry submission:</dt>
</ul> <dd>
<t>These are examples of requests where there is information in a reques <t>Applications that submit reports about their usage to their devel
t that - if opers might
it were connected to the identity of the user - might allow a server to learn use Oblivious HTTP for some types of moderately sensitive data.</t>
something about that user even if the identity of the user is pseudonymous. </dd>
Other examples include the submission of anonymous surveys, making search </dl>
queries, or requesting location-specific content (such as retrieving tiles of a <t>These are examples of requests where there is information in a reques
map display).</t> t that --
if it were connected to the identity of the user -- might allow a server to
learn something about that user even if the identity of the user were
pseudonymous. Other examples include submitting anonymous surveys, making
search queries, or requesting location-specific content (such as retrieving
tiles of a map display).</t>
<t>In addition to these limitations, <xref target="security"/> describes operational constraints <t>In addition to these limitations, <xref target="security"/> describes operational constraints
that are necessary to realize the goals of the protocol.</t> that are necessary to realize the goals of the protocol.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<t>This document uses terminology from <xref target="HTTP"/> and defines <?line -18?>
several terms as
<t>This document uses terminology from <xref target="HTTP"/> and defines several
terms as
follows:</t> follows:</t>
<dl> <dl newline="true">
<dt><iref item="Client"/><xref target="dfn-client" format="none">Clien <!-- def: client -->
t</xref>:</dt> <dt anchor="dfn-client">Client:</dt>
<dd> <dd>
<t anchor="dfn-client">A <iref item="Client"/><xref target="dfn-clie <t>A Client originates Oblivious HTTP requests. A Client is also an
nt" format="none">Client</xref> originates Oblivious HTTP requests. A <iref ite HTTP client
m="Client"/><xref target="dfn-client" format="none">Client</xref> is also an HTT in two ways: for the <xref target="dfn-target" format="none">Target Resource</xr
P client ef> and for the <xref target="dfn-relay" format="none">Oblivious Relay
in two ways: for the <iref item="Target Resource"/><xref target="dfn-target" for
mat="none">Target Resource</xref> and for the <iref item="Oblivious Relay Resour
ce"/><xref target="dfn-relay" format="none">Oblivious Relay
Resource</xref>. However, when referring to the HTTP definition of client (<xref section="3.3" sectionFormat="of" target="HTTP"/>), the term "HTTP client" is us ed; see <xref target="http-usage"/>.</t> Resource</xref>. However, when referring to the HTTP definition of client (<xref section="3.3" sectionFormat="of" target="HTTP"/>), the term "HTTP client" is us ed; see <xref target="http-usage"/>.</t>
</dd> </dd>
<dt><iref item="Encapsulated Request"/><xref target="dfn-enc-req" form <!-- def: Encapsulated Request -->
at="none">Encapsulated Request</xref>:</dt> <dt anchor="dfn-enc-req">Encapsulated Request:</dt>
<dd> <dd>
<t anchor="dfn-enc-req">An HTTP request that is encapsulated in an H PKE-encrypted message; see <t>An HTTP request that is encapsulated in an HPKE-encrypted message ; see
<xref target="request"/>.</t> <xref target="request"/>.</t>
</dd> </dd>
<dt><iref item="Encapsulated Response"/><xref target="dfn-enc-res" for <!-- def: Encapsulated Response -->
mat="none">Encapsulated Response</xref>:</dt> <dt anchor="dfn-enc-res">Encapsulated Response:</dt>
<dd> <dd>
<t anchor="dfn-enc-res">An HTTP response that is encapsulated in an HPKE-encrypted message; see <t>An HTTP response that is encapsulated in an HPKE-encrypted messag e; see
<xref target="response"/>.</t> <xref target="response"/>.</t>
</dd> </dd>
<dt><iref item="Oblivious Relay Resource"/><xref target="dfn-relay" fo <!-- def: Oblivious Relay Resource -->
rmat="none">Oblivious Relay Resource</xref>:</dt> <dt anchor="dfn-relay">Oblivious Relay Resource:</dt>
<dd> <dd>
<t anchor="dfn-relay">An intermediary that forwards Encapsulated Req <t>An intermediary that forwards <xref target="dfn-enc-req" format="
uests and Responses between none">Encapsulated Requests</xref> and <xref target="dfn-enc-res" format="none">
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> and Responses</xref> between
a single <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" fo <xref target="dfn-client" format="none">Clients</xref> and a single <xref target
rmat="none">Oblivious Gateway Resource</xref>. In context, this can be ="dfn-gateway" format="none">Oblivious Gateway Resource</xref>. In context, thi
referred to as simply a "relay".</t> s can be
referred to simply as a "relay".</t>
</dd> </dd>
<dt><iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway <!-- def: Oblivious Gateway Resource -->
" format="none">Oblivious Gateway Resource</xref>:</dt> <dt anchor="dfn-gateway">Oblivious Gateway Resource:</dt>
<dd> <dd>
<t anchor="dfn-gateway">A resource that can receive an <iref item="E <t>A resource that can receive an <xref target="dfn-enc-req" format=
ncapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Requ "none">Encapsulated Request</xref>, extract the contents of
est</xref>, extract the contents of that request, forward it to a <xref target="dfn-target" format="none">Target Res
that request, forward it to a <iref item="Target Resource"/><xref target="dfn-ta ource</xref>, receive a response, encapsulate
rget" format="none">Target Resource</xref>, receive a response, encapsulate that response, and then return the resulting <xref target="dfn-enc-res" format="
that response, then return the resulting <iref item="Encapsulated Response"/><xr none">Encapsulated Response</xref>. In
ef target="dfn-enc-res" format="none">Encapsulated Response</xref>. In context, context, this can be referred to simply as a "gateway".</t>
this can be referred to as simply a "gateway".</t>
</dd> </dd>
<dt><iref item="Target Resource"/><xref target="dfn-target" format="no <!-- def: Target Resource -->
ne">Target Resource</xref>:</dt> <dt anchor="dfn-target">Target Resource:</dt>
<dd> <dd>
<t anchor="dfn-target">The resource that is the target of an <iref i <t>The resource that is the target of an <xref target="dfn-enc-req"
tem="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulate format="none">Encapsulated Request</xref>. This resource
d Request</xref>. This resource logically handles only regular HTTP requests and responses, so it might be
logically handles only regular HTTP requests and responses and so might be
ignorant of the use of Oblivious HTTP to reach it.</t> ignorant of the use of Oblivious HTTP to reach it.</t>
</dd> </dd>
</dl> </dl>
<t>This document includes pseudocode that uses the functions and convent ions <t>This document includes pseudocode that uses the functions and convent ions
defined in <xref target="HPKE"/>.</t> defined in <xref target="HPKE"/>.</t>
<t>Encoding an integer to a sequence of bytes in network byte order is d escribed <t>Encoding an integer to a sequence of bytes in network byte order is d escribed
using the function <tt>encode(n, v)</tt>, where <tt>n</tt> is the number of byte s and <tt>v</tt> is using the function <tt>encode(n, v)</tt>, where <tt>n</tt> is the number of byte s and <tt>v</tt> is
the integer value. ASCII <xref target="ASCII"/> encoding of a string <tt>s</tt> is the integer value. ASCII <xref target="ASCII"/> encoding of a string <tt>s</tt> is
indicated using the function <tt>encode_str(s)</tt>.</t> indicated using the function <tt>encode_str(s)</tt>.</t>
<t>Formats are described using notation from <xref section="1.3" section Format="of" target="QUIC"/>. An extension <t>Formats are described using notation from <xref section="1.3" section Format="of" target="QUIC"/>. An extension
to that notation expresses the number of bits in a field using a simple to that notation expresses the number of bits in a field using a simple
mathematical function.</t> mathematical function.</t>
</section> </section>
</section> </section>
<section anchor="key-configuration"> <section anchor="key-configuration">
<name>Key Configuration</name> <name>Key Configuration</name>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client</ <t>A <xref target="dfn-client" format="none">Client</xref> needs to acquir
xref> needs to acquire information about the <iref item="key configuration"/><xr e information about the key configuration of the
ef target="key-configuration" format="none">key configuration</xref> of the <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> in or
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none der to send <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref
">Oblivious Gateway Resource</xref> in order to send Encapsulated Requests. >.
In order to ensure that <iref item="Clients"/><xref target="dfn-client" format=" In order to ensure that Clients do not encapsulate messages that other entities
none">Clients</xref> do not encapsulate messages that other entities can intercept, the key configuration <bcp14>MUST</bcp14> be authenticated and ha
can intercept, the <iref item="key configuration"/><xref target="key-configurati ve integrity
on" format="none">key configuration</xref> <bcp14>MUST</bcp14> be authenticated
and have integrity
protection.</t> protection.</t>
<t>This document does not define how that acquisition occurs. However, in <t>This document does not define how that acquisition occurs. However, in
order to help facilitate interoperability, it does specify a format order to
for the keys. This ensures that different help facilitate interoperability, it does specify a format for the keys. This
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref> imple ensures that different Client implementations can be configured in the same way
mentations can be configured in the same way and also and also enables advertising key configurations in a consistent format. This
enables advertising <iref item="key configurations"/><xref target="key-configura format might be used, for example, with HTTPS, as part of a system for
tion" format="none">key configurations</xref> in a consistent format. This configuring or discovering key configurations. However, note that such a system
format might be used, for example with HTTPS, as part of a system for needs to consider the potential for key configuration to be used to compromise
configuring or discovering <iref item="key configurations"/><xref target="key-co Client privacy; see <xref target="privacy"/>.</t>
nfiguration" format="none">key configurations</xref>. Note however that such <t>A Client might have multiple key configurations to select from when
a system needs to consider the potential for <iref item="key configuration"/><xr encapsulating a request. Clients are responsible for selecting a preferred key
ef target="key-configuration" format="none">key configuration</xref> to be configuration from those it supports. Clients need to consider both the Key
used to compromise <iref item="Client"/><xref target="dfn-client" format="none"> Encapsulation Method (KEM) and the combinations of the Key Derivation Function
Client</xref> privacy; see <xref target="privacy"/>.</t> (KDF) and AEAD in this decision.</t>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client</
xref> might have multiple <iref item="key configurations"/><xref target="key-con
figuration" format="none">key configurations</xref> to select from when
encapsulating a request. <iref item="Clients"/><xref target="dfn-client" format=
"none">Clients</xref> are responsible for selecting a preferred <iref item="key
configuration"/><xref target="key-configuration" format="none">key
configuration</xref> from those it supports. <iref item="Clients"/><xref target=
"dfn-client" format="none">Clients</xref> need to consider both the key
encapsulation method (KEM) and the combinations of key derivation function
(KDF) and authenticated encryption with associated data (AEAD) in this
decision.</t>
<section anchor="key-config"> <section anchor="key-config">
<name>Key Configuration Encoding</name> <name>Key Configuration Encoding</name>
<t>A single <iref item="key configuration"/><xref target="key-configurat ion" format="none">key configuration</xref> consists of a key identifier, a publ ic key, an <t>A single <xref target="key-configuration" format="none">key configura tion</xref> consists of a key identifier, a public key, an
identifier for the KEM that the public key uses, and a set of HPKE symmetric identifier for the KEM that the public key uses, and a set of HPKE symmetric
algorithms. Each symmetric algorithm consists of an identifier for a KDF and an algorithms. Each symmetric algorithm consists of an identifier for a KDF and an
identifier for an AEAD.</t> identifier for an AEAD.</t>
<t><xref target="format-key-config"/> shows a single <iref item="key con figuration"/><xref target="key-configuration" format="none">key configuration</x ref>.</t> <t><xref target="format-key-config"/> shows a single key configuration.< /t>
<figure anchor="format-key-config"> <figure anchor="format-key-config">
<name>A Single Key Configuration</name> <name>A Single Key Configuration</name>
<sourcecode type="tls-syntax"><![CDATA[ <sourcecode type="tls-presentation"><![CDATA[
HPKE Symmetric Algorithms { HPKE Symmetric Algorithms {
HPKE KDF ID (16), HPKE KDF ID (16),
HPKE AEAD ID (16), HPKE AEAD ID (16),
} }
Key Config { Key Config {
Key Identifier (8), Key Identifier (8),
HPKE KEM ID (16), HPKE KEM ID (16),
HPKE Public Key (Npk * 8), HPKE Public Key (Npk * 8),
HPKE Symmetric Algorithms Length (16) = 4..65532, HPKE Symmetric Algorithms Length (16) = 4..65532,
HPKE Symmetric Algorithms (32) ..., HPKE Symmetric Algorithms (32) ...,
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>That is, a <iref item="key configuration"/><xref target="key-configur <t>That is, a key configuration consists of the following fields:</t>
ation" format="none">key configuration</xref> consists of the following fields:< <dl newline="true">
/t>
<dl>
<dt>Key Identifier:</dt> <dt>Key Identifier:</dt>
<dd> <dd>
<t>An 8 bit value that identifies the key used by the <iref item="Ob livious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Ga teway Resource</xref>.</t> <t>An 8-bit value that identifies the key used by the <xref target=" dfn-gateway" format="none">Oblivious Gateway Resource</xref>.</t>
</dd> </dd>
<dt>HPKE KEM ID:</dt> <dt>HPKE KEM ID:</dt>
<dd> <dd>
<t>A 16 bit value that identifies the Key Encapsulation Method (KEM) <t>A 16-bit value that identifies the KEM used for the identified ke
used for the y as defined
identified key as defined in <xref section="7.1" sectionFormat="of" target="HPKE in <xref section="7.1" sectionFormat="of" target="HPKE"/> or the <eref target="h
"/> or <eref target="https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-i ttps://www.iana.org/assignments/hpke" brackets="angle">"HPKE KEM Identifiers" re
ds">the HPKE KDF IANA gistry</eref>.</t>
registry</eref>.</t>
</dd> </dd>
<dt>HPKE Public Key:</dt> <dt>HPKE Public Key:</dt>
<dd> <dd>
<t>The public key used by the gateway. The length of the public key is <tt>Npk</tt>, which is <t>The public key used by the gateway. The length of the public key is <tt>Npk</tt>, which is
determined by the choice of HPKE KEM as defined in <xref section="4" sectionForm at="of" target="HPKE"/>.</t> determined by the choice of HPKE KEM as defined in <xref section="4" sectionForm at="of" target="HPKE"/>.</t>
</dd> </dd>
<dt>HPKE Symmetric Algorithms Length:</dt> <dt>HPKE Symmetric Algorithms Length:</dt>
<dd> <dd>
<t>A 16 bit integer in network byte order that encodes the length, i n bytes, of <t>A 16-bit integer in network byte order that encodes the length, i n bytes, of
the HPKE Symmetric Algorithms field that follows.</t> the HPKE Symmetric Algorithms field that follows.</t>
</dd> </dd>
<dt>HPKE Symmetric Algorithms:</dt> <dt>HPKE Symmetric Algorithms:</dt>
<dd> <dd>
<t>One or more pairs of identifiers for the different combinations o f HPKE KDF <t>One or more pairs of identifiers for the different combinations o f HPKE KDF
and AEAD that the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gat and AEAD that the Oblivious Gateway Resource supports:</t>
eway" format="none">Oblivious Gateway Resource</xref> supports:</t> <dl newline="true">
<dl>
<dt>HPKE KDF ID:</dt> <dt>HPKE KDF ID:</dt>
<dd> <dd>
<t>A 16 bit HPKE KDF identifier as defined in <xref section="7.2 <t>A 16-bit HPKE KDF identifier as defined in <xref section="7.2
" sectionFormat="of" target="HPKE"/> or <eref target="https://www.iana.org/assig " sectionFormat="of" target="HPKE"/> or the <eref target="https://www.iana.org/a
nments/hpke/hpke.xhtml#hpke-kdf-ids">the ssignments/hpke" brackets="angle">
HPKE KDF IANA "HPKE KDF Identifiers"
registry</eref>.</t> registry</eref>.</t>
</dd> </dd>
<dt>HPKE AEAD ID:</dt> <dt>HPKE AEAD ID:</dt>
<dd> <dd>
<t>A 16 bit HPKE AEAD identifier as defined in <xref section="7. <t>A 16-bit HPKE AEAD identifier as defined in <xref section="7.
3" sectionFormat="of" target="HPKE"/> or <eref target="https://www.iana.org/assi 3" sectionFormat="of" target="HPKE"/> or the <eref target="https://www.iana.org/
gnments/hpke/hpke.xhtml#hpke-aead-ids">the assignments/hpke" brackets="angle">"HPKE AEAD Identifiers" registry</eref>.</t>
HPKE AEAD IANA
registry</eref>.</t>
</dd> </dd>
</dl> </dl>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="ohttp-keys"> <section anchor="ohttp-keys">
<name>Key Configuration Media Type</name> <name>Key Configuration Media Type</name>
<t>The "application/ohttp-keys" format is a media type that identifies a serialized <t>The "application/ohttp-keys" format is a media type that identifies a serialized
collection of <iref item="key configurations"/><xref target="key-configuration" collection of <xref target="key-configuration" format="none">key configurations<
format="none">key configurations</xref>. The content of this media type comprise /xref>. The content of this media type comprises one
s one or more key configuration encodings (see <xref target="key-config"/>). Each enc
or more <iref item="key configuration"/><xref target="key-configuration" format= oded
"none">key configuration</xref> encodings (see <xref target="key-config"/>) that configuration is prefixed with a 2-byte integer in network byte order that
are concatenated; indicates the length of the key configuration in bytes. The length-prefixed
see <xref target="iana-keys"/> for a definition of the media type.</t> encodings are concatenated to form a list. See <xref target="iana-keys"/> for a
<t>Evolution of the <iref item="key configuration"/><xref target="key-co definition
nfiguration" format="none">key configuration</xref> format is supported through of the media type.</t>
the definition of <t>Evolution of the key configuration format is supported through the de
finition of
new formats that are identified by new media types.</t> new formats that are identified by new media types.</t>
<t>A <xref target="dfn-client" format="none">Client</xref> that receives
an "application/ohttp-keys" object with encoding errors
might be able to recover one or more key configurations. Differences in how key
configurations are recovered might be exploited to segregate Clients, so Clients
<bcp14>MUST</bcp14> discard incorrectly encoded key configuration coll
ections.</t>
</section> </section>
</section> </section>
<section anchor="hpke-encapsulation"> <section anchor="hpke-encapsulation">
<name>HPKE Encapsulation</name> <name>HPKE Encapsulation</name>
<t>This document defines how a binary-encoded HTTP message <xref target="B INARY"/> is <t>This document defines how a binary-encoded HTTP message <xref target="B INARY"/> is
encapsulated using HPKE <xref target="HPKE"/>. Separate media types are defined to encapsulated using HPKE <xref target="HPKE"/>. Separate media types are defined to
distinguish request and response messages:</t> distinguish request and response messages:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>An <iref item="Encapsulated Request"/><xref target="dfn-enc-req" for <li>
mat="none">Encapsulated Request</xref> format defined in <xref target="req-forma <t>An <xref target="dfn-enc-req" format="none">Encapsulated Request</x
t"/> is identified by the ref> format defined in <xref target="req-format"/> is identified by the
<xref format="title" target="iana-req">"<tt>message/ohttp-req</tt>" media type</ <xref target="iana-req">"<tt>message/ohttp-req</tt>" media type</xref>.</t>
xref>.</li> </li>
<li>An <iref item="Encapsulated Response"/><xref target="dfn-enc-res" fo <li>
rmat="none">Encapsulated Response</xref> format defined in <xref target="res-for <t>An <xref target="dfn-enc-res" format="none">Encapsulated Response</
mat"/> is identified by the xref> format defined in <xref target="res-format"/> is identified by the
<xref target="iana-res">"<tt>message/ohttp-res</tt>" media type</xref>.</li> <xref target="iana-res">"<tt>message/ohttp-res</tt>" media type</xref>.</t>
</li>
</ul> </ul>
<t>Alternative encapsulations or message formats are indicated using the m edia <t>Alternative encapsulations or message formats are indicated using the m edia
type; see <xref target="req-res-media"/> and <xref target="repurposing"/>.</t> type; see Sections <xref format="counter" target="req-res-media"/> and <xref for mat="counter" target="repurposing"/>.</t>
<section anchor="req-format"> <section anchor="req-format">
<name>Request Format</name> <name>Request Format</name>
<t>A message in "<tt>message/ohttp-req</tt>" format protects a binary HT TP request <t>A message in "<tt>message/ohttp-req</tt>" format protects a binary HT TP request
message; see <xref target="fig-req-pt"/>.</t> message; see <xref target="fig-req-pt"/>.</t>
<figure anchor="fig-req-pt"> <figure anchor="fig-req-pt">
<name>Plaintext Request Content</name> <name>Plaintext Request Structure</name>
<artwork><![CDATA[ <artwork><![CDATA[
Request { Request {
Binary HTTP Message (..), Binary HTTP Message (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This plaintext Request is encapsulated into a message in "<tt>message <t>This plaintext Request structure is encapsulated into a message in
/ohttp-req</tt>" "<tt>message/ohttp-req</tt>" form by generating an <xref target="dfn-enc-req" fo
form by generating an <iref item="Encapsulated Request"/><xref target="dfn-enc-r rmat="none">Encapsulated Request</xref>. An
eq" format="none">Encapsulated Request</xref>. An <iref item="Encapsulated Requ Encapsulated Request comprises a key identifier; HPKE parameters for the chosen
est"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> compr KEM, KDF, and AEAD; the encapsulated KEM shared secret (or <tt>enc</tt>); and an
ises a HPKE-protected binary HTTP request message.</t>
key identifier; HPKE parameters for the chosen KEM, KDF, and AEAD; the <t>An Encapsulated Request is shown in <xref target="fig-enc-request"/>.
encapsulated KEM shared secret (or <tt>enc</tt>); and an HPKE-protected binary H <xref target="request"/> describes
TTP the process for constructing and processing an Encapsulated Request.</t>
request message.</t>
<t>An <iref item="Encapsulated Request"/><xref target="dfn-enc-req" form
at="none">Encapsulated Request</xref> is shown in <xref target="fig-enc-request"
/>. <xref target="request"/> describes
the process for constructing and processing an <iref item="Encapsulated Request"
/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref>.</t>
<figure anchor="fig-enc-request"> <figure anchor="fig-enc-request">
<name>Encapsulated Request</name> <name>Encapsulated Request</name>
<artwork><![CDATA[ <artwork><![CDATA[
Encapsulated Request { Encapsulated Request {
Key Identifier (8), Key Identifier (8),
HPKE KEM ID (16), HPKE KEM ID (16),
HPKE KDF ID (16), HPKE KDF ID (16),
HPKE AEAD ID (16), HPKE AEAD ID (16),
Encapsulated KEM Shared Secret (8 * Nenc), Encapsulated KEM Shared Secret (8 * Nenc),
HPKE-Protected Request (..), HPKE-Protected Request (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>That is, an <iref item="Encapsulated Request"/><xref target="dfn-enc- <t>That is, an <xref target="dfn-enc-req" format="none">Encapsulated Req
req" format="none">Encapsulated Request</xref> comprises a Key Identifier, HPKE uest</xref> comprises a Key Identifier, an HPKE KEM ID, an
KEM ID, HPKE HPKE KDF ID, an HPKE AEAD ID, an Encapsulated KEM Shared Secret, and an
KDF ID, HPKE AEAD ID, Encapsulated KEM Shared Secret, and HPKE-Protected HPKE-Protected Request. The Key Identifier, HPKE KEM ID, HPKE KDF ID, and HPKE
Request. The Key Identifier, HPKE KEM ID, HPKE KDF ID, and HPKE AEAD ID fields AEAD ID fields are defined in <xref target="key-config"/>. The Encapsulated KEM
are defined in <xref target="key-config"/>. The Encapsulated KEM Shared Secret Shared
is the output Secret is the output of the <tt>Encap()</tt> function for the KEM, which is <tt>
of the <tt>Encap()</tt> function for the KEM, which is <tt>Nenc</tt> bytes in le Nenc</tt>
ngth, as bytes in length, as defined in <xref section="4" sectionFormat="of" target="HPKE
defined in <xref section="4" sectionFormat="of" target="HPKE"/>.</t> "/>.</t>
</section> </section>
<section anchor="res-format"> <section anchor="res-format">
<name>Response Format</name> <name>Response Format</name>
<t>A message in "<tt>message/ohttp-res</tt>" format protects a binary HT TP response <t>A message in "<tt>message/ohttp-res</tt>" format protects a binary HT TP response
message; see <xref target="fig-res-pt"/>.</t> message; see <xref target="fig-res-pt"/>.</t>
<figure anchor="fig-res-pt"> <figure anchor="fig-res-pt">
<name>Plaintext Response Content</name> <name>Plaintext Response Structure</name>
<artwork><![CDATA[ <artwork><![CDATA[
Response { Response {
Binary HTTP Message (..), Binary HTTP Message (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This plaintext Response is encapsulated into a message in "<tt>messag <t>This plaintext Response structure is encapsulated into a message in
e/ohttp-res</tt>" "<tt>message/ohttp-res</tt>" form by generating an <xref target="dfn-enc-res" fo
form by generating an <iref item="Encapsulated Response"/><xref target="dfn-enc- rmat="none">Encapsulated Response</xref>. An
res" format="none">Encapsulated Response</xref>. An <iref item="Encapsulated Re Encapsulated Response comprises a nonce and the AEAD-protected binary HTTP
sponse"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref> c response message.</t>
omprises <t>An Encapsulated Response is shown in <xref target="fig-enc-response"/
a nonce and the AEAD-protected binary HTTP response message.</t> >. <xref target="response"/> describes
<t>An <iref item="Encapsulated Response"/><xref target="dfn-enc-res" for the process for constructing and processing an Encapsulated Response.</t>
mat="none">Encapsulated Response</xref> is shown in <xref target="fig-enc-respon
se"/>. <xref target="response"/> describes
the process for constructing and processing an <iref item="Encapsulated Response
"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>.</t>
<figure anchor="fig-enc-response"> <figure anchor="fig-enc-response">
<name>Encapsulated Response</name> <name>Encapsulated Response</name>
<artwork><![CDATA[ <artwork><![CDATA[
Encapsulated Response { Encapsulated Response {
Nonce (8 * max(Nn, Nk)), Nonce (8 * max(Nn, Nk)),
AEAD-Protected Response (..), AEAD-Protected Response (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>That is, an <iref item="Encapsulated Response"/><xref target="dfn-enc -res" format="none">Encapsulated Response</xref> contains a Nonce and an AEAD-Pr otected <t>That is, an <xref target="dfn-enc-res" format="none">Encapsulated Res ponse</xref> contains a Nonce and an AEAD-Protected
Response. The Nonce field is either <tt>Nn</tt> or <tt>Nk</tt> bytes long, whic hever is Response. The Nonce field is either <tt>Nn</tt> or <tt>Nk</tt> bytes long, whic hever is
larger. The <tt>Nn</tt> and <tt>Nk</tt> values correspond to parameters of the AEAD used in larger. The <tt>Nn</tt> and <tt>Nk</tt> values correspond to parameters of the AEAD used in
HPKE, which is defined in <xref section="7.3" sectionFormat="of" target="HPKE"/> HPKE, which is defined in <xref section="7.3" sectionFormat="of" target="HPKE"/>
or <eref target="https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids or <eref target="https://www.iana.org/assignments/hpke" brackets="angle">the "H
">the HPKE AEAD IANA PKE AEAD
Identifiers" IANA
registry</eref>. <tt>Nn</tt> registry</eref>. <tt>Nn</tt>
and <tt>Nk</tt> refer to the size of the AEAD nonce and key respectively, in byt es.</t> and <tt>Nk</tt> refer to the size of the AEAD nonce and key, respectively, in by tes.</t>
</section> </section>
<section anchor="request"> <section anchor="request">
<name>Encapsulation of Requests</name> <name>Encapsulation of Requests</name>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients <t><xref target="dfn-client" format="none">Clients</xref> encapsulate a
</xref> encapsulate a request, <tt>request</tt>, using values from a <iref item= request, identified as <tt>request</tt>, using values from a <xref target="key-c
"key configuration"/><xref target="key-configuration" format="none">key configur onfiguration" format="none">key
ation</xref>:</t> configuration</xref>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the key identifier from the configuration, <tt>key_id</tt>, with t <li>
he corresponding KEM <t>the key identifier from the configuration (<tt>key_id</tt>) with
identified by <tt>kem_id</tt>,</li> the corresponding
<li>the public key from the configuration, <tt>pkR</tt>, and</li> KEM identified by <tt>kem_id</tt>,</t>
<li>a combination of KDF, identified by <tt>kdf_id</tt>, and AEAD, ide </li>
ntified by <li>
<tt>aead_id</tt>, that the <iref item="Client"/><xref target="dfn-client" format <t>the public key from the configuration (<tt>pkR</tt>), and</t>
="none">Client</xref> selects from those in the <iref item="key configuration"/> </li>
<xref target="key-configuration" format="none">key configuration</xref>.</li> <li>
<t>a combination of KDF (identified by <tt>kdf_id</tt>) and AEAD (id
entified by
<tt>aead_id</tt>) that the Client selects from those in the key configuration.</
t>
</li>
</ul> </ul>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Clie <t>The Client then constructs an <xref target="dfn-enc-req" format="none
nt</xref> then constructs an <iref item="Encapsulated Request"/><xref target="df ">Encapsulated Request</xref>, <tt>enc_request</tt>, from a binary-encoded HTTP
n-enc-req" format="none">Encapsulated Request</xref>, <tt>enc_request</tt>, from request <xref target="BINARY"/> (<tt>request</tt>) as follows:</t>
a binary <ol spacing="normal" type="1"><li>
encoded HTTP request <xref target="BINARY"/>, <tt>request</tt>, as follows:</t> <t>Construct a message header (<tt>hdr</tt>) by concatenating the va
<ol spacing="normal" type="1"><li>Construct a message header, <tt>hdr</t lues of <tt>key_id</tt>,
t>, by concatenating the values of <tt>key_id</tt>, <tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt> as one 8-bit integer and
<tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt>, as one 8-bit integer and three 16-bit
three 16-bit integers, respectively, each in network byte order.</t>
integers, respectively, each in network byte order.</li> </li>
<li>Build <tt>info</tt> by concatenating the ASCII-encoded string "mes <li>
sage/bhttp <t>Build a sequence of bytes (<tt>info</tt>) by concatenating the AS
request", a zero byte, and the header. Note: <xref target="repurposing"/> discu CII-encoded string
sses how "message/bhttp request", a zero byte, and the header. Note: <xref target="repur
alternative message formats might use a different <tt>info</tt> value.</li> posing"/>
<li>Create a sending HPKE context by invoking <tt>SetupBaseS()</tt> (< discusses how alternative message formats might use a different <tt>info</tt> va
xref section="5.1.1" sectionFormat="of" target="HPKE"/>) with the public key of lue.</t>
the receiver <tt>pkR</tt> and <tt>info</tt>. This yields </li>
the context <tt>sctxt</tt> and an encapsulation key <tt>enc</tt>.</li> <li>
<li>Encrypt <tt>request</tt> by invoking the <tt>Seal()</tt> method on <t>Create a sending HPKE context by invoking <tt>SetupBaseS()</tt> (
<tt>sctxt</tt> (<xref section="5.2" sectionFormat="of" target="HPKE"/>) with em <xref section="5.1.1" sectionFormat="of" target="HPKE"/>) with the public key of
pty associated data <tt>aad</tt>, yielding ciphertext <tt>ct</tt>.</li> the receiver <tt>pkR</tt> and <tt>info</tt>. This yields
<li>Concatenate the values of <tt>hdr</tt>, <tt>enc</tt>, and <tt>ct</ the context <tt>sctxt</tt> and an encapsulation key <tt>enc</tt>.</t>
tt>, yielding an Encrypted </li>
Request <tt>enc_request</tt>.</li> <li>
<t>Encrypt <tt>request</tt> by invoking the <tt>Seal()</tt> method o
n <tt>sctxt</tt> (<xref section="5.2" sectionFormat="of" target="HPKE"/>) with e
mpty associated data <tt>aad</tt>, yielding ciphertext <tt>ct</tt>.</t>
</li>
<li>
<t>Concatenate the values of <tt>hdr</tt>, <tt>enc</tt>, and <tt>ct<
/tt>. This yields an Encapsulated
Request (<tt>enc_request</tt>).</t>
</li>
</ol> </ol>
<t>Note that <tt>enc</tt> is of fixed-length, so there is no ambiguity i n parsing this <t>Note that <tt>enc</tt> is of fixed length, so there is no ambiguity i n parsing this
structure.</t> structure.</t>
<t>In pseudocode, this procedure is as follows:</t> <t>In pseudocode, this procedure is as follows:</t>
<artwork><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
hdr = concat(encode(1, key_id), hdr = concat(encode(1, key_id),
encode(2, kem_id), encode(2, kem_id),
encode(2, kdf_id), encode(2, kdf_id),
encode(2, aead_id)) encode(2, aead_id))
info = concat(encode_str("message/bhttp request"), info = concat(encode_str("message/bhttp request"),
encode(1, 0), encode(1, 0),
hdr) hdr)
enc, sctxt = SetupBaseS(pkR, info) enc, sctxt = SetupBaseS(pkR, info)
ct = sctxt.Seal("", request) ct = sctxt.Seal("", request)
enc_request = concat(hdr, enc, ct) enc_request = concat(hdr, enc, ct)
]]></artwork> ]]></sourcecode>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway <t>An <xref target="dfn-gateway" format="none">Oblivious Gateway Resourc
" format="none">Oblivious Gateway Resource</xref> decrypts an <iref item="Encaps e</xref> decrypts an Encapsulated Request by reversing this
ulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</ process. To decapsulate an Encapsulated Request, <tt>enc_request</tt>:</t>
xref> by reversing this
process. To decapsulate an <iref item="Encapsulated Request"/><xref target="dfn-
enc-req" format="none">Encapsulated Request</xref>, <tt>enc_request</tt>:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Parses <tt>enc_request</tt> into <tt>key_id</tt>, <tt>kem_id</tt> <t>Parse <tt>enc_request</tt> into <tt>key_id</tt>, <tt>kem_id</tt>,
, <tt>kdf_id</tt>, <tt>aead_id</tt>, <tt>enc</tt>, and <tt>kdf_id</tt>, <tt>aead_id</tt>, <tt>enc</tt>, and
<tt>ct</tt> (indicated using the function <tt>parse()</tt> in pseudocode). The < <tt>ct</tt> (indicated using the function <tt>parse()</tt> in pseudocode). The O
iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none" blivious
>Oblivious Gateway Resource is then able to find the HPKE private key, <tt>skR</tt>,
Gateway Resource</xref> is then able to find the HPKE private key, <tt>skR</tt>,
corresponding to <tt>key_id</tt>. </t> corresponding to <tt>key_id</tt>. </t>
<t> <ol spacing="normal" type="a"><li>
a. If <tt>key_id</tt> does not identify a key matching the type of <tt>kem_id</t <t>If <tt>key_id</tt> does not identify a key matching the type
t>, the of <tt>kem_id</tt>, the
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="n Oblivious Gateway Resource returns an error.</t>
one">Oblivious Gateway Resource</xref> returns an error. </t> </li>
<t> <li>
b. If <tt>kdf_id</tt> and <tt>aead_id</tt> identify a combination of KDF and AEA <t>If <tt>kdf_id</tt> and <tt>aead_id</tt> identify a combinatio
D that the n of KDF and AEAD that the
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="n Oblivious Gateway Resource is unwilling to use with <tt>skR</tt>, the Oblivious
one">Oblivious Gateway Resource</xref> is unwilling to use with <tt>skR</tt>, th Gateway Resource returns an error.</t>
e <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format= </li>
"none">Oblivious </ol>
Gateway Resource</xref> returns an error.</t> </li>
<li>
<t>Build a sequence of bytes (<tt>info</tt>) by concatenating the AS
CII-encoded string
"message/bhttp request"; a zero byte; <tt>key_id</tt> as an 8-bit integer; plus
<tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt> as three 16-bit integers.
</t>
</li>
<li>
<t>Create a receiving HPKE context, <tt>rctxt</tt>, by invoking <tt>
SetupBaseR()</tt>
(<xref section="5.1.1" sectionFormat="of" target="HPKE"/>) with <tt>skR</tt>, <t
t>enc</tt>, and <tt>info</tt>.</t>
</li>
<li>
<t>Decrypt <tt>ct</tt> by invoking the <tt>Open()</tt> method on <tt
>rctxt</tt> (<xref section="5.2" sectionFormat="of" target="HPKE"/>), with an em
pty associated data <tt>aad</tt>, yielding <tt>request</tt> or an error
on failure. If decryption fails, the Oblivious Gateway Resource returns an
error.</t>
</li> </li>
<li>Build <tt>info</tt> by concatenating the ASCII-encoded string "mes
sage/bhttp
request", a zero byte, <tt>key_id</tt> as an 8-bit integer, plus <tt>kem_id</tt>
, <tt>kdf_id</tt>,
and <tt>aead_id</tt> as three 16-bit integers.</li>
<li>Create a receiving HPKE context, <tt>rctxt</tt>, by invoking <tt>S
etupBaseR()</tt>
(<xref section="5.1.1" sectionFormat="of" target="HPKE"/>) with <tt>skR</tt>, <t
t>enc</tt>, and <tt>info</tt>.</li>
<li>Decrypt <tt>ct</tt> by invoking the <tt>Open()</tt> method on <tt>
rctxt</tt> (<xref section="5.2" sectionFormat="of" target="HPKE"/>), with an emp
ty associated data <tt>aad</tt>, yielding <tt>request</tt> or an error
on failure. If decryption fails, the <iref item="Oblivious Gateway Resource"/><x
ref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> returns
an
error.</li>
</ol> </ol>
<t>In pseudocode, this procedure is as follows:</t> <t>In pseudocode, this procedure is as follows:</t>
<artwork><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request) key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request)
info = concat(encode_str("message/bhttp request"), info = concat(encode_str("message/bhttp request"),
encode(1, 0), encode(1, 0),
encode(1, key_id), encode(1, key_id),
encode(2, kem_id), encode(2, kem_id),
encode(2, kdf_id), encode(2, kdf_id),
encode(2, aead_id)) encode(2, aead_id))
rctxt = SetupBaseR(enc, skR, info) rctxt = SetupBaseR(enc, skR, info)
request, error = rctxt.Open("", ct) request, error = rctxt.Open("", ct)
]]></artwork> ]]></sourcecode>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatewa <t>The Oblivious Gateway Resource retains the HPKE context, <tt>rctxt</t
y" format="none">Oblivious Gateway Resource</xref> retains the HPKE context, <tt t>, so that it can
>rctxt</tt>, so that it can
encapsulate a response.</t> encapsulate a response.</t>
</section> </section>
<section anchor="response"> <section anchor="response">
<name>Encapsulation of Responses</name> <name>Encapsulation of Responses</name>
<t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" <t><xref target="dfn-gateway" format="none">Oblivious Gateway Resources<
format="none">Oblivious Gateway Resources</xref> generate an <iref item="Encapsu /xref> generate an <xref target="dfn-enc-res" format="none">Encapsulated Respons
lated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response< e</xref> (<tt>enc_response</tt>)
/xref>, <tt>enc_response</tt>, from a binary-encoded HTTP response <xref target="BINARY"/> (<tt>response</tt>).
from a binary encoded HTTP response <xref target="BINARY"/>, <tt>response</tt>. The Oblivious
The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format= Gateway Resource uses the HPKE receiver context (<tt>rctxt</tt>) as the HPKE con
"none">Oblivious text
Gateway Resource</xref> uses the HPKE receiver context, <tt>rctxt</tt>, as the H (<tt>context</tt>) as follows:</t>
PKE context, <ol spacing="normal" type="1"><li>
<tt>context</tt>, as follows:</t> <t>Export a secret (<tt>secret</tt>) from <tt>context</tt>, using th
<ol spacing="normal" type="1"><li>Export a secret, <tt>secret</tt>, from e string "message/bhttp
<tt>context</tt>, using the string "message/bhttp
response" as the <tt>exporter_context</tt> parameter to <tt>context.Export</tt>; see response" as the <tt>exporter_context</tt> parameter to <tt>context.Export</tt>; see
<xref section="5.3" sectionFormat="of" target="HPKE"/>. The length of this secr et is <tt>max(Nn, Nk)</tt>, where <xref section="5.3" sectionFormat="of" target="HPKE"/>. The length of this secr et is <tt>max(Nn, Nk)</tt>, where
<tt>Nn</tt> and <tt>Nk</tt> are the length of AEAD key and nonce associated with <tt>context</tt>. <tt>Nn</tt> and <tt>Nk</tt> are the length of the AEAD key and nonce that are as sociated with <tt>context</tt>.
Note: <xref target="repurposing"/> discusses how alternative message formats mig ht use a Note: <xref target="repurposing"/> discusses how alternative message formats mig ht use a
different <tt>context</tt> value.</li> different <tt>context</tt> value.</t>
<li>Generate a random value of length <tt>max(Nn, Nk)</tt> bytes, call </li>
ed <li>
<tt>response_nonce</tt>.</li> <t>Generate a random value of length <tt>max(Nn, Nk)</tt> bytes, cal
<li>Extract a pseudorandom key, <tt>prk</tt>, using the <tt>Extract</t led
t> function provided by <tt>response_nonce</tt>.</t>
</li>
<li>
<t>Extract a pseudorandom key (<tt>prk</tt>) using the <tt>Extract</
tt> function provided by
the KDF algorithm associated with <tt>context</tt>. The <tt>ikm</tt> input to th is the KDF algorithm associated with <tt>context</tt>. The <tt>ikm</tt> input to th is
function is <tt>secret</tt>; the <tt>salt</tt> input is the concatenation of <tt >enc</tt> (from function is <tt>secret</tt>; the <tt>salt</tt> input is the concatenation of <tt >enc</tt> (from
<tt>enc_request</tt>) and <tt>response_nonce</tt>.</li> <tt>enc_request</tt>) and <tt>response_nonce</tt>.</t>
<li>Use the <tt>Expand</tt> function provided by the same KDF to creat </li>
e an AEAD key, <li>
<tt>key</tt>, of length <tt>Nk</tt> - the length of the keys used by the AEAD as <t>Use the <tt>Expand</tt> function provided by the same KDF to crea
sociated te an AEAD key,
with <tt>context</tt>. Generating <tt>aead_key</tt> uses a label of "key".</li> <tt>key</tt>, of length <tt>Nk</tt> -- the length of the keys used by the AEAD a
<li>Use the same <tt>Expand</tt> function to create a nonce, <tt>nonce ssociated
</tt>, of length <tt>Nn</tt> - with <tt>context</tt>. Generating <tt>aead_key</tt> uses a label of "key".</t>
</li>
<li>
<t>Use the same <tt>Expand</tt> function to create a nonce, <tt>nonc
e</tt>, of length <tt>Nn</tt> --
the length of the nonce used by the AEAD. Generating <tt>aead_nonce</tt> uses a the length of the nonce used by the AEAD. Generating <tt>aead_nonce</tt> uses a
label of "nonce".</li> label of "nonce".</t>
<li>Encrypt <tt>response</tt>, passing the AEAD function Seal the valu </li>
es of <tt>aead_key</tt>, <li>
<tt>aead_nonce</tt>, an empty <tt>aad</tt>, and a <tt>pt</tt> input of <tt>respo <t>Encrypt <tt>response</tt>, passing the AEAD function Seal the val
nse</tt>, which yields <tt>ct</tt>.</li> ues of
<li>Concatenate <tt>response_nonce</tt> and <tt>ct</tt>, yielding an < <tt>aead_key</tt>, <tt>aead_nonce</tt>, an empty <tt>aad</tt>, and a <tt>pt</tt>
iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Enca input of
psulated Response</xref>, <tt>response</tt>. This yields <tt>ct</tt>.</t>
<tt>enc_response</tt>. Note that <tt>response_nonce</tt> is of fixed-length, so </li>
there is no <li>
ambiguity in parsing either <tt>response_nonce</tt> or <tt>ct</tt>.</li> <t>Concatenate <tt>response_nonce</tt> and <tt>ct</tt>, yielding an
Encapsulated Response,
<tt>enc_response</tt>. Note that <tt>response_nonce</tt> is of fixed length, so
there is no
ambiguity in parsing either <tt>response_nonce</tt> or <tt>ct</tt>.</t>
</li>
</ol> </ol>
<t>In pseudocode, this procedure is as follows:</t> <t>In pseudocode, this procedure is as follows:</t>
<artwork><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
secret = context.Export("message/bhttp response", Nk) secret = context.Export("message/bhttp response", max(Nn, Nk))
response_nonce = random(max(Nn, Nk)) response_nonce = random(max(Nn, Nk))
salt = concat(enc, response_nonce) salt = concat(enc, response_nonce)
prk = Extract(salt, secret) prk = Extract(salt, secret)
aead_key = Expand(prk, "key", Nk) aead_key = Expand(prk, "key", Nk)
aead_nonce = Expand(prk, "nonce", Nn) aead_nonce = Expand(prk, "nonce", Nn)
ct = Seal(aead_key, aead_nonce, "", response) ct = Seal(aead_key, aead_nonce, "", response)
enc_response = concat(response_nonce, ct) enc_response = concat(response_nonce, ct)
]]></artwork> ]]></sourcecode>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients <t><xref target="dfn-client" format="none">Clients</xref> decrypt an Enc
</xref> decrypt an <iref item="Encapsulated Response"/><xref target="dfn-enc-res apsulated Response by reversing this process. That is,
" format="none">Encapsulated Response</xref> by reversing this process. That is Clients first parse <tt>enc_response</tt> into <tt>response_nonce</tt> and <tt>c
, t</tt>. Then, they
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> fir
st parse <tt>enc_response</tt> into <tt>response_nonce</tt> and <tt>ct</tt>. The
y then
follow the same process to derive values for <tt>aead_key</tt> and <tt>aead_nonc e</tt>, using follow the same process to derive values for <tt>aead_key</tt> and <tt>aead_nonc e</tt>, using
their sending HPKE context, <tt>sctxt</tt>, as the HPKE context, <tt>context</tt >.</t> their sending HPKE context, <tt>sctxt</tt>, as the HPKE context, <tt>context</tt >.</t>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Clie <t>The Client uses these values to decrypt <tt>ct</tt> using the AEAD fu
nt</xref> uses these values to decrypt <tt>ct</tt> using the Open function provi nction <tt>Open</tt>.
ded by Decrypting might produce an error, as follows:</t>
the AEAD. Decrypting might produce an error, as follows:</t> <sourcecode type="pseudocode"><![CDATA[
<artwork><![CDATA[
response, error = Open(aead_key, aead_nonce, "", ct) response, error = Open(aead_key, aead_nonce, "", ct)
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="req-res-media"> <section anchor="req-res-media">
<name>Request and Response Media Types</name> <name>Request and Response Media Types</name>
<t>Media types are used to identify Encapsulated Requests and Responses; see <t>Media types are used to identify Encapsulated Requests and Responses; see
<xref target="iana-req"/> and <xref target="iana-res"/> for definitions of these media types.</t> Sections <xref format="counter" target="iana-req"/> and <xref format="counter" t arget="iana-res"/> for definitions of these media types.</t>
<t>Evolution of the format of Encapsulated Requests and Responses is sup ported <t>Evolution of the format of Encapsulated Requests and Responses is sup ported
through the definition of new formats that are identified by new media types. through the definition of new formats that are identified by new media types.
New media types might be defined to use similar encapsulation with a different New media types might be defined to use a similar encapsulation with a different
HTTP message format than in <xref target="BINARY"/>; see <xref target="repurposi ng"/> for guidance on HTTP message format than in <xref target="BINARY"/>; see <xref target="repurposi ng"/> for guidance on
reusing this encapsulation. Alternatively, a new encapsulation method might be reusing this encapsulation method. Alternatively, a new encapsulation method
defined.</t> might be defined.</t>
</section> </section>
<section anchor="repurposing"> <section anchor="repurposing">
<name>Repurposing the Encapsulation Format</name> <name>Repurposing the Encapsulation Format</name>
<t>The encrypted payload of an Oblivious HTTP request and response is a binary HTTP message <t>The encrypted payload of an Oblivious HTTP request and response is a binary HTTP message
<xref target="BINARY"/>. The <iref item="Client"/><xref target="dfn-client" for mat="none">Client</xref> and <iref item="Oblivious Gateway Resource"/><xref targ et="dfn-gateway" format="none">Oblivious Gateway Resource</xref> agree on this e ncrypted <xref target="BINARY"/>. The <xref target="dfn-client" format="none">Client</xr ef> and <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xre f> agree on this encrypted
payload type by specifying the media type "message/bhttp" in the HPKE info payload type by specifying the media type "message/bhttp" in the HPKE info
string and HPKE export context string for request and response encryption, string and HPKE export context string for request and response encryption,
respectively.</t> respectively.</t>
<t>Future specifications may repurpose the encapsulation mechanism descr ibed in <t>Future specifications may repurpose the encapsulation mechanism descr ibed in
this document. This requires that the specification define a new media type. this document. This requires that the specification define a new media type.
The encapsulation process for that content type can follow the same process, The encapsulation process for that content type can follow the same process,
using new constant strings for the HPKE info and exporter context inputs.</t> using new constant strings for the HPKE info and exporter context inputs.</t>
<t>For example, a future specification might encapsulate DNS messages, w hich use <t>For example, a future specification might encapsulate DNS messages, w hich use
the "application/dns-message" media type <xref target="RFC8484"/>. In creating a new, the "application/dns-message" media type <xref target="RFC8484"/>. In creating a new,
encrypted media types, specifications might define the use of string encrypted media types, specifications might define the use of string
"application/dns-message request" (plus a zero byte and the header for the full "application/dns-message request" (plus a zero byte and the header for the full
value) for request encryption and the string "application/dns-message response" value) for request encryption and the string "application/dns-message response"
for response encryption.</t> for response encryption.</t>
</section> </section>
</section> </section>
<section anchor="http-usage"> <section anchor="http-usage">
<name>HTTP Usage</name> <name>HTTP Usage</name>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client</ <t>A <xref target="dfn-client" format="none">Client</xref> interacts with
xref> interacts with the <iref item="Oblivious Relay Resource"/><xref target="df the <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> by co
n-relay" format="none">Oblivious Relay Resource</xref> by constructing an nstructing an
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>. This Enca
psulated Request</xref>. This <iref item="Encapsulated Request"/><xref target=" psulated Request is included as the content of a
dfn-enc-req" format="none">Encapsulated Request</xref> is included as the conten POST request to the Oblivious Relay Resource. This request only needs those
t of a fields necessary to carry the Encapsulated Request: a method of POST, a target
POST request to the <iref item="Oblivious Relay Resource"/><xref target="dfn-rel URI of the Oblivious Relay Resource, a header field containing the content type
ay" format="none">Oblivious Relay Resource</xref>. This request only needs thos (see <xref target="iana-req"/>), and the Encapsulated Request as the request con
e tent. In the
fields necessary to carry the <iref item="Encapsulated Request"/><xref target="d request to the Oblivious Relay Resource, Clients <bcp14>MAY</bcp14> include addi
fn-enc-req" format="none">Encapsulated Request</xref>: a method of POST, a targe tional
t fields. However, additional fields <bcp14>MUST</bcp14> be independent of the Enc
URI of the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" forma apsulated
t="none">Oblivious Relay Resource</xref>, a header field containing the content Request and <bcp14>MUST</bcp14> be fields that the Oblivious Relay Resource will
type remove before
(see <xref target="iana-req"/>), and the <iref item="Encapsulated Request"/><xre forwarding the Encapsulated Request towards the target, such as the <tt>Connecti
f target="dfn-enc-req" format="none">Encapsulated Request</xref> as the request on</tt>
content. In the or <tt>Proxy-Authorization</tt> header fields <xref target="HTTP"/>.</t>
request to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" f <t>The Client role in this protocol acts as an HTTP client both with respe
ormat="none">Oblivious Relay Resource</xref>, <iref item="Clients"/><xref target ct to the
="dfn-client" format="none">Clients</xref> <bcp14>MAY</bcp14> include additional Oblivious Relay Resource and the <xref target="dfn-target" format="none">Target
fields. However, additional fields <bcp14>MUST</bcp14> be independent of the <ir Resource</xref>. The request, which the Client
ef item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsu makes to the Target Resource, diverges from typical HTTP assumptions about
lated
Request</xref> and <bcp14>MUST</bcp14> be fields that the <iref item="Oblivious
Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource
</xref> will remove before
forwarding the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" for
mat="none">Encapsulated Request</xref> towards the target, such as the Connectio
n
or Proxy-Authorization header fields <xref target="HTTP"/>.</t>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Client
</xref> role in this protocol acts as an HTTP client both with respect to the
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob
livious Relay Resource</xref> and the <iref item="Target Resource"/><xref target
="dfn-target" format="none">Target Resource</xref>. For the request, the <iref
item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
makes to the <iref item="Target Resource"/><xref target="dfn-target" format="non
e">Target Resource</xref>, this diverges from typical HTTP assumptions about
the use of a connection (see <xref section="3.3" sectionFormat="of" target="HTTP "/>) in that the request and the use of a connection (see <xref section="3.3" sectionFormat="of" target="HTTP "/>) in that the request and
response are encrypted rather than sent over a connection. The <iref item="Obli response are encrypted rather than sent over a connection. The Oblivious Relay
vious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource and the <xref target="dfn-gateway" format="none">Oblivious Gateway Reso
Resource</xref> and the <iref item="Oblivious Gateway Resource"/><xref target="d urce</xref> also act as HTTP clients toward the
fn-gateway" format="none">Oblivious Gateway Resource</xref> also act as HTTP cli Oblivious Gateway Resource and Target Resource, respectively.</t>
ents toward the <t>In order to achieve the privacy and security goals of the protocol, a C
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none lient
">Oblivious Gateway Resource</xref> and <iref item="Target Resource"/><xref targ also needs to observe the guidance in <xref target="sec-client"/>.</t>
et="dfn-target" format="none">Target Resource</xref> respectively.</t> <t>The Oblivious Relay Resource interacts with the Oblivious Gateway Resou
<t>In order to achieve the privacy and security goals of the protocol a <i rce as an
ref item="Client"/><xref target="dfn-client" format="none">Client</xref> also HTTP client by constructing a request using the same restrictions as the Client
needs to observe the guidance in <xref target="sec-client"/>.</t> request, except that the target URI is the Oblivious Gateway Resource. The
<t>The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" for content of this request is copied from the Client. An Oblivious Relay Resource
mat="none">Oblivious Relay Resource</xref> interacts with the <iref item="Oblivi <bcp14>MAY</bcp14> reject
ous Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gatewa requests that are obviously invalid, such as a request with no content. The Obli
y Resource</xref> as an vious Relay
HTTP client by constructing a request using the same restrictions as the <iref i Resource <bcp14>MUST NOT</bcp14> add information to the request without the Clie
tem="Client"/><xref target="dfn-client" format="none">Client</xref> nt being aware of
request, except that the target URI is the <iref item="Oblivious Gateway Resourc
e"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>.
The
content of this request is copied from the <iref item="Client"/><xref target="df
n-client" format="none">Client</xref>. An <iref item="Oblivious Relay Resource"
/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> <bcp14>
MAY</bcp14> reject
requests that are obviously invalid, such as a request with no content. The <ire
f item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivi
ous Relay
Resource</xref> <bcp14>MUST NOT</bcp14> add information to the request without t
he <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> be
ing aware of
the type of information that might be added; see <xref target="relay-responsibil ities"/> for the type of information that might be added; see <xref target="relay-responsibil ities"/> for
more information on relay responsibilities.</t> more information on relay responsibilities.</t>
<t>When a response is received from the <iref item="Oblivious Gateway Reso <t>When a response is received from the Oblivious Gateway Resource, the Ob
urce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref livious
>, the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="n Relay Resource forwards the response according to the rules of an HTTP proxy;
one">Oblivious see <xref section="7.6" sectionFormat="of" target="HTTP"/>. In case of timeout
Relay Resource</xref> forwards the response according to the rules of an HTTP pr or error, the Oblivious Relay
oxy; Resource can generate a response with an appropriate status code.</t>
see <xref section="7.6" sectionFormat="of" target="HTTP"/>. In case of timeout <t>In order to achieve the privacy and security goals of the protocol, an
or error, the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" fo Oblivious
rmat="none">Oblivious Relay Relay Resource also needs to observe the guidance in <xref target="relay-respons
Resource</xref> can generate a response with an appropriate status code.</t> ibilities"/>.</t>
<t>In order to achieve the privacy and security goals of the protocol an < <t>An Oblivious Gateway Resource acts as a gateway for requests to the Tar
iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Obl get
ivious Resource (see <xref section="7.6" sectionFormat="of" target="HTTP"/>). The one
Relay Resource</xref> also needs to observe the guidance in exception is that any
<xref target="relay-responsibilities"/>.</t>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway"
format="none">Oblivious Gateway Resource</xref> acts as a gateway for requests t
o the <iref item="Target Resource"/><xref target="dfn-target" format="none">Targ
et
Resource</xref> (see <xref section="7.6" sectionFormat="of" target="HTTP"/>). T
he one exception is that any
information it might forward in a response <bcp14>MUST</bcp14> be encapsulated, unless it is information it might forward in a response <bcp14>MUST</bcp14> be encapsulated, unless it is
responding to errors that do not relate to processing the contents of the responding to errors that do not relate to processing the contents of the
encapsulated request; see <xref target="errors"/>.</t> Encapsulated Request; see <xref target="errors"/>.</t>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" <t>An Oblivious Gateway Resource, if it receives any response from the Tar
format="none">Oblivious Gateway Resource</xref>, if it receives any response fro get
m the <iref item="Target Resource"/><xref target="dfn-target" format="none">Targ Resource, sends a single 200 response containing the <xref target="dfn-enc-res"
et format="none">Encapsulated Response</xref>.
Resource</xref>, sends a single 200 response containing the encapsulated respons Like the request from the Client, this response <bcp14>MUST</bcp14> only contain
e. those fields
Like the request from the <iref item="Client"/><xref target="dfn-client" format= necessary to carry the Encapsulated Response: a 200 status code, a header field
"none">Client</xref>, this response <bcp14>MUST</bcp14> only contain those field indicating the content type, and the Encapsulated Response as the response
s
necessary to carry the encapsulated response: a 200 status code, a header field
indicating the content type, and the encapsulated response as the response
content. As with requests, additional fields <bcp14>MAY</bcp14> be used to conv ey information content. As with requests, additional fields <bcp14>MAY</bcp14> be used to conv ey information
that does not reveal information about the encapsulated response.</t> that does not reveal information about the Encapsulated Response.</t>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" <t>An Oblivious Gateway Resource that does not receive a response can itse
format="none">Oblivious Gateway Resource</xref> that does not receive a response lf
can itself
generate a response with an appropriate error status code (such as 504 (Gateway generate a response with an appropriate error status code (such as 504 (Gateway
Timeout); see <xref section="15.6.5" sectionFormat="of" target="HTTP"/>), which is then encapsulated in the Timeout); see <xref section="15.6.5" sectionFormat="of" target="HTTP"/>), which is then encapsulated in the
same way as a successful response.</t> same way as a successful response.</t>
<t>In order to achieve the privacy and security goals of the protocol an < <t>In order to achieve the privacy and security goals of the protocol, an
iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none" Oblivious
>Oblivious Gateway Resource also needs to observe the guidance in
Gateway Resource</xref> also needs to observe the guidance in
<xref target="server-responsibilities"/>.</t> <xref target="server-responsibilities"/>.</t>
<section anchor="informational-responses"> <section anchor="informational-responses">
<name>Informational Responses</name> <name>Informational Responses</name>
<t>This encapsulation does not permit progressive processing of response <t>This encapsulation does not permit progressive processing of response
s. Though s.
the binary HTTP response format does support the inclusion of informational Though the binary HTTP response format does support the inclusion of
(1xx) status codes, the AEAD encapsulation cannot be removed until the entire informational (1xx) status codes, the AEAD encapsulation cannot be removed until
message is received.</t> the entire message is received.</t>
<t>In particular, the Expect header field with 100-continue (see <xref s <t>In particular, the <tt>Expect</tt> header field with 100-continue (se
ection="10.1.1" sectionFormat="of" target="HTTP"/>) cannot be used. <iref item= e <xref section="10.1.1" sectionFormat="of" target="HTTP"/>) cannot be used. <x
"Clients"/><xref target="dfn-client" format="none">Clients</xref> <bcp14>MUST NO ref target="dfn-client" format="none">Clients</xref> <bcp14>MUST NOT</bcp14> con
T</bcp14> struct a request that includes a
construct a request that includes a 100-continue expectation; the <iref item="Ob 100-continue expectation; the <xref target="dfn-gateway" format="none">Oblivious
livious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> <bcp14>MUST</bcp14> generate an error
Gateway Resource</xref> <bcp14>MUST</bcp14> generate an error if a 100-continue if a 100-continue expectation is received.</t>
expectation is
received.</t>
</section> </section>
<section anchor="errors"> <section anchor="errors">
<name>Errors</name> <name>Errors</name>
<t>A server that receives an invalid message for any reason <bcp14>MUST< /bcp14> generate an HTTP <t>A server that receives an invalid message for any reason <bcp14>MUST< /bcp14> generate an HTTP
response with a 4xx status code.</t> response with a 4xx status code.</t>
<t>Errors detected by the <iref item="Oblivious Relay Resource"/><xref t <t>Errors detected by the <xref target="dfn-relay" format="none">Oblivio
arget="dfn-relay" format="none">Oblivious Relay Resource</xref> and errors detec us Relay Resource</xref> and errors detected by the
ted by the <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> befor
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none e removing protection (including being unable to
">Oblivious Gateway Resource</xref> before removing protection (including being
unable to
remove encapsulation for any reason) result in the status code being sent remove encapsulation for any reason) result in the status code being sent
without protection in response to the POST request made to that resource.</t> without protection in response to the POST request made to that resource.</t>
<t>Errors detected by the <iref item="Oblivious Gateway Resource"/><xref <t>Errors detected by the Oblivious Gateway Resource after successfully
target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> after succ removing
essfully removing encapsulation and errors detected by the <xref target="dfn-target" format="none"
encapsulation and errors detected by the <iref item="Target Resource"/><xref tar >Target Resource</xref> <bcp14>MUST</bcp14> be sent in an
get="dfn-target" format="none">Target Resource</xref> <bcp14>MUST</bcp14> be sen <xref target="dfn-enc-res" format="none">Encapsulated Response</xref>. This mig
t in an ht be because the <xref target="dfn-enc-req" format="none">Encapsulated Request<
<iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Enc /xref> is
apsulated Response</xref>. This might be because the <iref item="Encapsulated R malformed or the Target Resource does not produce a response. In either case,
equest"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> is the Oblivious Gateway Resource can generate a response with an appropriate error
malformed or the <iref item="Target Resource"/><xref target="dfn-target" format= status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see Sections <x
"none">Target Resource</xref> does not produce a response. In either case ref target="HTTP" section="15.5.1" sectionFormat="bare"/> and <xref target="HTTP
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format=" " section="15.6.5" sectionFormat="bare"/> of <xref target="HTTP"/>, respectively
none">Oblivious Gateway Resource</xref> can generate a response with an appropri ). This response is encapsulated in
ate error the same way as a successful response.</t>
status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see <xref secti
on="15.5.1" sectionFormat="of" target="HTTP"/> and <xref section="15.6.5" sectio
nFormat="of" target="HTTP"/>, respectively). This response
is encapsulated in the same way as a successful response.</t>
<t>Errors in the encapsulation of requests mean that responses cannot be <t>Errors in the encapsulation of requests mean that responses cannot be
encapsulated. This includes cases where the <iref item="key configuration"/><xr encapsulated. This includes cases where the <xref target="key-configuration" fo
ef target="key-configuration" format="none">key configuration</xref> is incorrec rmat="none">key configuration</xref> is incorrect or
t or outdated. The Oblivious Gateway Resource can generate and send a response with
outdated. The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatewa a 4xx status code to the Oblivious Relay Resource. This response <bcp14>MAY</bc
y" format="none">Oblivious Gateway Resource</xref> can generate and send a respo p14> be
nse with forwarded to the <xref target="dfn-client" format="none">Client</xref> or treate
a 4xx status code to the <iref item="Oblivious Relay Resource"/><xref target="df d by the Oblivious Relay Resource as a failure.
n-relay" format="none">Oblivious Relay Resource</xref>. This response <bcp14>MA If a Client receives a response that is not an Encapsulated Response, this could
Y</bcp14> be indicate that the Client configuration used to construct the request is
forwarded to the <iref item="Client"/><xref target="dfn-client" format="none">Cl
ient</xref> or treated by the <iref item="Oblivious Relay Resource"/><xref targe
t="dfn-relay" format="none">Oblivious Relay Resource</xref> as a failure.
If a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
receives a response that is not an <iref item="Encapsulated Response"/><xref tar
get="dfn-enc-res" format="none">Encapsulated Response</xref>, this could
indicate that the client configuration used to construct the request is
incorrect or out of date.</t> incorrect or out of date.</t>
</section> </section>
<section anchor="ohttp-key-problem"> <section anchor="ohttp-key-problem">
<name>Signaling Key Configuration Problems</name> <name>Signaling Key Configuration Problems</name>
<t>The problem type <xref target="PROBLEM"/> of <t>The problem type <xref target="PROBLEM"/> of
"https://iana.org/assignments/http-problem-types#ohttp-key" is defined. An "https://iana.org/assignments/http-problem-types#ohttp-key" is defined in this
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none section. An <xref target="dfn-gateway" format="none">Oblivious Gateway Resource
">Oblivious Gateway Resource</xref> <bcp14>MAY</bcp14> use this problem type in </xref> <bcp14>MAY</bcp14> use this problem type in a response
a response to indicate to indicate that an <xref target="dfn-enc-req" format="none">Encapsulated Reques
that an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="no t</xref> used an outdated or incorrect <xref target="key-configuration" format="
ne">Encapsulated Request</xref> used an outdated or incorrect <iref item="key co none">key
nfiguration"/><xref target="key-configuration" format="none">key configuration</ configuration</xref>.</t>
xref>.</t>
<t><xref target="fig-key-problem"/> shows an example response in HTTP/1. 1 format.</t> <t><xref target="fig-key-problem"/> shows an example response in HTTP/1. 1 format.</t>
<figure anchor="fig-key-problem"> <figure anchor="fig-key-problem">
<name>Example Rejection of Key Configuration</name> <name>Example Rejection of Key Configuration</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json Content-Type: application/problem+json
Content-Length: 106 Content-Length: 106
{"type":"https://iana.org/assignments/http-problem-types#ohttp-key", {"type":"https://iana.org/assignments/http-problem-types#ohttp-key",
"title": "key identifier unknown"} "title": "key identifier unknown"}
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>As this response cannot be encrypted, it might not reach the <iref it <t>As this response cannot be encrypted, it might not reach the <xref ta
em="Client"/><xref target="dfn-client" format="none">Client</xref>. A <iref ite rget="dfn-client" format="none">Client</xref>. A Client
m="Client"/><xref target="dfn-client" format="none">Client</xref> cannot rely on the <xref target="dfn-gateway" format="none">Oblivious Gateway Re
cannot rely on the <iref item="Oblivious Gateway Resource"/><xref target="dfn-ga source</xref> using this problem type. A Client
teway" format="none">Oblivious Gateway Resource</xref> using this problem type.
A <iref item="Client"/><xref target="dfn-client" format="none">Client</xref>
might also be configured to disregard responses that are not encapsulated on the might also be configured to disregard responses that are not encapsulated on the
basis that they might be subject to observation or modification by an <iref item basis that they might be subject to observation or modification by an Oblivious
="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource. A Client might manage the risk of an outdated key configuration
Relay Resource</xref>. A <iref item="Client"/><xref target="dfn-client" format= using a heuristic approach whereby it periodically refreshes its key
"none">Client</xref> might manage the risk of an outdated <iref item="key config configuration if it receives a response with an error status code that has not
uration"/><xref target="key-configuration" format="none">key configuration</xref
>
using a heuristic approach whereby it periodically refreshes its <iref item="key
configuration"/><xref target="key-configuration" format="none">key
configuration</xref> if it receives a response with an error status code that ha
s not
been encapsulated.</t> been encapsulated.</t>
</section> </section>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>In this design, a <iref item="Client"/><xref target="dfn-client" format <t>In this design, a <xref target="dfn-client" format="none">Client</xref>
="none">Client</xref> wishes to make a request to an <iref item="Oblivious Gatew wishes to make a request to an <xref target="dfn-gateway" format="none">Oblivio
ay Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resourc us Gateway
e</xref> Resource</xref> that is forwarded to a <xref target="dfn-target" format="none">T
that is forwarded to a <iref item="Target Resource"/><xref target="dfn-target" f arget Resource</xref>. The Client wishes to make this
ormat="none">Target Resource</xref>. The <iref item="Client"/><xref target="dfn- request without linking that request with either of the following:</t>
client" format="none">Client</xref> wishes to make this request without <ul spacing="normal">
linking that request with either:</t> <li>
<ol spacing="normal" type="1"><li>The identity at the network and transpor <t>The identity at the network and transport layer of the Client (that
t layer of the <iref item="Client"/><xref target="dfn-client" format="none">Clie is, the
nt</xref> (that is, the Client IP address and TCP or UDP port number the Client uses to create a
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref> IP ad connection).</t>
dress and TCP or UDP port number the <iref item="Client"/><xref target="dfn-clie </li>
nt" format="none">Client</xref> uses to create a <li>
connection).</li> <t>Any other request the Client might have made in the past or might m
<li>Any other request the <iref item="Client"/><xref target="dfn-client" ake in the
format="none">Client</xref> might have made in the past or might make in future.</t>
the future.</li> </li>
</ol> </ul>
<t>In order to ensure this, the <iref item="Client"/><xref target="dfn-cli <t>In order to ensure this, the Client selects a relay (that serves the
ent" format="none">Client</xref> selects a relay (that serves the <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref>) that it
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob trusts will protect this information
livious Relay Resource</xref>) that it trusts will protect this information by forwarding the Encapsulated Request and Response without passing it
by forwarding the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" to the server (that serves the Oblivious Gateway Resource).</t>
format="none">Encapsulated Request</xref> and Response without passing it
to the server (that serves the <iref item="Oblivious Gateway Resource"/><xref ta
rget="dfn-gateway" format="none">Oblivious Gateway Resource</xref>).</t>
<t>In this section, a deployment where there are three entities is conside red:</t> <t>In this section, a deployment where there are three entities is conside red:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A <iref item="Client"/><xref target="dfn-client" format="none">Clien <li>
t</xref> makes requests and receives responses</li> <t>A Client makes requests and receives responses.</t>
<li>A relay operates the <iref item="Oblivious Relay Resource"/><xref ta </li>
rget="dfn-relay" format="none">Oblivious Relay Resource</xref></li> <li>
<li>A server operates both the <iref item="Oblivious Gateway Resource"/> <t>A relay operates the Oblivious Relay Resource.</t>
<xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> and t </li>
he <iref item="Target Resource"/><xref target="dfn-target" format="none">Target <li>
Resource</xref></li> <t>A server operates both the Oblivious Gateway Resource and the Targe
t Resource.</t>
</li>
</ul> </ul>
<t><xref target="separate-target"/> discusses the security implications fo r a case where <t><xref target="separate-target"/> discusses the security implications fo r a case where
different servers operate the <iref item="Oblivious Gateway Resource"/><xref tar different servers operate the Oblivious Gateway Resource and Target Resource.</t
get="dfn-gateway" format="none">Oblivious Gateway Resource</xref> and <iref item >
="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xre <t>Requests from the Client to Oblivious Relay Resource and from Oblivious
f>.</t> Relay
<t>Requests from the <iref item="Client"/><xref target="dfn-client" format Resource to Oblivious Gateway Resource <bcp14>MUST</bcp14> use HTTPS in order to
="none">Client</xref> to <iref item="Oblivious Relay Resource"/><xref target="df provide
n-relay" format="none">Oblivious Relay Resource</xref> and from <iref item="Obli
vious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay
Resource</xref> to <iref item="Oblivious Gateway Resource"/><xref target="dfn-ga
teway" format="none">Oblivious Gateway Resource</xref> <bcp14>MUST</bcp14> use H
TTPS in order to provide
unlinkability in the presence of a network observer.</t> unlinkability in the presence of a network observer.</t>
<t>To achieve the stated privacy goals, the <iref item="Oblivious Relay Re <t>To achieve the stated privacy goals, the Oblivious Relay Resource canno
source"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> t be
cannot be operated by the same entity as the Oblivious Gateway Resource. However,
operated by the same entity as the <iref item="Oblivious Gateway Resource"/><xre colocation of the Oblivious Gateway Resource and Target Resource simplifies the
f target="dfn-gateway" format="none">Oblivious Gateway Resource</xref>. However, interactions between those resources without affecting Client privacy.</t>
colocation of the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gat
eway" format="none">Oblivious Gateway Resource</xref> and <iref item="Target Res
ource"/><xref target="dfn-target" format="none">Target Resource</xref> simplifie
s the
interactions between those resources without affecting <iref item="Client"/><xre
f target="dfn-client" format="none">Client</xref> privacy.</t>
<t>As a consequence of this configuration, Oblivious HTTP prevents linkabi lity <t>As a consequence of this configuration, Oblivious HTTP prevents linkabi lity
described above. Informally, this means:</t> described above. Informally, this means:</t>
<ol spacing="normal" type="1"><li>Requests and responses are known only to <ol spacing="normal" type="1"><li>
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> an <t>Requests and responses are known only to Clients and Oblivious Gate
d <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="n way
one">Oblivious Gateway Resources</xref>. Resources. In particular, the Oblivious Relay Resource knows the origin and
In particular, the <iref item="Oblivious Relay Resource"/><xref target="dfn-rela destination of an Encapsulated Request and Response, yet it does not know the
y" format="none">Oblivious Relay Resource</xref> knows the origin and destinatio decrypted contents. Likewise, Oblivious Gateway Resources learn only the
n Oblivious Relay Resource and the decrypted request. No entity other than the
of an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none Client can see the plaintext request and response and can attribute them to
">Encapsulated Request</xref> and Response, yet does not know the decrypted cont the Client.</t>
ents. </li>
Likewise, <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" f <li>
ormat="none">Oblivious Gateway Resources</xref> learn only the <iref item="Obliv <t>Oblivious Gateway Resources, and therefore Target Resources, cannot
ious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Res link
ource</xref> and requests from the same Client in the absence of unique per-Client keys.</t>
the decrypted request. No entity other than the <iref item="Client"/><xref targ </li>
et="dfn-client" format="none">Client</xref> can see the plaintext
request and response and can attribute them to the <iref item="Client"/><xref ta
rget="dfn-client" format="none">Client</xref>.</li>
<li>Oblivous Gateway Resources, and therefore Target Resources, cannot l
ink requests
from the same <iref item="Client"/><xref target="dfn-client" format="none">Clien
t</xref> in the absence of unique per-<iref item="Client"/><xref target="dfn-cli
ent" format="none">Client</xref> keys.</li>
</ol> </ol>
<t>Traffic analysis that might affect these properties are outside the sco <t>Traffic analysis that might affect these properties is outside the scop
pe of e of this
this document; see <xref target="ta"/>.</t> document; see <xref target="ta"/>.</t>
<t>A formal analysis of Oblivious HTTP is in <xref target="OHTTP-ANALYSIS" />.</t> <t>A formal analysis of Oblivious HTTP is in <xref target="OHTTP-ANALYSIS" />.</t>
<section anchor="sec-client"> <section anchor="sec-client">
<name>Client Responsibilities</name> <name>Client Responsibilities</name>
<t>Because <iref item="Clients"/><xref target="dfn-client" format="none" <t>Because <xref target="dfn-client" format="none">Clients</xref> do not
>Clients</xref> do not authenticate the <iref item="Target Resource"/><xref targ authenticate the <xref target="dfn-target" format="none">Target Resource</xref>
et="dfn-target" format="none">Target Resource</xref> when using Oblivious when using Oblivious
HTTP, <iref item="Clients"/><xref target="dfn-client" format="none">Clients</xre HTTP, Clients <bcp14>MUST</bcp14> have some mechanism to authorize an <xref targ
f> <bcp14>MUST</bcp14> have some mechanism to authorize an <iref item="Oblivious et="dfn-gateway" format="none">Oblivious Gateway
Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> for use with a Target Resource. One possible means of authorizat
Resource</xref> for use with a <iref item="Target Resource"/><xref target="dfn-t ion is
arget" format="none">Target Resource</xref>. One possible means of authorization an allowlist. This ensures that Oblivious Gateway Resources are not misused to
is
an allowlist. This ensures that <iref item="Oblivious Gateway Resources"/><xref
target="dfn-gateway" format="none">Oblivious Gateway Resources</xref> are not a
bused to
forward traffic to arbitrary Target Resources. <xref target="server-responsibili ties"/> forward traffic to arbitrary Target Resources. <xref target="server-responsibili ties"/>
describes similar responsibilities that apply to <iref item="Oblivious Gateway R describes similar responsibilities that apply to Oblivious Gateway Resources.</t
esources"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resources< >
/xref>.</t> <t>Clients <bcp14>MUST</bcp14> ensure that the <xref target="key-configu
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients ration" format="none">key configuration</xref> they select for generating
</xref> <bcp14>MUST</bcp14> ensure that the <iref item="key configuration"/><xre <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> is integri
f target="key-configuration" format="none">key configuration</xref> they select ty protected and authenticated so that it can
for generating be attributed to the Oblivious Gateway Resource; see <xref target="key-configura
Encapsulated Requests is integrity protected and authenticated so that it can tion"/>.</t>
be attributed to the <iref item="Oblivious Gateway Resource"/><xref target="dfn- <t>Since Clients connect directly to the <xref target="dfn-relay" format
gateway" format="none">Oblivious Gateway Resource</xref>; see <xref target="key- ="none">Oblivious Relay Resource</xref> instead of the
configuration"/>.</t> Target Resource, application configurations wherein Clients make policy
<t>Since <iref item="Clients"/><xref target="dfn-client" format="none">C decisions about target connections, e.g., to apply certificate pinning, are
lients</xref> connect directly to the <iref item="Oblivious Relay Resource"/><xr incompatible with Oblivious HTTP. In such cases, alternative technologies such
ef target="dfn-relay" format="none">Oblivious Relay Resource</xref> instead of t as HTTP CONNECT (<xref section="9.3.6" sectionFormat="of" target="HTTP"/>) can b
he <iref item="Target Resource"/><xref target="dfn-target" format="none">Target e used. Applications could
Resource</xref>, application implement related policies on key configurations and relay connections, though
configurations wherein <iref item="Clients"/><xref target="dfn-client" format="n these might not provide the same properties as policies enforced directly on
one">Clients</xref> make policy decisions about target connections, target connections. Instead, when this difference is relevant, applications can
e.g., to apply certificate pinning, are incompatible with Oblivious HTTP. In connect directly to the target at the cost of either privacy or performance.</t>
such cases, alternative technologies such as HTTP CONNECT <t>Clients cannot carry connection-level state between requests as they
(<xref section="9.3.6" sectionFormat="of" target="HTTP"/>) can be used. Applicat only
ions could implement related
policies on <iref item="key configurations"/><xref target="key-configuration" fo
rmat="none">key configurations</xref> and relay connections, though these might
not
provide the same properties as policies enforced directly on target
connections. When this difference is relevant, applications can instead connect
directly to the target at the cost of either privacy or performance.</t>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients
</xref> cannot carry connection-level state between requests as they only
establish direct connections to the relay responsible for the Oblivious Relay establish direct connections to the relay responsible for the Oblivious Relay
resource. However, the content of requests might be used by a server to Resource. However, the content of requests might be used by a server to
correlate requests. Cookies <xref target="COOKIES"/> are the most obvious featu correlate requests. Cookies <xref target="COOKIES"/> are the most obvious featu
re re that might
that might be used to correlate requests, but any identity information and be used to correlate requests, but any identity information and authentication
authentication credentials might have the same effect. <iref item="Clients"/><x credentials might have the same effect. Clients also need to treat information
ref target="dfn-client" format="none">Clients</xref> also need to learned from responses with similar care when constructing subsequent requests,
treat information learned from responses with similar care when constructing which includes the identity of resources.</t>
subsequent requests, which includes the identity of resources.</t> <t>Clients <bcp14>MUST</bcp14> generate a new HPKE context for every req
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients uest, using a good source
</xref> <bcp14>MUST</bcp14> generate a new HPKE context for every request, using of entropy <xref target="RANDOM"/> for generating keys. Key reuse not only risks
a good source requests being linked but also could expose request and response contents to the
of entropy (<xref target="RANDOM"/>) for generating keys. Key reuse not only ris
ks
requests being linked, reuse could expose request and response contents to the
relay.</t> relay.</t>
<t>The request the <iref item="Client"/><xref target="dfn-client" format ="none">Client</xref> sends to the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> only requires <t>The request the Client sends to the Oblivious Relay Resource only req uires
minimal information; see <xref target="http-usage"/>. The request that carries t he minimal information; see <xref target="http-usage"/>. The request that carries t he
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca Encapsulated Request and that is sent to the Oblivious Relay Resource <bcp14>MUS
psulated Request</xref> and is sent to the <iref item="Oblivious Relay Resource" T NOT</bcp14>
/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> <bcp14> include identifying information unless the Client can trust that this
MUST NOT</bcp14> information is removed by the relay. A Client <bcp14>MAY</bcp14> include informa
include identifying information unless the <iref item="Client"/><xref target="df tion only for
n-client" format="none">Client</xref> can trust that this the Oblivious Relay Resource in header fields identified by the <tt>Connection</
information is removed by the relay. A <iref item="Client"/><xref target="dfn-cl tt>
ient" format="none">Client</xref> <bcp14>MAY</bcp14> include information only fo header field if it trusts the relay to remove these, as required by <xref sectio
r n="7.6.1" sectionFormat="of" target="HTTP"/>. The Client needs to trust that the
the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none relay does not replicate the
">Oblivious Relay Resource</xref> in header fields identified by the Connection
header field if it trusts the relay to remove these as required by <xref section
="7.6.1" sectionFormat="of" target="HTTP"/>. The <iref item="Client"/><xref targ
et="dfn-client" format="none">Client</xref> needs to trust that the relay does n
ot replicate the
source addressing information in the request it forwards.</t> source addressing information in the request it forwards.</t>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients <t>Clients rely on the Oblivious Relay Resource to forward Encapsulated
</xref> rely on the <iref item="Oblivious Relay Resource"/><xref target="dfn-rel Requests
ay" format="none">Oblivious Relay Resource</xref> to forward Encapsulated Reques and Responses. However, the relay can only refuse to forward messages; it
ts cannot inspect or modify the contents of Encapsulated Requests or Responses.</t>
and responses. However, the relay can only refuse to forward messages, it
cannot inspect or modify the contents of Encapsulated Requests or responses.</t>
</section> </section>
<section anchor="relay-responsibilities"> <section anchor="relay-responsibilities">
<name>Relay Responsibilities</name> <name>Relay Responsibilities</name>
<t>The relay that serves the <iref item="Oblivious Relay Resource"/><xre <t>The relay that serves the <xref target="dfn-relay" format="none">Obli
f target="dfn-relay" format="none">Oblivious Relay Resource</xref> has a very si vious Relay Resource</xref> has a very simple function
mple function to perform. For each request it receives, it makes a request of the <xref target
to perform. For each request it receives, it makes a request of the <iref item=" ="dfn-gateway" format="none">Oblivious
Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious
Gateway Resource</xref> that includes the same content. When it receives a respo nse, Gateway Resource</xref> that includes the same content. When it receives a respo nse,
it sends a response to the <iref item="Client"/><xref target="dfn-client" format it sends a response to the <xref target="dfn-client" format="none">Client</xref>
="none">Client</xref> that includes the content of the response that includes the content of the response
from the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" for from the Oblivious Gateway Resource.</t>
mat="none">Oblivious Gateway Resource</xref>.</t>
<t>When forwarding a request, the relay <bcp14>MUST</bcp14> follow the f orwarding rules in <t>When forwarding a request, the relay <bcp14>MUST</bcp14> follow the f orwarding rules in
<xref section="7.6" sectionFormat="of" target="HTTP"/>. A generic HTTP intermed iary implementation is suitable <xref section="7.6" sectionFormat="of" target="HTTP"/>. A generic HTTP intermed iary implementation is suitable
for the purposes of serving an <iref item="Oblivious Relay Resource"/><xref targ for the purposes of serving an Oblivious Relay Resource, but additional care is
et="dfn-relay" format="none">Oblivious Relay Resource</xref>, but additional car needed to ensure that Client privacy is maintained.</t>
e is
needed to ensure that <iref item="Client"/><xref target="dfn-client" format="non
e">Client</xref> privacy is maintained.</t>
<t>Firstly, a generic implementation will forward unknown fields. For O blivious <t>Firstly, a generic implementation will forward unknown fields. For O blivious
HTTP, an <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format= HTTP, an Oblivious Relay Resource <bcp14>SHOULD NOT</bcp14> forward unknown fiel
"none">Oblivious Relay Resource</xref> <bcp14>SHOULD NOT</bcp14> forward unknown ds. Though
fields. Though Clients are not expected to include fields that might contain identifying
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> are
not expected to include fields that might contain identifying
information, removing unknown fields removes this privacy risk.</t> information, removing unknown fields removes this privacy risk.</t>
<t>Secondly, generic implementations are often configured to augment req uests with <t>Secondly, generic implementations are often configured to augment req uests with
information about the <iref item="Client"/><xref target="dfn-client" format="non e">Client</xref>, such as the Via field or the Forwarded field information about the Client, such as the Via field or the Forwarded field
<xref target="FORWARDED"/>. A relay <bcp14>MUST NOT</bcp14> add information whe n forwarding <xref target="FORWARDED"/>. A relay <bcp14>MUST NOT</bcp14> add information whe n forwarding
requests that might be used to identify <iref item="Clients"/><xref target="dfn- requests that might be used to identify Clients, except for information that
client" format="none">Clients</xref>, except for information that a Client is aware of; see <xref target="differential"/>.</t>
a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> is <t>Finally, a relay can also generate responses, though it is assumed to
aware of; see <xref target="differential"/>.</t> not be
<t>Finally, a relay can also generate responses, though it is assumed to able to examine the content of a request (other than to observe the choice of
not be able key identifier, KDF, and AEAD); therefore, it is also assumed that it cannot
to examine the content of a request (other than to observe the choice of key generate an <xref target="dfn-enc-res" format="none">Encapsulated Response</xref
identifier, KDF, and AEAD), so it is also assumed that it cannot generate an >.</t>
<iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Enc
apsulated Response</xref>.</t>
<section anchor="differential"> <section anchor="differential">
<name>Differential Treatment</name> <name>Differential Treatment</name>
<t>A relay <bcp14>MAY</bcp14> add information to requests if the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> is aware o f the nature of <t>A relay <bcp14>MAY</bcp14> add information to requests if the <xref target="dfn-client" format="none">Client</xref> is aware of the nature of
the information that could be added. Any addition <bcp14>MUST NOT</bcp14> inclu de information the information that could be added. Any addition <bcp14>MUST NOT</bcp14> inclu de information
that uniquely and permanently identifies the <iref item="Client"/><xref target=" that uniquely and permanently identifies the Client, including any pseudonymous
dfn-client" format="none">Client</xref>, including any pseudonymous identifier. identifier.
Information added by the relay - beyond what is already revealed through Information added by the relay -- beyond what is already revealed through
encapsulated requests from <iref item="Clients"/><xref target="dfn-client" forma <xref target="dfn-enc-req" format="none">Encapsulated Requests</xref> from Clien
t="none">Clients</xref> - can reduce the size of the anonymity set of ts -- can reduce the size of the anonymity set of
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> at Clients at a gateway.</t>
a gateway.</t> <t>A Client does not need to be aware of the exact value added for eac
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Clie h request
nt</xref> does not need to be aware of the exact value added for each request,
but needs to know the range of possible values the relay might use. How but needs to know the range of possible values the relay might use. How
a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> mig a Client might learn about added information is not defined in this document.</t
ht learn about added information is not defined in this document.</t> >
<t>Moreover, relays <bcp14>MAY</bcp14> apply differential treatment to <t>Moreover, relays <bcp14>MAY</bcp14> apply differential treatment to
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> th Clients that engage in
at engage in abusive abusive behavior, e.g., by sending too many requests in comparison to other
behavior, e.g., by sending too many requests in comparison to other <iref item=" Clients, or as a response to rate limits signaled from the gateway. Any such
Clients"/><xref target="dfn-client" format="none">Clients</xref>, differential treatment can reveal information to the gateway that would not be
or as a response to rate limits signalled from the gateway. Any such revealed otherwise and therefore reduce the size of the anonymity set of Clients
differential treatment can reveal information to the gateway that would not using a gateway. For example, if a relay chooses to rate limit or block an
be revealed otherwise and therefore reduce the size of the anonymity set of abusive Client, this means that any Client requests that are not treated this
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> usi way are known to be non-abusive by the gateway. Clients need to consider the
ng a gateway. For example, if a relay chooses to rate limit or likelihood of such differential treatment and the privacy risks when using a
block an abusive <iref item="Client"/><xref target="dfn-client" format="none">Cl relay.</t>
ient</xref>, this means that any <iref item="Client"/><xref target="dfn-client" <t>Some patterns of abuse cannot be detected without access to the req
format="none">Client</xref> requests which are not uest that is
treated this way are known to be non-abusive by the gateway. <iref item="Clients made to the target. This means that only the gateway or the target is in a
"/><xref target="dfn-client" format="none">Clients</xref> need to
consider the likelihood of such differential treatment and the privacy
risks when using a relay.</t>
<t>Some patterns of abuse cannot be detected without access to the req
uest that
is made to the target. This means that only the gateway or target are in a
position to identify abuse. A gateway <bcp14>MAY</bcp14> send signals toward the relay to position to identify abuse. A gateway <bcp14>MAY</bcp14> send signals toward the relay to
provide feedback about specific requests. For example, a gateway could respond provide feedback about specific requests. For example, a gateway could respond
differently to requests it cannot decapsulate, as mentioned in <xref target="err ors"/>. A differently to requests it cannot decapsulate, as mentioned in <xref target="err ors"/>. A
relay that acts on this feedback could - either inadvertently or by relay that acts on this feedback could -- either inadvertently or by design --
design - lead to <iref item="Client"/><xref target="dfn-client" format="none">Cl lead to Client deanonymization.</t>
ient</xref> deanonymization.</t>
</section> </section>
<section anchor="dos"> <section anchor="dos">
<name>Denial of Service</name> <name>Denial of Service</name>
<t>As there are privacy benefits from having a large rate of requests forwarded by <t>As there are privacy benefits from having a large rate of requests forwarded by
the same relay (see <xref target="ta"/>), servers that operate the <iref item="O the same relay (see <xref target="ta"/>), servers that operate the <xref target=
blivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious G "dfn-gateway" format="none">Oblivious Gateway Resource</xref>
ateway Resource</xref> might need an arrangement with <xref target="dfn-relay" format="none">Oblivious
might need an arrangement with <iref item="Oblivious Relay Resources"/><xref tar Relay Resources</xref>. This arrangement might
get="dfn-relay" format="none">Oblivious Relay Resources</xref>. This arrangement
might
be necessary to prevent having the large volume of requests being classified as be necessary to prevent having the large volume of requests being classified as
an attack by the server.</t> an attack by the server.</t>
<t>If a server accepts a larger volume of requests from a relay, it ne <t>If a server accepts a larger volume of requests from a relay, it ne
eds to eds to trust
trust that the relay does not allow abusive levels of request volumes from that the relay does not allow abusive levels of request volumes from
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref>. Th <xref target="dfn-client" format="none">Clients</xref>. That is, if a server all
at is, if a server allows requests from the relay to be exempt from ows requests from the relay to be exempt from
rate limits, the server might want to ensure that the relay applies a rate rate limits, the server might want to ensure that the relay applies a
limiting policy that is acceptable to the server.</t> rate-limiting policy that is acceptable to the server.</t>
<t>Servers that enter into an agreement with a relay that enables a hi gher request <t>Servers that enter into an agreement with a relay that enables a hi gher request
rate might choose to authenticate the relay to enable the higher rate.</t> rate might choose to authenticate the relay to enable the higher rate.</t>
</section> </section>
<section anchor="ta"> <section anchor="ta">
<name>Traffic Analysis</name> <name>Traffic Analysis</name>
<t>Using HTTPS protects information about which resources are the subj ect of <t>Using HTTPS protects information about which resources are the subj ect of
request and prevents a network observer from being able to trivially correlate request and prevents a network observer from being able to trivially correlate
messages on either side of a relay. However, using HTTPS does not prevent messages on either side of a relay. However, using HTTPS does not prevent
traffic analysis by such network observers.</t> traffic analysis by such network observers.</t>
<t>The time at which <iref item="Encapsulated Request"/><xref target=" dfn-enc-req" format="none">Encapsulated Request</xref> or response messages are sent can <t>The time at which Encapsulated Request or Response messages are sen t can
reveal information to a network observer. Though messages exchanged between the reveal information to a network observer. Though messages exchanged between the
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob livious Relay Resource</xref> and the <iref item="Oblivious Gateway Resource"/>< xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> might be sent in a <xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> and the < xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> might be sent in a
single connection, traffic analysis could be used to match messages that are single connection, traffic analysis could be used to match messages that are
forwarded by the relay.</t> forwarded by the relay.</t>
<t>A relay could, as part of its function, delay requests before forwa rding them. <t>A relay could, as part of its function, delay requests before forwa rding them.
Delays might increase the anonymity set into which each request is Delays might increase the anonymity set into which each request is
attributed. Any delay also increases the time that a <iref item="Client"/><xref attributed. Any delay also increases the time that a <xref target="dfn-client" f
target="dfn-client" format="none">Client</xref> waits for a ormat="none">Client</xref> waits for a
response, so delays <bcp14>SHOULD</bcp14> only be added with the consent - or at response, so delays <bcp14>SHOULD</bcp14> only be added with the consent -- or a
least t least
awareness - of <iref item="Clients"/><xref target="dfn-client" format="none">Cli awareness -- of Clients.</t>
ents</xref>.</t>
<t>A relay that forwards large volumes of exchanges can provide better privacy by <t>A relay that forwards large volumes of exchanges can provide better privacy by
providing larger sets of messages that need to be matched.</t> providing larger sets of messages that need to be matched.</t>
<t>Traffic analysis is not restricted to network observers. A maliciou s <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none"> Oblivious Relay Resource</xref> could <t>Traffic analysis is not restricted to network observers. A maliciou s Oblivious Relay Resource could
use traffic analysis to learn information about otherwise encrypted requests use traffic analysis to learn information about otherwise encrypted requests
and responses relayed between <iref item="Clients"/><xref target="dfn-client" fo and responses relayed between Clients and gateways. An Oblivious Relay Resource
rmat="none">Clients</xref> and gateways. An <iref item="Oblivious Relay Resource terminates
"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> termin TLS connections from Clients, so they see message boundaries. This privileged
ates
TLS connections from <iref item="Clients"/><xref target="dfn-client" format="non
e">Clients</xref>, so they see message boundaries. This privileged
position allows for richer feature extraction from encrypted data, which might position allows for richer feature extraction from encrypted data, which might
improve traffic analysis.</t> improve traffic analysis.</t>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clien ts</xref> and <iref item="Oblivious Gateway Resources"/><xref target="dfn-gatewa y" format="none">Oblivious Gateway Resources</xref> can use padding to reduce th e <t>Clients and Oblivious Gateway Resources can use padding to reduce t he
effectiveness of traffic analysis. Padding is a capability provided by binary effectiveness of traffic analysis. Padding is a capability provided by binary
HTTP messages; see <xref section="3.8" sectionFormat="of" target="BINARY"/>. If the encapsulation method HTTP messages; see <xref section="3.8" sectionFormat="of" target="BINARY"/>. If the encapsulation method
described in this document is used to protect a different message type (see described in this document is used to protect a different message type (see
<xref target="repurposing"/>), that message format might need to include padding support. <xref target="repurposing"/>), that message format might need to include padding support.
<iref item="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">O Oblivious Relay Resources can also use padding for the same reason but need to
blivious Relay Resources</xref> can also use padding for the same reason, but ne operate at the HTTP layer since they cannot manipulate binary HTTP messages; for
ed to example, see <xref section="10.7" sectionFormat="of" target="HTTP2"/> or <xref s
operate at the HTTP layer since they cannot manipulate binary HTTP messages; for ection="10.7" sectionFormat="of" target="HTTP3"/>).</t>
example,
see <xref section="10.7" sectionFormat="of" target="HTTP2"/> or <xref section="1
0.7" sectionFormat="of" target="HTTP3"/>).</t>
</section> </section>
</section> </section>
<section anchor="server-responsibilities"> <section anchor="server-responsibilities">
<name>Server Responsibilities</name> <name>Server Responsibilities</name>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatewa <t>The <xref target="dfn-gateway" format="none">Oblivious Gateway Resour
y" format="none">Oblivious Gateway Resource</xref> can be operated by a differen ce</xref> can be operated by a different entity than the
t entity than the <xref target="dfn-target" format="none">Target Resource</xref>. However, this m
<iref item="Target Resource"/><xref target="dfn-target" format="none">Target Res eans that the <xref target="dfn-client" format="none">Client</xref> needs to tru
ource</xref>. However, this means that the <iref item="Client"/><xref target="d st the
fn-client" format="none">Client</xref> needs to trust the Oblivious Gateway Resource not to modify requests or responses. This analysis
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none
">Oblivious Gateway Resource</xref> not to modify requests or responses. This a
nalysis
concerns itself with a deployment scenario where a single server provides both concerns itself with a deployment scenario where a single server provides both
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format=" none">Oblivious Gateway Resource</xref> and <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>.</t> the Oblivious Gateway Resource and Target Resource.</t>
<t>A server that operates both Oblivious Gateway and Target Resources is <t>A server that operates both Oblivious Gateway and Target Resources is
responsible for removing request encryption, generating a response to the responsible for removing request encryption, generating a response to the
<iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca psulated Request</xref>, and encrypting the response.</t> <xref target="dfn-enc-req" format="none">Encapsulated Request</xref>, and encryp ting the response.</t>
<t>Servers should account for traffic analysis based on response size or generation <t>Servers should account for traffic analysis based on response size or generation
time. Techniques such as padding or timing delays can help protect against such time. Techniques such as padding or timing delays can help protect against such
attacks; see <xref target="ta"/>.</t> attacks; see <xref target="ta"/>.</t>
<t>If separate entities provide the <iref item="Oblivious Gateway Resour ce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> and <iref item="Target Resource"/><xref target="dfn-target" format="none">Target Resource</xref>, <t>If separate entities provide the Oblivious Gateway Resource and Targe t Resource,
these entities might need an arrangement similar to that between server and these entities might need an arrangement similar to that between server and
relay for managing denial of service; see <xref target="dos"/>. Moreover, the <i relay for managing denial of service; see <xref target="dos"/>. Moreover, the Ob
ref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none"> livious
Oblivious Gateway Resource <bcp14>SHOULD</bcp14> have some mechanism to ensure that the Ob
Gateway Resource</xref> <bcp14>SHOULD</bcp14> have some mechanism to ensure that livious Gateway
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format= Resource is not misused as a relay for HTTP messages to an arbitrary Target
"none">Oblivious Gateway Resource, such as an allowlist.</t>
Resource</xref> is not misused as a relay for HTTP messages to an arbitrary <ire <t>Non-secure requests -- such as those with the "http" scheme as oppose
f item="Target Resource"/><xref target="dfn-target" format="none">Target d to the
Resource</xref>, such as an allowlist.</t> "https" scheme -- <bcp14>SHOULD NOT</bcp14> be used if the Oblivious Gateway and
<t>Non-secure requests - such as those with the "http" scheme as opposed Target
to the
"https" scheme - <bcp14>SHOULD NOT</bcp14> be used if the Oblivious Gateway and
Target
Resources are not on the same origin. If messages are forwarded between these Resources are not on the same origin. If messages are forwarded between these
resources without the protections afforded by HTTPS, they could be inspected or resources without the protections afforded by HTTPS, they could be inspected or
modified by a network attacker. Note that a request could be forwarded without modified by a network attacker. Note that a request could be forwarded without
protection if the two resources share an origin.</t> protection if the two resources share an origin.</t>
</section> </section>
<section anchor="key-management"> <section anchor="key-management">
<name>Key Management</name> <name>Key Management</name>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway " format="none">Oblivious Gateway Resource</xref> needs to have a plan for repla cing keys. This <t>An <xref target="dfn-gateway" format="none">Oblivious Gateway Resourc e</xref> needs to have a plan for replacing keys. This
might include regular replacement of keys, which can be assigned new key might include regular replacement of keys, which can be assigned new key
identifiers. If an <iref item="Oblivious Gateway Resource"/><xref target="dfn-ga teway" format="none">Oblivious Gateway Resource</xref> receives a request that c ontains a identifiers. If an Oblivious Gateway Resource receives a request that contains a
key identifier that it does not understand or that corresponds to a key that has key identifier that it does not understand or that corresponds to a key that has
been replaced, the server can respond with an HTTP 422 (Unprocessable Content) been replaced, the server can respond with an HTTP 422 (Unprocessable Content)
status code.</t> status code.</t>
<t>A server can also use a 422 status code if the server has a key that corresponds <t>A server can also use a 422 status code if the server has a key that corresponds
to the key identifier, but the <iref item="Encapsulated Request"/><xref target=" dfn-enc-req" format="none">Encapsulated Request</xref> cannot be successfully to the key identifier, but the <xref target="dfn-enc-req" format="none">Encapsul ated Request</xref> cannot be successfully
decrypted using the key.</t> decrypted using the key.</t>
<t>A server <bcp14>MUST</bcp14> ensure that the HPKE keys it uses are no t valid for any other <t>A server <bcp14>MUST</bcp14> ensure that the HPKE keys it uses are no t valid for any other
protocol that uses HPKE with the "message/bhttp request" label. Designers of protocol that uses HPKE with the "message/bhttp request" label. Designers of
protocols that reuse this encryption format, especially new versions of this protocols that reuse this encryption format, especially new versions of this
protocol, can ensure key diversity by choosing a different label in their use of protocol, can ensure key diversity by choosing a different label in their use of
HPKE. The "message/bhttp response" label was chosen for symmetry only as it HPKE. The "message/bhttp response" label was chosen for symmetry only as it
provides key diversity only within the HPKE context created using the provides key diversity only within the HPKE context created using the
"message/bhttp request" label; see <xref target="repurposing"/>.</t> "message/bhttp request" label; see <xref target="repurposing"/>.</t>
</section> </section>
<section anchor="replay"> <section anchor="replay">
<name>Replay Attacks</name> <name>Replay Attacks</name>
<t>A server is responsible for either rejecting replayed requests or ens uring that <t>A server is responsible for either rejecting replayed requests or ens uring that
the effect of replays does not adversely affect <iref item="Clients"/><xref targ the effect of replays does not adversely affect <xref target="dfn-client" format
et="dfn-client" format="none">Clients</xref> or resources.</t> ="none">Clients</xref> or resources.</t>
<t>Encrypted requests can be copied and replayed by the Oblivious Relay <t><xref target="dfn-enc-req" format="none">Encapsulated Requests</xref>
resource. The threat model for Oblivious HTTP allows the possibility that an can be copied and replayed by the <xref target="dfn-relay" format="none">Oblivi
<iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Ob ous Relay
livious Relay Resource</xref> might replay requests. Furthermore, if a <iref ite Resource</xref>. The threat model for Oblivious HTTP allows the possibility that
m="Client"/><xref target="dfn-client" format="none">Client</xref> sends an
an <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">E Oblivious Relay Resource might replay requests. Furthermore, if a Client sends
ncapsulated Request</xref> in TLS early data (see <xref section="8" sectionForma an Encapsulated Request in TLS early data (see <xref section="8" sectionFormat="
t="of" target="TLS"/> and of" target="TLS"/> and
<xref target="RFC8470"/>), a network-based adversary might be able to cause the request to <xref target="RFC8470"/>), a network-based adversary might be able to cause the request to
be replayed. In both cases, the effect of a replay attack and the mitigations be replayed. In both cases, the effect of a replay attack and the mitigations
that might be employed are similar to TLS early data.</t> that might be employed are similar to TLS early data.</t>
<t>It is the responsibility of the application that uses Oblivious HTTP to either <t>It is the responsibility of the application that uses Oblivious HTTP to either
reject replayed requests or to ensure that replayed requests have no adverse reject replayed requests or ensure that replayed requests have no adverse
effects on their operation. This section describes some approaches that are effect on their operation. This section describes some approaches that are
universally applicable and suggestions for more targeted techniques.</t> universally applicable and suggestions for more targeted techniques.</t>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client </xref> or <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" forma t="none">Oblivious Relay Resource</xref> <bcp14>MUST NOT</bcp14> automatically a ttempt to retry a <t>A Client or Oblivious Relay Resource <bcp14>MUST NOT</bcp14> automati cally attempt to retry a
failed request unless it receives a positive signal indicating that the request failed request unless it receives a positive signal indicating that the request
was not processed or forwarded. The HTTP/2 REFUSED_STREAM error code (<xref sect ion="8.1.4" sectionFormat="of" target="HTTP2"/>), the HTTP/3 H3_REQUEST_REJECTED error code (<xref section="8.1" sectionFormat="of" target="HTTP3"/>), or a GOAW AY frame with a low enough identifier (in either protocol was not processed or forwarded. The HTTP/2 REFUSED_STREAM error code (<xref sect ion="8.1.4" sectionFormat="of" target="HTTP2"/>), the HTTP/3 H3_REQUEST_REJECTED error code (<xref section="8.1" sectionFormat="of" target="HTTP3"/>), or a GOAW AY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred. HTTP/1.1 version) are all sufficient signals that no processing occurred. HTTP/1.1
<xref target="HTTP11"/> provides no equivalent signal. Connection failures or i nterruptions <xref target="HTTP11"/> provides no equivalent signal. Connection failures or i nterruptions
are not sufficient signals that no processing occurred.</t> are not sufficient signals that no processing occurred.</t>
<t>The anti-replay mechanisms described in <xref section="8" sectionForm at="of" target="TLS"/> are generally <t>The anti-replay mechanisms described in <xref section="8" sectionForm at="of" target="TLS"/> are generally
applicable to Oblivious HTTP requests. The encapsulated keying material (or applicable to Oblivious HTTP requests. The encapsulated keying material (or
<tt>enc</tt>) can be used in place of a nonce to uniquely identify a request. T his <tt>enc</tt>) can be used in place of a nonce to uniquely identify a request. T his
value is a high-entropy value that is freshly generated for every request, so value is a high-entropy value that is freshly generated for every request, so
two valid requests will have different values with overwhelming probability.</t> two valid requests will have different values with overwhelming probability.</t>
<t>The mechanism used in TLS for managing differences in <iref item="Cli ent"/><xref target="dfn-client" format="none">Client</xref> and server clocks <t>The mechanism used in TLS for managing differences in Client and serv er clocks
cannot be used as it depends on being able to observe previous interactions. cannot be used as it depends on being able to observe previous interactions.
Oblivious HTTP explicitly prevents such linkability.</t> Oblivious HTTP explicitly prevents such linkability.</t>
<t>The considerations in <xref target="RFC8470"/> as they relate to mana ging the risk of <t>The considerations in <xref target="RFC8470"/> as they relate to mana ging the risk of
replay also apply, though there is no option to delay the processing of a replay also apply, though there is no option to delay the processing of a
request.</t> request.</t>
<t>Limiting requests to those with safe methods might not be satisfactor y for some <t>Limiting requests to those with safe methods might not be satisfactor y for some
applications, particularly those that involve the submission of data to a applications, particularly those that involve the submission of data to a
server. The use of idempotent methods might be of some use in managing replay server. The use of idempotent methods might be of some use in managing replay
risk, though it is important to recognize that different idempotent requests risk, though it is important to recognize that different idempotent requests
can be combined to be not idempotent.</t> can be combined to be not idempotent.</t>
<t>Even without replay prevention, the server-chosen <tt>response_nonce< /tt> field <t>Even without replay prevention, the server-chosen <tt>response_nonce< /tt> field
ensures that responses have unique AEAD keys and nonces even when requests are ensures that responses have unique AEAD keys and nonces even when requests are
replayed.</t> replayed.</t>
<section anchor="use-of-date-for-anti-replay"> <section anchor="use-of-date-for-anti-replay">
<name>Use of Date for Anti-Replay</name> <name>Use of Date for Anti-replay</name>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clien <t><xref target="dfn-client" format="none">Clients</xref> <bcp14>SHOUL
ts</xref> <bcp14>SHOULD</bcp14> include a <tt>Date</tt> header field in Encapsul D</bcp14> include a <tt>Date</tt> header field in <xref target="dfn-enc-req" for
ated Requests, unless mat="none">Encapsulated Requests</xref>, unless
the <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> h the Client has prior knowledge that indicates that the <xref target="dfn-gateway
as prior knowledge that indicates that the <iref item="Oblivious Gateway Resourc " format="none">Oblivious Gateway
e"/><xref target="dfn-gateway" format="none">Oblivious Gateway
Resource</xref> does not use <tt>Date</tt> for anti-replay purposes.</t> Resource</xref> does not use <tt>Date</tt> for anti-replay purposes.</t>
<t>Though HTTP requests often do not include a <tt>Date</tt> header fi eld, the value of <t>Though HTTP requests often do not include a <tt>Date</tt> header fi eld, the value of
this field might be used by a server to limit the amount of requests it needs to this field might be used by a server to limit the amount of requests it needs to
track if it needs to prevent replay attacks.</t> track if it needs to prevent replay attacks.</t>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatew <t>An Oblivious Gateway Resource can maintain state for requests for a
ay" format="none">Oblivious Gateway Resource</xref> can maintain state for reque small window
sts for a small window of time over which it wishes to accept requests. The Oblivious Gateway Resource
of time over which it wishes to accept requests. The <iref item="Oblivious Gate
way Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resour
ce</xref>
can store all requests it processes within this window. Storing just the <tt>en c</tt> can store all requests it processes within this window. Storing just the <tt>en c</tt>
field of a request, which should be unique to each request, is sufficient. The field of a request, which should be unique to each request, is sufficient. The
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none ">Oblivious Gateway Resource</xref> can reject any request that is the same as o ne that Oblivious Gateway Resource can reject any request that is the same as one that
was previously answered within that time window or if the <tt>Date</tt> header f ield was previously answered within that time window or if the <tt>Date</tt> header f ield
from the decrypted request is outside of the current time window.</t> from the decrypted request is outside of the current time window.</t>
<t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway <t>Oblivious Gateway Resources might need to allow for the time it tak
" format="none">Oblivious Gateway Resources</xref> might need to allow for the t es requests
ime it takes requests to arrive from the Client, with a time window that is large enough to allow for
to arrive from the <iref item="Client"/><xref target="dfn-client" format="none">
Client</xref>, with a time window that is large enough to allow for
differences in clocks. Insufficient tolerance of time differences could result differences in clocks. Insufficient tolerance of time differences could result
in valid requests being unnecessarily rejected. Beyond allowing for multiple in valid requests being unnecessarily rejected. Beyond allowing for multiple
round trip times -- to account for retransmission -- network delays are unlikely round-trip times -- to account for retransmission -- network delays are unlikely
to be significant in determining the size of the window, unless all potential to be significant in determining the size of the window, unless all potential
<iref item="Clients"/><xref target="dfn-client" format="none">Clients</xref> are known to have excellent time-keeping. A specific window size might Clients are known to have excellent timekeeping. A specific window size might
need to be determined experimentally.</t> need to be determined experimentally.</t>
<t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway " format="none">Oblivious Gateway Resources</xref> <bcp14>MUST NOT</bcp14> treat the time window as secret <t>Oblivious Gateway Resources <bcp14>MUST NOT</bcp14> treat the time window as secret
information. An attacker can actively probe with different values for the <tt>Da te</tt> information. An attacker can actively probe with different values for the <tt>Da te</tt>
field to determine the time window over which the server will accept responses.< /t> field to determine the time window over which the server will accept responses.< /t>
</section> </section>
<section anchor="date-fix"> <section anchor="date-fix">
<name>Correcting Clock Differences</name> <name>Correcting Clock Differences</name>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatew ay" format="none">Oblivious Gateway Resource</xref> can reject requests that con tain a <tt>Date</tt> value <t>An <xref target="dfn-gateway" format="none">Oblivious Gateway Resou rce</xref> can reject requests that contain a <tt>Date</tt> value
that is outside of its active window with a 400 series status code. The problem that is outside of its active window with a 400 series status code. The problem
type <xref target="PROBLEM"/> of type <xref target="PROBLEM"/> of
"https://iana.org/assignments/http-problem-types#date" is defined to allow the "https://iana.org/assignments/http-problem-types#date" is defined to allow the
server to signal that the <tt>Date</tt> value in the request was unacceptable.</ t> server to signal that the <tt>Date</tt> value in the request was unacceptable.</ t>
<t><xref target="fig-date-reject"/> shows an example response in HTTP/ 1.1 format.</t> <t><xref target="fig-date-reject"/> shows an example response in HTTP/ 1.1 format.</t>
<figure anchor="fig-date-reject"> <figure anchor="fig-date-reject">
<name>Example Rejection of Request Date Field</name> <name>Example Rejection of Request Date Field</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json Content-Type: application/problem+json
Content-Length: 128 Content-Length: 128
{"type":"https://iana.org/assignments/http-problem-types#date", {"type":"https://iana.org/assignments/http-problem-types#date",
"title": "date field in request outside of acceptable range"} "title": "date field in request outside of acceptable range"}
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>Disagreements about time are unlikely if both <iref item="Client"/> <t>Disagreements about time are unlikely if both <xref target="dfn-cli
<xref target="dfn-client" format="none">Client</xref> and <iref item="Oblivious ent" format="none">Client</xref> and Oblivious Gateway
Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource have a good source of time; see <xref target="NTP"/>. However, clock
Resource</xref> have a good source of time; see <xref target="NTP"/>. However, c
lock
differences are known to be commonplace; see Section 7.1 of differences are known to be commonplace; see Section 7.1 of
<xref target="CLOCKSKEW"/>.</t> <xref target="CLOCKSKEW"/>.</t>
<t>Including a <tt>Date</tt> header field in the response allows the < iref item="Client"/><xref target="dfn-client" format="none">Client</xref> to cor rect <t>Including a <tt>Date</tt> header field in the response allows the C lient to correct
clock errors by retrying the same request using the value of the <tt>Date</tt> f ield clock errors by retrying the same request using the value of the <tt>Date</tt> f ield
provided by the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gatew ay" format="none">Oblivious Gateway Resource</xref>. The value of the <tt>Date< /tt> field can provided by the Oblivious Gateway Resource. The value of the <tt>Date</tt> fiel d can
be copied if the response is fresh, with an adjustment based on the <tt>Age</tt> field be copied if the response is fresh, with an adjustment based on the <tt>Age</tt> field
otherwise; see <xref section="4.2" sectionFormat="of" target="HTTP-CACHING"/>. When retrying a request, the otherwise; see <xref section="4.2" sectionFormat="of" target="HTTP-CACHING"/>. When retrying a request, the
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref> <bcp1 4>MUST</bcp14> create a fresh encryption of the modified request, using a new HP KE Client <bcp14>MUST</bcp14> create a fresh encryption of the modified request, us ing a new HPKE
context.</t> context.</t>
<figure anchor="fig-retry-date"> <figure anchor="fig-retry-date">
<name>Retrying with an Updated Date Field</name> <name>Retrying with an Updated Date Field</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="304" width="464" viewBox="0 0 464 304" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="304" width="464" viewBox="0 0 464 304" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px">
<path d="M 8,32 L 8,80" fill="none" stroke="black"/> <path d="M 8,32 L 8,80" fill="none" stroke="black"/>
<path d="M 48,80 L 48,288" fill="none" stroke="black"/> <path d="M 48,80 L 48,288" fill="none" stroke="black"/>
<path d="M 88,32 L 88,80" fill="none" stroke="black"/> <path d="M 88,32 L 88,80" fill="none" stroke="black"/>
<path d="M 152,32 L 152,80" fill="none" stroke="black"/> <path d="M 152,32 L 152,80" fill="none" stroke="black"/>
<path d="M 192,80 L 192,128" fill="none" stroke="black"/> <path d="M 192,80 L 192,128" fill="none" stroke="black"/>
skipping to change at line 1236 skipping to change at line 1341
| | | + Date | | | | + Date |
|<============================+<-------------+ |<============================+<-------------+
| | | | | | | |
| Request | | | | Request | | |
| + Updated Date | | | | + Updated Date | | |
+============================>+------------->| +============================>+------------->|
| | | | | | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Retrying immediately allows the <iref item="Oblivious Gateway Resou <t>Retrying immediately allows the <xref target="dfn-gateway" format="
rce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> none">Oblivious Gateway Resource</xref> to measure the
to measure the round round-trip time to the <xref target="dfn-client" format="none">Client</xref>. Th
trip time to the <iref item="Client"/><xref target="dfn-client" format="none">Cl e observed delay might reveal something about
ient</xref>. The observed delay might reveal something about the the location of the Client. Clients could delay retries to add some uncertainty
location of the <iref item="Client"/><xref target="dfn-client" format="none">Cli to any observed delay.</t>
ent</xref>. <iref item="Clients"/><xref target="dfn-client" format="none">Clien
ts</xref> could delay retries to add some uncertainty to
any observed delay.</t>
<t>Intermediaries can sometimes rewrite the <tt>Date</tt> field when f orwarding responses. <t>Intermediaries can sometimes rewrite the <tt>Date</tt> field when f orwarding responses.
This might cause problems if the <iref item="Oblivious Gateway Resource"/><xref This might cause problems if the Oblivious Gateway Resource and intermediary
target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> and interme clocks differ by enough to cause the retry to be rejected. Therefore, Clients
diary
clocks differ by enough to cause the retry to be rejected. Therefore, <iref ite
m="Clients"/><xref target="dfn-client" format="none">Clients</xref>
<bcp14>MUST NOT</bcp14> retry a request with an adjusted date more t han once.</t> <bcp14>MUST NOT</bcp14> retry a request with an adjusted date more t han once.</t>
<t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway " format="none">Oblivious Gateway Resources</xref> that condition their response s on the <tt>Date</tt> header <t>Oblivious Gateway Resources that condition their responses on the < tt>Date</tt> header
field <bcp14>SHOULD</bcp14> either ensure that intermediaries do not cache respo nses (by field <bcp14>SHOULD</bcp14> either ensure that intermediaries do not cache respo nses (by
including a <tt>Cache-Control</tt> directive of <tt>no-store</tt>) or designate the response including a <tt>Cache-Control</tt> directive of <tt>no-store</tt>) or designate the response
as conditional on the value of the <tt>Date</tt> request header field (by includ ing the as conditional on the value of the <tt>Date</tt> request header field (by includ ing the
token "date" in a <tt>Vary</tt> header field).</t> token "date" in a <tt>Vary</tt> header field).</t>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clien ts</xref> <bcp14>MUST NOT</bcp14> use the date provided by the <iref item="Obliv ious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gatew ay Resource</xref> for any <t>Clients <bcp14>MUST NOT</bcp14> use the date provided by the Oblivi ous Gateway Resource for any
other purpose, including future requests to any resource. Any request that uses other purpose, including future requests to any resource. Any request that uses
information provided by the <iref item="Oblivious Gateway Resource"/><xref targe t="dfn-gateway" format="none">Oblivious Gateway Resource</xref> might be correla ted using information provided by the Oblivious Gateway Resource might be correlated using
that information.</t> that information.</t>
</section> </section>
</section> </section>
<section anchor="forward-secrecy"> <section anchor="forward-secrecy">
<name>Forward Secrecy</name> <name>Forward Secrecy</name>
<t>This document does not provide forward secrecy for either requests or <t>This document does not provide forward secrecy for either requests or
responses during the lifetime of the <iref item="key configuration"/><xref targe responses during the lifetime of the <xref target="key-configuration" format="no
t="key-configuration" format="none">key configuration</xref>. A measure of ne">key configuration</xref>. A measure of
forward secrecy can be provided by generating a new <iref item="key configuratio forward secrecy can be provided by generating a new key configuration
n"/><xref target="key-configuration" format="none">key configuration</xref>
then deleting the old keys after a suitable period.</t> then deleting the old keys after a suitable period.</t>
</section> </section>
<section anchor="post-compromise-security"> <section anchor="post-compromise-security">
<name>Post-Compromise Security</name> <name>Post-Compromise Security</name>
<t>This design does not provide post-compromise security for responses.< /t> <t>This design does not provide post-compromise security for responses.< /t>
<t>A <iref item="Client"/><xref target="dfn-client" format="none">Client </xref> only needs to retain keying material that might be used to compromise <t>A <xref target="dfn-client" format="none">Client</xref> only needs to retain keying material that might be used to compromise
the confidentiality and integrity of a response until that response is consumed, the confidentiality and integrity of a response until that response is consumed,
so there is negligible risk associated with a <iref item="Client"/><xref target= "dfn-client" format="none">Client</xref> compromise.</t> so there is negligible risk associated with a Client compromise.</t>
<t>A server retains a secret key that might be used to remove protection from <t>A server retains a secret key that might be used to remove protection from
messages over much longer periods. A server compromise that provided access to messages over much longer periods. A server compromise that provided access to
the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format=" none">Oblivious Gateway Resource</xref> secret key could allow an attacker to re cover the the <xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> s ecret key could allow an attacker to recover the
plaintext of all requests sent toward affected keys and all of the responses plaintext of all requests sent toward affected keys and all of the responses
that were generated.</t> that were generated.</t>
<t>Even if server keys are compromised, an adversary cannot access messa ges <t>Even if server keys are compromised, an adversary cannot access messa ges
exchanged by the <iref item="Client"/><xref target="dfn-client" format="none">Cl exchanged by the Client with the <xref target="dfn-relay" format="none">Obliviou
ient</xref> with the <iref item="Oblivious Relay Resource"/><xref target="dfn-re s Relay Resource</xref> as messages are
lay" format="none">Oblivious Relay Resource</xref> as messages are protected by TLS. Use of a compromised key also requires that the Oblivious
protected by TLS. Use of a compromised key also requires that the <iref item="O Relay Resource cooperate with the attacker or that the attacker is able to
blivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious
Relay Resource</xref> cooperate with the attacker or that the attacker is able t
o
compromise these TLS connections.</t> compromise these TLS connections.</t>
<t>The total number of messages affected by server key compromise can be limited by <t>The total number of messages affected by server key compromise can be limited by
regular rotation of server keys.</t> regular rotation of server keys.</t>
</section> </section>
<section anchor="client-clock-exposure"> <section anchor="client-clock-exposure">
<name>Client Clock Exposure</name> <name>Client Clock Exposure</name>
<t>Including a <tt>Date</tt> field in requests reveals some information <t>Including a <tt>Date</tt> field in requests reveals some information
about the <iref item="Client"/><xref target="dfn-client" format="none">Client</x about the <xref target="dfn-client" format="none">Client</xref>
ref> clock. This might be used to fingerprint Clients <xref target="UWT"/> or to ide
clock. This might be used to fingerprint <iref item="Clients"/><xref target="df ntify Clients
n-client" format="none">Clients</xref> <xref target="UWT"/> or to identify <iref
item="Clients"/><xref target="dfn-client" format="none">Clients</xref>
that are vulnerable to attacks that depend on incorrect clocks.</t> that are vulnerable to attacks that depend on incorrect clocks.</t>
<t><iref item="Clients"/><xref target="dfn-client" format="none">Clients <t>Clients can randomize the value that they provide for <tt>Date</tt> t
</xref> can randomize the value that they provide for <tt>Date</tt> to obscure t o obscure the true
he true value of their clock and reduce the chance of linking requests over time.
value of their clock and reduce the chance of linking of requests over time.
However, this increases the risk that their request is rejected as outside the However, this increases the risk that their request is rejected as outside the
acceptable window.</t> acceptable window.</t>
</section> </section>
<section anchor="sec-media"> <section anchor="sec-media">
<name>Media Type Security</name> <name>Media Type Security</name>
<t>The <iref item="key configuration"/><xref target="key-configuration" <t>The <xref target="key-configuration" format="none">key configuration<
format="none">key configuration</xref> media type defined in <xref target="ohttp /xref> media type defined in <xref target="ohttp-keys"/> represents keying
-keys"/> represents keying material. The content of this media type is not active (see <xref section="4.6"
material. The content of this media type is not active (see <xref section="4.6" sectionFormat="of" target="RFC6838"/>), but it governs how a <xref target="dfn-
sectionFormat="of" target="RFC6838"/>), but it governs how a <iref item="Client client" format="none">Client</xref> might interact with an <xref target="dfn-gat
"/><xref target="dfn-client" format="none">Client</xref> might interact with an eway" format="none">Oblivious Gateway
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none
">Oblivious Gateway
Resource</xref>. The security implications of processing it are described in Resource</xref>. The security implications of processing it are described in
<xref target="sec-client"/>; privacy implications are described in <xref target= "privacy"/>.</t> <xref target="sec-client"/>; privacy implications are described in <xref target= "privacy"/>.</t>
<t>The security implications of handling the message media types defined in <t>The security implications of handling the message media types defined in
<xref target="req-res-media"/> is covered in other parts of this section in more detail. <xref target="req-res-media"/> is covered in other parts of this section in more detail.
However, these message media types are also encrypted encapsulations of HTTP However, these message media types are also encrypted encapsulations of HTTP
requests and responses.</t> requests and responses.</t>
<t>HTTP messages contain content, which can use any media type. In part icular, <t>HTTP messages contain content, which can use any media type. In part icular,
requests are processed by an Oblivious <iref item="Target Resource"/><xref targe requests are processed by an Oblivious <xref target="dfn-target" format="none">T
t="dfn-target" format="none">Target Resource</xref>, which - as an HTTP arget Resource</xref>, which -- as an HTTP
resource - defines how content is processed; see <xref section="3.1" sectionForm resource -- defines how content is processed; see <xref section="3.1" sectionFor
at="of" target="HTTP"/>. HTTP mat="of" target="HTTP"/>. HTTP
clients can also use resource identity and response content to determine how clients can also use resource identity and response content to determine how
content is processed. Consequently, the security considerations of <xref sectio n="17" sectionFormat="of" target="HTTP"/> also apply to the handling of the cont ent of these media types.</t> content is processed. Consequently, the security considerations of <xref sectio n="17" sectionFormat="of" target="HTTP"/> also apply to the handling of the cont ent of these media types.</t>
</section> </section>
<section anchor="separate-target"> <section anchor="separate-target">
<name>Separate Gateway and Target</name> <name>Separate Gateway and Target</name>
<t>This document generally assumes that the same entity operates the <ir <t>This document generally assumes that the same entity operates the <xr
ef item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">O ef target="dfn-gateway" format="none">Oblivious
blivious Gateway Resource</xref> and the <xref target="dfn-target" format="none">Target R
Gateway Resource</xref> and the <iref item="Target Resource"/><xref target="dfn- esource</xref>. However, as the Oblivious Gateway
target" format="none">Target Resource</xref>. However, as the <iref item="Obliv Resource performs generic HTTP processing, the use of forwarding cannot be
ious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gatew
ay
Resource</xref> performs generic HTTP processing, the use of forwarding cannot b
e
completely precluded.</t> completely precluded.</t>
<t>The scheme specified in the <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</xref> determines the se curity <t>The scheme specified in the <xref target="dfn-enc-req" format="none"> Encapsulated Request</xref> determines the security
requirements for any protocol that is used between the Oblivious Gateway and requirements for any protocol that is used between the Oblivious Gateway and
Target Resources. Using HTTPS is <bcp14>RECOMMENDED</bcp14>; see <xref target=" server-responsibilities"/>.</t> Target Resources. Using HTTPS is <bcp14>RECOMMENDED</bcp14>; see <xref target=" server-responsibilities"/>.</t>
<t>A <iref item="Target Resource"/><xref target="dfn-target" format="non <t>A Target Resource that is operated on a different server from the Obl
e">Target Resource</xref> that is operated on a different server from the <iref ivious
item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Obli Gateway Resource is an ordinary HTTP resource. A Target Resource can privilege
vious requests that are forwarded by a given Oblivious Gateway Resource if it trusts
Gateway Resource</xref> is an ordinary HTTP resource. A <iref item="Target Reso the operator of the Oblivious Gateway Resource to only forward requests that
urce"/><xref target="dfn-target" format="none">Target Resource</xref> can privil meet the expectations of the Target Resource. Otherwise, the Target Resource
ege treats requests from an Oblivious Gateway Resource no differently than any
requests that are forwarded by a given <iref item="Oblivious Gateway Resource"/>
<xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> if it
trusts
the operator of the <iref item="Oblivious Gateway Resource"/><xref target="dfn-g
ateway" format="none">Oblivious Gateway Resource</xref> to only forward requests
that
meet the expectations of the <iref item="Target Resource"/><xref target="dfn-tar
get" format="none">Target Resource</xref>. Otherwise, the <iref item="Target Re
source"/><xref target="dfn-target" format="none">Target Resource</xref>
treats requests from an <iref item="Oblivious Gateway Resource"/><xref target="d
fn-gateway" format="none">Oblivious Gateway Resource</xref> no differently than
any
other HTTP client.</t> other HTTP client.</t>
<t>For instance, an <iref item="Oblivious Gateway Resource"/><xref targe <t>For instance, an Oblivious Gateway Resource might -- possibly with th
t="dfn-gateway" format="none">Oblivious Gateway Resource</xref> might -- possibl e help of
y with the help of <xref target="dfn-relay" format="none">Oblivious Relay Resources</xref> -- be tr
<iref item="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">O usted not to forward an excessive volume of
blivious Relay Resources</xref> -- be trusted not to forward an excessive volume requests. This might allow the Target Resource to accept a greater volume of
of requests from that Oblivious Gateway Resource relative to other HTTP clients.</t
requests. This might allow the <iref item="Target Resource"/><xref target="dfn-t >
arget" format="none">Target Resource</xref> to accept a greater volume of <t>An Oblivious Gateway Resource could implement policies that improve t
requests from that <iref item="Oblivious Gateway Resource"/><xref target="dfn-ga he ability
teway" format="none">Oblivious Gateway Resource</xref> relative to other HTTP cl of the Target Resource to implement policy exemptions, such as only forwarding
ients.</t>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway
" format="none">Oblivious Gateway Resource</xref> could implement policies that
improve the ability
of the <iref item="Target Resource"/><xref target="dfn-target" format="none">Tar
get Resource</xref> to implement policy exemptions, such as only forwarding
requests toward specific Target Resources according to an allowlist; see <xref t arget="server-responsibilities"/>.</t> requests toward specific Target Resources according to an allowlist; see <xref t arget="server-responsibilities"/>.</t>
</section> </section>
</section> </section>
<section anchor="privacy"> <section anchor="privacy">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>One goal of this design is that independent <iref item="Client"/><xref <t>One goal of this design is that independent <xref target="dfn-client" f
target="dfn-client" format="none">Client</xref> requests are only linkable by ormat="none">Client</xref> requests are only linkable by
their content. However, the choice of <iref item="Client"/><xref target="dfn-cl their content. However, the choice of Client configuration might be used to
ient" format="none">Client</xref> configuration might be used to correlate requests. A Client configuration includes the <xref target="dfn-relay
correlate requests. A <iref item="Client"/><xref target="dfn-client" format="no " format="none">Oblivious Relay
ne">Client</xref> configuration includes the <iref item="Oblivious Relay Resourc Resource</xref> URI, the Oblivious Gateway <xref target="key-configuration" form
e"/><xref target="dfn-relay" format="none">Oblivious Relay at="none">key configuration</xref>, and the <xref target="dfn-gateway" format="n
Resource</xref> URI, the Oblivious Gateway <iref item="key configuration"/><xref one">Oblivious Gateway
target="key-configuration" format="none">key configuration</xref>, and <iref it Resource</xref> URI. A configuration is active if Clients can successfully use i
em="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivi t for
ous Gateway interacting with a target.</t>
Resource</xref> URI. A configuration is active if <iref item="Clients"/><xref ta <t>Oblivious Relay and Gateway Resources can identify when requests use th
rget="dfn-client" format="none">Clients</xref> can successfully use it for inter e same
acting with a target.</t> configuration by matching the key identifier from the key configuration or the
<t><iref item="Oblivious Relay and Gateway Resources"/><xref target="dfn-r Oblivious Gateway Resource URI. The Oblivious Gateway Resource might use the
elay" format="none">Oblivious Relay and Gateway Resources</xref> can identify wh source address of requests to correlate requests that use an Oblivious Relay
en requests use the same Resource run by the same operator. If the Oblivious Gateway Resource is willing
configuration by matching the key ID from the <iref item="key configuration"/><x to use trial decryption, requests can be further separated into smaller
ref target="key-configuration" format="none">key configuration</xref> or the <ir groupings based on active configurations that clients use.</t>
ef item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">O <t>Each active Client configuration partitions the Client anonymity set. I
blivious n
Gateway Resource</xref> URI. The <iref item="Oblivious Gateway Resource"/><xref
target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> might use
the source
address of requests to correlate requests that use an <iref item="Oblivious Rela
y Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xr
ef>
run by the same operator. If the <iref item="Oblivious Gateway Resource"/><xref
target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> is willing
to use
trial decryption, requests can be further separated into smaller groupings based
on the keys that are used.</t>
<t>Each active <iref item="Client"/><xref target="dfn-client" format="none
">Client</xref> configuration partitions the <iref item="Client"/><xref target="
dfn-client" format="none">Client</xref> anonymity set. In
practice, it is infeasible to reduce the number of active configurations to practice, it is infeasible to reduce the number of active configurations to
one. Enabling diversity in choice of <iref item="Oblivious Relay Resource"/><xre f target="dfn-relay" format="none">Oblivious Relay Resource</xref> naturally one. Enabling diversity in choice of Oblivious Relay Resource naturally
increases the number of active configurations. More than one configuration increases the number of active configurations. More than one configuration
might need to be active to allow for key rotation and server maintenance.</t> might need to be active to allow for key rotation and server maintenance.</t>
<t><iref item="Client"/><xref target="dfn-client" format="none">Client</xr <t>Client privacy depends on having each configuration used by many other
ef> privacy depends on having each configuration used by many other <iref item=" Clients.
Clients"/><xref target="dfn-client" format="none">Clients</xref>. It is critical to prevent the use of unique Client configurations, which might
It is critical to prevent the use of unique <iref item="Client"/><xref target="d be used to track individual Clients, but it is also important to avoid
fn-client" format="none">Client</xref> configurations, which might creating small groupings of Clients that might weaken privacy protections.</t>
be used to track individual <iref item="Clients"/><xref target="dfn-client" form <t>A specific method for a Client to acquire configurations is not include
at="none">Clients</xref>, but it is also important to avoid d in this
creating small groupings of <iref item="Clients"/><xref target="dfn-client" form
at="none">Clients</xref> that might weaken privacy protections.</t>
<t>A specific method for a <iref item="Client"/><xref target="dfn-client"
format="none">Client</xref> to acquire configurations is not included in this
specification. Applications using this design <bcp14>MUST</bcp14> provide accom modations to specification. Applications using this design <bcp14>MUST</bcp14> provide accom modations to
mitigate tracking using <iref item="Client"/><xref target="dfn-client" format="n mitigate tracking using Client configurations. <xref target="CONSISTENCY"/> pro
one">Client</xref> configurations. <xref target="CONSISTENCY"/> provides option vides options
s for ensuring that Client configurations are consistent between Clients.</t>
for ensuring that <iref item="Client"/><xref target="dfn-client" format="none">C
lient</xref> configurations are consistent between <iref item="Clients"/><xref t
arget="dfn-client" format="none">Clients</xref>.</t>
<t>The content of requests or responses, if used in forming new requests, can be <t>The content of requests or responses, if used in forming new requests, can be
used to correlate requests. This includes obvious methods of linking requests, used to correlate requests. This includes obvious methods of linking requests,
like cookies <xref target="COOKIES"/>, but it also includes any information in e ither like cookies <xref target="COOKIES"/>, but it also includes any information in e ither
message that might affect how subsequent requests are formulated. For example, message that might affect how subsequent requests are formulated. For example,
<xref target="FIELDING"/> describes how interactions that are individually state less can be <xref target="FIELDING"/> describes how interactions that are individually state less can be
used to build a stateful system when a <iref item="Client"/><xref target="dfn-cl ient" format="none">Client</xref> acts on the content of a response.</t> used to build a stateful system when a Client acts on the content of a response. </t>
</section> </section>
<section anchor="deployment"> <section anchor="deployment">
<name>Operational and Deployment Considerations</name> <name>Operational and Deployment Considerations</name>
<t>This section discusses various operational and deployment consideration s.</t> <t>This section discusses various operational and deployment consideration s.</t>
<section anchor="performance-overhead"> <section anchor="performance-overhead">
<name>Performance Overhead</name> <name>Performance Overhead</name>
<t>Using Oblivious HTTP adds both cryptographic overhead and latency to requests <t>Using Oblivious HTTP adds both cryptographic overhead and latency to requests
relative to a simple HTTP request-response exchange. Deploying relay services relative to a simple HTTP request-response exchange. Deploying relay services
that are on path between <iref item="Clients"/><xref target="dfn-client" format= "none">Clients</xref> and servers avoids adding significant that are on path between <xref target="dfn-client" format="none">Clients</xref> and servers avoids adding significant
additional delay due to network topology. A study of a similar system additional delay due to network topology. A study of a similar system
<xref target="ODOH-PETS"/> found that deploying proxies close to servers was mos t effective <xref target="ODOH-PETS"/> found that deploying proxies close to servers was mos t effective
in minimizing additional latency.</t> in minimizing additional latency.</t>
</section> </section>
<section anchor="proxy-state"> <section anchor="proxy-state">
<name>Resource Mappings</name> <name>Resource Mappings</name>
<t>This protocol assumes a fixed, one-to-one mapping between the <iref i <t>This protocol assumes a fixed, one-to-one mapping between the <xref t
tem="Oblivious Relay Resource"/><xref target="dfn-relay" format="none">Oblivious arget="dfn-relay" format="none">Oblivious Relay
Relay Resource</xref> and the <xref target="dfn-gateway" format="none">Oblivious Gatew
Resource</xref> and the <iref item="Oblivious Gateway Resource"/><xref target="d ay Resource</xref>. This means that any <xref target="dfn-enc-req" format="none"
fn-gateway" format="none">Oblivious Gateway Resource</xref>. This means that any >Encapsulated
encrypted Request</xref> sent to the Oblivious Relay Resource will always be forwarded to
request sent to the <iref item="Oblivious Relay Resource"/><xref target="dfn-rel the
ay" format="none">Oblivious Relay Resource</xref> will always be forwarded to th Oblivious Gateway Resource. This constraint was imposed to simplify relay
e configuration and mitigate against the Oblivious Relay Resource being used as
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none a generic relay for unknown Oblivious Gateway Resources. The relay will only
">Oblivious Gateway Resource</xref>. This constraint was imposed to simplify rel forward for Oblivious Gateway Resources that it has explicitly configured and
ay
configuration and mitigate against the <iref item="Oblivious Relay Resource"/><x
ref target="dfn-relay" format="none">Oblivious Relay Resource</xref> being used
as
a generic relay for unknown <iref item="Oblivious Gateway Resources"/><xref targ
et="dfn-gateway" format="none">Oblivious Gateway Resources</xref>. The relay wil
l only
forward for <iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway"
format="none">Oblivious Gateway Resources</xref> that it has explicitly configu
red and
allowed.</t> allowed.</t>
<t>It is possible for a server to be configured with multiple <iref item <t>It is possible for a server to be configured with multiple Oblivious
="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">Oblivious R Relay
elay Resources, each for a different Oblivious Gateway Resource as needed. If the
Resources</xref>, each for a different <iref item="Oblivious Gateway Resource"/> goal is to support a large number of Oblivious Gateway Resources, <xref target="
<xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> as ne dfn-client" format="none">Clients</xref> might
eded. If the
goal is to support a large number of <iref item="Oblivious Gateway Resources"/><
xref target="dfn-gateway" format="none">Oblivious Gateway Resources</xref>, <ire
f item="Clients"/><xref target="dfn-client" format="none">Clients</xref> might
be provided with a URI template <xref target="TEMPLATE"/>, from which multiple be provided with a URI template <xref target="TEMPLATE"/>, from which multiple
<iref item="Oblivious Relay Resources"/><xref target="dfn-relay" format="none">O blivious Relay Resources</xref> could be constructed.</t> Oblivious Relay Resources could be constructed.</t>
</section> </section>
<section anchor="network-management"> <section anchor="network-management">
<name>Network Management</name> <name>Network Management</name>
<t>Oblivious HTTP might be incompatible with network interception regime s, such as <t>Oblivious HTTP might be incompatible with network interception regime s, such as
those that rely on configuring <iref item="Clients"/><xref target="dfn-client" f ormat="none">Clients</xref> with trust anchors and intercepting TLS those that rely on configuring <xref target="dfn-client" format="none">Clients</ xref> with trust anchors and intercepting TLS
connections. While TLS might be intercepted successfully, interception connections. While TLS might be intercepted successfully, interception
middleboxes devices might not receive updates that would allow Oblivious HTTP to middlebox devices might not receive updates that would allow Oblivious HTTP to
be correctly identified using the media types defined in <xref target="iana-req" be correctly identified using the media types defined in Sections <xref format="
/> and counter" target="iana-req"/>
<xref target="iana-res"/>.</t> and <xref format="counter" target="iana-res"/>.</t>
<t>Oblivious HTTP has a simple key management design that is not trivial ly altered <t>Oblivious HTTP has a simple key management design that is not trivial ly altered
to enable interception by intermediaries. <iref item="Clients"/><xref target="d fn-client" format="none">Clients</xref> that are configured to enable to enable interception by intermediaries. Clients that are configured to enable
interception might choose to disable Oblivious HTTP in order to ensure that interception might choose to disable Oblivious HTTP in order to ensure that
content is accessible to middleboxes.</t> content is accessible to middleboxes.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>Please update the "Media Types" registry at <t>IANA has registered the following media types in the "Media Types" regi
<eref target="https://iana.org/assignments/media-types">https://iana.org/assignm stry at
ents/media-types</eref> for the media types <eref target="https://iana.org/assignments/media-types" brackets="angle"/>, foll
"application/ohttp-keys" (<xref target="iana-keys"/>), "message/ohttp-req" (<xre owing the procedures of
f target="iana-req"/>), <xref target="RFC6838"/>: "<tt>application/ohttp-keys</tt>" (<xref target="iana-
and "message/ohttp-res" (<xref target="iana-res"/>), following the procedures of keys"/>), "<tt>message/ohttp-req</tt>"
<xref target="RFC6838"/>.</t> (<xref target="iana-req"/>), and "<tt>message/ohttp-res</tt>" (<xref target="ian
<t>Please update the "HTTP Problem Types" registry at a-res"/>).</t>
<eref target="https://iana.org/assignments/http-problem-types">https://iana.org/ <t>IANA has added the following types to the "HTTP Problem Types" registry
assignments/http-problem-types</eref> for the types "date" at
<eref target="https://iana.org/assignments/http-problem-types" brackets="angle"/
>: "date"
(<xref target="iana-problem-date"/>) and "ohttp-key" (<xref target="iana-problem -ohttp-key"/>).</t> (<xref target="iana-problem-date"/>) and "ohttp-key" (<xref target="iana-problem -ohttp-key"/>).</t>
<section anchor="iana-keys"> <section anchor="iana-keys">
<name>application/ohttp-keys Media Type</name> <name>application/ohttp-keys Media Type</name>
<t>The "application/ohttp-keys" media type identifies a <iref item="key configuration"/><xref target="key-configuration" format="none">key configuration </xref> used by <t>The "<tt>application/ohttp-keys</tt>" media type identifies a <xref t arget="key-configuration" format="none">key configuration</xref> used by
Oblivious HTTP.</t> Oblivious HTTP.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>
<t>application</t> <t>application</t>
</dd> </dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>
<t>ohttp-keys</t> <t>ohttp-keys</t>
</dd> </dd>
skipping to change at line 1445 skipping to change at line 1551
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>
<t>"binary"</t> <t>"binary"</t>
</dd> </dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>
<t>see <xref target="sec-media"/></t> <t>See <xref target="sec-media"/></t>
</dd> </dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd>
<t>this specification</t> <t>RFC 9458</t>
</dd> </dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>
<t>This type identifies a <iref item="key configuration"/><xref targ et="key-configuration" format="none">key configuration</xref> as used by Oblivio us HTTP and <t>This type identifies a key configuration as used by Oblivious HTT P and
applications that use Oblivious HTTP.</t> applications that use Oblivious HTTP.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd> <dd>
<dl spacing="compact"> <t><br/></t>
<dl spacing="normal">
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
</dl> </dl>
</dd> </dd>
<dt>Person and email address to contact for further information:</dt> <dt>Person and email address to contact for further information:</dt>
<dd> <dd>
<t>see Authors' Addresses section</t> <t><br/>See Authors' Addresses section</t>
</dd> </dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>
<t>COMMON</t> <t>COMMON</t>
</dd> </dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Author:</dt> <dt>Author:</dt>
<dd> <dd>
<t>see Authors' Addresses section</t> <t>See Authors' Addresses section</t>
</dd> </dd>
<dt>Change controller:</dt> <dt>Change controller:</dt>
<dd> <dd>
<t>IETF</t> <t>IETF</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-req"> <section anchor="iana-req">
<name>message/ohttp-req Media Type</name> <name>message/ohttp-req Media Type</name>
<t>The "message/ohttp-req" identifies an encrypted binary HTTP request. This <t>The "<tt>message/ohttp-req</tt>" identifies an encrypted binary HTTP request. This
is a binary format that is defined in <xref target="request"/>.</t> is a binary format that is defined in <xref target="request"/>.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>
<t>message</t> <t>message</t>
</dd> </dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>
<t>ohttp-req</t> <t>ohttp-req</t>
</dd> </dd>
skipping to change at line 1526 skipping to change at line 1633
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>
<t>"binary"</t> <t>"binary"</t>
</dd> </dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>
<t>see <xref target="sec-media"/></t> <t>See <xref target="sec-media"/></t>
</dd> </dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd>
<t>this specification</t> <t>RFC 9458</t>
</dd> </dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>
<t>Oblivious HTTP and applications that use Oblivious HTTP use this media type to <t>Oblivious HTTP and applications that use Oblivious HTTP use this media type to
identify encapsulated binary HTTP requests.</t> identify encapsulated binary HTTP requests.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd> <dd>
<dl spacing="compact"> <t><br/></t>
<dl spacing="normal">
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
</dl> </dl>
</dd> </dd>
<dt>Person and email address to contact for further information:</dt> <dt>Person and email address to contact for further information:</dt>
<dd> <dd>
<t>see Authors' Addresses section</t> <t><br/>See Authors' Addresses section</t>
</dd> </dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>
<t>COMMON</t> <t>COMMON</t>
</dd> </dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Author:</dt> <dt>Author:</dt>
<dd> <dd>
<t>see Authors' Addresses section</t> <t>See Authors' Addresses section</t>
</dd> </dd>
<dt>Change controller:</dt> <dt>Change controller:</dt>
<dd> <dd>
<t>IETF</t> <t>IETF</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-res"> <section anchor="iana-res">
<name>message/ohttp-res Media Type</name> <name>message/ohttp-res Media Type</name>
<t>The "message/ohttp-res" identifies an encrypted binary HTTP response. This <t>The "<tt>message/ohttp-res</tt>" identifies an encrypted binary HTTP response. This
is a binary format that is defined in <xref target="response"/>.</t> is a binary format that is defined in <xref target="response"/>.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>
<t>message</t> <t>message</t>
</dd> </dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>
<t>ohttp-res</t> <t>ohttp-res</t>
</dd> </dd>
skipping to change at line 1607 skipping to change at line 1715
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>
<t>"binary"</t> <t>"binary"</t>
</dd> </dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>
<t>see <xref target="sec-media"/></t> <t>See <xref target="sec-media"/></t>
</dd> </dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd>
<t>this specification</t> <t>RFC 9458</t>
</dd> </dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>
<t>Oblivious HTTP and applications that use Oblivious HTTP use this media type to <t>Oblivious HTTP and applications that use Oblivious HTTP use this media type to
identify encapsulated binary HTTP responses.</t> identify encapsulated binary HTTP responses.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd> <dd>
<dl spacing="compact"> <t><br/></t>
<dl spacing="normal">
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
</dl> </dl>
</dd> </dd>
<dt>Person and email address to contact for further information:</dt> <dt>Person and email address to contact for further information:</dt>
<dd> <dd>
<t>see Authors' Addresses section</t> <t><br/>See Authors' Addresses section</t>
</dd> </dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>
<t>COMMON</t> <t>COMMON</t>
</dd> </dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Author:</dt> <dt>Author:</dt>
<dd> <dd>
<t>see Authors' Addresses section</t> <t>See Authors' Addresses section</t>
</dd> </dd>
<dt>Change controller:</dt> <dt>Change controller:</dt>
<dd> <dd>
<t>IETF</t> <t>IETF</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-problem-date"> <section anchor="iana-problem-date">
<name>Registration of "date" Problem Type</name> <name>Registration of "date" Problem Type</name>
<t>IANA are requested to create a new entry in the "HTTP Problem Type" r <t>IANA has added a new entry in the "HTTP Problem Types" registry estab
egistry lished by
established by <xref target="PROBLEM"/>.</t> <xref target="PROBLEM"/>.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Type URI:</dt> <dt>Type URI:</dt>
<dd> <dd>
<t>https://iana.org/assignments/http-problem-types#date</t> <t>https://iana.org/assignments/http-problem-types#date</t>
</dd> </dd>
<dt>Title:</dt> <dt>Title:</dt>
<dd> <dd>
<t>Date Not Acceptable</t> <t>Date Not Acceptable</t>
</dd> </dd>
<dt>Recommended HTTP Status Code:</dt> <dt>Recommended HTTP Status Code:</dt>
<dd> <dd>
<t>400</t> <t>400</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t><xref target="date-fix"/> of this document</t> <t><xref target="date-fix"/> of RFC 9458</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-problem-ohttp-key"> <section anchor="iana-problem-ohttp-key">
<name>Registration of "ohttp-key" Problem Type</name> <name>Registration of "ohttp-key" Problem Type</name>
<t>IANA are requested to create a new entry in the "HTTP Problem Type" r <t>IANA has added a new entry in the "HTTP Problem Types" registry estab
egistry lished by
established by <xref target="PROBLEM"/>.</t> <xref target="PROBLEM"/>.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Type URI:</dt> <dt>Type URI:</dt>
<dd> <dd>
<t>https://iana.org/assignments/http-problem-types#ohttp-key</t> <t>https://iana.org/assignments/http-problem-types#ohttp-key</t>
</dd> </dd>
<dt>Title:</dt> <dt>Title:</dt>
<dd> <dd>
<t>Oblivious HTTP <iref item="key configuration"/><xref target="key- configuration" format="none">key configuration</xref> not acceptable</t> <t>Oblivious HTTP key configuration not acceptable</t>
</dd> </dd>
<dt>Recommended HTTP Status Code:</dt> <dt>Recommended HTTP Status Code:</dt>
<dd> <dd>
<t>400</t> <t>400</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t><xref target="ohttp-key-problem"/> of this document</t> <t><xref target="ohttp-key-problem"/> of RFC 9458</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="HTTP11" to="HTTP/1.1"/> <displayreference target="HTTP11" to="HTTP/1.1"/>
<displayreference target="HTTP2" to="HTTP/2"/> <displayreference target="HTTP2" to="HTTP/2"/>
<displayreference target="HTTP3" to="HTTP/3"/> <displayreference target="HTTP3" to="HTTP/3"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="BINARY"> <reference anchor="BINARY" target="https://www.rfc-editor.org/info/rfc92 92">
<front> <front>
<title>Binary Representation of HTTP Messages</title> <title>Binary Representation of HTTP Messages</title>
<author fullname="M. Thomson" initials="M." surname="Thomson"> <author fullname="M. Thomson" initials="M." surname="Thomson"/>
<organization/> <author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
</author>
<author fullname="C. A. Wood" initials="C. A." surname="Wood">
<organization/>
</author>
<date month="August" year="2022"/> <date month="August" year="2022"/>
<abstract> <abstract>
<t>This document defines a binary format for representing HTTP mes sages.</t> <t>This document defines a binary format for representing HTTP mes sages.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9292"/> <seriesInfo name="RFC" value="9292"/>
<seriesInfo name="DOI" value="10.17487/RFC9292"/> <seriesInfo name="DOI" value="10.17487/RFC9292"/>
</reference> </reference>
<reference anchor="HTTP"> <reference anchor="HTTP" target="https://www.rfc-editor.org/info/rfc9110 ">
<front> <front>
<title>HTTP Semantics</title> <title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname=" <author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"> Fielding"/>
<organization/> <author fullname="M. Nottingham" initials="M." role="editor" surname
</author> ="Nottingham"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname <author fullname="J. Reschke" initials="J." role="editor" surname="R
="Nottingham"> eschke"/>
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke">
<organization/>
</author>
<date month="June" year="2022"/> <date month="June" year="2022"/>
<abstract> <abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati on-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common te rminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. </t> <t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati on-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common te rminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7 232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t> <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7 232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="STD" value="97"/> <seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/> <seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/> <seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference> </reference>
<reference anchor="HTTP-CACHING"> <reference anchor="HTTP-CACHING" target="https://www.rfc-editor.org/info /rfc9111">
<front> <front>
<title>HTTP Caching</title> <title>HTTP Caching</title>
<author fullname="R. Fielding" initials="R." role="editor" surname=" <author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"> Fielding"/>
<organization/> <author fullname="M. Nottingham" initials="M." role="editor" surname
</author> ="Nottingham"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname <author fullname="J. Reschke" initials="J." role="editor" surname="R
="Nottingham"> eschke"/>
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke">
<organization/>
</author>
<date month="June" year="2022"/> <date month="June" year="2022"/>
<abstract> <abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati on-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. </t> <t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati on-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t>
<t>This document obsoletes RFC 7234.</t> <t>This document obsoletes RFC 7234.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="STD" value="98"/> <seriesInfo name="STD" value="98"/>
<seriesInfo name="RFC" value="9111"/> <seriesInfo name="RFC" value="9111"/>
<seriesInfo name="DOI" value="10.17487/RFC9111"/> <seriesInfo name="DOI" value="10.17487/RFC9111"/>
</reference> </reference>
<reference anchor="QUIC"> <reference anchor="QUIC" target="https://www.rfc-editor.org/info/rfc9000 ">
<front> <front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I <author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"> yengar"/>
<organization/> <author fullname="M. Thomson" initials="M." role="editor" surname="T
</author> homson"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<date month="May" year="2021"/> <date month="May" year="2021"/>
<abstract> <abstract>
<t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communic ation, low-latency connection establishment, and network path migration. QUIC in cludes security measures that ensure confidentiality, integrity, and availabilit y in a range of deployment circumstances. Accompanying documents describe the i ntegration of TLS for key negotiation, loss detection, and an exemplary congesti on control algorithm.</t> <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communica tion, low-latency connection establishment, and network path migration. QUIC inc ludes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the int egration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9000"/> <seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/> <seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference> </reference>
<reference anchor="TLS"> <reference anchor="TLS" target="https://www.rfc-editor.org/info/rfc8446" >
<front> <front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl e> <title>The Transport Layer Security (TLS) Protocol Version 1.3</titl e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<organization/>
</author>
<date month="August" year="2018"/> <date month="August" year="2018"/>
<abstract> <abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu <t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over rity (TLS) protocol. TLS allows client/server applications to communicate over t
the Internet in a way that is designed to prevent eavesdropping, tampering, and he Internet in a way that is designed to prevent eavesdropping, tampering, and m
message forgery.</t> essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50 <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 77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
mplementations.</t> plementations.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8446"/> <seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference> </reference>
<reference anchor="HPKE"> <reference anchor="HPKE" target="https://www.rfc-editor.org/info/rfc9180 ">
<front> <front>
<title>Hybrid Public Key Encryption</title> <title>Hybrid Public Key Encryption</title>
<author fullname="R. Barnes" initials="R." surname="Barnes"> <author fullname="R. Barnes" initials="R." surname="Barnes"/>
<organization/> <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
</author> <author fullname="B. Lipp" initials="B." surname="Lipp"/>
<author fullname="K. Bhargavan" initials="K." surname="Bhargavan"> <author fullname="C. Wood" initials="C." surname="Wood"/>
<organization/>
</author>
<author fullname="B. Lipp" initials="B." surname="Lipp">
<organization/>
</author>
<author fullname="C. Wood" initials="C." surname="Wood">
<organization/>
</author>
<date month="February" year="2022"/> <date month="February" year="2022"/>
<abstract> <abstract>
<t>This document describes a scheme for hybrid public key encrypti on (HPKE). This scheme provides a variant of public key encryption of arbitrary- sized plaintexts for a recipient public key. It also includes three authenticate d variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key deri vation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEM s. We provide instantiations of the scheme using widely used and efficient primi tives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based ke y derivation function (HKDF), and SHA2.</t> <t>This document describes a scheme for hybrid public key encrypti on (HPKE). This scheme provides a variant of public key encryption of arbitrary- sized plaintexts for a recipient public key. It also includes three authenticate d variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key deri vation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEM s. We provide instantiations of the scheme using widely used and efficient primi tives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based ke y derivation function (HKDF), and SHA2.</t>
<t>This document is a product of the Crypto Forum Research Group ( CFRG) in the IRTF.</t> <t>This document is a product of the Crypto Forum Research Group ( CFRG) in the IRTF.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9180"/> <seriesInfo name="RFC" value="9180"/>
<seriesInfo name="DOI" value="10.17487/RFC9180"/> <seriesInfo name="DOI" value="10.17487/RFC9180"/>
</reference> </reference>
<reference anchor="RFC2119"> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 119">
<front> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit le> <title>Key words for use in RFCs to Indicate Requirement Levels</tit le>
<author fullname="S. Bradner" initials="S." surname="Bradner"> <author fullname="S. Bradner" initials="S." surname="Bradner"/>
<organization/>
</author>
<date month="March" year="1997"/> <date month="March" year="1997"/>
<abstract> <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> <t>In many standards track documents several words are used to sig nify the requirements in the specification. These words are often capitalized. T his document defines these words as they should be interpreted in IETF documents . This document specifies an Internet Best Current Practices for the Internet Co mmunity, and requests discussion and suggestions for improvements.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/> <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC8174"> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8 174">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"> <author fullname="B. Leiba" initials="B." surname="Leiba"/>
<organization/>
</author>
<date month="May" year="2017"/> <date month="May" year="2017"/>
<abstract> <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> <t>RFC 2119 specifies common key words that may be used in protoco l specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<reference anchor="ASCII"> <reference anchor="ASCII" target="https://www.rfc-editor.org/info/rfc20" >
<front> <front>
<title>ASCII format for network interchange</title> <title>ASCII format for network interchange</title>
<author fullname="V.G. Cerf" initials="V.G." surname="Cerf"> <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
<organization/>
</author>
<date month="October" year="1969"/> <date month="October" year="1969"/>
</front> </front>
<seriesInfo name="STD" value="80"/> <seriesInfo name="STD" value="80"/>
<seriesInfo name="RFC" value="20"/> <seriesInfo name="RFC" value="20"/>
<seriesInfo name="DOI" value="10.17487/RFC0020"/> <seriesInfo name="DOI" value="10.17487/RFC0020"/>
</reference> </reference>
<reference anchor="PROBLEM">
<reference anchor="PROBLEM" target="https://www.rfc-editor.org/info/rfc9
457">
<front> <front>
<title>Problem Details for HTTP APIs</title> <title>Problem Details for HTTP APIs</title>
<author fullname="Mark Nottingham" initials="M." surname="Nottingham "> <author fullname="Mark Nottingham" initials="M." surname="Nottingham ">
</author> </author>
<author fullname="Erik Wilde" initials="E." surname="Wilde"> <author fullname="Erik Wilde" initials="E." surname="Wilde">
</author> </author>
<author fullname="Sanjay Dalal" initials="S." surname="Dalal"> <author fullname="Sanjay Dalal" initials="S." surname="Dalal">
</author> </author>
<date day="1" month="March" year="2023"/> <date month="July" year="2023"/>
<abstract> <abstract>
<t> This document defines a "problem detail" to carry machine-re <t>This document defines a "problem detail" to carry machine-reada
adable ble details of erors in HTTP response content to avoid the need to define new er
details of errors in HTTP response content to avoid the need to ror response formats for HTTP APIs.
define new error response formats for HTTP APIs.
This document obsoletes RFC 7807.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-httpapi/rfc7807bis.
</t> </t>
<t>This document obsoletes RFC 7807.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-rfc7807bis <seriesInfo name="RFC" value="9457"/>
-06"/> <seriesInfo name="DOI" value="10.17487/RFC9457"/>
</reference> </reference>
<reference anchor="RFC8470">
<reference anchor="RFC8470" target="https://www.rfc-editor.org/info/rfc8
470">
<front> <front>
<title>Using Early Data in HTTP</title> <title>Using Early Data in HTTP</title>
<author fullname="M. Thomson" initials="M." surname="Thomson"> <author fullname="M. Thomson" initials="M." surname="Thomson"/>
<organization/> <author fullname="M. Nottingham" initials="M." surname="Nottingham"/
</author> >
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> <author fullname="W. Tarreau" initials="W." surname="Tarreau"/>
<organization/>
</author>
<author fullname="W. Tarreau" initials="W." surname="Tarreau">
<organization/>
</author>
<date month="September" year="2018"/> <date month="September" year="2018"/>
<abstract> <abstract>
<t>Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communi cate with servers about HTTP requests that are sent in early data. Techniques a re described that use these mechanisms to mitigate the risk of replay.</t> <t>Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communic ate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8470"/> <seriesInfo name="RFC" value="8470"/>
<seriesInfo name="DOI" value="10.17487/RFC8470"/> <seriesInfo name="DOI" value="10.17487/RFC8470"/>
</reference> </reference>
<reference anchor="RFC6838"> <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6 838">
<front> <front>
<title>Media Type Specifications and Registration Procedures</title> <title>Media Type Specifications and Registration Procedures</title>
<author fullname="N. Freed" initials="N." surname="Freed"> <author fullname="N. Freed" initials="N." surname="Freed"/>
<organization/> <author fullname="J. Klensin" initials="J." surname="Klensin"/>
</author> <author fullname="T. Hansen" initials="T." surname="Hansen"/>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization/>
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization/>
</author>
<date month="January" year="2013"/> <date month="January" year="2013"/>
<abstract> <abstract>
<t>This document defines procedures for the specification and regi stration of media types for use in HTTP, MIME, and other Internet protocols. Th is memo documents an Internet Best Current Practice.</t> <t>This document defines procedures for the specification and regi stration of media types for use in HTTP, MIME, and other Internet protocols. Thi s memo documents an Internet Best Current Practice.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="13"/> <seriesInfo name="BCP" value="13"/>
<seriesInfo name="RFC" value="6838"/> <seriesInfo name="RFC" value="6838"/>
<seriesInfo name="DOI" value="10.17487/RFC6838"/> <seriesInfo name="DOI" value="10.17487/RFC6838"/>
</reference> </reference>
</references> </references>
<references> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="CONSISTENCY"> <reference anchor="CONSISTENCY">
<front> <front>
<title>Key Consistency and Discovery</title> <title>Key Consistency and Discovery</title>
<author fullname="Alex Davidson" initials="A." surname="Davidson"> <author fullname="Alex Davidson" initials="A." surname="Davidson">
<organization>Brave Software</organization> <organization>Brave Software</organization>
</author> </author>
<author fullname="Matthew Finkel" initials="M." surname="Finkel"> <author fullname="Matthew Finkel" initials="M." surname="Finkel">
<organization>The Tor Project</organization> <organization>The Tor Project</organization>
</author> </author>
<author fullname="Martin Thomson" initials="M." surname="Thomson"> <author fullname="Martin Thomson" initials="M." surname="Thomson">
<organization>Mozilla</organization> <organization>Mozilla</organization>
</author> </author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo d"> <author fullname="Christopher A. Wood" initials="C. A." surname="Woo d">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
</author> </author>
<date day="24" month="October" year="2022"/> <date day="10" month="July" year="2023"/>
<abstract> <abstract>
<t> This document describes the key consistency and correctness <t> This document describes the consistency requirements of prot
requirements of protocols such as Privacy Pass, Oblivious DoH, and ocols
Oblivious HTTP for user privacy. It discusses several mechanisms and such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user
proposals for enabling user privacy in varying threat models. In privacy. It presents definitions for consistency and then surveys
mechanisms for providing consistency in varying threat models. In
concludes with discussion of open problems in this area. concludes with discussion of open problems in this area.
</t> </t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-key-co nsistency-00"/> <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-key-co nsistency-01"/>
</reference> </reference>
<reference anchor="HTTP11"> <reference anchor="HTTP11" target="https://www.rfc-editor.org/info/rfc91 12">
<front> <front>
<title>HTTP/1.1</title> <title>HTTP/1.1</title>
<author fullname="R. Fielding" initials="R." role="editor" surname=" <author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"> Fielding"/>
<organization/> <author fullname="M. Nottingham" initials="M." role="editor" surname
</author> ="Nottingham"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname <author fullname="J. Reschke" initials="J." role="editor" surname="R
="Nottingham"> eschke"/>
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke">
<organization/>
</author>
<date month="June" year="2022"/> <date month="June" year="2022"/>
<abstract> <abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati on-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connectio n management, and related security concerns. </t> <t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati on-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connectio n management, and related security concerns.</t>
<t>This document obsoletes portions of RFC 7230.</t> <t>This document obsoletes portions of RFC 7230.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="STD" value="99"/> <seriesInfo name="STD" value="99"/>
<seriesInfo name="RFC" value="9112"/> <seriesInfo name="RFC" value="9112"/>
<seriesInfo name="DOI" value="10.17487/RFC9112"/> <seriesInfo name="DOI" value="10.17487/RFC9112"/>
</reference> </reference>
<reference anchor="HTTP2"> <reference anchor="HTTP2" target="https://www.rfc-editor.org/info/rfc911 3">
<front> <front>
<title>HTTP/2</title> <title>HTTP/2</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T <author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"> homson"/>
<organization/> <author fullname="C. Benfield" initials="C." role="editor" surname="
</author> Benfield"/>
<author fullname="C. Benfield" initials="C." role="editor" surname="
Benfield">
<organization/>
</author>
<date month="June" year="2022"/> <date month="June" year="2022"/>
<abstract> <abstract>
<t>This specification describes an optimized expression of the sem antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent excha nges on the same connection.</t> <t>This specification describes an optimized expression of the sem antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent excha nges on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</t> <t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9113"/> <seriesInfo name="RFC" value="9113"/>
<seriesInfo name="DOI" value="10.17487/RFC9113"/> <seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference> </reference>
<reference anchor="HTTP3"> <reference anchor="HTTP3" target="https://www.rfc-editor.org/info/rfc911 4">
<front> <front>
<title>HTTP/3</title> <title>HTTP/3</title>
<author fullname="M. Bishop" initials="M." role="editor" surname="Bi <author fullname="M. Bishop" initials="M." role="editor" surname="Bi
shop"> shop"/>
<organization/>
</author>
<date month="June" year="2022"/> <date month="June" year="2022"/>
<abstract> <abstract>
<t>The QUIC transport protocol has several features that are desir able in a transport for HTTP, such as stream multiplexing, per-stream flow contr ol, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features tha t are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP /3.</t> <t>The QUIC transport protocol has several features that are desir able in a transport for HTTP, such as stream multiplexing, per-stream flow contr ol, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3 .</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9114"/> <seriesInfo name="RFC" value="9114"/>
<seriesInfo name="DOI" value="10.17487/RFC9114"/> <seriesInfo name="DOI" value="10.17487/RFC9114"/>
</reference> </reference>
<reference anchor="COOKIES"> <reference anchor="COOKIES" target="https://www.rfc-editor.org/info/rfc6 265">
<front> <front>
<title>HTTP State Management Mechanism</title> <title>HTTP State Management Mechanism</title>
<author fullname="A. Barth" initials="A." surname="Barth"> <author fullname="A. Barth" initials="A." surname="Barth"/>
<organization/>
</author>
<date month="April" year="2011"/> <date month="April" year="2011"/>
<abstract> <abstract>
<t>This document defines the HTTP Cookie and Set-Cookie header fie lds. These header fields can be used by HTTP servers to store state (called cook ies) at HTTP user agents, letting the servers maintain a stateful session over t he mostly stateless HTTP protocol. Although cookies have many historical infeli cities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [ST ANDARDS-TRACK]</t> <t>This document defines the HTTP Cookie and Set-Cookie header fie lds. These header fields can be used by HTTP servers to store state (called cook ies) at HTTP user agents, letting the servers maintain a stateful session over t he mostly stateless HTTP protocol. Although cookies have many historical infelic ities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STAND ARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6265"/> <seriesInfo name="RFC" value="6265"/>
<seriesInfo name="DOI" value="10.17487/RFC6265"/> <seriesInfo name="DOI" value="10.17487/RFC6265"/>
</reference> </reference>
<reference anchor="DMS2004" target="https://svn.torproject.org/svn/proje cts/design-paper/tor-design.html"> <reference anchor="DMS2004" target="https://svn.torproject.org/svn/proje cts/design-paper/tor-design.html">
<front> <front>
<title>Tor: The Second-Generation Onion Router</title> <title>Tor: The Second-Generation Onion Router</title>
<author initials="R." surname="Dingledine"> <author initials="R." surname="Dingledine">
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Mathewson"> <author initials="N." surname="Mathewson">
<organization/> <organization/>
</author> </author>
<author initials="P." surname="Syverson"> <author initials="P." surname="Syverson">
<organization/> <organization/>
</author> </author>
<date year="2004" month="August"/> <date year="2004" month="May"/>
</front> </front>
</reference> </reference>
<reference anchor="PRIO" target="https://crypto.stanford.edu/prio/paper. pdf"> <reference anchor="PRIO" target="https://crypto.stanford.edu/prio/paper. pdf">
<front> <front>
<title>Prio: Private, Robust, and Scalable Computation of Aggregate Statistics</title> <title>Prio: Private, Robust, and Scalable Computation of Aggregate Statistics</title>
<author initials="H." surname="Corrigan-Gibbs"> <author initials="H." surname="Corrigan-Gibbs">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Boneh"> <author initials="D." surname="Boneh">
<organization/> <organization/>
</author> </author>
<date year="2017" month="March" day="14"/> <date year="2017" month="March"/>
</front> </front>
</reference> </reference>
<reference anchor="ODOH-PETS" target="https://www.petsymposium.org/2021/ files/papers/issue4/popets-2021-0085.pdf"> <reference anchor="ODOH-PETS" target="https://www.petsymposium.org/2021/ files/papers/issue4/popets-2021-0085.pdf">
<front> <front>
<title>Oblivious DNS over HTTPS (ODoH): A Practical Privacy Enhancem ent to DNS</title> <title>Oblivious DNS over HTTPS (ODoH): A Practical Privacy Enhancem ent to DNS</title>
<author fullname="Sudheesh Singanamalla"> <author fullname="Sudheesh Singanamalla" initials="S." surname="Sing
<organization/> anamalla"/>
</author> <author fullname="Suphanat Chunhapanya" initials="S." surname="Chunh
<author fullname="Suphanat Chunhapanya"> apanya"/>
<organization/> <author fullname="Jonathan Hoylan" initials="J." surname="Hoyland"/>
</author> <author fullname="Marek Vavruša" initials="M." surname="Vavruša"/>
<author fullname="Marek Vavrusa"> <author fullname="Tanya Verma" initials="T." surname="Verma"/>
<organization/> <author fullname="Peter Wu" initials="P." surname="Wu"/>
</author> <author fullname="Marwan Fayed" initials="M." surname="Fayed"/>
<author fullname="Tanya Verma"> <author fullname="Kurtis Heimerl" initials="K." surname="Heimerl"/>
<organization/> <author fullname="Nick Sullivan" initials="N." surname="Sullivan"/>
</author> <author fullname="Christopher A. Wood" initials="C. A." surname="Woo
<author fullname="Peter Wu"> d"/>
<organization/> <date year="2021" month="January"/>
</author>
<author fullname="Marwan Fayed">
<organization/>
</author>
<author fullname="Kurtis Heimerl">
<organization/>
</author>
<author fullname="Nick Sullivan">
<organization/>
</author>
<author fullname="Christopher A. Wood">
<organization/>
</author>
<date year="2021" month="January" day="07"/>
</front> </front>
<seriesInfo name="DOI" value="10.2478/popets-2021-0085"/>
<refcontent>PoPETS Proceedings Volume 2021, Issue 4, pp. 575-592</refc
ontent>
</reference> </reference>
<reference anchor="OHTTP-ANALYSIS" target="https://github.com/cloudflare /ohttp-analysis"> <reference anchor="OHTTP-ANALYSIS" target="https://github.com/cloudflare /ohttp-analysis">
<front> <front>
<title>Tamarin Model of Oblivious HTTP</title> <title>Tamarin Model of Oblivious HTTP</title>
<author fullname="Jonathan Hoyland"> <author fullname="Jonathan Hoyland" initials="J." surname="Hoyland">
<organization/> <organization/>
</author> </author>
<date year="2021" month="August" day="23"/> <date year="2022" month="October"/>
</front> </front>
<refcontent>commit 6824eee</refcontent>
</reference> </reference>
<reference anchor="UWT" target="https://www.w3.org/2001/tag/doc/unsancti oned-tracking/"> <reference anchor="UWT" target="https://www.w3.org/2001/tag/doc/unsancti oned-tracking/">
<front> <front>
<title>Unsanctioned Web Tracking</title> <title>Unsanctioned Web Tracking</title>
<author fullname="Mark Nottingham"> <author fullname="Mark Nottingham">
<organization/> <organization/>
</author> </author>
<date year="2015" month="July" day="17"/> <date year="2015" month="July"/>
</front> </front>
<refcontent>W3C TAG Finding</refcontent>
</reference> </reference>
<reference anchor="FIELDING" target="https://www.ics.uci.edu/~fielding/p ubs/dissertation/fielding_dissertation.pdf"> <reference anchor="FIELDING" target="https://www.ics.uci.edu/~fielding/p ubs/dissertation/fielding_dissertation.pdf">
<front> <front>
<title>Architectural Styles and the Design of Network-based Software Architectures</title> <title>Architectural Styles and the Design of Network-based Software Architectures</title>
<author fullname="Roy Thomas Fielding"> <author fullname="Roy Thomas Fielding">
<organization/> <organization/>
</author> </author>
<date year="2000"/> <date year="2000" month="January"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC7838"> <reference anchor="RFC7838" target="https://www.rfc-editor.org/info/rfc7 838">
<front> <front>
<title>HTTP Alternative Services</title> <title>HTTP Alternative Services</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> <author fullname="M. Nottingham" initials="M." surname="Nottingham"/
<organization/> >
</author> <author fullname="P. McManus" initials="P." surname="McManus"/>
<author fullname="P. McManus" initials="P." surname="McManus"> <author fullname="J. Reschke" initials="J." surname="Reschke"/>
<organization/>
</author>
<author fullname="J. Reschke" initials="J." surname="Reschke">
<organization/>
</author>
<date month="April" year="2016"/> <date month="April" year="2016"/>
<abstract> <abstract>
<t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate networ k location, possibly accessed with a different protocol configuration.</t> <t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate networ k location, possibly accessed with a different protocol configuration.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7838"/> <seriesInfo name="RFC" value="7838"/>
<seriesInfo name="DOI" value="10.17487/RFC7838"/> <seriesInfo name="DOI" value="10.17487/RFC7838"/>
</reference> </reference>
<reference anchor="RFC8484"> <reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8 484">
<front> <front>
<title>DNS Queries over HTTPS (DoH)</title> <title>DNS Queries over HTTPS (DoH)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<organization/> <author fullname="P. McManus" initials="P." surname="McManus"/>
</author>
<author fullname="P. McManus" initials="P." surname="McManus">
<organization/>
</author>
<date month="October" year="2018"/> <date month="October" year="2018"/>
<abstract> <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> <t>This document defines a protocol for sending DNS queries and ge tting DNS responses over HTTPS. Each DNS query-response pair is mapped into an H TTP exchange.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8484"/> <seriesInfo name="RFC" value="8484"/>
<seriesInfo name="DOI" value="10.17487/RFC8484"/> <seriesInfo name="DOI" value="10.17487/RFC8484"/>
</reference> </reference>
<reference anchor="RANDOM"> <reference anchor="RANDOM" target="https://www.rfc-editor.org/info/rfc40 86">
<front> <front>
<title>Randomness Requirements for Security</title> <title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3 <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"> rd"/>
<organization/> <author fullname="J. Schiller" initials="J." surname="Schiller"/>
</author> <author fullname="S. Crocker" initials="S." surname="Crocker"/>
<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"/> <date month="June" year="2005"/>
<abstract> <abstract>
<t>Security systems are built on strong cryptographic algorithms t <t>Security systems are built on strong cryptographic algorithms t
hat foil pattern analysis attempts. However, the security of these systems is d hat foil pattern analysis attempts. However, the security of these systems is de
ependent on generating secret quantities for passwords, cryptographic keys, and pendent on generating secret quantities for passwords, cryptographic keys, and s
similar quantities. The use of pseudo-random processes to generate secret quant imilar quantities. The use of pseudo-random processes to generate secret quantit
ities can result in pseudo-security. A sophisticated attacker may find it easier ies can result in pseudo-security. A sophisticated attacker may find it easier t
to reproduce the environment that produced the secret quantities and to search o reproduce the environment that produced the secret quantities and to search th
the resulting small set of possibilities than to locate the quantities in the wh e resulting small set of possibilities than to locate the quantities in the whol
ole of the potential number space.</t> e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated <t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in adversary is surprisingly difficult. This document points out many pitfalls in u
using poor entropy sources or traditional pseudo-random number generation techni sing poor entropy sources or traditional pseudo-random number generation techniq
ques for generating such quantities. It recommends the use of truly random hard ues for generating such quantities. It recommends the use of truly random hardwa
ware techniques and shows that the existing hardware on many systems can be used re techniques and shows that the existing hardware on many systems can be used f
for this purpose. It provides suggestions to ameliorate the problem when a hard or this purpose. It provides suggestions to ameliorate the problem when a hardwa
ware solution is not available, and it gives examples of how large such quantiti re solution is not available, and it gives examples of how large such quantities
es need to be for some applications. This document specifies an Internet Best C need to be for some applications. This document specifies an Internet Best Curr
urrent Practices for the Internet Community, and requests discussion and suggest ent Practices for the Internet Community, and requests discussion and suggestion
ions for improvements.</t> s for improvements.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="106"/> <seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/> <seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/> <seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference> </reference>
<reference anchor="FORWARDED"> <reference anchor="FORWARDED" target="https://www.rfc-editor.org/info/rf c7239">
<front> <front>
<title>Forwarded HTTP Extension</title> <title>Forwarded HTTP Extension</title>
<author fullname="A. Petersson" initials="A." surname="Petersson"> <author fullname="A. Petersson" initials="A." surname="Petersson"/>
<organization/> <author fullname="M. Nilsson" initials="M." surname="Nilsson"/>
</author>
<author fullname="M. Nilsson" initials="M." surname="Nilsson">
<organization/>
</author>
<date month="June" year="2014"/> <date month="June" year="2014"/>
<abstract> <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 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 pos sible to arrange it so that each subsequent component will have access to, for e xample, 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> <t>This document also specifies guidelines for a proxy administrat or to anonymize the origin of a request.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7239"/> <seriesInfo name="RFC" value="7239"/>
<seriesInfo name="DOI" value="10.17487/RFC7239"/> <seriesInfo name="DOI" value="10.17487/RFC7239"/>
</reference> </reference>
<reference anchor="NTP"> <reference anchor="NTP" target="https://www.rfc-editor.org/info/rfc5905" >
<front> <front>
<title>Network Time Protocol Version 4: Protocol and Algorithms Spec ification</title> <title>Network Time Protocol Version 4: Protocol and Algorithms Spec ification</title>
<author fullname="D. Mills" initials="D." surname="Mills"> <author fullname="D. Mills" initials="D." surname="Mills"/>
<organization/> <author fullname="J. Martin" initials="J." role="editor" surname="Ma
</author> rtin"/>
<author fullname="J. Martin" initials="J." role="editor" surname="Ma <author fullname="J. Burbank" initials="J." surname="Burbank"/>
rtin"> <author fullname="W. Kasch" initials="W." surname="Kasch"/>
<organization/>
</author>
<author fullname="J. Burbank" initials="J." surname="Burbank">
<organization/>
</author>
<author fullname="W. Kasch" initials="W." surname="Kasch">
<organization/>
</author>
<date month="June" year="2010"/> <date month="June" year="2010"/>
<abstract> <abstract>
<t>The Network Time Protocol (NTP) is widely used to synchronize c omputer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protoco l header to accommodate the Internet Protocol version 6 address family. NTPv4 i ncludes fundamental improvements in the mitigation and discipline algorithms tha t extend the potential accuracy to the tens of microseconds with modern workstat ions and fast LANs. It includes a dynamic server discovery scheme, so that in m any cases, specific server configuration is not required. It corrects certain e rrors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]</t> <t>The Network Time Protocol (NTP) is widely used to synchronize c omputer clocks in the Internet. This document describes NTP version 4 (NTPv4), w hich is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 inc ludes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstatio ns and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain error s in the NTPv3 design and implementation and includes an optional extension mech anism. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5905"/> <seriesInfo name="RFC" value="5905"/>
<seriesInfo name="DOI" value="10.17487/RFC5905"/> <seriesInfo name="DOI" value="10.17487/RFC5905"/>
</reference> </reference>
<reference anchor="CLOCKSKEW"> <reference anchor="CLOCKSKEW">
<front> <front>
<title>Where the Wild Warnings Are: Root Causes of Chrome HTTPS Cert ificate Errors</title> <title>Where the Wild Warnings Are: Root Causes of Chrome HTTPS Cert ificate Errors</title>
<author fullname="Mustafa Emre Acer" initials="M." surname="Acer"> <author fullname="Mustafa Emre Acer" initials="M." surname="Acer">
<organization>Google Inc., Mountain View, CA, USA</organization> <organization>Google Inc., Mountain View, CA, USA</organization>
skipping to change at line 2264 skipping to change at line 2262
<organization>Google Inc., Mountain View, CA, USA</organization> <organization>Google Inc., Mountain View, CA, USA</organization>
</author> </author>
<author fullname="Ryan Sleevi" initials="R." surname="Sleevi"> <author fullname="Ryan Sleevi" initials="R." surname="Sleevi">
<organization>Google Inc., Mountain View, CA, USA</organization> <organization>Google Inc., Mountain View, CA, USA</organization>
</author> </author>
<author fullname="Parisa Tabriz" initials="P." surname="Tabriz"> <author fullname="Parisa Tabriz" initials="P." surname="Tabriz">
<organization>Google Inc., Mountain View, CA, USA</organization> <organization>Google Inc., Mountain View, CA, USA</organization>
</author> </author>
<date month="October" year="2017"/> <date month="October" year="2017"/>
</front> </front>
<seriesInfo name="Proceedings of the 2017 ACM SIGSAC Conference on Com puter and Communications" value="Security"/>
<seriesInfo name="DOI" value="10.1145/3133956.3134007"/> <seriesInfo name="DOI" value="10.1145/3133956.3134007"/>
<refcontent>Proceedings of the 2017 ACM SIGSAC Conference on
Computer and Communications Security</refcontent>
</reference> </reference>
<reference anchor="TEMPLATE"> <reference anchor="TEMPLATE" target="https://www.rfc-editor.org/info/rfc 6570">
<front> <front>
<title>URI Template</title> <title>URI Template</title>
<author fullname="J. Gregorio" initials="J." surname="Gregorio"> <author fullname="J. Gregorio" initials="J." surname="Gregorio"/>
<organization/> <author fullname="R. Fielding" initials="R." surname="Fielding"/>
</author> <author fullname="M. Hadley" initials="M." surname="Hadley"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"> <author fullname="M. Nottingham" initials="M." surname="Nottingham"/
<organization/> >
</author> <author fullname="D. Orchard" initials="D." surname="Orchard"/>
<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"/> <date month="March" year="2012"/>
<abstract> <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> <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> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6570"/> <seriesInfo name="RFC" value="6570"/>
<seriesInfo name="DOI" value="10.17487/RFC6570"/> <seriesInfo name="DOI" value="10.17487/RFC6570"/>
</reference> </reference>
<reference anchor="X25519"> <reference anchor="X25519" target="https://www.rfc-editor.org/info/rfc77 48">
<front> <front>
<title>Elliptic Curves for Security</title> <title>Elliptic Curves for Security</title>
<author fullname="A. Langley" initials="A." surname="Langley"> <author fullname="A. Langley" initials="A." surname="Langley"/>
<organization/> <author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
</author> <author fullname="S. Turner" initials="S." surname="Turner"/>
<author fullname="M. Hamburg" initials="M." surname="Hamburg">
<organization/>
</author>
<author fullname="S. Turner" initials="S." surname="Turner">
<organization/>
</author>
<date month="January" year="2016"/> <date month="January" year="2016"/>
<abstract> <abstract>
<t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, includin g Transport Layer Security (TLS). These curves are intended to operate at the ~ 128-bit and ~224-bit security level, respectively, and are generated determinist ically based on a list of required properties.</t> <t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, includin g Transport Layer Security (TLS). These curves are intended to operate at the ~1 28-bit and ~224-bit security level, respectively, and are generated deterministi cally based on a list of required properties.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7748"/> <seriesInfo name="RFC" value="7748"/>
<seriesInfo name="DOI" value="10.17487/RFC7748"/> <seriesInfo name="DOI" value="10.17487/RFC7748"/>
</reference> </reference>
<reference anchor="ODOH"> <reference anchor="ODOH" target="https://www.rfc-editor.org/info/rfc9230 ">
<front> <front>
<title>Oblivious DNS over HTTPS</title> <title>Oblivious DNS over HTTPS</title>
<author fullname="E. Kinnear" initials="E." surname="Kinnear"> <author fullname="E. Kinnear" initials="E." surname="Kinnear"/>
<organization/> <author fullname="P. McManus" initials="P." surname="McManus"/>
</author> <author fullname="T. Pauly" initials="T." surname="Pauly"/>
<author fullname="P. McManus" initials="P." surname="McManus"> <author fullname="T. Verma" initials="T." surname="Verma"/>
<organization/> <author fullname="C.A. Wood" initials="C.A." surname="Wood"/>
</author>
<author fullname="T. Pauly" initials="T." surname="Pauly">
<organization/>
</author>
<author fullname="T. Verma" initials="T." surname="Verma">
<organization/>
</author>
<author fullname="C.A. Wood" initials="C.A." surname="Wood">
<organization/>
</author>
<date month="June" year="2022"/> <date month="June" year="2022"/>
<abstract> <abstract>
<t>This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH ) messages. This improves privacy of DNS operations by not allowing any one serv er entity to be aware of both the client IP address and the content of DNS queri es and answers.</t> <t>This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH ) messages. This improves privacy of DNS operations by not allowing any one serv er entity to be aware of both the client IP address and the content of DNS queri es and answers.</t>
<t>This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among imp lementations, and enable wide-scale experimentation.</t> <t>This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among imp lementations, and enable wide-scale experimentation.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9230"/> <seriesInfo name="RFC" value="9230"/>
<seriesInfo name="DOI" value="10.17487/RFC9230"/> <seriesInfo name="DOI" value="10.17487/RFC9230"/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="complete-example-of-a-request-and-response"> <?line 1865?>
<section anchor="complete-example-of-a-request-and-response">
<name>Complete Example of a Request and Response</name> <name>Complete Example of a Request and Response</name>
<!-- Generated using ohttp (https://github.com/martinthomson/ohttp): <!-- Generated using ohttp (https://github.com/martinthomson/ohttp):
RUST_LOG=ohttp cargo test -\-features nss,client,server -\-no-default-features - p ohttp -\-lib -\- -\-nocapture request_response RUST_LOG=ohttp cargo test -\-features nss,client,server -\-no-default-features - p ohttp -\-lib -\- -\-nocapture request_response
Note: "rust-hpke" doesn't log the client/sender keying material. Note: "rust-hpke" doesn't log the client/sender keying material.
--> -->
<t>A single request and response exchange is shown here. Binary values (<iref it em="key configuration"/><xref target="key-configuration" format="none">key <t>A single request and response exchange is shown here. Binary values (<xref ta rget="key-configuration" format="none">key
configuration</xref>, secret keys, the content of messages, and intermediate val ues) configuration</xref>, secret keys, the content of messages, and intermediate val ues)
are shown in hexadecimal. The request and response here are minimal; the purpose are shown in hexadecimal. The request and response here are minimal; the purpose
of this example is to show the cryptographic operations. In this example, the of this example is to show the cryptographic operations. In this example, the
<iref item="Client"/><xref target="dfn-client" format="none">Client</xref> is co nfigured with the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay " format="none">Oblivious Relay Resource</xref> URI of <xref target="dfn-client" format="none">Client</xref> is configured with the <xr ef target="dfn-relay" format="none">Oblivious Relay Resource</xref> URI of
<tt>https://proxy.example.org/request.example.net/proxy</tt>, and the proxy is <tt>https://proxy.example.org/request.example.net/proxy</tt>, and the proxy is
configured to map requests to this URI to the <iref item="Oblivious Gateway Reso configured to map requests to this URI to the <xref target="dfn-gateway" format=
urce"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref "none">Oblivious Gateway Resource</xref> URI
> URI <tt>https://example.com/oblivious/request</tt>. The <xref target="dfn-target" fo
<tt>https://example.com/oblivious/request</tt>. The <iref item="Target Resource" rmat="none">Target Resource</xref> URI, i.e., the
/><xref target="dfn-target" format="none">Target Resource</xref> URI, i.e., the resource the Client ultimately wishes to query, is <tt>https://example.com</tt>.
resource the <iref item="Client"/><xref target="dfn-client" format="none">Client </t>
</xref> ultimately wishes to query, is <tt>https://example.com</tt>.</t> <t>To begin the process, the Oblivious Gateway Resource generates a key pa
<t>To begin the process, the <iref item="Oblivious Gateway Resource"/><xre ir.
f target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> generates In this example, the server chooses DHKEM(X25519, HKDF-SHA256) and generates
a key pair.
In this example the server chooses DHKEM(X25519, HKDF-SHA256) and generates
an X25519 key pair <xref target="X25519"/>. The X25519 secret key is:</t> an X25519 key pair <xref target="X25519"/>. The X25519 secret key is:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a 3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a
]]></artwork> ]]></artwork>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> constructs a <iref item="key co nfiguration"/><xref target="key-configuration" format="none">key configuration</ xref> that includes the <t>The Oblivious Gateway Resource constructs a key configuration that incl udes the
corresponding public key as follows:</t> corresponding public key as follows:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e 01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e
79815500080001000100010003 79815500080001000100010003
]]></artwork> ]]></artwork>
<t>This <iref item="key configuration"/><xref target="key-configuration" f ormat="none">key configuration</xref> is somehow obtained by the <iref item="Cli ent"/><xref target="dfn-client" format="none">Client</xref>. Then, when a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> <t>This key configuration is somehow obtained by the Client. Then, when a Client
wishes to send an HTTP GET request to the target <tt>https://example.com</tt>, i t wishes to send an HTTP GET request to the target <tt>https://example.com</tt>, i t
constructs the following binary HTTP message:</t> constructs the following binary HTTP message:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
00034745540568747470730b6578616d706c652e636f6d012f 00034745540568747470730b6578616d706c652e636f6d012f
]]></artwork> ]]></artwork>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Client <t>The Client then reads the Oblivious Gateway Resource key configuration
</xref> then reads the <iref item="Oblivious Gateway Resource"/><xref target="df and
n-gateway" format="none">Oblivious Gateway Resource</xref> <iref item="key confi selects a mutually supported KDF and AEAD. In this example, the Client selects
guration"/><xref target="key-configuration" format="none">key configuration</xre HKDF-SHA256 and AES-128-GCM. The Client then generates an HPKE sending context
f> and
selects a mutually supported KDF and AEAD. In this example, the <iref item="Clie
nt"/><xref target="dfn-client" format="none">Client</xref> selects
HKDF-SHA256 and AES-128-GCM. The <iref item="Client"/><xref target="dfn-client"
format="none">Client</xref> then generates an HPKE sending context
that uses the server public key. This context is constructed from the following that uses the server public key. This context is constructed from the following
ephemeral secret key:</t> ephemeral secret key:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73 bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73
]]></artwork> ]]></artwork>
<t>The corresponding public key is:</t> <t>The corresponding public key is:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472 4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
]]></artwork> ]]></artwork>
<t>And an <tt>info</tt> parameter of:</t> <t>The context is created with an <tt>info</tt> parameter of:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
6d6573736167652f626874747020726571756573740001002000010001 6d6573736167652f626874747020726571756573740001002000010001
]]></artwork> ]]></artwork>
<t>Applying the Seal operation from the HPKE context produces an encrypted <t>Applying the Seal operation from the HPKE context produces an encrypted
message, allowing the <iref item="Client"/><xref target="dfn-client" format="non e">Client</xref> to construct the following <iref item="Encapsulated Request"/>< xref target="dfn-enc-req" format="none">Encapsulated Request</xref>:</t> message, allowing the Client to construct the following <xref target="dfn-enc-re q" format="none">Encapsulated Request</xref>:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1 010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1
9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796 9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796
5e7d86b83dd440b2c0185204b4d63525 5e7d86b83dd440b2c0185204b4d63525
]]></artwork> ]]></artwork>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Client </xref> then sends this to the <iref item="Oblivious Relay Resource"/><xref targ et="dfn-relay" format="none">Oblivious Relay Resource</xref> in a POST request, <t>The Client then sends this to the Oblivious Relay Resource in a POST re quest,
which might look like the following HTTP/1.1 request:</t> which might look like the following HTTP/1.1 request:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /request.example.net/proxy HTTP/1.1 POST /request.example.net/proxy HTTP/1.1
Host: proxy.example.org Host: proxy.example.org
Content-Type: message/ohttp-req Content-Type: message/ohttp-req
Content-Length: 78 Content-Length: 78
<content is the Encapsulated Request above> <content is the Encapsulated Request above>
]]></sourcecode> ]]></sourcecode>
<t>The <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" for <t>The Oblivious Relay Resource receives this request and forwards it to t
mat="none">Oblivious Relay Resource</xref> receives this request and forwards it he
to the Oblivious Gateway Resource, which might look like:</t>
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none
">Oblivious Gateway Resource</xref>, which might look like:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /oblivious/request HTTP/1.1 POST /oblivious/request HTTP/1.1
Host: example.com Host: example.com
Content-Type: message/ohttp-req Content-Type: message/ohttp-req
Content-Length: 78 Content-Length: 78
<content is the Encapsulated Request above> <content is the Encapsulated Request above>
]]></sourcecode> ]]></sourcecode>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> receives this request, selects the key it <t>The <xref target="dfn-gateway" format="none">Oblivious Gateway Resource </xref> receives this request, selects the key it
generated previously using the key identifier from the message, and decrypts the generated previously using the key identifier from the message, and decrypts the
message. As this request is directed to the same server, the <iref item="Oblivio message. As this request is directed to the same server, the Oblivious Gateway
us Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource does not need to initiate an HTTP request to the <xref target="dfn-targ
Resource</xref> does not need to initiate an HTTP request to the <iref item="Tar et" format="none">Target Resource</xref>. The
get Resource"/><xref target="dfn-target" format="none">Target Resource</xref>. T request can be served directly by the Target Resource, which generates a minimal
he
request can be served directly by the <iref item="Target Resource"/><xref target
="dfn-target" format="none">Target Resource</xref>, which generates a minimal
response (consisting of just a 200 status code) as follows:</t> response (consisting of just a 200 status code) as follows:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
0140c8 0140c8
]]></artwork> ]]></artwork>
<t>The response is constructed by exporting a secret from the HPKE context :</t> <t>The response is constructed by exporting a secret from the HPKE context :</t>
<!-- ikm for HKDF extract --> <!-- ikm for HKDF extract -->
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
62d87a6ba569ee81014c2641f52bea36 62d87a6ba569ee81014c2641f52bea36
]]></artwork> ]]></artwork>
<t>The key derivation for the <iref item="Encapsulated Response"/><xref ta rget="dfn-enc-res" format="none">Encapsulated Response</xref> uses both the enca psulated KEM <t>The key derivation for the <xref target="dfn-enc-res" format="none">Enc apsulated Response</xref> uses both the encapsulated KEM
key from the request and a randomly selected nonce. This produces a salt of:</t> key from the request and a randomly selected nonce. This produces a salt of:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472 4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
c789e7151fcba46158ca84b04464910d c789e7151fcba46158ca84b04464910d
]]></artwork> ]]></artwork>
<t>The salt and secret are both passed to the Extract function of the sele cted KDF <t>The salt and secret are both passed to the <tt>Extract</tt> function of the selected KDF
(HKDF-SHA256) to produce a pseudorandom key of:</t> (HKDF-SHA256) to produce a pseudorandom key of:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
979aaeae066cf211ab407b31ae49767f344e1501e475c84e8aff547cc5a683db 979aaeae066cf211ab407b31ae49767f344e1501e475c84e8aff547cc5a683db
]]></artwork> ]]></artwork>
<t>The pseudorandom key is used with the Expand function of the KDF and an info <t>The pseudorandom key is used with the <tt>Expand</tt> function of the K DF and an info
field of "key" to produce a 16-byte key for the selected AEAD (AES-128-GCM):</t> field of "key" to produce a 16-byte key for the selected AEAD (AES-128-GCM):</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
5d0172a080e428b16d298c4ea0db620d 5d0172a080e428b16d298c4ea0db620d
]]></artwork> ]]></artwork>
<t>With the same KDF and pseudorandom key, an info field of "nonce" is use d to <t>With the same KDF and pseudorandom key, an info field of "nonce" is use d to
generate a 12-byte nonce:</t> generate a 12-byte nonce:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
f6bf1aeb88d6df87007fa263 f6bf1aeb88d6df87007fa263
]]></artwork> ]]></artwork>
<t>The AEAD <tt>Seal()</tt> function is then used to encrypt the response, which is added <t>The AEAD <tt>Seal()</tt> function is then used to encrypt the response, which is added
to the randomized nonce value to produce the <iref item="Encapsulated Response"/ ><xref target="dfn-enc-res" format="none">Encapsulated Response</xref>:</t> to the randomized nonce value to produce the Encapsulated Response:</t>
<artwork type="hex-dump"><![CDATA[ <artwork type="hex-dump"><![CDATA[
c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
857fbd 857fbd
]]></artwork> ]]></artwork>
<t>The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resource</xref> constructs a response with the same content:</t> <t>The <xref target="dfn-gateway" format="none">Oblivious Gateway Resource </xref> constructs a response with the same content:</t>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Wed, 27 Jan 2021 04:45:07 GMT Date: Wed, 27 Jan 2021 04:45:07 GMT
Cache-Control: private, no-store Cache-Control: private, no-store
Content-Type: message/ohttp-res Content-Type: message/ohttp-res
Content-Length: 38 Content-Length: 38
<content is the Encapsulated Response> <content is the Encapsulated Response>
]]></sourcecode> ]]></sourcecode>
<t>The same response might then be generated by the <iref item="Oblivious <t>The same response might then be generated by the <xref target="dfn-rela
Relay Resource"/><xref target="dfn-relay" format="none">Oblivious Relay Resource y" format="none">Oblivious Relay Resource</xref>, which
</xref> which might change as little as the <tt>Date</tt> header. The <xref target="dfn-client
might change as little as the Date header. The <iref item="Client"/><xref target " format="none">Client</xref> is then able to use the
="dfn-client" format="none">Client</xref> is then able to use the HPKE context it created and the nonce from the Encapsulated Response to
HPKE context it created and the nonce from the <iref item="Encapsulated Response
"/><xref target="dfn-enc-res" format="none">Encapsulated Response</xref> to
construct the AEAD key and nonce and decrypt the response.</t> construct the AEAD key and nonce and decrypt the response.</t>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This design is based on a design for Oblivious DoH, described in <t>This design is based on a design for Oblivious DNS (queries) over HTTPS
<xref target="ODOH"/>. <contact fullname="David Benjamin"/>, <contact fullname=" (DoH),
Mark Nottingham"/>, and <contact fullname="Eric Rescorla"/> made technical contr described in <xref target="ODOH"/>. <contact fullname="David Benjamin"/>, <conta
ibutions. The authors also thank <contact fullname="Ralph Giles"/>, <contact fu ct fullname="Mark Nottingham"/>, and
llname="Lucas Pardue"/>, and <contact fullname="Tommy Pauly"/> for invaluable as <contact fullname="Eric Rescorla"/> made technical contributions. The authors a
sistance.</t> lso thank
<contact fullname="Ralph Giles"/>, <contact fullname="Lucas Pardue"/>, and <cont
act fullname="Tommy Pauly"/> for invaluable
assistance.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIALcxEmQAA+19aXfb2JXg9/cr0PKHlmKSpnbJtaRVklylLlt2W3LX5GRy
SiABSohJgA2AkhmX+7fMb5lfNnd9CwBScpLumTknPp0uGwTect99d1/6/b6p
s3qavow23o6m2X1WLKrop+vrdxsmKcZ5PINfkjKe1P0srSf94i7O4P/V9bw/
PDLjuE5vi3L5MqrqxNy/jHZNXKYxjHWVjhdlVi83zENRfrwti8W8NUN0Mp9P
MxgjK/LoIq/TcpYmGf1zw9yn+SJ9aaLor/g2iurlHHf0C8yd5bfRjzgGPp/F
2RSe4y7+BfczKMpbfB6X4zt4jvuqXr54ga/ho+w+HehrL/DBi1FZPFTpCxzg
BX54m9V3ixF8StB5uCUAvSh0rX0cEd+bAqSq2pvCf3/AowyyovHli07ID+7q
2XTDmHhR3xUlwqgP/4uiLK9eRm8G0fVdMauKnJ7xAb6JyzrLgx9gR/C8+Es2
ncb0IGXYzOp/mRYPaV6XxXw5yNM6HP50cDKIfimKxBv99K7MqrqY36Vl5P9K
U5xOi0UyAWim/izj+OFf7tJ4DoczyuqK5jF5Uc7gBO/h2OHdHy4uT97/4WX0
/tXp8c7xDjzBc+d/b28P5d/905PTny4uf9Tn2/D83z5cnPK/h0N87/r1Ff3z
aG/vAD979/O5vH40NCbLJ8G8p28vry6urs8vT2Hyi/4ZIUB/Xmb38Xg5j6uq
/zFd9sdFXsGm03y8lJVsb7+kHX6nS9mhfyZZNZ/GcEPwnRfbg215fafx9m7H
27rp3ca7ex3v7tLS3/58cc6bPdg52MftnL252hkO93gEvenXgDaADWkE17TI
k/6PaZ6WfJfe5vj/3xcLuFIbPA+g7ssIB8ErT8PE5W3qI3N1nw/qopyXxZ/T
cU23BR69kH9XL5K0ym7z/jyep+ULeLHPDwSRcUiHy/inz8j2fhCdAYZM4Wbn
afjT5QCQur5LHxSf7S/vBtHV8j4t8Qf45d37i7fh5t+VWQGv4YHWaQ+2OlpU
dS+K8yS6GsfTeDRNo9NiNl/UDJFiEp3c3pbpLbweXeHDqs7GVQic7cP+cLcv
J9OCz7hczutiUNUxIlsySJMFAAeuO0FkME8ma6Dw0wCWU5bZbZz3f8xGoyr8
+WwQ/VDk6R1u9u3Z25/6786vr8IdO9J5dnkVFQAcwpmraPPtWfHT1svoBMAR
j2FX8ZQBM15G5/ldnI/TGZCCqC7wy3DHO9v9IfzfYbBj3fDDw8NgntbVcjYv
qmwxI5TAb15Msmla8b6rF1lVLdK9F/MC3+3zmMOjfQRIJzwmi+mUac7VIrlL
0+ouugIEieFZrHSs+d4cthHXQKQWsKF5nC+7XgMCmX6M/j2+LxdV1+/X+F30
78Blun59l8JliX5ZdA/8EOfRq3iZJh0//7wAwgwcLc1maTnteOEyG3+ETUzh
AOO84/cu2ouIQLTx5PLk9R+AmDUuPwCrBG7wpkjSKWJ3k+83T/mov7PbecrC
tsbF7MXYkvkXLB0A0KdLIJGPnOO/FnA4cELRT8VyClcQF//hl+twxR/yClAR
L2OaRL+ko+gasBUZe9etCWD/MbosamB9t3fxLLyv+4C6/e3V2PuwKzg73H5R
x7cvQBh6sfDW0a9lDS9wya8uzl+fIRsK1n2CIkQNFHBRwsW6qpeA+kRngHBF
Z0QCEf6XaY1CUn8UV7C/q2JSPwAcI+/rtFq/0/fFkph7XEWvsnQK5PI2JN3D
brqEGwVSNliMM6JJ/zmRr1/MFyMg23A/05LJ4Av96Vf/KZMuY/r9fhSPKoQJ
MPLrO8BpANiCiAfQ+nGZjXDrUbUEnjmLgAji/2CbOGIEXBQJJGyeRLtZWlXx
bVoNeCC42SBzwcfjaSbEaBZ/TKPZYlpncyDWZfofCxCuKvwFMKkAUgnoDWtE
QvcAOArMDEAORECejVKcFQm9gU+mWf4Rfi6qcCQ8I5kRVgsPsgT+nk2W9It9
E0B+F9/jeHANUjMpixm9UMHByPe96OEOqF4E3HqMLxb5dAmzzjLccQ0UpwZK
Th/lcCWraIFoABMKhOgXBxMG9ixLEli+eYbCb1kkC0JLY05yhqGsD/57n8bT
KrJSDjC0eMQA0fX9cyV7q5e6cQbUwFzBnhBFCXr+GFmla9aZQJCoabOC4GUK
b6fRIk8A4jRZgSudGhpO5x7AxX+ANZY9nrdYlOM0ungXxUkCaF9F8jYNM10y
nPM8pe3q7oy/Mlqqd3h3cEIBxGUdxAcBnOegacABwXoRebyZYYt5AeiblTAb
fA+iXzEGFQOGQKTCt7M8AcqZLOJpL8AKM4uTNCJcyAAy8OYI91+W6ZS+JxZc
A80nlIXrNEOhI45AYEL+iJuW1Y9SxK6iHMA5mzmK8eMFUNleCAXAmCibwdf3
gD7AWQkawLx70QhOGp9niFh8qhUt3+B641E2lVO3q/MuAV2ZO6RFsTcfwOyU
FodC8CS7BfIkFxcm+pTBPLhhmRS+TFIQnmhP8KyWNce3MUgvNcDbKLyVoDIG
MaWo4NTgqt9nZQ1AjuYstEU5U0xHTEGg1Yfm82eReb98catIkgznhTGKOf6l
IhrEQMZLZbEwFXQIUEGXhjgBSJTd0ikuKr7NckNSOATY3l2eIfxgpHh8p8A0
eZomRFYAEXD7SC2AdtUpIFaePqCO4h8posV9kSV6cfQ56ErpdCIEDOmECY7O
YQtRzgylLzwPVFbg/pBo66EHgS+dTLJxhooMoSVoZQksPlkQbSQkcbADNRoB
XmbzkFBEm4ApMYAmz2aL2VbP/wZ4UByln8bA5G/ThA7XeD+fvvsA6wNMQJwn
Mfm2jOd32ZggJDI4ntB1QetDKivApgvNv+P1C3nOBFSGqiHa9PiK1cUYrj8A
wQjjIW6AOJfmxI8CLsTX2Oc+cYTn/xAjJwCI3AIpYDIOOIEHsTQIlWyc4qWN
/EuLELMLIPrZyShBD90eIH2Jp7fAzeo75piw2nhewUi04FGWx+WysdbPn1lt
BtRn7PxpOSozkjzfLQAW4+jnFEV73jYg1CZqw9/Ad/jfL1+2cH9yTXG1Wal0
veoZszPAQ06BVyZNFs4n4lYIoLCLGsHFTOFCyW0jULMw647nR4Ho+1RYQBu0
7uX3CGT3Ku0Uh5MzRilyd0BXD2j3jObE5d4VD3QCa2YFJE1QSAs2gsPi8HZD
uIE5Md3mq0At5oCOKU/osTkUivAmz/DYVK30DhRpQi7owyJRhWIf0+DVCwa6
gtevSulVj6F7xEtp5Er4uTEMiCgZHPenOsArxQHYRcMKJ7JZixnpkXt8GJfR
WILRJfRQjHpIp1P8r/s2rhkgHVtoAqIHogNdJ1ON7+DM4cM57J7xLaB5wifp
xhEf5ovyZxTDkJarPAPXEym48RhfFP2CjD8U3VCqg3+INLQSyJsAX2BNldhF
4ar1olO9EMhhq4oYqexapcsyJSFkQUwFhZAaqC8wdZIQkYfPUDpFEZZlxgIl
L/s9SovPorf3SI7SB5IOGwfISwBZmnYMRBlOdBl9zOWqTAo8YIAPkKTfkcXI
SoqAv3G+5kQAWsSEZtntHY49ni4SFPBmaMlpi6MPuO9rUlDsENUjhw4DVYv5
vChpp7y+JK3jbFrJ8pCqRXOmfB+B8umtXINItDpcLHMFFfuztJSvYZ04lOIk
TWEJtdxYPDdizxHLivrV4FEwNtCGPnzI8GaMx+lcL4QVNCMQtspyKWs992nR
e0FkuFIgNugdpnX7moU+z5AiMxkPFCqPga0/7RCzYLBFRTofXKp+XfTxbs3i
+Zx4l1zx5rZxbc2Rq2+QNMFwnz+jfLnsV8DzU2BweBozVDHkyAeieAa4xfQJ
93lq+Tey+UBLsvqeXY9pcYYmv0PINNCVML4DtyyZA1afslIxTeMyX0mxYao4
X8pdVrUTeVxLz+HLNUpFE4JTtwqokl1WhkCCzSu8KRHAGeXcHMQfWs4jHJFX
CgosCLOii1moZYiO4zRDrQMN/KHye6qc7z//8z+jOK7ub8Vusf7PoL/2z8A8
t39/Lp+4J/Lot/az8N+/md8UIfBl+YiRMNJHv+H/KUD42W965vyr+c0u2x9F
QOeNEj4L//0b7+h5a0fPu3b0PNzRc7ejYBnuT/DkRkDwWwhU/ec/6yAWEl2D
rHj4m/uYCc9f9fEfn4dU7Ks+hj86+Z++cubn/caf772zf9LMjUmaUPiqj5tQ
+KqPowYUvuLjFhQYEMFenoZp3SN+/3Uff9Weux++F4n8iR/rkf/2bbDu50/5
2E31Nct+BOGfsGw775+e8DHf7Mb2fNq58uNV22suJ/z4b73P67a39uPWDp93
fPv3wDDvY+B05vPL6Nkku+0XInWzN+C7DZXCOzwuX4y5QLs1WUqd3Te2uggK
Hy1xoyW0tOSNXijDR6BGz0G6GIMKQhpXBRoxGjFBtPJX/OULGyCundSEFiRQ
d8akvYcW5s61DchY4A0Aqi7Ztkli9j/P0BjWYctQ+ZrsBJ6OLQK2viVWDpLB
RSAHKXGMUhRJI58/y0RfvgzIKuCtCeVAFFDfvb26tutpAbUhkIs4T+7oVeK2
L1ar8VwWDIvYGzTExMYMcvwVW4dWrksPG9ZROqjvNwdvCXRWYguGZ+PDDA3I
OKJVbDyTLWqXI5C08yYKiHFjrTEHhH21rTRRQIyV9XKO/ufpEqTc+2KKK5zF
H0WxCVCGz7wF5LTzPAbR25xXYNbafXzEFnrD6p4DUuM6Ge86IXDKtF6UuX4h
YwSOJHet1iylgetpa1F6mwUJFd3pGutroB6pQVMOOstbi7I3WMT20CIXYqW7
0E/G23Ayqw2Ed1Bwjl4JzWEO3Xit4XDs5IvZZe7jIW21Timcocid7wNdp6hI
jZ2xjdwXpF3F5AXxcF0UVOMpjittUOxkQVt7Wcc5eopQw/MtYG4EGrClNv5C
7sGOn9DfEGOgT53l49pigsAbjs08ZhWD35dkjRgVaLkqbvmOtd1ycofal6QX
wXXjG7QObdHns8gzRNuSZkiyMSrqxj+9Si6Jr6eu4GqCL0wb4rJE7wHa7Ey2
hm+RveuZxgayc6tls8S7ria82H8T9PcLPEU6xB5rt2RCrqL0ExCnrDZiblKf
ABpm8CquvBOh0bNtayI/6Uh8k0rV0IDaEhKIGt1inFY21mWT6+MbU6VphJZF
9MT0BdQZbSlLK99Q4pkPAFJv0MZANhqYjKYYwfCTTHbnnOTkHkQrU0SmF4va
agfoAVjGd2TCReY4LoqP6AXc/PxZAtLI2Nm4gPDrlVy27W1dAb5o0NOBTrh4
CqiUU2BeJA4VGvT371+dHh7tHsHLLauTpSdoEQV2a1aZP9igkYlrGKAwWUxZ
lMl96Bri3dZssw4KbeM4jD4vMwy2cVOwo1miCaMyq9CJ2XAsz4sKzm+aGpoI
v6rLNK5nwukC43C1EPcd0p0pXiXPAS5utSSdTwuyHxFltg4o8Uuj5Rvtm0kb
mnjXMvRTloTJU+QzOOoUXV9xbgirSgqgU4dtjz22GGSHh4Xhd+hWAsiij3bT
c85u6SnAOow6akHKLOCmA6ovYryI6NiA7dxlt2gLK+YSphhPaR3dQKdVecsk
EopO/KaHVcMcoojiHGjEnqH1czyISCKJIrb9ugIyNu8pBGOYsc7+gt7NEUdW
oEG/hANEzwqsFS49cWDe74oVA41J4eLep41Fy3mTBf7c8yk76hSTQRGFxAcU
Q27JVhsYOC2oi8U0YQs3oBT6UGOKYR20Bs+I6MGps2+jgu1J2IPz3TJdwrig
Cs3mqXUr9jXQYZbWMTqA2ad/cn5yxqNWTIJ+F50BPePomcD3+zFdip8Q7uJS
CCN7QT2J1UROLvAF1fgj3de8n6e3U5ATkIZ53mR0ZKtxGQNAPsWI4kQG9Xoi
AbL0GGkJefq9u8eGV746SzGbE/4Y8XTQcWG4JXxQAjkEJPP+FVGACOFgiR4h
OnZc1PSe3DdozPXJNYao26gdWQSSMWebB1zPJi1HkE5Obod0Chy0RgK2GM2y
qmKXlhdIryEf+DOiF3lW3MQZ+spQ6aoLdhXAgwSWOsVrqSBB5tXBuSpy2y/n
DOZZgdEIGPyALhzEeqLyiCmsTFR0fwBX3NFY0PMZ8SVrmPtJmbQaE+6lD1Ax
sJmHtLSBFAyguuGFEc5bRn3ZCfkOLJHAT8gWbnArQEiJOdrIMvqS2FY2WT00
Ut8qXSRFvpwBeAbmLZ2S3aZ6yciGbg+JfUTyDTyH5SzhRot2VKWYmGDkpHuR
uyL467Tgo+1X83QMVH5sdaZNZdogksGXdAnrTIAdm1k81wjzrQHZJ/TiC/Ca
ARi+b9OL+QtJNloR0MNcGesmgxNB1bhcsg4FovhfGAC3RTy18V/KtETCOy1y
uqGIs0gmzjDeg1ZXsTKKHrqHArWRjTcfrq43evzf6PIt/f39+b99uHh/foZ/
v/rp5PVr+xcjb1z99PbD6zP3N/fl6ds3b84vz/hjeBoFj8zGm5M/bDC923j7
7vri7eXJ6412sAduncOBSF0BkkPyaGUUdER2fzh997//1/YeAPefQOrZ2d4+
BuDyP462DzHCCUOVeDaSZPifKPUbIJ2AGnQnpsjs53BW08oz/OANQsrwR4TM
n15G347G8+297+UBbjh4qDALHhLM2k9aHzMQOx51TGOhGTxvQDpc78kfgn8r
3L2HzahUEnwxbSjLC1CLlmouYjGUAKpBRMrF8W2U1gzr4Bim87s/sp4CEz1L
Jnmf9Xz7uGo97zJR6EvAP4Fx/kf7LWZx4WsVbnOF2qFvcjCS/15TA9E3JaBp
zZjV0wetHh+109HbnKGhGerPHMWsQYhwCJi/cKqRumQWqFuhX05Mj9zbFFxc
FdbyI6cU0W0FUQrFtpc2ZqCpqIojvctcaCJPu7ehhRRVWKaTtCzFhWzNO4ml
X17sp1ORYLzdwa6vJbFWAwgZbXhL38AtYdwB+cwBmykUn5g2KsdR9PklLHt8
V5TfbTi0RPtzF14yaBvGN44EboQ9iU3w3c/nfRfLLRZP5773LLGtlQjudyyF
kb+xFjUG/S2LUUvZytVUuJpV90EXlNncw3LJ67F2sC6YMrt6b+0hamiKXDAQ
Sr1oc7mdrjO4oLEiZ2b+qZbwR1ZHSCpGJGM5JxYdDi5dtEFXa6Njx/xDsN/m
jHLTSmfUjTm2WSzKqwJQeiDfUGKAb7JFxk5CpIt26lnHR1Z3xlf03EwWBXr+
2bsB9cear5wYZknExqwBuH2dWBYClYazYF0NVCFzXWDVnwCwjc0QNK95SR48
MzaFMo2T4KBuszZbxvRrmNoZ99TSThJBpz4o9n7FQrIVFzaaBCngbU6GME98
7bBJscSGhpS6Y/O8Cdp7wHpFylVZGB1DVojm7U8WnGZTqZ1WhT3DPDlh4x/H
rA6IZBQ2XgsO75bldZTdYb9ovYS1j5Y1idgaKE4PxOuGy1O5yzj/gq4jumH/
1SbIVvdbNz3RQW7yGz2wfDEboYFCp8F139zjz2QA1UXdx9MFYtnJ1enFBQpy
9JfvQJwbDneGIHekuhM8erSG4N9vKhoIsw3GXuR51wp/hU82q60bAMorUovY
TOSESv40LyS5UaQea4pjLoMZtADYCAkc3ISU9HWOB4djsh+DKo/xSmkLBBhv
RroYGQdkzlhsSaBaoDIfc7qhboBDFTE6+VSyCniOz88k3dY9+4JyFwr4wVMU
D1qvdr1Ydb9prFhgY/XjMRlYViTPtAZeaUL37Pmem5fC0Dp5xCBwB3MoMINe
mURSkD3So30uOpleZPWfVFDQCs1YLkaJMYS9FcsnqR/NWc5SiyoJrPIuvhcc
Rv3OOFvLoJXspaZSvqgSc42qHsKyEhEHXWaVJxllubHbvUun82gSj9F+jfui
ZZMWyVZ6MszTNKzSIgnm4zEqjaH1SDwHQRx1kk2AhKOIpwIg4iOuW8wfNlPH
5rWI+4kC2h5EcEWZ0aQ5msbhdiWwgzojDG+jGt8Cmyxey0qFehv+l4viQ9Gt
x7H+bBJgkxsl65LihvYeIQ02k87olEQ2StTax+gS6V4RTH0Jp4cHQ2HfYvEZ
3xk7psV/zRthDbyo2VVG62tjDymzRnPX0NwGpCWrrPdLbN4qmco/iXzbm8eA
IGyz2X0dQKXLM0XbKJEvlKtNmBxhrUCDIMjaOkem7N3lUfiDueXvMKMJ9ybO
KjIJ1y7m2I6NEAsARt42QUUT+jUlf2Lz5/M3W9ap6CUGkMkDN52klO1E8wuR
NJs/n73ir8JL6kyvYqR1LgXKv9lE0+uWWiGAi44zMcE+6yK6lp/61PcLHpTI
pe3jFxxn6xH97gKnKe/GBmGjtcK0oqrTCADifBdezDZKBT0Vi1kootCEajlD
c2Y2Ni76esBGbPuTl0ETLLAV1h1HAFnNTGn+lpPlGoD1+TPf2L4HlS9kTamc
zN6CjYTA1tOqXy2B1nwytP4ru8gTFz3+WQpU0HIuzqLN7YOtnj4j+7l9COfh
To4+xH9euLVvHrlPEbjN4byMoM3L+cfod5H3QefqXqf5LWAXjhJ9F+0NBgf7
+7s767/Z3N3ZigaDAS7Yxkc1oahBUieUzw9AbOEki5EkIfcEwVYjYBj2xB6K
lwwuBx/V4I5QXmHJTGRwfaWyjJLI2mj5iBMc8wgdsEVf2j54ZHzJyPJIxBuf
RNDUckdQMNePE85CqKJAJFZB7nCwrRcFMBS+/qMN6SHMOrk8IT3xFkBWLv+0
GWSEx3nMFW8qTFGnBKoXd/OPKf2/wSes2vEM/woHOOtnSbWlG3cYZdWb8CJb
IIpixLEgU0YrNfW6L4CB3wBm3jh/LSw6Sdls5wYDlSNjGd+CfxVc9hxUdNFr
MD08QhXiu1UIOlo/zI13hcIN6wQ9VXnTNbeFBWaxI5CVcd0yaX1vMQFVPPzz
OCvpBjgS5lLRrPjTYjeKF+hmUj+dJcVrxFnlhFiR4Ntk+j39p/7eI2Avv30B
D+h5Es3i8mNSPOTfbWxv4DMLWfuBR3lXY/ZOG7MDqvl3wu1kIrgNi3+RJMHm
hBJ/xe7oiydtb3f19njav8/+4jRO2ht8gae4Qip4g1au6Ho5B/ntGVf5QEn7
C3tcNrywiRfu1w0ReTmUiQxl5AdskUJytGXk/klA/JpOBSAiDTWl2Otm+B+6
0d3oJH9mFNySp0avR5trqL5dUYIenIPP2bci66WCRyhpoWk50YgbhDVD4IvI
EKEZFy+PWxKVGiimC//X9nocsORuUUogp8LSHfZnMJg5PhE13y7V4xAjTi53
i5CMQEKmgOe0i3aw7+OOXKAcn9tn6hZW6fBTjoE8B5ZYLzjXGmui6CoFLYY1
VrssMVLwfagLwyFvt6AxuogE32RltV1ys5+syHwTYAb3DEbr83NacANafNf+
uHEj4wsiw0c3G956/7T5jA4fnm99finzfLdBQszGl0H3mlxUaceiqr9mUdWK
RRFDPvHCpwINhPLL9PQmnpGoy75EwxscXhU3BCCul34RTxk+nS9KrPWU39ow
PD0GNkQBzfBgj7qErgFA0A1wAZWYG6pGoLiWVvBN+xIRiBPNOeQbRU5dCMrI
P3gjvJEFbA4GW4F4aodQufSdzYvWsU6Z9ljr5rz1RtsvQSbJx3ZNRgE89lsp
yrY6tZMNdJ2o7+hfbEJl7BsJ7IY7OENJyktVRwU3R/Gph4zUxex8QygYbAZl
LCoNgkHG4xLUsk0YBY2QN1vfiB7FPhg5PURlB3qjl9qFxa/aSTveU3xF4kvy
HUsu7sAEmQBF6TIYtNiD/LgOvIw9nav6K9StxzW6RkYBDnLFML4SGB+BknYJ
+7cj9N9Z8OrSurDZA5midNe2QiXrcdRqgKDnb57/YXjXvWC7vUf2yZgXbs/4
jo/08YkjnViHsrBmddD4HIdQy+f8MssjxyG2/2JRzxe11jW6oY82t26cbd6z
cHiRpzd4kDfOLaH6QtzwcnSrLkxghad4FLZ6MoWtnkBhefxuEluFJFaW8nU0
tlpBY2WwdURWXvlrqGz1VCprvYIrubm9DCbGiMOxzVsidOsmfi0pppP6uf11
kj/rvQ6zPv5eBFB23kkBvZO+pC0TWZrFnzYv8150+XGLqBPt36dO8tlq8qRO
/U76xD8+QqDsoeSYOILofGnPRKx4AUWx54uXnV9lBRyxKiMXys1lfoMC083l
R72r0wKLVNE9JhM6iL0UeV3KQPQJOQDxGzL8VFykCecjQ7HHfYVsEHUiC0mW
k8LvUYqnK4pNNfHvpyRGtC1jt0XWclsFCmP2/I24q4DCB24cV32fUl6F2EOE
iIWmLxjERkqQwEiMXYN9grvujPy96Eb+dtMT2VWgLnkaLT2L1AbVwHxzr62e
4L8N48N7v2YJGqIk/887UJwPSHtonAPSAh/N6COdzC9Esmqi+cf3N1LD6Hdc
JsyvGERiWXOWZMJLU3Gt8Qas6wbPkV+yZh2bBDklyu+7OPJu5VTy/LSQBoZW
hHmh3dEfKBT+6s5HjoTpoQlUSpVQnEoZnGxcRS7ybhur4srkHr3H8mUoD9zc
JSV8Mlp6mrvqNIIbAE57rJhGZo+rAVIPeFRKMI2O+r45kAk+lrjbPsAfcCz5
reo1cJ+DJbrsh5xg98MiA+pzgw7nm+7FU8CA1cQlQGBDOdwIr7lxKXEYiBr9
JS0LmsnWZhQwiS/wZVN/Ixfighz7wHpwOD8Xp6k6urjv2DMxyh444IGy/k4x
iSUlO4+UWUNaJcE2uFnMtqCQ5psrTK/4Ia7SK5SjvFSh/cE2Gbap2pdULLM3
0rtetlIJxQuVfK34NGldGj6zZFlQMl51LTfVuP5U3yjbCP13ODzpOZzKK7XU
HJ4GOyGB8CqNp7gP8fxhsIZMEOyM6oVbii77Smfzetly593EMaLjUkqyRuMM
CwDz2sf1DecBnzqTVRPt+XLQLgTHx7U/Ht9lDp3DVanoH1xlmIU8yURRaCzK
p5oAC/2UJn0VZ6kul8Tq5yCaAT27XWBgfEa18cTSgIW76C4vKCYZ6+bZ4CCJ
biN5JVnwSAEtQFECthR9J/dlU6J1tnsRX3ASSLw/8vsO/j5b/ztRgtW/C23Y
2qLaPM0VUDROeDntzWyOGblFD1u/we62kFYCOBFzYB7vigBu9yhGZcuM8Sd6
ZUBYt7HR0wnpez08t1AYmWLoetEYXkFIhlXCWjb/JCXEWEnwEf8xgcU7WZE0
B9F1gZ87Bv4klsHE/h2gCmBv8AsL+443d1Fwj3o7fCdyP8YLuD6mCvEzxaub
+fi41UiExtHakT4Vc0hNoAQJzqsXpoVMyR1+UyHPx1FCmcLb28AQFR5EF45p
uVgbW5mYJR2gyuM73QxZw5nVzVQC0Fr6a6sEYMwkHXJalkXJCxjJAhi4IXf0
V9GWWtp+pcfXgLHMuabYAjCQxRBRZICFzikZ7ikb+W/gs/aMuK5AIDD0QI2F
7XYgK51xAFMqJuFECytXNDgq87kmT0XhifhMbwV3fQ+ojXN2MNiQCwnAfYbB
bJRY4FkqLHDcxf3eztO8wf3KLu4XcvWerbH8NA7o2C8HbNBZE0PNo0mcTZGt
IO4K9crkcdXAonX4Q4VIBIW+nj8xQijDUcZiGYilwUCZmep4hO6/mLk8xi0f
ZZeP8stOhlk2Odn7TeZwjp1Z/Y7gDu/SNwNCKWRtlmVdP3qIZA+w9Ld9QyoJ
buV63b6x24s2X62yaiQ1meDYGLMulr5Su1MXE9TgdeF1/E+gDoHmFDU0JzXK
hKqTfNusTNgub2hDrwk8Vm5uwynugKK5kb91KGnnnyjtPhY3AXI7+otqgt6n
jgOvIbdiB9J13KQ0flr+quM42woxUHk84HXcaAJI5NMez5AikPIjUtACZ+29
N56ZS+PASZoIbD4xJ6h6wxDr07KhYh1ppP1bSKBD/imK2VO1MhzOU8wsoFQ3
A374o8XGqIQVwrlwvBKsXPYQbFwDWjDdgDUEi2u/0uZumEGdS+JHLNRSxmap
Z15+DA79Rt72DOdSFUCsGGxDR1nCBvWthiFb4rKPMxTe5gspoMT9SOz4eKCC
jt/wGiqAqX6R2UpOKhvwbWddZ5Pqr+DWfZGUgzM7oAF88kOV6kYxsb57ny7c
GHeKMaXC5HOLQ2qtWN70/ANCxOs30E6joYPYKxrHQQ5HawLvR2cVZ2EEZ9OC
rtN4xI1jNuDpBiubujdaeXuD3j4Y++H8GTThFuAS9fWkw13wnWluo2OlPKys
Fcdyy6WfcMEHgd6uBDbC7l5W/kMg2fWjMtVUoi1c+Dy8yXtObhE5haNXb+YW
t3AAb2Y29bI1QlX4w1CFb+LUar29g5d4eGpZgqe8N4d+XI8nUbVLlVezeXNI
NKHzvr5edhLy+10UEvO28CPMgYiUCVeAwgNRn03fUWHwvgeCVS8Kv9sC7fUj
vCHEaRM/6AlD2DKKA/QC4vwmvN3ji8GrcGjRfIexEd7KRW8njV1HFElJLgvr
8bwuVeSF49vFh+v2hCObNCJy+kq/SUtzj6zmHqnXxY42yUqsfo6yagO1RC1f
ha9EmukK55JJ7SiHOqzqgsPf7YVDD5ZHiZyWpDeOmwDUVJSiy8DYU6Nbtwjj
c1/fyq1yUWVXQkvzFB7HwFAs7eZdjlyJroSfMIeWPgJWZ+m10d/LdRQxmATg
1ZhiT96PwvHzTr1QPnGzeCE9xrxpBGZpUofV8J+Q2cqClgTJwQQ2UkhjlCRo
zgW0qSusShsBa62wOfFaw7+ekmLrx9KZlbF00V8TS3cZPnCJPC6UjUSwKpth
Q9GGJZk1XC8rKYirk01SLSBy/Klg7wKxfMmQyoMtsoR6HBS5wT4M9hoH86I7
2wmO6JWIaWedaSo2JVR2ZCMP7NwEylAj8sIR3BL5WrmM7Hm8nBZx0iqAH3iC
gpi/rBmfIKAyDjYivnsl+9ZohTH3JcotjMTgrSsj0xkcu+SZBSFx/GPIgDbU
c0aUBTVYI4qMjUFhbcU6GuTnRlkjt2OX1tMzviMJszsXaCqPtKyLRPbNqDcA
A50FsuapYh+erJpFfpkRE5QmcanFUl7KugyDyTTDL25ci4GeszetH4fAaeMS
ucuxunEerWAEPUnGxSnI14gpyQw1F7dmwU3AU4XQApkErooTYjWvDnF+0gFB
wXdf+8eqTRptqoIa3Gmi6UHMc5IjBaUX/bDMiCvWHe0d7RF+YoI5isKcdQYb
65nUK1NgiUmvdba0NIF67XKyGRxm1VqsTSjaJLujZ6dsuAMtQLGxoCF2txXg
ppdlpl+qpr56cpHJDA/UQmwJSMbr/IHjiZ95RSu83ECt6lk5h9/Ksots0fXD
XTqj+BTTV8UdSqJ60lHTNzZfUzXYv1Ip9Zmhtl+UZokud8MxaWEtJC42GFJX
rziHa8UEy8HFIE5LbZQP7y+UV65aEr6tx04hLxI00yyti7hoNr2Ad+LlW86V
3Ak8AZjuV/sHIfKj6f+JYHMdct6c/MEWx3IF6ARsXiKxV5xOQKpJzVmepCA1
JSvKBRtfTNJvZIiOTJhWUejpVEpPwnfY99CEvbG6oVQXWjBXKz70Iq3KRSEa
tuAgZjC8o+4nJ9QCNPsLkyv/BCtbvSgUYctimtr6U7b4I90kr+qx9hvExFW6
YMJv5IxW1kGxeNBuhvJKyElQPllO1MyoSJ8gQKvQBzMkNEHaDmxSH1r6TlXV
YiaN/Cgj33gE0W9WqGkdauwLy+gwWOKgrB75By2hoip0ljyXMSm3JJNVtoFU
0Byx2QMmbHRlobVOLKGSRGO6RN7RVIIujdNofw4zNEsVNWQHv7pAPL7L0ntm
KFqWlEtHczG37jJssGeVsTAZ3maMFyOqlkfvWmmUpFcYT8oNWfxciVJrSX17
w+ScCZC4Sf47SoeTlAFwwYw6wSO/T5DnevhEfZcsmkhpFiSx2WPdcxgbTDNP
yauxOS7mmV8NWcseRydrmkIhNSxTbK2uy/RUlmJE30zJDxdP0bWkNMXBgeCa
F44wr0VaLQeH5DUohtEoJO567VriI1WEqaFxMTG+R3p1MyOYxpWwospEK8oa
m2ZZ44g60HGHrPADwLlfyB8f6BPi6PAO4JFi2p4PZXX5c69ceTweF7ZjFP2y
0BKLuWuautSUMhfceeDIlAiNMVM3bBuLQEZhlg0GHazJnR0K17eedV8Xpu5V
ENzKAi4+/oz1hheIk0n6d6IS+Wp4EZl7jHCY1ec/eCxQxXI4267Tk2UbrMfB
a3PNQWwJdccYQCYL4kTgy5cvgwZdmWK0LWsVYJ8KGX70ei9a5FRkGV39lQlj
Qei0tZIJ13+Rtq/cs1ODuT3pTU8kzN0REOgF43EfB2gPS5sGLb/ypdtOo567
14NE22xIeYSd4dB91RA6G8tUp+trrsjc7lggVKanZNUHLcnYMj5L2Zr5sULK
7pwcxWxcsXc1mpKz1mXqkpydmNw5upOTJdHC0uPopFIxTCs4d8i2wAdGzjxH
dbKWQdngsHx5u66wV85oBewfuWTNCZr12Yj+cNdi81QyxFZOD+KuVu3+cC/a
1M4n10wJtxSRbRGr/cHBYD+olmhD6Skmq5EwQjfEVfghXF2MEUew9roHir83
RewW/Z5AE1fW+hfz3IU7YThvawqVLJrQNmMPb45VFcggfVsiKblPfapCFZhl
HCKDaEYlft6Z2aJZrlSnSZom4MukxGlR48xfptnc/vRpyz92Cc7hquHBmgGp
uMeGKF0J0M06mwoe11lpU5Z8Ji++p0Y/5vNPpOYEujBh5fZwiPlgcK8XLbaw
PdRAZNUk3JLwOg5cPUcVnowVSZs1qm09vDicM6WV0Y6/acgeLcyhWfyYEr5E
2WTNoMxiLGwosoV4ARX6karXXE/RUnwVKn0ztTCCuNIaYv46JNszuO7R3qdP
DWGDJ6baHpwu1ay10qF1pp3frNONWDdnpEGk9orGb7qmr9JdPZfQTSOKfYiC
4b63pLKkrRfmES8eDtVFowKyN29HX57AsqSF4rWwpRaaeRRgbeIyQauoo2xU
G5IB0ShRtRq4Lc1SpZiKTXQdljYvxyrzPCSjdBwvxEa9wv5mZvEUCQQ8XFGC
19Eu9aI5ck1Cs3ijUXZ+pFXOVwnKHF3YyaH2QFjY/CG2+6DWFz7bilawLQNs
a3/gtUIRf9kqrhamlmx5BUFZlOgoi2v13kf4nOCWfBHiRtAEIY1tm271tlk6
GMicujpL6vBEvFL+HZUw+G0MiB6jsmMAZIkd6itOUtpgNY/UtKjQ0424KmaS
+KWWvtR2FbC1qLlvy1OoGZ6Fhqmai4kzrzjS65EJKRSLcF4dPcila6nfhwa5
OyPG2Lb18yDuyZHCqHyZmwqQuvOICo5iwTPhMnJX2S2wcUqGa5WOeVcWQEyx
vpkrHIPJsfhQPIPyL/WZ/NO7929/eH3+5ruL/tkgS+tJH7+L51m/nIwPj4aH
owyNAMCBNzS1sTutEWeTsfvkWHEr2PCSK8nkso534GkzwWIzqltsqNehn1zg
LU0OVuRJELjhR0VsBKqDcFf2Hef/+qCzxedyWzHSmTeY+b5AQUXKTnIhOtq+
+k7tK0i4PLplzmIMQHyDSYnDw+hVOgI9aGcnGg5f7hy9HO5HP765NpKf3cdA
gpd+36QXssDnfwbmaF+TologkBzAZjYQeBsv/4bj6xkpufKSIm78RM5Fjj3s
sWqcn2fsgc6mGQvY3pM9TRMWuqrPnTQ72zmRz1qIe07rZ30I8/1Cu54aGOVr
UOGX7INeS9MWQUyOxT1/QO1aUhWNGqYYsZJVZXqLRghHqV0HjrCSbCLLMaO4
ypz3Y+l4d7UY/VlcA6yjCGvAKkuJ86WOlusMQH4hfh55BghwK4p+Vn0UI5m9
Hq0bYbSu8F0KKldVc2O0skCYP0hjtYz0mqxIpDR2mU4AAncYFgIMrF3ps2ni
aMsBbe2UIIRd5QCQZpQ2FEx2cF6pWngqJULFqfv5me2aQtoJOz5SvAA9xwUe
MloywBvdJr7+UITBE028McorAibV0bne8xc1Jgss1iLAGm2J5Ndvl4RFkrhc
p0vbB0c4j2a+kl0k7MqmyrKsY7PWRP+as4Xk+cU7NIWgisq+jtN3iHkfzt5F
NJSUofYG4hguF4HKmVbqsdniCOgTkOW5aLLTzdKuurQoj4tkNMeeW4j1gr4f
ST2X8FUOL2hYDWwtZ9lWMws7Fus17510sGqt+01KlGHF/HJB3ZHQFSn6RSSd
P509aLSMnuKYDGLFrNIi0bFZbTTtn3XE5mLX4KO0EtKges55j6VDHRUe87s7
cRg9BuloIWt2mfANShMu/mUPiTyKjQr3co8t1aMPGMbcmai15BC+9L7s035g
q/s+4obrUFkMWW+4AJoUyA/C+hmsQiuwPLUN/+AKc+QF4KwDF9LP69NeS4+2
6uzwEMKx2Oi5hnEV0XatGk7vr/Q/BF93my1QqqIS10F5dImfNIucejly8W97
8+BAU6nrH1uaIgYzTNC6Di101EkxsYY6ss11Ok4CLUIUGQFrGJ2vVO1xF6AG
J2BRQ+nG1Q7OeJIbl+rn28KxxutzaxuJiKVbDQWVvb0xIAt7Q8N63AMSbLhG
udcsQbSHoDZFI0ZPuuRJr01pturCyuJRcY85d0x9phhnKEUagegzf3gf3lXb
jQIrNaL0xjZ8wAW/N8qapCpKnOkw8a08Y5xFajhR46CI2z5h7UFtu7emB0dA
JnvRMvUs4TgyDSyxwmlifTK0SnRpAKNNe+v2ww3nBAqPWMOU7bj5bAX06LJQ
dC1c/IJ3w8cUziC2bC2x5GW3hkGJ1JIDDSJ1DSe9YHoza/V5Bp5K6+3cmfWL
lGyRa2A6pRbR9UPcsjSdcneUOtEttLFh9CgeWaKwyDP4BmW/vrxDTQGAMJQx
dkyF+ePp0sq3IjvTHcGhuKHkHCv7C0LCHUKuw1OPi7m4s724SbXn1LEUtWfE
dzO1+6dk0rb7Lf6rf3J58voPVxdX1owvK3/fMPOz0KjRFMb8IKa0RnMIv0J8
p/WM+lGxDO2EdFxJLzRek9xDDRxd+ChKkRKJlHaKoI4DIONaONtvS/TE+sXa
8papA925IM4pq0ycc0fGaeYC94LuDusukqo58UiMHGq1QRmU8AE3VI4y+Ge5
bKHjYF1/ZeOaHWqcd/Ml0bWwl+l6hogYGsDeb/7RbScj1UzbIWiPaPJGdsY8
VpF0SKdWHiopptznI2wq0EiJxcAMvfJJ21jW3Ipeh3b7FkTvK+oprlsVaVw6
3jKQ1hK8LK/qlIPHOzC7F7RwbjSPIOEJbp3OTWL7vIDXseUC90WwTU95XKcs
VD2TDm4HPUIXOs4x0ogJX7J5lqMruyfVVLE2HEw60jYe4eUnAzV3ziZjaC9I
54RDuaPGhBk50Ni2TDTj9O3l5fnptfGy548Hu0GYgvYxYU9U0OCVDIKu74lE
ECSGAJBRueSujhvMAPAIfFigsCHJFJi0oWYP28zZkmmfllaRnStF2WCMKf16
7tS9l+IHvHkGEUXuSEwgC71j8exN0/sYAwDiYJPkp2IMkXFME7XkaButssVf
oHIiXCdYN9HxnIRki7DMnTh4wC21P8V2uCsahIusuCR+buBJDPhQ3bV7U9vY
lEYkkzQt6Qr3sY6hyMXC+rEI7dbFI5dM6bW4NWR+pKASr2HiqXR09xq62xTn
GUGOY86iCSjYQK5MGM7l7MrNsblfNrrRrJkgCE4AsabRNh50eHoTfeueVu7E
cmLhnvvVutRxd2SPD6YgCUvjv5wISvdVqfkY9/oQlDtD6lotRiwx195+JNBA
3Ry1bwFhF3o3nfc8T5jrEJTGon5AcD5LF0mrlq/bokA6TZolom9ew01bYmWN
378/uTx7+wZbi+0Njw6QKoTcQbok/Uz1+ZA/I0JzxzjsSu8iC9l/yZ2le/Iu
kxFMtajSbinRRiBJ/DDhsgR+dlhYOEjoMbIvDe04L8XMsjybhfEsnX0vo3DO
mO+talErJXsyUeSPBqk7B78GqGuaHBlLPFyT2K6G4E12G2Xw5GTxQsgqG+Ag
uieD0Rk9/MD4MA5ySqYe8wgbbUSQtwqP+zHoQYgEG0rF6OSIFXUEJHc5M4XY
5hHRiM7beTg48J2dgQXSRsAEsNEpvGgjpvk0l1FViE2DTdhn2v9RnFmuTad3
E7tt8Q2YYS0nkR075SsTKLODkB4LD41zReXJogqGdJlGmXURACubi9ON7OtL
n7RXq9MgvYQbLbZp9xKIp3or6QBX2vIacLgjpyWRJe7r57pUofWG2eaAkgDI
C+KBXs1y7C0hs50zaTdNI+1YlzBoxpJ+GztH0kK3Fb+HveA1ILEZd2ELWzaH
D+K3vWi9JwQNa9ixZ3X1ypY6lCAi4iXBee9zxDDFfa0KDz5hug5qDKuVfk/a
sMcdZ8NmKHuktl+e5AsSKuHRSymB1Wk5xLVdOCIxyKyiNABm9e2ehVamQhMQ
mhhiSSd9hXnknIWqm2gsmUzaekHEsRdp6g8hWFN9XbP4yLUdXz2mRLf5rePI
SUaxU5ILLUTXzxFigURjTj024BP1ngs/CucVwlmpl4/BhcwY9aUUhk0QTN1A
EiPFpGYpxXP9xYvbmS+jcPRDdwyohtP6SUj/nmkbT8GWV9aVxOGvIGu8evv+
l5P3Z+dnKG4c7uweC1Z6uN2VPvAQ3oxGMkNLfrTp53IuNjdjQp7zMJvAWOcZ
pg1L/oGKB9Z0DnIkqaOvspxNlLFHokl0tIKZJaVW7cl4bExF4gWKN5juFl6C
T/FMczX91EFL6jZ9c1wY7+laWqGP0m+lF3Rm2KK6HJnXylxX4xR3XJUXDrMi
PgvZw7PozANMdI3SMuHO52cBxNC4JUcL4kdHUog9yCzw6Hknwb5A0hY0L6SV
D8JCpuaDUIDG0pIdh1Ud4g8rIGwDnHJcLka3xjmsYrpsNmBTrHcRgKiRcI2S
fDlDGuIOAHuzelcnSRqyWdSHFS+xzPeDuF7jKcAxWUr0dWr7+XQG5Yv7RSlP
XxpsU3AbcTqv0nac4/JQs+C2iI5e1S7pwW+vaSUn7VeJsPUPBDB2rK3qeGuT
BvvuGaT9VkCzZu4yzm9pGGvJ03IZFjC2IhUrqe6C8g9s62ZaxHM3JGHXVTax
6Yw2Z92YN0WZFiRo0XQcHc82Gh95OSZrJoK9Qkyat91KywA0E4LkYEYpaJcZ
5tiw1QeLAaSakIH+8Xzp4XpO3QBioNh8C/h2K7HCFM64KXbQnZyCnlmj8RDj
p6Z+MpLtkoeYT01aV2yFsaQV3S+Cjea/0C4f6FZxqILDSVorOiQahvmvRT2r
mOrKg6T7bOII7F1RiF/eAQHj/EbTYvyRAi75EMIcD7YPa76Ni5JT3kbqt/Br
o+F39CXFPFrPEiM/7KKv0zQbEzZ6uxrb2xXfmmYf02l2V3D2NbHLFSejfmDh
54aUa9/0LgBBHo8m9nlcoxWQbeCjRRBmZINxrVNvrNVyfOWG2B+JWS6okc1d
0hTZA6L1LSmOIJMX01jJd8FgAQ9FJ1fkdUQ3+cR+iNeNAi0Zj/10VasbWsvg
BIA6ivGc6b5rpQPP6NQo1qCzME+QxCh3G6bLkO1YxueVG6bKOngmsBVtpmBz
n6IT4+k/lDqmhUHsWnnuvhoJQWSg3s88PSx3RO5P2D28M0XboyUwsAy5MX/R
WD7itmmOyAInfYVS9xiLHyRFpbFmGgKhouAImPgkUxaBlInQh3pP8CXyzXwu
4kcKEEnGK4WXOE8VShASPsAI8aQYAgk2o7uBV7Uk+s8BHKGpO5S+tS23/wEN
hcQoyMsS77Juky4dbRSLAc3CrbKFajzFABWyXcTsLqprPDb12mtoAIXXisUT
LxDVsubBy67RpewmQY40VuV+Zr15grxVloqRZbjyBpapeHylnwNbZ4tppS6T
ykE1lhQYXTAI8ROWnOPhPL7S83YvrPYhZu7XdC7xaGRKZ60ZY1hpFEqWYB+J
RpQx6LS8dQDhKx+hUlRGpS1PzjV3HJ4oN5A3paV6dAfLdJFYvBtRrohtqPsx
cG9aWKSSuQHPdCAOUqZLpw7gE3XLfn5WY9GrD9yskOJQbD+ktprEHKYMPIu0
eYmJBF7o20NtkEQ7SoVPURKkFYxw1TMKVLTGcs1kIoIkpIc80YVlpr7Vf+Ft
w0uPoFWYuun8HrFY0VpbJZZaTDZGcZJ33Wkq9cu62KUiVCoRTEy3YNIRtiN6
txsG9Ls7pBOJF97yhFIUa8JqXAyrJqwYyUt1/pde1IKTVUVUF6Ua626hGktr
fKrrGWydxkQjESvCKBXKgsMLLaazHnAK9vlY0kZiWBi0NxuYM5ZxeTuguGAa
UtohmtG949MLrXBAIa0zl+VLnpm0SB1QSpMgEvAObYxonNUSkuaVp6sKHqRS
IwtJF6rA+a1zcgJ/n4p1k+gPt5w0kRzlmT6CRSmiA510RZY0e58bEF1VZGH/
n0oagDi159EDXsi/kE+DaT7AiQYIT9PTkeiwyVjVih7J1BTNhSTEDtC6TSAn
zWL0eiJSrg45o2wNsgi3olQKUZDaFMmJ7l6hkk5jNMPRu01+XJVIWLjWNdYz
br2NUZDm+vVV4LT0FVctF7okg4vmCsJy8yRGz4uIAXgq2TS9JQe0CJnC6yhX
HztslepVhAOuJdyN53LbxZLw6ntjcSKb4TG3AelZ+x8JJiMswrOYo8mBU/Cd
NmTY0QicnTAW1aLmTFH0Tr6kwnVAOjWI0S/3K32Q/Hp2VTOheXdwhDN4Re4u
RF/vKNln/MpuoZZMHRWEgGmIsN+zR8+Jslo2uX5jUGVwS/pHNWoUesKgZxlV
uEn672Al3a6ctc2Ht1qnRW7FNEu2PKtGpqKqSC8EQg4kryi6hPBP9ABQ1bM5
F3TrqCAIEJ94+oZpJfseqrl9h3utdf+4iyUi2NHCIlB36FZ3HNGjRewlqMOP
RvUPT5zMGttn2vWYPE9UqAR6JrqW621tPi1CFpkhe6XKTseThGrptUA9ekwK
LlcFsFUwXQh4NQYJrswKiQW3lSNEbJLbw2HYj2V1dsc6h+nNYVx3e7COMSpX
nsMFZli7frteXi/oM9n0PHX6oNnIq0OICuQlaaqQXd2RbIKFZhY528LbYl5c
cVqPnZiNOS4eAG2mwObxtDDyCA2nLu5IbyQODdoA/E3YPKLkXTqdO2pyi30W
arZVsf5VNeIiL9DHJB3AbVi/HzH0dafZM+xotkOt1kw1nkOzqZULqpJFdb+m
UieGkpF4q6qkV6ykWydCQYYDZ3d8xG0pMtGKaMqmLrYmoFJkjllWcQqhSxvB
hQd0TRKEmpGNfnUWrQ3lh1diZ6+8T3kILlgHxDLnFyo0oBPXusHVTyvg1jNy
+Rdz9CdqkKBkaNoX+r4PTmXqbFVEvDtz8z7QujhexbEIDuFm5hgoIp5M7rSI
KjVOifMLV7nc/AoDggsV5kml6glTUXVAXPOUvGk4+U0ps010oltgm+2pIO1K
I8pQbpWaZOVXCWDowIie6kn9tylFjnfOnAcDet5QJh0i/WP1Wyy9J7SMMfw7
F2IGfx27OCEk4saqG8Tgy/R2wdGu+CrfMXZY2UAo4Vmc0Qlbw9im0KFVUVue
tUlsoSPfD+OxfV4bPc6t+8tqwCB4wlw1IpOrQavNtviaUNyj5vJxHp/sLAls
KGxr51aumhRIl25vZyfa/JBL0RRS6SXzdcuE1S5O/LGs4BPTCH5moRy7vMwR
F3aV3vo1ISuEAktL+LxTcXd2Zb8mhHEJBK5YHozrr7ozMplC1qjXRCYpd3pJ
uWCIFswgdcXYgjjsqcPXaQBHU7obG3E3B7hLZ2Rp5Qa6djSRZzhGza/qLBU7
QFjtRVQ1gY0siI5U795WH+dudTQY5SDoNhGyVI+yQiFrJP4L5uZOBuNWExxr
lJVSj5K6+UrVglUdC+TLBzjhMdJWvoPVcgYyfckRo0hXMxtbWzVWRG8g8PwS
1BpAOBY/iD1Qsxa6nQXGXeFvZDQnzNq5xDc8+OJhh0uRtpKRmK24ZiFLSHPW
RH2ZkUCtWaUk2LGSxUbTOUkczrqKtveKvLv8kqp1LHzaKMvzlk6sRElKL7KG
LMvpLtTghdeSUeyOwkiB3KcUl9LM6hANlpgJeUNZ6xOn1WrzFVNXXovvCVmU
CD0sdShWYT9m0qxKTgJEQA09jUv0gGLPtEYNI9Ip4RWuNAKq3j9RmerDIZf3
VQbWZ+GR4Y0ihCvTKEZLV8jFpSWzc5GhSmV/SbaWQPfwaGPdstjr1YqHZudb
Dm5pBBSnM9QVcFFl6kt14X5R1rRNfAJ1y/aH9aLGPULUOE4Uzgh/DeNvN/I2
RLj2O8RgsQEqI64YEMTNhNSC1RCtIesSZCMvvwTFRs1x982Oi5woARE12RQe
DhU/WdzeYkab5pBSyUx28aGEZqV9P1AgwOkV4a5ogC/QEMWJ9ei2RPcDWUmQ
ZsUGC5o4CHilDT1+zmYflIjJaxgFtfTCwrzmIbbFfpBdccUMKzbx3aRyFjvR
+/NXH67Oz369un5/fvJGcva5UI8LQT0abA/2PMV+q2ftCC92o592f31//m8f
zq+u4b//en56fX7WPU505CqB7dIolKn749uTX07+EE1KKrjDSi46hNKcg4ec
sLKZ5S7xgHmPEa60RSgOAIZjRJWO7706WMlMGdR+LMYgspcIDK3rYbgo9PY2
XHPLO+AjDMoFxuzGozh/WzZZitFUXJSkho0vuNyyUa7+lQti80YMe+7Ldbfq
TxU0I1hBoWBW1lVRRvFQPEin8ntHVIwQQZAN8EzqvAL/KFGp2wSpnbp5BSkz
1M4I5T7JLqbmPdjJQ+OJvE6nLsmSBGQOncnUh9XXgHx+bosxYAkKGEejspKu
EP+qMCjus/DkBe8BLhApcVKHRNoQjqEm+gAq+UzKm43E5ijwdyqnbhRpZqjv
2gwbCmnxWmmozIoBGpUZBwXvWDqJuMY6EbXQsaWxbeiJoqPyk5d90yAdYfoJ
zzdDv7p1oJHu6aUay440LEOiIAl/HCOzOTeuUqrdKJEWrjNilANRCB3GDPm5
TbZ3dTFX51UiDolmicRYnX+wutfqOA1LzlrNuYonqdhsK69mDMrjsJlqAsAp
Stbpke4bP8Wp5+U4UwBHYetC5ffF9N76JGdZpdUWSQZARcc4d5utmQ4gnM2L
mq3A/pJG3GMCGc+CiwpZADLQKKKlEROZzdDiK15moPbFbY72Ji4WavHWm9P6
K6xshg2ErQNGmhzL29QSKM2t1i6HJ5jCDjyrNfVFnr5RWVvbUXHwapBB6hwl
dMMkh1jb7rHHgL6u8LJK/KpL7ypTY0UecTZ/YOhiLSU6yBOkfyxDO0eEWENs
f4PoBt+/CUtSZt1iXqUlg41nxEVFcV5mMB8GOwEPvrXIwYWpOnsatOxMTnnG
Fl+8JtbiHBHX0HG6jYQBAQ2WiGTJSF67Qz40bTvJqdW89XUJaxI3RsLcjAyg
fuhGGKyBwiWnrVirh0aZBBJo9WjVW8RSDWKXbL+gtjTX6qiw7AFgaZ4UD0Yq
d3PHAMkS82vtcDiFx7weqXJHN6WqCxEP/C2rfFQ5hRDj32gdMO4VfITX989i
4Od+lkZivL34ZDXiiIV5ZG8Eyrp+TCgnFag4IEXvHwGfyNJeBKVlj9aih5bE
nFGXhD9lHhTSWz1gCRi3RcTnjEQt3GfExU9pe21cc5kbrXIJ1PtQcv1FSyAJ
Jg+GH6xv7hs6xDgQSN1ZNAqibFCuxlD+OXW8axW3FuHR352Cip3gIlL6U5kG
G2emTTnHnuBWF1PgnFryA8f3P7OxdotpbWCMhiiiZVI1bCujhKY/kzkUJvqB
o6BpRerOm8FI2XwKdBI9wRjtMqdpq6jfl0tgnRioRcApKwODF9SiKs4HFAmx
OMxHEMkM8wkURCkZm2M7MF4S3dW254MXwcqAtAXX8Q4xdwG5MEj8sPGixBMw
42A6VWzof0zTOYxOyQ42iFHOiGZjb7QXS6BrSil9EsRQSuGYUl+OdShl1S7O
YbWYJJPF2qTYz+wgV77an9nWKOVCSTQUOaQlSCqm8sURwkBCjyy9NbtH1Dx7
Jcmqlq4FiWjPQNegOodckAYjfs88zPv8DEu+9SfZpy9PIcVWL/fTRzQNxzIb
2p0tiObdcQxlYcDofrRMMRZ+TylT1LffMmmWMnzmv75eJcLCL1XpLjqa8hwr
FBXasnZ/380ESCSni9zF8NnqkgR4Buj/r9Uld47+huqSBGy/sGRC3F1lMJul
6NDHC4QkX2Oj5qQH0LU1J9VuR7LiK5wPi06eZZUNmbRVKSgoz6N+yOnIvrau
76GT68TV4+WOK/lXy+/vL6/fYSrX/vFwH32cNnKA2EjAW5oh9SC5z4qc1Gce
zeUskpUEBj99/fb056ufz3/57uztxQBLqW/v7b/Y3d7dPd4/GMB/AVkO2Vfs
MnJWCcW+V9y3vLriZVJR1dData41tbqtS9vUUYJMml2CbBd07z6xBNFs2f1Y
E6DVQ2lxFbFHZ2GSqbUX9KyzKU5QdCN3m3Xs06Ant3Z5NiisGUu0N9hRk1f/
9OT0p4vLHymi6BfWZQQkYY6q0WRz5EG2jzetynewyN6sG7RVrUArGxjt48wU
I46r+1vzvK9/nkf8xz3pN3/zfnpuftPDjn6TL38ToyVeBD2O3/QnCSCAvxp9
3/8S/zi26/32m2M6v/Fqn7dW6y/5ebja57LaYDr357cVf6d1/i3fKF158jfP
v1vz5/vwUL7/29a29htkGZqe+HUweM5EVL/5dt2Gnn8b4td/L6x/w8V+mHOB
W170o9/8N5yPz7+IJhAXU/b1XqmEEqRgA5Z12deyGeWi1+SscxR6XVeZAsPT
xJsCtBC1BWO1hUapOW7JxPbFRCxz6kqjwHM0XqGSeOsynU2zEqOtz+xKUqHy
o9HYNZcLKSjZlY1hGMWGAmZNiU3k2Q7WQOzL5uFnEuVIayGNp0wfykxSFwJ2
0MiK9kVnr4UCO93mWld9ZfhMEDvlFwZgfqgVlZCNOTXS9+jVpSaYeMrdtSYI
2lJxxioo4v5xombAtjhaNxU31B1VwqCYvHXKjwr0kvrL/jJnrVP+50sIoraI
bU3cK76HLgsPR0xUY3SseUNvjpYm86WQU3yhjzJnWUxvpHgTqg6ASDd50SeT
zA11feBkMJeeIlUj4sptBQPL8pWShkIwkHk2saq1XRHicl18BIzZEDWBNJ5/
hwMOZaWtZsUhPCo9ZTqRp0s0GsvBUobaAP0Eaumt7Fu+pVuYrf3dNPyg6zUo
S/AV67EWQps1I8EOou55KjGHMUgNAxRO4fyW0hjJxkn7fUU4X1Her/j9MKjB
OoGNw5tEIxkwDWuSsulvYoN0wsr+mB0g5A4k5OZcYhL3wREEk0pMVaM2eo1U
BAhRamNHi2kiZmxqBBPbOiBSIZ27OLwrqhrQG8PnZ5hToIXLFUSc4NgC0Bw/
G7vPbA1jv+1z6GP2eiCTzxiV9aaDblUhMZ2HrN60cakKRjV5hdJxhUOxaIoc
oX2iPGu/1pTGugk9w3kL4vJJb6fZLUWxkKMIVMdinMWagesiMdyC/DAp3hO1
WSHTjAvdau1IaiZ5EX+UxudSvyh5jzxgRY45K3xklFiibjkHfJrD4otNEn4s
VtpbJXM/yWD0bEjizuHQ6dTYYrEEZd8MLZWzCJE5QCdNnBMFX20U05EYDzTq
Or+oenqyie6ShyhTb7tJj7mLxqeIY1K2rSA0Xi7Z0tcQH+8mHldBPKnGZfJI
16+vgJp9cJ2H7bIIkORR1IplHV6XZlfMcaFZDXZdFvgauBg8RF+z9KkKMABj
ohsZOprTV9Rws6RMvp/2ZM+JyhwouH3EElJEPhdOLLYxoEVt5SnvqMJCtmzo
O8eqcVglsEu9bxpaKhHiJPZlXdkaFmhajab0ik0yvDhzIMsuVuzz5w+/XHNG
R0d9GWM7ZNwvpoiR4ssWL5G4M8njHVGJMe3dIsb2oFwk2oYSgOJfUo/du94a
HqNRULDXfKxCcF0uUuNLCZm44iWCzdZpQDRnk452afBdYnx3MdTfhPkgYc4f
0TtdXuaaIlBw35+lYmzlV0U2nh3MOknw8N+gjBWhEc91weAKxiR9SeJLu7At
/cq5SF7Zj8+fbf8XtKeWKZeC52YeyPGVd4jZpdl72RtVWyix/LbZtJNgiS3z
/tXpwdHuEYX1YDRtVke3CEIg63dIG8MaJhrUYGXe1VY4WV53rX+so+LiCjJG
Qj9IxoQNtb9x1bX8YZpfwfbkPduDe+X8gETJVEUHzfdywKu8M6Essf/AjCY5
0S/MUu/JQYc1/VlMjMvaRtna4DYMKChoncAspwFSplX3zBwSVRVeAmCQCFep
gcsVlApr8pkw3c66CgRX/OB1isvOl978g2aJeW+WMvWC0xrtb9pFinmWvmRf
aKNE5gN9gS+jmSIxd//h8dtJgkE5RR5v7BEgG2duJ3G9WToqd4YeH1iF6VoF
R41JHVQOm/GQqhGcA8vzEucOjdfqzgbeqHJv8U+dsEENvirACJtzJ2lFHYlb
SHDCrhtNmd9Gl0kNLY9b+w0furuGdLRy7e7/4afhreod4Sz1UkWxCsv7OdLA
4JYQHs9k4HpXIPMGHYBdfimFX2gsnmTjiNsytdb0zmhiiwlhixIjog27JzTE
Pwzu16RTL/mmO82nmbJYkWDlyhnAQO/PT9++eXN+eXZ+pvi/rhfuSavmvXX/
aRYlChJRs5VKRzv49glTUmNE3d39/reuuVVzbk5Ll4znRrG7Rp4S2k9uMbl4
nbzul2Al2Z43VdhGSustbFoi9oHbgnmrAb0jlabQrlus7WXcxui36mzodb3A
ZZia1UvWZ/zkRRTU9kE7kTM4EKjH2mjiFYWoYm4PVX5fOy6z6X5fy5QtnZhN
eYzA8VdnKfextBvDO00091UBSD7SsfRNtlVk7CkPfKnUOm/b6GkDgeD8ydFS
dgym6Lm26QGHPFIteS1F5sHtCTFOjUrxtmo7XyHNr0ddRHq/dOMHSdbhKEup
VcORjJpU6ONjWA2S1UgbX9HKxcWwkVJz9P1ExqfQCPMseifCU6s3m0pLxmCT
CuwaZOUXMYRoAxEQeEkRSK12EQQG8uY4enWaSkUmFOBtv/ewbLut/mgNDIFk
3NBtuqu2n3R/HFS2Xdm26cP7i2bvHMWQlqTee8zhDIOhoaLV31Uk72wS+YpS
0KGYYk61wqdEDFvPg1Y1M61L6zv+wjIDVskLgzfVEoqsvtESEIgxFQDxkuGi
izPHItqaS7NIf5t3EEQe62NrCybyypiYaus7X6frrK1vrarrquGacpEHba2U
hbgaE+sYEMejy8VboDmOrHYSVCfFbsOsqwlnM9kc8IRL1FCsJDy+LYsFRlRJ
zroR6ziZfSyjpL4WxpxjDKLgUCeqk5AuHRWcwScokIO5SWZOaIXcQ8KX8wlo
wpmo+55q7YwmMm2jTQYWpciBI55jBSoOptcEPVQv7K1eaWqiiqiU4hCq449M
DKf1xvOnNH42YTgiZm6NlTG42EREY2vF8cL9Kc41zYMGGFbd9OL9pVAbBYZ2
9BWmW2R7LNriPpyhBRoq5RH5IbmeZCthp11nXIVlXzx7j8T75nAEWbKAsW1p
GtHjtWRuEKwe3xdZYijGgWqXUAivQ0pXl8g35D6kMXpgFCheBjmbg5VxcWS9
RAe7AJV4TDJ0E5nEPCH02lZzMTqc5ooF/V28PrHCocjZo+Yl5JSzWZE4fJUs
u5ThRRGdldclroVn2APk8uri6vr88vQPfk5RIflBk2YmZ/dQYsQFhluRXtco
SeSyO1r9S3yHAiVEaioLqko4KTpEXEcOpjtmdROSVm9y7WaiiRCeJc0OazDy
Cq21zcYoFr20kBaPST1Own4EklRoi+60+pCh5t/RZER1hZm2VvdLZZrPn19d
nL8+o7AeL3MQxwr6BVpi6m4IsFuKZaeA2AbYRosMHQL8AraLr5ZwbjPmohaZ
Xd3MVsVrW7cE5K23mulI3dGS6MzVfmmJYK4ujGrsNi3SNs28x2oxi8plUMq4
Xk2Z0BIhri7X2id6C6QO3aVaB7CZ0pskUh6GOFtxW8ZzIDtkTcXPaDo8jnwc
VCI1vhAea6MEP0VChdLU1i+j5HZcOCMc8gepPOJZpIm7wXK6KnlpPU+iZVWk
ZZhcbLTxavdzhEPCUf0aYV0Xc+w9teS45nqRiBtNc2358AHX3p69/an/7vwa
U/QmHNMtRnFZP5CHTxT7MJWyjbo4DECl3kG2kBaGmFNLl+wv5BJwaxTADiQD
XRNR4zkTZZTTi0/LPuGmYom1Qag1B6vYf0JnEfDHfl30kU3OeIgVpomGSPx4
dcF2eV289tZKaQtDPqmtDEdPT7EkW1geRIqqPLoMblaE3JuAjWxOLrP0EeWs
uGYHbNymZQpaz2ftSiURoJLCq9ZY5WrSaKODdY3vpEsPfkJbpy5Zql2HWfYr
AkQyznzykge9TgjUSwqFHRIdWeywtcolX8dGUof900nZ0NSFlfiB7QhQ9uGx
nEVpXUgOV5cmKypL24Z0TK73J3XTbIVfJwOugYRr3WgFIusIFqUJdI8Ic7WJ
CX7+/Pvr8zfvXp9cn2PA78E+Zk32WLkRwUpzNtaUb9P8INsfSzPgokuhKH5F
mgZttdpsu2Oe0iPiXGgWyaiG1S0GUFnDgfGyH7WDj56ek2QkP5bLmgHJv8Mo
YBsTRWPDu9evr8LOc9Evd9mUPaneOuWLNAmU1V6wTpCskmSajopP5Cwh+u2l
eUoOfLSg2DnB4AfP7d6qQmA0vmUc9DDw67R0+2fgkDH6HTjNf9haD/KATSCN
qbjOjPAqVAtm9vBUqFQzKhnBbM1aamAIdM7V4A0OjgKX/KArL9zOMraweQkP
Y4JhmoWAQQ6guZq9Vbvarse178XgEAHV87zzYjHl4uTypCGQGPNuSpVW+dgI
6BvOwVltEHZWFABXm2/XJh8QGDjr4Hubc+OdoNnwUx6c13MDaw/Q+bEPdKvn
ysrwW3DQ7iU69a0eVQJtvVf57/FY3IRIMYp8DQlXAphIjRB2iA46YUGgf8dR
iV8PknY+hoMMYzVHuRldtL6LT7HFHW3SgsptTt+zP7lKjd1A9r3Wn585aLNa
svJkfO+yazISd9iIRClu3D1Ue/DjPJ6lL40Jsl6MuVqM6uBXNzX3b6c2a2hX
maG7pqJ3Ll+cwA2fiyjV9eM50F12GwW4Ti9scLXMDepA1OXUo7fUyqou/S8S
+0oCuZRc6fiMZn+3oDaYqTPw0hv0AnuK/cegT/vqrrVxNXz79DVJQU85i7iy
Noqm3E+NtePOKVsn96qMudWSV9tj1a5PnHTrqYX0+7cJaFdzqr323QZxxHG9
8T0s49uk/v5NfAuSFYsCm9XWy29fwMNvk+R7GBX+nuh7ZxgXwW1842mGgkY8
s6l9ApaVH79Clpd+AjKJqZfrpnmDy6yLCsQe/IaAjTlyK795kUy/hzMH/BNR
M53F2VS79rGCntex9DJWY2ETRIhvJ9Qguvrn6IS/Ta1myMiXJ8QagdrRJ+g3
fHuJ14QrNbNHK/fe4HOhUZ80ySlpa7TeskDjJX11cX79CmPnWycId4LoTYtU
d5AapNlCaToou4/NuRcEMQockUFdEqpIIr9L0V5l4YGcIJ9xeEhAajSjbxUR
gi//QYPaNKhNT55ETbrGQxEwcv6LoLBNx9FX/6BI/6BIj1KkDoLUJfuUtkB1
lwj5NIIkFsCvJUj82V9Fkf4hFf2/QpFc5N0/SNI/SNKjJOk9a4w2olxym3y9
UilToAHCplBnj13qkTh9NGcZXUNYk22pwW5thdXpqwa+j/UaUvNqLfLgqNGH
9xcvYUN/TZUBGAHzKfFzSpy8LOroxMZQ4yGgr46PiFZ5xTUoTgF18KO94RBf
kkx8fPL5sy2b8cUFqkiA41fB21Oh1wHdqdP/30DeLtkDf4PStRVEzSf5W47G
TqwL+poz6mPsWTz+SHapU4npjLSOBPlm/Nb1mjZtzLf/BF/+aOsMsqmQlhJt
Kuhus/puMRrAfC9mGDGRw3WeVWrZ2Hpp3n+4uv719dsfv+MPx3F5W0Q1Ttb/
n33pzgLEs6p6HFzWE0s6/JoXfeDn8WJauxf7c1kB/D7NRvgffhXYh582+KtN
mcTC6cB10Xbbv5t/BEzBBLT8n+toWrCdiid+gSVxOfXETyMbAPy+J088N5Lw
G3S13G9UzOoOvRWYBjaIfmBGJrVxNhFzGtFPLm9Katt6rk/Xzz3Mv621QeoW
FdTkCTOc81OcAGefYQLD9d2KtdrWgOQvi6ffsK2O8zCNYpXWbBF3wp3EHDY8
mPPUOfcv8uDLoPgDe5QCn8harxC6GYqJuVEsIx/dQEamm6o6qj7L05rfuul5
bTPh3xG3DfHswrN4HvnhT7Rqcmw0vWpdoVduUTo14n6h3+jCbvgEmvGMFBqX
DdIBg8dG03shRugymXHCu6vwBmOWS6qV1jX9DdI19DzdCn2UKO9VUXh2OZos
p6ateZxRk+IQB2pXlkk7r5799PP5m83/sbO/v33ci376+exV/+qnk539Azaj
2nGxwjS/ZcdHtxE/oobfh3toDyZgyYteKmGGAh0VBko/9ZPFbG52x9sHR8eH
+weHe6OdSXyU7h3sHx8OR4fH46NkPBkeT7bHh3vbBzsHe0fDUbI3PoC/T8b7
o4P4+Cjdjqk8waPdctQV1W3yk6BNFwppXDl98luj/D3mFL5KbOKtjQy3h8Od
4e52uj0Z7seHe/Dvne3t/Z2dYXocT463jyaHu0ewyzgdH+9P9veS0UE63EtH
h/B2nB6l5vD4aHt/fzgcHsH/tr3/7eoes6pj8Rlnw+GFLkaYudJMaqSzyHth
dIZxqEh9WrVtwY/n1y4T2+8W242nGCRnPOji+85n0NFcqQU12N7e4d7+/t5w
/+DoEP56ODzcHY4O9g+P4KSTw+HB+GB/Jz3YPZgcJMPtnYk7cA2a4tjNOHm0
kkSHsTdPTJVOU8aM2aKWyBf2tgIk4SLY/uqDTpLoCrDTMMa7O/LlVX9756j/
4+kbvhX+sr37mnOZfm0pLVVxjKtE7t1ah5DOvU+Zt9bTT25XF5Zqz8Skc0z0
KLEShr2WzUMZjfe3k/30GM4hiXcO9o+Oj46H8fhwuLszORzGyfZOupeOR7uH
8Wi0DUc12obNjo/He0fHx8fjw113RCvvUZsQwPU/mhwdbe/u7qaHQBT2JpPx
3vFxnBwfHh9Mjg4PJ3vp9nB/O00Pkt3tEaziGHjj8cF4Z3g02jvc4UlPGJdv
UP+5cao8MJ/mfAcJ4Nju4S5g2SFg2AQojODfzvAQNn24DUQJ39jja7gz1Csp
M2GCknrGrrC0iOWeDu5B5wUg4hg8GtpFNOSr54ojekjF2h2fZ+NydWXmdNMk
XffXQ9iEID4AYAB9Pt7e3T8eHhwf76TbALTx/vFeshNvD8cHx/vJ0f7ReG8Y
D3cOUhjV7KeHydHB6Gg3Sfb2hqOd8XD7aH9nuDfaSw5293f2u28zNTMQtfuR
yBgqcfHu7ZUlWz3jxYCCSFh8pAbdDejZWnRlCDm/Xh2NulowcVXVfypggKgl
0zRq1rWM961idYdHIKN7LumVCVjxqLhPv+9ifQ3o2OL6BEtffLStM7P68SCi
IK7WwXQ10FriUxNYHhP5vwGm1V2FfED1lKjb0H7gdq5Ou1eBNuiO41uzLCVw
15xiEen2s6whvwyik8YxoS5IFWVsnBeH5TMTWCELdlRsdr0Ys5qUDWX2DUbf
yuW6vrOZaRqxr0WNMok8EUljRTqrL46KdmLLokSbEvAreZ1UgTiOdrDMpquv
ubVW4tobjo/c8TZreCgXxGpGn5Cfc3EB4XudNPqlKMnZxxn3T0P+L61GI9Qb
QxaykxwdxgejeP/gOE2PtmFBY5BTtyf7O6M03j1wS6P+PCmGhDN/kDCGBtZq
WZJK2w9S1p3/Dgjp1N3K6/ntrnQsZQVQgCG8TaVCuW2wqvwH8Ghad/DEv5kH
jw+PjtPD7f3tyXgU7x1sAzOIj/ZGw729g73j7WHiIEIr4ABVOg5UYGnP87hy
3eKic4G99kTWvEO7QTggsxnoK9zPlNI04mhepYukYLjQKbQ3DXsDATxOhwcH
4wmI7PFob3g42t2O073jw4PDye4ebHp/uJ3uHe6Pj/bSo3gC4vvheLwfHwBf
G7k9tSbTbFerIJ9/mhPxbexGpcyYW/q68tsbZHULdrR90B8ta0Yp2xVVoUHl
6Tc9kXOrudt9EKIPd2JQMtK9naMRiNg7x8Cx03gICsmOntAvumAiOLq85v56
uuDILZgQbsNrLmsJJq59h9dOLzVXNjkYTQDoo6Oj5CABZBsODycgfXrSJO3u
BmWtza0bB0RmAblN9hDZSu6H9qOWMusV95/WJmm2EIdcFa3F4SC+8p421/8Y
7h8dTI6H27vp3nBvkgK8t/fSw1G6F+8BwdjZ3ZuYo/3DySj5eoXW0r2H4NSE
Q3YxaSv9ILV9+7MU4P0FA6J3DqN/hVPdAeU1Gu693Nt/OTzkArx+rbOXnN9S
A1y1zNkjbLxqsfHdx9k47+t7n2rMPDrP4gid/cgrFLSicZcXTY2oYDR0kOx8
wGWmWV1PU03EJys810wL1DZFNq3/Ihl5JpD0M9dmTW1XjF2WbndTfsre9MV9
bTfhuk348kOA4RymeDLWLg9k9EYbMru+0uS7jUk8rbAicVC9y+8IG+vDMMT6
rPip16w48nuM9keDz/HO7hANPp8/fz6L77Mk+iHN/xwDt/+CscPw9E1cfkR/
BrLfu3hGj3ET8NN5mY1RYAE1cRrDD9Esxvox1IYKM8DIU4Rt6cUkiecQs4OJ
U2owx+0jjvQ+ns7vzI/ZFAMXed7XizGc5TsQchepP+l1MZst4fliuvxCmQro
LcNrz12yKpRJOMHt/wArpFpKEEEBAA==
</rfc> </rfc>
 End of changes. 317 change blocks. 
2230 lines changed or deleted 1306 lines changed or added

This html diff was produced by rfcdiff 1.48.