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

[Benjamin Kaduk <[e-mail]>]

# Ben Kaduk's review of draft-ietf-tls-mlkem-05
CC @kaduk

I do not support publication of this document at this time; see the "discuss" points for specific items that IMO should be blocking.  (I'm not an AD anymore, of course, so they aren't actually blocking just because I think they should be, but this is a handy review template...)

## Discuss

### KeyShare semantics

In §4.2 when we write

> 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.

that misrepresents the semantics of the "key_share" extension (and I assume we are not attempting to redefine core TLS 1.3 semantics).  "key_share" contains cryptographic parameters but makes no indication about algorithms that the client (or server) supports -- that role is fulfiled by "supported_groups".

(It's also a bit strange to have prose describing what KeyShareClientHello contains without corresponding prose about the KeyShareServerHello, but since we're not actually redefining what TLS 1.3 says I guess we don't need to.  But by that measure we don't need to have prose about KeyShareClientHello, either.)

### Security considerations of non-hybrid

draft-ietf-tls-hybrid-design has passed WGLC and IETF LC and is in the RFC-Editor queue.  While it does indicate that "Ideally, one would not use hybrid key exchange: one would have confidence in a single algorithm and parameterization that will stand the test of time", it also states clearly that "Many (though not all) post-quantum algorithms currently under consideration are relatively new; they have not been subject to the same depth of study as RSA and finite-field or elliptic curve Diffie-Hellman, and thus the security community does not necessarily have as much confidence in their fundamental security, or the concrete security level of specific parameterizations."

If we believe that this description does not apply to ML-KEM or the situation has changed since draft-ietf-tls-hybrid-design was approved, we need to say so.  But, on the other hand, if we believe that this description remains accurate, we need to acknowledge those concerns in this document.  draft-ietf-tls-hybrid-design has set the context for the use of PQC in TLS and we need to say how this document fits into that context.  I would mostly expect such discussion to include some kind of criteria for assessing whether a given use case would or would not benefit from using pure ML-KEM over a hybrid (and any tradeoffs involved in making that decision), too.

## Comments

### Presumption of migrating beyond hybrids

In §1.1 we note that "Having a purely post-quantum (not hybrid) key establishment option for TLS 1.3 is necessary for migrating beyond hybrids and for users that want or need post-quantum security without hybrids" which is true if we presuppose that there is a need to migrate beyond hybrids and user desire to achieve post-quantum security without hybrids, but does not really justify those presuppositions.  I think we should try to avoid value judgements (which may be hard to achieve consensus on), and thus that we should rather say something like "This document defines key-establishment options for TLS 1.3 that use solely post-quantum algorithms, without a hybrid construction that also includes a traditional cryptographic algorithm".

### definitions

I think it's worth noting the specific terms that we use from FIPS203, e.g., "key seed" (though FIPS 203 seems to just use a bare "seed") or otherwise aligning our terminology more closely with FIPS 203.

### encapsulation key check

In §4.2 we say the server MUST perform the check from §7.2 of FIPS203, which presumably is intended to disallow the option in FIPS203 of "assurance that these checks have been performed can be acquired through other means".  If that's the intent, I think we should say so explicitly, e.g., "the server MUST NOT rely on 'assurance that these checks have been performed' that is acquired through other means".

### contributory behavior

KEMs diverge in general from traditional key-agreement mechanisms with respect to the so-called "contributory behavior", which IIUC corresponds to the LEAK-BIND-K-PK property in [CDM23].  Again if I am reading [CDM23] correctly, ML-KEM itself does provide this property, and then the TLS 1.3 protocol structure *also* (with transcript hash and both endpoints providing randomness) achieves contributory behavior, so in practice we seem to be safe.  But the discussion in §5.2 is pretty hard to follow (in particular, the grammar and binding of pronouns doesn't seem to line up) and seems to talk only about the TLS 1.3 handshake properties, ignoring the properties of ML-KEM itself.  I think this discussion needs to be fleshed out further to cover what we get from the TLS handshake/key schedule, what we get from ML-KEM, and how they are related.

### Main security property for KEMs

Do we want to cite a reference for a claim that "The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack"?  (I happen to agree, but this is not really something that the TLS WG should be trying to speak authoritatively on.)

### IND-CCA vs IND-CCA2

In this document we state that ML-KEM achieves IND-CCA, but draft-ietf-tls-hybrid-design requires that the KEMs used are "designed to be secure in the event that the public key is reused, such as achieving IND-CCA2 security or ..." (while separately noting that ML-KEM has such security properties).  I recognize that the distinction between IND-CCA and IND-CCA1 and IND-CCA2 is not always worth making, but it also seems like we should try to be consistent across our own related documents.  Can we get away with just talking about IND-CCA2 here, or are there other considerations such that we should keep the IND-CCA term and add text to bridge the gap between documents?

## Nits

### Forward Secrecy

In RFC 8446 we opted to use just "forward secrecy" rather than "perfect forward secrety", and I think we should continue that practice here.

# Notes

This review is formatted in the "IETF Comments" Markdown format, see https://github.com/mnot/ietf-comments .