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

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Jun 2016 08:51:23 -0700

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

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 4 Jun 2016 19:21:37 +0300

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:
> 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
> 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".
>
> "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.
>
> 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.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Jun 2016 09:48:41 -0700

> 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

---

From: David Benjamin <[email-masked]>
Date: Sat, 04 Jun 2016 17:06:38 +0000

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Jun 2016 10:15:23 -0700

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

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 4 Jun 2016 10:23:14 -0700

What about the choice of, randomly use any of the tickets but don’t re-use a ticket?  I am not sure why using them in a specific order is better or worse.  Even if you assign a specific ticket to a reconnect, I would expect that timing of issues might make the server see the tickets out of order so that it needs to deal with the fact that they come in randomly. 

Jim

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Saturday, June 04, 2016 8:51 AM
To: [email-masked]
Subject: [TLS] PR #493: Multiple concurrent tickets

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

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.

 

-Ekr

---

From: David Benjamin <[email-masked]>
Date: Sat, 04 Jun 2016 18:10:09 +0000

Wouldn't the server be required to handle such a case anyway? If it's doing
post-handshake auth, it wants to do something reactive, such as based on
HTTP request or so. But that means I may have not hit an auth'd URL, saved
the session, resumed it, and then hit an auth'd URL. Or perhaps I have two
connections, one of which happens to hit auth'd URLs and the other happens
to hit unauth'd URLs. There's no ordering between the two sets of sessions,
so the unauth'd one may win.

That means servers must already allow for resuming an unauth'd session,
hitting a auth'd URL, and sending a fresh post-handshake
CertificateRequest. If anything, I wouldn't want to encourage servers to
assume they can make assumptions here. (I have seen some sites make strong
assumptions of this sort, and they've been sufficiently strong that they're
unsupportable. It's basically incompatible with having any parallel
connections at all.)

Incidentally, Chrome will never offer or store sessions on renegotiation,
the exact opposite here, and no one seems to have noticed.

David

On Sat, Jun 4, 2016 at 1:16 PM Eric Rescorla <[email-masked]> wrote:

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Jun 2016 11:28:41 -0700

Yes, these are all reasonable points. It's purely a matter of thinking one
might want to minimize
the number of anomalies. But maybe that's not a useful goal.

-Ekr

On Sat, Jun 4, 2016 at 11:10 AM, David Benjamin <[email-masked]>
wrote:

> Wouldn't the server be required to handle such a case anyway? If it's
> doing post-handshake auth, it wants to do something reactive, such as based
> on HTTP request or so. But that means I may have not hit an auth'd URL,
> saved the session, resumed it, and then hit an auth'd URL. Or perhaps I
> have two connections, one of which happens to hit auth'd URLs and the other
> happens to hit unauth'd URLs. There's no ordering between the two sets of
> sessions, so the unauth'd one may win.
>
> assume they can make assumptions here. (I have seen some sites make
> strong assumptions of this sort, and they've been sufficiently strong that
> they're unsupportable. It's basically incompatible with having any parallel
> connections at all.)
>
>>>> 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

---

From: Kyle Rose <[email-masked]>
Date: Sat, 4 Jun 2016 14:42:28 -0400

> annoying (though I agree, not fatal).

I have several thoughts:

(1) In many cases, the client can handle this unilaterally. Are there
examples of this kind of ticket-relevant state change that the client would
not be aware of? When the client is aware of a state change (such as client
auth negotiation), it can purge any tickets received before the state
change.

(2) If the ticket isn't encrypted data but is instead just an index into
full session state on the server, the ticket might actually still be valid
for state changes that occur after the ticket was handed out. I have no
idea how common this brand of session caching is likely to be, but I'm
guessing "not very".

(3) Tickets already allow the server to encode state: the proposal here
seems to be about revealing additional ticket semantics to the client. The
server could after all encode the generation in the (encrypted) ticket and
then use that to reject old tickets: this results in more full handshakes,
but it would eliminate weird behavior when clients use old tickets.

Correctness seems achievable either way, so I'm not sure a purge mechanism
(beyond expiration) is justified by this specific use case in isolation.
Are there other uses cases for which server-initiated purge of classes of
session tickets would be helpful?

Kyle

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Jun 2016 12:04:11 -0700

> auth negotiation), it can purge any tickets received before the state

Sure. HTTP-level authentication via a Web form.

> session tickets would be helpful?

Unexpected key changes.

-Ekr

---

From: Kyle Rose <[email-masked]>
Date: Sat, 4 Jun 2016 15:36:44 -0400

> Sure. HTTP-level authentication via a Web form.

Would that typically feed into the ticket state? I'm thinking of something
like Rails, which (at least when I worked with it) maintained its own
session state separately from TLS session state, and signaled via cookie or
Auth header.

>> session tickets would be helpful?

Rotation of the ticket-encrypting key? This seems like a good argument for
it, because it's something that's likely to happen regularly, and maybe
even on a schedule, and almost certainly across all clients simultaneously
(meaning "load spike" if the clients aren't guided to the right behavior).

In general, I like the idea of having a way to purge state beyond simply
expiration; I wonder if generation is the right level of specificity, or if
it's too general and we should reopen the expiration time vs. issue
time+TTL discussion and allow purging by issue time. (I'm not actually
suggesting the latter.) But I also don't have a strong opinion about the
balance between complexity and performance benefit here.

Kyle

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Mon, 06 Jun 2016 10:53:30 +0100

Hi,

Le 2016-06-04 16:51, Eric Rescorla a écrit :
> 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.

Looking at the pull request, I don't think it will have much impact on 
the protocol analysis given that it doesn't introduce any adversarial 
capability that wasn't already present before. If anything, your change 
may enable a proof of session unlinkability for well-behaved clients 
connecting to honest servers, under a number of restrictions.

My main complain about the current specification is that it doesn't 
clearly state that the specified restriction mechanisms for ticket 
lifetime and usage only partially bound the forward secrecy loss of PSK; 
implementations themselves must independently keep track of the lifetime 
of any given PSK in addition to managing the lifetime of tickets and 
ticket encryption keys by servers.
For instance, if a server keeps re-issuing allow_psk_resumption tickets 
based on the same PSK it is up to the client to expire the session at 
some point even if still has valid ticket(s). Similarly, if servers do 
not store PSK lifetime information inside tickets it may end up using an 
ancient PSK although the ticket may have been encrypted under a recent 
ticket key.

Best,

Antoine

---

From: Felix Günther <[email-masked]>
Date: Mon, 6 Jun 2016 15:11:23 +0200

Hi,

> connecting to honest servers, under a number of restrictions.

I agree with Antoine that I don't expect multiple ticket values for the
same cryptographic key to have a (negative) impact on the/our security
results. As the ticket value is, through ClientHello, part of the
handshake hash, hence flowing into the key derviation, separate ticket
values should "domain-separate" the keys established from the same RMS.

And yes, might be one can establish some form of cryptographic
session/handshake unlinkability for honest client-server communication.

Cheers,
Felix