Subject: [quicwg/base-drafts] Clarify the state a client stores with a token (#3150)

From: Nick Harper <[email-masked]>
Date: Thu, 24 Oct 2019 14:52:43 -0700

It is permissible for a client to do 0-RTT resumption with a NST from
one connection and a token from another. This clarifies that a client
only needs to associate a token (from a NEW_TOKEN frame) with the server
it was from and no additional state, and that a server can&#39;t require
that a token be from the same connection as the NST in use.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Clarify the state a client stores with a token

-- File Changes --

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

-- Patch Links --

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

---

From: ianswett <[email-masked]>
Date: Thu, 24 Oct 2019 15:14:23 -0700

ianswett commented on this pull request.

> @@ -1697,7 +1697,8 @@ 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.
+validate the client address without an additional round trip.  A client MAY use
+a token from any previous connection to that server.

Do we need any caveats about how older tokens might not be able to be processed?  Or maybe tokens should have an expiry time, which would be a design change... :(

-- 
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/3150#pullrequestreview-306894277

---

From: Nick Harper <[email-masked]>
Date: Thu, 24 Oct 2019 15:17:22 -0700

nharper commented on this pull request.

3 paragraphs down ("Clients might receive multiple tokens on a single connection") mentions that older tokens might become invalid and that clients should send the most recent unused token. I think that covers your 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/pull/3150#discussion_r338815723

---

From: ianswett <[email-masked]>
Date: Thu, 24 Oct 2019 15:19:00 -0700

ianswett 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/3150#pullrequestreview-306895891

---

From: David Schinazi <[email-masked]>
Date: Thu, 24 Oct 2019 16:01:38 -0700

DavidSchinazi 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/3150#pullrequestreview-306909404

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Oct 2019 16:52:08 -0700

marten-seemann 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/3150#pullrequestreview-306922557

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Oct 2019 19:33:43 -0700

martinthomson commented on this pull request.

This is placing a constraint on the server that I think is reasonable, but I want to test it out.

If I handed out a session ticket for 0-RTT, but I wouldn't accept 0-RTT without a token, would it be reasonable for me to put additional information about 0-RTT in the token?  This PR would seem to prevent that by allowing a client to switch 0-RTT tickets and tokens from two connections.

@kazuho previously suggested that quicly might put some 0-RTT-related information in the token.  As long as the cross-checking between token and ticket validation exists, the client doing a mix and match with incompatible tickets and tokens won't have any disastrous consequences.  But it could lead to the server rejecting 0-RTT, which isn't great.

Of course, the information in the token might be generic enough to match with the ticket: for instance, if it identifies "0-RTT configuration X" and the server still understands that configuration, then the information could be interchangeable and therefore usable.

I'd like two things here: 1. an expression of the problem statement in the form of an issue, and 2. input from @kazuho.

> @@ -1746,7 +1747,8 @@ validate a client address.  Tokens are not integrated into the cryptographic
 handshake and so they are not authenticated.  For instance, a client might be
 able to reuse a token.  To avoid attacks that exploit this property, a server

So that I don't forget: A client might not be prevented from reusing a token.

> @@ -1746,7 +1747,8 @@ validate a client address.  Tokens are not integrated into the cryptographic
 handshake and so they are not authenticated.  For instance, a client might be
 able to reuse a token.  To avoid attacks that exploit this property, a server
 can limit its use of tokens to only the information needed to validate client
-addresses.
+addresses.  A server MUST NOT require the client to correlate any additional
+information with a token (e.g. a NewSessionTicket).

```suggestion

Clients MAY use tokens obtained from the this version of QUIC with any connection attempt for the same version.   Clients do not need to consider other properties of the connection that is being attempted when selecting a token, including the choice of possible application protocols, session tickets, or other connection properties.
```

I don't think that this is a testable "MUST NOT".  It's more or less axiomatic.  A server can't prevent clients from attempting to use 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/3150#pullrequestreview-306953063

---

From: Nick Harper <[email-masked]>
Date: Fri, 25 Oct 2019 03:17:28 +0000 (UTC)

You're right that this isn't a testable "MUST NOT". I think the proposed language here is better suited with the language above describing a client's behavior.

Here I'm trying to provide some advice to server implementers that clients aren't going to keep track of which token came from where (or goes with which ticket), so if they expect that a token and ticket used on a new connection came from the same old connection, they're going to have a bad time.

-- 
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/3150#discussion_r338871141

---

From: Nick Harper <[email-masked]>
Date: Fri, 25 Oct 2019 03:11:22 +0000 (UTC)

> If I handed out a session ticket for 0-RTT, but I wouldn't accept 0-RTT without a token, would it be reasonable for me to put additional information about 0-RTT in the token?

The token is used for deciding whether the server believes the packet it's receiving actually comes from the address it says it's coming from. I could believe a server might trust a client only if it's doing a 1-RTT handshake, but not trust it if it's doing a 0-RTT handshake, so might encode that bit in the token. I don't think the server should be putting more specific bits like "this is the NST that should be used" or "here are the SETTINGS from the previous connection" in the token.

If the server doesn't like a token it receives with a 0-RTT handshake, it can send a Retry packet but still continue with the 0-RTT crypto handshake (even though it's now 1-RTT from a transport perspective). I don't see the need for there to be fate sharing between accepting a token and accepting 0-RTT - a server can reject one without rejecting the other.

I've created #3152 to express the problem statement as 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/3150#issuecomment-546182450

---

From: ianswett <[email-masked]>
Date: Fri, 25 Oct 2019 06:10:50 -0700

If you're going to continue with 0-RTT, but not trust the token, why not just limit the amount sent by the amplification factor?  The receipt of a Handshake packet constitutes path validation.

Also, a Retry doesn't allow you to acknowledge the client's Initial or any 0-RTT packets.

-- 
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/3150#issuecomment-546347449