On Mon, Jul 20, 2015 at 12:12 AM, Dave Garrett <davemgarr...@gmail.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
