rfc9458-authors.xml   rfc9458-sg.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.7.1 (Ruby 3.0.2 <!-- Restores formatting of Martin's XML, with a few updates (e.g., added refere
) --> nce targets, convered <seriesInfo> to <refcontent>.
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -->
-ietf-ohai-ohttp-latest" category="std" consensus="true" number="9458" tocInclud
e="true" sortRefs="true" symRefs="true" version="3"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
docName="draft-ietf-ohai-ohttp-10" number="9458" submissionType="IETF" category=
"std"
consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obs
oletes=""
xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.18.1 --> <!-- xml2rfc v2v3 conversion 3.18.1 -->
<link href="https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp-latest" rel ="prev"/>
<front> <front>
<title>Oblivious HTTP</title> <title>Oblivious HTTP</title>
<seriesInfo name="RFC" value="9458"/> <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="October" day="10"/> <date year="2023" month="November" />
<area>Security</area> <area>Security</area>
<workgroup>Oblivious HTTP Application Intermediation</workgroup> <workgroup>Oblivious HTTP Application Intermediation</workgroup>
<keyword>privacy</keyword> <keyword>privacy</keyword>
<keyword>proxy</keyword> <keyword>proxy</keyword>
<keyword>partitioning</keyword> <keyword>partitioning</keyword>
<keyword>tunnel</keyword> <keyword>tunnel</keyword>
<abstract> <abstract>
<?line 118?>
<t>This document describes Oblivious HTTP, a protocol for forwarding encrypted H TTP messages. <t>This document describes Oblivious HTTP, a protocol for forwarding encrypted H TTP messages.
Oblivious HTTP allows a client to make multiple requests to an origin server wit hout that server Oblivious HTTP allows a client to make multiple requests to an origin server wit hout that server
being able to link those requests to the client or to identify the requests as h aving come from the being able to link those requests to the client or to identify the requests as h aving come from the
same client, while placing only limited trust in the nodes used to forward the m essages.</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>
<?line 126?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>HTTP requests reveal information about client identities to servers. Wh ile the <t>HTTP requests reveal information about client identities to servers. Wh ile the
actual content of the request message is under the control of the client, other actual content of the request message is under the control of the client, other
information that is more difficult to control can still be used to identify the information that is more difficult to control can still be used to identify the
client.</t> client.</t>
<t>Even where an IP address is not directly associated with an individual, the <t>Even where an IP address is not directly associated with an individual, the
requests made from it can be correlated over time to assemble a profile of requests made from it can be correlated over time to assemble a profile of
client behavior. In particular, connection reuse improves performance but client behavior. In particular, connection reuse improves performance but
provides servers with the ability to link requests that share a connection.</t> provides servers with the ability to link requests that share a connection.</t>
skipping to change at line 467 skipping to change at line 452
</figure> </figure>
<t>That is, a <iref item="key configuration"/><xref target="key-configur ation" format="none">key configuration</xref> consists of the following fields:< /t> <t>That is, a <iref item="key configuration"/><xref target="key-configur ation" format="none">key configuration</xref> consists of the following fields:< /t>
<dl newline="true"> <dl newline="true">
<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 <iref item="Ob livious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious Ga teway 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 KEM used for the identified ke y as defined <t>A 16-bit value that identifies the KEM used for the identified ke y as defined
in <xref section="7.1" sectionFormat="of" target="HPKE"/> or <eref target="https ://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids">the "HPKE KEM Identifi ers" IANA in <xref section="7.1" sectionFormat="of" target="HPKE"/> or <eref target="https ://www.iana.org/assignments/hpke" brackets="angle">the "HPKE KEM Identifiers" IA NA
registry</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 eway" format="none">Oblivious Gateway Resource</xref> supports:</t> and AEAD that the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gat eway" format="none">Oblivious Gateway Resource</xref> supports:</t>
<dl newline="true"> <dl newline="true">
<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 " sectionFormat="of" target="HPKE"/> or <eref target="https://www.iana.org/assig nments/hpke/hpke.xhtml#hpke-kdf-ids">the <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 nments/hpke" brackets="angle">the
"HPKE KDF Identifiers" IANA "HPKE KDF Identifiers" IANA
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. 3" sectionFormat="of" target="HPKE"/> or <eref target="https://www.iana.org/assi gnments/hpke/hpke.xhtml#hpke-aead-ids">the <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 gnments/hpke" brackets="angle">the
"HPKE AEAD Identifiers" IANA "HPKE AEAD Identifiers" IANA
registry</eref>.</t> 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
skipping to change at line 604 skipping to change at line 589
<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 <iref item="Encapsulated Response"/><xref target="dfn-enc -res" format="none">Encapsulated Response</xref> contains a Nonce and an AEAD-Pr otected
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"/> or <eref target="https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids ">the "HPKE AEAD HPKE, which is defined in <xref section="7.3" sectionFormat="of" target="HPKE"/> or <eref target="https://www.iana.org/assignments/hpke" brackets="angle">the "H PKE AEAD
Identifiers" IANA 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 </xref> encapsulate a request, identified as <tt>request</tt>, using values from a <iref item="key configuration"/><xref target="key-configuration" format="none ">key <t><iref item="Clients"/><xref target="dfn-client" format="none">Clients </xref> encapsulate a request, identified as <tt>request</tt>, using values from a <iref item="key configuration"/><xref target="key-configuration" format="none ">key
configuration</xref>:</t> configuration</xref>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>the key identifier from the configuration (<tt>key_id</tt>) with the corresponding <t>the key identifier from the configuration (<tt>key_id</tt>) with the corresponding
KEM identified by <tt>kem_id</tt>,</t> KEM identified by <tt>kem_id</tt>,</t>
</li> </li>
<li> <li>
<t>the public key from the configuration (<tt>pkR</tt>), and</t> <t>the public key from the configuration (<tt>pkR</tt>), and</t>
</li> </li>
<li> <li>
<t>a combination of KDF (identified by <tt>kdf_id</tt>) and AEAD (id entified by <t>a combination of KDF (identified by <tt>kdf_id</tt>) and AEAD (id entified by
<tt>aead_id</tt>) that the <iref item="Client"/><xref target="dfn-client" format ="none">Client</xref> selects from those in the <iref item="key configuration"/> <xref target="key-configuration" format="none">key configuration</xref>.</t> <tt>aead_id</tt>) that the <iref item="Client"/><xref target="dfn-client" format ="none">Client</xref> selects from those in the <iref item="key configuration"/> <xref target="key-configuration" format="none">key configuration</xref>.</t>
</li> </li>
</ul> </ul>
<t>The <iref item="Client"/><xref target="dfn-client" format="none">Clie <t>The <iref item="Client"/><xref target="dfn-client" format="none">Clie
nt</xref> then constructs an <iref item="Encapsulated Request"/><xref target="df nt</xref> then constructs an <iref item="Encapsulated Request"/><xref target="df
n-enc-req" format="none">Encapsulated Request</xref>, <tt>enc_request</tt>, from n-enc-req" format="none">Encapsulated Request</xref>, <tt>enc_request</tt>, from
a binary a binary-encoded HTTP request <xref target="BINARY"/> (<tt>request</tt>) as fol
encoded HTTP request <xref target="BINARY"/> (<tt>request</tt>) as follows:</t> lows:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Construct a message header (<tt>hdr</tt>) by concatenating the va lues of <tt>key_id</tt>, <t>Construct a message header (<tt>hdr</tt>) by concatenating the va lues of <tt>key_id</tt>,
<tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt>, as one 8-bit integer and three 16-bit <tt>kem_id</tt>, <tt>kdf_id</tt>, and <tt>aead_id</tt> as one 8-bit integer and three 16-bit
integers, respectively, each in network byte order.</t> integers, respectively, each in network byte order.</t>
</li> </li>
<li> <li>
<t>Build a sequence of bytes (<tt>info</tt>) by concatenating the AS CII-encoded string <t>Build a sequence of bytes (<tt>info</tt>) by concatenating the AS CII-encoded string
"message/bhttp request", a zero byte, and the header. Note: <xref target="repur posing"/> "message/bhttp request", a zero byte, and the header. Note: <xref target="repur posing"/>
discusses how alternative message formats might use a different <tt>info</tt> va lue.</t> discusses how alternative message formats might use a different <tt>info</tt> va lue.</t>
</li> </li>
<li> <li>
<t>Create a sending HPKE context by invoking <tt>SetupBaseS()</tt> ( <xref section="5.1.1" sectionFormat="of" target="HPKE"/>) with the public key of the receiver <tt>pkR</tt> and <tt>info</tt>. This yields <t>Create a sending HPKE context by invoking <tt>SetupBaseS()</tt> ( <xref section="5.1.1" sectionFormat="of" target="HPKE"/>) with the public key of the receiver <tt>pkR</tt> and <tt>info</tt>. This yields
the context <tt>sctxt</tt> and an encapsulation key <tt>enc</tt>.</t> the context <tt>sctxt</tt> and an encapsulation key <tt>enc</tt>.</t>
skipping to change at line 668 skipping to change at line 652
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)
]]></sourcecode> ]]></sourcecode>
<t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway " format="none">Oblivious Gateway Resource</xref> decrypts an <iref item="Encaps ulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</ xref> by reversing this <t>An <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway " format="none">Oblivious Gateway Resource</xref> decrypts an <iref item="Encaps ulated Request"/><xref target="dfn-enc-req" format="none">Encapsulated Request</ 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> 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> , <tt>kdf_id</tt>, <tt>aead_id</tt>, <tt>enc</tt>, and <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>ct</tt> (indicated using the function <tt>parse()</tt> in pseudocode). The < iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none" >Oblivious <tt>ct</tt> (indicated using the function <tt>parse()</tt> in pseudocode). The < iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none" >Oblivious
Gateway Resource</xref> 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>
<ol spacing="normal" type="a"><li> <ol spacing="normal" type="a"><li>
<t>If <tt>key_id</tt> does not identify a key matching the type of <tt>kem_id</tt>, the <t>If <tt>key_id</tt> does not identify a key matching the type of <tt>kem_id</tt>, the
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none ">Oblivious Gateway Resource</xref> returns an error.</t> <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none ">Oblivious Gateway Resource</xref> returns an error.</t>
</li> </li>
<li> <li>
<t>If <tt>kdf_id</tt> and <tt>aead_id</tt> identify a combinatio n of KDF and AEAD that the <t>If <tt>kdf_id</tt> and <tt>aead_id</tt> identify a combinatio n of KDF and AEAD that the
<iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none ">Oblivious Gateway Resource</xref> is unwilling to use with <tt>skR</tt>, the < iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none" >Oblivious <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none ">Oblivious Gateway Resource</xref> is unwilling to use with <tt>skR</tt>, the < iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none" >Oblivious
skipping to change at line 723 skipping to change at line 707
<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" format="none">Oblivious Gateway Resources</xref> generate an <iref item="Encapsu lated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response< /xref> (<tt>enc_response</tt>) <t><iref item="Oblivious Gateway Resources"/><xref target="dfn-gateway" format="none">Oblivious Gateway Resources</xref> generate an <iref item="Encapsu lated Response"/><xref target="dfn-enc-res" format="none">Encapsulated Response< /xref> (<tt>enc_response</tt>)
from a binary-encoded HTTP response <xref target="BINARY"/> (<tt>response</tt>). The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format ="none">Oblivious from a binary-encoded HTTP response <xref target="BINARY"/> (<tt>response</tt>). The <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" format ="none">Oblivious
Gateway Resource</xref> uses the HPKE receiver context (<tt>rctxt</tt>) as the H PKE context Gateway Resource</xref> uses the HPKE receiver context (<tt>rctxt</tt>) as the H PKE context
(<tt>context</tt>) as follows:</t> (<tt>context</tt>) as follows:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Export a secret (<tt>secret</tt>) from <tt>context</tt>, using th e string "message/bhttp <t>Export a secret (<tt>secret</tt>) from <tt>context</tt>, using th e 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.</t> different <tt>context</tt> value.</t>
</li> </li>
<li> <li>
<t>Generate a random value of length <tt>max(Nn, Nk)</tt> bytes, cal led <t>Generate a random value of length <tt>max(Nn, Nk)</tt> bytes, cal led
<tt>response_nonce</tt>.</t> <tt>response_nonce</tt>.</t>
</li> </li>
<li> <li>
<t>Extract a pseudorandom key (<tt>prk</tt>) using the <tt>Extract</ tt> function provided by <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
skipping to change at line 754 skipping to change at line 738
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".</t> label of "nonce".</t>
</li> </li>
<li> <li>
<t>Encrypt <tt>response</tt>, passing the AEAD function Seal the val ues of <t>Encrypt <tt>response</tt>, passing the AEAD function Seal the val ues of
<tt>aead_key</tt>, <tt>aead_nonce</tt>, an empty <tt>aad</tt>, and a <tt>pt</tt> input of <tt>aead_key</tt>, <tt>aead_nonce</tt>, an empty <tt>aad</tt>, and a <tt>pt</tt> input of
<tt>response</tt>. This yields <tt>ct</tt>.</t> <tt>response</tt>. This yields <tt>ct</tt>.</t>
</li> </li>
<li> <li>
<t>Concatenate <tt>response_nonce</tt> and <tt>ct</tt>, yielding an <iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Enc apsulated Response</xref>, <t>Concatenate <tt>response_nonce</tt> and <tt>ct</tt>, yielding an <iref item="Encapsulated Response"/><xref target="dfn-enc-res" format="none">Enc apsulated Response</xref>,
<tt>enc_response</tt>. Note that <tt>response_nonce</tt> is of fixed-length, so there is no <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> ambiguity in parsing either <tt>response_nonce</tt> or <tt>ct</tt>.</t>
</li> </li>
</ol> </ol>
<t>In pseudocode, this procedure is as follows:</t> <t>In pseudocode, this procedure is as follows:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
secret = context.Export("message/bhttp response", max(Nn, 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)
skipping to change at line 1030 skipping to change at line 1014
<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 <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
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 psulated Request</xref> and that is sent to the <iref item="Oblivious Relay Reso urce"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> <b cp14>MUST NOT</bcp14> <iref item="Encapsulated Request"/><xref target="dfn-enc-req" format="none">Enca psulated Request</xref> and that is sent to the <iref item="Oblivious Relay Reso urce"/><xref target="dfn-relay" format="none">Oblivious Relay Resource</xref> <b cp14>MUST NOT</bcp14>
include identifying information unless the <iref item="Client"/><xref target="df n-client" format="none">Client</xref> can trust that this include identifying information unless the <iref item="Client"/><xref target="df n-client" format="none">Client</xref> can trust that this
information is removed by the relay. A <iref item="Client"/><xref target="dfn-cl ient" format="none">Client</xref> <bcp14>MAY</bcp14> include information only fo r information is removed by the relay. A <iref item="Client"/><xref target="dfn-cl ient" format="none">Client</xref> <bcp14>MAY</bcp14> include information only fo r
the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none ">Oblivious Relay Resource</xref> in header fields identified by the <tt>Connect ion</tt> the <iref item="Oblivious Relay Resource"/><xref target="dfn-relay" format="none ">Oblivious Relay Resource</xref> in header fields identified by the <tt>Connect ion</tt>
header field if it trusts the relay to remove these, as required by <xref sectio n="7.6.1" sectionFormat="of" target="HTTP"/>. The <iref item="Client"/><xref tar get="dfn-client" format="none">Client</xref> needs to trust that the relay does not replicate the header field if it trusts the relay to remove these, as required by <xref sectio n="7.6.1" sectionFormat="of" target="HTTP"/>. The <iref item="Client"/><xref tar get="dfn-client" format="none">Client</xref> needs to trust that the relay does not 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 </xref> rely on the <iref item="Oblivious Relay Resource"/><xref target="dfn-rel ay" format="none">Oblivious Relay Resource</xref> to forward <iref item="Encapsu lated Requests"/><xref target="dfn-enc-req" format="none">Encapsulated Requests< /xref> <t><iref item="Clients"/><xref target="dfn-client" format="none">Clients </xref> rely on the <iref item="Oblivious Relay Resource"/><xref target="dfn-rel ay" format="none">Oblivious Relay Resource</xref> to forward <iref item="Encapsu lated Requests"/><xref target="dfn-enc-req" format="none">Encapsulated Requests< /xref>
and Responses. However, the relay can only refuse to forward messages; it and Responses. However, the relay can only refuse to forward messages; it
cannot inspect or modify the contents of <iref item="Encapsulated Requests"/><xr ef target="dfn-enc-req" format="none">Encapsulated Requests</xref> or responses. </t> cannot inspect or modify the contents of <iref item="Encapsulated Requests"/><xr ef target="dfn-enc-req" format="none">Encapsulated Requests</xref> 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 f target="dfn-relay" format="none">Oblivious Relay Resource</xref> has a very si mple function <t>The relay that serves the <iref item="Oblivious Relay Resource"/><xre f target="dfn-relay" format="none">Oblivious Relay Resource</xref> has a very si mple function
to perform. For each request it receives, it makes a request of the <iref item=" Oblivious Gateway Resource"/><xref target="dfn-gateway" format="none">Oblivious to perform. For each request it receives, it makes a request of the <iref item=" 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 ="none">Client</xref> that includes the content of the response it sends a response to the <iref item="Client"/><xref target="dfn-client" format ="none">Client</xref> that includes the content of the response
from the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" for mat="none">Oblivious Gateway Resource</xref>.</t> from the <iref item="Oblivious Gateway Resource"/><xref target="dfn-gateway" for 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
skipping to change at line 1106 skipping to change at line 1090
rate-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 <iref item="Encapsulated Request"/><xref target=" dfn-enc-req" format="none">Encapsulated Request</xref> or Response messages are sent 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 <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
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 target="dfn-client" format="none">Client</xref> waits for a attributed. Any delay also increases the time that a <iref item="Client"/><xref target="dfn-client" format="none">Client</xref> waits for a
response, so delays <bcp14>SHOULD</bcp14> only be added with the consent -- or a t least response, so delays <bcp14>SHOULD</bcp14> only be added with the consent -- or a t least
awareness -- of <iref item="Clients"/><xref target="dfn-client" format="none">Cl ients</xref>.</t> awareness -- of <iref item="Clients"/><xref target="dfn-client" format="none">Cl ients</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
skipping to change at line 1531 skipping to change at line 1515
be correctly identified using the media types defined in Sections <xref format=" counter" target="iana-req"/> be correctly identified using the media types defined in Sections <xref format=" counter" target="iana-req"/>
and <xref format="counter" 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. <iref item="Clients"/><xref target="d fn-client" format="none">Clients</xref> 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>IANA has registered following media types in the "Media Types" registry <t>IANA has registered the following media types in the "Media Types" regi
at stry at
<eref target="https://iana.org/assignments/media-types">https://iana.org/assignm <eref target="https://iana.org/assignments/media-types" brackets="angle"/>, foll
ents/media-types</eref>, following the procedures of owing the procedures of
<xref target="RFC6838"/>: "<tt>application/ohttp-keys</tt>" (<xref target="iana- keys"/>), "<tt>message/ohttp-req</tt>" <xref target="RFC6838"/>: "<tt>application/ohttp-keys</tt>" (<xref target="iana- keys"/>), "<tt>message/ohttp-req</tt>"
(<xref target="iana-req"/>), and "<tt>message/ohttp-res</tt>" (<xref target="ian a-res"/>).</t> (<xref target="iana-req"/>), and "<tt>message/ohttp-res</tt>" (<xref target="ian a-res"/>).</t>
<t>IANA has added the following types to the "HTTP Problem Types" registry at <t>IANA has added the following types to the "HTTP Problem Types" registry at
<eref target="https://iana.org/assignments/http-problem-types">https://iana.org/ assignments/http-problem-types</eref>: "date" <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 "<tt>application/ohttp-keys</tt>" media type identifies a <iref i tem="key configuration"/><xref target="key-configuration" format="none">key conf iguration</xref> used by <t>The "<tt>application/ohttp-keys</tt>" media type identifies a <iref i tem="key configuration"/><xref target="key-configuration" format="none">key conf iguration</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>
skipping to change at line 1843 skipping to change at line 1827
</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 anchor="sec-normative-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"/>
<author fullname="C. A. Wood" initials="C. A." surname="Wood"/> <author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
<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=" Fielding"/> <author fullname="R. Fielding" initials="R." role="editor" surname=" Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname ="Nottingham"/> <author fullname="M. Nottingham" initials="M." role="editor" surname ="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R eschke"/> <author fullname="J. Reschke" initials="J." role="editor" surname="R eschke"/>
<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=" Fielding"/> <author fullname="R. Fielding" initials="R." role="editor" surname=" Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname ="Nottingham"/> <author fullname="M. Nottingham" initials="M." role="editor" surname ="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R eschke"/> <author fullname="J. Reschke" initials="J." role="editor" surname="R eschke"/>
<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 yengar"/> <author fullname="J. Iyengar" initials="J." role="editor" surname="I yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T homson"/> <author fullname="M. Thomson" initials="M." role="editor" surname="T homson"/>
<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 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> <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"/>
<date month="August" year="2018"/> <date month="August" year="2018"/>
<abstract> <abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu rity (TLS) protocol. TLS allows client/server applications to communicate over t he Internet in a way that is designed to prevent eavesdropping, tampering, and m essage forgery.</t> <t>This document specifies version 1.3 of the Transport Layer Secu rity (TLS) protocol. TLS allows client/server applications to communicate over t he Internet in a way that is designed to prevent eavesdropping, tampering, and m essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50 77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im plementations.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50 77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im 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"/>
<author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/> <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
<author fullname="B. Lipp" initials="B." surname="Lipp"/> <author fullname="B. Lipp" initials="B." surname="Lipp"/>
<author fullname="C. Wood" initials="C." surname="Wood"/> <author fullname="C. Wood" initials="C." surname="Wood"/>
<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"/>
<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. 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> <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"/>
<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 that 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"/>
<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="28" month="April" year="2023"/> <date month="July" year="2023"/>
<abstract> <abstract>
<t>This document defines a "problem detail" to carry machine-reada <t>This document defines a "problem detail" to carry machine-reada
ble details of errors in HTTP response content to avoid the need to define new e ble details of erors in HTTP response content to avoid the need to define new er
rror response formats for HTTP APIs. ror response formats for HTTP APIs.
This document obsoletes RFC 7807.
</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"/>
-07"/> <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"/>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/ > <author fullname="M. Nottingham" initials="M." surname="Nottingham"/ >
<author fullname="W. Tarreau" initials="W." surname="Tarreau"/> <author fullname="W. Tarreau" initials="W." surname="Tarreau"/>
<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 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> <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"/>
<author fullname="J. Klensin" initials="J." surname="Klensin"/> <author fullname="J. Klensin" initials="J." surname="Klensin"/>
<author fullname="T. Hansen" initials="T." surname="Hansen"/> <author fullname="T. Hansen" initials="T." surname="Hansen"/>
<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. Thi s 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>
skipping to change at line 2045 skipping to change at line 2031
such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user
privacy. It presents definitions for consistency and then surveys privacy. It presents definitions for consistency and then surveys
mechanisms for providing consistency in varying threat models. In 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-01"/> <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=" Fielding"/> <author fullname="R. Fielding" initials="R." role="editor" surname=" Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname ="Nottingham"/> <author fullname="M. Nottingham" initials="M." role="editor" surname ="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R eschke"/> <author fullname="J. Reschke" initials="J." role="editor" surname="R eschke"/>
<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 homson"/> <author fullname="M. Thomson" initials="M." role="editor" surname="T homson"/>
<author fullname="C. Benfield" initials="C." role="editor" surname=" Benfield"/> <author fullname="C. Benfield" initials="C." role="editor" surname=" Benfield"/>
<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 shop"/> <author fullname="M. Bishop" initials="M." role="editor" surname="Bi shop"/>
<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 that 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"/>
<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 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> <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"/>
skipping to change at line 2129 skipping to change at line 2115
</author> </author>
<author initials="D." surname="Boneh"> <author initials="D." surname="Boneh">
<organization/> <organization/>
</author> </author>
<date year="2017" month="March"/> <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/>
</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"/> <date year="2021" month="January"/>
</front> </front>
<seriesInfo name="PoPETS" value="Volume 2021, Issue 4, pp. 575-592"/> <refcontent>PoPETS Proceedings Volume 2021, Issue 4, pp. 575-592</refc
<seriesInfo name="DOI" value="10.2478/popets-2021-0085"/> 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"/> <date year="2022" month="October"/>
</front> </front>
<seriesInfo name="commit" value="6824eee"/> <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"/> <date year="2015" month="July"/>
</front> </front>
<seriesInfo name="W3C" value="TAG Finding"/> <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" month="January"/> <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"/ >
<author fullname="P. McManus" initials="P." surname="McManus"/> <author fullname="P. McManus" initials="P." surname="McManus"/>
<author fullname="J. Reschke" initials="J." surname="Reschke"/> <author fullname="J. Reschke" initials="J." surname="Reschke"/>
<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"/>
<author fullname="P. McManus" initials="P." surname="McManus"/> <author fullname="P. McManus" initials="P." surname="McManus"/>
<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 H TTP 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 rd"/> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3 rd"/>
<author fullname="J. Schiller" initials="J." surname="Schiller"/> <author fullname="J. Schiller" initials="J." surname="Schiller"/>
<author fullname="S. Crocker" initials="S." surname="Crocker"/> <author fullname="S. Crocker" initials="S." surname="Crocker"/>
<date month="June" year="2005"/> <date month="June" year="2005"/>
<abstract> <abstract>
<t>Security systems are built on strong cryptographic algorithms t hat foil pattern analysis attempts. However, the security of these systems is de pendent on generating secret quantities for passwords, cryptographic keys, and s imilar quantities. The use of pseudo-random processes to generate secret quantit ies can result in pseudo-security. A sophisticated attacker may find it easier t o reproduce the environment that produced the secret quantities and to search th e resulting small set of possibilities than to locate the quantities in the whol e of the potential number space.</t> <t>Security systems are built on strong cryptographic algorithms t hat foil pattern analysis attempts. However, the security of these systems is de pendent on generating secret quantities for passwords, cryptographic keys, and s imilar quantities. The use of pseudo-random processes to generate secret quantit ies can result in pseudo-security. A sophisticated attacker may find it easier t o reproduce the environment that produced the secret quantities and to search th e resulting small set of possibilities than to locate the quantities in the whol e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in u sing poor entropy sources or traditional pseudo-random number generation techniq ues for generating such quantities. It recommends the use of truly random hardwa re techniques and shows that the existing hardware on many systems can be used f or this purpose. It provides suggestions to ameliorate the problem when a hardwa re solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Curr ent Practices for the Internet Community, and requests discussion and suggestion s for improvements.</t> <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in u sing poor entropy sources or traditional pseudo-random number generation techniq ues for generating such quantities. It recommends the use of truly random hardwa re techniques and shows that the existing hardware on many systems can be used f or this purpose. It provides suggestions to ameliorate the problem when a hardwa re solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Curr ent Practices for the Internet Community, and requests discussion and suggestion 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"/>
<author fullname="M. Nilsson" initials="M." surname="Nilsson"/> <author fullname="M. Nilsson" initials="M." surname="Nilsson"/>
<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 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 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"/>
<author fullname="J. Martin" initials="J." role="editor" surname="Ma rtin"/> <author fullname="J. Martin" initials="J." role="editor" surname="Ma rtin"/>
<author fullname="J. Burbank" initials="J." surname="Burbank"/> <author fullname="J. Burbank" initials="J." surname="Burbank"/>
<author fullname="W. Kasch" initials="W." surname="Kasch"/> <author fullname="W. Kasch" initials="W." surname="Kasch"/>
<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), 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> <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>
skipping to change at line 2294 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>ACM</refcontent> <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"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/> <author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="M. Hadley" initials="M." surname="Hadley"/> <author fullname="M. Hadley" initials="M." surname="Hadley"/>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/ > <author fullname="M. Nottingham" initials="M." surname="Nottingham"/ >
<author fullname="D. Orchard" initials="D." surname="Orchard"/> <author fullname="D. Orchard" initials="D." surname="Orchard"/>
<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"/>
<author fullname="M. Hamburg" initials="M." surname="Hamburg"/> <author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
<author fullname="S. Turner" initials="S." surname="Turner"/> <author fullname="S. Turner" initials="S." surname="Turner"/>
<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 ~1 28-bit and ~224-bit security level, respectively, and are generated deterministi cally 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"/>
<author fullname="P. McManus" initials="P." surname="McManus"/> <author fullname="P. McManus" initials="P." surname="McManus"/>
<author fullname="T. Pauly" initials="T." surname="Pauly"/> <author fullname="T. Pauly" initials="T." surname="Pauly"/>
<author fullname="T. Verma" initials="T." surname="Verma"/> <author fullname="T. Verma" initials="T." surname="Verma"/>
<author fullname="C.A. Wood" initials="C.A." surname="Wood"/> <author fullname="C.A. Wood" initials="C.A." surname="Wood"/>
<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>
 End of changes. 56 change blocks. 
120 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.48.