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

From: MikkelFJ <[email-masked]>
Date: Thu, 12 Mar 2020 09:24:00 -0700

mikkelfj commented on this pull request.

> @@ -1623,6 +1623,14 @@ 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
+
+A token sent in a NEW_TOKEN frames or a Retry packet MUST be constructed in a
+way that allows the server to identity how it was provided to a client.  These

"server to identity" -> "server to identify"

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 12 Mar 2020 09:26:17 -0700

>  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

Note that we have inconsistent terminology: and "off-path" attack can still read packets in the threat model, but here an "on-path" observer can see packets presumably as opposed to "off-path".

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