On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote: > > > I'm not seeing a lot of value here. Remember that servers are not > > required (and have never been required) to do session resumption, but > > much of the overhead of doing it (having to have a database, session > > ticket machinery) is associated with being willing to do session > > resumption at all, so if a small fraction of clients would tell > > you that they're not interested in resumption, it's not clear that > > buys you much. > > > > Are there any server operators who think this is a useful feature > > and can explain why? > > These days, I'm operating servers that only support session tickets > (no server-side cache). If the client does not send the session > ticket extension, no session is cached. > > So for servers that elect the same strategy, there's no need for > a separate means to signal the client's intentions. > First, I think that there should be only one way to do resumption in TLS 1.3 anyway. All I'm asking for is that the client have some way of indicating whether or not it supports resumption. Viktor's method seems fine with me. Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft actually contains a regression here. It seems like it is no longer possible for the server to indicate how long a PSK should be held by the client to resume a session, and it seems like it is no longer possible for the server to indicate that it doesn't support resumption. I don't know that the lifetime hint is valuable, but being able to reduce attack surface by being disabling resumption for a session seems clearly useful. See https://www.secure-resumption.com/, CVE-2014-1490 in Firefox/NSS, and CVE-2015-1791 in OpenSSL, which show that it can be useful to avoid resumption in many cases. Cheers, Brian
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
