Consistency in off-path usage: -transport

draft-ietf-quic-transport.md

@@ -4258,8 +4258,9 @@ Path Maximum Transmission Unit Discovery (PMTUD; {{!RFC1191}}, {{!RFC8201}})
 relies on reception of ICMP messages (e.g., IPv6 Packet Too Big 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 to off-path attacks that successfully guess the
-addresses used on the path and reduce the PMTU to a bandwidth-inefficient value.
+is potentially vulnerable to attacks by elements 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.
 
 An endpoint MUST ignore an ICMP message that claims the PMTU has decreased below
 QUIC's smallest allowed maximum datagram size.
@@ -4271,7 +4272,7 @@ actually be smaller, or the information unintelligible, as described in Section
 1.1 of {{!DPLPMTUD}}.
 
 QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect from
-off-path injection as specified in {{!RFC8201}} and Section 5.2 of {{!RFC8085}}.
+packet injection as specified in {{!RFC8201}} and Section 5.2 of {{!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}}).  ICMP message validation MUST include matching
@@ -4648,8 +4649,8 @@ packet it receives in the Destination Connection ID field.  The value for Source
 Connection ID MUST be copied from the 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 the Version Negotiation packet was not generated by an off-path
-attacker.
+and that the Version Negotiation packet was not generated by an entity that
+did not receive the Initial packet.
 
 Future versions of QUIC could have different requirements for the lengths of
 connection IDs. In particular, connection IDs might have a smaller minimum
@@ -4727,7 +4728,7 @@ 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 provide confidentiality or
 integrity against on-path attackers, but provides some level of protection
-against off-path attackers.
+against attackers that cannot also receive packets.
 
 The client and server use the Initial packet type for any packet that contains
 an initial cryptographic handshake message. This includes all cases where a new
@@ -4935,9 +4936,9 @@ from the server, it MUST discard any subsequent Retry packets that it receives.
 
 Clients MUST discard Retry packets that have a Retry Integrity Tag that cannot
 be validated; see the Retry Packet Integrity section of {{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.
+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.
 
 The client responds to a Retry packet with an Initial packet that includes the
 provided Retry Token to continue connection establishment.