> > (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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
