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

[Eric Rescorla <[e-mail]>]

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

> On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni <[e-mail]>
> wrote:
>
>> On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote:
>>
>> > I'm not seeing a lot of value here. Remember that servers are not
>> > required (and have never been required) to do session resumption, but
>> > much of the overhead of doing it (having to have a database, session
>> > ticket machinery) is associated with being willing to do session
>> > resumption at all, so if a small fraction of clients would tell
>> > you that they're not interested in resumption, it's not clear that
>> > buys you much.
>> >
>> > Are there any server operators who think this is a useful feature
>> > and can explain why?
>>
>> These days, I'm operating servers that only support session tickets
>> (no server-side cache).  If the client does not send the session
>> ticket extension, no session is cached.
>>
>> So for servers that elect the same strategy, there's no need for
>> a separate means to signal the client's intentions.
>>
>
> First, I think that there should be only one way to do resumption in TLS
> 1.3 anyway. All I'm asking for is that the client have some way of
> indicating whether or not it supports resumption. Viktor's method seems
> fine with me.
>
> 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.

-Ekr