Change:
1. <del> Words... </del> <ins> 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. </ins> This document describes a method of encapsulation for binary HTTP messages BINARY using Hybrid Public Key Encryption (HPKE; HPKE). <ins> 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. </ins> 2.

Discussion:
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 can'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).