Subject: [quicwg/base-drafts] Allow reuse of stateless reset tokens (#2733)

From: Martin Thomson <[email-masked]>
Date: Tue, 21 May 2019 02:03:26 -0700

This came up as the result of an incomplete implementation, but there
are - maybe - good reasons to have the same stateless reset token being
used for multiple connection IDs on the same connection.

There are drawbacks however.  Reuse of a stateless reset token means
that you have to remember (and consistently route) connection IDs, even
when they are retired.

This text makes a note of the possibility and explains the drawbacks.

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

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

-- Commit Summary --

  * Allow reuse of stateless reset tokens

-- File Changes --

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

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 21 May 2019 02:34:22 -0700

mikkelfj commented on this pull request.

> @@ -2476,6 +2476,14 @@ the same static key (see {{reset-oracle}}).  A connection ID from a connection
 that is reset by revealing the Stateless Reset Token MUST NOT be reused for new
 connections at nodes that share a static key.
 
+The same Stateless Reset Token MAY be used for multiple connection IDs on the
+same connection.  An endpoint that reuses a Stateless Reset Token MUST ensure
+that any connection ID used on the connection is matched to the active
+connection, including any routing performed at load balancers, even when a
+connection ID has been retired.  Otherwise, an attacker might be able to send a
+packet with a retired connection ID and cause the endpoint to produce a
+Stateless Reset.
+
 Note that Stateless Reset packets do not have any cryptographic protection.

I don't understand this text. I can see the issuer of the reset can and should coordinate with load balancers, but the text reads as if the sender is responsible for the receiver matching up the connection ID, or that an active connection should be matched sender side when the reset is transmitted to cancel an unknown connection, which by definition isn't possible. In part it is unclear what is mean by connection ID since there are two kinds.

-- 
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/2733#pullrequestreview-239930816

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 21 May 2019 03:11:50 -0700

kazuho approved this pull request.

LGTM.

Quicly was originally implemented this way, though we stopped doing that.

When an endpoint construct a CID as an encrypted tuple of (conn_id<sup>1</sup>, path_id), there's no need to regenerate a token for every new path ID being generated.

1: An ID that identifies a QUIC connection. Not the CID that appears on the wire.

-- 
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/2733#pullrequestreview-239950057

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 May 2019 02:41:58 -0700

@martinthomson pushed 1 commit.

a5bcc0b9f5c00113a15b32bac26db9d148c4bcb3  Fixup of reset-oracle links

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 May 2019 08:00:22 -0700

mnot commented on this pull request.

@mikkelfj can you clarify what this comment is in relation to?

-- 
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/2733#discussion_r286537644

---

From: Eric Kinnear <[email-masked]>
Date: Wed, 22 May 2019 08:00:26 -0700

erickinnear commented on this pull request.

+The same Stateless Reset Token MAY be used for multiple connection IDs on the
+same connection.  An endpoint that reuses a Stateless Reset Token MUST ensure
+that any connection ID associated with the reused value is correlated with to

```suggestion
that any connection ID associated with the reused value is correlated with
```
(remove extra word)

-- 
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/2733#pullrequestreview-240691470

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 May 2019 08:02:36 -0700

6d614fa63d5293e59d78777068658c24b5fe1919  Edit for clarity

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2733/files/a5bcc0b9f5c00113a15b32bac26db9d148c4bcb3..6d614fa63d5293e59d78777068658c24b5fe1919

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 May 2019 08:10:04 -0700

5201e2e0524413b885af92c93245f98caef1675c  More editorial hacking; this is complex

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2733/files/6d614fa63d5293e59d78777068658c24b5fe1919..5201e2e0524413b885af92c93245f98caef1675c

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 May 2019 08:10:23 -0700

martinthomson commented on this pull request.

I've tweaked the text (there was a grammatical error), but I think that this was related to the change.  It was a minor editorial thing.  It's really hard to get this right.

-- 
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/2733#discussion_r286542720

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 08:17:20 -0700

The text has been changed since I wrote the above, but largely:

> An endpoint that reuses a Stateless Reset Token MUST ensure
that any connection ID associated with the reused value is correlated with to
the active connection, even when the connection ID has been retired.

It is not entirely clear what timeframe this pertains to. There is time where the an unknown packet is received and the connection is active from the peers perspective but no longer used from the receivers perspective. And there is the time where the token is issued during connection establishment or path migration. The latter is the intent, but it is not easy to read.

It could perhaps be formulated like

A Stateless Reset Token MUST be unique to a single connection. The same token MAY be reissued for different Connection ID's on the same connection when it can be guaranteed that they all route to the same endpoint for the duration of the connection even after a Connection ID has been retired.

-- 
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/2733#discussion_r286546409

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 May 2019 08:45:22 -0700

That doesn't quite work because it is OK to forget a connection ID if the associated stateless reset token is no longer in use.  Maybe I need to try again.

-- 
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/2733#discussion_r286560870

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 May 2019 08:51:26 -0700

b645d79f3fafce73b96af5b2c3bcf7368f7a2571  Try again

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2733/files/5201e2e0524413b885af92c93245f98caef1675c..b645d79f3fafce73b96af5b2c3bcf7368f7a2571