Re: [TLS] PR #493: Multiple concurrent tickets

[Kyle Rose <[e-mail]>]

On Sat, Jun 4, 2016 at 1:15 PM, Eric Rescorla <[e-mail]> wrote:

> I don't think it's principally about discarding keying material, but
> rather about allowing the server to attach state to a ticket and then have
> predictable behavior. Consider the obvious case of post-handshake client
> auth (which I know you hate) and a client which has tickets issue before
> and after the auth event. If it tries to use them both, that's going to be
> annoying (though I agree, not fatal).
>

I have several thoughts:

(1) In many cases, the client can handle this unilaterally. Are there
examples of this kind of ticket-relevant state change that the client would
not be aware of? When the client is aware of a state change (such as client
auth negotiation), it can purge any tickets received before the state
change.

(2) If the ticket isn't encrypted data but is instead just an index into
full session state on the server, the ticket might actually still be valid
for state changes that occur after the ticket was handed out. I have no
idea how common this brand of session caching is likely to be, but I'm
guessing "not very".

(3) Tickets already allow the server to encode state: the proposal here
seems to be about revealing additional ticket semantics to the client. The
server could after all encode the generation in the (encrypted) ticket and
then use that to reject old tickets: this results in more full handshakes,
but it would eliminate weird behavior when clients use old tickets.

Correctness seems achievable either way, so I'm not sure a purge mechanism
(beyond expiration) is justified by this specific use case in isolation.
Are there other uses cases for which server-initiated purge of classes of
session tickets would be helpful?

Kyle