TLS suggests not more than 24 hours in RFC 5246 for sessionID lifetime. This document
follows this suggestion. Session resumption shall be performed in regular intervals for active
sessions. For ended sessions, the session may resume not later than 24 hours (depending on
the sessionID lifetime). The actual parameters should be defined based on risk assessment
by the operator.
There is no rationale given for this requirement. I can infer that the reason is to check Client state and create new connection keys, but this is not explicit. Further, there is no subsequent requirement to close previously-opened TLS connections after resumption. What is the client to do? Prefer this new TLS connection even if existing ones are open? Could the TLS client potentially open multiple unused connections due to this requirement and keep them all open?
Proposal
Add guidance for TLS connection management or remove this requirement.
Discussion
Created
Status
I am OK with rejecting this proposal.
30 Sep 24
Discussion (red)
Proposal to reject (Approve (N/A))
Guidance regarding the session handling is already provided in clause 7.4.4 as noted before. Regarding the rational for the timings RFC 5246 is referred to and seen as sufficient.
TLS connection handling (opening and closing TLS connections, application behavior, etc.) guidance like
- before resuming closed sessions, verify that there is no existing TLS session that can be used
- close TLS connections which are not used
- ...
are seen beyond the scope of a TLS profile definition in IEC 62351-3 and rather application specific.
27 Aug 24
Discussion (red)
The motivation to support session resumption is included in 7.4.4 and may be summarized as:
- regular session key update: 0 < session resumption interval < session renegotiation interval <= 24h
- optimized additional session establishment based on already existing session between the same peers to avoid asymmetric handshakes.
Additional guidance may be provided regarding usage of TLS connection by the application.