Subject: [quicwg/base-drafts] Empty NEW_TOKEN (#2978)

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Aug 2019 18:39:35 -0700

It makes absolutely no sense to allow NEW_TOKEN to be empty, but we never really said that explicitly.  So let's do that.  @marten-seemann opened #2977 for that.

Unfortunately, this is technically a design change, and we are that point.  So let's do this by the book.

-- 
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/2978

---

From: MikkelFJ <[email-masked]>
Date: Sun, 18 Aug 2019 23:23:26 -0700

Would a token of length 1 be any better? We already have that tokens must be unique and different from other token types.

-- 
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/2978#issuecomment-522430033

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Aug 2019 23:27:53 -0700

Yes.  At least then we have a clear signal that a token was provided.  Now, it's probably still awful (though it might be stateful and so not *completely* awful), but absent some strong signal about how short things can be we're in much the same state we are with connection IDs.  We now allow those to be 1 byte long, with similar results.

-- 
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/2978#issuecomment-522431033

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 18 Aug 2019 23:30:01 -0700

My weak preference is to not forbid 0-byte tokens, as it would be something that stacks would be forced to implement, just to pass the conformance tests.

It does not provide us any benefit (as @mikkelfj points out), while requiring stacks to have the check implemented.

-- 
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/2978#issuecomment-522431527

---

From: MikkelFJ <[email-masked]>
Date: Sun, 18 Aug 2019 23:40:10 -0700

@martinthomson I see the point. There is already text in initial packets stating

"Token Length:
A variable-length integer specifying the length of the Token field, in bytes. This value is zero if no token is present. "

-- 
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/2978#issuecomment-522434028

---

From: Marten Seemann <[email-masked]>
Date: Sun, 18 Aug 2019 23:42:18 -0700

Allowing 0-length token requires the receiver to filter them out before saving them to their token store (however that is implemented) for reuse in a connection in the future. If you don't do this, you might go and retrieve a token from the token store, use it on an Initial packet, just to end up in the situation that you're actually not using a token at all.

I disagree with @mikkelfj here. A stateful implementation could for example generate tokens by drawing random numbers between 0 and (a big value of) N. Occasionally, this will result in small token lengths, without compromising on the desired privacy properties.

-- 
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/2978#issuecomment-522434625

---

From: MikkelFJ <[email-masked]>
Date: Sun, 18 Aug 2019 23:43:17 -0700

@marten-seemann there is nothing to disagree with, or thumbsdown - it was a question.

-- 
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/2978#issuecomment-522434866

---

From: Marten Seemann <[email-masked]>
Date: Sun, 18 Aug 2019 23:45:15 -0700

Fair enough, that's a legitimate question, and I hope that I could provide a satisfying answer.
Removed my thumbsdown.

-- 
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/2978#issuecomment-522435425

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 18 Aug 2019 23:46:13 -0700

@marten-seemann That's a good point. That makes sense - I can see the value of  using "0" as a signal to indicate the "absence" of the token throughout the specification, considering the fact that it is used that way at some parts of the spec.

-- 
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/2978#issuecomment-522435720

---

From: ianswett <[email-masked]>
Date: Mon, 19 Aug 2019 06:35:45 -0700

I'm not sure why you'd want to do this, but an empty NEW_TOKEN could be used to indicate the past tokens are no longer valid, but the peer isn't getting a new one(at least yet).  That is the practical implication of the way it's written today(later tokens are likely better than earlier, etc).

-- 
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/2978#issuecomment-522578379

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Aug 2019 17:02:48 -0700

Yeah, that's just confusing.  The semantics of NEW_TOKEN don't imply invalidation.  We'd have to explicitly say that if NEW_TOKEN.size == 0, all previous tokens are invalid.  And then you have to also address the case of reordering and retransmissions of old NEW_TOKEN frames that arrive after the empty one.  Let's not go there.

-- 
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/2978#issuecomment-522799181