Subject: [quicwg/base-drafts] clarify the scope of a NEW_TOKEN token (#3156)

From: Kazuho Oku <[email-masked]>
Date: Sun, 27 Oct 2019 23:52:31 -0700

This PR clarifies that the scope of a NEW_TOKEN is equivalent to that of the TLS connection (i.e., the scope of the server certificate).

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

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

-- Commit Summary --

  * clarify the scope of a NEW_TOKEN token

-- File Changes --

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

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Oct 2019 02:24:07 -0700

martinthomson commented on this pull request.

> @@ -1698,10 +1698,14 @@ encrypted form 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.
 
-If the client has a token received in a NEW_TOKEN frame on a previous connection
-to what it believes to be the same server, it SHOULD include that value in the
-Token field of its Initial packet.  Including a token might allow the server to
-validate the client address without an additional round trip.
+A token received in a NEW_TOKEN frame is applicable against the servers that the

```suggestion
A token received in a NEW_TOKEN frame is applicable to any server that the
```

> @@ -1698,10 +1698,14 @@ encrypted form 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.
 
-If the client has a token received in a NEW_TOKEN frame on a previous connection
-to what it believes to be the same server, it SHOULD include that value in the
-Token field of its Initial packet.  Including a token might allow the server to
-validate the client address without an additional round trip.
+A token received in a NEW_TOKEN frame is applicable against the servers that the
+connection is considered authoritative for (e.g., server names included in the
+certificate).  A client MUST only use a token that is applicable to the server

```suggestion
certificate).  A client SHOULD only use a token that is applicable to the server
```

We don't need to prevent a client from using a token from one server on a completely different one.  That won't *work*, but the server needs to protect itself against outdated tokens and attack, so they shouldn't outright reject the connection.

> @@ -1698,10 +1698,14 @@ encrypted form 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.
 
-If the client has a token received in a NEW_TOKEN frame on a previous connection
-to what it believes to be the same server, it SHOULD include that value in the
-Token field of its Initial packet.  Including a token might allow the server to
-validate the client address without an additional round trip.
+A token received in a NEW_TOKEN frame is applicable against the servers that the
+connection is considered authoritative for (e.g., server names included in the
+certificate).  A client MUST only use a token that is applicable to the server
+that the client is connecting to to.  If the client has a token received in a
+NEW_TOKEN frame that is applicable to a new connection attempt, it SHOULD

Rephrase:

A client SHOULD use an applicable and previously unused token when connecting to a server.  Including a token in an Initial packet could allow the server to validate the client address without an additional round trip.

-- 
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/3156#pullrequestreview-307714882

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 02:26:47 -0700

kazuho commented on this pull request.

I thought you had an argument that we need a prohibition here; see https://github.com/quicwg/base-drafts/issues/3155#issuecomment-546789506.

-- 
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/3156#discussion_r339464391

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Oct 2019 02:32:29 -0700

I don't remember making that argument, but I guess I could have said that.

The particular "attack" requires having a server privileged or capable enough to recognize a token from a different server with a fair degree of confidence.  For NEW_TOKEN, I can maybe see how that would happen though.  I'm OK with a MUST.

-- 
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/3156#discussion_r339466782

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 04:48:37 -0700

@kazuho pushed 1 commit.

fb291efde6bdb976af004252087865410ed23917  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3156/files/d867945f6f1ca9ada1e01c92e5294310b4dc400b..fb291efde6bdb976af004252087865410ed23917

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 05:02:18 -0700

@kazuho pushed 1 commit.

e67d71336fdf52a267fbccde942849dac6004c69  encourage the use of applicable and unused token, while prohibiting the use of unapplicable ones

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3156/files/fb291efde6bdb976af004252087865410ed23917..e67d71336fdf52a267fbccde942849dac6004c69

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 05:03:11 -0700

Thank you for the suggestion. I believe the intent here is to recommend the use of tokens when appropriate; hence went with e67d713.

-- 
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/3156#discussion_r339526766

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 05:13:13 -0700

@martinthomson FWIW I think the attack you were discussing was something different, that works even if the tokens were perfectly encrypted.

Consider the case where an attacker is an ISP and also controls example.com, which is hosted behind the large-scale load balancer hosted by a different entity (e.g., CDN). The attacker issues tokens when clients connect to example.com through the load balancer (IP address 192.0.2.1). Then, when the clients connect to different hostnames under the same load balancer (IP address 192.0.2.1), it can (as an ISP) see which exact clients went for which exact server-names.

I think you pointing out this attack has effectively killed https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/, I appreciate that. But if it is the case that you think it's an attack we can ignore, I'm happy to revive the draft :-)

-- 
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/3156#discussion_r339530240

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Oct 2019 20:36:38 -0700

martinthomson approved this pull request.

> @@ -1698,10 +1698,13 @@ encrypted form in the token.
 
-If the client has a token received in a NEW_TOKEN frame on a previous connection
-to what it believes to be the same server, it SHOULD include that value in the
-Token field of its Initial packet.  Including a token might allow the server to
-validate the client address without an additional round trip.
+A token received in a NEW_TOKEN frame is applicable to any server that the
+connection is considered authoritative for (e.g., server names included in the
+certificate).  When connecting to a server for which the client retains an
+applicable and unused token, it SHOULD include that token in the Token field of
+its Initial packet.  Including a token might allow the server to validate the
+client address without an additional round trip.  A client MUST NOT include a
+token that is unapplicable to the server that it is connecting to.

```suggestion
token that is not applicable to the server that it is connecting to.
```

-- 
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/3156#pullrequestreview-308260294

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 20:58:43 -0700

@kazuho pushed 1 commit.

3d68e2be216d2ca28a28221f1f86bc91ffde7fa0  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3156/files/e67d71336fdf52a267fbccde942849dac6004c69..3d68e2be216d2ca28a28221f1f86bc91ffde7fa0

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 29 Oct 2019 18:00:21 -0700

janaiyengar approved this pull request.

-- 
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/3156#pullrequestreview-308916183

---

From: MikkelFJ <[email-masked]>
Date: Wed, 30 Oct 2019 15:24:33 -0700

mikkelfj commented on this pull request.

+token that is not applicable to the server that it is connecting to.

What happens if it does anyway?

-- 
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/3156#pullrequestreview-309557851

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 31 Oct 2019 02:23:09 -0700

We have a normative text below, suggesting that says: _if the token is invalid then the server SHOULD proceed as if the client did not have a validated address, including potentially sending a Retry._

-- 
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/3156#discussion_r341029110

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 31 Oct 2019 22:38:01 -0700

@kazuho pushed 1 commit.

e0a60c778340168e734cb229d12ec7257f736192  add unless, based on the discussion starting from https://github.com/quicwg/base-drafts/issues/3155#issuecomment-548264247

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3156/files/3d68e2be216d2ca28a28221f1f86bc91ffde7fa0..e0a60c778340168e734cb229d12ec7257f736192