Subject: NEW_TOKEN token should be encrypted

From: Kazuho Oku <[email-masked]>
Date: Fri, 22 Mar 2019 09:29:14 +0900

As stated in https://github.com/quicwg/base-drafts/issues/2543, my
understanding is that a token sent in a NEW_TOKEN frame SHOULD be
encrypted. The only exception would be the case of the token carrying
only an opaque and randomly-generated key identifier in a stateful
design (i.e. a server using a key-value store to retain the
information of previous connections).

Otherwise, an observer can use the information contained in the token
sent in an resuming connection, to correlate that connection to the
previous connection that issued the token. For example, if a server
includes the generation time of the token in plaintext, an observer
can extract that information found in an Initial packet to nail down
the connection that issued the token.

While I think we might be call this an editorial issue, I think we
should clarify this as a normative requirement (e.g., SHOULD). Hence
bringing the discussion to the mailing list as well.

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 22 Mar 2019 03:50:53 -0400

I think I added some text about token independence and also mentioned
encryption.
MT argued that encryption was not a goal - I presume reasoning that a
secure hash could work just as well if you can associate the context.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 22 March 2019 at 01.29.46, Kazuho Oku ([email-masked]) wrote:

-- 
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 22 Mar 2019 22:15:47 +0900

2019年3月22日(金) 16:50 Mikkel Fahnøe Jørgensen <[email-masked]>:
>
> I think I added some text about token independence and also mentioned encryption.
> MT argued that encryption was not a goal - I presume reasoning that a secure hash could work just as well if you can associate the context.

Would you mind looking for that discussion so that I could learn from it?

My understanding is that while plaintext+MAC is fine for a Retry token
to avoid security issues (e.g., used as an DoS attack vector),
encrypting the contents of a NEW_TOKEN token is important because
exposing the information of the previous connection on the wire is a
privacy concern.

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 22 Mar 2019 14:42:59 +0100

I was confusing this with make connection ID’s independent, but perhaps
there is some carry over.
https://github.com/quicwg/base-drafts/pull/1750

Kind Regards,
Mikkel Fahnøe Jørgensen

On 22 March 2019 at 14.15.59, Kazuho Oku ([email-masked]) wrote:

encryption.

-- 
Kazuho Oku

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 22 Mar 2019 12:04:58 -0400

The token in NEW_TOKEN, like session tickets, can be implemented in a number of ways.  Stateless implementations, which I expect to be common, will need to embed information about addresses in a way that is both authenticated (i.e., unpredictable and verifiable) and unlinkable (maybe, see below).  As you say, encryption is the only sensible way to do that.

However, like session tickets, you can vend random identifiers and maintain a lookup table.  That doesn't scale nearly as well, but it does work.  The authentication is done via lookup, the unlinkability is provided by the randomness.  And it gains additional resistance against replay (whereas NEW_TOKEN can be replayed).

The unlinkability assumption is probably right, but the interesting thing here is that NEW_TOKEN isn't good unless you don't move, which makes linking based on your source address trivial.  Unless you are sharing a NAT.

So yeah, I think that this recommendation follows from the stated requirements. but it will require some care to get the right text.

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 23 Mar 2019 09:46:16 +0900

> The unlinkability assumption is probably right, but the interesting thing here is that NEW_TOKEN isn't good unless you don't move, which makes linking based on your source address trivial.  Unless…

That's a good point. In addition to NAT, what I wonder is if all the
clients, running in various environments, would be possible of
detecting network changes. If they fail to detect, linkability gets
exposed across networks.

I might argue that requiring the servers to provide unlinkability (by
encrypting non-random parts of a NEW_TOKEN token) can be a more
reliable defense, while also having the potential of simplifying
client implementations by relaxing (or removing) the requirement to
detect network changes (assuming that we agree that only having
server-side defense is sufficient).

-- 
Kazuho Oku