50   Add mandatory support for extended master secret extension (RFC 7627) to TLS 1.2

Created: 05 Jul 2024

Status: Discussion (red)

Part: Part 3 (2023, Edition 2)

Links:

Page: 1

Clause: 1

Paragraph: 1

Issue

RFC 7627 seems highly relevant for embedded devices in power systems due to their reliance on long-lived TLS 1.2 sessions. Implementing the Extended Master Secret extension could help to prevent MITM attacks by ensuring that the session keys are uniquely bound to the initial handshake.

Proposal

Evaluate mandating support for RFC 7627 extended master secret for TLS 1.2 implementations.

https://datatracker.ietf.org/doc/html/rfc7627

Discussion Created Status
As reported in RFC 7627 mutual authentication doesn't help to prevent triple handshake attack: ".....Even if client authentication is used, the scenario still works, except that the two sessions now differ on both client and server identities.....). 03 Dec 24 Discussion (red)
I am OK to accept it as future improvement.

At the moment, I don't have a preference for making it optional or mandatory. From a testing perspective it is perhaps easier to make it mandatory. If it is mandatory you simply have to verify that the extension is there and that it works. If it is optional you need multiple test cases. 		27 Aug 24 Discussion (red)
Proposal to accept as future improvement.

The extended master secret is used to address the triple handshake vulnerability in which an active attacker as man-in-the-middle may force the generation of the same master secret on the connection to the TLS client and the TLS server. This is specifically problematic, if only server side authentication is used or if there is a delayed client authentication.

IEC 62351-3 requires always mutual authentication and also requires support for the session renegotiation extension, which binds a renegotiated session to the initially negotiated session also to thwart the triple handshake attack.

Based on the above the extended master secret should be supported at least optionally. Given that major TLS implementations (e.g., openSSL, mbed TLS, wolfssl) support this extension and enable it by default we could also require mandatory support. 		27 Aug 24 Discussion (red)
Based on the current discussion the support is accepted. Clarification is necessary, if support is to be handled as option or mandatory. This discussion should take the current means (renegotiation handshake extension used and mutual authentication) into account. 23 Jul 24 Accepted
We did not include the extension yet. Based on the discussion we had we referred to the session renegotiation extension to handle the Triple Handshake attack in TLS. Also as we always require mutual authentication including the verification of the received certificates we have to further analyze if the attack as described still applies.
Nevertheless, in any case, it may be good to include the use of the extension in an amendment to also address potential attacks using captured devices, for which the certificates have not been revoked.
The extension is already supported in major TLS implementations. So this may also help 		16 Jul 24 Triage
I have not yet looked into this in detail but at first sight it seems a good idea to include support for RFC 7627.
At the moment there is no reference to RFC 7627. If we want to mandate support for RFC 7627, I believe this should be handled via an amendment. 		16 Jul 24 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 24.12.6.1