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

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Dec 2019 08:14:05 -0800

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2019 18:23:00 -0800

martinthomson commented on this pull request.

Of note here is that we allow Initial packets to be smaller than 1200 bytes, as long as they are coalesced with other stuff to make up a 1200 byte UDP datagram.  That too is vulnerable to this sort of composition problem.  I think that it's fine to make these assumptions and risk modification as long as they are recognized as such.  For Initial, we are doing so on the understanding that elements on the path are able to disrupt the handshake at that point anyway.  For PMTUD, we might make a different assessment as the conditions are different.

-- 
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#discussion_r356375759