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

[Eric Rescorla <[e-mail]>]

On Mon, Jul 20, 2015 at 12:12 AM, Dave Garrett <[e-mail]>
wrote:

> On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote:
> > 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.
>
> If the general ticket lifetime request route is not needed, here's the
> simplest route: just don't drop the Session Ticket extension.
>
>
> https://github.com/tlswg/tls13-spec/compare/master...davegarrett:recycleticketextension
>
> This keeps it with the same semantics for requesting a ticket, thus
> allowing TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2
> servers with no additional effort. TLS 1.3 sessions would be resumed using
> the new PSK-based method and TLS 1.2 sessions would be resumed using the
> old session ticket extension.
>
> Should I submit this as a PR? It seems like the obvious route if all we
> want is to just keep the ability for a client to not request a ticket. No
> need to write a new extension at all.


As I said initially, I'm having trouble seeing why this is particularly
useful.

-Ekr