Eric Rescorla <e...@rtfm.com> wrote: > On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith <br...@briansmith.org> > 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
