Subject: [quicwg/base-drafts] Add initial threat model appendix (#2925)

From: Eric Kinnear <[email-masked]>
Date: Mon, 22 Jul 2019 22:00:08 -0700

This adds an appendix for a QUIC threat model, filling in only the migration section (for #2143, some of the rest of the threat model will come in #2387).

Some wordsmithing can be applied here, and we may want additional issues to fill out detailed descriptions of some of the worst attacks and outline heuristics that might help, but for now I'm focusing this purely on documenting what's possible/not possible for an attacker to do today.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2925

-- Commit Summary --

  * Initial threat model appendix

-- File Changes --

    M draft-ietf-quic-transport.md (171)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2925.patch
https://github.com/quicwg/base-drafts/pull/2925.diff

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

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 22 Jul 2019 22:06:24 -0700

@erickinnear pushed 1 commit.

c22e24fb18b952d4ce2ceb7447d5d8c355c2508a  Fix typo

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

---

From: Nick Banks <[email-masked]>
Date: Tue, 23 Jul 2019 05:38:10 -0700

nibanks commented on this pull request.

> +properties as an aid to implementors and to help guide protocol analysis.
+
+We cover properties of the handshake, general transport, and migration
+separately.
+
+## Handshake {#handshake-properties}
+
+TBD.
+
+## Short Headers {#short-headers-properties}
+
+TBD.
+
+## Connection Migration {#migration-properties}
+
+Connection Migration ({{migration}}) provides endpoints with the ability to

I don't think this intro paragraph is really necessary.

> @@ -5753,13 +5753,184 @@ DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
    return candidate_pn
 ~~~
 
+# Overview of Security Properties {#security-properties}
+
+A complete security analysis of QUIC is outside the scope of this document.  In
+this appendix, we provide an informal description of the desired security
+properties as an aid to implementors and to help guide protocol analysis.
+
+We cover properties of the handshake, general transport, and migration
+separately.
+
+## Handshake {#handshake-properties}

Maybe a 0-RTT section as well?

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 23 Jul 2019 05:56:51 -0700

erickinnear commented on this pull request.

    return candidate_pn
 ~~~

Makes sense, good thinking! 
Probably others that might be interesting, too, not sure if it's worth adding a bunch of TBD sections, but definitely should have an issue covering writing up the 0-RTT section.

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 23 Jul 2019 08:48:56 -0700

Upcoming change to terminology here as well, just as a note.

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

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 26 Jul 2019 06:14:34 -0700

dtikhonov commented on this pull request.

    return candidate_pn
 ~~~

I'd drop the use of "we."  In the whole `draft-ietf-quic-transport-22`, for instance, the word "we" is encountered only once, while RFC 7540 and 7541 contain no instances of this pronoun.

I suggest instead:
- _This appendix provides and informal description..._; and
- _Handshake, ...etc. are covered separately_.

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Jul 2019 07:47:54 -0700

MikeBishop approved this pull request.

    return candidate_pn
 ~~~

...and perhaps file an issue for that other use of "we."

+An on-path attacker is present between the QUIC client and server, and an
+endpoint is required to send packets through this attacker to establish
+connectivity on a given path.
+
+An on-path attacker can:
+
+- Inspect packets
+- Modify unencrypted packet headers
+- Inject new packets
+- Delay packets
+- Drop packets
+
+An on-path attacker cannot:
+
+- Modify encrypted packet payloads

Well, they can, but the packets will no longer be accepted as valid, which is part of this threat model and mitigation.  Also, you don't discuss the unencrypted, but authenticated, portions of the headers.  Perhaps you should frame the capabilities in terms of what they can do to authenticated portions of the packet, and note that the payload is both encrypted *and* authenticated?

> +or other methods.
+
+2. An on-path attacker can prevent migration to a new path for which the
+attacker is also on-path by causing path validation to fail on the new path.
+
+3. An on-path attacker cannot prevent a client from migrating to a path for
+which the attacker is not on-path.
+
+4. An on-path attacker can reduce the throughput of a connection by delaying
+packets or dropping them.
+
+
+### Off-Path Attacker
+
+An off-path attacker is not directly on the path between the QUIC client and
+server, but is able to obtain copies of all packets sent between the client and

Perhaps change this to "may be able to obtain copies of some or all packets sent between the client and the server"?  Certainly there are subclasses of off-path attackers who see no traffic (inject-only) or who get only a partial view (e.g. eavesdropping on only one direction, one path, etc.).

> +- Delay packets
+- Drop packets
+
+An off-path attacker can, however, modify packets that it has observed and
+inject them back into the network, potentially with spoofed source and
+destination addresses.
+
+For the purposes of this discussion, we assume 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, the 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.
+
+We also assume that the attacker has the resources necessary to affect NAT
+state, potentially both causing an endpoint to lose its NAT binding, and an

Pick "the" or "an" here.  Jumping back and forth is throwing me; if there's a pattern, I'm not able to intuit it.

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