jiebi/CodeConvo huggingface dataset:
Code change:
This seems fine to me, but doesn't seem to include URL
NAME 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 NAME alluded to.
Let'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. Now it rotates and public key B is valid as of 2022-07-03. X encapsulated using pubkey A would not be decryptable by pubkey B. 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. "Don'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 don'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.

Related discussion:
text: 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 <del> 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 </del> <ins> 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 </ins> size of the anonymity set of clients at a gateway. Moreover, relays MAY apply differential treatment to clients that
Code change:
This seems fine to me, but doesn't seem to include URL
NAME 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 NAME alluded to.
Let'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. Now it rotates and public key B is valid as of 2022-07-03. X encapsulated using pubkey A would not be decryptable by pubkey B. 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. "Don'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 don'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.

Related discussion:
text: 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. <del> A relay that acts on this feedback could - either inadvertently or by design - lead to clients being deanonymized. </del> <ins> 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. </ins> 7.2.2.
Code change:
Section 5 details HTTP usage. It seems it's technically correct but the section closes with a sequence of paragraphs that jump back and forth between statements about how an Oblivious Gateway Resource treats requests or responses. Perhaps these could be consolidated to present requests first consistently. I.e. swap the final two paragraphs around

Related discussion:
text: Oblivious Relay Resource also needs to observe the guidance in relay- responsibilities. <ins> An Oblivious Gateway Resource acts as a gateway for requests to the Target Resource (see HTTP).  The one exception is that any information it might forward in a response MUST be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </ins> An Oblivious Gateway Resource, if it receives any response from the Target Resource, sends a single 200 response containing the encapsulated response.  Like the request from the client, this
Code change:
Section 5 details HTTP usage. It seems it's technically correct but the section closes with a sequence of paragraphs that jump back and forth between statements about how an Oblivious Gateway Resource treats requests or responses. Perhaps these could be consolidated to present requests first consistently. I.e. swap the final two paragraphs around

Related discussion:
text: information that does not reveal information about the encapsulated response. <del> An Oblivious Gateway Resource acts as a gateway for requests to the Target Resource (see HTTP).  The one exception is that any information it might forward in a response MUST be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </del> In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities.
Code change:
We debated this at some length. This defines an optional-to-use signaling method for the gateway so that it can inform the client when the key configuration is not acceptable. Clients can use this as a prompt to refresh their configuration.
(Originally posted by NAME in URL): Any lifetime information that comes with a key is helpful, but in practice is insufficient for clients to drive key updates. Key rotation may not occur on a fixed schedule and it may not occur synchronously (some gateway instances might not get the key at the right time. This means that clients cannot distinguish between failures due to configuration mismatch or request tampering (or whatever else might cause the gateway to reply without an encapsulated response). If the client can't distinguish then the client's recovery implementation is a lot more complicated. Does it always try to forcibly update its configuration? Does it implement some sort of backoff? Can a relay abuse the client's recovery implementation to somehow put the client into a state where it is stuck with an old configuration? It seems vastly simpler to just be clear that the configuration is wrong as a signal to the client that it's time to update. This was done in ODoH with a 401 response code. proposed a new problem statement, which I think is the right way to deal with this. Yes, there are potential privacy problems based on automated updates, but those depend on the client's consistency story and is therefore not something new a signal would introduce.
This looks great -- thanks!

Related discussion:
text: indicate that the client configuration used to construct the request is incorrect or out of date. <ins> 5.3. The problem type PROBLEM of "https://iana.org/assignments/http- problem-types#ohttp-key" is defined.  An MAY use this problem type in a response to indicate that an used an outdated or incorrect . fig-key-problem shows an example response in HTTP/1.1 format. As this response cannot be encrypted, it might not reach the .  A cannot rely on the using this problem type.  A might also be configured to disregard responses that are not encapsulated on the basis that they might be subject to observation or modification by an .  A might manage the risk of an outdated using a heuristic approach whereby it periodically refreshes its if it receives a response with an error status code that has not been encapsulated. </ins> 6. In this design, a wishes to make a request of a server that is
Code change:
We debated this at some length. This defines an optional-to-use signaling method for the gateway so that it can inform the client when the key configuration is not acceptable. Clients can use this as a prompt to refresh their configuration.
(Originally posted by NAME in URL): Any lifetime information that comes with a key is helpful, but in practice is insufficient for clients to drive key updates. Key rotation may not occur on a fixed schedule and it may not occur synchronously (some gateway instances might not get the key at the right time. This means that clients cannot distinguish between failures due to configuration mismatch or request tampering (or whatever else might cause the gateway to reply without an encapsulated response). If the client can't distinguish then the client's recovery implementation is a lot more complicated. Does it always try to forcibly update its configuration? Does it implement some sort of backoff? Can a relay abuse the client's recovery implementation to somehow put the client into a state where it is stuck with an old configuration? It seems vastly simpler to just be clear that the configuration is wrong as a signal to the client that it's time to update. This was done in ODoH with a 401 response code. proposed a new problem statement, which I think is the right way to deal with this. Yes, there are potential privacy problems based on automated updates, but those depend on the client's consistency story and is therefore not something new a signal would introduce.
This looks great -- thanks!

Related discussion:
text: 9. Please update the "Media Types" registry at <del> https://www.iana.org/assignments/media-types [1] for the media types </del> <ins> https://iana.org/assignments/media-types [1] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). <ins> Please update the "HTTP Problem Types" registry at https://iana.org/assignments/http-problem-types [2] for the types "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). </ins> 9.1. The "application/ohttp-keys" media type identifies a used by
Code change:
We debated this at some length. This defines an optional-to-use signaling method for the gateway so that it can inform the client when the key configuration is not acceptable. Clients can use this as a prompt to refresh their configuration.
(Originally posted by NAME in URL): Any lifetime information that comes with a key is helpful, but in practice is insufficient for clients to drive key updates. Key rotation may not occur on a fixed schedule and it may not occur synchronously (some gateway instances might not get the key at the right time. This means that clients cannot distinguish between failures due to configuration mismatch or request tampering (or whatever else might cause the gateway to reply without an encapsulated response). If the client can't distinguish then the client's recovery implementation is a lot more complicated. Does it always try to forcibly update its configuration? Does it implement some sort of backoff? Can a relay abuse the client's recovery implementation to somehow put the client into a state where it is stuck with an old configuration? It seems vastly simpler to just be clear that the configuration is wrong as a signal to the client that it's time to update. This was done in ODoH with a 401 response code. proposed a new problem statement, which I think is the right way to deal with this. Yes, there are potential privacy problems based on automated updates, but those depend on the client's consistency story and is therefore not something new a signal would introduce.
This looks great -- thanks!

Related discussion:
text: IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. <ins> 9.5. IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. </ins> 10.  References 10.1.  URIs <del> [1] https://www.iana.org/assignments/media-types </del> <ins> [1] https://iana.org/assignments/media-types [2] https://iana.org/assignments/http-problem-types </ins> Index
Code change:
From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.

Related discussion:
text: constructing and processing an . The Nenc parameter corresponding to the KEM used in HPKE can be found <del> in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </del> <ins> in HPKE or the HPKE KEM IANA registry [1].  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </ins> 4.2.
Code change:
From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.

Related discussion:
text: constructing and processing an . The Nn and Nk values correspond to parameters of the AEAD used in <del> HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </del> <ins> HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [2]. Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </ins> 4.3.
Code change:
From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.

Related discussion:
text: 9. Please update the "Media Types" registry at <del> https://iana.org/assignments/media-types [1] for the media types </del> <ins> https://iana.org/assignments/media-types [3] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). Please update the "HTTP Problem Types" registry at <del> https://iana.org/assignments/http-problem-types [2] for the types </del> <ins> https://iana.org/assignments/http-problem-types [4] for the types </ins> "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). 9.1.
Code change:
From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.

Related discussion:
text: 10.1.  URIs <del> [1] https://iana.org/assignments/media-types </del> <ins> [1] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids </ins> <del> [2] https://iana.org/assignments/http-problem-types </del> <ins> [2] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids [3] https://iana.org/assignments/media-types [4] https://iana.org/assignments/http-problem-types </ins> Index
Code change:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Related discussion:
text: identified by "aead_id". The then constructs an , "enc_request", from a binary encoded HTTP <del> request, "request", as follows: </del> <ins> request BINARY, "request", as follows: </ins> Construct a message header, "hdr", by concatenating the values of "key_id", "kem_id", "kdf_id", and "aead_id", as one 8-bit integer
Code change:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Related discussion:
text: bhttp request", a zero byte, "key_id" as an 8-bit integer, plus "kem_id", "kdf_id", and "aead_id" as three 16-bit integers. <del> Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info".  This produces a context "rctxt". </del> <ins> Create a receiving HPKE context, "rctxt", by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info". </ins> Decrypt "ct" by invoking the "Open()" method on "rctxt" (HPKE), with an empty associated data "aad", yielding "request" or an
Code change:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Related discussion:
text: In pseudocode, this procedure is as follows: <ins> The retains the HPKE context, "rctxt", so that it can encapsulate a response. </ins> 4.4. <del> Given an HPKE context, "context"; a request message, "request"; and a response, "response", generate an , "enc_response", as follows: </del> <ins> generate an , "enc_response", from a binary encoded HTTP response BINARY, "response".  The uses the HPKE receiver context, "rctxt", as the HPKE context, "context", as follows: </ins> Export a secret, "secret", from "context", using the string "message/bhttp response" as the "exporter_context" parameter to
Code change:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Related discussion:
text: In pseudocode, this procedure is as follows: <del> decrypt an by reversing this process.  That is, they first parse </del> <ins> decrypt an by reversing this process.  That is, first parse </ins> "enc_response" into "response_nonce" and "ct".  They then follow the <del> same process to derive values for "aead_key" and "aead_nonce". </del> <ins> same process to derive values for "aead_key" and "aead_nonce", using their sending HPKE context, "sctxt", as the HPKE context, "context". </ins> The uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows:
Code change:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Related discussion:
text: respectively. In order to achieve the privacy and security goals of the protocol a <del> also needs to observe the guidance in client-responsibilities. </del> <ins> also needs to observe the guidance in sec-client. </ins> The interacts with the as an HTTP client by constructing a request using the same restrictions as the request, except that the target
Code change:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Related discussion:
text: requests over time.  However, this increases the risk that their request is rejected as outside the acceptable window. <ins> 6.9. The media type defined in ohttp-keys represents keying material.  The content of this media type is not active (see RFC6838), but it governs how a might interact with an .  The security implications of processing it are described in sec-client; privacy implications are described in privacy. The security implications of handling the message media types defined in req-res-media is covered in other parts of this section in more detail.  However, these message media types are also encrypted encapsulations of HTTP requests and responses. HTTP messages contain content, which can use any media type.  In particular, requests are processed by an Oblivious , which - as an HTTP resource - defines how content is processed; see HTTP.  HTTP clients can also use resource identity and response content to determine how content is processed.  Consequently, the security considerations of HTTP also apply to the handling of the content of these media types. </ins> 7. One goal of this design is that independent requests are only
Code change:
Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.

Related discussion:
text: Please update the "Media Types" registry at https://iana.org/assignments/media-types [2] for the media types "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), <del> and "message/ohttp-res" (iana-res). </del> <ins> and "message/ohttp-res" (iana-res), following the procedures of RFC6838. </ins> Please update the "HTTP Problem Types" registry at https://iana.org/assignments/http-problem-types [3] for the types