mbedtls
mbedtls copied to clipboard
Remove static ECDH cipher suites
Static ECDH is officially deprecated by RFC 9325. It does not exist in TLS 1.3. OpenSSL stopped supporting static (EC)DH in its 1.1.0 release in 2016.
Does Mbed TLS 4 still need to support static ECDH?
(Related: https://github.com/Mbed-TLS/mbedtls/issues/7679 — if we keep them, they might be disabled by default.)
Mailing list thread: https://lists.trustedfirmware.org/archives/list/[email protected]/thread/AVTTVTS654DD45NYRCWA6G4WI4AOCYAH/
Note: we have tests in ssl-opt.sh that use static ECDH key exchange to test other things, for example, handling of the keyUsage extension in certificates. To my knowledge, static ECDH was the only key exchange using the keyAgreement bit, so positive tests about this bit will probably just be removed without a replacement.
(If we also remove plain-RSA suites as we're planning to then all cert-based key exchanges will be needing the digitalSignature bit, so we can only have positive testing of that bit and negative testing of its absence - so TLS 1.2 will become aligned with TLS 1.3 on this point. I'm talking about testing above, but probably the library code about keyUsage in TLS can be simplified as well.).)
A few years ago (private link) we had a hard requirement on static ECDH keys (with a key enrolled using ECDSA) for the DLMS/IEC 62056 protocol used in smart meters. I don't actually know about the network protocol side: does DLMS use TLS with a static ECDH cipher suite, or does it use a different protocol which includes an ECDH key exchange?
As far as I can tell without access to official specifications, DLMS uses its own secure channel protocol. I see several mentions of TLS as an optional transport mechanism for DLMS, distinct from the protocol that allows several “security suites” that may involve ECDH (and ECDSA!). The clearest source is DLMS/COSEM Protocol — Security Walk-Through which states
The protocol integrates all the required security features in the application layer. (…) – Ad-hoc security mechanisms imply lightweight implementation wrt TLS or similar generic protocols. – Application-to-application security regardless of the communication media used for transport.
So DLMS support is not a requirement on TLS, and in particular not a requirement on static ECDH cipher suites in TLS.
Architectural decision: we are removing static ECDH cipher suites from Mbed TLS 4.0. That means the MBEDTLS_KEY_EXCHANGE_ECDH_RSA and MBEDTLS_KEY_EXCHANGE_ECDH_ECDSA key exchanges.
See https://github.com/Mbed-TLS/mbedtls/issues/9681 for a recipe for removing key exchange types.
At this time, we would like to remove static ECDH, but we haven't scheduled it yet, and we may run out of time.
@bjwtaylor We've established a procedure for removing a key exchange family: https://github.com/Mbed-TLS/mbedtls/issues/9681 . The list of tasks might need to be tweaked a bit because each key exchange has its specificities, but please try to follow the same procedure. It's not just a matter of completeness, but also this has proved to be relatively easy to review.