That's all fine and well, but parasocial interactions tend to get toxic. I believe this tendency will be exacerrbated when not tempered with the awareness that there are excellent people beyond your "faves" participating in the discussion.
On Thu, Jul 9, 2026 at 9:44 AM Andrew Lee <[email protected]> wrote: > Dear John, > > Evaluating participant track record is due diligence, and further, part of > the rough consensus process. > > Every single cryptographer is standing on the shoulders of giants like > Diffie, Hellman, Rivest, Shamir, and Adleman. Attempting to dismiss such > recognition leaves me… curious (without a better choice of words). > > Whenever I see someone dismissing their more distinguished peers, I am > reminded of this study [1]. > > Sincerely, > Andrew > > [1] https://link.springer.com/article/10.1007/s11126-025-10227-6 > > > On Jul 9, 2026, at 1:34 AM, John Mattsson <john.mattsson= > [email protected]> wrote: > > 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]> > *Date: *Wednesday, 8 July 2026 at 20:33 > *To: * > *Cc: *[email protected] <[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]> wrote: > > Hi, > > I support publishing draft-ietf-tls-mlkem-08. > > Best, > James > > On Wed, 8 Jul 2026, 14:33 BARNETT Anthony, < > [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] > To unsubscribe send an email to [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] > > > _______________________________________________ > 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]
