TLS session resumption
On the mailing, list Solderpunk drew attention to the issue of tracking via TLS session resumption:
https://lists.orbitalfox.eu/archives/gemini/2020/001903.html
Regarding TLS session resumption, there is the issue to consider of so-called "prolongation attacks":
whereby TLS session information which roundtrips from the server to client and back can be used (as can any information which roundtrips in this way) for tracking. This could be mitigated easily with client-side policies on maximum session duration, but would be something for implementers to be wary of.
The paper he linked to is really good. Some takeaways from the section on countermeasures (page 9):
- To maximize privacy, clients should not use TLS session resumption at all. This is what Tor Browser does. However, client developers who wish to take advantage of the performance gains of session resumption should keep in mind the following points:
- To prevent prolongation attacks, the paper says: "We recommend that a server-initiated renewal of a session identifier must not lead to a prolongation of client-side expiry dates. Instead, a client must stick to the expiry date of the initial session identifier."
- The paper recommends a maximum lifetime of 10 minutes for the session cache.
- The paper recommends deactivating TLS 1.3 1-RTT session resumption, as the performance gains are much too small to justify the cost to privacy.
These recommendations could be put in the best practices document.
Or, to make things simple, the spec can say "TLS session resumption must not be used".
On a related note, 0-RTT should be used with caution, to protect against replay attacks:
- A safe bet for server admins is not to use 0-RTT for "any request with non-reversible non-trivial consequences".
- When clients issue requests using client certificates, they should not use 0-RTT.
Also see https://blog.cloudflare.com/introducing-0-rtt/#whatsthecatch