Change:
5. <ins> In this design, a client wishes to make a request of a server that is authoritative for the oblivious target resource.  The client wishes to make this request without linking that request with either: 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). In this section, a deployment where there are three entities is considered: A client makes requests and receives responses A proxy operates the oblivious proxy resource A server operates both the oblivious request resource and the oblivious target 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. </ins> 5.1. <ins> 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. </ins> 5.2. <ins> 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. 5.2.1. 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. 5.2.2. 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. </ins> 5.3. <del> 5.4. </del> <ins> 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. </ins> 6.

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).