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

["Bellebaum, Thomas" <[e-mail]>]

I **strongly oppose** publication of this document as is.

In the seven months since its adoption...

...the draft raised several concerns ([11][12][13][14][15][16][17][18][19] to just link a few, there were more) during the adoption call, regarding its comparison to hybrid constructions such as [1], its lack of proper motivation, its focus on a national standard, the possibility of key reuse [101], potential IPR problems, etc. While some of these could be resolved, others could not be brought to an agreement yet. [102]

...the eventual consensus call has triggered an IESG appeal [21], repeatedly [22], the discussion of which revolved around procedural matters more than it did on the question at hand. This has cost time, with the final response being published less than a week ago [23] and refering back to Paul Wouters to deal with the actual question.

...one person [31][32] brought up "Experimental" as the right track for the document, and one (me) advocated for "recommended=D" based on the above concerns.

...at IETF 124, the only GitHub pull request adding considerations around non-hybrid use [41] was rejected without ever mentioning that the pull request added such considerations. Instead, the presentation there was reduced to the (controversal yet discussable, as the PR explicitly mentions!) "recommended=D" change.

...a GitHub issue asking for better motivations was closed with the sole comment "No one is happy with longer motivations, keeping them shorter is better imo" [42], despite several people asking for motivation on the mailing list by that point.

...AD Paul Wouters wrote a summary of the arguments during the adoption call [51]. In the five days since, given the above, the following two quotes have not aged well:

> And people have proposed extending the
> Security Considerations to more clearly state that this algorithm is not
> recommended at this point in time. Without an RFC, these recommendations
> cannot be published by the IETF in a way that implementers would be known
> to consume.

> It was further argued
> that adopting and publishing this document gives the WG control over
> the accompanying warning text, such as Security Considerations, that
> can reflect the current consensus of not recommending pure MLKEM over
> hybrid at publication time.

Publishing a document which has caused such controversy without even mentioning the controversy in the document, let alone dealing with it and writing up appropriate security considerations, is not just a fatal signal to the community, as Stephen puts it. It does fundamentally not live up to the IETF's standards.

-- TBB

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/

[11] https://mailarchive.ietf.org/arch/msg/tls/toxVUv_d1pdDspbfo8OxcJeC_QU/
[12] https://mailarchive.ietf.org/arch/msg/tls/lLeVwL-GhfuEPmHM3dVJJ4Kh2As/
[13] https://mailarchive.ietf.org/arch/msg/tls/YyemGJF-4-hRVwOcJ47Rw4Nu8Js/
[14] https://mailarchive.ietf.org/arch/msg/tls/0R1IKE3_7vOVGKvf-UgO3BG2Wjk/
[15] https://mailarchive.ietf.org/arch/msg/tls/0f6XBGPElMLNoiS1Eh3u7EhzoGc/
[16] https://mailarchive.ietf.org/arch/msg/tls/2Dfu4x678DEKCzF-fkdvJHJkS-8/
[17] https://mailarchive.ietf.org/arch/msg/tls/EzKcwjagajQqcRpH4TDTn70W9hc/
[18] https://mailarchive.ietf.org/arch/msg/tls/YNSu6ZO5e0JMJ1cRlnxh6oIjyZg/
[19] https://mailarchive.ietf.org/arch/msg/tls/6DEv0wZpIkf_DNh8NR5RG6Vud34/

[21] https://datatracker.ietf.org/group/iesg/appeals/artifact/141
[22] https://datatracker.ietf.org/group/iesg/appeals/artifact/217
[23] https://datatracker.ietf.org/group/iesg/appeals/artifact/220

[31] https://mailarchive.ietf.org/arch/msg/tls/tLCzbjetxlFmlEnS2m_B5mGvXDs/
[32] https://mailarchive.ietf.org/arch/msg/tls/YjYKiztu3JmWiaAUz0O3szeMHMQ/
[33] https://mailarchive.ietf.org/arch/msg/tls/8K5t_3kktN2RJSGsxam4IWF01Xw/

[41] https://github.com/tlswg/draft-ietf-tls-mlkem/pull/6/files
[42] https://github.com/tlswg/draft-ietf-tls-mlkem/issues/7

[51] https://mailarchive.ietf.org/arch/msg/tls/dzPT8KQe4S-_pZROLUJMvS9pM0M/

[101] It was noted that when ignoring ciphertext reuse (which also used to be called a "key" with ECDH) this is not a problem with IND-CCA2 secure schemes, which ML-KEM claims to be. One critique of this argument is that IND-CCA2 of ML-KEM relies on a kind of "re-encryption", which an overly speed-minded person is incentivized to omit from their implementation. However, a speed-minded person would also reuse keys regardless of an explicit argument against it, so that criticism has limited value. Another threat, to forward secrecy, is addressed in the document.
[102] There has been some limited constructive discussion on some of these matters. For instance, https://mailarchive.ietf.org/arch/msg/tls/-pjWkZhvhABqEfn685AEs4WoIhU/ helped quantify memory requirements of KEMs, which was one _assumed_ reason for "needing to be fully PQ". None of these are reflected in the document, where they would be helpful to application developers.