Hi, I support publication as long as the major comments below are addressed.
I think it is correct to publish the "groups" as RECOMMENDED = N and then discuss all algorithms together at a later stage. I can understand why some people strongly prefer hybrids to protect against implementation bugs, but I do not see why standalone ML-KEM should be marked as discouraged. It is a very well-studied algorithm believed to provide very good security. European governments are now stating that they have the highest confidence in ML-KEM. I think the recommended level should be above P-256, X25519, and all other algorithms providing zero security against quantum attackers. Major: - "The KeyShareClientHello includes a list of KeyShareEntry structs that represent the key establishment algorithms the client supports. For each parameter of ML-KEM the client supports, the corresponding KeyShareEntry consists of a NamedGroup that indicates the appropriate parameter, and a key_exchange value that is the pk output of the KeyGen algorithm." This seems like an explanation of the "supported_groups" extension, not the KeyShareClientHello. My understanding is that "supported_groups" represent the key establishment algorithms the client supports and that KeyShareClientHello is a subset. I suggest removing text (incorrectly) duplicating RFC 8446. - "For all parameter sets, the server MUST perform the encapsulation key check described in Section 7.2 of [FIPS203]" I completely agree that NIST requirements should be followed but explicitly mention 7.2 and not other mandatory requirements like the decapsulation input check in 7.3 might make the reader wondering if the mandatory requirements in e.g., 7.3. can be skipped, which I would disagree with. - "TLS 1.3 does not prohibit key re-use; some implementations may use the same ephemeral public key for more than one key establishment at the cost of limited forward secrecy. Care must be taken to ensure that keys are only re-used if the algorithms from which they are derived are designed to be secure under key-reuse. ML-KEM's IND-CCA security satisfies this requirement such that the public key/secret key pair can be used long-term or re-used without compromising the security of the keys. However, it is still recommended that implementations avoid re-use of any keys (including ML-KEM keys) to ensure perfect forward secrecy." This is wrong in many ways. FIPS 203 forbids reuse of ephemeral keys, which applies to this draft. IETF specifications referring to FIPS 203 may not use the same ephemeral public key for more than one key establishment. TLS WG has not discussed violating NISTs requirements, and I suspect most people in IETF do not want to violate NIST requirements for ML-KEM, I certainly don't. Ephemeral keys should be independent and reusing them has a large number of negative security consequences. As stated in NIST SP 1800-37 “Addressing Visibility Challenges with TLS 1.3 within the Enterprise High-Level Document”: “Reuse of a key share allows passive observers to correlate different connections. This specification discourages client and server reuse of a key share for multiple internet connections. Reusing key shares outside protected facilities can also expand the impact of security breaches.” And the above statement from NIST is too soft. If you believe in zero trust rather than perimeter security, reusing key shares can expand the impact of security breaches even within protected facilities. Moreover, reusing key shares also weakens post-compromise security. Minor: - I think the draft should mention that ML-KEM is very very fast. Suggestion: "Optimized implementations of ML-KEM achieve key generation, encapsulation, and decapsulation operations that are faster than elliptic-curve Diffie–Hellman mechanisms (such as X25519 or P-256) on modern 64-bit CPU architectures with vector instructions." - [AVIRAM], [DOWLING], [FO], [HHK], [HPKE], [hybrid], [LUCKY13], [RACCOON] are not used and should be removed. - OLD: key establishment mechanism (KEM) NEW: key encapsulation mechanism (KEM) Cheers, John
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
