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