Draft: draft-ietf-ohai-ohttp

Commentary: This seems fine to me , but does n't seem to include 
 after trying to work that text in it became clear ( to me ) that a better outcome was modify the existing text we have about anonymity set reduction . So I went with that approach rather than open the can of consistency worms that alluded to . 
 's say HPKE public key A was valid from 2022 - 07 - 01 to 2022 - 07 - 02 . The client encapsulates a request X using pubkey A , but buffers it because of network issues , in order to retry later . it rotates and public key B is valid as of 2022 - 07 - 03 . encapsulated using pubkey A would not be decryptable by pubkey  So if you receive X on 2022 - 07 - 03 , then you know that X was generated between 2022 - 07 - 01 and 2022 - 07 - 02 . 
 I 'm not inclined to add this . " Do n't do that " seems pretty obvious to me , especially when we recommend that requests include a Date . 
 While this advice seems fine , I agree that it 's not really necessary . It also brings up more questions to me — what stops any layer below the OHTTP layer or an intermediary from arbitrarily buffering messages ? Maybe just have a note that the key config that 's used as well as explicit date markings can leak the time that the request was generated ? 
 This seems like a reasonable way to deal with the problem . Liveness information can leak in a number of places , including through noting which public key was used . It might also leak via the date . Maybe this can become part of the differential treatment section ? 
 That sounds good to me 
 I think that while this text is true , I believe that it is also unnecessary . Discussion of key liveness are dealt with in the key - consistency draft , so this is really about requests that are transmitted well after they are constructed . If we start to document that , there are lots of other things that start to come up . 
 I agree , but the content I 'm proposing here relates to how liveness affects differential treatment . We 've already noted a few key ways in which this can happen , so it seems pretty harmless to me to include one more . I do n't think we need to say anything more about how to deal with liveness or how it pertains to consistency . I 'll propose some text to make this more clear . No more than one sentence .
A relay 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 relay might use.  It is
important to note that information added by the relay can reduce the
size of the anonymity set of clients at a gateway.
A relay 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 relay might use.
Importantly, information added by the relay - beyond what is already
revealed through encapsulated requests from clients - can reduce the
size of the anonymity set of clients at a gateway.
Some patterns of abuse cannot be detected without access to the
request that is made to the target.  This means that only the gateway
or target are in a position to identify abuse.  A gateway MAY send
signals toward the relay to provide feedback about specific requests.
A relay that acts on this feedback could - either inadvertently or by
design - lead to clients being deanonymized.
Some patterns of abuse cannot be detected without access to the
request that is made to the target.  This means that only the gateway
or target are in a position to identify abuse.  A gateway MAY send
signals toward the relay to provide feedback about specific requests.
For example, a gateway could respond differently to requests it
cannot decapsulate, as mentioned in errors.  A relay that acts on
this feedback could - either inadvertently or by design - lead to
client deanonymization.