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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
