Could TLS session resumption be another ‘super cookie’?

The problem with trying to stop advertisers from tracking web users is that the complex engineering of the web offers so many ways for them to do this.
Well-known techniques include using cookies and browser fingerprinting, which is why Firefox and Apple’s Safari have introduced new controls designed to blunt them in recent weeks.
However, researchers at the University of Hamburg think they’ve spotted another one nobody has been paying attention to – Transport Layer Security (TLS) session resumption.
Session resumption isn’t supposed to be a tracking tool – it’s a perfectly sensible way for a server to resume an encrypted TLS session (TLS being the protocol successor to SSL used to secure HTTPS), without having to go through the palaver of repeated handshakes every time.
These days, a visit to almost any website will establish possibly dozens of these TLS connections, mostly to advertisers whose ads are placed on or around the page that interests the user.
Under TLS 1.2 this works using either session IDs or tickets, while the newer TLS 1.3 uses pre-shared keys (PSKs). In either case, what matters is that they all create a session ticket or key that sits in the browser cache which could, in theory, be tracked as the user moves from site to site.
How easy would this be to do in real-world conditions?
One issue is how long the session resumption ticket remains valid, which depending on the TLS version and the website interacting with it could be anything from minutes to days.
They’re also cleared when a user closes a browser session which, the researchers point out, could still be days for mobile browsers.
To offer a clearer idea, the researchers tested 48 different browsers against the resumption lifetimes used by the top one million sites on Alexa.
Not all use TLS but of the 691,000 that do, 80% set the lifetime of the session at 10 minutes or lower. Interestingly, Google and Facebook turned out to be outliers, setting the timeout at 28 hours and 48 hours respectively, although this is probably done for performance reasons.
Turning to browsers (excluding those such as Tor which don’t support TLS session resumption at all), tracking was possible for 38 of the 48 tested.
However, all set limits for TLS session identifiers to anything from around 30 minutes (i.e. Chrome for TLS 1.2) to one day (Firefox for both TLS 1.2/1.3).

On the face of it this is reassuring but remember that if a user encounters a third-party advertiser setting a TLS session resumption identifier more often than the timeout specified by the browser (i.e. one day for Firefox), it is possible to reset it repeatedly to extend its lifetime up to the maximum allowed by the version of TLS being used.
The researchers conclude:

Our results indicate that with the standard setting of the session resumption lifetime in many current browsers, the average user can be tracked for up to eight days.

Shady tracking techniques are often combined rather than used in isolation so in the wild the technique might be used to respawn deleted cookies, or mixed in with other fingerprinting techniques to extend that eight day limit indefinitely.
To sum this up: nobody seems to be using TLS session resumption to track users – there are no shortage of easier ways to do this already – but this might change if tracking control becomes more widespread.
Fixing this hypothetical weakness won’t be easy. Browser makers could set lower lifetimes for session identifiers or even dispense with them completely, but that might impact performance.
One solution might be to allow session resumption for first-party domains but not third-parties. However, this would inevitably be seen as a hit on traffic and latency given that most websites make numerous third-party HTTPS TLS connections.