Subject: [quicwg/base-drafts] Stateless reset oracle defense (#1554)

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 22:53:57 -0700

This enacts the plan discussed in #1386 and discussed in Kista.

Closes #1386.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Stateless reset oracle defense

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1554.patch
https://github.com/quicwg/base-drafts/pull/1554.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/1554

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Jul 2018 15:18:59 +0000 (UTC)

MikeBishop approved this pull request.

-- 
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/1554#pullrequestreview-136700775

---

From: ianswett <[email-masked]>
Date: Thu, 12 Jul 2018 18:25:28 +0000 (UTC)

ianswett commented on this pull request.

Looks good, some small suggestions.

> @@ -4722,6 +4719,37 @@ receiver, an off-path attacker will need to race the duplicate packet against
 the original to be successful in this attack.  Therefore, QUIC receivers ignore
 ECN codepoints set in duplicate packets (see {{using-ecn}}).
 
+## Stateless Reset Oracle {#reset-oracle}
+
+An attacker that can cause a server to emit a stateless reset token can cause
+any connection that uses the same connection ID and method of producing the
+token to be destroyed.  This creates a possible denial of service attack on

nit: destroyed?  Closed? Reset?

> +An attacker that can cause a server to emit a stateless reset token can cause
+any connection that uses the same connection ID and method of producing the
+token to be destroyed.  This creates a possible denial of service attack on
+existing connections if the attacker is able to cause a stateless reset token to
+be generated for a connection with a selected connection ID.  That is, an attack
+is possible if an attacker can alter packet routing so that a packet is received
+by an instance that uses the same stateless reset key, but no connection state
+for the connection ID.
+
+The only viable defense against this style of denial of service is to ensure
+that routing configuration for a cluster guarantees consistent routing of
+packets for a given connection ID.  That is, the routing needs to ensure that a
+stateless reset is not generated unless the associated connection (as identified
+by the connection ID) cannot proceed.
+
+For endpoints that operate in clusters, instances that share a static key for

This paragraph is largely an easier to read version of the paragraph that precedes it.  Can you combine them?  Maybe:

"To defend against this style of denial of service attack, endpoints in clusters that share a static stateless reset key (see {{reset-token}}) MUST be arranged..."

-- 
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/1554#pullrequestreview-136771824

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 12 Jul 2018 17:11:52 -0700

kazuho commented on this pull request.

+stateless reset is not generated unless the associated connection (as identified
+by the connection ID) cannot proceed.
+
+For endpoints that operate in clusters, instances that share a static key for
+stateless reset (see {{reset-token}}) MUST be arranged so that packets with a
+given connection ID always arrive at an instance that has connection state,
+unless that connection is no longer active.
+
+In the case of a cluster that uses dynamic load balancing, it's possible that a
+change in load balancer configuration could happen while an active instance
+retains connection state; even if an instance retains connection state, the
+change in routing and resulting stateless reset will result in the connection
+being terminated.  This is acceptable as long as the loss of connections during
+rebalancing is by design and not something that an external entity can
+influence.

I am not sure how the last sentence applies to the discussion in the paragraph.

If I understand correctly, the intent of the paragraph is to state that if there is no chance in the packet being routed to the correct server, it is logical to send a stateless reset rather than waiting for timeout. That is logical. However, the last sentence talks about frequency of rebalancing, which IMO is unrelated to whether if we send a reset or wait for timeout.

It seems to me that it might be a better idea to state here that, by using the rebalancing as an example, that sending stateless reset is preferable than waiting for timeout, and move the discussion about the frequency of rebalancing to somewhere else, since it is not an issue specific to QUIC having authenticated resets (TCP sharding using 5-tuple has the same issue).

-- 
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/1554#pullrequestreview-136871375

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jul 2018 18:48:44 -0700

@martinthomson pushed 1 commit.

c77cec3  Tweak language some more

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1554/files/5072146a9e653bfa1886606431f796af3cbec084..c77cec3da8f5ccf45d414f2b99ca13ae29ee2a56

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jul 2018 18:49:14 -0700

Thanks for the comments @kazuho, @ianswett.  Would you mind taking another look?

-- 
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/1554#issuecomment-408724666

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 29 Jul 2018 18:57:15 -0700

LGTM :+1: aside from one editorial issue (see my inline comment).

> @@ -4730,6 +4727,32 @@ receiver, an off-path attacker will need to race the duplicate packet against

"can cause force" -> "can force"?

-- 
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/1554#pullrequestreview-141373218

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jul 2018 19:02:06 -0700

b1e8dec  Oops

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

---

From: ianswett <[email-masked]>
Date: Mon, 30 Jul 2018 15:28:13 +0000 (UTC)

Some editorial suggestions

+## Stateless Reset Oracle {#reset-oracle}
+
+An attacker that can cause a server to emit a stateless reset token can force
+the closure of any connection that uses the same connection ID and method of
+producing the token.  This creates a possible denial of service attack on

I think of this as a reset injection attack.  Do you think denial of service is a better characterization?

+## Stateless Reset Oracle {#reset-oracle}
+
+An attacker that can cause a server to emit a stateless reset token can force
+the closure of any connection that uses the same connection ID and method of
+producing the token.  This creates a possible denial of service attack on
+existing connections if the attacker is able to cause a stateless reset token to
+be generated for a connection with a selected connection ID.  That is, an attack
+is possible if an attacker can alter packet routing so that a packet is received
+by an instance that uses the same stateless reset key, but no connection state
+for the connection ID.
+
+To defend against this style of denial service, endpoints that operate in
+clusters and that share a static key for stateless reset (see {{reset-token}})

I think "that operate in clusters and" is unnecessary.  If they share a static key for stateless reset, it's an issue.

+## Stateless Reset Oracle {#reset-oracle}
+
+An attacker that can cause a server to emit a stateless reset token can force
+the closure of any connection that uses the same connection ID and method of
+producing the token.  This creates a possible denial of service attack on

I find this paragraph difficult to read.  How about reordering it and rewording it slightly:

"Stateless resets create a possible denial of service(reset injection) attack on existing connections if an attacker is able to cause a stateless reset token to be generated for a connection with a selected connection ID.  An attacker that can cause this token to be generated and appear to be on-path can reset any active connection."

I'd move the concept from the last sentence to the end of the next paragraph.  "If a connection ID may be routed to different instances that share a static key, for example by changing the destination IP or port, then an attacker can cause the server to create a stateless reset token."

-- 
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/1554#pullrequestreview-141579246

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jul 2018 16:26:32 -0700

80f6c9c  Ian's suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1554/files/b1e8dec0e1d727af0b08221ccbf660f43aaa24c3..80f6c9c4030c8f7913c3a7039d6278a7e2034bef

---

From: ianswett <[email-masked]>
Date: Mon, 30 Jul 2018 17:15:03 -0700

> @@ -4729,18 +4729,23 @@ ECN codepoints set in duplicate packets (see {{using-ecn}}).
 
 ## Stateless Reset Oracle {#reset-oracle}
 
+Stateless resets create a possible denial of service attack analogous to a TCP
+reset injection. This attack is possible if an attacker is able to cause a
+stateless reset token to be generated for a connection with a selected
+connection ID. An attacker that can cause this token to be generated can reset
+an active connection with the same connection ID.
+
 An attacker that can cause a server to emit a stateless reset token can force

I think you can remove this paragraph now.  If there's something important here I'm missing, maybe work it into an adjacent paragraph.

-- 
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/1554#pullrequestreview-141762578

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jul 2018 17:29:21 -0700

bd8d09c  Remove text, yay

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1554/files/80f6c9c4030c8f7913c3a7039d6278a7e2034bef..bd8d09c2fb89cb4e0643eaacae1f3ebde1bc18a8

---

From: ianswett <[email-masked]>
Date: Mon, 30 Jul 2018 17:32:24 -0700

ianswett approved this pull request.

-- 
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/1554#pullrequestreview-141765293

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jul 2018 17:43:34 -0700

Merged #1554.

-- 
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/1554#event-1761550012