[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

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]