What is the equivalent of SSLSessionID for TLS1.3 sessions

Question

In TLSv1.2 the client was able to resume with the SSLSessionID. This ID stayed constant among multiple resumed sessions.

In my modified apache webserver, i have a logic, that checks the session-cookie against the SSLSessionID. If the SSLSessionID changed for the same cookie, i drop the request.

Now how could i achieve this in TLSv1.3. (The resumption of the session is not the problem, this works.)

The problem is, that the SSLSessionID changes for every request, also on resumed sessions.

Obviously my mechanism does no longer work so i need an identifier which stays constant among resumed sessions.

Answer 1

TL;DR: There is no strict equivalent, as the feature was dropped. But new session tickets were introduced for similar needs.

RFC 8446 on TLS 1.3 says this:

2.2. Resumption and Pre-Shared Key (PSK)

[..]

In TLS 1.2 and below, this functionality was provided by "session IDs" and "session tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.

Section §4.1.2 about ClientHello also describes this extension:

legacy_session_id:

Versions of TLS before TLS 1.3 supported a "session resumption" feature which has been merged with pre-shared keys in this version (see Section 2.2). A client which has a cached session ID set by a pre-TLS 1.3 server SHOULD set this field to that value. In compatibility mode (see Appendix D.4), this field MUST be non-empty, so a client not offering a pre-TLS 1.3 session MUST generate a new 32-byte value. This value need not be random but SHOULD be unpredictable to avoid implementations fixating on a specific value (also known as ossification). Otherwise, it MUST be set as a zero-length vector (i.e., a zero-valued single byte length field).

The closest you can find is a new "session ticket", see §4.6.1

But if you go however to things like https://ssl-config.mozilla.org/ you will see that all configurations are done with session tickets being disabled.

You can have a look at https://timtaubert.de/blog/2017/02/the-future-of-session-resumption/ for an explanation of the change between 1.2 and 1.3