jiebi/CodeConvo huggingface dataset:
Change:
So add some forward references.
Sections 6.1, 6.2 and 6.3 detail normative requirements that seem to apply to the actors duties outlined in section 5. Consider forward references to each respective section to aid implementers in discovery applicable considerations.

Discussion:
Gateway Resource also act as HTTP clients toward the Oblivious Gateway Resource and Target Resource respectively. <ins> In order to achieve the privacy and security goals of the protocol a client also needs to observe the guidance in client-responsibilities. </ins> The Oblivious Relay Resource interacts with the Oblivious Gateway 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 Relay Resource forwards the response according to the rules of an HTTP proxy; see HTTP. <ins> In order to achieve the privacy and security goals of the protocol an Oblivious Relay Resource also needs to observe the guidance in relay- responsibilities. </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

unless it is responding to errors it detects before removing encapsulation of the request; see errors. <ins> 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. </ins> 5.1. This encapsulation does not permit progressive processing of
Change:
Especially when we already address this point a few paragraphs above and we then directly contradict it in the next one.
Currently, these normative references are to old document versions. We should link to RFC 9113 and 9114, and probably use the Use [HTTP/2] and [HTTP/3] labels for consistency with the HTTP style guide.

Discussion:
If separate entities provide the Oblivious Gateway Resource and Target Resource, these entities might need an arrangement similar to that between server and relay for managing denial of service; see <del> dos.  It is also necessary to provide confidentiality protection for the unprotected requests and responses, plus protections for traffic analysis; see ta. </del> <ins> dos. </ins> Nonsecure requests - such those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and
Change:
This would have been easier had I not forgotten how to do this.
Does this ref need to be normative?
oh, it seems this relates to a the registration of buried down in Section 10.2. Is this still valid?
Yes it is, though I realize that we also buried the IANA considerations a little too deep.
Currently, these normative references are to old document versions. We should link to RFC 9113 and 9114, and probably use the Use [HTTP/2] and [HTTP/3] labels for consistency with the HTTP style guide.

Discussion:
A client or Oblivious Relay Resource MUST NOT automatically attempt to retry a failed request unless it receives a positive signal indicating that the request was not processed or forwarded.  The <del> HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of RFC7540), the HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of QUIC-HTTP), or a GOAWAY frame with a low enough identifier (in either protocol version) are all sufficient signals that no processing occurred. Connection failures or interruptions are not sufficient signals that no processing occurred. </del> <ins> HTTP/2 REFUSED_STREAM error code (HTTP2), the HTTP/3 H3_REQUEST_REJECTED error code (HTTP3), or a GOAWAY frame with a low enough identifier (in either protocol version) are all sufficient signals that no processing occurred.  Connection failures or interruptions are not sufficient signals that no processing occurred. </ins> The anti-replay mechanisms described in TLS are generally applicable to Oblivious HTTP requests.  The encapsulated keying material (or

The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response. <ins> 10.4. </ins> IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM.
Change:
In Deployment Considerations / Performance Overhead... Should that be "cryptographic" -> "cryptographic complexity" or something like that?
It should probably be "cryptographic overhead." Nice catch!

Discussion:
8.1. <del> Using Oblivious HTTP adds both cryptographic and latency to requests relative to a simple HTTP request-response exchange.  Deploying relay services that are on path between clients and servers avoids adding significant additional delay due to network topology.  A study of a similar system ODoH found that deploying proxies close to servers was most effective in minimizing additional latency. </del> <ins> Using Oblivious HTTP adds both cryptographic overhead and latency to requests relative to a simple HTTP request-response exchange. Deploying relay services that are on path between clients and servers avoids adding significant additional delay due to network topology. A study of a similar system ODoH found that deploying proxies close to servers was most effective in minimizing additional latency. </ins> 8.2.
Change:
This was the only case we used the TLS-style dot notation, but we don't need to pull in a new concept.

Discussion:
successfully use it for interacting with with a target. Oblivious Relay and Gateway Resources can identify when requests use <del> the same configuration by matching "KeyConfig.key_id" or the Oblivious Gateway Resource URI.  The Oblivious Gateway Resource might use the source address of requests to correlate requests that use an Oblivious Relay Resource run by the same operator.  If the Oblivious Gateway Resource is willing to use trial decryption, requests can be further separated into smaller groupings based on the keys that are used. </del> <ins> the same configuration by matching the key ID from the key configuration or the Oblivious Gateway Resource URI.  The Oblivious Gateway Resource might use the source address of requests to correlate requests that use an Oblivious Relay Resource run by the same operator.  If the Oblivious Gateway Resource is willing to use trial decryption, requests can be further separated into smaller groupings based on the keys that are used. </ins> Each active client configuration partitions the client anonymity set. In practice, it is infeasible to reduce the number of active
Change:
RFC 9180 does use skR/pkR/skS/skR, so I didn't change everything to use snake_case, but this is more consistent with how we identify things in other places. Also, it reads better and we don't have to grapple with whether it should be keyId or keyID.

Discussion:
Clients encapsulate a request "request" using values from a key configuration: <del> the key identifier from the configuration, "keyID", with the corresponding KEM identified by "kemID", </del> <ins> the key identifier from the configuration, "key_id", with the corresponding KEM identified by "kem_id", </ins> the public key from the configuration, "pkR", and <del> a selected combination of KDF, identified by "kdfID", and AEAD, identified by "aeadID". </del> <ins> a selected combination of KDF, identified by "kdf_id", and AEAD, identified by "aead_id". </ins> The client then constructs an Encapsulated Request, "enc_request", from a binary encoded HTTP request, "request", as follows: Construct a message header, "hdr", by concatenating the values of <del> "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </del> <ins> "key_id", "kem_id", "kdf_id", and "aead_id", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </ins> Build "info" by concatenating the ASCII-encoded string "message/ bhttp request", a zero byte, and the header.

Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server: <del> Parses "enc_request" into "keyID", "kemID", "kdfID", "aeadID", </del> <ins> Parses "enc_request" into "key_id", "kem_id", "kdf_id", "aead_id", </ins> "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private <del> key, "skR", corresponding to "keyID". </del> <ins> key, "skR", corresponding to "key_id". </ins> <del> a.  If "keyID" does not identify a key matching the type of "kemID", the server returns an error. </del> <ins> a.  If "key_id" does not identify a key matching the type of "kem_id", the server returns an error. </ins> <del> b.  If "kdfID" and "aeadID" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns an error. </del> <ins> b.  If "kdf_id" and "aead_id" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns an error. </ins> Build "info" by concatenating the ASCII-encoded string "message/ <del> bhttp request", a zero byte, "keyID" as an 8-bit integer, plus "kemID", "kdfID", and "aeadID" as three 16-bit integers. </del> <ins> 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. </ins> Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info".  This produces a context "rctxt".
Change:
Forwarding an empty request will always yield a failure on the gateway, so just don't do it.
A request without a body is basically malformed, and the gateway will treat it that way. I think relays should be encouraged to reject malformed requests (invalid method, content type, or content body) so this burden doesn't fall on the gateway.
This seems a little bit strange to single out. Do we really need to mandate this? If the relay forwards the request anyway, the gateway will be unable to decrypt it. This creates a shorter and more immediate feedback loop, but it sort of leads to the next question: how much validation do we rely on the relay to do? What if the content-type is not acceptable? Enforcing that choice might be sensible, but it can also lead to ossification, where the relay's view of what is acceptable prevents new options from being deployed. I would have said that it would be better to say something like "A [relay] MAY reject requests that are obviously invalid, such as a request with no content." Obviously, the relay is going to do some amount of denial of service protection on behalf of the gateway, and blocking empty content is a fairly trivial thing to do there, but so is 1 byte of content or a content-type of . We probably don't need to enumerate all the ways and nor do we need to be so strict about what to do.
Your proposed text works for me.
OK, I'll work out how to make that change. I want to submit an update today.
NAME already applied the suggestion!
Yeah, this is much better.
Perfect, thanks!Seems fine. What was the motivation here?

Discussion:
The interacts with the as an HTTP client by constructing a request using the same restrictions as the request, except that the target <del> URI is the .  The content of this request is copied from the .  The MUST NOT add information to the request without the being aware of the type of information that might be added; see relay- responsibilities for more information on relay responsibilities. </del> <ins> URI is the .  The content of this request is copied from the .  An MAY reject requests that are obviously invalid, such as a request with no content.  The MUST NOT add information to the request without the being aware of the type of information that might be added; see relay-responsibilities for more information on relay responsibilities. </ins> When a response is received from the , the forwards the response according to the rules of an HTTP proxy; see HTTP.  In case of
Change:
Duplicate reference: RFC6265, mentioned in 'RFC6265', was also mentioned in 'COOKIES'. Duplicate reference: RFC9110, mentioned in 'SEMANTICS', was also mentioned in 'HTTP'.

Discussion:
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit from being able to carry state between requests, such as with cookies <del> (RFC6265), authentication (HTTP), or even alternative services </del> <ins> (COOKIES), authentication (HTTP), or even alternative services </ins> (RFC7838).  Oblivious HTTP removes linkage at the transport layer, which is only useful for an application that does not carry state between requests.

additional fields.  However, those fields MUST be independent of the and MUST be fields that the will remove before forwarding the towards the target, such as the Connection or Proxy-Authorization header <del> fields SEMANTICS. </del> <ins> fields HTTP. </ins> The role in this protocol acts as an HTTP client both with respect to the and the .  For the request the makes to the , this diverges from
Change:
Might as well say that.
From NAME Section 5.3: Should there be any indication that such errors in processing should be considered as bad requests (and hence return an appropriate error status code) or is this obvious?

Discussion:
Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or <del> outdated.  The can generate and send a response with an error status to the .  This response MAY be forwarded to the or treated by the as a failure.  If a receives a response that is not an , this could indicate that the client configuration used to construct the request is incorrect or out of date. </del> <ins> outdated.  The can generate and send a response with a 4xx status code to the .  This response MAY be forwarded to the or treated by the as a failure.  If a receives a response that is not an , this could indicate that the client configuration used to construct the request is incorrect or out of date. </ins> 5.3.
Change:
From NAME Please add a reference to section 5.3 of [HPKE]; it could be confusing at a first glance to have both the context from the exporter function in 5.3 of [HPKE] and the HPKE context here named "context".

Discussion:
Given an HPKE context "context", a request message "request", and a response "response", servers generate an "enc_response" as follows: <del> Export a secret "secret" from "context", using the string "message/bhttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce associated with "context".  Note: repurposing discusses how </del> <ins> Export a secret, "secret", from "context", using the string "message/bhttp response" as the "exporter_context" parameter to "context.Export"; see HPKE.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce associated with "context".  Note: repurposing discusses how </ins> alternative message formats might use a different "context" value. Generate a random value of length "max(Nn, Nk)" bytes, called
Change:
Remove a "MUST" in this sentence and lean more heavily on the requirement later.
From NAME It seems to me these two sentences contraddict each other: MUST only contain these fields, and MAY include additional fields. Do I read this wrong? (and same for the response later in the section)

Discussion:
5. A interacts with the by constructing an .  This is included as the <del> content of a POST request to the .  This request MUST only contain those fields necessary to carry the : a method of POST, a target URI of the , a header field containing the content type (see (iana-req), and the as the request content.  In the request to the , MAY include additional fields.  However, those fields MUST be independent of the and MUST be fields that the will remove before forwarding the towards the target, such as the Connection or Proxy-Authorization header fields HTTP. </del> <ins> content of a POST request to the .  This request only needs those fields necessary to carry the : a method of POST, a target URI of the , a header field containing the content type (see (iana-req), and the as the request content.  In the request to the , MAY include additional fields.  However, additional fields MUST be independent of the and MUST be fields that the will remove before forwarding the towards the target, such as the Connection or Proxy-Authorization header fields HTTP. </ins> The role in this protocol acts as an HTTP client both with respect to the and the .  For the request the makes to the , this diverges from
Change:
This really just needs a good explanation of what might happen.
From NAME I understand the goal of the sentence above, but I am not sure the SHOULD is appropriate here - in particular if I think about the above as an interoperability requirement, I don't think it gives enough information to the implementer of what is recommended here. If this was to give for example a default time window, it would be a different story. Can we rephrase? (You can also leave as is, but I think it will come up again in IESG review with no change)

Discussion:
field from the decrypted request is outside of the current time window. <del> SHOULD allow for the time it takes requests to arrive from the , with a time window that is large enough to allow for differences in clocks. </del> <ins> might need to allow for the time it takes requests to arrive from the , with a time window that is large enough to allow for differences in clocks.  Insufficient tolerance of time differences could result in valid requests being unnecessarily rejected. </ins> MUST NOT treat the time window as secret information.  An attacker can actively probe with different values for the "Date" field to
Change:
From NAME First and only time KeyConfig appear in the text. Section 6.7: Missing "to" after "used" Section 6.7: Remove the first "affected" Section 7: Missing "to" before prevent, remove "of"

Discussion:
This design does not provide post-compromise security for responses. <del> A only needs to retain keying material that might be used compromise the confidentiality and integrity of a response until that response is consumed, so there is negligible risk associated with a </del> <ins> A only needs to retain keying material that might be used to compromise the confidentiality and integrity of a response until that response is consumed, so there is negligible risk associated with a </ins> compromise. A server retains a secret key that might be used to remove protection

attacker or that the attacker is able to compromise these TLS connections. <del> The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. </del> <ins> The total number of messages affected by server key compromise can be limited by regular rotation of server keys. </ins> 6.8.

One goal of this design is that independent requests are only linkable by their content.  However, the choice of configuration might be used to correlate requests.  A configuration includes the <del> URI, the Oblivious Gateway (KeyConfig), and URI.  A configuration is active if can successfully use it for interacting with with a target. </del> <ins> URI, the Oblivious Gateway , and URI.  A configuration is active if can successfully use it for interacting with with a target. </ins> Oblivious Relay and Gateway Resources can identify when requests use the same configuration by matching the key ID from the or the URI.

need to be active to allow for key rotation and server maintenance. privacy depends on having each configuration used by many other .  It <del> is critical prevent the use of unique configurations, which might be used to track of individual , but it is also important to avoid </del> <ins> is critical to prevent the use of unique configurations, which might be used to track of individual , but it is also important to avoid </ins> creating small groupings of that might weaken privacy protections. A specific method for a to acquire configurations is not included in
Change:
This is based on the observation from NAME that we're presuming a specific processing order at the gateway, which is unnecessary.

Discussion:
An acts as a gateway for requests to the (see HTTP).  The one exception is that any information it might forward in a response MUST <del> be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </del> <ins> be encapsulated, unless it is responding to errors that do not relate to processing the contents of the encapsulated request; see errors. </ins> An , if it receives any response from the , sends a single 200 response containing the encapsulated response.  Like the request from
Change:
As NAME observes in his review, "same entity" is more or less meaningless when it comes to ensuring that forwarding doesn't happen in the clear. This narrows the recommendation to a concrete "same origin", but notes that even that is not sufficient in all cases.

Discussion:
Nonsecure requests - such as those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway <del> and Target Resources are operated by different entities as that would expose both requests and response to modification or inspection by a network attacker. </del> <ins> and Target Resources are not on the same origin.  If messages are forwarded between these resources without the protections afforded by HTTPS, they could be inspected or modified by a network attacker. Note that two resources that share an origin do not guarantee that requests are not forwarded without protection. </ins> 6.4.