Subject: [quicwg/base-drafts] NEW_TOKEN token and encryption (#2543)

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Mar 2019 13:53:50 -0700

My understanding is that tokens provided by NEW_TOKEN frames should not leak information that allows observers correlate the newly established connection with the previous connection. Such information include the time when the token was issued, RTT, server name (when SNI is not used or Encrypted SNI is used).

However, the draft seems to be vague about the requirement. I think it might be worth clarifying the principle in the draft.

"a token SHOULD include an expiration time" (section 8.1.2) - I think we should change this to "a token SHOLUD be associated an expiration time", considering the fact that we are talking about "stateful" design (stateless design is mentioned briefly in one of the following paragraphs).

"In a stateless design, a server can use encrypted and authenticated tokens to pass information to clients" - I think we might prefer using "SHOULD" rather than "can".

-- 
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/issues/2543

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 21 Mar 2019 14:03:15 -0700

I think the current text is fine:

```
   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 include an expiration time.
   The server MAY include either an explicit expiration time or an
   issued timestamp and dynamically calculate the expiration time.  It
   is also unlikely that the client port number is the same on two
   different connections; validating the port is therefore unlikely to
   be successful.
```

"include" translates to "put into the token and encrypt" in my mind.  Reading that a token is "associated" with an expiration time would give me pause.

-- 
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/issues/2543#issuecomment-475401325

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Mar 2019 14:13:33 -0700

> "include" translates to "put into the token and encrypt"

Would you mind clarifying where the "and encrypt" comes from? My point is that that is the way it should be, however the text does not seem to clarify that.

-- 
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/issues/2543#issuecomment-475404739

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 21 Mar 2019 14:17:23 -0700

I don't recall how I arrived at it -- perhaps some common sense. 😄  Now that I have implemented it, it seems only natural.

Perhaps we should simply add "and encrypt" to the text instead of changing to "associated with," which is less clear?

-- 
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/issues/2543#issuecomment-475405980

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Mar 2019 17:16:35 -0700

I'm happy to know that we share the common sense :+1:

As stated in the opening comment, my "editorial" preference goes to stating the principle that any information in an NEW_TOKEN token (other than the opaque lookup key used in a stateful design) SHOULD be encrypted. If that is to be met, I think keeping "and encrypt" would be fine.

-- 
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/issues/2543#issuecomment-475450149

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 22 Mar 2019 17:11:40 +0000 (UTC)

I agree with @kazuho -- I think stating this explicitly as a SHOULD is sensible.

-- 
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/issues/2543#issuecomment-475703118

---

From: Martin Thomson <[email-masked]>
Date: Sun, 24 Mar 2019 02:37:42 -0700

(For the chairs, and triage purposes).

This suggests a normative requirement that I don't think that we need, or that is already implied by existing text.  There would be new normative text.  I believe that is still editorial on the basis that the requirement is already implied, but will defer to your judgment.

-- 
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/issues/2543#issuecomment-475942899

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 24 Mar 2019 21:53:52 -0700

FWIW, what I am shooting for is a change like https://github.com/kazuho/base-drafts/commit/9017aaeb7924124ee93175283cb6c97ad11edf2c.

-- 
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/issues/2543#issuecomment-476054482