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

[Brian Smith <[e-mail]>]

Eric Rescorla <[e-mail]> wrote:

> On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith <[e-mail]>
> wrote:
>
>> 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)
>

It depends on how the server implements tickets. The server could implement
tickets the same way that it implements session ID-based resumption. That's
not a good idea, but I don't think the spec should prohibit that type of
implementation either since it unenforceable. Thus, because of that
possibility, it is valuable to have the client be able to say "don't cache
the session" and/or limit the session's lifetime, so the client can help
direct the level of forward secrecy for the session. Right now, only the
server has a say in how long a session will be forward-secret.

Note also that the NewSessionTicket extension precedes any application
data, so without a way to prevent an unwanted NewSessionTicket message from
being sent, the client has to waste effort and time to consume the
NewSessionTicket before it can do anything useful.

Anyway, I don't understand why you keep directing your question to server
vendors. The people that would be interested in such a feature are client
software vendors, for client software that wants to control the level of
forward secrecy for a session.

Cheers,
Brian