jiebi/TextFlow huggingface dataset:
Original text:
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>  alternative message formats might use a different "context" value. Generate a random value of length "max(Nn, Nk)" bytes, called

Reviewer comments:
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".

Revised text:
Given an HPKE context "context", a request message "request", and a response "response", servers generate an "enc_response" as follows:  <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
Original text:
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>  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

Reviewer comments:
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)

Revised text:
5. A interacts with the by constructing an .  This is included as the  <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
Original text:
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>  MUST NOT treat the time window as secret information.  An attacker can actively probe with different values for the "Date" field to

Reviewer comments:
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)

Revised text:
field from the decrypted request is outside of the current time window.  <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
Original text:
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>  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>  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>  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>  creating small groupings of that might weaken privacy protections. A specific method for a to acquire configurations is not included in

Reviewer comments:
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"

Revised text:
This design does not provide post-compromise security for responses.  <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.  <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  <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  <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
Original text:
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>  An , if it receives any response from the , sends a single 200 response containing the encapsulated response.  Like the request from

Reviewer comments:
This is based on the observation from NAME that we're presuming a specific processing order at the gateway, which is unnecessary.

Revised text:
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  <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
Original text:
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>  6.4.

Reviewer comments:
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.

Revised text:
Nonsecure requests - such as those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway  <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.
Original text:
-configured HTTP proxies can provide a degree of protection against IP address tracking, and systems like virtual private networks and <del> the Tor network Dingledine2004 provide additional options for clients. </del>  However, even when IP address tracking is mitigated using one of these techniques, each request needs to be on a completely new TLS with possible stateful treatment of requests are sufficiently large that the cost of deploying this protocol can be justified.  Oblivious HTTP is simpler and less costly than more robust systems, like Prio <del> (PRIO) or Tor (Dingledine2004), which can provide stronger guarantees at higher operational costs. </del>  Oblivious HTTP is more costly than a direct connection to a server. Some costs, like those involved with connection setup, can be requests relative to a simple HTTP request-response exchange. Deploying relay services that are on path between and servers avoids adding significant additional delay due to network topology.  A study <del> of a similar system ODoH found that deploying proxies close to </del>  servers was most effective in minimizing additional latency. 8.2.

Reviewer comments:
Dingledine2004 -> DMS2004 ODoH -> ODOH-PETS
Comment by NAME ODOH and ODoH seems very similar and likely to cause confusion. Rename one?
thanks
Comment by NAME Using "[Dingledine2004]" as description identifier for TOR is a bit weird :P
This is entirely appropriate given the nature of the reference. This is a reference to a paper, not a specification for Tor, so using "[TOR]" could be misleading. It's possible that we could cite a specification, but it's really hard to pin that down properly. URL seems right, but it doesn't bear a date and appears to be a rendering from URL which is in turn just a snapshot (currently URL). Aside from referential stability, the specification is less of a useful reference as it says less about what Tor is and gets buried in detail. I'm inclined to leave as-is, or switch to "[DMS2004]" to reference all author's names.
ok

Revised text:
-configured HTTP proxies can provide a degree of protection against IP address tracking, and systems like virtual private networks and  <ins> the Tor network DMS2004 provide additional options for clients. </ins> However, even when IP address tracking is mitigated using one of these techniques, each request needs to be on a completely new TLS with possible stateful treatment of requests are sufficiently large that the cost of deploying this protocol can be justified.  Oblivious HTTP is simpler and less costly than more robust systems, like Prio  <ins> (PRIO) or Tor (DMS2004), which can provide stronger guarantees at higher operational costs. </ins> Oblivious HTTP is more costly than a direct connection to a server. Some costs, like those involved with connection setup, can be requests relative to a simple HTTP request-response exchange. Deploying relay services that are on path between and servers avoids adding significant additional delay due to network topology.  A study  <ins> of a similar system ODOH-PETS found that deploying proxies close to </ins> servers was most effective in minimizing additional latency. 8.2.
Original text:
The request the sends to the only requires minimal information; see http-usage.  The request that carries the and is sent to the MUST NOT <del> include identifying information unless the ensures that this </del>  information is removed by the relay.  A MAY include information only for the in header fields identified by the Connection header field if it trusts the relay to remove these as required by Section 7.6.1 of

Reviewer comments:
The client relies on a very specific form of trust here, though maybe they have other means to ensure compliance, it's trust that operates here.
Comment by NAME How could a client "ensure" that? Couldn't this at best be "unless the Client can trust that [...]"
(OK, edited this so that it only includes one comment, not two mangled together.) The answer here is down to trust, so this comment is right. Will fix.
looks good.

Revised text:
The request the sends to the only requires minimal information; see http-usage.  The request that carries the and is sent to the MUST NOT  <ins> include identifying information unless the can trust that this </ins> information is removed by the relay.  A MAY include information only for the in header fields identified by the Connection header field if it trusts the relay to remove these as required by Section 7.6.1 of
Original text:
protection for the unprotected requests and responses, plus protections for traffic analysis; see ta.  8. Words...

Reviewer comments:
If the key identifier isn't known to the oblivious request resource, or the message can't be decrypted, it probably wants to send a clear signal. The signal is definitely not encapsulated at that point, so clients have limited options available to them. As a first-order suggestion, a 4xx status code generally indicates to the client that it might want to review the information it used. However, more specific error codes might help in specific cases that we deem important or common. Top of the list: when the identified key has been decommissioned.
How does sound in terms of saying "the content was unusable". We could go further and recommend the use of if you think more detail is needed.

Revised text:
protection for the unprotected requests and responses, plus protections for traffic analysis; see ta. <ins> An oblivious request resource needs to have a plan for replacing keys.  This might include regular replacement of keys, which can be assigned new key identifiers.  If an oblivious request resource receives a request that contains a key identifier that it does not understand or that corresponds to a key that has been replaced, the server can respond with an HTTP 422 (Unprocessable Content) status code. A server can also use a 422 status code if the server has a key that corresponds to the key identifier, but the encapsulated request cannot be successfully decrypted using the key. </ins> 8. Words...
Original text:
3.1. A single consists of a key identifier, a public key, an identifier <del> for the KEM that the public key uses, and a set HPKE symmetric </del>  algorithms.  Each symmetric algorithm consists of an identifier for a KDF and an identifier for an AEAD.

Reviewer comments:
"and a set HPKE" => "and a set of HPKE"
Thanks for the quick review and approval, NAME I haven't used the GitHub UI for submitting PRs in a long time so please pardon my lack of understanding here but I still don't see a way to merge the PR. Does it also need a review from NAME ?
NAME it doesn't technically need a review from Martin. The pattern we seem to have landed on is that one of us merges once both approve, but this is simple enough that I just merged it now. Thanks for sending the PR!

Revised text:
3.1. A single consists of a key identifier, a public key, an identifier  <ins> for the KEM that the public key uses, and a set of HPKE symmetric </ins> algorithms.  Each symmetric algorithm consists of an identifier for a KDF and an identifier for an AEAD.
Original text:
Encrypt (seal) "request" with "aad" as associated data using "context", yielding ciphertext "ct". <del> Concatenate the three values of "aad", "enc", and "ct", yielding an Encapsulated Request "enc_request". </del>  Note that "enc" is of fixed-length, so there is no ambiguity in parsing this structure. In pseudocode, this procedure is as follows: <del> Servers MUST verify that the request padding consists of all zeroes before processing the corresponding Message. </del> 5.2. Given an HPKE context "context", a request message "request", and a "enc_response" as follows: Export a secret "secret" from "context", using the string <del> "response" as a label.  The length of this secret is "Nk" - the length of an AEAD key assocated with "context". </del>  Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce". The client uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows: <del> 5.3. Plaintext Messages support arbitrary length padding.  Clients and servers MAY pad HTTP messages as needed to hide metadata leakage through ciphertext length. </del> 6. A client interacts with the oblivious proxy resource by constructing

Reviewer comments:
One question we might want to ask (even though I think we have the right answer already) is: should be included in AAD? I also removed the padding text, since we moved that to the bhttp spec.
It's a reasonable question, but I think we can safely assume that a single key can't be used with multiple KEMs.
In principle it might be possible, but I think we should prohibit it.

Revised text:
Encrypt (seal) "request" with "aad" as associated data using "context", yielding ciphertext "ct".  <ins> Concatenate the values of "aad", "enc", and "ct", yielding an Encapsulated Request "enc_request". </ins> Note that "enc" is of fixed-length, so there is no ambiguity in parsing this structure. In pseudocode, this procedure is as follows:  5.2. Given an HPKE context "context", a request message "request", and a "enc_response" as follows: Export a secret "secret" from "context", using the string  <ins> "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". </ins> Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce". The client uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows:  6. A client interacts with the oblivious proxy resource by constructing
Original text:
The server-chosen "response_nonce" field ensures that responses have unique AEAD keys and nonces even when requests are replayed.  9. Please update the "Media Types" registry at

Reviewer comments:
And recommend key rotation as a mitigation strategy.
Compromise of the client after it sends the request can be used to recover the keys used to decrypt (or falsify) the response.
NAME suggests that we need to consider how to time-bound server keys to limit the risk of secret key exposure.

Revised text:
The server-chosen "response_nonce" field ensures that responses have unique AEAD keys and nonces even when requests are replayed. <ins> 8.5. This design does not provide post-compromise security for responses. A client 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 client compromise. A server retains a secret key that might be used to remove protection from messages over much longer periods.  A server compromise that provided access to the oblivious request resource secret key could allow an attacker to recover the plaintext of all requests sent toward affected keys and all of the responses that were generated. Accessing requests and responses also requires access to requests and responses, which implies either compromise of TLS connections or collusion with the oblivious proxy resource. The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. </ins> 9. Please update the "Media Types" registry at
Original text:
9.  Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] with the registration information in media-types for the media types "message/ ohttp-req", "message/ohttp-res", and "application/ohttp-keys". <del> 10.  References </del>  <del> 10.1.  URIs </del>  [1] https://www.iana.org/assignments/media-types

Reviewer comments:
A server that wants to undermine this process can ensure that clients are provided with individual keys. Though there is a limited number of key identifiers (though see also ), a server could extend the number of identifiers with a little bit of trial decryption. Or the server could just use this ability selectively. Though the draft deliberately avoids talking about how clients learn about keys, we might talk about the implications of acquiring keys from servers. If the server is responsible for issuing keys, then the server can target individuals with specific keys. NAME suggests that maybe we could have the proxy provide keys. This is not a bad way to deal with this problem, though it places more trust in the proxy as the proxy now needs to be trusted not to provide a key for which it has the secret key. That might still work if the key could be further authenticated by the server, but that's a rabbit hole of its own.

Revised text:
9. <ins> One goal of this design is that independent client requests are only linkable by the chosen KeyConfig.  The oblivious proxy and request resources can link requests using the same KeyConfig by matching KeyConfig.key_id.  The oblivious proxy can also link requests using the public key corresponding to KeyConfig.key_id.  The proxy cannot determine precisely which public key was used to encapsulate a request, given that multiple public keys may have matching key identifiers. Request resources are capable of linking requests depending on how KeyConfigs are produced by servers and discovered by clients. Specifically, servers can maliciously construct KeyConfigs to track individual clients.  While KeyConfig discovery is outside the scope of this specification, clients should consider this tracking vector in deployments.  Applications using this design should provide accommodations to mitigation this tracking vector. 10. </ins> Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] with the registration information in media-types for the media types "message/ ohttp-req", "message/ohttp-res", and "application/ohttp-keys".  <ins> 11.  References </ins>  <ins> 11.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types