Draft: draft-ietf-ohai-ohttp

Commentary: Is this what you had in mind 
 It seems like the glossary would be easier to read if Figure 1 was shown before , thus making the terms clearer . Happier to submit a PR if that would help
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit
from being able to carry state between requests, such as with cookies
(RFC6265), authentication (Section 11 of HTTP), or even alternative
services (RFC7838).  Oblivious HTTP removes linkage at the transport
layer, which must be used in conjunction with applications that do
not carry state between requests.
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit
from being able to carry state between requests, such as with cookies
(RFC6265), authentication (HTTP), or even alternative services
(RFC7838).  Oblivious HTTP removes linkage at the transport layer,
which must be used in conjunction with applications that do not carry
state between requests.
This document uses its own definition of client.  When referring
to the HTTP definition of client (Section 3.3 of HTTP), the term
"HTTP client" is used; see http-usage.
An HTTP request that is encapsulated in an HPKE-encrypted message;
see request.
An HTTP response that is encapsulated in an HPKE-encrypted
message; see response.
An intermediary that forwards requests and responses between
clients and a single oblivious request resource.
A resource that can receive an encapsulated request, extract the
contents of that request, forward it to an oblivious target
resource, receive a response, encapsulate that response, then
return that response.
The resource that is the target of an encapsulated request.  This
resource logically handles only regular HTTP requests and
responses and so might be ignorant of the use of oblivious HTTP to
reach it.
Formats are described using notation from Section 1.3 of QUIC.
Formats are described using notation from QUIC.
The Nenc parameter corresponding to the HpkeKdfId can be found in
Section 7.1 of HPKE.
The Nenc parameter corresponding to the HpkeKdfId can be found in
HPKE.
The client role in this protocol acts as an HTTP client both with
respect to the oblivious proxy 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 Section 3.3 of HTTP) in that the request and
response are encapsulated rather than sent over a connection.  The
oblivious proxy resource and the oblivious request resource also act
as HTTP clients toward the oblivious request resource and oblivious
target resource respectively.
The client role in this protocol acts as an HTTP client both with
respect to the oblivious proxy 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
encapsulated rather than sent over a connection.  The oblivious proxy
resource and the oblivious request resource also act as HTTP clients
toward the oblivious request resource and oblivious target resource
respectively.
When a response is received from the oblivious request resource, the
oblivious proxy resource forwards the response according to the rules
of an HTTP proxy; see Section 7.6 of HTTP.
When a response is received from the oblivious request resource, the
oblivious proxy resource forwards the response according to the rules
of an HTTP proxy; see HTTP.
An oblivious request resource acts as a gateway for requests to the
oblivious target resource (see Section 7.6 of 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 request 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.
Since clients connect directly to the proxy 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 (Section 9.3.6 of HTTP) can be
used.  Applications could implement related policies on key
configurations and proxy 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.
Since clients connect directly to the proxy 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 proxy
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.
When forwarding a request, the proxy MUST follow the forwarding rules
in Section 7.6 of HTTP.  A generic HTTP intermediary implementation
is suitable for the purposes of serving an oblivious proxy resource,
but additional care is needed to ensure that client privacy is
maintained.
When forwarding a request, the proxy MUST follow the forwarding rules
in HTTP.  A generic HTTP intermediary implementation is suitable for
the purposes of serving an oblivious proxy resource, but additional
care is needed to ensure that client privacy is maintained.
A proxy can use padding to reduce the effectiveness of traffic
analysis.  Padding is a capability provided by binary HTTP messages;
see Section 3.8 of BINARY.
A proxy can use padding to reduce the effectiveness of traffic
analysis.  Padding is a capability provided by binary HTTP messages;
see BINARY.
Encapsulated requests can be copied and replayed by the oblivious
proxy resource.  The threat model for oblivious HTTP allows the
possibility that an oblivious proxy resource might replay requests.
Furthermore, if a client sends an encapsulated request in TLS early
data (see Section 8 of 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.
Encapsulated requests can be copied and replayed by the oblivious
proxy resource.  The threat model for oblivious HTTP allows the
possibility that an oblivious proxy 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.
The anti-replay mechanisms described in Section 8 of TLS are
generally applicable to oblivious HTTP requests.  The encapsulated
keying material (or "enc") can be used in place of a nonce to
uniquely identify a request.  This value is a high-entropy value that
is freshly generated for every request, so two valid requests will
have different values with overwhelming probability.
The anti-replay mechanisms described in TLS are generally applicable
to oblivious HTTP requests.  The encapsulated keying material (or
"enc") can be used in place of a nonce to uniquely identify a
request.  This value is a high-entropy value that is freshly
generated for every request, so two valid requests will have
different values with overwhelming probability.
A server can maintain state for requests for a small window of time
over which it wishes to accept requests.  The server then rejects
requests if the request is the same as one that was previously
answered within that time window.  Servers can reject requests
outside of this window and signal that clients might retry with a
different "Date" header field; see Section 4 of REQUEST-DATE.
Servers can identify duplicate requests using the encapsulation
("enc") value.
A server can maintain state for requests for a small window of time
over which it wishes to accept requests.  The server then rejects
requests if the request is the same as one that was previously
answered within that time window.  Servers can reject requests
outside of this window and signal that clients might retry with a
different "Date" header field; see REQUEST-DATE.  Servers can
identify duplicate requests using the encapsulation ("enc") value.
REQUEST-DATE contains further considerations for the use of the
"Date" request header field.  This includes the way in which clients
might correct for clock skew and the privacy considerations arising
from that usage.  Servers that reject requests on the basis of the
"Date" request header field SHOULD implement the feedback mechanism
in Section 4 of REQUEST-DATE to support clock correction by clients.
REQUEST-DATE contains further considerations for the use of the
"Date" request header field.  This includes the way in which clients
might correct for clock skew and the privacy considerations arising
from that usage.  Servers that reject requests on the basis of the
"Date" request header field SHOULD implement the feedback mechanism
in REQUEST-DATE to support clock correction by clients.