If the called entity does not receive a TLS renegotiation (ClientHello) in response to a HelloRequest, the called entity shall terminate the connection.
However, the standard does not specify how long to wait. Perhaps the Client does not implement HelloRequest (although it should if following IEC 62351-3:2023) or perhaps the message was lost in transit due to a TCP failure. In the former case, it seems that we need to specify some maximum time in case the Client does not respond with a HelloRequest.
Proposal
Specify a maximum time, e.g., "60 seconds".
Discussion
Created
Status
The proposed text is OK for me.
20 Jun 25
Discussion (red)
I just stated the explicit reference to TLS 1.2 (RFC 5246 section 7.2.2) as explanation where to find it. Section 7.4.5 requires adherence to TLS 1.2 so we may not put the RFC informaiton there, as we stated TLS 1.2 and referenced the RFC in the sections before. As we describe the handling of failures during renegotiation already, we can request the same for the HelloRequest processing.
Proposal to include the following into clause 7.4.5, see also attachement:
A client shall reply to the HelloRequest message with a ClientHello within 60 seconds. If the server does not receive a ClientHello within 60 seconds after the HelloRequest was sent, a security event shall be raised event ("alarm: HelloRequest timed out") and the connection shall be terminated.
As the current edition does not specify the timeout values and further handling, it may be treated as future improvement.
20 Jun 25
Discussion (red)
I do not see where in clause 7.4.5 we refer to RFC 5246 section 7.2.2.
Clause 7.4.5 does say: "If the called entity does not receive a TLS renegotiation (ClientHello) in response to a HelloRequest, the called entity shall terminate the connection."
In my opinion, a renegotiation is like a complete handshake. If this fails for some reason we should terminate the connection as we would also do for an initial handshake.
19 Jun 25
Discussion (red)
In clause 7.4.5 we do not specify the behavior of the server, if the renegotiation fails. We rather provide a reference to TLS v1.2, (RFC 5246, Section 7.2.2). Here, the reaction is open and only a recommendation to close the connection if no renegotiation is done.
Likewise, the handling of no response to a HelloRequest should be handled, to be consistent.
18 Jun 25
Discussion (red)
During the WG15 meeting 06/2025 the following has been agreed:
Proposal to go forward with a time out value for the response time to a HelloRequest (60s). This would lead to the following enhancement in clause 7.4.5:
A client shall react to the HelloRequest message with a ClientHello within 60 seconds. If the server does not receive a ClientHello within 60 seconds after the HelloRequest was sent, a security event shall be raised event ("alarm: HelloRequest timed out") and the session shall be terminated.
---
Note that the session termination has consequently been added but should be idscussed further.
16 Jun 25
Discussion (red)
Needs discussion
08 Jan 25
Discussion (red)
I just checked a little bit more. The handshake timeout is usually handled by the application that uses a TLS library.
So, do we want to define such a configurable timeout value in IEC 62351-3, or in the referencing standards like IEC 60870-5-7?
30 Oct 24
Accepted
I guess this kind of thing could happen with every TLS message in the handshake.
So, there must be some TLS timeout somewhere in the TLS stack. I think we need to investigate this further.
30 Oct 24
Accepted
As RFC 5246 does not specify a reaction time on the HelloRequest and essentially leaves it open to the application, it is probably good to have a maximum value here before terminating the connection. It has to be kept in mind to verify if common stack implementations support this configuration.