Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Eric Rescorla <[e-mail]>]

On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith <[e-mail]> wrote:

> Eric Rescorla <[e-mail]> wrote:
>
>> On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith <[e-mail]>
>> wrote:
>>
>>> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft
>>> actually contains a regression here. It seems like it is no longer possible
>>> for the server to indicate how long a PSK should be held by the client to
>>> resume a session,
>>>
>>
>> Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint
>> value.
>>
>> http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12
>>
>> and it seems like it is no longer possible for the server to indicate
>>> that it doesn't support resumption.
>>>
>>
>> Well, it can't indicate it, but if it doesn't supply a session ticket,
>> there's no way for
>> the client to do it.
>>
>
> Great. I was misunderstanding. Here's the part that is not is still not
> clear to me: Is the SessionTicket extension still to be used or not? It
> seems not, AFAICT. If the SessionTicket extension were to be used, then
> everything would work perfectly as Viktor suggested in his message: the
> absense of the SessionTicket extension in the ClientHello would be the way
> that a client can indicate that it doesn't want the session to be cached.
>

No, it's not used.


It seems weird that the server can supply a lifetime hint but the client
> can't, especially in cases like WebRTC where there is no functional
> difference between the two. But, that's a smaller issue than the lack of an
> indication that resumption machinery isn't wanted at all.
>

I don't think it's *that* odd, since tickets have at least two fundamental
asymmetries:

- The client needs to actually keep state and the server does not
(that being the point of tickets)
- The client (because they speak first) gets to offer the ticket for
resumption and the server can accept it or reject it.

-Ekr