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

[Yaron Sheffer <[e-mail]>]

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.

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? If so, maybe the client should 
indicate how much concurrency it plans to use?

I think we would all be happier if the security proofs hold even if 
clients use the same ticket again and again.

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>