On Sat, Jun 4, 2016 at 9:21 AM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:
> Hi EKR, > > This is confusing: on the one hand you encourage clients to use multiple > tickets when available, "to the extent possible use a different one for > each new connection", and on the other hand you say that a simple way to > follow the Generation policy is to keep only the latest ticket, and then > presumably to use it multiple times. > What I'm trying to make clear is that clients which don't open multiple concurrent connections don't need to do anything fancy, but that clients which do, should. Can you please expand on the motivation here? Do we assume that a browser > normally opens (say) 5 connections concurrently and we want each one to use > fresh/separate key material? It's not separate keying material. This is a question of linkability between the connections. > If so, maybe the client should indicate how much concurrency it plans to > use? > Yes, we could do that I think we would all be happier if the security proofs hold even if clients > use the same ticket again and again. > To the best of my knowledge, the proofs already assume this, but perhaps Thyla, Sam, or Cas, can weigh in. -Ekr > Thanks, > Yaron > > > On 04/06/16 18:51, Eric Rescorla 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
