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

[Eric Rescorla <[e-mail]>]

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