jiebi/TextFlow huggingface dataset:
Original text:
7.2.2.  As the time at which encapsulated request or response messages are sent can reveal information to a network observer.  Though messages exchanged between the oblivious proxy resource and the oblivious

Reviewer comments:
Let's be clearer about what it means to proxy here. Also, since it is the same text, talk about TLS assumptions more directly. This will interact poorly with . Sorry about that NAME
From Vienna chat. A proxy is not a generic HTTP intermediary, and therefore is not subject to the same rules.
From NAME Generic proxies would forward unknown HTTP headers between clients and targets. We should be very clear that oblivious proxies are not generic, and should not be doing things like forwarding unknown headers arbitrarily between client and target, or target and client.
requests. This includes the Via field, the Forwarded field {{?FORWARDED=RFC7239}}, and any similar information. A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. Obviously, you need encryption on one or the other side of the proxy, right? Probably this document should require it on the inbound side, but I don't see the text that requires it. Did I just miss it?
Yeah, it's only necessary on the inbound side, per the analysis, though the document assumes it's on both sides.

Revised text:
7.2.2. <ins> This document assumes that all communication between different entities 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 proxy. </ins> As the time at which encapsulated request or response messages are sent can reveal information to a network observer.  Though messages exchanged between the oblivious proxy resource and the oblivious
Original text:
6. In this design, a client wishes to make a request of a server that is <del> authoritative for the Target Resource.  The client wishes to make this request without linking that request with either: </del>  The identity at the network and transport layer of the client (that is, the client IP address and TCP or UDP port number the

Reviewer comments:
Most of the text was correct in that we talk about making a request of a resource. Where the text refers to making requests of a server, those usages seem to be correct.
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
mnot recently made a PR (now merged) that replaced "requests of a server" with "requests to an origin server" and that feels both grammatically and technically more correct. However, there are still few cases peppered through the doc that use "requests of a server". I'd kindly ask the editors to revisit these and consider if they could be made more consistent with the above

Revised text:
6. In this design, a client wishes to make a request of a server that is  <ins> authoritative for a Target Resource.  The client wishes to make this request without linking that request with either: </ins> The identity at the network and transport layer of the client (that is, the client IP address and TCP or UDP port number the
Original text:
analysis could be used to match messages that are forwarded by the relay. <del> A relay could, as part of its function, add delays in order to increase the anonymity set into which each message is attributed. This could latency to the overall time clients take to receive a response, which might not be what some clients want. </del>  A relay that forwards large volumes of exchanges can provide better privacy by providing larger sets of messages that need to be matched.

Reviewer comments:
I presume the idea here is to add jitter to the system (different delays for different requests) rather than compound delays on a single request? Even if not, this paragraph could probably benefit from some language fixups. There's a missing word and "might not be what some clients want" could benefit from a rephrasing to make it stronger.
clearer, thanks

Revised text:
analysis could be used to match messages that are forwarded by the relay.  <ins> A relay could, as part of its function, delay requests before forwarding them.  Delays might increase the anonymity set into which each request is attributed.  Any delay also increases the time that a client waits for a response, so delays SHOULD only be added with the consent - or at least awareness - of clients. </ins> A relay that forwards large volumes of exchanges can provide better privacy by providing larger sets of messages that need to be matched.
Original text:
response to the POST request made to that resource. Errors detected by the after successfully removing encapsulation and <del> errors detected by the MUST be sent in an . </del>  6.

Reviewer comments:
This starts by moving the good text from to the "Errors" section, where I realized that it duplicated some of that language. It was more complete, so I merged the two. I then added some language about what happens to errors prior to decapsulation. This doesn't define an error signaling format. Though that might be useful, it is also a lot more work and I'm leery of scope creep in this document. My view: if you get an error, you have screwed up somewhere. You probably want to have a human look at what is going on. The privacy consequences of automated responses are difficult to work out properly. Hence this proposed change.
This is an improvement but still insufficient with respect to configuration mismatch signaling.
Let's start with this one and I'll look at addressing the open issue in a follow-up.
Thanks, I think this is clear enough now.

Revised text:
response to the POST request made to that resource. Errors detected by the after successfully removing encapsulation and  <ins> errors detected by the MUST be sent in an .  This might be because the request is malformed or the does not produce a response.  In either case the can generate a response with an appropriate error status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see HTTP and HTTP, respectively).  This response is encapsulated in the same way as a successful response. Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or 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. </ins> 6.
Original text:
4.6. <del> The encrypted payload of an OHTTP request and response is a binary HTTP message BINARY.  The and agree on this encrypted payload type by specifying the media type "message/bhttp" in the HPKE info string and HPKE export context string for request and response encryption, respectively. </del>  Future specifications may repurpose the encapsulation mechanism described in this document.  This requires that the specification

Reviewer comments:
From NAME Interesting that this is the first time OHTTP appear in the text, excluding pseudocode and mediatype - please expand (or define somewhere else, for example in terminology).

Revised text:
4.6.  <ins> The encrypted payload of an Oblivious HTTP request and response is a binary HTTP message BINARY.  The and agree on this encrypted payload type by specifying the media type "message/bhttp" in the HPKE info string and HPKE export context string for request and response encryption, respectively. </ins> Future specifications may repurpose the encapsulation mechanism described in this document.  This requires that the specification
Original text:
This draft includes pseudocode that uses the functions and conventions defined in HPKE. <del> This draft uses the variable-length integer encoding from Section 16 of QUIC.  Encoding and decoding variable-length integers to a sequence of bytes are described using the functions "vencode()" and "vdecode()".  The function "len()" takes the length of a sequence of bytes. </del>  Formats are described using notation from Section 1.3 of QUIC.

Reviewer comments:
Switches to an 8-bit key identifier here as well. This format now doesn't need varints. Yay. Implemented this in my ohttp library and it's fine.
Splitting this from . It seems likely that a single KEM key will support multiple KDF or AEAD options (NSS will soon support 3 of the former, and 2 of the latter, maybe 3 of each). Having a configuration that includes a single set of (KEM, key, and key identifier) with a list of KDF+AEAD pairs, akin to ECH, would make it easier to support that sort of deployment. Without that, key identifiers need to carry information about the KDF and AEAD. To support this, the format needs to be adjusted to carry the KDF and AEAD identifier. In doing so, we probably want to encode the choice of KDF and AEAD in the key schedule or AAD accordingly.
Should the key ID length be explicitly authenticated, e.g., by including it in the AAD, or should the AEAD implicitly authenticate things? Unclear!
Should we even bother with an AAD at all? The best reason is that the keyID determines which key the server uses, which is information that factors into decisions. (A related question might be why doesn't HPKE take variables as input so that things like key identifiers can be integrated into the key schedule.)
My take: yes. I need to think through the implications of no additional authentication at all, and in the mean time, I'd be more comfortable with simply authenticating everything possible. I think it was discussed, but it makes the interface a mess. And since applications can accomplish the same thing by shoving what they want authenticated into the AAD, it was voted down.
Yeah, you and I both know that putting stuff in the AAD isn't a real substitute for having it in the key schedule. I completely understand how this would mess with the purity of the design, but TLS managed by wrapping its labels better (which also addresses a known problem with HKDF not being injective).
Fixed by virtue of making the key ID fixed length in .

Revised text:
This draft includes pseudocode that uses the functions and conventions defined in HPKE.  <ins> Encoding an integer to a sequence of bytes in network byte order is described using the function "encode(n, v)", where "n" is the number of bytes and "v" is the integer value.  The function "len()" returns the length of a sequence of bytes. </ins> Formats are described using notation from Section 1.3 of QUIC.
Original text:
Padding is a capability provided by binary HTTP messages; see BINARY. If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message <del> format might need to include padding support. </del>  6.3.

Reviewer comments:
This came out of , where we realized that the relay padding is useful, but needs to employ different methods than client or gateway. The relay can't use binary HTTP padding; it has to insert stuff at the HTTP layer. Include citations for padding in those documents. Note that these citations are slightly misleading. Most relays won't have access at the level necessary to add that padding. More likely, the relay will need to do as NAME originally suggested, namely adding fields of an appropriate size. But we don't have good citations for that, so I'm cheaping out. (Note that RFC 9112, Section 7.1.1 talks about using chunk extensions for padding, but I'm going to pretend that doesn't exist; it's even less usable than the HTTP/2 and HTTP/3 options.)
Take it or leave it!

Revised text:
Padding is a capability provided by binary HTTP messages; see BINARY. If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message  <ins> format might need to include padding support.  can also use padding for the same reason, but need to operate at the HTTP layer since they cannot manipulate binary HTTP messages; for example, see HTTP2 or HTTP3). </ins> 6.3.
Original text:
6.5.1. SHOULD include a "Date" header field in Encapsulated Requests, unless <del> the does not use "Date" for anti-replay purposes. </del>  Though HTTP requests often do not include a "Date" header field, the value of this field might be used by a server to limit the amount of

Reviewer comments:
Comment by NAME In How does a client know this? Preconfiguration ? Are we talking ms? sec? minutes? Any advise to implementers ?
It can't be less than 2s, because the granularity of the field doesn't permit detecting anything finer than 1s. I've done what I can.
This still does not seem to address: Maybe just cut off the “unless” part if there is no signal for this? Paul
NAME also included URL which I think should address your concern:
Thanks. That commit does address the issue, mostly. I guess it moves it do an unspecified provisioning layer :P Paul

Revised text:
6.5.1. SHOULD include a "Date" header field in Encapsulated Requests, unless  <ins> the has prior knowledge that indicates that the does not use "Date" for anti-replay purposes. </ins> Though HTTP requests often do not include a "Date" header field, the value of this field might be used by a server to limit the amount of
Original text:
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 <del> valid requests being unnecessarily rejected. </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:
Comment by NAME In How does a client know this? Preconfiguration ? Are we talking ms? sec? minutes? Any advise to implementers ?
It can't be less than 2s, because the granularity of the field doesn't permit detecting anything finer than 1s. I've done what I can.
This still does not seem to address: Maybe just cut off the “unless” part if there is no signal for this? Paul
NAME also included URL which I think should address your concern:
Thanks. That commit does address the issue, mostly. I guess it moves it do an unspecified provisioning layer :P Paul

Revised text:
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  <ins> valid requests being unnecessarily rejected.  Beyond allowing for multiple round trip times - to account for retransmission - network delays are unlikely to be significant in determining the size of the window, unless all potential are known to have excellent time- keeping.  A specific window size might need to be determined experimentally. </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:
resource; see key-configuration. Clients MUST NOT include identifying information in the request that <del> is encapsulated. </del>  Clients cannot carry connection-level state between requests as they only establish direct connections to the proxy responsible for the

Reviewer comments:
This was vague enough that an example might help.
Yeah, this seems good. Do we want to explicitly mention cookies?

Revised text:
resource; see key-configuration. Clients MUST NOT include identifying information in the request that  <ins> is encapsulated.  Identifying information includes cookies COOKIES, authentication credentials or tokens, and any information that might reveal client-specific information such as account credentials. </ins> Clients cannot carry connection-level state between requests as they only establish direct connections to the proxy responsible for the
Original text:
HPKE algorithms that are used with that key. The identity of an oblivious proxy resource that will forward <del> encapsulated requests and responses to the oblivious request resource. </del>  This information allows the client to make a request of an oblivious target resource without that resource having only a limited ability

Reviewer comments:
This makes the choice of a 1:1 mapping clear: avoid being used as an open proxy through explicit configuration of your ACLs. cc NAME
The proxy has a fixed mapping. It's resource maps to just one request resource. That's a deliberate choice that we should probably be much more up front about.
Yes, I think this makes sense, but it took me a while to realize it when implementing. Having a section on mapping state on the proxy would be useful.
Vittorio says: This relates in particular to the potential for generic services with open destination (not a capability in the proposal) to be used for nefarious purposes (spamming, bot net command and control, hiding illegal activity, etc...).

Revised text:
HPKE algorithms that are used with that key. The identity of an oblivious proxy resource that will forward  <ins> encapsulated requests and responses to a single oblivious request resource.  See proxy-state for more information about the mapping between oblivious proxy and oblivious request resources. </ins> This information allows the client to make a request of an oblivious target resource without that resource having only a limited ability
Original text:
10.  Using Oblivious HTTP adds both cryptographic and latency to requests relative to a simple HTTP request-response exchange.  Deploying proxy services that are on path between clients and servers avoids adding

Reviewer comments:
This makes the choice of a 1:1 mapping clear: avoid being used as an open proxy through explicit configuration of your ACLs. cc NAME
The proxy has a fixed mapping. It's resource maps to just one request resource. That's a deliberate choice that we should probably be much more up front about.
Yes, I think this makes sense, but it took me a while to realize it when implementing. Having a section on mapping state on the proxy would be useful.
Vittorio says: This relates in particular to the potential for generic services with open destination (not a capability in the proposal) to be used for nefarious purposes (spamming, bot net command and control, hiding illegal activity, etc...).

Revised text:
10. <ins> This section discusses various operational and deployment considerations. 10.1. </ins> Using Oblivious HTTP adds both cryptographic and latency to requests relative to a simple HTTP request-response exchange.  Deploying proxy services that are on path between clients and servers avoids adding
Original text:
similar system ODoH found that deploying proxies close to servers was most effective in minimizing additional latency.  Oblivious HTTP might be incompatible with network interception regimes, such as those that rely on configuring clients with trust anchors and intercepting TLS connections.  While TLS might be

Reviewer comments:
This makes the choice of a 1:1 mapping clear: avoid being used as an open proxy through explicit configuration of your ACLs. cc NAME
The proxy has a fixed mapping. It's resource maps to just one request resource. That's a deliberate choice that we should probably be much more up front about.
Yes, I think this makes sense, but it took me a while to realize it when implementing. Having a section on mapping state on the proxy would be useful.
Vittorio says: This relates in particular to the potential for generic services with open destination (not a capability in the proposal) to be used for nefarious purposes (spamming, bot net command and control, hiding illegal activity, etc...).

Revised text:
similar system ODoH found that deploying proxies close to servers was most effective in minimizing additional latency. <ins> 10.2. This protocol assumes a fixed, one-to-one mapping between the Oblivious Proxy Resource and the Oblivious Request Resource.  This means that any encapsulated request sent to the Oblivious Proxy Resource will always be forwarded to the Oblivious Request Resource. This constraint was imposed to simplify proxy configuration and mitigate against the Oblivious Proxy Resource being used as a generic proxy for unknown Oblivious Request Resources.  The proxy will only forward for Oblivious Request Resources that it has explicitly configured and allowed. It is possible for a server to be configured with multiple Oblivious Proxy Resources, each for a different Oblivious Request Resource as needed. 10.3. </ins> Oblivious HTTP might be incompatible with network interception regimes, such as those that rely on configuring clients with trust anchors and intercepting TLS connections.  While TLS might be
Original text:
2.1. QUIC packets may have either a long header, or a short header.  The <del> first bit of the QUIC header indicates which type of header is present. </del>  The long header exposes more information.  It is used during connection establishment, including version negotiation, retry, and

Reviewer comments:
(which didn't require any non-editorial changes; the review is done now)
Also call out invariants (esp. in header structure and handshake) explicitly: v2 may/will break functionality outside the invariants.
Document is currently in in with final invariants; do one last pass to make sure everything documented in Section 17 as expose information appears here (which is basically the same check).

Revised text:
2.1. QUIC packets may have either a long header, or a short header.  The  <ins> first bit of the QUIC header us the Header Form bit, and indicates which type of header is present. </ins> The long header exposes more information.  It is used during connection establishment, including version negotiation, retry, and
Original text:
The following information is exposed in QUIC packet headers: <del> demux bit: the second most significant bit of the first octet every QUIC packet of the current version is set to 1, for demultiplexing with other UDP-encapsulated protocols. </del>  latency spin bit: the third most significant bit of first octet in the short packet header.  The spin bit is set by endpoints such

Reviewer comments:
(which didn't require any non-editorial changes; the review is done now)
Also call out invariants (esp. in header structure and handshake) explicitly: v2 may/will break functionality outside the invariants.
Document is currently in in with final invariants; do one last pass to make sure everything documented in Section 17 as expose information appears here (which is basically the same check).

Revised text:
The following information is exposed in QUIC packet headers:  <ins> "fixed bit": the second most significant bit of the first octet most QUIC packets of the current version is currently set to 1, for demultiplexing with other UDP-encapsulated protocols. </ins> latency spin bit: the third most significant bit of first octet in the short packet header.  The spin bit is set by endpoints such