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

[Eric Rescorla <[e-mail]>]

On Sat, Jun 4, 2016 at 11:42 AM, Kyle Rose <[e-mail]> wrote:

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

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