I made a PR [1] to revise the security considerations. It has some facts about pure-MLKEM, and then makes a comparison based strictly on what the two drafts each say in their IANA sections. I hope it’s useful. New text is below.
[1] https://github.com/tlswg/draft-ietf-tls-mlkem/pull/14 # Security Considerations {#security-considerations} {{NIST-SP-800-227}} includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers. TLS 1.3's key schedule commits to the ML-KEM encapsulation key and the ciphertext as the `key_exchange` field of the `key_share` extension is populated with those values, which are included as part of the handshake messages. This provides resilience against re-encapsulation attacks against KEMs used for key establishment {{CDM23}}. This document defines standalone ML-KEM key establishment for TLS 1.3. A hybrid combines a traditional algorithm such as ECDH with a post-quantum algorithm such as ML-KEM. The IETF is working on an RFC that defines several hybrid key extablishment mechanism, each combining a tradition ECDHE curve with ML-KEM in {{ECDHE-MLKEM}}. Both documents have IANA registry entries with an `N` in the recommended column. Quoting from the registry {{TLSREG}}, "\[this] does not necessarily mean that it is flawed; rather, it indicates that the item ... has limited applicability, or is intended only for specific use cases." Those developing or deploying TLS 1.3 with either encapsulation method will have to determine the security and operational considerations when choosing which mechanism to support.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
