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 <e...@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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
