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