jiebi/TextFlow huggingface dataset:
Original text:
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame carrying a request that is not cacheable, is not known to be safe, that indicates the presence of a request body, or <del> for which it does not consider the server authoritative. </del>  Each pushed response is associated with one or more client requests. The push is associated with the request stream on which the

Reviewer comments:
In the HTTP/3 draft 30, section 4.4 on Server Push says and then adds in 10.4 (URL) I don't think normative requirements belong in security considerations except in reference to that requirement elsewhere. Also, requirements in general should clearly state who is responsible for implementing them, whereas the latter requirement implies a client (maybe). And sending CANCEL_PUSH is kind of like the MUST NOT, but not really the same thing; it seems a bit weak in response given that the server just tried to poison the client. I think the server MUST is an interop requirement because the client MUST NOT is a critical security requirement. I think both should be described in Server Push and merely noted in the Security Considerations, since they are really important. Way more important than the spec reads now. My guess is that this is editorial, but is the kind of thing that should be fixed before IESG last call.
The reason it's only a SHOULD CANCEL_PUSH is that the server can't know with certainty for which origins the client considers it authoritative. The server only knows for which origins it believes that it's authoritative. So having received a push the client considers out-of-bounds, the client can't know for sure whether it's a poisoning attempt or simply a difference in view. Yes, I think this is editorial, since the core request is to relocate existing text without changing the normative requirements.

Revised text:
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame carrying a request that is not cacheable, is not known to be safe, that indicates the presence of a request body, or  <ins> for which it does not consider the server authoritative.  Any corresponding responses MUST NOT be used or cached. </ins> Each pushed response is associated with one or more client requests. The push is associated with the request stream on which the
Original text:
served out of cache, overriding the actual representation that the authoritative tenant provides. <del> Pushed responses for which an origin server is not authoritative (see connection-reuse) MUST NOT be used or cached. </del>  10.5.

Reviewer comments:
In the HTTP/3 draft 30, section 4.4 on Server Push says and then adds in 10.4 (URL) I don't think normative requirements belong in security considerations except in reference to that requirement elsewhere. Also, requirements in general should clearly state who is responsible for implementing them, whereas the latter requirement implies a client (maybe). And sending CANCEL_PUSH is kind of like the MUST NOT, but not really the same thing; it seems a bit weak in response given that the server just tried to poison the client. I think the server MUST is an interop requirement because the client MUST NOT is a critical security requirement. I think both should be described in Server Push and merely noted in the Security Considerations, since they are really important. Way more important than the spec reads now. My guess is that this is editorial, but is the kind of thing that should be fixed before IESG last call.
The reason it's only a SHOULD CANCEL_PUSH is that the server can't know with certainty for which origins the client considers it authoritative. The server only knows for which origins it believes that it's authoritative. So having received a push the client considers out-of-bounds, the client can't know for sure whether it's a poisoning attempt or simply a difference in view. Yes, I think this is editorial, since the core request is to relocate existing text without changing the normative requirements.

Revised text:
served out of cache, overriding the actual representation that the authoritative tenant provides.  <ins> Clients are required to reject pushed responses for which an origin server is not authoritative; see server-push. </ins> 10.5.
Original text:
21.6. <del> An adversarial sender might intentionally send fragments of stream data in an attempt to cause disproportionate receive buffer memory commitment and/or creation of a large and inefficient data structure. </del>  An adversarial receiver might intentionally not acknowledge packets containing stream data in an attempt to force the sender to store the

Reviewer comments:
Proposal to clarify "stream fragmentation". Suggested by Issue .
I don’t understand what section 21.6 is about… the title seems to suggests it is about IP Fragmentation and Reassembly Attacks, but elsewhere the spec already prohibits IP Fragmentation in section 14? And I have seen no encouragement to do any form of network-layer fragmentation - so I don’t understand a security consideration in this topic. Is this therefiore some other thing? It may about something different where a sender originates data with “holes” of missing packet to try and exercise the server? or soemthing? What is this?
Hi NAME 21.6 is titled "Stream Fragmentation and Reassembly Attacks". It refers to streams, not IP packets. The attack involves sending stream frames with holes such as and some receivers might allocate the entire stream receive buffer between 0 and 10000001. I found the section pretty clear, but we should make it clear to everyone - could you perhaps suggest text that would make it clearer?
OK. I see. I can try a PR, if I can find words that avoid "fragment": Is this close enough to start: /An adversarial sender might intentionally omit to send portions of the stream data causing the receiver to commit resources for the omitted data, this could cause a disproportionate receive buffer memory commitment and/or creation of a large and inefficient data structure.
Do we really need to avoid the term "fragment"? It's not the only overloaded networking term in the spec. Perhaps adding a "Note that stream fragmentation is unrelated to IP fragmentation" could suffice?
I don't think this clarification is necessary. The context makes it clear what fragmentation this is, and talking about IP fragmentation only leads to confuse the reader. (I like the first part of your PR though, as I've noted on my review of it.)

Revised text:
21.6.  <ins> An adversarial sender might intentionally not send portions of the stream data, causing the receiver to commit resources for the unsent data.  This could cause a disproportionate receive buffer memory commitment and/or the creation of a large and inefficient data structure at the receiver. </ins> An adversarial receiver might intentionally not acknowledge packets containing stream data in an attempt to force the sender to store the
Original text:
Using a value for "N" that is small, but at least 1 (for example, 1.25) ensures that variations in round-trip time do not result in <del> under-utilization of the congestion window.  Values of 'N' larger than 1 ultimately result in sending packets as acknowledgments are received rather than when timers fire, provided the congestion window is fully utilized and acknowledgments arrive at regular intervals. </del>  Practical considerations, such as packetization, scheduling delays, and computational efficiency, can cause a sender to deviate from this

Reviewer comments:
N was introduced in to describe how a sender might pace at a rate that allows it to send a congestion window's worth of data in a period that is shorter than an RTT. This PR clarifies text that goes into unnecessary detail, trying to describe assumptions (the network is spreading the packets out, for example, resulting in an ack clock).
Can we make progress in this one?
Yes, I'm waiting for the design issues to get done before moving on the remaining editorial ones.
I think that has happened now :-)
Nudge

Revised text:
Using a value for "N" that is small, but at least 1 (for example, 1.25) ensures that variations in round-trip time do not result in  <ins> under-utilization of the congestion window. </ins> Practical considerations, such as packetization, scheduling delays, and computational efficiency, can cause a sender to deviate from this
Original text:
tuple, as shown in transport-parameter-encoding-fig: The Transport Parameter Length field contains the length of the <del> Transport Parameter Value field. </del>  QUIC encodes transport parameters into a sequence of bytes, which is then included in the cryptographic handshake.

Reviewer comments:
Does this win the record for least amount of bytes touched in a PR?
Lars, I can't find it easily, but I believe that I pushed a 1 bit change at one point in this process.
Parameter Value field. Presumably the length in bytes.

Revised text:
tuple, as shown in transport-parameter-encoding-fig: The Transport Parameter Length field contains the length of the  <ins> Transport Parameter Value field in bytes. </ins> QUIC encodes transport parameters into a sequence of bytes, which is then included in the cryptographic handshake.
Original text:
entity that receives an Initial packet from a client can recover the keys that will allow them to both read the contents of the packet and generate Initial packets that will be successfully authenticated at <del> either endpoint. </del>  All other packets are protected with keys derived from the cryptographic handshake.  The cryptographic handshake ensures that

Reviewer comments:
The description neglected to mention this. Obviously, the confidentiality protection (specifically, the lack thereof) is the part that needs to be highlighted, but we shouldn't neglect the other purpose of using an AEAD here.

Revised text:
entity that receives an Initial packet from a client can recover the keys that will allow them to both read the contents of the packet and generate Initial packets that will be successfully authenticated at  <ins> either endpoint.  The AEAD also protects Initial packets against accidental modification. </ins> All other packets are protected with keys derived from the cryptographic handshake.  The cryptographic handshake ensures that
Original text:
The payload of this packet contains CRYPTO frames and could contain PING, PADDING, or ACK frames.  Handshake packets MAY contain CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt <del> of Handshake packets with other frames as a connection error. </del>  Like Initial packets (see discard-initial), data in CRYPTO frames for Handshake packets is discarded - and no longer retransmitted - when

Reviewer comments:
Because it always is.
I'm checking "MUST treat" in the transport draft. Sec 17.2.4 says: This is only the place where the type of a connection error is NOT specified. This part should be modified as "a connection error of XXX".
This was deliberate, but you can now send CONNECTION_CLOSE in this case, so it makes sense to use a code here.

Revised text:
The payload of this packet contains CRYPTO frames and could contain PING, PADDING, or ACK frames.  Handshake packets MAY contain CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt  <ins> of Handshake packets with other frames as a connection error of type PROTOCOL_VIOLATION. </ins> Like Initial packets (see discard-initial), data in CRYPTO frames for Handshake packets is discarded - and no longer retransmitted - when
Original text:
control across the entire connection, QUIC has the capability to improve the performance of HTTP compared to a TCP mapping.  QUIC also incorporates TLS 1.3 (TLS13) at the transport layer, offering <del> comparable security to running TLS over TCP, with the improved connection setup latency of TCP Fast Open (TFO). </del>  This document defines a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2.  While

Reviewer comments:
Mostly because QUIC doesn't prevent all forms of request forgery. Thankfully, this is dealt with in detail in the transport draft.
NAME this looks good. Can you also change one sentence in Sec 1.2, from: to .
Hilarie Orman wrote: all this is assumed to be provided by QUIC. Section 10.2 says that all QUIC packets are encrypted; I'm not sure if that's true, or if QUIC has an option for "non-modifiable" without encryption.
Actually, we now know that this is not true, so this really needs to be fixed: -- from . The real solution here is to cite of the transport draft.
The version of QUIC required by this draft is always encrypted; that seems sufficient for the original issue. NAME issue is distinct, and worth fixing. I'll use this issue to track it.
... and we could add some text stating the integrity point in Section 1.2. NAME suggests: "comparable integrity and confidentiality to TLS over TCP"
Could we make some progress on this one?
Progress made; the PR now needs review.

Revised text:
control across the entire connection, QUIC has the capability to improve the performance of HTTP compared to a TCP mapping.  QUIC also incorporates TLS 1.3 (TLS13) at the transport layer, offering  <ins> comparable confidentiality and integrity to running TLS over TCP, with the improved connection setup latency of TCP Fast Open (TFO). </ins> This document defines a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2.  While
Original text:
The use of ALPN in the TLS and QUIC handshakes establishes the target application protocol before application-layer bytes are processed. <del> Because all QUIC packets are encrypted, it is difficult for an attacker to control the plaintext bytes of an HTTP/3 connection, which could be used in a cross-protocol attack on a plaintext protocol. </del>  10.3.

Reviewer comments:
Mostly because QUIC doesn't prevent all forms of request forgery. Thankfully, this is dealt with in detail in the transport draft.
NAME this looks good. Can you also change one sentence in Sec 1.2, from: to .
Hilarie Orman wrote: all this is assumed to be provided by QUIC. Section 10.2 says that all QUIC packets are encrypted; I'm not sure if that's true, or if QUIC has an option for "non-modifiable" without encryption.
Actually, we now know that this is not true, so this really needs to be fixed: -- from . The real solution here is to cite of the transport draft.
The version of QUIC required by this draft is always encrypted; that seems sufficient for the original issue. NAME issue is distinct, and worth fixing. I'll use this issue to track it.
... and we could add some text stating the integrity point in Section 1.2. NAME suggests: "comparable integrity and confidentiality to TLS over TCP"
Could we make some progress on this one?
Progress made; the PR now needs review.

Revised text:
The use of ALPN in the TLS and QUIC handshakes establishes the target application protocol before application-layer bytes are processed.  <ins> This ensures that endpoints have strong assurances that peers are using the same protocol. This does not guarantee protection from all cross-protocol attacks. Section 21.5 of QUIC-TRANSPORT describes some ways in which the plaintext of QUIC packets can be used to perform request forgery against endpoints that don't use authenticated transports. </ins> 10.3.
Original text:
A PATH_RESPONSE frame received on any network path validates the path on which the PATH_CHALLENGE was sent. <del> If the PATH_CHALLENGE frame that resulted in successful path validation was sent in a datagram that was not expanded to at least 1200 bytes, the endpoint can regard the address as valid.  The endpoint is then able to send more than three times the amount of </del>  data that has been received.  However, the endpoint MUST initiate another path validation with an expanded datagram to verify that the <del> path supports required MTU. </del>  Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be

Reviewer comments:
This was definitely odd. Let's take another tilt at making it comprehensible.
Erik Kline said:
Yep, when it's called out, it's distinctly odd. Hopefully it's an easy fix, but writing is hardd.

Revised text:
A PATH_RESPONSE frame received on any network path validates the path on which the PATH_CHALLENGE was sent.  <ins> If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not expanded to at least 1200 bytes, and if the response to it validates the peer address, the path is validated but not the path MTU.  As a result, the endpoint can now send more than three times the amount of </ins> data that has been received.  However, the endpoint MUST initiate another path validation with an expanded datagram to verify that the  <ins> path supports the required MTU. </ins> Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be
Original text:
authenticated negotiation of an application protocol (TLS uses ALPN ALPN for this purpose) <del> Endpoints can use packets sent during the handshake to test for Explicit Congestion Notification (ECN) support; see ecn.  An endpoint verifies support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </del> The CRYPTO frame can be sent in different packet number spaces (packet-numbers).  The offsets used by CRYPTO frames to ensure ordered delivery of cryptographic handshake data start from zero in

Reviewer comments:
This is my best stab at it.
Erik Kline said:
I thought that section reference was wrong, but Section 7 does indeed mention ECN twice. Once is almost too much for this section. I checked the history and the commits that affected this text likely are the result of a merge, and one that either git resolved incorrectly for us, or one that we messed up. Either way, this is worth fixing.
one nit

Revised text:
authenticated negotiation of an application protocol (TLS uses ALPN ALPN for this purpose)  The CRYPTO frame can be sent in different packet number spaces (packet-numbers).  The offsets used by CRYPTO frames to ensure ordered delivery of cryptographic handshake data start from zero in
Original text:
shown with a '*'.  Once completed, endpoints are able to exchange application data. <del> An endpoint validates support for Explicit Congestion Notification (ECN) by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </del>  Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol

Reviewer comments:
This is my best stab at it.
Erik Kline said:
I thought that section reference was wrong, but Section 7 does indeed mention ECN twice. Once is almost too much for this section. I checked the history and the commits that affected this text likely are the result of a merge, and one that either git resolved incorrectly for us, or one that we messed up. Either way, this is worth fixing.
one nit

Revised text:
shown with a '*'.  Once completed, endpoints are able to exchange application data.  <ins> Endpoints can use packets sent during the handshake to test for Explicit Congestion Notification (ECN) support; see ecn.  An endpoint validates support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </ins> Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol
Original text:
A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used. <del> Clients that want to break continuity of identity with a server MAY </del>  discard tokens provided using the NEW_TOKEN frame.  In comparison, a token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection

Reviewer comments:
NAME said:
I think "can" works equally well, given the precondition. I'll make that change.

Revised text:
A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used.  <ins> Clients that want to break continuity of identity with a server can </ins> discard tokens provided using the NEW_TOKEN frame.  In comparison, a token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection
Original text:
The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and <del> MUST be discarded. </del>  The next two bits (those with a mask of 0x30) of byte 0 contain a packet type.  Packet types are listed in long-packet-types.

Reviewer comments:
NAME said:
This particular choice has not a lot to do with QUIC and would therefore bring in a lot of non-sequitur references, but a single sentence won't hurt. It has to be repeated, which is gross, but I can live with that.

Revised text:
The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and  <ins> MUST be discarded.  A value of 1 for this bit allows QUIC to coexist with other protocols; see RFC7983. </ins> The next two bits (those with a mask of 0x30) of byte 0 contain a packet type.  Packet types are listed in long-packet-types.
Original text:
The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and <del> MUST be discarded. </del>  The third most significant bit (0x20) of byte 0 is the latency spin bit, set as described in spin-bit.

Reviewer comments:
NAME said:
This particular choice has not a lot to do with QUIC and would therefore bring in a lot of non-sequitur references, but a single sentence won't hurt. It has to be repeated, which is gross, but I can live with that.

Revised text:
The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and  <ins> MUST be discarded.  A value of 1 for this bit allows QUIC to coexist with other protocols; see RFC7983. </ins> The third most significant bit (0x20) of byte 0 is the latency spin bit, set as described in spin-bit.
Original text:
newer encryption level are available. An endpoint cannot discard keys for a given encryption level unless <del> it has both received and acknowledged all CRYPTO frames for that encryption level and when all CRYPTO frames for that encryption level have been acknowledged by its peer.  However, this does not guarantee that no further packets will need to be received or sent at that </del>  encryption level because a peer might not have received all the <del> acknowledgments necessary to reach the same state. </del>  Though an endpoint might retain older keys, new data MUST be sent at the highest currently-available encryption level.  Only ACK frames

Reviewer comments:
The three points are wordy enough it might be worth making this a bulleted list, however. Thoughts?
NAME said:
With NAME fixes, this is good.

Revised text:
newer encryption level are available. An endpoint cannot discard keys for a given encryption level unless  <ins> it has received all the cryptographic handshake messages from its peer at that encryption level and its peer has done the same. Different methods for determining this are provided for Initial keys (discard-initial) and Handshake keys (discard-handshake).  These methods do not prevent packets from being received or sent at that </ins> encryption level because a peer might not have received all the  <ins> acknowledgments necessary. </ins> Though an endpoint might retain older keys, new data MUST be sent at the highest currently-available encryption level.  Only ACK frames