Draft: draft-ietf-ohai-ohttp

Commentary: This change tries to emphasize that OHTTP is a protocol between client , relay , and gateway , and that the target is sort of ancillary to the whole thing . It further clarifies that the relay should not act as an open proxy when it 's operated by an entity that is separate from the target server . 
 This works for me . We can merge this and then I want to take another pass at the other PR.Thanks -- couple nits , otherwise lgtm . LGTM
To overcome these limitations, this document defines how binary HTTP
messages BINARY can be encapsulated using Hybrid Public Key
Encryption (HPKE; HPKE) to protect their contents.  exchange these
messages with an , which is responsible for forwarding decapsulated
requests to the original and encapsulating the corresponding
responses and sending them back to the client.  Critically,
encapsulated messages are sent through a separate to avoid exposing
the client's IP address or allowing the connection to be used as a
correlator between its requests.
Because it allows connection reuse between the client and , as well
as between that relay and the , this scheme represents a performance
improvement over using 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.
an algorithm for encapsulating binary HTTP messages BINARY using
Hybrid Public Key Encryption (HPKE; HPKE) to protect their
contents,
requirements for how the handles encapsulated HTTP messages and
produces encapsulated responses for the client.
The combination of encapsulation and relaying ensures that never sees
the client's IP address and the never sees plaintext HTTP message
content.
Oblivious HTTP allows connection reuse between the client and , as
well as between that relay and the , so this scheme represents a
performance improvement over using 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.
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.
This information allows the to send HTTP requests to the for
forwarding to a .  The does not learn the client's IP address or any
other identifying information that might be revealed from the client
at the transport layer, nor does the learn which of the requests it
receives are from the same .
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.
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit
from being able to carry state between requests, such as with cookies
(COOKIES), authentication (HTTP), or even alternative services
(RFC7838).  Oblivious HTTP removes linkage at the transport layer,
which is only useful for an application that does not carry state
between requests.
This interaction provides authentication and confidentiality
protection between the and the Oblivious Gateway, but importantly not
between the and the . While the is a distinct HTTP resource from the
, they are both logically under the control of the Oblivious Gateway,
since the can unilaterally dictate the responses returned from the to
the . This arrangement is shown in fig-overview.  See security for
more information about and Oblivious Relay, and Oblivous Gateway
resources in running this protocol.
Oblivious HTTP has limited applicability.  Imporantly, it requires
expicit support from a willing and , thereby limiting the use of
Oblivious HTTP for generic applications; see server-responsibilities
for more information.
Many uses of HTTP benefit from being able to carry state between
requests, such as with cookies (COOKIES), authentication (HTTP), or
even alternative services (RFC7838).  Oblivious HTTP removes linkage
at the transport layer, which is only useful for an application that
does not carry state between requests.
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 knows the origin and
destination of an and Response, yet does not know the decrypted
contents.  Likewise, learn 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.
Requests and responses are known only to and .  In particular, the
knows the origin and destination of an and Response, yet does not
know the decrypted contents.  Likewise, learn only the and the
decrypted request.  No entity other than the can see the plaintext
request and response and can attribute them to the .
Oblivous Gateway Resources, and therefore Target Resources, cannot
link requests from the same in the absence of unique per- keys.
Because do not authenticate the when using Oblivious HTTP, MUST
maintain an explicit allowlist of target resources that the trusts an
Oblivious Gateway to respond for, and check requests against this
allowlist before sending them.  This ensures that are not abused to
forward traffic to arbitrary Target Resources.  See server-
responsibilities for similar responsibilities that apply to .
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.
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.  Moreover, the SHOULD apply some form of
allowlist to ensure that the is not misused as a relay for HTTP
messages to an arbitrary .