Subject: [quicwg/base-drafts] Clarify that unlinkability is required for NEW_TOKEN tokens. Changes … (#2647)

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2019 20:13:15 -0700

…are:

* require unlinkability by stating: "SHOULD NOT expose linkability"
* suggest use of encryption when embedding expiration time in the token

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

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

-- Commit Summary --

  * Clarify that unlinkability is required for NEW_TOKEN tokens. Changes are:

-- File Changes --

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

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2019 20:18:47 -0700

martinthomson commented on this pull request.

This is definitely the right sentiment, but I have a few editorial suggestions.

>  A token SHOULD be constructed for the server to easily distinguish it from
 tokens that are sent in Retry packets as they are carried in the same field.
+The token SHOULD NOT expose linkability; i.e., information that lets observers

This is worth making a new paragraph for.  How about:

"The token MUST NOT include information that would allow it to be linked to the connection on which it was issued by an on-path observer.  For example, it cannot include the connection ID or addressing information unless the values are encrypted."

>  A token SHOULD be constructed for the server to easily distinguish it from
 tokens that are sent in Retry packets as they are carried in the same field.
+The token SHOULD NOT expose linkability; i.e., information that lets observers
+correlate the connection that is using the token and the one that issued the
+token.
+
+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 retain the expiration time in the server-side

```suggestion
the expiration time.  A server can store the expiration time or include it in an encrypted form in the token.
```

>  A token SHOULD be constructed for the server to easily distinguish it from
 tokens that are sent in Retry packets as they are carried in the same field.
+The token SHOULD NOT expose linkability; i.e., information that lets observers
+correlate the connection that is using the token and the one that issued the
+token.
+
+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 retain the expiration time in the server-side
+store, or embed the encrypted value in the token.  It is unlikely that the
+client port number is the same on two different connections; validating the port
+is therefore unlikely to be successful.

This sentence doesn't really flow from the previous any more.  This can probably be made into a new 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/2647#pullrequestreview-229883171

---

From: MikkelFJ <[email-masked]>
Date: Tue, 23 Apr 2019 22:57:08 -0700

mikkelfj commented on this pull request.

The client port can easily be the same on two different connections in a server p2p configuration, or just in a reverse proxy connection.

-- 
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/2647#discussion_r277964127

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2019 23:40:07 -0700

Yes, but the point is that you can't generally rely on it being the same between two connections.  I'm sure that those in those special circumstances will know to ignore this.

-- 
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/2647#discussion_r277973408