Add initial threat model to security considerations

draft-ietf-quic-transport.md

@@ -5889,66 +5889,60 @@ considered separately.
 The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the
 cryptographic properties described in {{?RFC8446}}; Appendix E.1.
 
-In addition to those properties, the QUIC handshake is intended to provide
-some defense against DoS attacks on the handshake, as described below.
+In addition to those properties, the QUIC handshake is intended to provide some
+defense against DoS attacks on the handshake, as described below.
 
 #### Anti-Amplification
 
-Because the QUIC handshake can occur without a transport-level
-round-trip, the QUIC server's first flight may be sent to a client
-whose address it cannot validate. This flight may be long and
-therefore potentially allows the server to be used as a DoS
-reflector/amplifier. The mechanisms described in {{validate-handshake}}
-restrict the amplification to a factor of three.
+Because the QUIC handshake can occur without a transport-level round-trip, the
+QUIC server's first flight may be sent to a client whose address it cannot
+validate.  This flight may be long and therefore potentially allows the server
+to be used as a DoS reflector/amplifier.  The mechanisms described in
+{{validate-handshake}} restrict the amplification to a factor of three.
 
 #### Server-Side DoS
 
-Computing the server's first flight for a full handshake is
-potentially expensive, requiring both a signature and a key exchange
-computation. In order to prevent computational DoS attacks, QUIC
-incorporates a cheap token exchange mechanism which allows servers to
-validate a client's IP address prior to doing any expensive
-computations at the cost of a single round trip.  After a successful
-handshake, servers can issue new tokens to a client which will allow
+Computing the server's first flight for a full handshake is potentially
+expensive, requiring both a signature and a key exchange computation.  In order
+to prevent computational DoS attacks, QUIC incorporates a cheap token exchange
+mechanism which allows servers to validate a client's IP address prior to doing
+any expensive computations at the cost of a single round trip.  After a
+successful handshake, servers can issue new tokens to a client which will allow
 new connection establishment without incurring this cost.
 
 
 #### On-Path Handshake Termination
 
 [[TODO: Move the definitions upward after the other PR lands.]]
 
-An on-path attacker can force the QUIC handshake to fail by replacing
-either the client or server Initial messages with invalid ones. An
-off-path attacker can also mount this attack by racing the Initials.
-Once valid Initial messages have been exchanged, the remaining
-handshake messages are protected with the handshake keys and an
-on-path attacker cannot force handshake failure, though they can
-produce a handshake timeout by dropping packets.
+An on-path attacker can force the QUIC handshake to fail by replacing either the
+client or server Initial messages with invalid ones.  An off-path attacker can
+also mount this attack by racing the Initials.  Once valid Initial messages have
+been exchanged, the remaining handshake messages are protected with the
+handshake keys and an on-path attacker cannot force handshake failure, though
+they can produce a handshake timeout by dropping packets.
 
-An on-path attacker can also replace the addresses of packets on
-either side and therefore cause the client or server to have an
-incorrect view of the remote addresses.
+An on-path attacker can also replace the addresses of packets on either side and
+therefore cause the client or server to have an incorrect view of the remote
+addresses.
 
 #### Parameter Negotiation
 
-The entire handshake is cryptographically protected, with the
-Initial packets being encrypted with per-version keys and the
-Handshake and later packets being encrypted with keys derived
-from the TLS key exchange. Further, parameter negotiation is
-folded into the TLS transcript and thus provides the same
-security guarantees as ordinary TLS negotiation. Thus, an
-attacker can observe the client's transport parameters
-(as long as it knows the QUIC version-specific salt) but cannot
-observe the server's transport paramaters and cannot influence
+The entire handshake is cryptographically protected, with the Initial packets
+being encrypted with per-version keys and the Handshake and later packets being
+encrypted with keys derived from the TLS key exchange.  Further, parameter
+negotiation is folded into the TLS transcript and thus provides the same
+security guarantees as ordinary TLS negotiation.  Thus, an attacker can observe
+the client's transport parameters (as long as it knows the QUIC version-specific
+salt) but cannot observe the server's transport parameters and cannot influence
 parameter negotiation.
 
-Connection IDs are unencrypted but integrity protected
-in all messages. They are not incorporated in the TLS
-handshake transcript.
+Connection IDs are unencrypted but integrity protected in all messages.  They
+are not incorporated in the TLS handshake transcript.
 
-This version of QUIC does not incorporate a version negotiation
-mechanism; implementations of QUIC with incompatible versions
-will simply fail to negotiate.
+This version of QUIC does not incorporate a version negotiation mechanism;
+implementations of QUIC with incompatible versions will simply fail to
+negotiate.
 
 
 ### Short Headers {#short-headers-properties}
@@ -5962,8 +5956,7 @@ transition between IP addresses and ports on multiple paths, using one path at a
 time for transmission and receipt of non-probing frames.  Path validation
 ({{migrate-validate}}) establishes that a peer is both willing and able
 to receive packets sent on a particular path.  This helps reduce the effects of
-address spoofing, by limiting the number of packets sent to a spoofed address,
-unless an attacker is able to also receive packets sent to that address.
+address spoofing by limiting the number of packets sent to a spoofed address.
 
 This section describes the intended security properties of connection migration
 when under various types of attack, as described in more detail by {{?RFC3552}}.
@@ -5973,12 +5966,13 @@ attackers having the capability to read packets from the network and active
 attackers having the capability to write packets into the network.
 
 Attackers are additionally categorized as either on-path attackers or off-path
-attackers (see Section 3.5 of {{?RFC3552}}); an on-path attacker is on the
-critical path for a given connection and 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. An off-path attacker can transmit arbitrary
-packets, and it may be able to attack the network so as to place itself on-path.
+attackers; see Section 3.5 of {{?RFC3552}}.  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.  An off-path
+attacker can also transmit arbitrary packets.  Properties of connection
+migration allow an off-path attacker to place itself on path by sending packets
+under certain narrow conditions.
 
 
 #### Passive Attacks
@@ -6013,7 +6007,8 @@ protection ensures that valid packets are only generated by endpoints which
 possess the key material established during the handshake.  Similarly, any
 active attacker that observes QUIC packets and attempts to insert new data or
 modify existing data in those packets should not be able to generate packets
-deemed valid by the receiving endpoint.
+deemed valid by the receiving endpoint.  QUIC endpoints ignore invalid packets
+and receipt of an invalid packet does not cause a connection to close.
 
 However, an attacker can modify the boundaries between QUIC packets and UDP
 datagrams, causing multiple packets to be coalesced into a single datagram, or
@@ -6057,7 +6052,7 @@ to be dropped by the receiving endpoint as invalid, as QUIC payloads are both
 authenticated and encrypted.
 
 In the presence of an on-path attacker, QUIC aims to provide the following
-properties.
+properties:
 
 1. An on-path attacker can prevent use of a path for a QUIC connection, causing
 it to fail if it cannot migrate to a new path that does not contain the
@@ -6113,7 +6108,7 @@ state, potentially both causing an endpoint to lose its NAT binding, and an
 attacker to obtain the same port for use with its traffic.
 
 In the presence of an off-path attacker, QUIC aims to provide the following
-properties.
+properties:
 
 1. An off-path attacker can race packets and attempt to become a "limited"
 on-path attacker.
@@ -6157,19 +6152,19 @@ A limited on-path attacker can:
 
 A limited on-path attacker cannot:
 
-- Delay packets beyond the original packet duration
+- Delay packets so that they arrive later than packets sent on the original path
 - Drop packets
 - Modify the authenticated and encrypted portion of a packet and cause the
  recipient to accept that packet
 
 A limited on-path attacker can only delay packets up to the point that the
 original packets arrive before the duplicate packets, meaning that it cannot
-offer worse routing than the original path, only improved routing.  If a limited
-on-path attacker drops packets, the original copy will still arrive at the
-destination endpoint.
+offer routing with worse latency than the original path.  If a limited on-path
+attacker drops packets, the original copy will still arrive at the destination
+endpoint.
 
 In the presence of a limited on-path attacker, QUIC aims to provide the
-following properties.
+following properties:
 
 1. A limited on-path attacker cannot cause an active connection to close.