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

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
>