Toerless's comment is closest to what I wanted to write. (A) I think that this draft must add a text that at least captures the controversy of a non-hybrid KEMs. Nobody is disputing the fact that the issue of pure v.s. hybrid KEM is a subject of controversy in the WG. This document should at least capture that state of procedural history in the WG -- the WG has clearly reached the point of establishing the controversy.
(B) If, as it appears to me, the consensus of the WG is to recommend hybrid KEMs (v.s. pure), then this document should also state so. I think this will make the maximum number of people amenable to this document. This document accommodates a design choice of one important customer. However, this should not be done at the expense of the rest who do not think that this choice is optimal. On Sun, Feb 22, 2026 at 4:48 PM Toerless Eckert <[email protected]> wrote: > Given how i am only > > a) a beneficiary of TLS (thanks for all the privacy fish so far) > b) A non-cryptography-expert reader of draft-ietf-tls-mlkem-05 > c) A spectator usually attending this type of TLS debates with popcorn > > I hope my comments are useful, and although i definitely will not call > myself > a TLS WG participant, i do not think it would make sense for me to raise > the points > later in IETF last call than now during WG work phase (more work for IESG). > > I will constrain myself to two asks for textual improvements that i would > like to see. > Especially because without such textual improvements i wouldn't even > be able to come up with a good laymens opinion whether or not, or rather > when > and where to apply this drafts technology (as opposed to the alternative). > > 1. I think this document needs a BIG BOLD FACE introductory warning. > something like > > THIS RFC DOES NOT SPECIFY AN IETF STANDARDS TRACK METHOD. IT IS SOLELEY > PUBLISHED FOR INFORMATIONAL PURPOSES. THE IETF RECOMMENDS TO USE > draft-ietf-tls-ecdhe-mlkem IN ALL CIRCUMSTANCES INSTEAD OF THIS DOCUMENTS > METHOD. > > If this text is too strong, then maybe the WG should try to find a text > softened sufficiently for maybe even more than rough consensus. But the > document > really needs an explicit reminder about the difference in status because > it is likely that people will browse through this draft who are just > pointed > to it as a reference in some "regulatory framework". Even worse: It may be > browsed by people rewieving such a regulatory framework, not understanding > that from the eyes of the IETF there is a better technology. So let's pleae > make sure we (IETF) are not so lame to think that it is sufficient to > direct user of our technologies to our preferred methods by just the > document > header (heck, i just had IESG reviews that totally fell apart because IESG > didn't even check the status of RFCs correctly). > > 2. Given how important TLS and the evolution towards post-quantum crypto > is for many industries, it is quite frankly irresponsible to publish > documents > whose only real-world discussing text is > > a) Intro text: "standalone post-quantum key establishment, targeting > smaller key > sizes or less computation, and simplicity" > > b) One page of "only-for-the-eyes-of-security-experts" Section 5 > (security considerations) > > I really think that as long as this stays a WG document instead of an > individual submission, there needs to be a much more "laymen" oriented > description of attack vectors and how draft-ietf-tls-ecdhe-mlkem vs > this draft will fare against them. A good amount of this was discussed > on the list, but none of it made it into the text. That is lazy > by the WG. > > Of course, such an "operationally" focussed discussion of security > properties comparing the two mechanisms would also work very nicely > as a separate RFC, but i wouldn't know how IETF could make sure that > this RFC does not get published until such a comparison is also published > (normative references in an informational RFC ?). > > At minimum, it would be lovely to have at least ONE example in the RFC, > how the > added amount of storage and compute for ECDHE in the hybrid solution is > significant, given how (in my laymen understanding), both storage and > compute > would predominatly be determined by MLKEM. Else the intro claim "targeting > smaller key > sizes or less computation" is just marketing that should be removed. > > Or to paraphrase Uncle Ben: > > With great power over crypto comes great responsibility to explain better. > > Cheers > Toerless > > On Thu, Feb 12, 2026 at 11:05:22AM -0800, Joseph Salowey wrote: > > This message starts the second Working Group Last Call for the pure > ML-KEM > > document (draft-ietf-tls-mlkem-07). > > > > > > The file can be retrieved from: > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ > > > > The diff with the previous WGLC draft (-05) is here: > > > > > > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html > > < > https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-06&difftype=--html > > > > > > > > The main focus of this WGLC is to review new text providing more context > > around the use of pure ML-KEM. For those who indicated they wanted this > > text, please let us know if the new text satisfies you and if you support > > publication. This working group last call will end on February 27, 2026. > > > > > > Thank You. > > -- > --- > [email protected] > > _______________________________________________ > 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]
