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

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

Anyway, I could live without doing this now (part of why I added ticket
extensions is to let us make these decisions later), if nobody else thinks
it's that valuable. I *do* think it's important that we make sure that
analysis supports multiple tickets pointing to the same underlying RMS.

-Ekr

On Sat, Jun 4, 2016 at 10:06 AM, David Benjamin <davidben@chromium.org>
wrote:

> I'm not sure I follow why the additional "generation" machinery is
> necessary.
>
> What do we gain from having the server to tell us to discard a ticket
> beyond what the ticket lifetime already gives? This doesn't seem an
> effective way to discard key material since, unlike the ticket lifetime, we
> need a live connection to the server at the time. Beyond that, if a client
> uses a ticket the server no longer likes, we'll just fall back to a full
> handshake. That seems fine.
>
> I would favor simply saying the client SHOULD prefer to use more recent
> tickets over earlier ones (since that's probably a good idea) and that
> clients which expect to open multiple concurrent connections SHOULD retain
> a window of several one-use tickets. We can always add this generation
> thing back in later as a TicketExtension if we change our minds.
>
> Am I missing something?
>
> David
>
>
> On Sat, Jun 4, 2016 at 11:52 AM Eric Rescorla <ekr@rtfm.com> wrote:
>
>> https://github.com/tlswg/tls13-spec/pull/493
>>
>> Currently the server can send multiple tickets but we don't say anything
>> about the semantics.
>> So, say a server sends tickets T_1, T_2, T_3... T_n, and the client wants
>> to initiate m < n connections, should he use:
>>
>> - only T_n
>> - T_1...T_m
>> - T_n, T_n-1, ... T_n-m+1
>>
>> The intuition I have had is that we want the third option (latest wins,
>> but allow multiples for linkability) but the spec doesn't say and there
>> aren't any semantics that tell you, so I think we want some way for the
>> server to say "these group of tickets are all co-valid".
>>
>> I've just created PR#493, which provides an explicit mechanism for this,
>> "ticket generations". Tickets with the same generation M are co-valid and a
>> ticket with generation N expires all tickets with generation M < N. The
>> nice thing about this encoding is that a client can implement the old "one
>> ticket at a time" behavior by just ignoring the generation and taking the
>> last ticket.
>>
>> I wanted to call out to cryptographers/analysts that this formalizes the
>> existing practice (going back to RFC 5077) of having multiple ticket values
>> tied to the same basic secret (though less so with 1.3 because tickets
>> issued on connection N+1 don't have the same RMS as those on connection N).
>> If there is a problem with this, that would be good to know.
>>
>> Barring major objections, I'll merge this Thursday.
>>
>>
>> -Ekr
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>