[TLS] Security Considerations for MLKEM draft

["Salz, Rich" <[e-mail]>]

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.