Clients using TLSv1.2 shall include the signature_algorithm extension with at least the
combination of {SHA-1, RSA; SHA-256, RSA; SHA-256, ECDSA} in the ClientHello
message. The combination SHA-1 and RSA is for backward compatibility only (see also below)
and depends on an organization’s security policy (see also 7.4.3). Other combinations may be
supported.
At first glance this appears as though the TLS 1.2 peer can avoid implementing SHA-1. However, here is RFC 5246 https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.1.4.1
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
sent the value {sha1,rsa}.
- If the negotiated key exchange algorithm is one of (DHE_DSS,
DH_DSS), behave as if the client had sent the value {sha1,dsa}.
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
This clause in RFC 5246 means that TLS 1.2 peers must support SHA-1.
Proposal
Devices supporting IEC 62351-3:2023 already must support SHA-256. It no long makes sense to require TLS 1.2 peers to mandate support for backwards compatibility if it's not needed.
Therefore, update this standard to add the following correction to RFC 5246:
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
sent the value {sha256,rsa}.
- If the negotiated key exchange algorithm is one of (DHE_DSS,
DH_DSS), behave as if the client had sent the value {sha256,dsa}.
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
ECDHE_ECDSA), behave as if the client had sent value {sha256,ecdsa}.
This way TLS 1.2 peers following IEC 62351-3:2023 need not support SHA1 if backwards compatibility is not required.
Discussion
Created
Status
OK.
27 Aug 24
Discussion (red)
Proposal to reject (Approval (N/A))
26 Aug 24
Discussion (red)
I agree with the explanation of Steffen Fries. As we require that signature_algorithm extension, there is no problem.
27 Jun 24
Accepted
The correction proposed is for the case the TLS client does not send the signature_algorithm extension as requested according to IEC 62351-3.
Clause 7.5.4 already provides security events for the case a SHA-1, RSA proposal is detected and this allows for proper handling. In addition, following the proposal in Tissue #46, the combination of SHA-1, RSA should be removed as default proposal and only enable if allowed by the organization's security policy.
Note that if the proposed correction is stated in IEC 62351-3 it will overwrite the specified behavior in RFC 5246. Support of this in implementations is likely hard as standard implementations may not be utilized.
Regarding backward compatibility, the statement in the clause "Security policies of entities shall be able to disallow or prevent any optional hashing algorithms being supported." was intended to be restrictive in the policy. This consequently would leads to the change proposed in Tissue #46