Re: [TLS] Fate of resumption

[Yoav Nir <[e-mail]>]

On Oct 18, 2014, at 7:16 PM, Eric Rescorla <[e-mail]> wrote:

> 
> The argument for resumption seems pretty straightforward: it requires
> significantly less computation (in the form of asymmetric operations)
> than a full handshake. I suspect that this argument is less powerful
> than it used to be for two reasons:
> 
> - Increased computational power.
> - Faster algorithms in the form of ECC.
> 

There’s one other thing, that is relevant for HTTPS, which is the biggest use case for TLS. The trend in recent years is that the TCP connections (and thus, TLS sessions) last for far longer than they used to.

This trend started with HTTP/1.1, but it’s now common for TLS sessions to last for many minutes as long as the browser window remains open.Since the original session lasts and lasts, there is less use for resumption. 

The latest figures I’ve heard were of 50% of sessions being resumed, which is still a lot, but far less than it used to be 10 years ago, when both browsers and servers typically closed TCP connections after several seconds of inactivity. Still, assuming PK operations account for a large chunk of a server’s CPU cycles (and it is so in some common benchmark tests), eliminating resumption can reduce a server’s session rate by up to 50%.

With HTTP/2 poised to get deployed on much of the Internet, that 50% figure (that I suspect is driven by browsers opening several simultaneous connections before a session cache entry is available) is likely to be reduced further.

Yoav