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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
