[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[Bas Westerbaan <[e-mail]>]

On Fri, Nov 7, 2025 at 8:12 AM John Mattsson <john.mattsson=
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>