Subject: [quicwg/base-drafts] Repeat tokens in all Initial packets (#2089)

From: ianswett <[email-masked]>
Date: Sat, 01 Dec 2018 13:07:39 -0800

The client repeats the token in all Initial packets.  Also clarifies that the token is sent in Initial in a few spots.

https://www.ietf.org/mail-archive/web/quic/current/msg05071.html
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Repeat tokens in all Initial packets

-- File Changes --

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

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Sat, 01 Dec 2018 13:24:04 -0800

mikkelfj commented on this pull request.

>  Upon receiving the client's Initial packet, the server can request address
 validation by sending a Retry packet ({{packet-retry}}) containing a token. This
-token is repeated by the client in an Initial packet after it receives the Retry
-packet.  In response to receiving a token in an Initial packet, a server can
-either abort the connection or permit it to proceed.
+token is repeated by the client in all Initial packets after it receives the

The future version of this text, below, uses a MUST repeat. Suggest using MUST here as well.

> @@ -1614,17 +1614,19 @@ token was issued and any connection where it is used.  Clients that want to
 break continuity of identity with a server MAY discard tokens provided using the
 NEW_TOKEN frame.  Tokens obtained in Retry packets MUST NOT be discarded.
 
-A client SHOULD NOT reuse a token.  Reusing a token allows connections to be
-linked by entities on the network path (see {{migration-linkability}}).  A
-client MUST NOT reuse a token if it believes that its point of network
-attachment has changed since the token was last used; that is, if there is a
-change in its local IP address or network interface.  A client needs to start
-the connection process over if it migrates prior to completing the handshake.
+A client SHOULD NOT reuse a token in different connections. Reusing a token
+allows connections to be linked by entities on the network path
+(see {{migration-linkability}}).  A client MUST NOT reuse a token if it
+believes that its point of network attachment has changed since the token was
+last used; that is, if there is a change in its local IP address or network
+interface.  A client needs to start the connection process over if it migrates
+prior to completing the handshake.

Maybe this is getting ahead of other discussions, but a client SHOULD not repeat also because the server MAY reject repeated tokens.

 When a server receives an Initial packet with an address validation token, it
-SHOULD attempt to validate it.  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. If the validation succeeds, the server SHOULD then allow the
+SHOULD attempt to validate it, unless it has already completed address
+validation.  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. If the validation succeeds, the server SHOULD then allow the
 handshake to proceed.

And here text might be placed on server MAY reject repeat tokens?

-- 
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/2089#pullrequestreview-180538707

---

From: Christian Huitema <[email-masked]>
Date: Sat, 01 Dec 2018 15:16:08 -0800

huitema commented on this pull request.

I assume that we will process PR #2064 after this one. I am fine with the text, but I would like something said about server behavior. Client recommendations are mostly enforced when breaking them causes servers to reject packets...

 validation by sending a Retry packet ({{packet-retry}}) containing a token. This
-token is repeated by the client in an Initial packet after it receives the Retry
-packet.  In response to receiving a token in an Initial packet, a server can
-either abort the connection or permit it to proceed.
+token is repeated by the client in all Initial packets after it receives the
+Retry packet.  In response to receiving a token in an Initial packet, a server
+can either abort the connection or permit it to proceed.
+
+As long as it is not possible for an attacker to generate a valid token for
+its own address (see {{token-integrity}}) and the client is able to return
+that token, it proves to the server that it received the token.

Define "proves". The token mechanism may be vulnerable to replay attacks.

> @@ -1590,9 +1588,11 @@ amount of data to a client in response to 0-RTT data.
 
 The server uses the NEW_TOKEN frame {{frame-new-token}} to provide the client
 with an address validation token that can be used to validate future
-connections.  The client may then use this token to validate future connections
-by including it in the Initial packet's header.  The client MUST NOT use the
-token provided in a Retry for future connections.
+connections.  The client includes this token in Initial packets to provide
+address validation in a future connection.  The client MUST include the
+token in all Initial packets it sends, unless a Retry replaces the token
+with a newer token. The client MUST NOT use the token provided in a Retry
+for future connections.

Yes, "all Initial packets" is what we want. At least it is not ambiguous. There is however a general problem with such recommendations: they are not enforced unless servers behave that way. I would add something at the end:
```
with a newer token. The client MUST NOT use the token provided in a Retry
for future connections. Servers MAY reject any Initial packet that does not
carry the expected token.
```

I am not sure about the use of the plural in "future connections". Allowing the same token to be reused in multiple connections is potentially dangerous. But that may be work for another PR.

I assume that the text from PR #2064 will be inserted after this paragraph. Again, it is the flip side of the "client SHOULD NOT" clause. Client should not reuse the same token for multiple connections, and servers MAY (or SHOULD?) reject connections that attempt to reuse a token.

-- 
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/2089#pullrequestreview-180541459

---

From: Martin Thomson <[email-masked]>
Date: Sat, 01 Dec 2018 19:02:24 -0800

martinthomson commented on this pull request.

This is fine, pending the small suggested tweaks.  Though we need to settle on "reject" vs. "discard" to close this one.

```suggestion
token MUST be repeated by the client in all Initial packets it sends after it receives the
```

It only proves that it received it, not when.  I think that we can probably defer discussion of the reuse/replay aspects of this.

Is the desired action "reject" or "ignore/discard"?  I would say either is OK, though I might be inclined more toward the latter (on the basis that spoofing implies DoS).

@huitema has it right here.  We are adding text in #2064 that should help.

#2064.

-- 
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/2089#pullrequestreview-180545823

---

From: Christian Huitema <[email-masked]>
Date: Sat, 01 Dec 2018 23:12:51 -0800

Yes, discard is 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/pull/2089#discussion_r238087301

---

From: ianswett <[email-masked]>
Date: Sun, 02 Dec 2018 11:32:53 -0800

@ianswett pushed 1 commit.

c3206b4  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/2089/files/e8277d1e4e1e5589c42a8f30d6522e7a3464a5b6..c3206b4990ab6ac7c06bfd106b1b5343f0ff88d1

---

From: Mike Bishop <[email-masked]>
Date: Mon, 03 Dec 2018 12:10:05 -0800

@MikeBishop pushed 1 commit.

ce9e08e  Rewrap

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 03 Dec 2018 12:25:43 -0800

> @@ -1548,9 +1548,9 @@ frame (see {{validate-future}}).
 
 Upon receiving the client's Initial packet, the server can request address
 validation by sending a Retry packet ({{packet-retry}}) containing a token. This
-token MUST be repeated by the client in all Initial packets it sends after it receives the
-Retry packet.  In response to receiving a token in an Initial packet, a server
-can either abort the connection or permit it to proceed.
+token MUST be repeated by the client in all Initial packets it sends after it
+receives the Retry packet.  In response to receiving a token in an Initial
+packet, a server can either abort the connection or permit it to proceed.

Isn't there a third option to ignore a packet rather then abort or permit to proceed?

-- 
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/2089#pullrequestreview-180962882

---

From: ianswett <[email-masked]>
Date: Mon, 03 Dec 2018 18:12:30 -0800

ianswett commented on this pull request.

What's the 3rd option?

-- 
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/2089#discussion_r238508579

---

From: ianswett <[email-masked]>
Date: Mon, 03 Dec 2018 18:15:54 -0800

1c3b5a245a3c135c60388fc902175b09c9267266  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/2089/files/ce9e08e2374f0aea9abc35fae41ef4433a09a9a9..1c3b5a245a3c135c60388fc902175b09c9267266

---

From: ianswett <[email-masked]>
Date: Mon, 03 Dec 2018 18:16:40 -0800

Thanks, updated.

-- 
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/2089#discussion_r238509296

---

From: MikkelFJ <[email-masked]>
Date: Tue, 04 Dec 2018 03:55:30 -0800

The third option is to "drop/ignore". The mentioned options are "abort" and "proceed", but proceed implies the packet is processed.

-- 
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/2089#discussion_r238632018

---

From: ianswett <[email-masked]>
Date: Tue, 04 Dec 2018 07:40:52 -0800

18774ce05e2a5d17ae8d5aa824ff5626a6b56564  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/2089/files/1c3b5a245a3c135c60388fc902175b09c9267266..18774ce05e2a5d17ae8d5aa824ff5626a6b56564

---

From: ianswett <[email-masked]>
Date: Tue, 04 Dec 2018 15:41:23 +0000 (UTC)

SG, changed from receiving to processing, because otherwise I think this sentence is not really correct.

-- 
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/2089#discussion_r238715955

---

From: Martin Thomson <[email-masked]>
Date: Tue, 04 Dec 2018 13:13:06 -0800

Merged #2089 into master.

-- 
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/2089#event-2005487558

---

From: Martin Thomson <[email-masked]>
Date: Tue, 04 Dec 2018 13:13:18 -0800

@ianswett, does this fix an issue?

-- 
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/2089#issuecomment-444260215

---

From: ianswett <[email-masked]>
Date: Tue, 04 Dec 2018 13:52:24 -0800

The only issue I'm aware of is the thread I linked 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/2089#issuecomment-444272837