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

[David Benjamin <[e-mail]>]

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 <[e-mail]> 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
> 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 <[e-mail]>
> 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-mail]> 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
>>>
>>
>