[TLS] PR #493: Multiple concurrent tickets

[Eric Rescorla <[e-mail]>]

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