I do not support the publication of this document. Both the ECDHE and
ML-KEM components of hybrid key agreement have important roles to play
in guaranteeing its security: ML-KEM obviously guards against
harvest-now-decrypt-later quantum attacks, and ECDHE guards against the
ongoing cryptanalysis of ML-KEM as well as side channels and other bugs
in ML-KEM implementations, which are far less mature than elliptic curve
implementations. A scheme without both presents a meaningfully increased
risk to users compared to the hybrid key agreement schemes already being
successfully rolled out.
If individual organizations want to use solo ML-KEM internally for
whatever reason, there is nothing stopping them from doing so, with or
without the tacit endorsement of an IETF publication. But as far as
globally interoperable, RFC-compliant TLS deployments go, providing
options that deviate from best practices exposes unsuspecting users to
unnecessary risks. It's for this very reason that TLS 1.3 mandates
ephemeral key exchange, despite the added computational effort for
servers to generate unique keypairs. Nobody is proposing to allow server
operators to disable forward secrecy, even though we're all trying our
hardest to prevent key compromises anyway, because ephemeral keys
mitigate the risks posed by static keys. In a similar vein, hybrid key
agreement should remain as the single published PQ migration target for
the foreseeable future because hybrid key agreement mitigates the risks
posed by solo ML-KEM key agreement.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
