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

From: Eric Kinnear <[email-masked]>
Date: Fri, 03 Jan 2020 08:25:03 -0800

@erickinnear pushed 1 commit.

b7191cdf616a0c04f1f7ca36d742770690137921  Merge branch 'master' into ek/migration_threat_model

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2925/files/8d2ed7162448e2c6527733a34e838335ebe24a3a..b7191cdf616a0c04f1f7ca36d742770690137921

---

From: Eric Kinnear <[email-masked]>
Date: Fri, 03 Jan 2020 08:40:31 -0800

02d0fe812f5785f4addaab15b1631e3f93202492  Apply @MikeBishop's suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2925/files/b7191cdf616a0c04f1f7ca36d742770690137921..02d0fe812f5785f4addaab15b1631e3f93202492

---

From: Eric Kinnear <[email-masked]>
Date: Fri, 03 Jan 2020 08:45:45 -0800

5950556834ddc60b30a21271e18d2a4b956b3acb  The rest of @MikeBishop's suggestions, rewrapped

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2925/files/02d0fe812f5785f4addaab15b1631e3f93202492..5950556834ddc60b30a21271e18d2a4b956b3acb

---

From: Eric Kinnear <[email-masked]>
Date: Fri, 03 Jan 2020 08:46:15 -0800

erickinnear commented on this pull request.

Thanks for the review @MikeBishop! Applied suggestions and rewrapping.

> @@ -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

Nice! No worries, rewrapped :)

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

Yes, great idea! Added a sentence here indicating that an attack here is indistinguishable from the presence of a NAT. (We've got a similar note about some of that later, but this is a great place to start people thinking in that direction.)

> +{{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 thinking, it might be worth a note around those rules in the Initial that such a thing is possible (and might be more likely than if you just padded the initial packet?). PMTUD is probably worth calling out a little bit more clearly -- I'll file an editorial issue for each, since that's way elsewhere.

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

This seems like a nice balance with the mention of both authentication and encryption in the later paragraph, while the specific capability is only around the authenticated portion.

-- 
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-338163909

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 13 Jan 2020 13:19:20 -0800

Anything else we want to do before this is ready to land?

-- 
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#issuecomment-573875718

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Jan 2020 22:05:34 -0800

martinthomson approved this pull request.

Reviewing the amended stuff.  All goodness, though I have a suggestion or two.

I think that @janaiyengar promised to take another look at this, but for me I'm getting tired of staring at this.  I want to merge this very soon.

+#### 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
+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 messages.  An off-path attacker
+can also mount this attack by racing the Initials.  Once valid Initial messages

As I said elsewhere, this could be simplied to:

> An on-path or off-path attacker can force the QUIC handshake to fail by replacing or racing Initial packets.  Once valid Initial packets [...]

Note: "packet" and not "message".

+Attackers are additionally categorized as either on-path attackers or off-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 the handshake, protected packets, and connection migration are
+considered separately.
+
+
+### Handshake {#handshake-properties}
+
+The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the
+cryptographic properties described in {{?RFC8446}}; Appendix E.1.

```suggestion
cryptographic properties described in {{?TLS13=RFC8446}}; Appendix E.1.
```

+### Handshake {#handshake-properties}
+
+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.
+
+#### 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.

Maybe instead:

> Address validation ({{address-validation}}) is used to verify that an entity that claims a given address is able to receive packets at that address.  Address validation limits amplification attack targets to addresses for which an attacker is either on-path or off-path.
>
> Prior to validation, endpoints are limited in what they are able to send.  During the handshake, a server cannot send more than three times the data it receives; clients that initiate new connections or migrate to a new network path are limited to [um, I can't find a concrete limit in the document].

> +protection ensures that valid packets are only generated by endpoints which
+possess the key material established during the handshake; see {{handshake}} and

```suggestion
splitting coalesced packets into multiple datagrams.  Aside from datagrams containing Initial packets, which require padding, modification has no
```

-- 
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-345645852

---

From: ianswett <[email-masked]>
Date: Tue, 21 Jan 2020 09:17:39 -0800

ianswett approved this pull request.

Some suggestions, but nothing concerning, so LG.

+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. Such an attack is indistinguishable from the functions performed by a
+NAT.
+
+#### 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

nit: Is it a key exchange or message exchange?

> +addresses. Such an attack is indistinguishable from the functions performed by a
+NAT.
+
+#### 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 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.

This is potentially misleading, since there is the original_connection_id transport param, but I'm not sure if it's worth mentioning.

@MikeBishop In terms of relying on how packets were coalesced, I don't believe there's any reliable information to be obtained, and relying on these hueristics is already prone to cause problems.  For example, there's no guarantee that a receiver buffers the currently undecryptable packets in a datagram if it can decrypt at least one packet.  So yes, we should caution against that if we don't already.

> +### Connection Migration {#migration-properties}
+
+Connection Migration ({{migration}}) provides endpoints with the ability to
+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.
+
+This section describes the intended security properties of connection migration
+when under various types of DoS attacks.
+
+#### On-Path Active Attacks
+
+An attacker that can cause a packet it observes to no longer reach its intended
+destination is considered an on-path attacker.  Such an attacker generally is

generally is present is both a somewhat strong(implying >50% of the time) and quite vague statement.  Maybe this clause should be changed to: "When an attacker is present between the QUIC client and server, QUIC endpoints are required to send packets through the attacker to establish connectivity on a given path."?

+An on-path attacker cannot:
+
+- Modify an authenticated portion of a packet and cause the
+ recipient to accept that packet
+
+An on-path attacker has the opportunity to modify the packets that it observes,
+however any modifications to an authenticated portion of a packet will cause it
+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:
+
+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

I'm not sure it's necessary to use the word 'migrate' here.  If the handshake hasn't completed, you can't migrate yet.  If you take my suggestion, it probably makes sense to update the other bullets.

```suggestion
it to fail if it cannot use a different path that does not contain the
```

+For the purposes of this discussion, it is assumed that an off-path 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.
+
+It is also assumed that an attacker has the resources necessary to affect NAT
+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:
+
+1. An off-path attacker can race packets and attempt to become a "limited"

The word race is used a few times in this section, but I don't believe it's defined and I'm not sure it's clear to everyone what it means in this context?

+It is also assumed that an attacker has the resources necessary to affect NAT
+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:
+
+1. An off-path attacker can race packets and attempt to become a "limited"
+on-path attacker.
+
+2. An off-path attacker can cause path validation to succeed for forwarded
+packets with the source address listed as the off-path attacker as long as it
+can provide improved connectivity between the client and the server.
+
+3. An off-path attacker cannot cause a connection to close.

```suggestion
3. An off-path attacker cannot cause a connection to close once the handshake has completed.
```

+- 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 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:
+
+1. A limited on-path attacker cannot cause an active connection to close.

```suggestion
1. A limited on-path attacker cannot cause an established connection to close.
```

-- 
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-346016818

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 21 Jan 2020 14:56:21 -0800

janaiyengar approved this pull request.

+NAT.
+

I think this second sentence can be dropped.

-- 
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-346246474

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jan 2020 16:58:02 -0800

martinthomson commented on this pull request.

Just so everyone is clear on what is happening here, I've made a few changes and landed this.  This is obviously a lot of text and it could benefit from more review, but the editors all agreed that it would better to make incremental changes rather than continue to maintain our oldest open PR further.

+NAT.
+

Without further elaboration, I have to agree.  

Separately, I think it was Antoine who made some (good) points about authenticating connection IDs more thoroughly that we might want to consider.  Separately though (reminds self to open an issue).

Key exchange is correct (the key exchange depends on the message exchange, but it's the key exchange that matters here).

It's first use would seem to work well enough to be definitional.  I'm happy with this as it is.

-- 
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-346283685

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jan 2020 16:59:25 -0800

Merged #2925 into master.

-- 
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#event-2968333868

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 28 Jan 2020 16:50:02 -0800

Thanks Martin, and to all who reviewed! 
Definitely agree that further changes can be incremental editorial changes and that it's much nicer to land the main change.

-- 
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#issuecomment-579542937