On May 3, 2017, at 4:27 PM, Colm MacCárthaigh <[email protected]> wrote:
> On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni <[email protected]> > wrote: > >> The kind of application whose security requirements preclude use of RFC 5077 >> session tickets can and should likely also avoid both 0-RTT and session >> resumption entirely. > > I don't agree with this. Why should users of mobile devices, to pick one > example, > have to choose between speed and the extra risk of data disclosure for their > requests > and passwords? Their security requirements don't preclude use of RFC 5077 session tickets, they've been using them all along, and will continue to do so for the majority of destinations that will take quite some time to upgrade to TLS 1.3. As you might recall, I don't agree that STEKs are fundamentally less secure than remote session caches, I rather suspect that sensibly implemented STEKs are safer. [ I do concede that the current OpenSSL implementation leaves too much of the responsibility of doing STEKs right to applications, and I will endeavour to fix that. It is not especially difficult to implement a default-on key rotation mechanism. ] >> Second-guessing the server's design by looking at ticket sizes seems rather >> contrived. > > It's not a second guess. If the ticket size is smaller than the RPSK, then it > provably can not have been self-encrypted. But I agree that it says nothing > about the server-side security. They might be posting the keys to twitter. As you yourself concede it is not the size that matters. It is a very marginal indication of the security of the remote session. The server may wish to decorate the session id with additional data (say which data-centre issued the session) and fail your test, and yet be doing the type of session caching you're asking for. The client should either trust the server to cache sessions correctly (this would be the default client behaviour in most cases), or it can choose to forgo session re-use. Feel free to malign bad implementations of STEKs, but the basic mechanism is sound. -- Viktor. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
