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

[Dave Garrett <[e-mail]>]

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.


Dave