Draft: draft-ietf-ohai-ohttp

Commentary: Per suggestion , I also clarified the contents of the proxy and encapsulated request in the diagram . That revealed an inconsistency throughout the draft , where we sometimes refer to the encrypted binary HTTP message as the " encapsulated request , " but this change redefines the encapsulated request to be the request from proxy to encap resource that contains the encrypted binary HTTP message . In any case , I went through and changed all uses of " encapsulated request / response " to be " encrypted request / response " where it felt appropriate . This is encryption , after all , so it seems more clear to just call it that . ( Encapsulation in the context HPKE means something different , and is generally not the functionality that it provides to users . ) please have another look ! 
 LGTM 
 After chatting with offline , here 's a proposal we came up with . First , redefine the entities to Client , Oblivious Relay , Oblivious Gateway , and Target . Based on these , we think the following names make sense : Client -Oblivious Relay : Oblivious Relay Request , carrying an Encrypted Request Oblivious Relay -Oblivious Gateway : Oblivious Gateway Request , carrying the same Encrypted Request Oblivious Gateway -Target : Request I 'll take this to the list for the bike shed . 
 OK , new terminology updates applied . I reverted the encryption / encapsulation change to keep this PR focused on the new terms . I also tried to use consistency capitalization when referring to these types throughout the doc . please review ! 
 I 'm going to merge this to avoid dragging this PR out . If there 's anything left to fix , let 's do it on top of the changes in . 
 We need to improve the terminology in this draft . In particular , we need a distinguished term for the request to the proxy , which includes the encapsulated request , as well as a distinguished term for the inner request from client to target . 
 This would IMO help . There seems to be important security properties related to demarcation between the requests and having terms that could lead to ambiguity does n't seem good . 
 I personally used the following terms when I implemented the client - side : " Oblivious Request " is the encrypted message that goes from the client to the proxy " Oblivious Response " is the encrypted message that goes from the proxy to the client I did n't have terms for the inner requests and responses — the response was just a " decrypted response " . But using " inner " might make sense , or " plaintext " ? 
 inner = encapsulated outer = oblivious These all work for me . 
 Hrm , on reflection , I do n't think " oblivious request " and " oblivious response " will work for the client < proxy messages , since oblivious request means something else in this document ( the resource that decrypts the encapsulated request for the target ) . I have an alternative proposal in that I think better describes the different requests and resources based on what they 're doing . 
 I think that we have some inconsistent encapsulated vs. encrypted stuff here . I 'm also not that enthusiastic about   , but do n't care enough to fight for any particular outcome , except the one where they are used consistently . You seem to have missed a few , that is .
Though this scheme requires that servers and proxies explicitly
support it, this design represents a performance improvement over
options that perform just one request in each connection.  With
limited trust placed in the proxy (see security), clients are assured
that requests are not uniquely attributed to them or linked to other
requests.
The identity of an oblivious request resource.  This might include
some information about what oblivious target resources the
oblivious request resource supports.
The details of an HPKE public key that the oblivious request
resource accepts, including an identifier for that key and the
HPKE algorithms that are used with that key.
The identity of an oblivious proxy resource that will forward
encapsulated requests and responses to a single oblivious request
resource.  See proxy-state for more information about the mapping
between oblivious proxy and oblivious request resources.
The client sends a POST request to the oblivious proxy resource
with the encapsulated request as the content of that message.
The oblivious proxy resource forwards this request to the
oblivious request resource.
The oblivious request resource receives this request and removes
the HPKE protection to obtain an HTTP request.
The oblivious request resource makes an HTTP request that includes
the target URI, method, fields, and content of the request it
acquires.
The oblivious request resource encapsulates the HTTP response
following the process in response and sends this in response to
the request from the oblivious proxy resource.
The oblivious proxy resource forwards this response to the client.
Though this scheme requires that servers and proxies (called relays
in this document) explicitly support it, this design represents a
performance improvement over options that perform just one request in
each connection.  With limited trust placed in the relay (see
security), clients are assured that requests are not uniquely
attributed to them or linked to other requests.
The identity of an Oblivious Gateway Resource.  This might include
some information about what Oblivious Target Resources the
Oblivious Gateway Resource supports.
The details of an HPKE public key that the Oblivious Gateway
Resource accepts, including an identifier for that key and the
HPKE algorithms that are used with that key.
The identity of an Oblivious Relay Resource that will accept relay
requests carrying an encapsulated request as its content and
forward the content in these requests to a single Oblivious
Gateway Resource.  See proxy-state for more information about the
mapping between Oblivious Relay and Gateway Resources.
The client sends a POST request to the Oblivious Relay Resource
with the Encapsulated Request as the content of that message.
The Oblivious Relay Resource forwards this request to the
Oblivious Gateway resource.
The Oblivious Gateway Resource receives this request and removes
the HPKE protection to obtain an HTTP request.
The Oblivious Gateway Resource makes an HTTP request that includes
the target URI, method, fields, and content of the request it
acquires.
The Oblivious Gateway Resource encapsulates the HTTP response
following the process in response and sends this in response to
the request from the Oblivious Relay Resource.
The Oblivious Relay Resource forwards this response to the client.
A client needs to acquire information about the key configuration of
the oblivious request resource in order to send encapsulated
requests.  In order to ensure that clients do not encapsulate
messages that other entities can intercept, the key configuration
MUST be authenticated and have integrity protection.
A client needs to acquire information about the key configuration of
the Oblivious Gateway Resource in order to send encapsulated
requests.  In order to ensure that clients do not encapsulate
messages that other entities can intercept, the key configuration
MUST be authenticated and have integrity protection.
An encapsulated HTTP response includes a binary-encoded HTTP message
BINARY and no other content; see fig-res-pt.
Concatenate the values of "aad", "enc", and "ct", yielding an
Encapsulated Request "enc_request".
Concatenate the values of "aad", "enc", and "ct", yielding an
Encrypted Request "enc_request".
Clients decrypt an Encapsulated Request by reversing this process.
That is, they first parse "enc_response" into "response_nonce" and
"ct".  They then follow the same process to derive values for
"aead_key" and "aead_nonce".
Clients decrypt an Encapsulated Response by reversing this process.
That is, they first parse "enc_response" into "response_nonce" and
"ct".  They then follow the same process to derive values for
"aead_key" and "aead_nonce".
A client interacts with the oblivious proxy resource by constructing
an encapsulated request.  This encapsulated request is included as
the content of a POST request to the oblivious proxy resource.  This
request MUST only contain those fields necessary to carry the
encapsulated request: a method of POST, a target URI of the oblivious
proxy resource, a header field containing the content type (see
(media-types), and the encapsulated request as the request content.
In the request to the oblivious proxy resource, clients MAY include
additional fields.  However, those fields MUST be independent of the
encapsulated request and MUST be fields that the oblivious proxy
resource will remove before forwarding the encapsulated request
towards the target, such as the Connection or Proxy-Authorization
header fields SEMANTICS.
The oblivious proxy resource interacts with the oblivious request
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 request resource.  The content of this request is copied
from the client.  The oblivious proxy resource MUST NOT add
information to the request without the client being aware of the type
of information that might be added; see proxy-responsibilities for
more information on proxy responsibilities.
An oblivious request resource, if it receives any response from the
oblivious target resource, sends a single 200 response containing the
encapsulated response.  Like the request from the client, this
response MUST 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 MAY be used to convey
information that does not reveal information about the encapsulated
response.
A client interacts with the Oblivious Relay Resource by constructing
an Encapsulated Request.  This Encapsulated Request is included as
the content of a POST request to the Oblivious Relay Resource.  This
request MUST only contain 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
(media-types), and the Encapsulated Request as the request content.
In the request to the Oblivious Relay Resource, clients MAY include
additional fields.  However, those fields MUST be independent of the
Encapsulated Request and MUST be fields that the Oblivious Relay
Resource will remove before forwarding the Encapsulated Request
towards the target, such as the Connection or Proxy-Authorization
header fields SEMANTICS.
The client role in this protocol acts as an HTTP client both with
respect to the Oblivious Relay Resource and the Oblivious Target
Resource.  For the request the clients makes to the Oblivious Target
Resource, this diverges from typical HTTP assumptions about the use
of a connection (see HTTP) in that the request and response are
encrypted rather than sent over a connection.  The Oblivious Relay
Resource and the Oblivious Gateway Resource also act as HTTP clients
toward the Oblivious Gateway Resource and Oblivious Target Resource
respectively.
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.  The Oblivious Relay Resource MUST NOT add
information to the request without the client being aware of the type
of information that might be added; see relay-responsibilities for
more information on relay responsibilities.
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 HTTP.
An Oblivious Gateway Resource, if it receives any response from the
Oblivious Target Resource, sends a single 200 response containing the
encapsulated response.  Like the request from the client, this
response MUST 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 MAY be used to convey
information that does not reveal information about the encapsulated
response.
An Oblivious Gateway Resource acts as a gateway for requests to the
oblivious target resource (see HTTP).  The one exception is that any
information it might forward in a response MUST be encapsulated,
unless it is responding to errors it detects before removing
encapsulation of the request; see errors.
Errors detected by the oblivious proxy resource and errors detected
by the oblivious request resource 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.
Errors detected by the oblivious request resource after successfully
removing encapsulation and errors detected by the oblivious target
resource MUST be sent in an encapsulated response.
The "message/ohttp-req" identifies an encapsulated binary HTTP
request.  This is a binary format that is defined in request.
The "message/ohttp-res" identifies an encapsulated binary HTTP
response.  This is a binary format that is defined in response.
Errors detected by the Oblivious Relay Resource and errors detected
by the Oblivious Gateway Resource 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.
Errors detected by the Oblivious Gateway Resource after successfully
removing encapsulation and errors detected by the Oblivious Target
Resource MUST be sent in an Encapsulated Response.
The "message/ohttp-req" identifies an encrypted binary HTTP request.
This is a binary format that is defined in request.
The "message/ohttp-res" identifies an encrypted binary HTTP response.
This is a binary format that is defined in response.
In order to ensure this, the client selects a proxy (that serves the
oblivious proxy resource) that it trusts will protect this
information by forwarding the encapsulated request and response
without passing it to the server (that serves the oblivious request
resource).
To achieve the stated privacy goals, the oblivious proxy resource
cannot be operated by the same entity as the oblivious request
resource.  However, colocation of the oblivious request resource and
oblivious target resource simplifies the interactions between those
resources without affecting client privacy.
In order to ensure this, the client selects a relay (that serves the
Oblivious Relay Resource) 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).
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
Oblivious Target Resource simplifies the interactions between those
resources without affecting client privacy.
Requests and responses are known only to clients and targets in
possession of the corresponding response encapsulation key and
HPKE keying material.  In particular, the oblivious proxy knows
the origin and destination of an encapsulated request and
response, yet does not know the decapsulated contents.  Likewise,
targets know only the oblivious request origin, i.e., the proxy,
and the decapsulated request.  Only the client knows both the
plaintext request and response.
Requests and responses are known only to clients and targets in
possession of the corresponding response encapsulation key and
HPKE keying material.  In particular, the Oblivious Relay knows
the origin and destination of an Encapsulated Request and
Response, yet does not know the decrypted contents.  Likewise,
targets know only the Oblivious Gateway origin, i.e., the relay,
and the decrypted request.  Only the client knows both the
plaintext request and response.
Clients MUST ensure that the key configuration they select for
generating encapsulated requests is integrity protected and
authenticated so that it can be attributed to the oblivious request
resource; see key-configuration.
Clients MUST NOT include identifying information in the request that
is encapsulated.  Identifying information includes cookies COOKIES,
authentication credentials or tokens, and any information that might
reveal client-specific information such as account credentials.
Clients cannot carry connection-level state between requests as they
only establish direct connections to the proxy responsible for the
oblivious proxy resource.  However, clients need to ensure that they
construct requests without any information gained from previous
requests.  Otherwise, the server might be able to use that
information to link requests.  Cookies COOKIES are the most obvious
feature that MUST NOT be used by clients.  However, clients need to
include all information learned from requests, which could include
the identity of resources.
Clients MUST ensure that the key configuration they select for
generating Encapsulated Requests is integrity protected and
authenticated so that it can be attributed to the Oblivious Gateway
Resource; see key-configuration.
Since clients connect directly to the relay instead of the target,
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 (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.  When this
difference is relevant, applications can instead connect directly to
the target at the cost of either privacy or performance.
Clients MUST NOT include identifying information in the request that
is encrypted.  Identifying information includes cookies COOKIES,
authentication credentials or tokens, and any information that might
reveal client-specific information such as account credentials.
Clients cannot carry connection-level state between requests as they
only establish direct connections to the relay responsible for the
Oblivious Relay resource.  However, clients need to ensure that they
construct requests without any information gained from previous
requests.  Otherwise, the server might be able to use that
information to link requests.  Cookies COOKIES are the most obvious
feature that MUST NOT be used by clients.  However, clients need to
include all information learned from requests, which could include
the identity of resources.
Clients MUST generate a new HPKE context for every request, using a
good source of entropy (RANDOM) for generating keys.  Key reuse not
only risks requests being linked, reuse could expose request and
response contents to the proxy.
The request the client sends to the oblivious proxy resource only
requires minimal information; see http-usage.  The request that
carries the encapsulated request and is sent to the oblivious proxy
resource MUST NOT include identifying information unless the client
ensures that this information is removed by the proxy.  A client MAY
include information only for the oblivious proxy resource in header
fields identified by the Connection header field if it trusts the
proxy to remove these as required by Section 7.6.1 of HTTP.  The
client needs to trust that the proxy does not replicate the source
addressing information in the request it forwards.
Clients rely on the oblivious proxy resource to forward encapsulated
requests and responses.  However, the proxy can only refuse to
forward messages, it cannot inspect or modify the contents of
encapsulated requests or responses.
The proxy that serves the oblivious proxy resource has a very simple
function to perform.  For each request it receives, it makes a
request of the oblivious request resource that includes the same
content.  When it receives a response, it sends a response to the
client that includes the content of the response from the oblivious
request resource.
Firstly, a generic implementation will forward unknown fields.  For
oblivious HTTP, a proxy SHOULD NOT forward unknown fields.  Though
clients are not expected to include fields that might contain
identifying information, removing unknown fields removes this privacy
risk.
Secondly, generic implementations are often configured to augment
requests with information about the client, such as the Via field or
the Forwarded field FORWARDED.  A proxy MUST NOT add information when
forwarding requests that might be used to identify clients, with the
exception of information that a client is aware of.
A proxy MAY add information to requests if the client is aware of the
nature of the information that could be added.  The 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 proxy might use.  It is
important to note that information added by the proxy can reduce the
size of the anonymity set of clients at a server.
A proxy can also generate responses, though it assumed to not be able
to examine the content of a request (other than to observe the choice
of key identifier, KDF, and AEAD), so it is also assumed that it
cannot generate an encapsulated response.
As there are privacy benefits from having a large rate of requests
forwarded by the same proxy (see ta), servers that operate the
oblivious request resource might need an arrangement with proxies.
This arrangement might be necessary to prevent having the large
volume of requests being classified as an attack by the server.
If a server accepts a larger volume of requests from a proxy, it
needs to trust that the proxy does not allow abusive levels of
request volumes from clients.  That is, if a server allows requests
from the proxy to be exempt from rate limits, the server might want
to ensure that the proxy applies a rate limiting policy that is
acceptable to the server.
Servers that enter into an agreement with a proxy that enables a
higher request rate might choose to authenticate the proxy to enable
the higher rate.
Clients MUST generate a new HPKE context for every request, using a
good source of entropy (RANDOM) for generating keys.  Key reuse not
only risks requests being linked, reuse could expose request and
response contents to the relay.
The request the client sends to the Oblivious Relay Resource only
requires minimal information; see http-usage.  The request that
carries the Encapsulated Request and is sent to the Oblivious Relay
Resource MUST NOT include identifying information unless the client
ensures that this information is removed by the relay.  A client MAY
include information only for the Oblivious Relay Resource in header
fields identified by the Connection header field if it trusts the
relay to remove these as required by Section 7.6.1 of HTTP.  The
client needs to trust that the relay does not replicate the source
addressing information in the request it forwards.
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.
The relay that serves the Oblivious Relay Resource has a very simple
function to perform.  For each request it receives, it makes a
request of the oblivious request resource that includes the same
content.  When it receives a response, it sends a response to the
client that includes the content of the response from the Oblivious
Gateway Resource.
When forwarding a request, the relay MUST follow the forwarding rules
in 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.
Firstly, a generic implementation will forward unknown fields.  For
oblivious HTTP, a relay SHOULD NOT forward unknown fields.  Though
clients are not expected to include fields that might contain
identifying information, removing unknown fields removes this privacy
risk.
Secondly, generic implementations are often configured to augment
requests with information about the client, such as the Via field or
the Forwarded field FORWARDED.  A relay MUST NOT add information when
forwarding requests that might be used to identify clients, with the
exception of information that a client is aware of.
A relay MAY add information to requests if the client is aware of the
nature of the information that could be added.  The 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.  It is
important to note that information added by the relay can reduce the
size of the anonymity set of clients at a server.
A relay can also generate responses, though it assumed to not be able
to examine the content of a request (other than to observe the choice
of key identifier, KDF, and AEAD), so it is also assumed that it
cannot generate an Encapsulated Response.
As there are privacy benefits from having a large rate of requests
forwarded by the same relay (see ta), servers that operate the
Oblivious Gateway resource might need an arrangement with proxies.
This arrangement might be necessary to prevent having the large
volume of requests being classified as an attack by the server.
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 clients.  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.
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.
This document assumes that all communication between different
entities is protected by HTTPS.  This 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 proxy.
As the time at which encapsulated request or response messages are
sent can reveal information to a network observer.  Though messages
exchanged between the oblivious proxy resource and the oblivious
request resource might be sent in a single connection, traffic
analysis could be used to match messages that are forwarded by the
proxy.
A proxy could, as part of its function, add delays in order to
increase the anonymity set into which each message is attributed.
This could latency to the overall time clients take to receive a
response, which might not be what some clients want.
A proxy that forwards large volumes of exchanges can provide better
privacy by providing larger sets of messages that need to be matched.
A server that operates both oblivious request and oblivious target
resources is responsible for removing request encapsulation,
generating a response the encapsulated request, and encapsulating the
response.
If separate entities provide the oblivious request resource and
oblivious target resource, these entities might need an arrangement
similar to that between server and proxy for managing denial of
service; see dos.  It is also necessary to provide confidentiality
protection for the unprotected requests and responses, plus
protections for traffic analysis; see ta.
An oblivious request resource 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 request 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.
A server MUST 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 encapsulation 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 repurposing-the-encapsulation-format.
This document assumes that all communication between different
entities is protected by HTTPS.  This 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.
As the time at which Encapsulated Request or response messages are
sent can reveal information to a network observer.  Though messages
exchanged between the Oblivious Relay Resource and the Oblivious
Gateway Resource might be sent in a single connection, traffic
analysis could be used to match messages that are forwarded by the
relay.
A relay could, as part of its function, add delays in order to
increase the anonymity set into which each message is attributed.
This could latency to the overall time clients take to receive a
response, which might not be what some clients want.
A relay can use padding to reduce the effectiveness of traffic
analysis.  Padding is a capability provided by binary HTTP messages;
see BINARY.
A relay that forwards large volumes of exchanges can provide better
privacy by providing larger sets of messages that need to be matched.
A server that operates both Oblivious Gateway and Oblivious Target
Resources is responsible for removing request encryption, generating
a response to the Encapsulated Request, and encrypting the response.
If separate entities provide the Oblivious Gateway Resource and
oblivious target resource, these entities might need an arrangement
similar to that between server and relay for managing denial of
service; see dos.  It is also necessary to provide confidentiality
protection for the unprotected requests and responses, plus
protections for traffic analysis; see ta.
An Oblivious Gateway Resource 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.
Encrypted requests can be copied and replayed by the Oblivious Relay
resource.  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 TLS
and 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.
A client or oblivious proxy resource MUST NOT 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 (Section 8.1.4 of RFC7540), the
HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of QUIC-HTTP), or
a GOAWAY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred.
Connection failures or interruptions are not sufficient signals that
no processing occurred.
A client or Oblivious Relay Resource MUST NOT 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 (Section 8.1.4 of RFC7540), the
HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of QUIC-HTTP), or
a GOAWAY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred.
Connection failures or interruptions are not sufficient signals that
no processing occurred.
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 oblivious request resource 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.
Even if server keys are compromised, an adversary cannot access
messages exchanged by the client with the oblivious proxy resource as
messages are protected by TLS.  Use of a compromised key also
requires that the oblivious proxy resource cooperate with the
attacker or that the attacker is able to compromise these TLS
connections.
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 Oblivious Gateway Resource 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.
Even if server keys are compromised, an adversary cannot access
messages exchanged by the client with the Oblivious Relay Resource 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.
One goal of this design is that independent client requests are only
linkable by the chosen key configuration.  The oblivious proxy and
request resources can link requests using the same key configuration
by matching KeyConfig.key_id, or, if the oblivious target resource is
willing to use trial decryption, a limited set of key configurations
that share an identifier.  An oblivious proxy can link requests using
the public key corresponding to KeyConfig.key_id.
One goal of this design is that independent client requests are only
linkable by the chosen key configuration.  The Oblivious Relay and
request resources can link requests using the same key configuration
by matching KeyConfig.key_id, or, if the Oblivious Target Resource is
willing to use trial decryption, a limited set of key configurations
that share an identifier.  An Oblivious Relay can link requests using
the public key corresponding to KeyConfig.key_id.
Using Oblivious HTTP adds both cryptographic and latency to requests
relative to a simple HTTP request-response exchange.  Deploying proxy
services that are on path between clients and servers avoids adding
significant additional delay due to network topology.  A study of a
similar system ODoH found that deploying proxies close to servers was
most effective in minimizing additional latency.
Using Oblivious HTTP adds both cryptographic and latency to requests
relative to a simple HTTP request-response exchange.  Deploying relay
services that are on path between clients and servers avoids adding
significant additional delay due to network topology.  A study of a
similar system ODoH found that deploying proxies close to servers was
most effective in minimizing additional latency.
This protocol assumes a fixed, one-to-one mapping between the
Oblivious Proxy Resource and the Oblivious Request Resource.  This
means that any encapsulated request sent to the Oblivious Proxy
Resource will always be forwarded to the Oblivious Request Resource.
This constraint was imposed to simplify proxy configuration and
mitigate against the Oblivious Proxy Resource being used as a generic
proxy for unknown Oblivious Request Resources.  The proxy will only
forward for Oblivious Request Resources that it has explicitly
configured and allowed.
It is possible for a server to be configured with multiple Oblivious
Proxy Resources, each for a different Oblivious Request Resource as
needed.  If the goal is to support a large number of Oblivious
Request Resources, clients might be provided with a URI template
TEMPLATE, from which multiple Oblivious Proxy Resources could be
constructed.
This protocol assumes a fixed, one-to-one mapping between the
Oblivious Proxy Resource and the Oblivious Gateway Resource.  This
means that any encrypted request 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.
It is possible for a server to be configured with multiple Oblivious
Proxy Resources, each for a different Oblivious Gateway Resource as
needed.  If the goal is to support a large number of Oblivious
Gateway Resources, clients might be provided with a URI template
TEMPLATE, from which multiple Oblivious Relay Resources could be
constructed.
The encapsulated payload of an OHTTP request and response is a binary
HTTP message BINARY.  Client and target agree on this encapsulated
payload type by specifying the media type "message/bhttp" in the HPKE
encapsulation info string and HPKE export context string for request
and response encapsulation, respectively.
Future specifications may repurpose the encapsulation mechanism
described in hpke-encapsulation, provided that the content type of
the encapsulated payload is appropriately reflected in the HPKE info
and context strings.  For example, if a future specification were to
use the encapsulation mechanism in this specification for DNS
messages, identified by the "application/dns-message" media type,
then the HPKE info string SHOULD be "application/dns-message request"
for request encapsulation, and the HPKE export context string should
be "application/dns-message response" for response encapsulation.