Original text:
messages) that indicate when an IP packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable <del> to off-path attacks that successfully guess the addresses used on the path and reduce the PMTU to a bandwidth-inefficient value. </del>  An endpoint MUST ignore an ICMP message that claims the PMTU has decreased below QUIC's smallest allowed maximum datagram size. unintelligible, as described in Section 1.1 of DPLPMTUD. QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect <del> from off-path injection as specified in RFC8201 and Section 5.2 of </del>  RFC8085.  This validation SHOULD use the quoted packet supplied in the payload of an ICMP message to associate the message with a corresponding transport connection (see Section 4.6.1 of DPLPMTUD). Destination Connection ID of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that <del> the Version Negotiation packet was not generated by an off-path attacker. </del>  Future versions of QUIC could have different requirements for the lengths of connection IDs.  In particular, connection IDs might have In order to prevent tampering by version-unaware middleboxes, Initial packets are protected with connection- and version-specific keys (Initial keys) as described in QUIC-TLS.  This protection does not <del> provide confidentiality or integrity against on-path attackers, but provides some level of protection against off-path attackers. </del>  The client and server use the Initial packet type for any packet that contains an initial cryptographic handshake message.  This includes Clients MUST discard Retry packets that have a Retry Integrity Tag that cannot be validated; see the Retry Packet Integrity section of <del> QUIC-TLS.  This diminishes an off-path attacker's ability to inject a Retry packet and protects against accidental corruption of Retry packets.  A client MUST discard a Retry packet with a zero-length Retry Token field. </del>  The client responds to a Retry packet with an Initial packet that includes the provided Retry Token to continue connection modification in the path taken by packets that comprise a connection. Attackers are additionally categorized as either on-path attackers or <del> off-path attackers; see Section 3.5 of SEC-CONS.  An on-path attacker can read, modify, or remove any packet it observes such that it no longer reaches its destination, while an off-path attacker observes the packets, but cannot prevent the original packet from reaching its intended destination.  Both types of attackers can also transmit arbitrary packets. </del>  Properties of the handshake, protected packets, and connection migration are considered separately. An off-path attacker cannot: <del> Modify any part of a packet </del>  Delay packets Reorder original packets <del> An off-path attacker can modify packets that it has observed and inject them back into the network, potentially with spoofed source and destination addresses. </del>  For the purposes of this discussion, it is assumed that an off-path <del> attacker has the ability to observe, modify, and re-inject a packet into the network that will reach the destination endpoint prior to the arrival of the original packet observed by the attacker.  In other words, an attacker has the ability to consistently "win" a race with the legitimate packets between the endpoints, potentially causing the original packet to be ignored by the recipient. </del>  It is also assumed that an attacker has the resources necessary to affect NAT state, potentially both causing an endpoint to lose its

Reviewer comments:
We weren't being consistent. This should help.
NAME said:
The first here is in the process of being addressed, see . I agree regarding "strong", but also agree regarding what to do about it. My proposal is to let close this issue.
NAME said:
Proposed resolution is URL
This is an improvement. Thanks.

Revised text:
messages) that indicate when an IP packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable  <ins> to attacks by entities that cannot observe packets but might successfully guess the addresses used on the path.  These attacks could reduce the PMTU to a bandwidth-inefficient value. </ins> An endpoint MUST ignore an ICMP message that claims the PMTU has decreased below QUIC's smallest allowed maximum datagram size. unintelligible, as described in Section 1.1 of DPLPMTUD. QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect  <ins> from packet injection as specified in RFC8201 and Section 5.2 of </ins> RFC8085.  This validation SHOULD use the quoted packet supplied in the payload of an ICMP message to associate the message with a corresponding transport connection (see Section 4.6.1 of DPLPMTUD). Destination Connection ID of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that  <ins> the Version Negotiation packet was not generated by an entity that did not observe the Initial packet. </ins> Future versions of QUIC could have different requirements for the lengths of connection IDs.  In particular, connection IDs might have In order to prevent tampering by version-unaware middleboxes, Initial packets are protected with connection- and version-specific keys (Initial keys) as described in QUIC-TLS.  This protection does not  <ins> provide confidentiality or integrity against attackers that can observe packets, but provides some level of protection against attackers that cannot observe packets. </ins> The client and server use the Initial packet type for any packet that contains an initial cryptographic handshake message.  This includes Clients MUST discard Retry packets that have a Retry Integrity Tag that cannot be validated; see the Retry Packet Integrity section of  <ins> QUIC-TLS.  This diminishes an attacker's ability to inject a Retry packet and protects against accidental corruption of Retry packets. A client MUST discard a Retry packet with a zero-length Retry Token field. </ins> The client responds to a Retry packet with an Initial packet that includes the provided Retry Token to continue connection modification in the path taken by packets that comprise a connection. Attackers are additionally categorized as either on-path attackers or  <ins> off-path attackers.  An on-path attacker can read, modify, or remove any packet it observes such that it no longer reaches its destination, while an off-path attacker observes the packets, but cannot prevent the original packet from reaching its intended destination.  Both types of attackers can also transmit arbitrary packets.  This definition differs from that of Section 3.5 of SEC- CONS in that an off-path attacker is able to observe packets. </ins> Properties of the handshake, protected packets, and connection migration are considered separately. An off-path attacker cannot:  <ins> Modify packets sent by endpoints </ins> Delay packets Reorder original packets  <ins> An off-path attacker can create modified copies of packets that it has observed and inject those copies into the network, potentially with spoofed source and destination addresses. </ins> For the purposes of this discussion, it is assumed that an off-path  <ins> attacker has the ability to inject a modified copy of a packet into the network that will reach the destination endpoint prior to the arrival of the original packet observed by the attacker.  In other words, an attacker has the ability to consistently "win" a race with the legitimate packets between the endpoints, potentially causing the original packet to be ignored by the recipient. </ins> It is also assumed that an attacker has the resources necessary to affect NAT state, potentially both causing an endpoint to lose its