jiebi/TextFlow huggingface dataset:
Original text:
A server operates both the Oblivious Gateway Resource and the Target Resource  To achieve the stated privacy goals, the Oblivious Relay Resource cannot be operated by the same entity as the Oblivious Gateway Resource.  However, colocation of the Oblivious Gateway Resource and 6.2.3. <del> This document assumes that all communication between different Oblivious Client, Oblivious Relay Resource, and Oblivious Gateway Resource is protected by HTTPS.  This protects information about which resources are the subject of request and prevents a network observer from being able to trivially correlate messages on either side of a relay.  However, it does not mitigate traffic analysis by such network observers. </del>  The time at which Encapsulated Request or response messages are sent can reveal information to a network observer.  Though messages

Reviewer comments:
The text noted in was correct, but we didn't have a single place where we outlined this as a direct requirement. The day where HTTP presupposes TLS has come for some, but not all of us. Until then, we can be more careful.
The document uses the term TLS connection(s) in four places: My understanding is that oHTTP is not restricted to versions of HTTP that use TLS. The obvious one being QUIC (arguably TLS-like) but presumably some future protocol that satisfies the security properties of HTTPS could be used and oHTTP wouldn't really care. Now, perhaps I'm mistaken and oHTTP does mandate TLS. If so, perhaps I'm overlooking it. URL states many requirements but not the use of HTTPS. That seems implicit via URL However, that seems in conflict with URL, which says In summary, there seems to be some opportunity to tighten up the consistency of expectations about the connections underpinning oHTTP interations.

Revised text:
A server operates both the Oblivious Gateway Resource and the Target Resource <ins> Connections between the client, Oblvious Relay Resource, and Oblivious Gateway Resource MUST use HTTPS in order to provide unlinkability in the presence of a network observer.  The scheme of the encapsulated request detemrines what is used between the Oblivious Gateway and Target Resources, though using HTTPS is RECOMMENDED; see server-responsibilities. </ins> To achieve the stated privacy goals, the Oblivious Relay Resource cannot be operated by the same entity as the Oblivious Gateway Resource.  However, colocation of the Oblivious Gateway Resource and 6.2.3.  <ins> Using HTTPS protects information about which resources are the subject of request and prevents a network observer from being able to trivially correlate messages on either side of a relay.  However, using HTTPS does not prevent traffic analysis by such network observers. </ins> The time at which Encapsulated Request or response messages are sent can reveal information to a network observer.  Though messages
Original text:
string "s" is indicated using the function "encode_str(s)".  The function "len()" returns the length of a sequence of bytes. <del> Formats are described using notation from QUIC. </del>  3. request describes the process for constructing and processing an Encapsulated Request. <del> The Nenc parameter corresponding to the HpkeKdfId can be found in HPKE. </del>  An encrypted HTTP response includes a binary-encoded HTTP message BINARY and no other content; see fig-res-pt. content.  response describes the process for constructing and processing an Encapsulated Response. <del> The Nenc and Nk parameters corresponding to the HpkeKdfId can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes; Nk refers to the size of the AEAD key for the HPKE ciphersuite, in bits. </del>  4.1.

Reviewer comments:
In Section 4, there are two statements for Encapsulated Request and Encapsulate Response respectively These are the only places that is used. The HPKE spec doesn't use the term either. Doing some digging, it seemed like an older draft defined this term (and others); see URL But it seems like you moved away from that and this is a hangover
So this isn't ideal. It is also wrong. It would be HpkeKemId in the first instance and HpkeAeadId in the second. The second also refers to Nenc without using it. The second also neglected to mention Nn, which was in the algorithm. What a mess. I've cleaned it up, but would appreciate someone double-checking my work.
This addresses the issue I created, thanks. I can't vouch for the correctness of the crypto pieces though

Revised text:
string "s" is indicated using the function "encode_str(s)".  The function "len()" returns the length of a sequence of bytes.  <ins> Formats are described using notation from QUIC.  An extension to that notation expresses the number of bits in a field using a simple mathematical function. </ins> 3. request describes the process for constructing and processing an Encapsulated Request.  <ins> The Nenc parameter corresponding to the KEM used in HPKE can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </ins> An encrypted HTTP response includes a binary-encoded HTTP message BINARY and no other content; see fig-res-pt. content.  response describes the process for constructing and processing an Encapsulated Response.  <ins> The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The Encapsulated Response nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </ins> 4.1.
Original text:
Use the "Expand" function provided by the same KDF to extract an AEAD key "key", of length "Nk" - the length of the keys used by <del> the AEAD associated with "context".  Generating "key" uses a label of "key". </del>  Use the same "Expand" function to extract a nonce "nonce" of length "Nn" - the length of the nonce used by the AEAD. <del> Generating "nonce" uses a label of "nonce". </del>  Encrypt "response", passing the AEAD function Seal the values of <del> "key", "nonce", empty "aad", and a "pt" input of "request", which yields "ct". </del>  Concatenate "response_nonce" and "ct", yielding an Encapsulated Response "enc_response".  Note that "response_nonce" is of fixed-

Reviewer comments:
Section 4.2, prose says whereas the pseudo-code says
A few things here should improve readability: key -> aeadkey, nonce -> aeadnonce, then we should be sure to pass the response in rather than the request.
Nice catch on s/request/responseLGTM

Revised text:
Use the "Expand" function provided by the same KDF to extract an AEAD key "key", of length "Nk" - the length of the keys used by  <ins> the AEAD associated with "context".  Generating "aead_key" uses a label of "key". </ins> Use the same "Expand" function to extract a nonce "nonce" of length "Nn" - the length of the nonce used by the AEAD.  <ins> Generating "aead_nonce" uses a label of "nonce". </ins> Encrypt "response", passing the AEAD function Seal the values of  <ins> "aead_key", "aead_nonce", an empty "aad", and a "pt" input of "response", which yields "ct". </ins> Concatenate "response_nonce" and "ct", yielding an Encapsulated Response "enc_response".  Note that "response_nonce" is of fixed-
Original text:
difference is relevant, applications can instead connect directly to the target at the cost of either privacy or performance. <del> Clients MUST NOT include identifying information in the request that is encrypted.  Identifying information includes cookies COOKIES, authentication credentials or tokens, and any information that might reveal client-specific information such as account credentials. </del> Clients cannot carry connection-level state between requests as they only establish direct connections to the relay responsible for the <del> Oblivious Relay resource.  However, clients need to ensure that they construct requests without any information gained from previous requests.  Otherwise, the server might be able to use that information to link requests.  Cookies COOKIES are the most obvious feature that MUST NOT be used by clients.  However, clients need to include all information learned from requests, which could include the identity of resources. </del>  Clients MUST generate a new HPKE context for every request, using a good source of entropy (RANDOM) for generating keys.  Key reuse not

Reviewer comments:
Not even once, down from two. Using cookies is dumb, but we don't need to ban them so directly. There are tons of ways in which information from a previous request might leak across into the current one. The point is to highlight the risk of using them. A direct prohibition doesn't make sense if the use of the cookie is well understood (not that attaining such an understanding is likely to be easy).
In Section 6.1, the document states twice, in the space of two paragraphs, that clients MUST NOT use cookies. That seems a little excessive.
I'm OK with this relaxation. Clients who want to use OHTTP will presumably not do the dumb thing.

Revised text:
difference is relevant, applications can instead connect directly to the target at the cost of either privacy or performance.  Clients cannot carry connection-level state between requests as they only establish direct connections to the relay responsible for the  <ins> Oblivious Relay resource.  However, the content of requests might be used by a server to correlate requests.  Cookies COOKIES are the most obvious feature that might be used to correlate requests, but any identity information and authentication credentials might have the same effect.  Clients also need to treat information learned from responses with similar care when constructing subsequent requests, which includes the identity of resources. </ins> Clients MUST generate a new HPKE context for every request, using a good source of entropy (RANDOM) for generating keys.  Key reuse not
Original text:
Gateway Resource also act as HTTP clients toward the Oblivious Gateway Resource and Target Resource respectively.  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.  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.  5.1. This encapsulation does not permit progressive processing of

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

Revised text:
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
Original text:
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>  Nonsecure requests - such those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and

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

Revised text:
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  <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
Original text:
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>  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.  IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM.

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

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

Reviewer comments:
In Deployment Considerations / Performance Overhead... Should that be "cryptographic" -> "cryptographic complexity" or something like that?
It should probably be "cryptographic overhead." Nice catch!

Revised text:
8.1.  <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.
Original text:
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>  Each active client configuration partitions the client anonymity set. In practice, it is infeasible to reduce the number of active

Reviewer comments:
This was the only case we used the TLS-style dot notation, but we don't need to pull in a new concept.

Revised text:
successfully use it for interacting with with a target. Oblivious Relay and Gateway Resources can identify when requests use  <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
Original text:
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>  When a response is received from the , the forwards the response according to the rules of an HTTP proxy; see HTTP.  In case of

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

Revised text:
The interacts with the as an HTTP client by constructing a request using the same restrictions as the request, except that the target  <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
Original text:
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>  (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>  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:
Duplicate reference: RFC6265, mentioned in 'RFC6265', was also mentioned in 'COOKIES'. Duplicate reference: RFC9110, mentioned in 'SEMANTICS', was also mentioned in 'HTTP'.

Revised text:
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit from being able to carry state between requests, such as with cookies  <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  <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
Original text:
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>  5.3.

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

Revised text:
Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or  <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.