On Sat, Jun 4, 2016 at 11:42 AM, Kyle Rose <kr...@krose.org> wrote: > On Sat, Jun 4, 2016 at 1:15 PM, Eric Rescorla <e...@rtfm.com> 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. >
Sure. HTTP-level authentication via a Web form. (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? > Unexpected key changes. -Ekr > > > Kyle > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
