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

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Dec 2019 19:42:30 -0800

martinthomson commented on this pull request.

> @@ -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).

@nharper where are we at here?  I was suggesting a new paragraph, but I didn't get any sense from your reply about whether you thought that was necessary/useful/not.

-- 
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_r352972436

---

From: Nick Harper <[email-masked]>
Date: Fri, 13 Dec 2019 11:25:04 -0800

nharper commented on this pull request.

Sorry for the delay. The new paragraph (framed as client considerations) sounds like a better way to describe this point. I've added a version of that paragraph and rebased this PR. (There was a merge conflict for the change above.)

-- 
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_r357796404

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 Dec 2019 20:51:30 -0800

janaiyengar commented on this pull request.

A couple of editorial suggestions.

> @@ -1792,6 +1793,12 @@ able to reuse a token.  To avoid attacks that exploit this property, a server
 addresses.
 
+Clients MAY use tokens obtained on one connection for any connection attempt
+using the same version.  When selecting a token to use, clients do not need to
+consider other properties of the connection that is being attempted, including
+the choice of possible application protocols, session tickets, or other

```suggestion
the choice of application protocol or the value of any session ticket being used.
```

> @@ -1792,6 +1793,12 @@ able to reuse a token.  To avoid attacks that exploit this property, a server
 addresses.
 
+Clients MAY use tokens obtained on one connection for any connection attempt
+using the same version.  When selecting a token to use, clients do not need to
+consider other properties of the connection that is being attempted, including
+the choice of possible application protocols, session tickets, or other
+connection properties.

```suggestion
```

> @@ -1792,6 +1793,12 @@ able to reuse a token.  To avoid attacks that exploit this property, a server
 addresses.
 
+Clients MAY use tokens obtained on one connection for any connection attempt
+using the same version.  When selecting a token to use, clients do not need to

```suggestion
using the same version.  When selecting a token to use, a client does not need 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/3150#pullrequestreview-333024523

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 16 Dec 2019 21:16:12 -0800

kazuho commented on this pull request.

I have some editiorial comments, but the design looks fine to me.

While we might embed some information related to 0-RTT configuration in QUIC tokens, they would be decryptable and be usable, so we do not think there would be a problem for us (thanks to @martinthomson for checking).

> @@ -1741,7 +1741,8 @@ 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 not applicable to the server that it is connecting to, unless the
 client has the knowledge that the server that issued the token and the server
-the client is connecting to are jointly managing the tokens.
+the client is connecting to are jointly managing the tokens.  A client MAY use a
+token from any previous connection to that server.

Maybe this sentence can be subsumed by the first sentence of the same paragraph that discusses the applicability of the token?

It might be better to say: _using the same "QUIC" version_.

Also, I think it might be a good idea to gather the discussion about applicability to one place. At the moment this PR scatters that to three places: one being the change above (and the first sentence of that paragraph, which already exists), and the provisions being added here.

-- 
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-333028995

---

From: Mike Bishop <[email-masked]>
Date: Thu, 19 Dec 2019 11:22:54 -0800

MikeBishop 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-334876816