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

[Kyle Rose <[e-mail]>]

>
> (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.
>


> Sure. HTTP-level authentication via a Web form.
>

Would that typically feed into the ticket state? I'm thinking of something
like Rails, which (at least when I worked with it) maintained its own
session state separately from TLS session state, and signaled via cookie or
Auth header.


> 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?
>>
>
> Unexpected key changes.
>

Rotation of the ticket-encrypting key? This seems like a good argument for
it, because it's something that's likely to happen regularly, and maybe
even on a schedule, and almost certainly across all clients simultaneously
(meaning "load spike" if the clients aren't guided to the right behavior).

In general, I like the idea of having a way to purge state beyond simply
expiration; I wonder if generation is the right level of specificity, or if
it's too general and we should reopen the expiration time vs. issue
time+TTL discussion and allow purging by issue time. (I'm not actually
suggesting the latter.) But I also don't have a strong opinion about the
balance between complexity and performance benefit here.

Kyle