Draft: draft-ietf-ohai-ohttp

Commentary: Let 's be clearer about what it means to proxy here . Also , since it is the same text , talk about TLS assumptions more directly . This will interact poorly with . Sorry about that 
 From Vienna chat . A proxy is not a generic HTTP intermediary , and therefore is not subject to the same rules . 
 From Generic proxies would forward unknown HTTP headers between clients and targets . We should be very clear that oblivious proxies are not generic , and should not be doing things like forwarding unknown headers arbitrarily between client and target , or target and client . 
 requests . This includes the Via field , the Forwarded field { { ? FORWARDED = RFC7239 } } , and any similar information . A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource , only that information about the client not be attached to forwarded requests . Obviously , you need encryption on one or the other side of the proxy , right ? Probably this document should require it on the inbound side , but I do n't see the text that requires it . Did I just miss it ? 
 Yeah , it 's only necessary on the inbound side , per the analysis , though the document assumes it 's on both sides .
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.  When generating a request, the proxy MUST follow
the forwarding rules in Section 7.6 of HTTP.
A proxy MUST NOT add information about the client identity when
forwarding requests.  This includes the Via field, the Forwarded
field FORWARDED, and any similar information.  A client does not
depend on the proxy using an authenticated and encrypted connection
to the oblivious request resource, only that information about the
client not be attached to forwarded requests.
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.
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.
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
about the client identity when forwarding requests.
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.