Re: [quicwg/base-drafts] Add initial threat model to security considerations (#2925)

[Mike Bishop <[e-mail]>]

MikeBishop approved this pull request.

Looking great.  Minor editorial nitpicks, and one which might turn into a separate issue.

> @@ -5874,6 +5874,288 @@ decisions are made independently of client-selected values; a Source Connection
 ID can be selected to route later packets to the same server.
 
 
+## Overview of Security Properties {#security-properties}
+
+A complete security analysis of QUIC is outside the scope of this document.
+This section provides an informal description of the desired security properties
+as an aid to implementors and to help guide protocol analysis.
+
+QUIC provides protection against various types of attacks, as described in more

```suggestion
QUIC provides protection against various types of attacks, which are described in more
```
As written, this sentence reads as if 3552 describes how QUIC protects against the attacks, rather than describing the attacks themselves.  (Note you'll probably need to rewrap after accepting the suggestion; sorry.)

> @@ -5874,6 +5874,288 @@ decisions are made independently of client-selected values; a Source Connection
 ID can be selected to route later packets to the same server.
 
 
+## Overview of Security Properties {#security-properties}
+
+A complete security analysis of QUIC is outside the scope of this document.
+This section provides an informal description of the desired security properties
+as an aid to implementors and to help guide protocol analysis.
+
+QUIC provides protection against various types of attacks, as described in more
+detail by {{?RFC3552}}.
+
+For this purpose, attacks are divided into passive and active attacks, passive

```suggestion
For this purpose, attacks are divided into passive and active attacks. Passive
```

> @@ -5874,6 +5874,288 @@ decisions are made independently of client-selected values; a Source Connection
 ID can be selected to route later packets to the same server.
 
 
+## Overview of Security Properties {#security-properties}
+
+A complete security analysis of QUIC is outside the scope of this document.
+This section provides an informal description of the desired security properties
+as an aid to implementors and to help guide protocol analysis.
+
+QUIC provides protection against various types of attacks, as described in more
+detail by {{?RFC3552}}.
+
+For this purpose, attacks are divided into passive and active attacks, passive
+attackers having the capability to read packets from the network and active

```suggestion
attackers have the capability to read packets from the network, while active
```

> @@ -5874,6 +5874,288 @@ decisions are made independently of client-selected values; a Source Connection
 ID can be selected to route later packets to the same server.
 
 
+## Overview of Security Properties {#security-properties}
+
+A complete security analysis of QUIC is outside the scope of this document.
+This section provides an informal description of the desired security properties
+as an aid to implementors and to help guide protocol analysis.
+
+QUIC provides protection against various types of attacks, as described in more
+detail by {{?RFC3552}}.
+
+For this purpose, attacks are divided into passive and active attacks, passive
+attackers having the capability to read packets from the network and active
+attackers having the capability to write packets into the network.  However, a

```suggestion
attackers also have the capability to write packets into the network.  However, a
```

> +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
+
+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.

Is it worth noting that this is indistinguishable from the presence of a NAT?

> +{{handshake-properties}}.  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.
+
+A spoofing attack, in which an active attacker rewrites unprotected parts of a
+QUIC packet that it forwards or injects, such as the source or destination
+address, is only effective if the attacker can forward packets to the original
+endpoint.  Packet protection ensures that the packet payloads can only be
+processed by the endpoints that completed the handshake, and invalid QUIC
+packets are ignored by those endpoints.
+
+An attacker can also modify the boundaries between QUIC packets and UDP
+datagrams, causing multiple packets to be coalesced into a single datagram, or
+splitting coalesced packets into multiple datagrams.  Such modification has no
+functional effect on a QUIC connection, although it might change the performance
+characteristics exhibited by the receiving endpoint.

Good observation.  I remember having discussions about heuristics that assume packets sent in a single datagram arrived together.  This means those heuristics aren't reliable.  I don't recall whether we endorsed such approaches in the document (PMTU probing, maybe?), but this suggests that we might want to explicitly caution against them.  (Not necessarily here.)

> +present between the QUIC client and server, and a QUIC endpoint is required to
+send packets through this attacker to establish connectivity on a given path.
+
+An on-path attacker can:
+
+- Inspect packets
+- Modify IP and UDP packet headers
+- Inject new packets
+- Delay packets
+- Reorder packets
+- Drop packets
+- Split and merge datagrams along packet boundaries
+
+An on-path attacker cannot:
+
+- Modify an authenticated and encrypted portion of a packet and cause the

```suggestion
- Modify an authenticated portion of a packet and cause the
```
The rejection of modified packets doesn't depend on the encryption, but the authentication.  The encryption itself is mostly irrelevant to this assertion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2925#pullrequestreview-329932408