Draft: draft-ietf-ohai-ohttp

Commentary: Split out from , since the shadowban bit needs more consideration in relation to target - proxy signals like rate limits . cc 
 We could list examples , but it would be a non - exhaustive list that might end up harming more than helping , so I 'm inclined to omit that for now . 
 Something that came up during Vienna during the rate limiting topic is how these signals are consumed and acted upon by proxies . We know that the proxy sending additional bits per client might allow the target to partition the anonymity set to detrimental effect . But we have n't fully explored how target - proxy signals , like rate limits , are consumed and applied . Generally speaking , I think that proxies need to act on any target - proxy signals independently of client requests , as otherwise a target can use this signal to try and partition the anonymity set . That means , for example , that a proxy should not apply rate limits to just one bad - behaving client , but apply limits uniformly across all client requests . 
 Do you mean the oblivious request resource -oblivious proxy resource hop ? The target ca n't communicate with the proxy ; anything it sends is encapsulated ( which is why  wanted a new header field that breaks out of that encapsulation ) . The most obvious example ( see ) is that a particular request is identified as abusive somehow . Letting the proxy know , so that it might treat that client differently , is the entire goal of that process . And I do n't think that there is any inherent risk of that being tied to an individual request . Though I think that this is unlike the CDN reputation case where a set of attributes is forwarded along with a request ; the goal here is to have the proxy do the extra work of offloading requests by blocking or slowing them . I guess that slowing requests might have an observable effect through the timestamps . There is a second piece , which is not request - related . A server might become overloaded and need to tell the proxy to slow down in the aggregate . A holistic signal makes sense there . 
 Surely the target can communicate with the proxy -- it just adds a header , just like  did . Yes , I understand the goal , but I 'm saying that goals runs contrary to the competing privacy goal of OHTTP , which is to maintain client < request unlinkability . As a simple example , consider the following scenario . There are three clients C1 , C2 , and  sending requests to a target through a proxy in rounds . In each round , the target can guess which request corresponds to which client with some probability . Absent any information about the client , the target guesses correctly with probability 1/3 . Now let 's assume the proxy flags one request from one client  in round j with the shadowban bit . The target , in response , decides it 's going to apply some rate limit or otherwise ask the proxy to treat the client differently . And let 's say it does that by banning  from sending a request in round j+1 . Now , in round j+1 , the target sees only two requests . If all requests were unlinkable , the probability that the target could correctly guess the client for each request in j+1 and j would be 1/9 (= 1/3 * 1/3 ) . But that 's not the case anymore , since the target knows the requests in   to the unflagged requests in round j. This is all pretty farfetched , but I think the core idea is simply that the proxy allowed the target to partition the anonymity set by applying per - client actions at request of the target . Balancing abuse and privacy here seems pretty challenging . 
 The response from the target will be encapsulated , so new headers will be hidden from the proxy . What  was suggesting was that we teach the response resource to recognize a header that is not encapsulated , but copied to the outer envelope instead . Is n't this exactly the sort of thing that we 're warning about when we say that every bit can split the client population in half ? That speaks to a similar restriction on per - response entropy as exists on requests . The question whether this is orthogonal ( and additive ) or correlated ( and therefore not able to divide the client population again ) . 
 Yes , I 'm saying this header is not encapsulated . Well , sort of . Perhaps restricting per - response entropy will help , but I think this needs more analysis . In any case , if the proxy does not treat client requests independently of what information it learns from the target , then things start becoming correlated . I 'd prefer we not just overlook this relationship as we reason about ( a ) what information proxies ( and targets ) can send to targets ( and proxies , respectively ) , and ( b ) how the recipient of that entity uses the information . As of now , I think applying per - client restrictions to requests upon being signaled from the target is harmful ( see scenario described above ) . 
 We updated draft - rdb - ohai - feedback - to - proxy to handle both server overload and malicious clients attacking the server scenarios . The latter case is tricky as it can be potentially abused to identify a client . We proposed the following changes to address this attack : 1 : Indicates that RateLimit fields are applicable to all the clients that are serviced by the same Oblivious proxy . 2 : Indicates that RateLimit fields are applicable only to the offending client . For example , this value is used if the client is attacking the server ( e.g. , the client is using an abnormal header that matches an attack pattern ) . The Oblivious proxy can shadowban requests from the offending client for a certain duration instead of rate - limiting the requests when the client has a high ratio of malicious requests to legitimate requests . 
 The second value of the " ohttp - target " parameter seems to be the problematic case here , as described earlier in this issue . do you think it 's safe ( from a client privacy perspective ) for the proxy to change its behavior on a per - client basis ? 
 Yes , the second value can be potentially abused by the target . However , the proxy does not immediately act on the second value to rate - limit the traffic from the client but starts maintaining a count of responses to the client with " ohttp - target " parameter set to 2 ( potential malcious - requests ) and responses without the parameter ( legitimate - requests ) . If the client has a high ratio of malicous - requests to legitimate - requests , it can shadow requests from the offending client for certain duration . A typical botnet attacking the server would not send a single malicious request but multiple requests from the same client and from multiple clients to overload the server . The target has no clue if the requests are coming from the same client or different clients and the proxy is using the second value only as a hint to determine the client reputation score and act accordingly at a later time . Do you think the proposed mechanism is safe to protect the client privacy or it can possibly be abused by the target ? 
 So I 'm seeing some fairly positive things in the new version of the feedback draft . What I think we should do is first take this discussion to the mailing list , but then talk about whether just providing rate limiting signals is the right approach or whether a more generic communication path needs to be established . Rate limiting does allow us to address a good number of the use cases we have identified so far , but it could be constraining if we find that request resources need to be updated piecemeal to enable new use cases later . A more generic signaling scheme might relieve some of that pressure . It might be that all we need is a negotiation system whereby the request resource signals what it is willing to keep outside of encapsulation and the target then uses those . Given likely deployment scenarios , that might work even without signaling in some cases , but a more explicit scheme might be better for interoperability . 
 No , I do n't , as . I do n't think the question is whether rate limits are sufficient for the use cases we care about . As described , the relevant question here seems to be whether the signals from target to proxy -- whatever they may be , and however they may be sent -- can be used to further partition the client anonymity set . 
 Fair . So what does a system that looks good look like ? Do we have to frame differential treatment in terms of things that the client accepts , just like we do for information ? Because we might frame differential treatment as being roughly equated to adding information to requests . 
 This would be a reasonable framing , yeah . Something something " if you misuse this proxy , you run the risk of revealing information to the target " ? 
 In your example of three clients , the proxy does not rate - limit the requests from client C1 based on a single feedback from proxy . The proxy will block traffic from C1 only after it sees such a feedback signal for multiple requests from C1 . Assuming the threshold is 10 requests , the probability score will be ( 0 . ) to send successive 10 feedback signals to C1 . The mechanism only works if the target sees an attack pattern or garbage data in multiple requests from C1 . An legitimate client will never send requests which are linkable unlike a malicious client which will send malformed requests . 
 Well , this is different from the example I proposed . Nevertheless , I 'm not convinced this changes the situation in any meaningful way . I think we need to be clear about the risks here , and stating them in a way like proposed seems like a good way to do that . 
 Agreed , I was trying to show the proposed mechanism does not adversely impact the privacy of legitimate clients . 
 Sounds good , we can introduce a new header ( e.g. , h = header1 : header2 :  ) for the request resource to signal that it will keep header1 , header2 and  outside of the encapsulation so the target can decide to use those headers . RateLimit - Limit can be one of the headers to start with . 
 Sorry , but I do n't think this is true . I 'm saying that we 've not demonstrated this to be the case , and the burden is on us to do so if we are to recommend it in the spec . 
 Sure , the onus will anyway be on draft - rdb - ohai - feedback - to - proxy to prove it is privacy preserving . 
 The text says : This seems perhaps too strong . One might imagine wanting to for instance indicate the geographic location of the client at some broad granularity . More generally , the client depends on correct proxy behavior and obviously this MUST does n't guarantee actual compliance , so perhaps we should just remove the MUST in favor of a description of the implications of various choices . See also issue 
 The draft currently says " The oblivious proxy resource MUST NOT add information about the client to this request " . While identifying information would obviously defeat the whole point of OHTTP , it would be useful for the proxy to add some headers that would help the server with abuse mitigation while not revealing identity . For a simple example , the proxy ( which is IP address - aware ) could add an header if it sees a request from a known abusive IP address and then forward that to the server . The server could then use that signal + the contents of the request to determine what to do with the data ( if it 's telemetry , then it could choose not to count it ) . This would also be useful for shadowbanning clients , in which case you do n't want the proxy to just outright reject the request . Importantly , the server does n't come to know anything about the client other than the fact that the proxy thinks it is abusive ( which does n't split the anonymity set by too much ) . 
 This is a reasonable thing to do . The question is how we can best frame this . Implementing shadow bans by flagging requests seems like a good way to manage some aspects of this , but unbounded use of similar mechanisms could partition users too finely . We should talk about this in a working group to understand it more completely . 
 let 's throw this one on the agenda for 113 . 
 As discussed in the OHAI discussion on ohai - oblivious - proxy - feedback , the general issue seems to be dealing with abuse in a privacy - preserving manner . It seems like the approaches are proxy - requestresource ( eg , a client reputation bit ) and a private requestresource - proxy channels ( eg , this request may want to degrade client reputation ) channel . Rate - limiting on the proxy is just one way to deal with bad reputation . For requestresource - proxy it might be reasonable to have more than one bit ( such as either a few bits of badness - level , or perhaps a vector indicating nature - of - badness which might include things like " this request was expensive " , " this request may have been malicious ( eg , triggered a WAF rule ) " , etc ) . Proxies could potentially rate - limit clients that have a high ratio of responses " suspicious " responses to non - suspicious responses . Proxies might also use some mixture of reputation information to inform what they send to the requestresource . Note that at least some CDN services doing client reputation tend to have a vector of reputations , and this blurs into the " demographic " topic . Having a single bit might not be good enough to make good decisions in a fair manner . It may be worth enumerating some use - cases ( rate - limiting against DDoS attacks against a target , dealing with abusive clients / bots with bad reputation , etc ) and to explore the design - space before jumping to a particular implementation . 
 does address this ? 
 Closing now that has been merged . feel free to reopen if more changes are desired . 
 WFM
An HTTP request that is encapsulated in an HPKE-encrypted message;
see request.
An HTTP response that is encapsulated in an HPKE-encrypted
message; see response.
An intermediary that forwards requests and responses between
clients and a single oblivious request resource.
A resource that can receive an encapsulated request, extract the
contents of that request, forward it to an oblivious target
resource, receive a response, encapsulate that response, then
return that response.
The resource that is the target of an encapsulated request.  This
resource logically handles only regular HTTP requests and
responses and so might be ignorant of the use of oblivious HTTP to
reach it.
The Nenc parameter corresponding to the HpkeKdfId can be found in
Section 7.1 of HPKE.
The oblivious proxy resource interacts with the oblivious request
resource as an HTTP client by constructing a request using the same
restrictions as the client request, except that the target URI is the
oblivious request resource.  The content of this request is copied
from the client.  The oblivious proxy resource MUST NOT add
information to the request without the client being aware of the type
of information that might be added; see proxy-responsibilities for
more information on proxy responsibilities.
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.
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 when
forwarding requests that might be used to identify clients, with the
exception of information that a client is aware of.
A proxy MAY add information to requests if the client is aware of the
nature of the information that could be added.  The client does not
need to be aware of the exact value added for each request, but needs
to know the range of possible values the proxy might use.  It is
important to note that information added by the proxy can reduce the
size of the anonymity set of clients at a server.
The anti-replay mechanisms described in Section 8 of TLS are
generally applicable to oblivious HTTP requests.  The encapsulated
keying material (or "enc") can be used in place of a nonce to
uniquely identify a request.  This value is a high-entropy value that
is freshly generated for every request, so two valid requests will
have different values with overwhelming probability.
The anti-replay mechanisms described in TLS are generally applicable
to oblivious HTTP requests.  The encapsulated keying material (or
"enc") can be used in place of a nonce to uniquely identify a
request.  This value is a high-entropy value that is freshly
generated for every request, so two valid requests will have
different values with overwhelming probability.
A server can maintain state for requests for a small window of time
over which it wishes to accept requests.  The server then rejects
requests if the request is the same as one that was previously
answered within that time window.  Servers can reject requests
outside of this window and signal that clients might retry with a
different "Date" header field; see Section 4 of REQUEST-DATE.
Servers can identify duplicate requests using the encapsulation
("enc") value.
REQUEST-DATE contains further considerations for the use of the
"Date" request header field.  This includes the way in which clients
might correct for clock skew and the privacy considerations arising
from that usage.  Servers that reject requests on the basis of the
"Date" request header field SHOULD implement the feedback mechanism
in Section 4 of REQUEST-DATE to support clock correction by clients.