Draft: draft-ietf-ohai-ohttp

Commentary: In order to do this properly , I decided to capitalize  where it refers to an OHTTP Client . That was a lot of changes . This adds a beefy appendix to the document , but I have opened issues on xml2rfc that might eventually slim that down .
Client-configured HTTP proxies can provide a degree of protection
against IP address tracking, and systems like virtual private
networks and the Tor network Dingledine2004 provide additional
options for clients.
This document defines two kinds of HTTP resources - Oblivious Relay
Resources and Oblivious Gateway Resources - that process encapsulated
binary HTTP messages BINARY using Hybrid Public Key Encryption (HPKE;
HPKE).  They can be composed to protect the content of encapsulated
requests and responses, thereby separating the identity of a
requester from the request.
Although this scheme requires support for two new kinds of oblivious
resources, it represents a performance improvement over options that
perform just one request in each connection.  With limited trust
placed in the Oblivious Relay Resource (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 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.
This information allows the client to make a request of a Target
Resource with that resource having only a limited ability to
correlate that request with the client IP or other requests that the
client might make to that server.
The client constructs an HTTP request for a Target Resource.
The client encodes the HTTP request in a binary HTTP message and
then encapsulates that message using HPKE and the process from
request.
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 Target Resource answers this HTTP request with an HTTP
response.
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.
The client removes the encapsulation to obtain the response to the
original request.
This document defines two kinds of HTTP resources - and - that
process encapsulated binary HTTP messages BINARY using Hybrid Public
Key Encryption (HPKE; HPKE).  They can be composed to protect the
content of encapsulated requests and responses, thereby separating
the identity of a requester from the request.
Although this scheme requires support for two new kinds of oblivious
resources, it represents a performance improvement over options that
perform just one request in each connection.  With limited trust
placed in the (see security), are assured that requests are not
uniquely attributed to them or linked to other requests.
The identity of an .  This might include some information about
what Target Resources the supports.
The details of an HPKE public key that the accepts, including an
identifier for that key and the HPKE algorithms that are used with
that key.
The identity of an that will accept relay requests carrying an
encapsulated request as its content and forward the content in
these requests to a single . See proxy-state for more information
about the mapping between Oblivious Relay and Gateway Resources.
This information allows the to make a request of a with that resource
having only a limited ability to correlate that request with the IP
or other requests that the might make to that server.
The constructs an HTTP request for a .
The encodes the HTTP request in a binary HTTP message and then
encapsulates that message using HPKE and the process from request.
The sends a POST request to the with the as the content of that
message.
The forwards this request to the Oblivious Gateway resource.
The receives this request and removes the HPKE protection to
obtain an HTTP request.
The makes an HTTP request that includes the target URI, method,
fields, and content of the request it acquires.
The answers this HTTP request with an HTTP response.
The encapsulates the HTTP response following the process in
response and sends this in response to the request from the .
The forwards this response to the .
The removes the encapsulation to obtain the response to the
original request.
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.
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.  Note however that
such a system needs to consider the potential for key configuration
to be used to compromise client privacy; see privacy.
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 key derivation function (KDF) and authenticated encryption with
associated data (AEAD) in this decision.
A single key configuration consists of a key identifier, a public
key, an identifier for the KEM that the public key uses, and a set
HPKE symmetric algorithms.  Each symmetric algorithm consists of an
identifier for a KDF and an identifier for an AEAD.
format-key-config shows a single key configuration.
A needs to acquire information about the of the in order to send
encapsulated requests.  In order to ensure that do not encapsulate
messages that other entities can intercept, the MUST be authenticated
and have integrity protection.
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 implementations can
be configured in the same way and also enables advertising in a
consistent format.  This format might be used, for example with
HTTPS, as part of a system for configuring or discovering .  Note
however that such a system needs to consider the potential for to be
used to compromise privacy; see privacy.
A might have multiple to select from when encapsulating a request.
are responsible for selecting a preferred from those it supports.
need to consider both the key encapsulation method (KEM) and the
combinations of key derivation function (KDF) and authenticated
encryption with associated data (AEAD) in this decision.
A single consists of a key identifier, a public key, an identifier
for the KEM that the public key uses, and a set HPKE symmetric
algorithms.  Each symmetric algorithm consists of an identifier for a
KDF and an identifier for an AEAD.
format-key-config shows a single .
The "application/ohttp-keys" format is a media type that identifies a
serialized collection of key configurations.  The content of this
media type comprises one or more key configuration encodings (see
key-config) that are concatenated; see iana-keys for a definition of
the media type.
Evolution of the key configuration format is supported through the
definition of new formats that are identified by new media types.
The "application/ohttp-keys" format is a media type that identifies a
serialized collection of . The content of this media type comprises
one or more encodings (see key-config) that are concatenated; see
iana-keys for a definition of the media type.
Evolution of the format is supported through the definition of new
formats that are identified by new media types.
An Encapsulated Request is comprised of a key identifier and a HPKE-
protected request message.  HPKE protection includes an encapsulated
KEM shared secret (or "enc"), plus the AEAD-protected request
message.  An Encapsulated Request is shown in fig-enc-request.
request describes the process for constructing and processing an
Encapsulated Request.
An is comprised of a key identifier and a HPKE-protected request
message.  HPKE protection includes an encapsulated KEM shared secret
(or "enc"), plus the AEAD-protected request message.  An is shown in
fig-enc-request. request describes the process for constructing and
processing an .
Responses are bound to requests and so consist only of AEAD-protected
content.  response describes the process for constructing and
processing an Encapsulated Response.
The Nn and Nk values correspond to parameters of the AEAD used in
HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the
AEAD nonce and key respectively, in bytes.  The Encapsulated Response
nonce length is set to the larger of these two lengths, i.e., max(Nn,
Nk).
Responses are bound to requests and so consist only of AEAD-protected
content.  response describes the process for constructing and
processing an .
The Nn and Nk values correspond to parameters of the AEAD used in
HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the
AEAD nonce and key respectively, in bytes.  The nonce length is set
to the larger of these two lengths, i.e., max(Nn, Nk).
Concatenate "response_nonce" and "ct", yielding an Encapsulated
Response "enc_response".  Note that "response_nonce" is of fixed-
length, so there is no ambiguity in parsing either
"response_nonce" or "ct".
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".
Concatenate "response_nonce" and "ct", yielding an "enc_response".
Note that "response_nonce" is of fixed-length, so there is no
ambiguity in parsing either "response_nonce" or "ct".
decrypt an 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 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
(iana-req), 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 Target Resource.  For
the request the clients makes to the 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 Target Resource respectively.
In order to achieve the privacy and security goals of the protocol a
client also needs to observe the guidance in client-responsibilities.
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.  In case of timeout or error, the
Oblivious Relay Resource can generate a response with an appropriate
status code.
In order to achieve the privacy and security goals of the protocol an
Oblivious Relay Resource also needs to observe the guidance in relay-
responsibilities.
An Oblivious Gateway Resource acts as a gateway for requests to the
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.
An Oblivious Gateway Resource, if it receives any response from the
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 that does not receive a response can
itself generate a response with an appropriate error status code
(such as 504 (Gateway Timeout); see HTTP), which is then encapsulated
in the same way as a successful response.
In order to achieve the privacy and security goals of the protocol an
Oblivious Gateway Resource also needs to observe the guidance in
server-responsibilities.
A interacts with the by constructing an .  This is included as the
content of a POST request to the .  This request MUST only contain
those fields necessary to carry the : a method of POST, a target URI
of the , a header field containing the content type (see (iana-req),
and the as the request content.  In the request to the , MAY include
additional fields.  However, those fields MUST be independent of the
and MUST be fields that the will remove before forwarding the towards
the target, such as the Connection or Proxy-Authorization header
fields SEMANTICS.
The role in this protocol acts as an HTTP client both with respect to
the and the .  For the request the makes to the , 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 and the also act as HTTP clients toward the and
respectively.
In order to achieve the privacy and security goals of the protocol a
also needs to observe the guidance in client-responsibilities.
The interacts with the as an HTTP client by constructing a request
using the same restrictions as the request, except that the target
URI is the .  The content of this request is copied from the .  The
MUST NOT add information to the request without the 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 , the forwards the response
according to the rules of an HTTP proxy; see HTTP.  In case of
timeout or error, the can generate a response with an appropriate
status code.
In order to achieve the privacy and security goals of the protocol an
also needs to observe the guidance in relay-responsibilities.
An acts as a gateway for requests to the (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.
An , if it receives any response from the , sends a single 200
response containing the encapsulated response.  Like the request from
the , 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 that does not receive a response can itself generate a response
with an appropriate error status code (such as 504 (Gateway Timeout);
see HTTP), which is then encapsulated in the same way as a successful
response.
In order to achieve the privacy and security goals of the protocol an
also needs to observe the guidance in server-responsibilities.
In particular, the Expect header field with 100-continue (see HTTP)
cannot be used.  Clients MUST NOT construct a request that includes a
100-continue expectation; the Oblivious Gateway Resource MUST
generate an error if a 100-continue expectation is received.
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 Target Resource
MUST be sent in an Encapsulated Response.
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).
Any other request the client might have made in the past or might
make in the future.
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).
Connections between the client, Oblvious Relay Resource, and
Oblivious Gateway Resource MUST use HTTPS in order to provide
unlinkability in the presence of a network observer.  The scheme of
the encapsulated request determines what is used between the
Oblivious Gateway and Target Resources, though using HTTPS is
RECOMMENDED; see server-responsibilities.
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.
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.
Targets cannot link requests from the same client in the absence
of unique per-client keys.
In particular, the Expect header field with 100-continue (see HTTP)
cannot be used.  MUST NOT construct a request that includes a
100-continue expectation; the MUST generate an error if a
100-continue expectation is received.
Errors detected by the and errors detected by the 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 after successfully removing encapsulation and
errors detected by the MUST be sent in an .
The identity at the network and transport layer of the (that is,
the IP address and TCP or UDP port number the uses to create a
connection).
Any other request the might have made in the past or might make in
the future.
In order to ensure this, the selects a relay (that serves the ) that
it trusts will protect this information by forwarding the and
Response without passing it to the server (that serves the ).
Connections between the , Oblvious Relay Resource, and MUST use HTTPS
in order to provide unlinkability in the presence of a network
observer.  The scheme of the encapsulated request determines what is
used between the Oblivious Gateway and Target Resources, though using
HTTPS is RECOMMENDED; see server-responsibilities.
To achieve the stated privacy goals, the cannot be operated by the
same entity as the . However, colocation of the and simplifies the
interactions between those resources without affecting privacy.
Requests and responses are known only to and Target Resources,
plus that possess the corresponding response encapsulation key and
HPKE keying material.  In particular, the Oblivious Relay knows
the origin and destination of an and Response, yet does not know
the decrypted contents.  Likewise, learns only the and the
decrypted request.  No entity other than the can see the plaintext
request and response and can attribute them to the .
Targets cannot link requests from the same in the absence of
unique per- keys.
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 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 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.
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 Gateway 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 Oblivious Relay Resource 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.
Finally, 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.
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.
Importantly, information added by the relay - beyond what is already
revealed through encapsulated requests from clients - can reduce the
size of the anonymity set of clients at a gateway.
Moreover, relays MAY 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
signalled 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
which are not treated this way are known to be non-abusive by the
gateway.  Clients should consider the likelihood of such differential
treatment and the privacy risks when using a relay.
MUST ensure that the they select for generating Encapsulated Requests
is integrity protected and authenticated so that it can be attributed
to the ; see key-configuration.
Since connect directly to the instead of the , application
configurations wherein 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 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.
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 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.  also need to treat information learned from responses
with similar care when constructing subsequent requests, which
includes the identity of resources.
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 sends to the only requires minimal information; see
http-usage.  The request that carries the and is sent to the MUST NOT
include identifying information unless the ensures that this
information is removed by the relay.  A MAY include information only
for the 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 needs to trust that the relay does not replicate the
source addressing information in the request it forwards.
rely on the 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 has a very simple function to perform.  For
each request it receives, it makes a request of the that includes the
same content.  When it receives a response, it sends a response to
the that includes the content of the response from the .
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 , but additional care is needed to ensure
that privacy is maintained.
Firstly, a generic implementation will forward unknown fields.  For
Oblivious HTTP, a SHOULD NOT forward unknown fields.  Though 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 , 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 , with the
exception of information that a is aware of.
Finally, 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 .
A relay MAY add information to requests if the is aware of the nature
of the information that could be added.  The 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.  Importantly,
information added by the relay - beyond what is already revealed
through encapsulated requests from - can reduce the size of the
anonymity set of at a gateway.
Moreover, relays MAY apply differential treatment to that engage in
abusive behavior, e.g., by sending too many requests in comparison to
other , or as a response to rate limits signalled 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 using a gateway.  For example, if a relay
chooses to rate limit or block an abusive , this means that any
requests which are not treated this way are known to be non-abusive
by the gateway.  should consider the likelihood of such differential
treatment and the privacy risks when using a relay.
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 target are in a position to identify abuse.  A gateway MAY 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 errors.  A relay that acts on
this feedback could - either inadvertently or by design - lead to
client deanonymization.
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 Oblivious
Relay Resources.  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.
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 target are in a position to identify abuse.  A gateway MAY 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 errors.  A relay that acts on
this feedback could - either inadvertently or by design - lead to
deanonymization.
As there are privacy benefits from having a large rate of requests
forwarded by the same relay (see ta), servers that operate the might
need an arrangement with . 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 . 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.
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, 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
client waits for a response, so delays SHOULD only be added with the
consent - or at least awareness - of clients.
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.
Clients can use padding to reduce the effectiveness of traffic
analysis.  Padding is a capability provided by binary HTTP messages;
see BINARY.
The Oblivious Gateway Resource can be operated by a different entity
than the Target Resource.  However, this means that the client 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.
A server that operates both Oblivious Gateway and 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
Target Resource, these entities might need an arrangement similar to
that between server and relay for managing denial of service; see
dos.
The time at which or response messages are sent can reveal
information to a network observer.  Though messages exchanged between
the and the 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, 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
waits for a response, so delays SHOULD only be added with the consent
- or at least awareness - of .
Traffic analysis is not restricted to network observers.  A malicious
could use traffic analysis to learn information about otherwise
encrypted requests and responses relayed between and gateways.  An
terminates TLS connections from , so they see message boundaries.
This privileged position allows for richer feature extraction from
encrypted data, which might improve traffic analysis.
can use padding to reduce the effectiveness of traffic analysis.
Padding is a capability provided by binary HTTP messages; see BINARY.
The can be operated by a different entity than the .  However, this
means that the needs to trust the not to modify requests or
responses.  This analysis concerns itself with a deployment scenario
where a single server provides both the and .
A server that operates both Oblivious Gateway and Target Resources is
responsible for removing request encryption, generating a response to
the , and encrypting the response.
If separate entities provide the and , these entities might need an
arrangement similar to that between server and relay for managing
denial of service; see dos.
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.
A server can also use a 422 status code if the server has a key that
corresponds to the key identifier, but the Encapsulated Request
cannot be successfully decrypted using the key.
An needs to have a plan for replacing keys.  This might include
regular replacement of keys, which can be assigned new key
identifiers.  If an 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 can also use a 422 status code if the server has a key that
corresponds to the key identifier, but the cannot be successfully
decrypted using the key.
A server is responsible for either rejecting replayed requests or
ensuring that the effect of replays does not adversely affect clients
or resources.
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 server is responsible for either rejecting replayed requests or
ensuring that the effect of replays does not adversely affect or
resources.
Encrypted requests can be copied and replayed by the Oblivious Relay
resource.  The threat model for Oblivious HTTP allows the possibility
that an might replay requests.  Furthermore, if a sends an 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 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 (HTTP2), the HTTP/3
H3_REQUEST_REJECTED error code (HTTP3), 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 or 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
(HTTP2), the HTTP/3 H3_REQUEST_REJECTED error code (HTTP3), 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.
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.
The mechanism used in TLS for managing differences in and server
clocks cannot be used as it depends on being able to observe previous
interactions.  Oblivious HTTP explicitly prevents such linkability.
Clients SHOULD include a "Date" header field in Encapsulated
Requests, unless the Oblivious Gateway Resource does not use "Date"
for anti-replay purposes.
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 "enc" field of a request, which should
be unique to each request, is sufficient.  The Oblivious Gateway
Resource then rejects requests if the request is the same as one that
was previously answered within that time window, or if the "Date"
header field from the decrypted request is outside of the current
time window.
Oblivious Gateway Resources SHOULD 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.
Oblivious Gateway Resources MUST NOT treat the time window as secret
information.  An attacker can actively probe with different values
for the "Date" field to determine the time window over which the
server will accept responses.
An Oblivious Gateway Resource can reject requests that contain a
"Date" value that is outside of its active window with a 400 series
status code.  The problem type PROBLEM of
"https://iana.org/assignments/http-problem-types#date" is defined to
allow the server to signal that the "Date" value in the request was
unacceptable.
Disagreements about time are unlikely if both client and Oblivious
Gateway Resource have a good source of time; see NTP.  However, clock
differences are known to be commonplace; see Section 7.1 of
CLOCKSKEW.
Including a "Date" header field in the response allows the client to
correct clock errors by retrying the same request using the value of
the "Date" field provided by the Oblivious Gateway Resource.  The
value of the "Date" field can be copied if the request is fresh, with
an adjustment based on the "Age" field otherwise.  When retrying a
request, the client MUST create a fresh encryption of the modified
request, using a new HPKE context.
Intermediaries can sometimes rewrite the "Date" 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 MUST NOT retry a request with an
adjusted date more than once.
Oblivious Gateway Resources that condition their responses on the
"Date" header field SHOULD either ensure that intermediaries do not
cache responses (by including a "Cache-Control" directive of "no-
store") or designate the response as conditional on the value of the
"Date" request header field (by including the token "date" in a
"Vary" header field).
Clients MUST NOT 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.
This document does not provide forward secrecy for either requests or
responses during the lifetime of the key configuration.  A measure of
forward secrecy can be provided by generating a new key configuration
then deleting the old keys after a suitable period.
A client only needs to retain keying material that might be used
compromise the confidentiality and integrity of a response until that
response is consumed, so there is negligible risk associated with a
client compromise.
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.
SHOULD include a "Date" header field in Encapsulated Requests, unless
the does not use "Date" for anti-replay purposes.
An can maintain state for requests for a small window of time over
which it wishes to accept requests.  The can store all requests it
processes within this window.  Storing just the "enc" field of a
request, which should be unique to each request, is sufficient.  The
then rejects requests if the request is the same as one that was
previously answered within that time window, or if the "Date" header
field from the decrypted request is outside of the current time
window.
SHOULD allow for the time it takes requests to arrive from the , with
a time window that is large enough to allow for differences in
clocks.
MUST NOT treat the time window as secret information.  An attacker
can actively probe with different values for the "Date" field to
determine the time window over which the server will accept
responses.
An can reject requests that contain a "Date" value that is outside of
its active window with a 400 series status code.  The problem type
PROBLEM of "https://iana.org/assignments/http-problem-types#date" is
defined to allow the server to signal that the "Date" value in the
request was unacceptable.
Disagreements about time are unlikely if both and have a good source
of time; see NTP.  However, clock differences are known to be
commonplace; see Section 7.1 of CLOCKSKEW.
Including a "Date" header field in the response allows the to correct
clock errors by retrying the same request using the value of the
"Date" field provided by the .  The value of the "Date" field can be
copied if the request is fresh, with an adjustment based on the "Age"
field otherwise.  When retrying a request, the MUST create a fresh
encryption of the modified request, using a new HPKE context.
Intermediaries can sometimes rewrite the "Date" field when forwarding
responses.  This might cause problems if the and intermediary clocks
differ by enough to cause the retry to be rejected.  Therefore, MUST
NOT retry a request with an adjusted date more than once.
that condition their responses on the "Date" header field SHOULD
either ensure that intermediaries do not cache responses (by
including a "Cache-Control" directive of "no-store") or designate the
response as conditional on the value of the "Date" request header
field (by including the token "date" in a "Vary" header field).
MUST NOT use the date provided by the for any other purpose,
including future requests to any resource.  Any request that uses
information provided by the might be correlated using that
information.
This document does not provide forward secrecy for either requests or
responses during the lifetime of the . A measure of forward secrecy
can be provided by generating a new then deleting the old keys after
a suitable period.
A only needs to retain keying material that might be used compromise
the confidentiality and integrity of a response until that response
is consumed, so there is negligible risk associated with a
compromise.
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 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 with the as messages are protected by TLS.
Use of a compromised key also requires that the cooperate with the
attacker or that the attacker is able to compromise these TLS
connections.
Including a "Date" field in requests reveals some information about
the client clock.  This might be used to fingerprint clients UWT or
to identify clients that are vulnerable to attacks that depend on
incorrect clocks.
Clients can randomize the value that they provide for "Date" to
obscure the true value of their clock and reduce the chance of
linking of requests over time.  However, this increases the risk that
their request is rejected as outside the acceptable window.
One goal of this design is that independent client requests are only
linkable by their content.  However, the choice of client
configuration might be used to correlate requests.  A client
configuration includes the Oblivious Relay Resource URI, the
Oblivious Gateway key configuration (KeyConfig), and Oblivious
Gateway Resource URI.  A configuration is active if clients can
successfully use it for interacting with with a target.
Oblivious Relay and Gateway Resources can identify when requests use
the same configuration by matching the key ID 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 the keys that are used.
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.  A small number of configurations might need to be
active to allow for key rotation and server maintenance.
Client privacy depends on having each configuration used by many
other clients.  It is critical prevent the use of unique client
configurations, which might be used to track of individual clients,
but it is also important to avoid creating small groupings of clients
that might weaken privacy protections.
A specific method for a client to acquire configurations is not
included in this specification.  Applications using this design MUST
provide accommodations to mitigate tracking using client
configurations.  CONSISTENCY provides options for ensuring that
client configurations are consistent between clients.
Including a "Date" field in requests reveals some information about
the clock.  This might be used to fingerprint UWT or to identify that
are vulnerable to attacks that depend on incorrect clocks.
can randomize the value that they provide for "Date" to obscure the
true value of their clock and reduce the chance of linking of
requests over time.  However, this increases the risk that their
request is rejected as outside the acceptable window.
One goal of this design is that independent requests are only
linkable by their content.  However, the choice of configuration
might be used to correlate requests.  A configuration includes the
URI, the Oblivious Gateway (KeyConfig), and URI.  A configuration is
active if can successfully use it for interacting with with a target.
Oblivious Relay and Gateway Resources can identify when requests use
the same configuration by matching the key ID from the or the URI.
The might use the source address of requests to correlate requests
that use an run by the same operator.  If the is willing to use trial
decryption, requests can be further separated into smaller groupings
based on the keys that are used.
Each active configuration partitions the anonymity set.  In practice,
it is infeasible to reduce the number of active configurations to
one.  Enabling diversity in choice of naturally increases the number
of active configurations.  A small number of configurations might
need to be active to allow for key rotation and server maintenance.
privacy depends on having each configuration used by many other .  It
is critical prevent the use of unique configurations, which might be
used to track of individual , but it is also important to avoid
creating small groupings of that might weaken privacy protections.
A specific method for a to acquire configurations is not included in
this specification.  Applications using this design MUST provide
accommodations to mitigate tracking using configurations.
CONSISTENCY provides options for ensuring that configurations are
consistent between .
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 COOKIES, but it also
includes any information in either message that might affect how
subsequent requests are formulated.  For example, 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.
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 COOKIES, but it also
includes any information in either message that might affect how
subsequent requests are formulated.  For example, FIELDING describes
how interactions that are individually stateless can be used to build
a stateful system when a acts on the content of a response.
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 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 Relay 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
Relay 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.
Oblivious HTTP might be incompatible with network interception
regimes, such as those that rely on configuring clients with trust
anchors and intercepting TLS connections.  While TLS might be
intercepted successfully, interception middleboxes devices might not
receive updates that would allow Oblivious HTTP to be correctly
identified using the media types defined in iana-req and iana-res.
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.
The encrypted payload of an OHTTP request and response is a binary
HTTP message BINARY.  Client and target 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.
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 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 and the
. This means that any encrypted request sent to the will always be
forwarded to the . This constraint was imposed to simplify relay
configuration and mitigate against the being used as a generic relay
for unknown . The relay will only forward for that it has explicitly
configured and allowed.
It is possible for a server to be configured with multiple , each for
a different as needed.  If the goal is to support a large number of ,
might be provided with a URI template TEMPLATE, from which multiple
could be constructed.
Oblivious HTTP might be incompatible with network interception
regimes, such as those that rely on configuring with trust anchors
and intercepting TLS connections.  While TLS might be intercepted
successfully, interception middleboxes devices might not receive
updates that would allow Oblivious HTTP to be correctly identified
using the media types defined in iana-req and iana-res.
Oblivious HTTP has a simple key management design that is not
trivially altered to enable interception by intermediaries.  that are
configured to enable interception might choose to disable Oblivious
HTTP in order to ensure that content is accessible to middleboxes.
The encrypted payload of an OHTTP request and response is a binary
HTTP message BINARY.  and target 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.
The "application/ohttp-keys" media type identifies a key
configuration used by Oblivious HTTP.
The "application/ohttp-keys" media type identifies a used by
Oblivious HTTP.