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

[Martin Thomson <[e-mail]>]

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