<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-ohai-ohttp-10" number="9458" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" prepTime="2024-01-12T16:32:28" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9458" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title>Oblivious HTTP</title>
    <seriesInfo name="RFC" value="9458" stream="IETF"/>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization showOnFrontPage="true">Mozilla</organization>
      <address>
        <email>mt@lowentropy.net</email>
      </address>
    </author>
    <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
      <organization showOnFrontPage="true">Cloudflare</organization>
      <address>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <date month="01" year="2024"/>
    <area>Security</area>
    <workgroup>Oblivious HTTP Application Intermediation</workgroup>
    <keyword>privacy</keyword>
    <keyword>proxy</keyword>
    <keyword>partitioning</keyword>
    <keyword>tunnel</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages.
Oblivious HTTP allows a client to make multiple requests to an origin server without that server
being able to link those requests to the client or to identify the requests as having come from the
same client, while placing only limited trust in the nodes used to forward the messages.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9458" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability">Applicability</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-and-definitions">Conventions and Definitions</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-configuration">Key Configuration</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-configuration-encoding">Key Configuration Encoding</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-configuration-media-typ">Key Configuration Media Type</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hpke-encapsulation">HPKE Encapsulation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-request-format">Request Format</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-response-format">Response Format</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-encapsulation-of-requests">Encapsulation of Requests</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-encapsulation-of-responses">Encapsulation of Responses</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-request-and-response-media-">Request and Response Media Types</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.6">
                <t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent="4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-repurposing-the-encapsulati">Repurposing the Encapsulation Format</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-http-usage">HTTP Usage</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informational-responses">Informational Responses</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-errors">Errors</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signaling-key-configuration">Signaling Key Configuration Problems</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client-responsibilities">Client Responsibilities</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-relay-responsibilities">Relay Responsibilities</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.2.2">
                  <li pn="section-toc.1-1.6.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.1.1"><xref derivedContent="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-differential-treatment">Differential Treatment</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.2.1"><xref derivedContent="6.2.2" format="counter" sectionFormat="of" target="section-6.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-denial-of-service">Denial of Service</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.3.1"><xref derivedContent="6.2.3" format="counter" sectionFormat="of" target="section-6.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-traffic-analysis">Traffic Analysis</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-server-responsibilities">Server Responsibilities</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-management">Key Management</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-replay-attacks">Replay Attacks</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.5.2">
                  <li pn="section-toc.1-1.6.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.1.1"><xref derivedContent="6.5.1" format="counter" sectionFormat="of" target="section-6.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-date-for-anti-replay">Use of Date for Anti-replay</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.2.1"><xref derivedContent="6.5.2" format="counter" sectionFormat="of" target="section-6.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-correcting-clock-difference">Correcting Clock Differences</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-forward-secrecy">Forward Secrecy</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.7">
                <t indent="0" pn="section-toc.1-1.6.2.7.1"><xref derivedContent="6.7" format="counter" sectionFormat="of" target="section-6.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-post-compromise-security">Post-Compromise Security</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.8">
                <t indent="0" pn="section-toc.1-1.6.2.8.1"><xref derivedContent="6.8" format="counter" sectionFormat="of" target="section-6.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client-clock-exposure">Client Clock Exposure</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.9">
                <t indent="0" pn="section-toc.1-1.6.2.9.1"><xref derivedContent="6.9" format="counter" sectionFormat="of" target="section-6.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type-security">Media Type Security</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.10">
                <t indent="0" pn="section-toc.1-1.6.2.10.1"><xref derivedContent="6.10" format="counter" sectionFormat="of" target="section-6.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-separate-gateway-and-target">Separate Gateway and Target</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-and-deployment-">Operational and Deployment Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-performance-overhead">Performance Overhead</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-resource-mappings">Resource Mappings</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-network-management">Network Management</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-ohttp-keys-medi">application/ohttp-keys Media Type</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-message-ohttp-req-media-typ">message/ohttp-req Media Type</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-message-ohttp-res-media-typ">message/ohttp-res Media Type</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.4">
                <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-of-date-proble">Registration of "date" Problem Type</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.5">
                <t indent="0" pn="section-toc.1-1.9.2.5.1"><xref derivedContent="9.5" format="counter" sectionFormat="of" target="section-9.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-of-ohttp-key-p">Registration of "ohttp-key" Problem Type</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-complete-example-of-a-reque">Complete Example of a Request and Response</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">HTTP requests reveal information about client identities to servers. While the
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
client.</t>
      <t indent="0" pn="section-1-2">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
client behavior.  In particular, connection reuse improves performance but
provides servers with the ability to link requests that share a connection.</t>
      <t indent="0" pn="section-1-3">In particular, the source IP address of the underlying connection reveals
identifying information that the client has only limited control over. While
client-configured HTTP proxies can provide a degree of protection against IP
address tracking, they present an unfortunate trade-off: if they are used without
TLS, the contents of communication are revealed to the proxy; if they are used
with TLS, a new connection needs to be used for each request to ensure that the
origin server cannot use the connection as a way to correlate requests,
incurring significant performance overheads.</t>
      <t indent="0" pn="section-1-4">To overcome these limitations, this document defines Oblivious HTTP, a protocol
for encrypting and sending HTTP messages from a client to a gateway. This uses a
trusted relay service in a manner that mitigates the use of metadata such as IP
address and connection information for client identification, with reasonable
performance characteristics.  This document describes:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1-5"><li pn="section-1-5.1" derivedCounter="1.">
          <t indent="0" pn="section-1-5.1.1">an algorithm for encapsulating binary HTTP messages <xref target="BINARY" format="default" sectionFormat="of" derivedContent="BINARY"/> using Hybrid
Public Key Encryption (HPKE) <xref target="HPKE" format="default" sectionFormat="of" derivedContent="HPKE"/> to protect their contents,</t>
        </li>
        <li pn="section-1-5.2" derivedCounter="2.">
          <t indent="0" pn="section-1-5.2.1">a method for forwarding <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Requests</xref> between <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> and an
<xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> through a trusted <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> using
HTTP, and</t>
        </li>
        <li pn="section-1-5.3" derivedCounter="3.">
          <t indent="0" pn="section-1-5.3.1">requirements for how the Oblivious Gateway Resource handles Encapsulated Requests and produces <xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Encapsulated Responses</xref> for the Client.</t>
        </li>
      </ol>
      <t indent="0" pn="section-1-6">The combination of encapsulation and relaying ensures that Oblivious Gateway
Resource never sees the Client's IP address and that the Oblivious Relay
Resource never sees plaintext HTTP message content.</t>
      <t indent="0" pn="section-1-7">Oblivious HTTP allows connection reuse between the Client and Oblivious Relay
Resource, as well as between that relay and the Oblivious Gateway Resource, so this
scheme represents a performance improvement over using just one request in each
connection.  With limited trust placed in the Oblivious Relay Resource (see
<xref target="security" format="default" sectionFormat="of" derivedContent="Section 6"/>), Clients are assured that requests are not uniquely attributed to
them or linked to other requests.</t>
    </section>
    <section anchor="overview" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-overview">Overview</name>
      <t indent="0" pn="section-2-1">An Oblivious HTTP <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> must initially know the following:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-2">
        <li pn="section-2-2.1">
          <t indent="0" pn="section-2-2.1.1">The identity of an <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref>.  This might include some
information about what <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resources</xref> the Oblivious Gateway Resource
supports.</t>
        </li>
        <li pn="section-2-2.2">
          <t indent="0" pn="section-2-2.2.1">The details of an HPKE public key for the Oblivious Gateway Resource,
including an identifier for that key and the HPKE algorithms that are used
with that key.</t>
        </li>
        <li pn="section-2-2.3">
          <t indent="0" pn="section-2-2.3.1">The identity of an <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> that will accept relay requests
carrying an <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref> as its content and forward the content in
these requests to a particular Oblivious Gateway Resource.  Oblivious HTTP
uses a one-to-one mapping between Oblivious Relay and Gateway Resources; see
<xref target="proxy-state" format="default" sectionFormat="of" derivedContent="Section 8.2"/> for more details.</t>
        </li>
      </ul>
      <t indent="0" pn="section-2-3">This information allows the Client to send HTTP requests to the Oblivious
Gateway Resource for forwarding to a Target Resource.  The Oblivious Gateway
Resource 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 Oblivious Gateway Resource learn which of the requests it receives are
from the same Client.</t>
      <figure anchor="fig-overview" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-overview-of-oblivious-http">Overview of Oblivious HTTP</name>
        <artset pn="section-2-4.1">
          <artwork type="svg" align="left" pn="section-2-4.1.1"><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 48,96 L 48,464" 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 192,96 L 192,464" fill="none" stroke="black"/>
              <path d="M 240,48 L 240,96" fill="none" stroke="black"/>
              <path d="M 288,48 L 288,96" fill="none" stroke="black"/>
              <path d="M 312,48 L 312,96" fill="none" stroke="black"/>
              <path d="M 360,96 L 360,464" fill="none" stroke="black"/>
              <path d="M 400,48 L 400,96" fill="none" stroke="black"/>
              <path d="M 440,48 L 440,96" fill="none" stroke="black"/>
              <path d="M 480,96 L 480,464" fill="none" stroke="black"/>
              <path d="M 528,48 L 528,96" fill="none" stroke="black"/>
              <path d="M 552,48 L 552,96" fill="none" stroke="black"/>
              <path d="M 304,32 L 536,32" fill="none" stroke="black"/>
              <path d="M 8,48 L 88,48" fill="none" stroke="black"/>
              <path d="M 152,48 L 240,48" fill="none" stroke="black"/>
              <path d="M 312,48 L 400,48" fill="none" stroke="black"/>
              <path d="M 440,48 L 528,48" fill="none" stroke="black"/>
              <path d="M 8,96 L 88,96" fill="none" stroke="black"/>
              <path d="M 152,96 L 240,96" fill="none" stroke="black"/>
              <path d="M 312,96 L 400,96" fill="none" stroke="black"/>
              <path d="M 440,96 L 528,96" fill="none" stroke="black"/>
              <path d="M 304,112 L 352,112" fill="none" stroke="black"/>
              <path d="M 368,112 L 472,112" fill="none" stroke="black"/>
              <path d="M 488,112 L 536,112" fill="none" stroke="black"/>
              <path d="M 48,192 L 184,192" fill="none" stroke="black"/>
              <path d="M 192,256 L 352,256" fill="none" stroke="black"/>
              <path d="M 360,272 L 472,272" fill="none" stroke="black"/>
              <path d="M 368,320 L 480,320" fill="none" stroke="black"/>
              <path d="M 200,384 L 360,384" fill="none" stroke="black"/>
              <path d="M 56,448 L 192,448" fill="none" stroke="black"/>
              <path d="M 304,32 C 295.16936,32 288,39.16936 288,48" fill="none" stroke="black"/>
              <path d="M 536,32 C 544.83064,32 552,39.16936 552,48" fill="none" stroke="black"/>
              <path d="M 304,112 C 295.16936,112 288,104.83064 288,96" fill="none" stroke="black"/>
              <path d="M 536,112 C 544.83064,112 552,104.83064 552,96" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="480,272 468,266.4 468,277.6" fill="black" transform="rotate(0,472,272)"/>
              <polygon class="arrowhead" points="376,320 364,314.4 364,325.6" fill="black" transform="rotate(180,368,320)"/>
              <polygon class="arrowhead" points="360,256 348,250.4 348,261.6" fill="black" transform="rotate(0,352,256)"/>
              <polygon class="arrowhead" points="208,384 196,378.4 196,389.6" fill="black" transform="rotate(180,200,384)"/>
              <polygon class="arrowhead" points="192,192 180,186.4 180,197.6" fill="black" transform="rotate(0,184,192)"/>
              <polygon class="arrowhead" points="64,448 52,442.4 52,453.6" fill="black" transform="rotate(180,56,448)"/>
              <g class="text">
                <text x="44" y="68">Client</text>
                <text x="184" y="68">Relay</text>
                <text x="352" y="68">Gateway</text>
                <text x="476" y="68">Target</text>
                <text x="196" y="84">Resource</text>
                <text x="356" y="84">Resource</text>
                <text x="484" y="84">Resource</text>
                <text x="80" y="132">Relay</text>
                <text x="88" y="148">Request</text>
                <text x="68" y="164">[+</text>
                <text x="132" y="164">Encapsulated</text>
                <text x="112" y="180">Request</text>
                <text x="152" y="180">]</text>
                <text x="232" y="196">Gateway</text>
                <text x="232" y="212">Request</text>
                <text x="212" y="228">[+</text>
                <text x="276" y="228">Encapsulated</text>
                <text x="256" y="244">Request</text>
                <text x="296" y="244">]</text>
                <text x="400" y="260">Request</text>
                <text x="436" y="308">Response</text>
                <text x="320" y="324">Gateway</text>
                <text x="316" y="340">Response</text>
                <text x="236" y="356">[+</text>
                <text x="300" y="356">Encapsulated</text>
                <text x="300" y="372">Response</text>
                <text x="344" y="372">]</text>
                <text x="160" y="388">Relay</text>
                <text x="148" y="404">Response</text>
                <text x="68" y="420">[+</text>
                <text x="132" y="420">Encapsulated</text>
                <text x="132" y="436">Response</text>
                <text x="176" y="436">]</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="left" pn="section-2-4.1.2">
                                    .------------------------------.
+---------+       +----------+     |  +----------+    +----------+  |
| Client  |       | Relay    |     |  | Gateway  |    | Target   |  |
|         |       | Resource |     |  | Resource |    | Resource |  |
+----+----+       +----+-----+     |  +-----+----+    +----+-----+  |
     |                 |            `-------|--------------|-------'
     | Relay           |                    |              |
     | Request         |                    |              |
     | [+ Encapsulated |                    |              |
     |    Request ]    |                    |              |
     +----------------&gt;| Gateway            |              |
     |                 | Request            |              |
     |                 | [+ Encapsulated    |              |
     |                 |    Request ]       |              |
     |                 +-------------------&gt;| Request      |
     |                 |                    +-------------&gt;|
     |                 |                    |              |
     |                 |                    |     Response |
     |                 |            Gateway |&lt;-------------+
     |                 |           Response |              |
     |                 |    [+ Encapsulated |              |
     |                 |         Response ] |              |
     |           Relay |&lt;-------------------+              |
     |        Response |                    |              |
     | [+ Encapsulated |                    |              |
     |      Response ] |                    |              |
     |&lt;----------------+                    |              |
     |                 |                    |              |
</artwork>
        </artset>
      </figure>
      <t indent="0" pn="section-2-5">In order to forward a request for a <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref> to the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway
Resource</xref>, the following steps occur, as shown in <xref target="fig-overview" format="default" sectionFormat="of" derivedContent="Figure 1"/>:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-6"><li pn="section-2-6.1" derivedCounter="1.">
          <t indent="0" pn="section-2-6.1.1">The <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> constructs an HTTP request for a Target Resource.</t>
        </li>
        <li pn="section-2-6.2" derivedCounter="2.">
          <t indent="0" pn="section-2-6.2.1">The Client encodes the HTTP request in a binary HTTP message and then
encapsulates that message using HPKE and the process from <xref target="request" format="default" sectionFormat="of" derivedContent="Section 4.3"/>.</t>
        </li>
        <li pn="section-2-6.3" derivedCounter="3.">
          <t indent="0" pn="section-2-6.3.1">The Client sends a POST request to the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> with the
<xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref> as the content of that message.</t>
        </li>
        <li pn="section-2-6.4" derivedCounter="4.">
          <t indent="0" pn="section-2-6.4.1">The Oblivious Relay Resource forwards this request to the Oblivious Gateway
Resource.</t>
        </li>
        <li pn="section-2-6.5" derivedCounter="5.">
          <t indent="0" pn="section-2-6.5.1">The Oblivious Gateway Resource receives this request and removes
the HPKE protection to obtain an HTTP request.</t>
        </li>
      </ol>
      <t indent="0" pn="section-2-7">The Oblivious Gateway Resource then handles the HTTP request. This typically
involves making an HTTP request using the content of the Encapsulated Request. Once the
Oblivious Gateway Resource has an HTTP response for this request, the following
steps occur to return this response to the Client:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-8"><li pn="section-2-8.1" derivedCounter="1.">
          <t indent="0" pn="section-2-8.1.1">The Oblivious Gateway Resource encapsulates the HTTP response following the
process in <xref target="response" format="default" sectionFormat="of" derivedContent="Section 4.4"/> and sends this in response to the request from the
Oblivious Relay Resource.</t>
        </li>
        <li pn="section-2-8.2" derivedCounter="2.">
          <t indent="0" pn="section-2-8.2.1">The Oblivious Relay Resource forwards this response to the Client.</t>
        </li>
        <li pn="section-2-8.3" derivedCounter="3.">
          <t indent="0" pn="section-2-8.3.1">The Client removes the encapsulation to obtain the response to the original
 request.</t>
        </li>
      </ol>
      <t indent="0" pn="section-2-9">This interaction provides authentication and confidentiality protection between
the Client and the Oblivious Gateway, but importantly not between the Client and
the Target Resource. While the Target Resource is a distinct HTTP resource from
the Oblivious Gateway Resource, they are both logically under the control of the
Oblivious Gateway, since the Oblivious Gateway Resource can unilaterally dictate
the responses returned from the Target Resource to the Client. This arrangement
is shown in <xref target="fig-overview" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
      <section anchor="applicability" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-applicability">Applicability</name>
        <t indent="0" pn="section-2.1-1">Oblivious HTTP has limited applicability.  Importantly, it requires explicit
support from a willing <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> and <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref>,
thereby limiting the use of Oblivious HTTP for generic applications;
see <xref target="server-responsibilities" format="default" sectionFormat="of" derivedContent="Section 6.3"/> for more information.</t>
        <t indent="0" pn="section-2.1-2">Many uses of HTTP benefit from being able to carry state between requests, such
as with cookies <xref target="COOKIES" format="default" sectionFormat="of" derivedContent="COOKIES"/>, authentication (<xref section="11" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-11" derivedContent="HTTP"/>), or even
alternative services <xref target="RFC7838" format="default" sectionFormat="of" derivedContent="RFC7838"/>.  Oblivious HTTP removes linkage at the
transport layer, which is only useful for an application that does not carry
state between requests.</t>
        <t indent="0" pn="section-2.1-3">Oblivious HTTP is primarily useful where the privacy risks associated with
possible stateful treatment of requests are sufficiently large that the cost of
deploying this protocol can be justified.  Oblivious HTTP is simpler and less
costly than more robust systems, like Prio <xref target="PRIO" format="default" sectionFormat="of" derivedContent="PRIO"/> or Tor <xref target="DMS2004" format="default" sectionFormat="of" derivedContent="DMS2004"/>, which
can provide stronger guarantees at higher operational costs.</t>
        <t indent="0" pn="section-2.1-4">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
several ways in which Oblivious HTTP is more expensive than a direct request:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.1-5">
          <li pn="section-2.1-5.1">
            <t indent="0" pn="section-2.1-5.1.1">Each request requires at least two regular HTTP requests, which could
increase latency.</t>
          </li>
          <li pn="section-2.1-5.2">
            <t indent="0" pn="section-2.1-5.2.1">Each request is expanded in size with additional HTTP fields,
encryption-related metadata, and Authenticated Encryption with Associated Data
(AEAD) expansion.</t>
          </li>
          <li pn="section-2.1-5.3">
            <t indent="0" pn="section-2.1-5.3.1">Deriving cryptographic keys and applying them for request and
response protection takes non-negligible computational resources.</t>
          </li>
        </ul>
        <t indent="0" pn="section-2.1-6">Examples of where preventing the linking of requests might justify these costs
include:</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-2.1-7">
          <dt pn="section-2.1-7.1">DNS queries:</dt>
          <dd pn="section-2.1-7.2">
            <t indent="0" pn="section-2.1-7.2.1">DNS queries made to a recursive resolver reveal information about the
requester, particularly if linked to other queries.</t>
          </dd>
          <dt pn="section-2.1-7.3">Telemetry submission:</dt>
          <dd pn="section-2.1-7.4">
            <t indent="0" pn="section-2.1-7.4.1">Applications that submit reports about their usage to their developers might
use Oblivious HTTP for some types of moderately sensitive data.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-2.1-8">These are examples of requests where there is information in a request 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 indent="0" pn="section-2.1-9">In addition to these limitations, <xref target="security" format="default" sectionFormat="of" derivedContent="Section 6"/> describes operational constraints
that are necessary to realize the goals of the protocol.</t>
      </section>
      <section anchor="conventions-and-definitions" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-conventions-and-definitions">Conventions and Definitions</name>
        <t indent="0" pn="section-2.2-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <t indent="0" pn="section-2.2-2">This document uses terminology from <xref target="HTTP" format="default" sectionFormat="of" derivedContent="HTTP"/> and defines several terms as
follows:</t>
        <dl newline="true" indent="3" spacing="normal" pn="section-2.2-3">
          <dt anchor="dfn-client" pn="section-2.2-3.1">Client:</dt>
          <dd pn="section-2.2-3.2">
            <t indent="0" pn="section-2.2-3.2.1">A Client originates Oblivious HTTP requests.  A Client is also an HTTP client
in two ways: for the <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref> and for the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay
Resource</xref>. However, when referring to the HTTP definition of client (<xref section="3.3" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-3.3" derivedContent="HTTP"/>), the term "HTTP client" is used; see <xref target="http-usage" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
          </dd>
          <dt anchor="dfn-enc-req" pn="section-2.2-3.3">Encapsulated Request:</dt>
          <dd pn="section-2.2-3.4">
            <t indent="0" pn="section-2.2-3.4.1">An HTTP request that is encapsulated in an HPKE-encrypted message; see
<xref target="request" format="default" sectionFormat="of" derivedContent="Section 4.3"/>.</t>
          </dd>
          <dt anchor="dfn-enc-res" pn="section-2.2-3.5">Encapsulated Response:</dt>
          <dd pn="section-2.2-3.6">
            <t indent="0" pn="section-2.2-3.6.1">An HTTP response that is encapsulated in an HPKE-encrypted message; see
<xref target="response" format="default" sectionFormat="of" derivedContent="Section 4.4"/>.</t>
          </dd>
          <dt anchor="dfn-relay" pn="section-2.2-3.7">Oblivious Relay Resource:</dt>
          <dd pn="section-2.2-3.8">
            <t indent="0" pn="section-2.2-3.8.1">An intermediary that forwards <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Requests</xref> and <xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Responses</xref> between
<xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> and a single <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref>.  In context, this can be
referred to simply as a "relay".</t>
          </dd>
          <dt anchor="dfn-gateway" pn="section-2.2-3.9">Oblivious Gateway Resource:</dt>
          <dd pn="section-2.2-3.10">
            <t indent="0" pn="section-2.2-3.10.1">A resource that can receive an <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref>, extract the contents of
that request, forward it to a <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref>, receive a response, encapsulate
that response, and then return the resulting <xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Encapsulated Response</xref>.  In
context, this can be referred to simply as a "gateway".</t>
          </dd>
          <dt anchor="dfn-target" pn="section-2.2-3.11">Target Resource:</dt>
          <dd pn="section-2.2-3.12">
            <t indent="0" pn="section-2.2-3.12.1">The resource that is the target of an <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref>.  This resource
logically handles only regular HTTP requests and responses, so it might be
ignorant of the use of Oblivious HTTP to reach it.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-2.2-4">This document includes pseudocode that uses the functions and conventions
defined in <xref target="HPKE" format="default" sectionFormat="of" derivedContent="HPKE"/>.</t>
        <t indent="0" pn="section-2.2-5">Encoding an integer to a sequence of bytes in network byte order is described
using the function <tt>encode(n, v)</tt>, where <tt>n</tt> is the number of bytes and <tt>v</tt> is
the integer value.  ASCII <xref target="ASCII" format="default" sectionFormat="of" derivedContent="ASCII"/> encoding of a string <tt>s</tt> is
indicated using the function <tt>encode_str(s)</tt>.</t>
        <t indent="0" pn="section-2.2-6">Formats are described using notation from <xref section="1.3" sectionFormat="of" target="QUIC" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9000#section-1.3" derivedContent="QUIC"/>.  An extension
to that notation expresses the number of bits in a field using a simple
mathematical function.</t>
      </section>
    </section>
    <section anchor="key-configuration" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-key-configuration">Key Configuration</name>
      <t indent="0" pn="section-3-1">A <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> needs to acquire information about the key configuration of the
<xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> in order to send <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Requests</xref>.
In order to ensure that Clients do not encapsulate messages that other entities
can intercept, the key configuration <bcp14>MUST</bcp14> be authenticated and have integrity
protection.</t>
      <t indent="0" pn="section-3-2">This document does not define how that acquisition occurs. However, in order to
help facilitate interoperability, it does specify a format for the keys. This
ensures that different Client implementations can be configured in the same way
and also enables advertising key configurations in a consistent format.  This
format might be used, for example, with HTTPS, as part of a system for
configuring or discovering key configurations.  However, note that such a system
needs to consider the potential for key configuration to be used to compromise
Client privacy; see <xref target="privacy" format="default" sectionFormat="of" derivedContent="Section 7"/>.</t>
      <t indent="0" pn="section-3-3">A Client might have multiple key configurations to select from when
encapsulating a request. Clients are responsible for selecting a preferred key
configuration from those it supports. Clients need to consider both the Key
Encapsulation Method (KEM) and the combinations of the Key Derivation Function
(KDF) and AEAD in this decision.</t>
      <section anchor="key-config" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-key-configuration-encoding">Key Configuration Encoding</name>
        <t indent="0" pn="section-3.1-1">A single <xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key configuration</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
algorithms. Each symmetric algorithm consists of an identifier for a KDF and an
identifier for an AEAD.</t>
        <t indent="0" pn="section-3.1-2"><xref target="format-key-config" format="default" sectionFormat="of" derivedContent="Figure 2"/> shows a single key configuration.</t>
        <figure anchor="format-key-config" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-a-single-key-configuration">A Single Key Configuration</name>
          <sourcecode type="tls-presentation" markers="false" pn="section-3.1-3.1">
HPKE Symmetric Algorithms {
  HPKE KDF ID (16),
  HPKE AEAD ID (16),
}

Key Config {
  Key Identifier (8),
  HPKE KEM ID (16),
  HPKE Public Key (Npk * 8),
  HPKE Symmetric Algorithms Length (16) = 4..65532,
  HPKE Symmetric Algorithms (32) ...,
}
</sourcecode>
        </figure>
        <t indent="0" pn="section-3.1-4">That is, a key configuration consists of the following fields:</t>
        <dl newline="true" indent="3" spacing="normal" pn="section-3.1-5">
          <dt pn="section-3.1-5.1">Key Identifier:</dt>
          <dd pn="section-3.1-5.2">
            <t indent="0" pn="section-3.1-5.2.1">An 8-bit value that identifies the key used by the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref>.</t>
          </dd>
          <dt pn="section-3.1-5.3">HPKE KEM ID:</dt>
          <dd pn="section-3.1-5.4">
            <t indent="0" pn="section-3.1-5.4.1">A 16-bit value that identifies the KEM used for the identified key as defined
in <xref section="7.1" sectionFormat="of" target="HPKE" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-7.1" derivedContent="HPKE"/> or the <eref target="https://www.iana.org/assignments/hpke" brackets="angle">"HPKE KEM Identifiers" registry</eref>.</t>
          </dd>
          <dt pn="section-3.1-5.5">HPKE Public Key:</dt>
          <dd pn="section-3.1-5.6">
            <t indent="0" pn="section-3.1-5.6.1">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" sectionFormat="of" target="HPKE" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-4" derivedContent="HPKE"/>.</t>
          </dd>
          <dt pn="section-3.1-5.7">HPKE Symmetric Algorithms Length:</dt>
          <dd pn="section-3.1-5.8">
            <t indent="0" pn="section-3.1-5.8.1">A 16-bit integer in network byte order that encodes the length, in bytes, of
the HPKE Symmetric Algorithms field that follows.</t>
          </dd>
          <dt pn="section-3.1-5.9">HPKE Symmetric Algorithms:</dt>
          <dd pn="section-3.1-5.10">
            <t indent="0" pn="section-3.1-5.10.1">One or more pairs of identifiers for the different combinations of HPKE KDF
and AEAD that the Oblivious Gateway Resource supports:</t>
            <dl newline="true" indent="3" spacing="normal" pn="section-3.1-5.10.2">
              <dt pn="section-3.1-5.10.2.1">HPKE KDF ID:</dt>
              <dd pn="section-3.1-5.10.2.2">
                <t indent="0" pn="section-3.1-5.10.2.2.1">A 16-bit HPKE KDF identifier as defined in <xref section="7.2" sectionFormat="of" target="HPKE" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-7.2" derivedContent="HPKE"/> or the <eref target="https://www.iana.org/assignments/hpke" brackets="angle">
"HPKE KDF Identifiers"
registry</eref>.</t>
              </dd>
              <dt pn="section-3.1-5.10.2.3">HPKE AEAD ID:</dt>
              <dd pn="section-3.1-5.10.2.4">
                <t indent="0" pn="section-3.1-5.10.2.4.1">A 16-bit HPKE AEAD identifier as defined in <xref section="7.3" sectionFormat="of" target="HPKE" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-7.3" derivedContent="HPKE"/> or the <eref target="https://www.iana.org/assignments/hpke" brackets="angle">"HPKE AEAD Identifiers"  registry</eref>.</t>
              </dd>
            </dl>
          </dd>
        </dl>
      </section>
      <section anchor="ohttp-keys" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-key-configuration-media-typ">Key Configuration Media Type</name>
        <t indent="0" pn="section-3.2-1">The "application/ohttp-keys" format is a media type that identifies a serialized
collection of <xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key configurations</xref>. The content of this media type comprises one
or more key configuration encodings (see <xref target="key-config" format="default" sectionFormat="of" derivedContent="Section 3.1"/>).  Each encoded
configuration is prefixed with a 2-byte integer in network byte order that
indicates the length of the key configuration in bytes.  The length-prefixed
encodings are concatenated to form a list.  See <xref target="iana-keys" format="default" sectionFormat="of" derivedContent="Section 9.1"/> for a definition
of the media type.</t>
        <t indent="0" pn="section-3.2-2">Evolution of the key configuration format is supported through the definition of
new formats that are identified by new media types.</t>
        <t indent="0" pn="section-3.2-3">A <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">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 collections.</t>
      </section>
    </section>
    <section anchor="hpke-encapsulation" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-hpke-encapsulation">HPKE Encapsulation</name>
      <t indent="0" pn="section-4-1">This document defines how a binary-encoded HTTP message <xref target="BINARY" format="default" sectionFormat="of" derivedContent="BINARY"/> is
encapsulated using HPKE <xref target="HPKE" format="default" sectionFormat="of" derivedContent="HPKE"/>.  Separate media types are defined to
distinguish request and response messages:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-2">
        <li pn="section-4-2.1">
          <t indent="0" pn="section-4-2.1.1">An <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref> format defined in <xref target="req-format" format="default" sectionFormat="of" derivedContent="Section 4.1"/> is identified by the
<xref target="iana-req" format="default" sectionFormat="of" derivedContent="Section 9.2">"<tt>message/ohttp-req</tt>" media type</xref>.</t>
        </li>
        <li pn="section-4-2.2">
          <t indent="0" pn="section-4-2.2.1">An <xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Encapsulated Response</xref> format defined in <xref target="res-format" format="default" sectionFormat="of" derivedContent="Section 4.2"/> is identified by the
<xref target="iana-res" format="default" sectionFormat="of" derivedContent="Section 9.3">"<tt>message/ohttp-res</tt>" media type</xref>.</t>
        </li>
      </ul>
      <t indent="0" pn="section-4-3">Alternative encapsulations or message formats are indicated using the media
type; see Sections <xref format="counter" target="req-res-media" sectionFormat="of" derivedContent="4.5"/> and <xref format="counter" target="repurposing" sectionFormat="of" derivedContent="4.6"/>.</t>
      <section anchor="req-format" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-request-format">Request Format</name>
        <t indent="0" pn="section-4.1-1">A message in "<tt>message/ohttp-req</tt>" format protects a binary HTTP request
message; see <xref target="fig-req-pt" format="default" sectionFormat="of" derivedContent="Figure 3"/>.</t>
        <figure anchor="fig-req-pt" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-plaintext-request-structure">Plaintext Request Structure</name>
          <artwork align="left" pn="section-4.1-2.1">
Request {
  Binary HTTP Message (..),
}
</artwork>
        </figure>
        <t indent="0" pn="section-4.1-3">This plaintext Request structure is encapsulated into a message in
"<tt>message/ohttp-req</tt>" form by generating an <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref>.  An
Encapsulated Request comprises a key identifier; HPKE parameters for the chosen
KEM, KDF, and AEAD; the encapsulated KEM shared secret (or <tt>enc</tt>); and an
HPKE-protected binary HTTP request message.</t>
        <t indent="0" pn="section-4.1-4">An Encapsulated Request is shown in <xref target="fig-enc-request" format="default" sectionFormat="of" derivedContent="Figure 4"/>. <xref target="request" format="default" sectionFormat="of" derivedContent="Section 4.3"/> describes
the process for constructing and processing an Encapsulated Request.</t>
        <figure anchor="fig-enc-request" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-encapsulated-request">Encapsulated Request</name>
          <artwork align="left" pn="section-4.1-5.1">
Encapsulated Request {
  Key Identifier (8),
  HPKE KEM ID (16),
  HPKE KDF ID (16),
  HPKE AEAD ID (16),
  Encapsulated KEM Shared Secret (8 * Nenc),
  HPKE-Protected Request (..),
}
</artwork>
        </figure>
        <t indent="0" pn="section-4.1-6">That is, an <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref> comprises a Key Identifier, an HPKE KEM ID, an
HPKE KDF ID, an HPKE AEAD ID, an Encapsulated KEM Shared Secret, and an
HPKE-Protected Request.  The Key Identifier, HPKE KEM ID, HPKE KDF ID, and HPKE
AEAD ID fields are defined in <xref target="key-config" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.  The Encapsulated KEM Shared
Secret is the output of the <tt>Encap()</tt> function for the KEM, which is <tt>Nenc</tt>
bytes in length, as defined in <xref section="4" sectionFormat="of" target="HPKE" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-4" derivedContent="HPKE"/>.</t>
      </section>
      <section anchor="res-format" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-response-format">Response Format</name>
        <t indent="0" pn="section-4.2-1">A message in "<tt>message/ohttp-res</tt>" format protects a binary HTTP response
message; see <xref target="fig-res-pt" format="default" sectionFormat="of" derivedContent="Figure 5"/>.</t>
        <figure anchor="fig-res-pt" align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-plaintext-response-structur">Plaintext Response Structure</name>
          <artwork align="left" pn="section-4.2-2.1">
Response {
  Binary HTTP Message (..),
}
</artwork>
        </figure>
        <t indent="0" pn="section-4.2-3">This plaintext Response structure is encapsulated into a message in
"<tt>message/ohttp-res</tt>" form by generating an <xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Encapsulated Response</xref>.  An
Encapsulated Response comprises a nonce and the AEAD-protected binary HTTP
response message.</t>
        <t indent="0" pn="section-4.2-4">An Encapsulated Response is shown in <xref target="fig-enc-response" format="default" sectionFormat="of" derivedContent="Figure 6"/>. <xref target="response" format="default" sectionFormat="of" derivedContent="Section 4.4"/> describes
the process for constructing and processing an Encapsulated Response.</t>
        <figure anchor="fig-enc-response" align="left" suppress-title="false" pn="figure-6">
          <name slugifiedName="name-encapsulated-response">Encapsulated Response</name>
          <artwork align="left" pn="section-4.2-5.1">
Encapsulated Response {
  Nonce (8 * max(Nn, Nk)),
  AEAD-Protected Response (..),
}
</artwork>
        </figure>
        <t indent="0" pn="section-4.2-6">That is, an <xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Encapsulated Response</xref> contains a Nonce and an AEAD-Protected
Response.  The Nonce field is either <tt>Nn</tt> or <tt>Nk</tt> bytes long, whichever is
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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-7.3" derivedContent="HPKE"/> or <eref target="https://www.iana.org/assignments/hpke" brackets="angle">the "HPKE AEAD
Identifiers" IANA
registry</eref>.  <tt>Nn</tt>
and <tt>Nk</tt> refer to the size of the AEAD nonce and key, respectively, in bytes.</t>
      </section>
      <section anchor="request" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-encapsulation-of-requests">Encapsulation of Requests</name>
        <t indent="0" pn="section-4.3-1"><xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> encapsulate a request, identified as <tt>request</tt>, using values from a <xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key
configuration</xref>:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-2">
          <li pn="section-4.3-2.1">
            <t indent="0" pn="section-4.3-2.1.1">the key identifier from the configuration (<tt>key_id</tt>) with the corresponding
KEM identified by <tt>kem_id</tt>,</t>
          </li>
          <li pn="section-4.3-2.2">
            <t indent="0" pn="section-4.3-2.2.1">the public key from the configuration (<tt>pkR</tt>), and</t>
          </li>
          <li pn="section-4.3-2.3">
            <t indent="0" pn="section-4.3-2.3.1">a combination of KDF (identified by <tt>kdf_id</tt>) and AEAD (identified by
<tt>aead_id</tt>) that the Client selects from those in the key configuration.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.3-3">The Client then constructs an <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref>, <tt>enc_request</tt>, from a binary-encoded HTTP request <xref target="BINARY" format="default" sectionFormat="of" derivedContent="BINARY"/> (<tt>request</tt>) as follows:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.3-4"><li pn="section-4.3-4.1" derivedCounter="1.">
            <t indent="0" pn="section-4.3-4.1.1">Construct a message header (<tt>hdr</tt>) 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 three 16-bit
integers, respectively, each in network byte order.</t>
          </li>
          <li pn="section-4.3-4.2" derivedCounter="2.">
            <t indent="0" pn="section-4.3-4.2.1">Build a sequence of bytes (<tt>info</tt>) by concatenating the ASCII-encoded string
"message/bhttp request", a zero byte, and the header.  Note: <xref target="repurposing" format="default" sectionFormat="of" derivedContent="Section 4.6"/>
discusses how alternative message formats might use a different <tt>info</tt> value.</t>
          </li>
          <li pn="section-4.3-4.3" derivedCounter="3.">
            <t indent="0" pn="section-4.3-4.3.1">Create a sending HPKE context by invoking <tt>SetupBaseS()</tt> (<xref section="5.1.1" sectionFormat="of" target="HPKE" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-5.1.1" derivedContent="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>
          </li>
          <li pn="section-4.3-4.4" derivedCounter="4.">
            <t indent="0" pn="section-4.3-4.4.1">Encrypt <tt>request</tt> by invoking the <tt>Seal()</tt> method on <tt>sctxt</tt> (<xref section="5.2" sectionFormat="of" target="HPKE" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-5.2" derivedContent="HPKE"/>) with empty associated data <tt>aad</tt>, yielding ciphertext <tt>ct</tt>.</t>
          </li>
          <li pn="section-4.3-4.5" derivedCounter="5.">
            <t indent="0" pn="section-4.3-4.5.1">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>
        <t indent="0" pn="section-4.3-5">Note that <tt>enc</tt> is of fixed length, so there is no ambiguity in parsing this
structure.</t>
        <t indent="0" pn="section-4.3-6">In pseudocode, this procedure is as follows:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-4.3-7">
hdr = concat(encode(1, key_id),
             encode(2, kem_id),
             encode(2, kdf_id),
             encode(2, aead_id))
info = concat(encode_str("message/bhttp request"),
              encode(1, 0),
              hdr)
enc, sctxt = SetupBaseS(pkR, info)
ct = sctxt.Seal("", request)
enc_request = concat(hdr, enc, ct)
</sourcecode>
        <t indent="0" pn="section-4.3-8">An <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> decrypts an Encapsulated Request by reversing this
process. To decapsulate an Encapsulated Request, <tt>enc_request</tt>:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.3-9"><li pn="section-4.3-9.1" derivedCounter="1.">
            <t indent="0" pn="section-4.3-9.1.1">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 Oblivious
Gateway Resource is then able to find the HPKE private key, <tt>skR</tt>,
corresponding to <tt>key_id</tt>.  </t>
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-4.3-9.1.2"><li pn="section-4.3-9.1.2.1" derivedCounter="a.">
                <t indent="0" pn="section-4.3-9.1.2.1.1">If <tt>key_id</tt> does not identify a key matching the type of <tt>kem_id</tt>, the
Oblivious Gateway Resource returns an error.</t>
              </li>
              <li pn="section-4.3-9.1.2.2" derivedCounter="b.">
                <t indent="0" pn="section-4.3-9.1.2.2.1">If <tt>kdf_id</tt> and <tt>aead_id</tt> identify a combination of KDF and AEAD that the
Oblivious Gateway Resource is unwilling to use with <tt>skR</tt>, the Oblivious
Gateway Resource returns an error.</t>
              </li>
            </ol>
          </li>
          <li pn="section-4.3-9.2" derivedCounter="2.">
            <t indent="0" pn="section-4.3-9.2.1">Build a sequence of bytes (<tt>info</tt>) by concatenating the ASCII-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 pn="section-4.3-9.3" derivedCounter="3.">
            <t indent="0" pn="section-4.3-9.3.1">Create a receiving HPKE context, <tt>rctxt</tt>, by invoking <tt>SetupBaseR()</tt>
(<xref section="5.1.1" sectionFormat="of" target="HPKE" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-5.1.1" derivedContent="HPKE"/>) with <tt>skR</tt>, <tt>enc</tt>, and <tt>info</tt>.</t>
          </li>
          <li pn="section-4.3-9.4" derivedCounter="4.">
            <t indent="0" pn="section-4.3-9.4.1">Decrypt <tt>ct</tt> by invoking the <tt>Open()</tt> method on <tt>rctxt</tt> (<xref section="5.2" sectionFormat="of" target="HPKE" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-5.2" derivedContent="HPKE"/>), with an empty 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>
        </ol>
        <t indent="0" pn="section-4.3-10">In pseudocode, this procedure is as follows:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-4.3-11">
key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request)
info = concat(encode_str("message/bhttp request"),
              encode(1, 0),
              encode(1, key_id),
              encode(2, kem_id),
              encode(2, kdf_id),
              encode(2, aead_id))
rctxt = SetupBaseR(enc, skR, info)
request, error = rctxt.Open("", ct)
</sourcecode>
        <t indent="0" pn="section-4.3-12">The Oblivious Gateway Resource retains the HPKE context, <tt>rctxt</tt>, so that it can
encapsulate a response.</t>
      </section>
      <section anchor="response" numbered="true" removeInRFC="false" toc="include" pn="section-4.4">
        <name slugifiedName="name-encapsulation-of-responses">Encapsulation of Responses</name>
        <t indent="0" pn="section-4.4-1"><xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resources</xref> generate an <xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Encapsulated Response</xref> (<tt>enc_response</tt>)
from a binary-encoded HTTP response <xref target="BINARY" format="default" sectionFormat="of" derivedContent="BINARY"/> (<tt>response</tt>).  The Oblivious
Gateway Resource uses the HPKE receiver context (<tt>rctxt</tt>) as the HPKE context
(<tt>context</tt>) as follows:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.4-2"><li pn="section-4.4-2.1" derivedCounter="1.">
            <t indent="0" pn="section-4.4-2.1.1">Export a secret (<tt>secret</tt>) from <tt>context</tt>, using the string "message/bhttp
response" as the <tt>exporter_context</tt> parameter to <tt>context.Export</tt>; see
<xref section="5.3" sectionFormat="of" target="HPKE" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-5.3" derivedContent="HPKE"/>.  The length of this secret is <tt>max(Nn, Nk)</tt>, where
<tt>Nn</tt> and <tt>Nk</tt> are the length of the AEAD key and nonce that are associated with <tt>context</tt>.
Note: <xref target="repurposing" format="default" sectionFormat="of" derivedContent="Section 4.6"/> discusses how alternative message formats might use a
different <tt>context</tt> value.</t>
          </li>
          <li pn="section-4.4-2.2" derivedCounter="2.">
            <t indent="0" pn="section-4.4-2.2.1">Generate a random value of length <tt>max(Nn, Nk)</tt> bytes, called
<tt>response_nonce</tt>.</t>
          </li>
          <li pn="section-4.4-2.3" derivedCounter="3.">
            <t indent="0" pn="section-4.4-2.3.1">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 this
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>.</t>
          </li>
          <li pn="section-4.4-2.4" derivedCounter="4.">
            <t indent="0" pn="section-4.4-2.4.1">Use the <tt>Expand</tt> function provided by the same KDF to create an AEAD key,
<tt>key</tt>, of length <tt>Nk</tt> -- the length of the keys used by the AEAD associated
with <tt>context</tt>. Generating <tt>aead_key</tt> uses a label of "key".</t>
          </li>
          <li pn="section-4.4-2.5" derivedCounter="5.">
            <t indent="0" pn="section-4.4-2.5.1">Use the same <tt>Expand</tt> function to create a nonce, <tt>nonce</tt>, of length <tt>Nn</tt> --
the length of the nonce used by the AEAD. Generating <tt>aead_nonce</tt> uses a
label of "nonce".</t>
          </li>
          <li pn="section-4.4-2.6" derivedCounter="6.">
            <t indent="0" pn="section-4.4-2.6.1">Encrypt <tt>response</tt>, passing the AEAD function Seal the values 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>
          </li>
          <li pn="section-4.4-2.7" derivedCounter="7.">
            <t indent="0" pn="section-4.4-2.7.1">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>
        <t indent="0" pn="section-4.4-3">In pseudocode, this procedure is as follows:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-4.4-4">
secret = context.Export("message/bhttp response", max(Nn, Nk))
response_nonce = random(max(Nn, Nk))
salt = concat(enc, response_nonce)
prk = Extract(salt, secret)
aead_key = Expand(prk, "key", Nk)
aead_nonce = Expand(prk, "nonce", Nn)
ct = Seal(aead_key, aead_nonce, "", response)
enc_response = concat(response_nonce, ct)
</sourcecode>
        <t indent="0" pn="section-4.4-5"><xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> decrypt an Encapsulated Response by reversing this process.  That is,
Clients first parse <tt>enc_response</tt> into <tt>response_nonce</tt> and <tt>ct</tt>. Then, they
follow the same process to derive values for <tt>aead_key</tt> and <tt>aead_nonce</tt>, using
their sending HPKE context, <tt>sctxt</tt>, as the HPKE context, <tt>context</tt>.</t>
        <t indent="0" pn="section-4.4-6">The Client uses these values to decrypt <tt>ct</tt> using the AEAD function <tt>Open</tt>.
Decrypting might produce an error, as follows:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-4.4-7">
response, error = Open(aead_key, aead_nonce, "", ct)
</sourcecode>
      </section>
      <section anchor="req-res-media" numbered="true" removeInRFC="false" toc="include" pn="section-4.5">
        <name slugifiedName="name-request-and-response-media-">Request and Response Media Types</name>
        <t indent="0" pn="section-4.5-1">Media types are used to identify Encapsulated Requests and Responses; see
Sections <xref format="counter" target="iana-req" sectionFormat="of" derivedContent="9.2"/> and <xref format="counter" target="iana-res" sectionFormat="of" derivedContent="9.3"/> for definitions of these media types.</t>
        <t indent="0" pn="section-4.5-2">Evolution of the format of Encapsulated Requests and Responses is supported
through the definition of new formats that are identified by new media types.
New media types might be defined to use a similar encapsulation with a different
HTTP message format than in <xref target="BINARY" format="default" sectionFormat="of" derivedContent="BINARY"/>; see <xref target="repurposing" format="default" sectionFormat="of" derivedContent="Section 4.6"/> for guidance on
reusing this encapsulation method.  Alternatively, a new encapsulation method
might be defined.</t>
      </section>
      <section anchor="repurposing" numbered="true" removeInRFC="false" toc="include" pn="section-4.6">
        <name slugifiedName="name-repurposing-the-encapsulati">Repurposing the Encapsulation Format</name>
        <t indent="0" pn="section-4.6-1">The encrypted payload of an Oblivious HTTP request and response is a binary HTTP message
<xref target="BINARY" format="default" sectionFormat="of" derivedContent="BINARY"/>.  The <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> and <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> agree on this encrypted
payload type by specifying the media type "message/bhttp" in the HPKE info
string and HPKE export context string for request and response encryption,
respectively.</t>
        <t indent="0" pn="section-4.6-2">Future specifications may repurpose the encapsulation mechanism described in
this document.  This requires that the specification define a new media type.
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>
        <t indent="0" pn="section-4.6-3">For example, a future specification might encapsulate DNS messages, which use
the "application/dns-message" media type <xref target="RFC8484" format="default" sectionFormat="of" derivedContent="RFC8484"/>.  In creating a new,
encrypted media types, specifications might define the use of string
"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"
for response encryption.</t>
      </section>
    </section>
    <section anchor="http-usage" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-http-usage">HTTP Usage</name>
      <t indent="0" pn="section-5-1">A <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> interacts with the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> by constructing an
<xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref>.  This Encapsulated Request is included as the content of a
POST request to the Oblivious Relay Resource.  This request only needs those
fields necessary to carry the Encapsulated Request: a method of POST, a target
URI of the Oblivious Relay Resource, a header field containing the content type
(see <xref target="iana-req" format="default" sectionFormat="of" derivedContent="Section 9.2"/>), and the Encapsulated Request as the request content. In the
request to the Oblivious Relay Resource, Clients <bcp14>MAY</bcp14> include additional
fields. However, additional fields <bcp14>MUST</bcp14> be independent of the Encapsulated
Request and <bcp14>MUST</bcp14> be fields that the Oblivious Relay Resource will remove before
forwarding the Encapsulated Request towards the target, such as the <tt>Connection</tt>
or <tt>Proxy-Authorization</tt> header fields <xref target="HTTP" format="default" sectionFormat="of" derivedContent="HTTP"/>.</t>
      <t indent="0" pn="section-5-2">The Client role in this protocol acts as an HTTP client both with respect to the
Oblivious Relay Resource and the <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref>.  The request, which the Client
makes to the Target Resource, diverges from typical HTTP assumptions about
the use of a connection (see <xref section="3.3" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-3.3" derivedContent="HTTP"/>) in that the request and
response are encrypted rather than sent over a connection.  The Oblivious Relay
Resource and the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> also act as HTTP clients toward the
Oblivious Gateway Resource and Target Resource, respectively.</t>
      <t indent="0" pn="section-5-3">In order to achieve the privacy and security goals of the protocol, a Client
also needs to observe the guidance in <xref target="sec-client" format="default" sectionFormat="of" derivedContent="Section 6.1"/>.</t>
      <t indent="0" pn="section-5-4">The Oblivious Relay Resource interacts with the Oblivious Gateway Resource as an
HTTP client by constructing a request using the same restrictions as the Client
request, except that the target URI is the Oblivious Gateway Resource.  The
content of this request is copied from the Client.  An Oblivious Relay Resource <bcp14>MAY</bcp14> reject
requests that are obviously invalid, such as a request with no content. The Oblivious Relay
Resource <bcp14>MUST NOT</bcp14> add information to the request without the Client being aware of
the type of information that might be added; see <xref target="relay-responsibilities" format="default" sectionFormat="of" derivedContent="Section 6.2"/> for
more information on relay responsibilities.</t>
      <t indent="0" pn="section-5-5">When a response is received from the Oblivious Gateway Resource, the Oblivious
Relay Resource forwards the response according to the rules of an HTTP proxy;
see <xref section="7.6" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-7.6" derivedContent="HTTP"/>.  In case of timeout or error, the Oblivious Relay
Resource can generate a response with an appropriate status code.</t>
      <t indent="0" pn="section-5-6">In order to achieve the privacy and security goals of the protocol, an Oblivious
Relay Resource also needs to observe the guidance in <xref target="relay-responsibilities" format="default" sectionFormat="of" derivedContent="Section 6.2"/>.</t>
      <t indent="0" pn="section-5-7">An Oblivious Gateway Resource acts as a gateway for requests to the Target
Resource (see <xref section="7.6" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-7.6" derivedContent="HTTP"/>).  The one exception is that any
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
Encapsulated Request; see <xref target="errors" format="default" sectionFormat="of" derivedContent="Section 5.2"/>.</t>
      <t indent="0" pn="section-5-8">An Oblivious Gateway Resource, if it receives any response from the Target
Resource, sends a single 200 response containing the <xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Encapsulated Response</xref>.
Like the request from the Client, this response <bcp14>MUST</bcp14> only contain those fields
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 convey information
that does not reveal information about the Encapsulated Response.</t>
      <t indent="0" pn="section-5-9">An Oblivious Gateway Resource that does not receive a response can itself
generate a response with an appropriate error status code (such as 504 (Gateway
Timeout); see <xref section="15.6.5" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-15.6.5" derivedContent="HTTP"/>), which is then encapsulated in the
same way as a successful response.</t>
      <t indent="0" pn="section-5-10">In order to achieve the privacy and security goals of the protocol, an Oblivious
Gateway Resource also needs to observe the guidance in
<xref target="server-responsibilities" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</t>
      <section anchor="informational-responses" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-informational-responses">Informational Responses</name>
        <t indent="0" pn="section-5.1-1">This encapsulation does not permit progressive processing of responses.
Though the binary HTTP response format does support the inclusion of
informational (1xx) status codes, the AEAD encapsulation cannot be removed until
the entire message is received.</t>
        <t indent="0" pn="section-5.1-2">In particular, the <tt>Expect</tt> header field with 100-continue (see <xref section="10.1.1" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-10.1.1" derivedContent="HTTP"/>) cannot be used.  <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> <bcp14>MUST NOT</bcp14> construct a request that includes a
100-continue expectation; the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> <bcp14>MUST</bcp14> generate an error
if a 100-continue expectation is received.</t>
      </section>
      <section anchor="errors" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-errors">Errors</name>
        <t indent="0" pn="section-5.2-1">A server that receives an invalid message for any reason <bcp14>MUST</bcp14> generate an HTTP
response with a 4xx status code.</t>
        <t indent="0" pn="section-5.2-2">Errors detected by the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> and errors detected by the
<xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> before removing protection (including being unable to
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>
        <t indent="0" pn="section-5.2-3">Errors detected by the Oblivious Gateway Resource after successfully removing
encapsulation and errors detected by the <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref> <bcp14>MUST</bcp14> be sent in an
<xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Encapsulated Response</xref>.  This might be because the <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref> is
malformed or the Target Resource does not produce a response.  In either case,
the Oblivious Gateway Resource can generate a response with an appropriate error
status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see Sections <xref target="HTTP" section="15.5.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-15.5.1" derivedContent="HTTP"/> and <xref target="HTTP" section="15.6.5" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-15.6.5" derivedContent="HTTP"/> of <xref target="HTTP" format="default" sectionFormat="of" derivedContent="HTTP"/>, respectively).  This response is encapsulated in
the same way as a successful response.</t>
        <t indent="0" pn="section-5.2-4">Errors in the encapsulation of requests mean that responses cannot be
encapsulated.  This includes cases where the <xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key configuration</xref> is incorrect or
outdated.  The Oblivious Gateway Resource can generate and send a response with
a 4xx status code to the Oblivious Relay Resource.  This response <bcp14>MAY</bcp14> be
forwarded to the <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> or treated by the Oblivious Relay Resource as a failure.
If a Client receives a response that is not an Encapsulated Response, this could
indicate that the Client configuration used to construct the request is
incorrect or out of date.</t>
      </section>
      <section anchor="ohttp-key-problem" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-signaling-key-configuration">Signaling Key Configuration Problems</name>
        <t indent="0" pn="section-5.3-1">The problem type <xref target="PROBLEM" format="default" sectionFormat="of" derivedContent="PROBLEM"/> of
"https://iana.org/assignments/http-problem-types#ohttp-key" is defined in this
section.  An <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> <bcp14>MAY</bcp14> use this problem type in a response
to indicate that an <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref> used an outdated or incorrect <xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key
configuration</xref>.</t>
        <t indent="0" pn="section-5.3-2"><xref target="fig-key-problem" format="default" sectionFormat="of" derivedContent="Figure 7"/> shows an example response in HTTP/1.1 format.</t>
        <figure anchor="fig-key-problem" align="left" suppress-title="false" pn="figure-7">
          <name slugifiedName="name-example-rejection-of-key-co">Example Rejection of Key Configuration</name>
          <sourcecode type="http-message" markers="false" pn="section-5.3-3.1">
HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json
Content-Length: 106

{"type":"https://iana.org/assignments/http-problem-types#ohttp-key",
"title": "key identifier unknown"}
</sourcecode>
        </figure>
        <t indent="0" pn="section-5.3-4">As this response cannot be encrypted, it might not reach the <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref>.  A Client
cannot rely on the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> using this problem type.  A Client
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 Oblivious
Relay Resource.  A Client might manage the risk of an outdated key configuration
using a heuristic approach whereby it periodically refreshes its key
configuration if it receives a response with an error status code that has not
been encapsulated.</t>
      </section>
    </section>
    <section anchor="security" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">In this design, a <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> wishes to make a request to an <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway
Resource</xref> that is forwarded to a <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref>. The Client wishes to make this
request without linking that request with either of the following:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6-2">
        <li pn="section-6-2.1">
          <t indent="0" pn="section-6-2.1.1">The identity at the network and transport layer of the Client (that is, the
Client IP address and TCP or UDP port number the Client uses to create a
connection).</t>
        </li>
        <li pn="section-6-2.2">
          <t indent="0" pn="section-6-2.2.1">Any other request the Client might have made in the past or might make in the
future.</t>
        </li>
      </ul>
      <t indent="0" pn="section-6-3">In order to ensure this, the Client selects a relay (that serves the
<xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref>) that it trusts will protect this information
by forwarding the Encapsulated Request and Response without passing it
to the server (that serves the Oblivious Gateway Resource).</t>
      <t indent="0" pn="section-6-4">In this section, a deployment where there are three entities is considered:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6-5">
        <li pn="section-6-5.1">
          <t indent="0" pn="section-6-5.1.1">A Client makes requests and receives responses.</t>
        </li>
        <li pn="section-6-5.2">
          <t indent="0" pn="section-6-5.2.1">A relay operates the Oblivious Relay Resource.</t>
        </li>
        <li pn="section-6-5.3">
          <t indent="0" pn="section-6-5.3.1">A server operates both the Oblivious Gateway Resource and the Target Resource.</t>
        </li>
      </ul>
      <t indent="0" pn="section-6-6"><xref target="separate-target" format="default" sectionFormat="of" derivedContent="Section 6.10"/> discusses the security implications for a case where
different servers operate the Oblivious Gateway Resource and Target Resource.</t>
      <t indent="0" pn="section-6-7">Requests from the Client to Oblivious Relay Resource and from Oblivious Relay
Resource to Oblivious Gateway Resource <bcp14>MUST</bcp14> use HTTPS in order to provide
unlinkability in the presence of a network observer.</t>
      <t indent="0" pn="section-6-8">To achieve the stated privacy goals, the Oblivious Relay Resource cannot be
operated by the same entity as the Oblivious Gateway Resource. However,
colocation of the Oblivious Gateway Resource and Target Resource simplifies the
interactions between those resources without affecting Client privacy.</t>
      <t indent="0" pn="section-6-9">As a consequence of this configuration, Oblivious HTTP prevents linkability
described above. Informally, this means:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6-10"><li pn="section-6-10.1" derivedCounter="1.">
          <t indent="0" pn="section-6-10.1.1">Requests and responses are known only to Clients and Oblivious Gateway
Resources.  In particular, the Oblivious Relay Resource knows the origin and
destination of an Encapsulated Request and Response, yet it does not know the
decrypted contents.  Likewise, Oblivious Gateway Resources learn only the
Oblivious Relay Resource and the decrypted request.  No entity other than the
Client can see the plaintext request and response and can attribute them to
the Client.</t>
        </li>
        <li pn="section-6-10.2" derivedCounter="2.">
          <t indent="0" pn="section-6-10.2.1">Oblivious Gateway Resources, and therefore Target Resources, cannot link
requests from the same Client in the absence of unique per-Client keys.</t>
        </li>
      </ol>
      <t indent="0" pn="section-6-11">Traffic analysis that might affect these properties is outside the scope of this
document; see <xref target="ta" format="default" sectionFormat="of" derivedContent="Section 6.2.3"/>.</t>
      <t indent="0" pn="section-6-12">A formal analysis of Oblivious HTTP is in <xref target="OHTTP-ANALYSIS" format="default" sectionFormat="of" derivedContent="OHTTP-ANALYSIS"/>.</t>
      <section anchor="sec-client" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-client-responsibilities">Client Responsibilities</name>
        <t indent="0" pn="section-6.1-1">Because <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> do not authenticate the <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref> when using Oblivious
HTTP, Clients <bcp14>MUST</bcp14> have some mechanism to authorize an <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway
Resource</xref> for use with a Target Resource. One possible means of authorization is
an allowlist.  This ensures that Oblivious Gateway Resources are not misused to
forward traffic to arbitrary Target Resources. <xref target="server-responsibilities" format="default" sectionFormat="of" derivedContent="Section 6.3"/>
describes similar responsibilities that apply to Oblivious Gateway Resources.</t>
        <t indent="0" pn="section-6.1-2">Clients <bcp14>MUST</bcp14> ensure that the <xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key configuration</xref> they select for generating
<xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Requests</xref> is integrity protected and authenticated so that it can
be attributed to the Oblivious Gateway Resource; see <xref target="key-configuration" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
        <t indent="0" pn="section-6.1-3">Since Clients connect directly to the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> instead of the
Target Resource, application configurations wherein Clients make policy
decisions about target connections, e.g., to apply certificate pinning, are
incompatible with Oblivious HTTP.  In such cases, alternative technologies such
as HTTP CONNECT (<xref section="9.3.6" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-9.3.6" derivedContent="HTTP"/>) can be used. Applications could
implement related policies on key configurations and relay connections, though
these might not provide the same properties as policies enforced directly on
target connections. Instead, when this difference is relevant, applications can
connect directly to the target at the cost of either privacy or performance.</t>
        <t indent="0" pn="section-6.1-4">Clients cannot carry connection-level state between requests as they only
establish direct connections to the relay responsible for the Oblivious Relay
Resource.  However, the content of requests might be used by a server to
correlate requests.  Cookies <xref target="COOKIES" format="default" sectionFormat="of" derivedContent="COOKIES"/> are the most obvious feature that might
be used to correlate requests, but any identity information and authentication
credentials might have the same effect.  Clients also need to treat information
learned from responses with similar care when constructing subsequent requests,
which includes the identity of resources.</t>
        <t indent="0" pn="section-6.1-5">Clients <bcp14>MUST</bcp14> generate a new HPKE context for every request, using a good source
of entropy <xref target="RANDOM" format="default" sectionFormat="of" derivedContent="RANDOM"/> for generating keys. Key reuse not only risks
requests being linked but also could expose request and response contents to the
relay.</t>
        <t indent="0" pn="section-6.1-6">The request the Client sends to the Oblivious Relay Resource only requires
minimal information; see <xref target="http-usage" format="default" sectionFormat="of" derivedContent="Section 5"/>. The request that carries the
Encapsulated Request and that is sent to the Oblivious Relay Resource <bcp14>MUST NOT</bcp14>
include identifying information unless the Client can trust that this
information is removed by the relay. A Client <bcp14>MAY</bcp14> include information only for
the Oblivious Relay Resource in header fields identified by the <tt>Connection</tt>
header field if it trusts the relay to remove these, as required by <xref section="7.6.1" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-7.6.1" derivedContent="HTTP"/>. The Client needs to trust that the relay does not replicate the
source addressing information in the request it forwards.</t>
        <t indent="0" pn="section-6.1-7">Clients rely on the Oblivious Relay Resource to forward Encapsulated Requests
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 anchor="relay-responsibilities" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-relay-responsibilities">Relay Responsibilities</name>
        <t indent="0" pn="section-6.2-1">The relay that serves the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> has a very simple function
to perform. For each request it receives, it makes a request of the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious
Gateway Resource</xref> that includes the same content. When it receives a response,
it sends a response to the <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> that includes the content of the response
from the Oblivious Gateway Resource.</t>
        <t indent="0" pn="section-6.2-2">When forwarding a request, the relay <bcp14>MUST</bcp14> follow the forwarding rules in
<xref section="7.6" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-7.6" derivedContent="HTTP"/>.  A generic HTTP intermediary implementation is suitable
for the purposes of serving an Oblivious Relay Resource, but additional care is
needed to ensure that Client privacy is maintained.</t>
        <t indent="0" pn="section-6.2-3">Firstly, a generic implementation will forward unknown fields.  For Oblivious
HTTP, an Oblivious Relay Resource <bcp14>SHOULD NOT</bcp14> forward unknown fields.  Though
Clients are not expected to include fields that might contain identifying
information, removing unknown fields removes this privacy risk.</t>
        <t indent="0" pn="section-6.2-4">Secondly, generic implementations are often configured to augment requests with
information about the Client, such as the Via field or the Forwarded field
<xref target="FORWARDED" format="default" sectionFormat="of" derivedContent="FORWARDED"/>.  A relay <bcp14>MUST NOT</bcp14> add information when forwarding
requests that might be used to identify Clients, except for information that
a Client is aware of; see <xref target="differential" format="default" sectionFormat="of" derivedContent="Section 6.2.1"/>.</t>
        <t indent="0" pn="section-6.2-5">Finally, a relay can also generate responses, though it is assumed to not be
able to examine the content of a request (other than to observe the choice of
key identifier, KDF, and AEAD); therefore, it is also assumed that it cannot
generate an <xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Encapsulated Response</xref>.</t>
        <section anchor="differential" numbered="true" removeInRFC="false" toc="include" pn="section-6.2.1">
          <name slugifiedName="name-differential-treatment">Differential Treatment</name>
          <t indent="0" pn="section-6.2.1-1">A relay <bcp14>MAY</bcp14> add information to requests if the <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> is aware of the nature of
the information that could be added.  Any addition <bcp14>MUST NOT</bcp14> include information
that uniquely and permanently identifies the Client, including any pseudonymous identifier.
Information added by the relay -- beyond what is already revealed through
<xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Requests</xref> from Clients -- can reduce the size of the anonymity set of
Clients at a gateway.</t>
          <t indent="0" pn="section-6.2.1-2">A Client 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
a Client might learn about added information is not defined in this document.</t>
          <t indent="0" pn="section-6.2.1-3">Moreover, relays <bcp14>MAY</bcp14> apply differential treatment to Clients that engage in
abusive behavior, e.g., by sending too many requests in comparison to other
Clients, or as a response to rate limits signaled from the gateway. Any such
differential treatment can reveal information to the gateway that would not be
revealed otherwise and therefore reduce the size of the anonymity set of Clients
using a gateway. For example, if a relay chooses to rate limit or block an
abusive Client, this means that any Client requests that are not treated this
way are known to be non-abusive by the gateway. Clients need to consider the
likelihood of such differential treatment and the privacy risks when using a
relay.</t>
          <t indent="0" pn="section-6.2.1-4">Some patterns of abuse cannot be detected without access to the request that is
made to the target. This means that only the gateway or the target is in a
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
differently to requests it cannot decapsulate, as mentioned in <xref target="errors" format="default" sectionFormat="of" derivedContent="Section 5.2"/>. A
relay that acts on this feedback could -- either inadvertently or by design --
lead to Client deanonymization.</t>
        </section>
        <section anchor="dos" numbered="true" removeInRFC="false" toc="include" pn="section-6.2.2">
          <name slugifiedName="name-denial-of-service">Denial of Service</name>
          <t indent="0" pn="section-6.2.2-1">As there are privacy benefits from having a large rate of requests forwarded by
the same relay (see <xref target="ta" format="default" sectionFormat="of" derivedContent="Section 6.2.3"/>), servers that operate the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref>
might need an arrangement with <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resources</xref>. This arrangement might
be necessary to prevent having the large volume of requests being classified as
an attack by the server.</t>
          <t indent="0" pn="section-6.2.2-2">If a server accepts a larger volume of requests from a relay, it needs to trust
that the relay does not allow abusive levels of request volumes from
<xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref>. That is, if a server allows requests from the relay to be exempt from
rate limits, the server might want to ensure that the relay applies a
rate-limiting policy that is acceptable to the server.</t>
          <t indent="0" pn="section-6.2.2-3">Servers that enter into an agreement with a relay that enables a higher request
rate might choose to authenticate the relay to enable the higher rate.</t>
        </section>
        <section anchor="ta" numbered="true" removeInRFC="false" toc="include" pn="section-6.2.3">
          <name slugifiedName="name-traffic-analysis">Traffic Analysis</name>
          <t indent="0" pn="section-6.2.3-1">Using HTTPS protects information about which resources are the subject of
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
traffic analysis by such network observers.</t>
          <t indent="0" pn="section-6.2.3-2">The time at which Encapsulated Request or Response messages are sent can
reveal information to a network observer. Though messages exchanged between the
<xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> and the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> might be sent in a
single connection, traffic analysis could be used to match messages that are
forwarded by the relay.</t>
          <t indent="0" pn="section-6.2.3-3">A relay could, as part of its function, delay requests before forwarding them.
Delays might increase the anonymity set into which each request is
attributed. Any delay also increases the time that a <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> waits for a
response, so delays <bcp14>SHOULD</bcp14> only be added with the consent -- or at least
awareness -- of Clients.</t>
          <t indent="0" pn="section-6.2.3-4">A relay that forwards large volumes of exchanges can provide better privacy by
providing larger sets of messages that need to be matched.</t>
          <t indent="0" pn="section-6.2.3-5">Traffic analysis is not restricted to network observers. A malicious Oblivious Relay Resource could
use traffic analysis to learn information about otherwise encrypted requests
and responses relayed between Clients and gateways. An Oblivious Relay Resource terminates
TLS connections from Clients, so they see message boundaries. This privileged
position allows for richer feature extraction from encrypted data, which might
improve traffic analysis.</t>
          <t indent="0" pn="section-6.2.3-6">Clients and Oblivious Gateway Resources can use padding to reduce the
effectiveness of traffic analysis.  Padding is a capability provided by binary
HTTP messages; see <xref section="3.8" sectionFormat="of" target="BINARY" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9292#section-3.8" derivedContent="BINARY"/>.  If the encapsulation method
described in this document is used to protect a different message type (see
<xref target="repurposing" format="default" sectionFormat="of" derivedContent="Section 4.6"/>), that message format might need to include padding support.
Oblivious Relay Resources can also use padding for the same reason but need to
operate at the HTTP layer since they cannot manipulate binary HTTP messages; for
example, see <xref section="10.7" sectionFormat="of" target="HTTP2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9113#section-10.7" derivedContent="HTTP/2"/> or <xref section="10.7" sectionFormat="of" target="HTTP3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9114#section-10.7" derivedContent="HTTP/3"/>).</t>
        </section>
      </section>
      <section anchor="server-responsibilities" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-server-responsibilities">Server Responsibilities</name>
        <t indent="0" pn="section-6.3-1">The <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> can be operated by a different entity than the
<xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref>.  However, this means that the <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> needs to trust the
Oblivious Gateway Resource not to modify requests or responses.  This analysis
concerns itself with a deployment scenario where a single server provides both
the Oblivious Gateway Resource and Target Resource.</t>
        <t indent="0" pn="section-6.3-2">A server that operates both Oblivious Gateway and Target Resources is
responsible for removing request encryption, generating a response to the
<xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref>, and encrypting the response.</t>
        <t indent="0" pn="section-6.3-3">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
attacks; see <xref target="ta" format="default" sectionFormat="of" derivedContent="Section 6.2.3"/>.</t>
        <t indent="0" pn="section-6.3-4">If separate entities provide the Oblivious Gateway Resource and Target Resource,
these entities might need an arrangement similar to that between server and
relay for managing denial of service; see <xref target="dos" format="default" sectionFormat="of" derivedContent="Section 6.2.2"/>. Moreover, the Oblivious
Gateway Resource <bcp14>SHOULD</bcp14> have some mechanism to ensure that the Oblivious Gateway
Resource is not misused as a relay for HTTP messages to an arbitrary Target
Resource, such as an allowlist.</t>
        <t indent="0" pn="section-6.3-5">Non-secure requests -- such as those with the "http" scheme as opposed 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 without the protections afforded by HTTPS, they could be inspected or
modified by a network attacker.  Note that a request could be forwarded without
protection if the two resources share an origin.</t>
      </section>
      <section anchor="key-management" numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-key-management">Key Management</name>
        <t indent="0" pn="section-6.4-1">An <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> needs to have a plan for replacing keys. This
might include regular replacement of keys, which can be assigned new key
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
been replaced, the server can respond with an HTTP 422 (Unprocessable Content)
status code.</t>
        <t indent="0" pn="section-6.4-2">A server can also use a 422 status code if the server has a key that corresponds
to the key identifier, but the <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref> cannot be successfully
decrypted using the key.</t>
        <t indent="0" pn="section-6.4-3">A server <bcp14>MUST</bcp14> ensure that the HPKE keys it uses are not valid for any other
protocol that uses HPKE with the "message/bhttp request" label.  Designers of
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
HPKE.  The "message/bhttp response" label was chosen for symmetry only as it
provides key diversity only within the HPKE context created using the
"message/bhttp request" label; see <xref target="repurposing" format="default" sectionFormat="of" derivedContent="Section 4.6"/>.</t>
      </section>
      <section anchor="replay" numbered="true" removeInRFC="false" toc="include" pn="section-6.5">
        <name slugifiedName="name-replay-attacks">Replay Attacks</name>
        <t indent="0" pn="section-6.5-1">A server is responsible for either rejecting replayed requests or ensuring that
the effect of replays does not adversely affect <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> or resources.</t>
        <t indent="0" pn="section-6.5-2"><xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Requests</xref> can be copied and replayed by the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay
Resource</xref>. The threat model for Oblivious HTTP allows the possibility that an
Oblivious Relay Resource might replay requests. Furthermore, if a Client sends
an Encapsulated Request in TLS early data (see <xref section="8" sectionFormat="of" target="TLS" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-8" derivedContent="TLS"/> and
<xref target="RFC8470" format="default" sectionFormat="of" derivedContent="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
that might be employed are similar to TLS early data.</t>
        <t indent="0" pn="section-6.5-3">It is the responsibility of the application that uses Oblivious HTTP to either
reject replayed requests or ensure that replayed requests have no adverse
effect on their operation.  This section describes some approaches that are
universally applicable and suggestions for more targeted techniques.</t>
        <t indent="0" pn="section-6.5-4">A Client or Oblivious Relay Resource <bcp14>MUST NOT</bcp14> automatically attempt to retry a
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 section="8.1.4" sectionFormat="of" target="HTTP2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9113#section-8.1.4" derivedContent="HTTP/2"/>), the HTTP/3 H3_REQUEST_REJECTED error code (<xref section="8.1" sectionFormat="of" target="HTTP3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9114#section-8.1" derivedContent="HTTP/3"/>), or a GOAWAY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred. HTTP/1.1
<xref target="HTTP11" format="default" sectionFormat="of" derivedContent="HTTP/1.1"/> provides no equivalent signal.  Connection failures or interruptions
are not sufficient signals that no processing occurred.</t>
        <t indent="0" pn="section-6.5-5">The anti-replay mechanisms described in <xref section="8" sectionFormat="of" target="TLS" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-8" derivedContent="TLS"/> are generally
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.  This
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>
        <t indent="0" pn="section-6.5-6">The mechanism used in TLS for managing differences in Client and server clocks
cannot be used as it depends on being able to observe previous interactions.
Oblivious HTTP explicitly prevents such linkability.</t>
        <t indent="0" pn="section-6.5-7">The considerations in <xref target="RFC8470" format="default" sectionFormat="of" derivedContent="RFC8470"/> as they relate to managing the risk of
replay also apply, though there is no option to delay the processing of a
request.</t>
        <t indent="0" pn="section-6.5-8">Limiting requests to those with safe methods might not be satisfactory for some
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
risk, though it is important to recognize that different idempotent requests
can be combined to be not idempotent.</t>
        <t indent="0" pn="section-6.5-9">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
replayed.</t>
        <section anchor="use-of-date-for-anti-replay" numbered="true" removeInRFC="false" toc="include" pn="section-6.5.1">
          <name slugifiedName="name-use-of-date-for-anti-replay">Use of Date for Anti-replay</name>
          <t indent="0" pn="section-6.5.1-1"><xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> <bcp14>SHOULD</bcp14> include a <tt>Date</tt> header field in <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Requests</xref>, unless
the Client has prior knowledge that indicates that the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway
Resource</xref> does not use <tt>Date</tt> for anti-replay purposes.</t>
          <t indent="0" pn="section-6.5.1-2">Though HTTP requests often do not include a <tt>Date</tt> header field, the value of
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>
          <t indent="0" pn="section-6.5.1-3">An Oblivious Gateway Resource can maintain state for requests for a small window
of time over which it wishes to accept requests.  The Oblivious Gateway Resource
can store all requests it processes within this window.  Storing just the <tt>enc</tt>
field of a request, which should be unique to each request, is sufficient.  The
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 field
from the decrypted request is outside of the current time window.</t>
          <t indent="0" pn="section-6.5.1-4">Oblivious Gateway Resources might need to allow for the time it takes requests
to arrive from the Client, with a time window that is large enough to allow for
differences in clocks.  Insufficient tolerance of time differences could result
in valid requests being unnecessarily rejected.  Beyond allowing for multiple
round-trip times -- to account for retransmission -- network delays are unlikely
to be significant in determining the size of the window, unless all potential
Clients are known to have excellent timekeeping.  A specific window size might
need to be determined experimentally.</t>
          <t indent="0" pn="section-6.5.1-5">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>Date</tt>
field to determine the time window over which the server will accept responses.</t>
        </section>
        <section anchor="date-fix" numbered="true" removeInRFC="false" toc="include" pn="section-6.5.2">
          <name slugifiedName="name-correcting-clock-difference">Correcting Clock Differences</name>
          <t indent="0" pn="section-6.5.2-1">An <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</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
type <xref target="PROBLEM" format="default" sectionFormat="of" derivedContent="PROBLEM"/> of
"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>
          <t indent="0" pn="section-6.5.2-2"><xref target="fig-date-reject" format="default" sectionFormat="of" derivedContent="Figure 8"/> shows an example response in HTTP/1.1 format.</t>
          <figure anchor="fig-date-reject" align="left" suppress-title="false" pn="figure-8">
            <name slugifiedName="name-example-rejection-of-reques">Example Rejection of Request Date Field</name>
            <sourcecode type="http-message" markers="false" pn="section-6.5.2-3.1">
HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json
Content-Length: 128

{"type":"https://iana.org/assignments/http-problem-types#date",
"title": "date field in request outside of acceptable range"}
</sourcecode>
          </figure>
          <t indent="0" pn="section-6.5.2-4">Disagreements about time are unlikely if both <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> and Oblivious Gateway
Resource have a good source of time; see <xref target="NTP" format="default" sectionFormat="of" derivedContent="NTP"/>. However, clock
differences are known to be commonplace; see Section 7.1 of
<xref target="CLOCKSKEW" format="default" sectionFormat="of" derivedContent="CLOCKSKEW"/>.</t>
          <t indent="0" pn="section-6.5.2-5">Including a <tt>Date</tt> header field in the response allows the Client to correct
clock errors by retrying the same request using the value of the <tt>Date</tt> field
provided by the Oblivious Gateway Resource.  The value of the <tt>Date</tt> field can
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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9111#section-4.2" derivedContent="HTTP-CACHING"/>.  When retrying a request, the
Client <bcp14>MUST</bcp14> create a fresh encryption of the modified request, using a new HPKE
context.</t>
          <figure anchor="fig-retry-date" align="left" suppress-title="false" pn="figure-9">
            <name slugifiedName="name-retrying-with-an-updated-da">Retrying with an Updated Date Field</name>
            <artset pn="section-6.5.2-6.1">
              <artwork type="svg" align="left" pn="section-6.5.2-6.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="304" width="464" viewBox="0 0 464 304" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                  <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 88,32 L 88,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,160 L 192,192" fill="none" stroke="black"/>
                  <path d="M 192,224 L 192,256" fill="none" stroke="black"/>
                  <path d="M 288,80 L 288,288" fill="none" stroke="black"/>
                  <path d="M 312,32 L 312,80" fill="none" stroke="black"/>
                  <path d="M 368,32 L 368,80" fill="none" stroke="black"/>
                  <path d="M 408,80 L 408,288" fill="none" stroke="black"/>
                  <path d="M 456,32 L 456,80" fill="none" stroke="black"/>
                  <path d="M 8,32 L 88,32" fill="none" stroke="black"/>
                  <path d="M 152,32 L 312,32" fill="none" stroke="black"/>
                  <path d="M 368,32 L 456,32" fill="none" stroke="black"/>
                  <path d="M 8,80 L 88,80" fill="none" stroke="black"/>
                  <path d="M 152,80 L 312,80" fill="none" stroke="black"/>
                  <path d="M 368,80 L 456,80" fill="none" stroke="black"/>
                  <path d="M 48,142 L 280,142" fill="none" stroke="black"/>
                  <path d="M 48,146 L 280,146" fill="none" stroke="black"/>
                  <path d="M 288,144 L 400,144" fill="none" stroke="black"/>
                  <path d="M 56,206 L 288,206" fill="none" stroke="black"/>
                  <path d="M 56,210 L 288,210" fill="none" stroke="black"/>
                  <path d="M 296,208 L 408,208" fill="none" stroke="black"/>
                  <path d="M 48,270 L 280,270" fill="none" stroke="black"/>
                  <path d="M 48,274 L 280,274" fill="none" stroke="black"/>
                  <path d="M 288,272 L 400,272" fill="none" stroke="black"/>
                  <polygon class="arrowhead" points="408,272 396,266.4 396,277.6" fill="black" transform="rotate(0,400,272)"/>
                  <polygon class="arrowhead" points="408,144 396,138.4 396,149.6" fill="black" transform="rotate(0,400,144)"/>
                  <polygon class="arrowhead" points="304,208 292,202.4 292,213.6" fill="black" transform="rotate(180,296,208)"/>
                  <polygon class="arrowhead" points="288,272 276,266.4 276,277.6" fill="black" transform="rotate(0,280,272)"/>
                  <polygon class="arrowhead" points="288,144 276,138.4 276,149.6" fill="black" transform="rotate(0,280,144)"/>
                  <polygon class="arrowhead" points="64,208 52,202.4 52,213.6" fill="black" transform="rotate(180,56,208)"/>
                  <g class="text">
                    <text x="44" y="52">Client</text>
                    <text x="184" y="52">Relay</text>
                    <text x="224" y="52">and</text>
                    <text x="272" y="52">Gateway</text>
                    <text x="404" y="52">Target</text>
                    <text x="232" y="68">Resources</text>
                    <text x="412" y="68">Resource</text>
                    <text x="96" y="132">Request</text>
                    <text x="312" y="180">400</text>
                    <text x="364" y="180">Response</text>
                    <text x="352" y="196">+</text>
                    <text x="380" y="196">Date</text>
                    <text x="96" y="244">Request</text>
                    <text x="72" y="260">+</text>
                    <text x="112" y="260">Updated</text>
                    <text x="164" y="260">Date</text>
                    <text x="192" y="292">|</text>
                  </g>
                </svg>
              </artwork>
              <artwork type="ascii-art" align="left" pn="section-6.5.2-6.1.2">
+---------+       +-------------------+      +----------+
| Client  |       | Relay and Gateway |      | Target   |
|         |       |     Resources     |      | Resource |
+----+----+       +----+-----------+--+      +----+-----+
     |                 |           |              |
     |                 |           |              |
     |  Request        |           |              |
     +============================&gt;+-------------&gt;|
     |                 |           |              |
     |                 |           | 400 Response |
     |                 |           |       + Date |
     |&lt;============================+&lt;-------------+
     |                 |           |              |
     |  Request        |           |              |
     |  + Updated Date |           |              |
     +============================&gt;+-------------&gt;|
     |                 |           |              |
</artwork>
            </artset>
          </figure>
          <t indent="0" pn="section-6.5.2-7">Retrying immediately allows the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> to measure the
round-trip time to the <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref>. The observed delay might reveal something about
the location of the Client.  Clients could delay retries to add some uncertainty
to any observed delay.</t>
          <t indent="0" pn="section-6.5.2-8">Intermediaries can sometimes rewrite the <tt>Date</tt> field when forwarding responses.
This might cause problems if the Oblivious Gateway Resource and intermediary
clocks differ by enough to cause the retry to be rejected.  Therefore, Clients
            <bcp14>MUST NOT</bcp14> retry a request with an adjusted date more than once.</t>
          <t indent="0" pn="section-6.5.2-9">Oblivious Gateway Resources that condition their responses on the <tt>Date</tt> header
field <bcp14>SHOULD</bcp14> either ensure that intermediaries do not cache responses (by
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 including the
token "date" in a <tt>Vary</tt> header field).</t>
          <t indent="0" pn="section-6.5.2-10">Clients <bcp14>MUST NOT</bcp14> use the date provided by the Oblivious Gateway Resource for any
other purpose, including future requests to any resource.  Any request that uses
information provided by the Oblivious Gateway Resource might be correlated using
that information.</t>
        </section>
      </section>
      <section anchor="forward-secrecy" numbered="true" removeInRFC="false" toc="include" pn="section-6.6">
        <name slugifiedName="name-forward-secrecy">Forward Secrecy</name>
        <t indent="0" pn="section-6.6-1">This document does not provide forward secrecy for either requests or
responses during the lifetime of the <xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key configuration</xref>. A measure of
forward secrecy can be provided by generating a new key configuration
then deleting the old keys after a suitable period.</t>
      </section>
      <section anchor="post-compromise-security" numbered="true" removeInRFC="false" toc="include" pn="section-6.7">
        <name slugifiedName="name-post-compromise-security">Post-Compromise Security</name>
        <t indent="0" pn="section-6.7-1">This design does not provide post-compromise security for responses.</t>
        <t indent="0" pn="section-6.7-2">A <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">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,
so there is negligible risk associated with a Client compromise.</t>
        <t indent="0" pn="section-6.7-3">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
the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> secret key could allow an attacker to recover the
plaintext of all requests sent toward affected keys and all of the responses
that were generated.</t>
        <t indent="0" pn="section-6.7-4">Even if server keys are compromised, an adversary cannot access messages
exchanged by the Client with the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> as messages are
protected by TLS.  Use of a compromised key also requires that the Oblivious
Relay Resource cooperate with the attacker or that the attacker is able to
compromise these TLS connections.</t>
        <t indent="0" pn="section-6.7-5">The total number of messages affected by server key compromise can be limited by
regular rotation of server keys.</t>
      </section>
      <section anchor="client-clock-exposure" numbered="true" removeInRFC="false" toc="include" pn="section-6.8">
        <name slugifiedName="name-client-clock-exposure">Client Clock Exposure</name>
        <t indent="0" pn="section-6.8-1">Including a <tt>Date</tt> field in requests reveals some information about the <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref>
clock.  This might be used to fingerprint Clients <xref target="UWT" format="default" sectionFormat="of" derivedContent="UWT"/> or to identify Clients
that are vulnerable to attacks that depend on incorrect clocks.</t>
        <t indent="0" pn="section-6.8-2">Clients can randomize the value that they provide for <tt>Date</tt> to obscure the true
value of their clock and reduce the chance of linking requests over time.
However, this increases the risk that their request is rejected as outside the
acceptable window.</t>
      </section>
      <section anchor="sec-media" numbered="true" removeInRFC="false" toc="include" pn="section-6.9">
        <name slugifiedName="name-media-type-security">Media Type Security</name>
        <t indent="0" pn="section-6.9-1">The <xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key configuration</xref> media type defined in <xref target="ohttp-keys" format="default" sectionFormat="of" derivedContent="Section 3.2"/> represents keying
material.  The content of this media type is not active (see <xref section="4.6" sectionFormat="of" target="RFC6838" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6838#section-4.6" derivedContent="RFC6838"/>), but it governs how a <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> might interact with an <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway
Resource</xref>.  The security implications of processing it are described in
<xref target="sec-client" format="default" sectionFormat="of" derivedContent="Section 6.1"/>; privacy implications are described in <xref target="privacy" format="default" sectionFormat="of" derivedContent="Section 7"/>.</t>
        <t indent="0" pn="section-6.9-2">The security implications of handling the message media types defined in
<xref target="req-res-media" format="default" sectionFormat="of" derivedContent="Section 4.5"/> is covered in other parts of this section in more detail.
However, these message media types are also encrypted encapsulations of HTTP
requests and responses.</t>
        <t indent="0" pn="section-6.9-3">HTTP messages contain content, which can use any media type.  In particular,
requests are processed by an Oblivious <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref>, which -- as an HTTP
resource -- defines how content is processed; see <xref section="3.1" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-3.1" derivedContent="HTTP"/>.  HTTP
clients can also use resource identity and response content to determine how
content is processed.  Consequently, the security considerations of <xref section="17" sectionFormat="of" target="HTTP" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-17" derivedContent="HTTP"/> also apply to the handling of the content of these media types.</t>
      </section>
      <section anchor="separate-target" numbered="true" removeInRFC="false" toc="include" pn="section-6.10">
        <name slugifiedName="name-separate-gateway-and-target">Separate Gateway and Target</name>
        <t indent="0" pn="section-6.10-1">This document generally assumes that the same entity operates the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious
Gateway Resource</xref> and the <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref>.  However, as the Oblivious Gateway
Resource performs generic HTTP processing, the use of forwarding cannot be
completely precluded.</t>
        <t indent="0" pn="section-6.10-2">The scheme specified in the <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref> determines the security
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" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</t>
        <t indent="0" pn="section-6.10-3">A Target Resource that is operated on a different server from the Oblivious
Gateway Resource is an ordinary HTTP resource.  A Target Resource can privilege
requests that are forwarded by a given Oblivious Gateway Resource if it trusts
the operator of the Oblivious Gateway Resource to only forward requests that
meet the expectations of the Target Resource.  Otherwise, the Target Resource
treats requests from an Oblivious Gateway Resource no differently than any
other HTTP client.</t>
        <t indent="0" pn="section-6.10-4">For instance, an Oblivious Gateway Resource might -- possibly with the help of
<xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resources</xref> -- be trusted not to forward an excessive volume of
requests. This might allow the Target Resource to accept a greater volume of
requests from that Oblivious Gateway Resource relative to other HTTP clients.</t>
        <t indent="0" pn="section-6.10-5">An Oblivious Gateway Resource could implement policies that improve the ability
of the Target Resource to implement policy exemptions, such as only forwarding
requests toward specific Target Resources according to an allowlist; see <xref target="server-responsibilities" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</t>
      </section>
    </section>
    <section anchor="privacy" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-7-1">One goal of this design is that independent <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> requests are only linkable by
their content.  However, the choice of Client configuration might be used to
correlate requests.  A Client configuration includes the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay
Resource</xref> URI, the Oblivious Gateway <xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key configuration</xref>, and the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway
Resource</xref> URI. A configuration is active if Clients can successfully use it for
interacting with a target.</t>
      <t indent="0" pn="section-7-2">Oblivious Relay and Gateway Resources can identify when requests use the same
configuration by matching the key identifier from the key configuration or the
Oblivious Gateway Resource URI.  The Oblivious Gateway Resource might use the
source address of requests to correlate requests that use an Oblivious Relay
Resource run by the same operator.  If the Oblivious Gateway Resource is willing
to use trial decryption, requests can be further separated into smaller
groupings based on active configurations that clients use.</t>
      <t indent="0" pn="section-7-3">Each active Client configuration partitions the Client anonymity set. In
practice, it is infeasible to reduce the number of active configurations to
one. Enabling diversity in choice of Oblivious Relay Resource naturally
increases the number of active configurations.  More than one configuration
might need to be active to allow for key rotation and server maintenance.</t>
      <t indent="0" pn="section-7-4">Client privacy depends on having each configuration used by many other Clients.
It is critical to prevent the use of unique Client configurations, which might
be used to track individual Clients, but it is also important to avoid
creating small groupings of Clients that might weaken privacy protections.</t>
      <t indent="0" pn="section-7-5">A specific method for a Client to acquire configurations is not included in this
specification.  Applications using this design <bcp14>MUST</bcp14> provide accommodations to
mitigate tracking using Client configurations.  <xref target="CONSISTENCY" format="default" sectionFormat="of" derivedContent="CONSISTENCY"/> provides options
for ensuring that Client configurations are consistent between Clients.</t>
      <t indent="0" pn="section-7-6">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,
like cookies <xref target="COOKIES" format="default" sectionFormat="of" derivedContent="COOKIES"/>, but it also includes any information in either
message that might affect how subsequent requests are formulated. For example,
<xref target="FIELDING" format="default" sectionFormat="of" derivedContent="FIELDING"/> describes how interactions that are individually stateless can be
used to build a stateful system when a Client acts on the content of a response.</t>
    </section>
    <section anchor="deployment" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-operational-and-deployment-">Operational and Deployment Considerations</name>
      <t indent="0" pn="section-8-1">This section discusses various operational and deployment considerations.</t>
      <section anchor="performance-overhead" numbered="true" removeInRFC="false" toc="include" pn="section-8.1">
        <name slugifiedName="name-performance-overhead">Performance Overhead</name>
        <t indent="0" pn="section-8.1-1">Using Oblivious HTTP adds both cryptographic overhead and latency to requests
relative to a simple HTTP request-response exchange.  Deploying relay services
that are on path between <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> and servers avoids adding significant
additional delay due to network topology.  A study of a similar system
<xref target="ODOH-PETS" format="default" sectionFormat="of" derivedContent="ODOH-PETS"/> found that deploying proxies close to servers was most effective
in minimizing additional latency.</t>
      </section>
      <section anchor="proxy-state" numbered="true" removeInRFC="false" toc="include" pn="section-8.2">
        <name slugifiedName="name-resource-mappings">Resource Mappings</name>
        <t indent="0" pn="section-8.2-1">This protocol assumes a fixed, one-to-one mapping between the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay
Resource</xref> and the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref>. This means that any <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated
Request</xref> sent to the Oblivious Relay Resource will always be forwarded to the
Oblivious Gateway Resource. This constraint was imposed to simplify relay
configuration and mitigate against the Oblivious Relay Resource being used as
a generic relay for unknown Oblivious Gateway Resources. The relay will only
forward for Oblivious Gateway Resources that it has explicitly configured and
allowed.</t>
        <t indent="0" pn="section-8.2-2">It is possible for a server to be configured with multiple Oblivious Relay
Resources, each for a different Oblivious Gateway Resource as needed.  If the
goal is to support a large number of Oblivious Gateway Resources, <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> might
be provided with a URI template <xref target="TEMPLATE" format="default" sectionFormat="of" derivedContent="TEMPLATE"/>, from which multiple
Oblivious Relay Resources could be constructed.</t>
      </section>
      <section anchor="network-management" numbered="true" removeInRFC="false" toc="include" pn="section-8.3">
        <name slugifiedName="name-network-management">Network Management</name>
        <t indent="0" pn="section-8.3-1">Oblivious HTTP might be incompatible with network interception regimes, such as
those that rely on configuring <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Clients</xref> with trust anchors and intercepting TLS
connections.  While TLS might be intercepted successfully, interception
middlebox devices might not receive updates that would allow Oblivious HTTP to
be correctly identified using the media types defined in Sections <xref format="counter" target="iana-req" sectionFormat="of" derivedContent="9.2"/>
and <xref format="counter" target="iana-res" sectionFormat="of" derivedContent="9.3"/>.</t>
        <t indent="0" pn="section-8.3-2">Oblivious HTTP has a simple key management design that is not trivially altered
to enable interception by intermediaries.  Clients that are configured to enable
interception might choose to disable Oblivious HTTP in order to ensure that
content is accessible to middleboxes.</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">IANA has registered the following media types in the "Media Types" registry at
<eref target="https://iana.org/assignments/media-types" brackets="angle"/>, following the procedures of
<xref target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC6838"/>: "<tt>application/ohttp-keys</tt>" (<xref target="iana-keys" format="default" sectionFormat="of" derivedContent="Section 9.1"/>), "<tt>message/ohttp-req</tt>"
(<xref target="iana-req" format="default" sectionFormat="of" derivedContent="Section 9.2"/>), and "<tt>message/ohttp-res</tt>" (<xref target="iana-res" format="default" sectionFormat="of" derivedContent="Section 9.3"/>).</t>
      <t indent="0" pn="section-9-2">IANA has added the following types to the "HTTP Problem Types" registry at
<eref target="https://iana.org/assignments/http-problem-types" brackets="angle"/>: "date"
(<xref target="iana-problem-date" format="default" sectionFormat="of" derivedContent="Section 9.4"/>) and "ohttp-key" (<xref target="iana-problem-ohttp-key" format="default" sectionFormat="of" derivedContent="Section 9.5"/>).</t>
      <section anchor="iana-keys" numbered="true" removeInRFC="false" toc="include" pn="section-9.1">
        <name slugifiedName="name-application-ohttp-keys-medi">application/ohttp-keys Media Type</name>
        <t indent="0" pn="section-9.1-1">The "<tt>application/ohttp-keys</tt>" media type identifies a <xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key configuration</xref> used by
Oblivious HTTP.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-9.1-2">
          <dt pn="section-9.1-2.1">Type name:</dt>
          <dd pn="section-9.1-2.2">
            <t indent="0" pn="section-9.1-2.2.1">application</t>
          </dd>
          <dt pn="section-9.1-2.3">Subtype name:</dt>
          <dd pn="section-9.1-2.4">
            <t indent="0" pn="section-9.1-2.4.1">ohttp-keys</t>
          </dd>
          <dt pn="section-9.1-2.5">Required parameters:</dt>
          <dd pn="section-9.1-2.6">
            <t indent="0" pn="section-9.1-2.6.1">N/A</t>
          </dd>
          <dt pn="section-9.1-2.7">Optional parameters:</dt>
          <dd pn="section-9.1-2.8">
            <t indent="0" pn="section-9.1-2.8.1">N/A</t>
          </dd>
          <dt pn="section-9.1-2.9">Encoding considerations:</dt>
          <dd pn="section-9.1-2.10">
            <t indent="0" pn="section-9.1-2.10.1">"binary"</t>
          </dd>
          <dt pn="section-9.1-2.11">Security considerations:</dt>
          <dd pn="section-9.1-2.12">
            <t indent="0" pn="section-9.1-2.12.1">See <xref target="sec-media" format="default" sectionFormat="of" derivedContent="Section 6.9"/></t>
          </dd>
          <dt pn="section-9.1-2.13">Interoperability considerations:</dt>
          <dd pn="section-9.1-2.14">
            <t indent="0" pn="section-9.1-2.14.1">N/A</t>
          </dd>
          <dt pn="section-9.1-2.15">Published specification:</dt>
          <dd pn="section-9.1-2.16">
            <t indent="0" pn="section-9.1-2.16.1">RFC 9458</t>
          </dd>
          <dt pn="section-9.1-2.17">Applications that use this media type:</dt>
          <dd pn="section-9.1-2.18">
            <t indent="0" pn="section-9.1-2.18.1">This type identifies a key configuration as used by Oblivious HTTP and
applications that use Oblivious HTTP.</t>
          </dd>
          <dt pn="section-9.1-2.19">Fragment identifier considerations:</dt>
          <dd pn="section-9.1-2.20">
            <t indent="0" pn="section-9.1-2.20.1">N/A</t>
          </dd>
          <dt pn="section-9.1-2.21">Additional information:</dt>
          <dd pn="section-9.1-2.22">
            <t indent="0" pn="section-9.1-2.22.1"><br/></t>
            <dl spacing="compact" indent="3" newline="false" pn="section-9.1-2.22.2">
              <dt pn="section-9.1-2.22.2.1">Magic number(s):</dt>
              <dd pn="section-9.1-2.22.2.2">N/A</dd>
              <dt pn="section-9.1-2.22.2.3">Deprecated alias names for this type:</dt>
              <dd pn="section-9.1-2.22.2.4">N/A</dd>
              <dt pn="section-9.1-2.22.2.5">File extension(s):</dt>
              <dd pn="section-9.1-2.22.2.6">N/A</dd>
              <dt pn="section-9.1-2.22.2.7">Macintosh file type code(s):</dt>
              <dd pn="section-9.1-2.22.2.8">
                <t indent="0" pn="section-9.1-2.22.2.8.1">N/A</t>
              </dd>
            </dl>
          </dd>
          <dt pn="section-9.1-2.23">Person and email address to contact for further information:</dt>
          <dd pn="section-9.1-2.24">
            <t indent="0" pn="section-9.1-2.24.1"><br/>See Authors' Addresses section</t>
          </dd>
          <dt pn="section-9.1-2.25">Intended usage:</dt>
          <dd pn="section-9.1-2.26">
            <t indent="0" pn="section-9.1-2.26.1">COMMON</t>
          </dd>
          <dt pn="section-9.1-2.27">Restrictions on usage:</dt>
          <dd pn="section-9.1-2.28">
            <t indent="0" pn="section-9.1-2.28.1">N/A</t>
          </dd>
          <dt pn="section-9.1-2.29">Author:</dt>
          <dd pn="section-9.1-2.30">
            <t indent="0" pn="section-9.1-2.30.1">See Authors' Addresses section</t>
          </dd>
          <dt pn="section-9.1-2.31">Change controller:</dt>
          <dd pn="section-9.1-2.32">
            <t indent="0" pn="section-9.1-2.32.1">IETF</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-req" numbered="true" removeInRFC="false" toc="include" pn="section-9.2">
        <name slugifiedName="name-message-ohttp-req-media-typ">message/ohttp-req Media Type</name>
        <t indent="0" pn="section-9.2-1">The "<tt>message/ohttp-req</tt>" identifies an encrypted binary HTTP request.  This
is a binary format that is defined in <xref target="request" format="default" sectionFormat="of" derivedContent="Section 4.3"/>.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-9.2-2">
          <dt pn="section-9.2-2.1">Type name:</dt>
          <dd pn="section-9.2-2.2">
            <t indent="0" pn="section-9.2-2.2.1">message</t>
          </dd>
          <dt pn="section-9.2-2.3">Subtype name:</dt>
          <dd pn="section-9.2-2.4">
            <t indent="0" pn="section-9.2-2.4.1">ohttp-req</t>
          </dd>
          <dt pn="section-9.2-2.5">Required parameters:</dt>
          <dd pn="section-9.2-2.6">
            <t indent="0" pn="section-9.2-2.6.1">N/A</t>
          </dd>
          <dt pn="section-9.2-2.7">Optional parameters:</dt>
          <dd pn="section-9.2-2.8">
            <t indent="0" pn="section-9.2-2.8.1">N/A</t>
          </dd>
          <dt pn="section-9.2-2.9">Encoding considerations:</dt>
          <dd pn="section-9.2-2.10">
            <t indent="0" pn="section-9.2-2.10.1">"binary"</t>
          </dd>
          <dt pn="section-9.2-2.11">Security considerations:</dt>
          <dd pn="section-9.2-2.12">
            <t indent="0" pn="section-9.2-2.12.1">See <xref target="sec-media" format="default" sectionFormat="of" derivedContent="Section 6.9"/></t>
          </dd>
          <dt pn="section-9.2-2.13">Interoperability considerations:</dt>
          <dd pn="section-9.2-2.14">
            <t indent="0" pn="section-9.2-2.14.1">N/A</t>
          </dd>
          <dt pn="section-9.2-2.15">Published specification:</dt>
          <dd pn="section-9.2-2.16">
            <t indent="0" pn="section-9.2-2.16.1">RFC 9458</t>
          </dd>
          <dt pn="section-9.2-2.17">Applications that use this media type:</dt>
          <dd pn="section-9.2-2.18">
            <t indent="0" pn="section-9.2-2.18.1">Oblivious HTTP and applications that use Oblivious HTTP use this media type to
identify encapsulated binary HTTP requests.</t>
          </dd>
          <dt pn="section-9.2-2.19">Fragment identifier considerations:</dt>
          <dd pn="section-9.2-2.20">
            <t indent="0" pn="section-9.2-2.20.1">N/A</t>
          </dd>
          <dt pn="section-9.2-2.21">Additional information:</dt>
          <dd pn="section-9.2-2.22">
            <t indent="0" pn="section-9.2-2.22.1"><br/></t>
            <dl spacing="compact" indent="3" newline="false" pn="section-9.2-2.22.2">
              <dt pn="section-9.2-2.22.2.1">Magic number(s):</dt>
              <dd pn="section-9.2-2.22.2.2">N/A</dd>
              <dt pn="section-9.2-2.22.2.3">Deprecated alias names for this type:</dt>
              <dd pn="section-9.2-2.22.2.4">N/A</dd>
              <dt pn="section-9.2-2.22.2.5">File extension(s):</dt>
              <dd pn="section-9.2-2.22.2.6">N/A</dd>
              <dt pn="section-9.2-2.22.2.7">Macintosh file type code(s):</dt>
              <dd pn="section-9.2-2.22.2.8">
                <t indent="0" pn="section-9.2-2.22.2.8.1">N/A</t>
              </dd>
            </dl>
          </dd>
          <dt pn="section-9.2-2.23">Person and email address to contact for further information:</dt>
          <dd pn="section-9.2-2.24">
            <t indent="0" pn="section-9.2-2.24.1"><br/>See Authors' Addresses section</t>
          </dd>
          <dt pn="section-9.2-2.25">Intended usage:</dt>
          <dd pn="section-9.2-2.26">
            <t indent="0" pn="section-9.2-2.26.1">COMMON</t>
          </dd>
          <dt pn="section-9.2-2.27">Restrictions on usage:</dt>
          <dd pn="section-9.2-2.28">
            <t indent="0" pn="section-9.2-2.28.1">N/A</t>
          </dd>
          <dt pn="section-9.2-2.29">Author:</dt>
          <dd pn="section-9.2-2.30">
            <t indent="0" pn="section-9.2-2.30.1">See Authors' Addresses section</t>
          </dd>
          <dt pn="section-9.2-2.31">Change controller:</dt>
          <dd pn="section-9.2-2.32">
            <t indent="0" pn="section-9.2-2.32.1">IETF</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-res" numbered="true" removeInRFC="false" toc="include" pn="section-9.3">
        <name slugifiedName="name-message-ohttp-res-media-typ">message/ohttp-res Media Type</name>
        <t indent="0" pn="section-9.3-1">The "<tt>message/ohttp-res</tt>" identifies an encrypted binary HTTP response. This
is a binary format that is defined in <xref target="response" format="default" sectionFormat="of" derivedContent="Section 4.4"/>.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-9.3-2">
          <dt pn="section-9.3-2.1">Type name:</dt>
          <dd pn="section-9.3-2.2">
            <t indent="0" pn="section-9.3-2.2.1">message</t>
          </dd>
          <dt pn="section-9.3-2.3">Subtype name:</dt>
          <dd pn="section-9.3-2.4">
            <t indent="0" pn="section-9.3-2.4.1">ohttp-res</t>
          </dd>
          <dt pn="section-9.3-2.5">Required parameters:</dt>
          <dd pn="section-9.3-2.6">
            <t indent="0" pn="section-9.3-2.6.1">N/A</t>
          </dd>
          <dt pn="section-9.3-2.7">Optional parameters:</dt>
          <dd pn="section-9.3-2.8">
            <t indent="0" pn="section-9.3-2.8.1">N/A</t>
          </dd>
          <dt pn="section-9.3-2.9">Encoding considerations:</dt>
          <dd pn="section-9.3-2.10">
            <t indent="0" pn="section-9.3-2.10.1">"binary"</t>
          </dd>
          <dt pn="section-9.3-2.11">Security considerations:</dt>
          <dd pn="section-9.3-2.12">
            <t indent="0" pn="section-9.3-2.12.1">See <xref target="sec-media" format="default" sectionFormat="of" derivedContent="Section 6.9"/></t>
          </dd>
          <dt pn="section-9.3-2.13">Interoperability considerations:</dt>
          <dd pn="section-9.3-2.14">
            <t indent="0" pn="section-9.3-2.14.1">N/A</t>
          </dd>
          <dt pn="section-9.3-2.15">Published specification:</dt>
          <dd pn="section-9.3-2.16">
            <t indent="0" pn="section-9.3-2.16.1">RFC 9458</t>
          </dd>
          <dt pn="section-9.3-2.17">Applications that use this media type:</dt>
          <dd pn="section-9.3-2.18">
            <t indent="0" pn="section-9.3-2.18.1">Oblivious HTTP and applications that use Oblivious HTTP use this media type to
identify encapsulated binary HTTP responses.</t>
          </dd>
          <dt pn="section-9.3-2.19">Fragment identifier considerations:</dt>
          <dd pn="section-9.3-2.20">
            <t indent="0" pn="section-9.3-2.20.1">N/A</t>
          </dd>
          <dt pn="section-9.3-2.21">Additional information:</dt>
          <dd pn="section-9.3-2.22">
            <t indent="0" pn="section-9.3-2.22.1"><br/></t>
            <dl spacing="compact" indent="3" newline="false" pn="section-9.3-2.22.2">
              <dt pn="section-9.3-2.22.2.1">Magic number(s):</dt>
              <dd pn="section-9.3-2.22.2.2">N/A</dd>
              <dt pn="section-9.3-2.22.2.3">Deprecated alias names for this type:</dt>
              <dd pn="section-9.3-2.22.2.4">N/A</dd>
              <dt pn="section-9.3-2.22.2.5">File extension(s):</dt>
              <dd pn="section-9.3-2.22.2.6">N/A</dd>
              <dt pn="section-9.3-2.22.2.7">Macintosh file type code(s):</dt>
              <dd pn="section-9.3-2.22.2.8">
                <t indent="0" pn="section-9.3-2.22.2.8.1">N/A</t>
              </dd>
            </dl>
          </dd>
          <dt pn="section-9.3-2.23">Person and email address to contact for further information:</dt>
          <dd pn="section-9.3-2.24">
            <t indent="0" pn="section-9.3-2.24.1"><br/>See Authors' Addresses section</t>
          </dd>
          <dt pn="section-9.3-2.25">Intended usage:</dt>
          <dd pn="section-9.3-2.26">
            <t indent="0" pn="section-9.3-2.26.1">COMMON</t>
          </dd>
          <dt pn="section-9.3-2.27">Restrictions on usage:</dt>
          <dd pn="section-9.3-2.28">
            <t indent="0" pn="section-9.3-2.28.1">N/A</t>
          </dd>
          <dt pn="section-9.3-2.29">Author:</dt>
          <dd pn="section-9.3-2.30">
            <t indent="0" pn="section-9.3-2.30.1">See Authors' Addresses section</t>
          </dd>
          <dt pn="section-9.3-2.31">Change controller:</dt>
          <dd pn="section-9.3-2.32">
            <t indent="0" pn="section-9.3-2.32.1">IETF</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-problem-date" numbered="true" removeInRFC="false" toc="include" pn="section-9.4">
        <name slugifiedName="name-registration-of-date-proble">Registration of "date" Problem Type</name>
        <t indent="0" pn="section-9.4-1">IANA has added a new entry in the "HTTP Problem Types" registry established by
<xref target="PROBLEM" format="default" sectionFormat="of" derivedContent="PROBLEM"/>.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-9.4-2">
          <dt pn="section-9.4-2.1">Type URI:</dt>
          <dd pn="section-9.4-2.2">
            <t indent="0" pn="section-9.4-2.2.1">https://iana.org/assignments/http-problem-types#date</t>
          </dd>
          <dt pn="section-9.4-2.3">Title:</dt>
          <dd pn="section-9.4-2.4">
            <t indent="0" pn="section-9.4-2.4.1">Date Not Acceptable</t>
          </dd>
          <dt pn="section-9.4-2.5">Recommended HTTP Status Code:</dt>
          <dd pn="section-9.4-2.6">
            <t indent="0" pn="section-9.4-2.6.1">400</t>
          </dd>
          <dt pn="section-9.4-2.7">Reference:</dt>
          <dd pn="section-9.4-2.8">
            <t indent="0" pn="section-9.4-2.8.1"><xref target="date-fix" format="default" sectionFormat="of" derivedContent="Section 6.5.2"/> of RFC 9458</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-problem-ohttp-key" numbered="true" removeInRFC="false" toc="include" pn="section-9.5">
        <name slugifiedName="name-registration-of-ohttp-key-p">Registration of "ohttp-key" Problem Type</name>
        <t indent="0" pn="section-9.5-1">IANA has added a new entry in the "HTTP Problem Types" registry established by
<xref target="PROBLEM" format="default" sectionFormat="of" derivedContent="PROBLEM"/>.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-9.5-2">
          <dt pn="section-9.5-2.1">Type URI:</dt>
          <dd pn="section-9.5-2.2">
            <t indent="0" pn="section-9.5-2.2.1">https://iana.org/assignments/http-problem-types#ohttp-key</t>
          </dd>
          <dt pn="section-9.5-2.3">Title:</dt>
          <dd pn="section-9.5-2.4">
            <t indent="0" pn="section-9.5-2.4.1">Oblivious HTTP key configuration not acceptable</t>
          </dd>
          <dt pn="section-9.5-2.5">Recommended HTTP Status Code:</dt>
          <dd pn="section-9.5-2.6">
            <t indent="0" pn="section-9.5-2.6.1">400</t>
          </dd>
          <dt pn="section-9.5-2.7">Reference:</dt>
          <dd pn="section-9.5-2.8">
            <t indent="0" pn="section-9.5-2.8.1"><xref target="ohttp-key-problem" format="default" sectionFormat="of" derivedContent="Section 5.3"/> of RFC 9458</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="HTTP11" to="HTTP/1.1"/>
    <displayreference target="HTTP2" to="HTTP/2"/>
    <displayreference target="HTTP3" to="HTTP/3"/>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="ASCII" target="https://www.rfc-editor.org/info/rfc20" quoteTitle="true" derivedAnchor="ASCII">
          <front>
            <title>ASCII format for network interchange</title>
            <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
            <date month="October" year="1969"/>
          </front>
          <seriesInfo name="STD" value="80"/>
          <seriesInfo name="RFC" value="20"/>
          <seriesInfo name="DOI" value="10.17487/RFC0020"/>
        </reference>
        <reference anchor="BINARY" target="https://www.rfc-editor.org/info/rfc9292" quoteTitle="true" derivedAnchor="BINARY">
          <front>
            <title>Binary Representation of HTTP Messages</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson"/>
            <author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document defines a binary format for representing HTTP messages.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9292"/>
          <seriesInfo name="DOI" value="10.17487/RFC9292"/>
        </reference>
        <reference anchor="HPKE" target="https://www.rfc-editor.org/info/rfc9180" quoteTitle="true" derivedAnchor="HPKE">
          <front>
            <title>Hybrid Public Key Encryption</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes"/>
            <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
            <author fullname="B. Lipp" initials="B." surname="Lipp"/>
            <author fullname="C. Wood" initials="C." surname="Wood"/>
            <date month="February" year="2022"/>
            <abstract>
              <t indent="0">This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one 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 derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.</t>
              <t indent="0">This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9180"/>
          <seriesInfo name="DOI" value="10.17487/RFC9180"/>
        </reference>
        <reference anchor="HTTP" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="HTTP">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, 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 indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="HTTP-CACHING" target="https://www.rfc-editor.org/info/rfc9111" quoteTitle="true" derivedAnchor="HTTP-CACHING">
          <front>
            <title>HTTP Caching</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-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 indent="0">This document obsoletes RFC 7234.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="98"/>
          <seriesInfo name="RFC" value="9111"/>
          <seriesInfo name="DOI" value="10.17487/RFC9111"/>
        </reference>
        <reference anchor="PROBLEM" target="https://www.rfc-editor.org/info/rfc9457" quoteTitle="true" derivedAnchor="PROBLEM">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author fullname="Mark Nottingham" initials="M." surname="Nottingham">
         </author>
            <author fullname="Erik Wilde" initials="E." surname="Wilde">
         </author>
            <author fullname="Sanjay Dalal" initials="S." surname="Dalal">
         </author>
            <date month="July" year="2023"/>
            <abstract>
              <t indent="0">This document defines a "problem detail" to carry machine-readable details of erors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.
              </t>
              <t indent="0">This document obsoletes RFC 7807.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9457"/>
          <seriesInfo name="DOI" value="10.17487/RFC9457"/>
        </reference>
        <reference anchor="QUIC" target="https://www.rfc-editor.org/info/rfc9000" quoteTitle="true" derivedAnchor="QUIC">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838" quoteTitle="true" derivedAnchor="RFC6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="January" year="2013"/>
            <abstract>
              <t indent="0">This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="13"/>
          <seriesInfo name="RFC" value="6838"/>
          <seriesInfo name="DOI" value="10.17487/RFC6838"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8470" target="https://www.rfc-editor.org/info/rfc8470" quoteTitle="true" derivedAnchor="RFC8470">
          <front>
            <title>Using Early Data in HTTP</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson"/>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="W. Tarreau" initials="W." surname="Tarreau"/>
            <date month="September" year="2018"/>
            <abstract>
              <t indent="0">Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate 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>
          </front>
          <seriesInfo name="RFC" value="8470"/>
          <seriesInfo name="DOI" value="10.17487/RFC8470"/>
        </reference>
        <reference anchor="TLS" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="TLS">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="CLOCKSKEW" quoteTitle="true" target="https://doi.org/10.1145/3133956.3134007" derivedAnchor="CLOCKSKEW">
          <front>
            <title>Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors</title>
            <author fullname="Mustafa Emre Acer" initials="M." surname="Acer">
              <organization showOnFrontPage="true">Google Inc., Mountain View, CA, USA</organization>
            </author>
            <author fullname="Emily Stark" initials="E." surname="Stark">
              <organization showOnFrontPage="true">Google Inc., Mountain View, CA, USA</organization>
            </author>
            <author fullname="Adrienne Porter Felt" initials="A." surname="Felt">
              <organization showOnFrontPage="true">Google Inc., Mountain View, CA, USA</organization>
            </author>
            <author fullname="Sascha Fahl" initials="S." surname="Fahl">
              <organization showOnFrontPage="true">Leibniz University Hannover, Hannover, Germany</organization>
            </author>
            <author fullname="Radhika Bhargava" initials="R." surname="Bhargava">
              <organization showOnFrontPage="true">Purdue University, West Lafayette, IN, USA</organization>
            </author>
            <author fullname="Bhanu Dev" initials="B." surname="Dev">
              <organization showOnFrontPage="true">International Institute of Information Technology, Hyderabad, Hyderabad, India</organization>
            </author>
            <author fullname="Matt Braithwaite" initials="M." surname="Braithwaite">
              <organization showOnFrontPage="true">Google Inc., Mountain View, CA, USA</organization>
            </author>
            <author fullname="Ryan Sleevi" initials="R." surname="Sleevi">
              <organization showOnFrontPage="true">Google Inc., Mountain View, CA, USA</organization>
            </author>
            <author fullname="Parisa Tabriz" initials="P." surname="Tabriz">
              <organization showOnFrontPage="true">Google Inc., Mountain View, CA, USA</organization>
            </author>
            <date month="October" year="2017"/>
          </front>
          <seriesInfo name="DOI" value="10.1145/3133956.3134007"/>
          <refcontent>Proceedings of the 2017 ACM SIGSAC Conference on
          Computer and Communications Security</refcontent>
        </reference>
        <reference anchor="CONSISTENCY" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-key-consistency-01" derivedAnchor="CONSISTENCY">
          <front>
            <title>Key Consistency and Discovery</title>
            <author fullname="Alex Davidson" initials="A." surname="Davidson">
              <organization showOnFrontPage="true">Brave Software</organization>
            </author>
            <author fullname="Matthew Finkel" initials="M." surname="Finkel">
              <organization showOnFrontPage="true">The Tor Project</organization>
            </author>
            <author fullname="Martin Thomson" initials="M." surname="Thomson">
              <organization showOnFrontPage="true">Mozilla</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization showOnFrontPage="true">Cloudflare</organization>
            </author>
            <date day="10" month="July" year="2023"/>
            <abstract>
              <t indent="0">   This document describes the consistency requirements of protocols
   such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user
   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.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-key-consistency-01"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="COOKIES" target="https://www.rfc-editor.org/info/rfc6265" quoteTitle="true" derivedAnchor="COOKIES">
          <front>
            <title>HTTP State Management Mechanism</title>
            <author fullname="A. Barth" initials="A." surname="Barth"/>
            <date month="April" year="2011"/>
            <abstract>
              <t indent="0">This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6265"/>
          <seriesInfo name="DOI" value="10.17487/RFC6265"/>
        </reference>
        <reference anchor="DMS2004" target="https://svn.torproject.org/svn/projects/design-paper/tor-design.html" quoteTitle="true" derivedAnchor="DMS2004">
          <front>
            <title>Tor: The Second-Generation Onion Router</title>
            <author initials="R." surname="Dingledine">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Mathewson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Syverson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="May"/>
          </front>
        </reference>
        <reference anchor="FIELDING" target="https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf" quoteTitle="true" derivedAnchor="FIELDING">
          <front>
            <title>Architectural Styles and the Design of Network-based Software Architectures</title>
            <author fullname="Roy Thomas Fielding">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2000" month="January"/>
          </front>
        </reference>
        <reference anchor="FORWARDED" target="https://www.rfc-editor.org/info/rfc7239" quoteTitle="true" derivedAnchor="FORWARDED">
          <front>
            <title>Forwarded HTTP Extension</title>
            <author fullname="A. Petersson" initials="A." surname="Petersson"/>
            <author fullname="M. Nilsson" initials="M." surname="Nilsson"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.</t>
              <t indent="0">This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7239"/>
          <seriesInfo name="DOI" value="10.17487/RFC7239"/>
        </reference>
        <reference anchor="HTTP11" target="https://www.rfc-editor.org/info/rfc9112" quoteTitle="true" derivedAnchor="HTTP/1.1">
          <front>
            <title>HTTP/1.1</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.</t>
              <t indent="0">This document obsoletes portions of RFC 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference>
        <reference anchor="HTTP2" target="https://www.rfc-editor.org/info/rfc9113" quoteTitle="true" derivedAnchor="HTTP/2">
          <front>
            <title>HTTP/2</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">This specification describes an optimized expression of the semantics 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 exchanges on the same connection.</t>
              <t indent="0">This document obsoletes RFCs 7540 and 8740.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9113"/>
          <seriesInfo name="DOI" value="10.17487/RFC9113"/>
        </reference>
        <reference anchor="HTTP3" target="https://www.rfc-editor.org/info/rfc9114" quoteTitle="true" derivedAnchor="HTTP/3">
          <front>
            <title>HTTP/3</title>
            <author fullname="M. Bishop" initials="M." role="editor" surname="Bishop"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9114"/>
          <seriesInfo name="DOI" value="10.17487/RFC9114"/>
        </reference>
        <reference anchor="NTP" target="https://www.rfc-editor.org/info/rfc5905" quoteTitle="true" derivedAnchor="NTP">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <author fullname="D. Mills" initials="D." surname="Mills"/>
            <author fullname="J. Martin" initials="J." role="editor" surname="Martin"/>
            <author fullname="J. Burbank" initials="J." surname="Burbank"/>
            <author fullname="W. Kasch" initials="W." surname="Kasch"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Network Time Protocol (NTP) is widely used to synchronize computer 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 protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5905"/>
          <seriesInfo name="DOI" value="10.17487/RFC5905"/>
        </reference>
        <reference anchor="ODOH" target="https://www.rfc-editor.org/info/rfc9230" quoteTitle="true" derivedAnchor="ODOH">
          <front>
            <title>Oblivious DNS over HTTPS</title>
            <author fullname="E. Kinnear" initials="E." surname="Kinnear"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <author fullname="T. Pauly" initials="T." surname="Pauly"/>
            <author fullname="T. Verma" initials="T." surname="Verma"/>
            <author fullname="C.A. Wood" initials="C.A." surname="Wood"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.</t>
              <t indent="0">This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9230"/>
          <seriesInfo name="DOI" value="10.17487/RFC9230"/>
        </reference>
        <reference anchor="ODOH-PETS" target="https://www.petsymposium.org/2021/files/papers/issue4/popets-2021-0085.pdf" quoteTitle="true" derivedAnchor="ODOH-PETS">
          <front>
            <title>Oblivious DNS over HTTPS (ODoH): A Practical Privacy Enhancement to DNS</title>
            <author fullname="Sudheesh Singanamalla" initials="S." surname="Singanamalla"/>
            <author fullname="Suphanat Chunhapanya" initials="S." surname="Chunhapanya"/>
            <author fullname="Jonathan Hoylan" initials="J." surname="Hoyland"/>
            <author fullname="Marek Vavruša" initials="M." surname="Vavruša"/>
            <author fullname="Tanya Verma" initials="T." surname="Verma"/>
            <author fullname="Peter Wu" initials="P." surname="Wu"/>
            <author fullname="Marwan Fayed" initials="M." surname="Fayed"/>
            <author fullname="Kurtis Heimerl" initials="K." surname="Heimerl"/>
            <author fullname="Nick Sullivan" initials="N." surname="Sullivan"/>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood"/>
            <date year="2021" month="January"/>
          </front>
          <seriesInfo name="DOI" value="10.2478/popets-2021-0085"/>
          <refcontent>PoPETS Proceedings Volume 2021, Issue 4, pp. 575-592</refcontent>
        </reference>
        <reference anchor="OHTTP-ANALYSIS" target="https://github.com/cloudflare/ohttp-analysis" quoteTitle="true" derivedAnchor="OHTTP-ANALYSIS">
          <front>
            <title>Tamarin Model of Oblivious HTTP</title>
            <author fullname="Jonathan Hoyland" initials="J." surname="Hoyland">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2022" month="October"/>
          </front>
          <refcontent>commit 6824eee</refcontent>
        </reference>
        <reference anchor="PRIO" target="https://crypto.stanford.edu/prio/paper.pdf" quoteTitle="true" derivedAnchor="PRIO">
          <front>
            <title>Prio: Private, Robust, and Scalable Computation of Aggregate Statistics</title>
            <author initials="H." surname="Corrigan-Gibbs">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Boneh">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="March"/>
          </front>
        </reference>
        <reference anchor="RANDOM" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RANDOM">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <date month="June" year="2005"/>
            <abstract>
              <t indent="0">Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t indent="0">Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC7838" target="https://www.rfc-editor.org/info/rfc7838" quoteTitle="true" derivedAnchor="RFC7838">
          <front>
            <title>HTTP Alternative Services</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <author fullname="J. Reschke" initials="J." surname="Reschke"/>
            <date month="April" year="2016"/>
            <abstract>
              <t indent="0">This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7838"/>
          <seriesInfo name="DOI" value="10.17487/RFC7838"/>
        </reference>
        <reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8484" quoteTitle="true" derivedAnchor="RFC8484">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <date month="October" year="2018"/>
            <abstract>
              <t indent="0">This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="TEMPLATE" target="https://www.rfc-editor.org/info/rfc6570" quoteTitle="true" derivedAnchor="TEMPLATE">
          <front>
            <title>URI Template</title>
            <author fullname="J. Gregorio" initials="J." surname="Gregorio"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="M. Hadley" initials="M." surname="Hadley"/>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="D. Orchard" initials="D." surname="Orchard"/>
            <date month="March" year="2012"/>
            <abstract>
              <t indent="0">A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6570"/>
          <seriesInfo name="DOI" value="10.17487/RFC6570"/>
        </reference>
        <reference anchor="UWT" target="https://www.w3.org/2001/tag/doc/unsanctioned-tracking/" quoteTitle="true" derivedAnchor="UWT">
          <front>
            <title>Unsanctioned Web Tracking</title>
            <author fullname="Mark Nottingham">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="July"/>
          </front>
          <refcontent>W3C TAG Finding</refcontent>
        </reference>
        <reference anchor="X25519" target="https://www.rfc-editor.org/info/rfc7748" quoteTitle="true" derivedAnchor="X25519">
          <front>
            <title>Elliptic Curves for Security</title>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="January" year="2016"/>
            <abstract>
              <t indent="0">This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7748"/>
          <seriesInfo name="DOI" value="10.17487/RFC7748"/>
        </reference>
      </references>
    </references>
    <section anchor="complete-example-of-a-request-and-response" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-complete-example-of-a-reque">Complete Example of a Request and Response</name>
      <t indent="0" pn="section-appendix.a-1">A single request and response exchange is shown here. Binary values (<xref target="key-configuration" format="none" sectionFormat="of" derivedContent="">key
configuration</xref>, secret keys, the content of messages, and intermediate values)
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
<xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> is configured with the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref> URI of
<tt>https://proxy.example.org/request.example.net/proxy</tt>, and the proxy is
configured to map requests to this URI to the <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> URI
<tt>https://example.com/oblivious/request</tt>. The <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref> URI, i.e., the
resource the Client ultimately wishes to query, is <tt>https://example.com</tt>.</t>
      <t indent="0" pn="section-appendix.a-2">To begin the process, the Oblivious Gateway Resource generates a key pair.
In this example, the server chooses DHKEM(X25519, HKDF-SHA256) and generates
an X25519 key pair <xref target="X25519" format="default" sectionFormat="of" derivedContent="X25519"/>. The X25519 secret key is:</t>
      <artwork align="left" pn="section-appendix.a-3">
3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a
</artwork>
      <t indent="0" pn="section-appendix.a-4">The Oblivious Gateway Resource constructs a key configuration that includes the
corresponding public key as follows:</t>
      <artwork align="left" pn="section-appendix.a-5">
01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e
79815500080001000100010003
</artwork>
      <t indent="0" pn="section-appendix.a-6">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>, it
constructs the following binary HTTP message:</t>
      <artwork align="left" pn="section-appendix.a-7">
00034745540568747470730b6578616d706c652e636f6d012f
</artwork>
      <t indent="0" pn="section-appendix.a-8">The Client then reads the Oblivious Gateway Resource key configuration and
selects a mutually supported KDF and AEAD. In this example, the Client selects
HKDF-SHA256 and AES-128-GCM. The Client then generates an HPKE sending context
that uses the server public key. This context is constructed from the following
ephemeral secret key:</t>
      <artwork align="left" pn="section-appendix.a-9">
bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73
</artwork>
      <t indent="0" pn="section-appendix.a-10">The corresponding public key is:</t>
      <artwork align="left" pn="section-appendix.a-11">
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
</artwork>
      <t indent="0" pn="section-appendix.a-12">The context is created with an <tt>info</tt> parameter of:</t>
      <artwork align="left" pn="section-appendix.a-13">
6d6573736167652f626874747020726571756573740001002000010001
</artwork>
      <t indent="0" pn="section-appendix.a-14">Applying the Seal operation from the HPKE context produces an encrypted
message, allowing the Client to construct the following <xref target="dfn-enc-req" format="none" sectionFormat="of" derivedContent="">Encapsulated Request</xref>:</t>
      <artwork align="left" pn="section-appendix.a-15">
010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1
9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796
5e7d86b83dd440b2c0185204b4d63525
</artwork>
      <t indent="0" pn="section-appendix.a-16">The Client then sends this to the Oblivious Relay Resource in a POST request,
which might look like the following HTTP/1.1 request:</t>
      <sourcecode type="http-message" markers="false" pn="section-appendix.a-17">
POST /request.example.net/proxy HTTP/1.1
Host: proxy.example.org
Content-Type: message/ohttp-req
Content-Length: 78

&lt;content is the Encapsulated Request above&gt;
</sourcecode>
      <t indent="0" pn="section-appendix.a-18">The Oblivious Relay Resource receives this request and forwards it to the
Oblivious Gateway Resource, which might look like:</t>
      <sourcecode type="http-message" markers="false" pn="section-appendix.a-19">
POST /oblivious/request HTTP/1.1
Host: example.com
Content-Type: message/ohttp-req
Content-Length: 78

&lt;content is the Encapsulated Request above&gt;
</sourcecode>
      <t indent="0" pn="section-appendix.a-20">The <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> receives this request, selects the key it
generated previously using the key identifier from the message, and decrypts the
message. As this request is directed to the same server, the Oblivious Gateway
Resource does not need to initiate an HTTP request to the <xref target="dfn-target" format="none" sectionFormat="of" derivedContent="">Target Resource</xref>. The
request can be served directly by the Target Resource, which generates a minimal
response (consisting of just a 200 status code) as follows:</t>
      <artwork align="left" pn="section-appendix.a-21">
0140c8
</artwork>
      <t indent="0" pn="section-appendix.a-22">The response is constructed by exporting a secret from the HPKE context:</t>
      <artwork align="left" pn="section-appendix.a-23">
62d87a6ba569ee81014c2641f52bea36
</artwork>
      <t indent="0" pn="section-appendix.a-24">The key derivation for the <xref target="dfn-enc-res" format="none" sectionFormat="of" derivedContent="">Encapsulated Response</xref> uses both the encapsulated KEM
key from the request and a randomly selected nonce. This produces a salt of:</t>
      <artwork align="left" pn="section-appendix.a-25">
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
c789e7151fcba46158ca84b04464910d
</artwork>
      <t indent="0" pn="section-appendix.a-26">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>
      <artwork align="left" pn="section-appendix.a-27">
979aaeae066cf211ab407b31ae49767f344e1501e475c84e8aff547cc5a683db
</artwork>
      <t indent="0" pn="section-appendix.a-28">The pseudorandom key is used with the <tt>Expand</tt> function of the KDF and an info
field of "key" to produce a 16-byte key for the selected AEAD (AES-128-GCM):</t>
      <artwork align="left" pn="section-appendix.a-29">
5d0172a080e428b16d298c4ea0db620d
</artwork>
      <t indent="0" pn="section-appendix.a-30">With the same KDF and pseudorandom key, an info field of "nonce" is used to
generate a 12-byte nonce:</t>
      <artwork align="left" pn="section-appendix.a-31">
f6bf1aeb88d6df87007fa263
</artwork>
      <t indent="0" pn="section-appendix.a-32">The AEAD <tt>Seal()</tt> function is then used to encrypt the response, which is added
to the randomized nonce value to produce the Encapsulated Response:</t>
      <artwork align="left" pn="section-appendix.a-33">
c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
857fbd
</artwork>
      <t indent="0" pn="section-appendix.a-34">The <xref target="dfn-gateway" format="none" sectionFormat="of" derivedContent="">Oblivious Gateway Resource</xref> constructs a response with the same content:</t>
      <sourcecode type="http-message" markers="false" pn="section-appendix.a-35">
HTTP/1.1 200 OK
Date: Wed, 27 Jan 2021 04:45:07 GMT
Cache-Control: private, no-store
Content-Type: message/ohttp-res
Content-Length: 38

&lt;content is the Encapsulated Response&gt;
</sourcecode>
      <t indent="0" pn="section-appendix.a-36">The same response might then be generated by the <xref target="dfn-relay" format="none" sectionFormat="of" derivedContent="">Oblivious Relay Resource</xref>, which
might change as little as the <tt>Date</tt> header. The <xref target="dfn-client" format="none" sectionFormat="of" derivedContent="">Client</xref> is then able to use the
HPKE context it created and the nonce from the Encapsulated Response to
construct the AEAD key and nonce and decrypt the response.</t>
    </section>
    <section numbered="false" anchor="acknowledgments" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.b-1">This design is based on a design for Oblivious DNS (queries) over HTTPS (DoH),
described in <xref target="ODOH" format="default" sectionFormat="of" derivedContent="ODOH"/>. <contact fullname="David Benjamin"/>, <contact fullname="Mark Nottingham"/>, and
<contact fullname="Eric Rescorla"/> made technical contributions.  The authors also thank
<contact fullname="Ralph Giles"/>, <contact fullname="Lucas Pardue"/>, and <contact fullname="Tommy Pauly"/> for invaluable
assistance.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="M." surname="Thomson" fullname="Martin Thomson">
        <organization showOnFrontPage="true">Mozilla</organization>
        <address>
          <email>mt@lowentropy.net</email>
        </address>
      </author>
      <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
        <organization showOnFrontPage="true">Cloudflare</organization>
        <address>
          <email>caw@heapingbits.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
