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

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 16:46:51 -0700

erickinnear commented on this pull request.

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

Removed all of the "we" from this diff, great suggestions as well, thanks!

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 16:47:11 -0700

+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

Updated this a bit, I suspect further discussion will also be in the security properties of short/long headers.

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 16:50:41 -0700

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

Updated, very good point, I think here I'm focusing mostly on the worst-case type of behavior (for example, assume an attacker can _always_ win a race), but I think there would be room to cover additional situations, both in the case where that changes the considerations or simply as a note that "these people also fall into this bucket".

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 16:53:11 -0700

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

I've changed some "the attacker" to "an attacker" to be more specific, we've got "an" for endpoint everywhere except one place where it's a packet between "the endpoints" that are having a conversation. 

There's a few places where we say something along the lines of 
> 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.

Which is a case where we use both "an" and "the", but otherwise it's all the same now. (And suggestions welcome for those cases, it started to sound very wrong when I switched those around.)

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 16:53:26 -0700

> +separately.
+
+## Handshake {#handshake-properties}
+
+TBD.
+
+## Short Headers {#short-headers-properties}
+
+TBD.
+
+## 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 sending non-probing frames.  Path validation helps to establish
+bidirectional connectivity with the peer over a new path and prevents source

Updated with that text, much nicer, thanks!

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 16:53:34 -0700

+
+TBD.
+
+## Short Headers {#short-headers-properties}
+
+TBD.
+
+## 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 sending non-probing frames.  Path validation helps to establish
+bidirectional connectivity with the peer over a new path and prevents source
+address spoofing from being used in a denial-of-service attack.  Migration is
+further restricted to be initiated only by QUIC clients.

Removed

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 16:53:55 -0700

> +attacks, requiring injection of packets into the network, as described in
+{{?RFC3552}}.
+
+### On-Path Attacker
+

Good point! Hopefully we'll catch some other cases that got left out like this one -- I've added 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#discussion_r320523701

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 16:54:03 -0700

+This section describes the intended security properties of connection migration
+when under attack by the following attackers.  These attackers all mount active
+attacks, requiring injection of packets into the network, as described in
+{{?RFC3552}}.
+
+### On-Path Attacker
+
+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

Nice, updated

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 16:54:33 -0700

+
+- Inspect packets
+- Modify unencrypted packet headers
+- Inject new packets
+- Delay packets
+- Drop packets
+
+An on-path attacker cannot:
+
+- Modify encrypted packet payloads
+
+In the presence of an on-path attacker, QUIC aims to provide the following
+properties.
+
+1. An on-path attacker can interrupt a QUIC connection, causing it to fail if it

Reworded this to be a bit more clear about exactly what's getting broken (that path, not the whole thing). 

The establishment case I think I'm going to leave for the section on the handshake here.

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 18:21:30 -0700

@erickinnear pushed 3 commits.

9f3b4214e6e96a57a66cb9cff7e995528cbcd450  Review comments
3610a785d1a7289d2add2775d2b8ae43aaa5cc5f  Move under security considerations
285020522eb63efa392c1fbdfe66898136ef7111  Remove other "we" instances

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 18:22:10 -0700

return candidate_pn
 ~~~

Two thoughts here: 
- This was an appendix since TLS 1.3 did it as an appendix. It's kind of nice that way, since we're documenting what we believe the rest of the document says, not introducing any new attacks or mitigations that shouldn't already have been covered above.
- From a purely aesthetic perspective, having 21.11.3.2. as a section means that I refer to one of these items as: 
> Section 21.11.3.2., point 3.

All that said, I've moved this to the last section in Security Considerations for the time being, and I don't have a super strong opinion on where it finally lands. :)
TLS is also a little bit different in that most of the document is a security consideration in one way or another, so some of the reasoning that resulted in structure there is not necessarily reflected in QUIC.

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 03 Sep 2019 18:25:28 -0700

@erickinnear pushed 1 commit.

0ba5b02857f64d231a7ece491c9d26dd5a0b353a  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/285020522eb63efa392c1fbdfe66898136ef7111..0ba5b02857f64d231a7ece491c9d26dd5a0b353a

---

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Sep 2019 10:57:58 -0700

MikeBishop commented on this pull request.

    return candidate_pn
 ~~~

It seems worth excerpting RFC 3552:
> While it is not a requirement that any given protocol or system be immune to all forms of attack, it is still necessary for authors to consider as many forms as possible.  Part of the purpose of the Security Considerations section is to explain what attacks are out of scope and what countermeasures can be applied to defend against them.
>
> There should be a clear description of the kinds of threats on the described protocol or technology.  This should be approached as an effort to perform "due diligence" in describing all known or foreseeable risks and threats to potential implementers and users.
>
> Authors MUST describe
>
>    1.   which attacks are out of scope (and why!)
>    2.   which attacks are in-scope
>          1.  and the protocol is susceptible to
>          2.  and the protocol protects against
>
> At least the following forms of attack MUST be considered:  eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle.  Potential denial of service attacks MUST be identified as well.  If the protocol incorporates cryptographic protection mechanisms, it should be clearly indicated which portions of the data are protected and what the protections are (i.e., integrity only, confidentiality, and/or endpoint authentication, etc.).  Some indication should also be given to what sorts of attacks the cryptographic protection is susceptible.  Data which should be held secret (keying material, random seeds, etc.) should be clearly labeled.

In other words, this reads a lot like a Security Considerations 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_r320895221

---

From: ianswett <[email-masked]>
Date: Tue, 17 Sep 2019 15:36:32 -0700

As commented on the issue, this should fix #2387 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#issuecomment-532428753

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 23 Sep 2019 00:53:51 -0700

@erickinnear pushed 2 commits.

5e14c63697de9794cbc3cff171b1df481a45d6d3  Merge branch 'master' into ek/migration_threat_model
510536d8109fe5635c7bf86566368b20fbcf2b66  Update with modified terminology and new text around active and passive attacks

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

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 23 Sep 2019 00:58:23 -0700

Added a few paragraphs describing general active and passive attacks in the context of RFC 3552 and more clearly defined off-path and on-path attackers to follow the definition established by that document. This will likely still take some iteration, but it should be mostly ready for that, comments welcome!

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

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 23 Sep 2019 00:58:53 -0700

return candidate_pn
 ~~~

Thanks! I've moved it up and updated the text to refer to it as such.

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

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 23 Sep 2019 01:01:12 -0700

5f80f8b12d669a1dad61c27ef18c84784892d5b9  Add reference and minor wording update.

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

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 23 Sep 2019 01:01:56 -0700

+

Open to moving it around / trimming it down a bit. Mostly I wanted a place so if you read this you've got links and references to the appropriate sections, but without going beyond a sentence or three.

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