Subject: [quicwg/base-drafts] Mandatory distinction between token types (#3128)

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2019 19:55:04 -0700

Closes #3127.

Question for reviewers: do you think it necessary to point out that this distinction doesn&#39;t need to be hidden from other entities?  That&#39;s almost obvious based on the way that this results in different behaviour from servers, but should it be written down?
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Mandatory distinction between token types

-- File Changes --

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

-- Patch Links --

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 21 Oct 2019 20:08:34 -0700

kazuho commented on this pull request.

> Question for reviewers: do you think it necessary to point out that this distinction doesn't need to be hidden from other entities?

Yes, I think doing so would help people understand the text. At the moment, in [section 8.1.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.8.1.1) we merely imply that a Retry token can be in cleartext. It is easy to miss that the bit used for the distinction can be in clear.

> @@ -1675,9 +1675,10 @@ one.  The client MUST NOT use the token provided in a Retry for future
 connections. Servers MAY discard any Initial packet that does not carry the
 expected token.
 
-A token SHOULD be constructed in a way that allows the server to distinguish it
-from tokens that are sent in Retry packets as they are carried in the same
-field.
+A token send in NEW_TOKEN frames MUST be constructed in a way that allows the

s/A token send/A token being sent/?

-- 
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/3128#pullrequestreview-304946898

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Oct 2019 03:17:58 +0000 (UTC)

@martinthomson pushed 1 commit.

47889736fe180f33c4951bbd60916278c7985329  Separate generic token construction requirements

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3128/files/7bed0b465944def7aee9349ea1b61bad09ce8f86..47889736fe180f33c4951bbd60916278c7985329

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 22 Oct 2019 03:50:14 +0000 (UTC)

> @@ -1623,6 +1623,20 @@ also constrained in what they can send by the limits set by the congestion
 controller.  Clients are only constrained by the congestion controller.

+### Token Construction
+
+Tokens sent in NEW_TOKEN frames or Retry packets MUST be constructed in a way
+that allows the server to identity how it was provided to a client.  These
+tokens are carried in the same field, but require different handling from
+servers.
+
+A token MUST NOT include information that would allow values to be linked by an

I think this requirement is specific to tokens used for validating future connections?

Therefore, something like "A token issued using NEW_TOKEN frames MUST NOT ..."

-- 
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/3128#pullrequestreview-304953073

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Oct 2019 03:53:09 +0000 (UTC)

martinthomson commented on this pull request.

+### Token Construction
+

Yeah, I moved too much up.

-- 
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/3128#discussion_r337322707

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Oct 2019 03:53:12 +0000 (UTC)

a263330298f0469ca7791cd503063b57eb0acac9  Moved too much up

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3128/files/47889736fe180f33c4951bbd60916278c7985329..a263330298f0469ca7791cd503063b57eb0acac9

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 22 Oct 2019 03:57:49 +0000 (UTC)

kazuho 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/3128#pullrequestreview-304954461

---

From: ianswett <[email-masked]>
Date: Tue, 22 Oct 2019 06:33:43 -0700

ianswett approved this pull request.

Some small suggestions, but LG

>  Unlike the token that is created for a Retry packet, there might be some time
 between when the token is created and when the token is subsequently used.
 Thus, a token SHOULD have an expiration time, which could be either an explicit
 expiration time or an issued timestamp that can be used to dynamically calculate
 the expiration time.  A server can store the expiration time or include it in an
 encrypted form in the token.
 
+A token issued with NEW_TOKEN MUST NOT include information that would allow
+values to be linked by an on-path observer to the connection on which it was
+issued.  For example, it cannot include the connection ID or addressing

```suggestion
issued.  For example, it cannot include the previous connection ID or addressing
```

-A client SHOULD NOT reuse a token in different connections.  Reusing a token
-allows connections to be linked by entities on the network path; see
+A client SHOULD NOT reuse a token for different connection attempts.  Reusing a

```suggestion
A client SHOULD NOT reuse a NEW_TOKEN token for different connection attempts.  Reusing a
```

-- 
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/3128#pullrequestreview-305207006

---

From: Nick Banks <[email-masked]>
Date: Tue, 22 Oct 2019 07:05:33 -0700

nibanks 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/3128#pullrequestreview-305233205

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Oct 2019 16:46:54 -0700

6b6273302247ffb91797391218850f95dae0b4af  Ian's tweaks

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 28 Oct 2019 13:12:21 -0700

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/3128#pullrequestreview-308118099