I think many people may strongly support DJB and his positions because he has a 3-decade+ history of strongly supporting the most secure ideas, to the detriment of nearly everything else. I've written articles critical of DJB over the decades because I didn't like his "full disclosure" (versus responsible disclosure) ideals. But one thing I can't deny is that whatever he is supporting is certainly on the side of the best security. And when you add that he's a central figure in the post-quantum world and is responsible for many long-surviving cryptography algorithms, perhaps the support is warranted. It's not like he's a newbie influencer without credentials to back his claims.
From: John Mattsson <[email protected]> Sent: Thursday, July 9, 2026 4:35 AM To: Harry Halpin <[email protected]> Cc: [email protected] Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) I think the tendency to idolize people such as Bernstein causes a lot of problems: it leads people to evaluate arguments based on who makes them rather than on their technical merits. Whenever I see someone idolizing another person, I am reminded of this study [1]. A major strength of the IETF is that it brings together participants from industry, governments, and academia. None of these groups is inherently neutral. Industry participants often advocate for approaches that benefit their businesses, and while many researchers are admirably objective, others strongly promote their own work. I do not think it would be wise to exclude people affiliated with governments from leadership roles. I would welcome greater participation from ANSSI and other EU agencies in the IETF, and I believe the IETF needs as many competent people as possible to volunteer for various positions. These roles involve difficult, unpaid, and often very underappreciated work. The key issue is not institutional affiliation; it is ensuring that decisions are made transparently and based on technical merit. Cheers, John Preuß Mattsson [1] https://pmc.ncbi.nlm.nih.gov/articles/PMC8574017/ From: Harry Halpin <[email protected]<mailto:[email protected]>> Date: Wednesday, 8 July 2026 at 20:33 To: Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) Hi everyone, I do not support the publication of the document. Overall, given the immaturity of the standards and lack of real clarity over safe parameters, and given the importance of TLS in encrypting most of the world's traffic in combination with the fairly low additional overhead of hybrid KEM mode for TLS, I think it makes sense to in general to recommend to use hybrid mode with X25519. Of course an Informational RFC is not a recommendation, but it can easily and will be viewed as such. As a former W3C staff member, I do understand there is a fairly informal process for Informational IETF RFCs and internally they are viewed more as house-keeping for implementers, but one must remember for the outside world, including many implementers, even Informational RFCs are treated as de-facto standards. So additional care must be taken and a certain degree of conservatism should be expected. As an implementer, for example, at Nym, our VPN product uses hybrid mode with ML-KEM and X25519, and is working on implementing support for non-lattice postquantum alternatives just to be extra paranoid. However this may be a bit off topic and non-technical, in addition to various purely technical arguments, but I do think it would be healthy for the IETF to discuss the role of the NSA inside the IETF which is the underlying issue leading to a clear lack of consensus over what could be a minor Informational RFC. The IETF as a body of individual engineers did a remarkable job post-Snowden in pushing through TLS 1.3 and gained the trust of much of the larger international community (developers, users, and nation-states), and X25519 - due to its neutral academic background and the personal reputation for integrity by DJB and Lange - was very well-received as an option to the NIST curves in TLS. The IETF received a well-deserved reputation this for being relatively free of undue US influence. So it should come as no surprise, given the NSA's original and well-documented historically attempted suppression of public key cryptography, backdoors in RNGs, and weakened standards means of course that when the NSA asks to drop all options - in even an Informational RFC - but ML-KEM in TLS that many people are concerned. So the real danger here is that the IETF loses its popular legitimacy due to following the NSA's recommendation given to the IETF years ago to remove X25519 hybrid mode, as the RFC may be seen not as as an "option" but as the recommended way to do it by implementers unaware of the intricacies of the IETF and what "Informational" means in terms of IETF process. How to avoid this problem in the future? I understand that any process change is outside of the scope of the TLS WG, but we will bring it up with the IESG and IAB. The IETF is composed of individuals, not institutions like the NSA, so it seems reasonable that while individuals can participate as individuals, I would recommend any individual affiliated with a national security agency like the NSA, not chair any Working Group, serve as editors of documents, and should not "drive" a process. It is important to be neutral so this practice should apply across any security agency, like ANSSI in France and so forth. The problem is exceptionally important today to make sure the IETF is not controlled by US institutions as they are increasingly viewed globally as not trustworthy due to the current geopolitical climate engendered by Trump, and if would be tragic for the internet if the IETF lost its legitimacy due to a real or even just perceived influence of any geopolitical actor. The mission to prevent the internet from fragmenting over postquantum cryptography - or any other issue - is of utmost importance to future generations, and minor procedural issues can thus have outsized importance down the line, as we learned with the standardization of DRM at W3C. Yours, Harry On Wed, 8 Jul 2026 at 17:42, James <[email protected]<mailto:[email protected]>> wrote: Hi, I support publishing draft-ietf-tls-mlkem-08. Best, James On Wed, 8 Jul 2026, 14:33 BARNETT Anthony, <[email protected]<mailto:[email protected]>> wrote: Classified as: {OPEN} I support publication of this document. Anthony Barnett {OPEN} The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform the originator immediately and delete it and all copies from your system. Thales UK Limited. A company registered in England and Wales. Registered Office: 350 Longwater Avenue<https://www.google.com/maps/search/350+Longwater+Avenue?entry=gmail&source=g>, Green Park, Reading, Berks RG2 6GF. Registered Number: 868273 Please consider the environment before printing a hard copy of this e-mail. _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
