On Sun, Jul 19, 2015 at 11:28 PM, Brian Smith <br...@briansmith.org> wrote:
> 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. > I don't think that the current spec does so. > 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. > I think perhaps you have misunderstood the forward secrecy properties of the current draft. Unlike TLS 1.2 and previous, the current draft has a separate resumption master secret which is independently derived from the master secret used for the connection keys in the original connection. This means that if you don't resume the connection, you have forward secrecy for the original connection regardless of whether the server stores the session in the session cache or sends the client a ticket. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
