On Fri, Nov 7, 2025 at 8:12 AM John Mattsson <john.mattsson= [email protected]> wrote:
> 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. > To me an ideal outcome would be if ML-KEM is N and X25519MLKEM768 is Y. > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
