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

[Nick Harper <[e-mail]>]

> 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