Draft: draft-thomson-http-oblivious

Commentary: A first cut at the intro and the text describing how different entities might think about each other . After all this , I 'm running short on stuff that might go in security considerations . Maybe we should move this new text there so that the security people can find what they need under a familiar heading . 
 This also needs to talk about how different entities might authenticate others that are involved in order to back that trust with something more concrete . Spamming / DoS : request resources trust proxy resources not to pass on spam ; same for target resources and request resources . A request resource might want to authenticate a proxy resource so that they can limit the proxies they accept . A target resource might do the same to request resources , but a more plausible deployment model is those two being the same entity ( something that you ca n't have with proxy / request ) . Information protection : clients trust proxy resources not to give their information to request resources . That is , not their IP address , nor any strong indication that two requests come from the same entity . ( We have seen cases where people think this might be required for anti - abuse , but I think that ignores the spamming / DoS relationship to the detriment of user privacy . This might be a fun discussion . ) 
 We need to explain the advantages of this over making a new connection via a proxy for every request . That is largely performance - related : TLS costs a lot more than this does , both in terms of round trips ( 1 extra ) , in terms of bytes exchanged ( waaay more ) , and in terms of CPU cycles spent doing crypto ( 2x at least ) .
Words...
This document describes a method of encapsulation for binary HTTP
messages BINARY using Hybrid Public Key Encryption (HPKE; HPKE).
The act of making a request using HTTP reveals information about the
client identity to a server.  Though the content of requests might
reveal information, that is information under the control of the
client.  In comparison, the source address on the connection reveals
information that a client has only limited control over.
Even where an IP address is not directly attributed to an individual,
the use of an address over time can be used to correlate requests.
Servers are able to use this information to assemble profiles of
client behavior, from which they can make inferences about the people
involved.  The use of persistent connections to make multiple
requests improves performance, but provides servers with additional
certainty about the identity of clients in a similar fashion.
Use of an HTTP proxy can provide a degree of protection against
servers correlating requests.  Systems like virtual private networks
or the Tor network Dingledine2004, provide other options for clients.
Though the overhead imposed by these methods varies, the cost for
each request is significant.  Preventing request linkability requires
that each request use a completely new TLS connection to the server.
At a minimum, this requires an additional round trip to the server in
addition to that required by the request.  In addition to having high
latency, there are significant secondary costs, both in terms of the
number of additional bytes exchanged and the CPU cost of
cryptographic computations.
This document describes a method of encapsulation for binary HTTP
messages BINARY using Hybrid Public Key Encryption (HPKE; HPKE).
This protects the content of both requests and responses and enables
a deployment architecture that can separate the identity of a
requester from the request.
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 trust), clients are assured
that requests are not uniquely attributed to them or linked to other
requests.
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 proxy (that serves the
oblivious proxy resource) that it trusts will protect this
information by forwarding the encapsulated request and response
without passing 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.
Clients have the fewest direct responsibilities, though clients do
need to ensure that they do not undermine the process.
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 also need to ensure that they correctly generate a new HPKE
context for every request, using a good source of entropy (RANDOM).
Key reuse not only risks linkability, but it could expose request and
response contents to the proxy.
Clients constructing the request that is to be encapsulated need to
avoid including identifying information.  Similarly, the request that
is sent to the oblivious request resource, though this request can
contain only minimal information as it only needs to include a method
and the oblivious request resource URL.
The proxy that serves the oblivious proxy resource has a very simple
function to perform.  It forwards messages received at this resource
to the oblivious request resource, and forwards responses from the
oblivious request resource back to clients.  The proxy MUST forward
response status codes without modification.
The 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.
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 does accept a large 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 similar rate limiting when receiving
requests from clients.
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.
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 what some clients want.
A proxy can use padding to reduce the effectiveness of traffic
analysis.
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.
Servers should account for traffic analysis based on response size or
generation time.  Techniques such as padding or timing delays can
help protect against such attacks; see ta.
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.