Let’s stick to the consensus call, "I support" or do "I do not support" as was requested in the email that began this thread.
I will, again, repeat the reminder, about conduct: Conduct Reminder: Given the heated nature of previous discussions on this topic, participants are strongly reminded to adhere to the IETF Code of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep feedback professional, technical, and focused on the document's text. For the TLS Chairs, spt > On Jul 2, 2026, at 07:17, Nadim Kobeissi <[email protected]> wrote: > > Hi Mark, > > For the record, there’s absolutely nothing wrong whatsoever in discussing > these topics on Slacks or wherever. I myself have for example posted about > this topic on LinkedIn (before anyone shoots me, I only posted about it once, > on LinkedIn, around 3 months ago, and haven’t publicly discussed it since.) > > I’m just deeply annoyed by this pearl-clutching as if Bernstein is the first > person to ever discuss these topics in a more open forum. What’s the > difference between a Slack with many thousands of members all of which are > into cryptography/cybersecurity, and the Mastodon account of a researcher who > works on cryptography/cybersecurity? > > Filippo has been absolutely relentless in discussing this mlkem draft’s > consensus calls, and trying to involve people in the discussion. That’s his > right! Good for him! But please, don’t feign this ultra fake outrage when > other people do the same! > > > But Filippo’s behavior (which you view to be equivalent to Bernstein’s) has > > never convinced me to do what so many are currently doing in response to > > Bernstein’s actions. Instead, I watched the trash fire from afar. > > So what? You weren’t encouraged by Filippo’s post. I wasn’t encouraged by > Bernstein’s post, either, despite Filippo implying that I was a few days ago. > By the same metric that he’s measuring whether or not people were > “encouraged” by Bernstein, we could also imply that many were encouraged by > Filippo or others. Maybe they were encouraged by my LinkedIn post! Who knows? > It doesn’t matter! This is all very stupid, actually! Of course people will > go out and talk about things that matter to them to people they want to reach! > > > As the *most basic* example of misinformation, I would conjecture many who > > have recently joined are confused on the fundamental point that the vast > > majority of people supporting this RFC are *not recommending pure ML-KEM*. > > That is not the process that’s occurring. Characterizations of that as > > being what this RFC is about are falsehoods. Repeated justifications to > > this end by the people whose votes’ Bernstein has whipped are false. > > Misinformation exists, you’re right, but it’s manifesting on both sides of > the debate, Mark, not just the side you disagree with! See, this is actually > exactly the reason why I sent this email yesterday: > > https://mailarchive.ietf.org/arch/msg/tls/rkkyF_SHmtUwILNn4AGN7zoo6qU/ > > In that email, I try to debunk some of the more nonsensical reasons to oppose > this draft, but I also debunk some of the weaker reasons to *support* it. > This goes to show that misinformation is all over the place, and can be > engaged in by different people with more and less honest motivations! > > > Perhaps a standards body can create good standards in the presence of > > consensus votes where a significant plurality has never read the standard, > > and doesn’t understand the most basic point regarding its purpose. I don’t > > see how it would be possible personally. Who knows. > > You touch upon an important point: how will the chairs determine consensus > when the discussion has become so heated and unusually public? That’s a > totally fair question. I guess one thing that the chairs will try to do is > take the opinion of people who only just showed up on the list with less > weight than those who have been contributing to discussions or to TLS somehow > (by implementing it, studying it, deploying it, etc.) for a long time. It’s a > hard question! I certainly agree! > > I just hate the hypocrisy. Everyone here is busy with trying to show that > their side is the honest one and the opposing side is the one engaging in > dishonest tactics, dishonest arguments, misinformation, packing the vote, > blah blah blah. The truth is: both sides are being dishonest! You’re all the > same!!! > > Nadim Kobeissi > Symbolic Software • https://symbolic.software > >> On 2 Jul 2026, at 1:05 PM, [email protected] wrote: >> >> Hi Nadim, >> >> I’m on those same slacks. This has been discussed on those slacks for years. >> I’ve also followed the NIST PQC Google group since 2016. >> >> As I’ve said on those same slacks (which you appear to be a member of), I >> moved *away* from lattice based PQC (and instead toward lattice based FHE) >> due to Bernstein’s very difficult to engage with behavior during the NIST >> PQC saga. >> >> Despite this, I never sent an email to either mailing list. I find >> Bernstein’s behavior around standards bodies to be personally quite >> distasteful (to the point of changing my career path to avoid it). But >> Filippo’s behavior (which you view to be equivalent to Bernstein’s) has >> never convinced me to do what so many are currently doing in response to >> Bernstein’s actions. Instead, I watched the trash fire from afar. >> >> I only engage now (despite being a lattice cryptographer, who could have in >> good faith engaged for the last half decade) due to viewing Bernstein’s >> current actions as not only distasteful, but reprehensible. I would >> characterize it as combining misinformation with populism to achieve his own >> personal goals in a situation where his personal goals are the (extremely) >> minority position among informed cryptographers. In my eyes, Filippo’s >> numbers appear to back up this interpretation. >> >> As the *most basic* example of misinformation, I would conjecture many who >> have recently joined are confused on the fundamental point that the vast >> majority of people supporting this RFC are *not recommending pure ML-KEM*. >> That is not the process that’s occurring. Characterizations of that as being >> what this RFC is about are falsehoods. Repeated justifications to this end >> by the people whose votes’ Bernstein has whipped are false. >> >> Perhaps a standards body can create good standards in the presence of >> consensus votes where a significant plurality has never read the standard, >> and doesn’t understand the most basic point regarding its purpose. I don’t >> see how it would be possible personally. Who knows. >> >> Cordially, >> >> Mark >> >> Sent from my iPhone >> >>> On Jul 2, 2026, at 5:24 AM, Nadim Kobeissi <[email protected]> wrote: >>> >>> > Again for the record, Bernstein has taken the campaign to social media >>> and podcasts. >>> >>> Buddy, you’ve been talking about this draft nonstop on Slacks/Discords with >>> thousands of members for months! Stop this hypocrisy! >>> >>> Nadim Kobeissi >>> Symbolic Software • https://symbolic.software >>> >>>> On 2 Jul 2026, at 11:03 AM, Filippo Valsorda <[email protected]> wrote: >>>> >>>> 2026-06-28 11:08 GMT+02:00 Filippo Valsorda <[email protected] >>>> <mailto:[email protected]>>: >>>>> I want the WG and the chairs to be aware that Bernstein is now >>>>> coordinating a campaign to get dissenting opinions emailed to the list. >>>>> >>>>> > You can have your voice heard too. All you have to do is join the IETF >>>>> > TLS mailing list >>>>> > <https://mailman3.ietf.org/mailman3/lists/tls.ietf.org/> (under your >>>>> > real name, please!) and send a message to the mailing list by 7 July >>>>> > 2026 >>>>> > <https://web.archive.org/web/20260625052729/https://mailarchive.ietf.org/arch/msg/tls/ol2otAvtdDrdz_xY0_eKcuY1om0/> >>>>> > under the subject line "Re: [TLS] WG Last Call: >>>>> > draft-ietf-tls-mlkem-08 (Ends 2026-07-08)" saying that you do not >>>>> > support the publication of this document. >>>>> >>>>> https://web.archive.org/web/20260627234614/https://nsa.2026.action.cr.yp.to/ >>>> >>>> Again for the record, Bernstein has taken the campaign to social media and >>>> podcasts. >>>> >>>> > Unhappy with NSA's SIGINT Enabling Project sabotaging cryptographic >>>> > standards? This week you can take action to register an objection with >>>> > IETF regarding an NSA-funded project to standardize ietf-tls-mlkem, a >>>> > weakened version of ietf-tls-ecdhe-mlkem: >>>> > https://nsa.2026.action.cr.yp.to/ >>>> >>>> https://mastodon.cr.yp.to/@djb/116832263167396019 >>>> >>>> > 30 people have already spoken up against weakening ECC+PQ to solo PQ! We >>>> > can do this! Spread the word: https://nsa.2026.action.cr.yp.to >>>> > <https://nsa.2026.action.cr.yp.to/> >>>> >>>> https://mastodon.cr.yp.to/@djb/116845616210504681 >>>> >>>> > This isn't settled. The IETF vote on stripping the classical safety >>>> > layer out of post-quantum crypto closes July 7, and the public can >>>> > object. Here's the full history and how to add your voice: >>>> > action.cr.yp.to <https://action.cr.yp.to/> >>>> >>>> https://web.archive.org/web/20260702084803/https://bsky.app/profile/vpnet.bsky.social/post/3mph2bsrji22b >>>> >>>> > NSA is packing an IETF vote to weaken post-quantum crypto by July 7 >>>> >>>> https://www.youtube.com/watch?v=ndMRNSJ8Qtw >>>> >>>> He has also added an "Example" section to the call to action, in case the >>>> "participants" wish to express an opinion without going to the trouble of >>>> formulating one. >>>> >>>> > There have been more than 30 opposition statements as of 1 July 2026. >>>> > Here are links to some examples of different lengths: Christian Grothoff >>>> > <https://archive.cr.yp.to/2026-07-01/16:08:36/_akapbL9zzOnQJBT4YR2JZbtfMPS-rk8QQdMogTpe9s/https/mailarchive.ietf.org/arch/msg/tls/Err40FOTKRJkd1x5sKsV0cH4ZKs/>. >>>> > Orr Dunkelman >>>> > <https://archive.cr.yp.to/2026-07-01/16:07:24/qtkD-1JFduNRK4zInRk5w9ziWyK-4G_6A0okNQtph_0/https/mailarchive.ietf.org/arch/msg/tls/RbpRQbHkEizsM8P9XeyBzIm2Bpw/>. >>>> > Simon Josefsson >>>> > <https://archive.cr.yp.to/2026-07-01/16:10:28/LlM9K6evJGlnknH8rCD6xToMC34K-OB9IkNnEeb6VjE/https/mailarchive.ietf.org/arch/msg/tls/SABh7Sw1dqdv_I04WFUeQByoVVY/>. >>>> > Yaakov Stein >>>> > <https://archive.cr.yp.to/2026-07-01/16:12:02/wWjSAriqQfA6WTzgarXD9gRKbZJfpn0ZqsrJ47z0q80/https/mailarchive.ietf.org/arch/msg/tls/G8RweFH4IBTBXXSi_nOTAKMI9Vw/>. >>>> > Peter Gutmann >>>> > <https://archive.cr.yp.to/2026-07-01/16:07:52/qbngTb2vXHguklcI2xA8kPCxbSf1dXhPEn3dmMuWyps/https/mailarchive.ietf.org/arch/msg/tls/wB2mPlX4XU6FlkEZjzkuAboLt7s/>. >>>> > David Stainton >>>> > <https://archive.cr.yp.to/2026-07-01/16:01:58/vGQT9GkM15Cp2tmPMSRa8a8TnbiqWn6VweYf2mzb2Go/https/mailarchive.ietf.org/arch/msg/tls/TodOftD9_5f-YdLvkpNor1lo6s4/>. >>>> > Stephan Neuhaus >>>> > <https://archive.cr.yp.to/2026-07-01/16:00:54/KTiv1OIyfO9XLxPeAcQA_zGR_Dn-QEc-ShY74iiEPVs/https/mailarchive.ietf.org/arch/msg/tls/ebO-XDf2_dsJmekTCYjCJccrK8U/>. >>>> > Tanja Lange >>>> > <https://archive.cr.yp.to/2026-07-01/16:13:48/e6PXICNeQxNs2fNxzPiKklLbcfTfudAiy1UPP32CitY/https/mailarchive.ietf.org/arch/msg/tls/g2JIyULihGxzNTDhhgl1MabOnYM/>. >>>> > Bertrand Jacquin >>>> > <https://archive.cr.yp.to/2026-07-01/16:03:25/eq7GzQcI3Wj9p8xpX8AiQoDpAYKk3aSJEBFVSlgBi38/https/mailarchive.ietf.org/arch/msg/tls/sbXARP74r1ZwIMk02t2Z2jaD1mw/>. >>>> >>>> https://web.archive.org/web/20260702015346/https://nsa.2026.action.cr.yp.to/ >>>> >>>> By a rough count, the list got 27 WGLC positions from senders that never >>>> before participated and who did not use an In-Reply-To header (suggesting >>>> they were not subscribed): 3 in favor and 24 opposing publication. The >>>> rest are approximately 54 in favor and 11 opposing publication. >>>> >>>>> There is no way to know for sure, but the last three emails to the list >>>>> are indeed negative opinions with subject line "[TLS] Re: WG Last Call: >>>>> draft-ietf-tls-mlkem-08 (Ends 2026-07-08)" but no In-Reply-To header >>>>> (which is slightly annoying to produce when one was not a participant in >>>>> the list previously). >>>>> >>>>> I don't believe this is breaking any rules, but I do believe that the >>>>> interpretation that consensus is a voting process is incorrect and in bad >>>>> faith, and instead the degree to which individuals have participated in >>>>> the WG in the past should be part of how their opinion is weighted into >>>>> calling the consensus of the WG. (Note that this is different from >>>>> restricting membership.) >>>>> >>>>> This is the only way the IETF can remain functional, by the way (to the >>>>> extent it is functional for cryptography work, which is... limited). Not >>>>> to put too fine a point on it, but I am confident I can get 0.1% of my >>>>> followers on various platforms to email the list, if every opinion under >>>>> a real name weights the same. >>>>> >>>>> Bernstein also refers to WG members as "NSA's minions" in his call to >>>>> action. I don't know if this has been repeated or linked to on list >>>>> because I have a filter sending his emails to trash, but if it has I ask >>>>> the chairs to please take moderation action, as discussed previously in >>>>> https://mailarchive.ietf.org/arch/msg/tls/v2OS0KLqwG8nohJwB34mV2_ktQQ/. >>>>> >>>>> (It is particularly frustrating that the work I should be doing instead >>>>> of writing this is implementing post-quantum signing in Sunlight for >>>>> Merkle Tree Certificates. I am convinced Bernstein has been by far the >>>>> most successful actor in slowing down the post-quantum transition, >>>>> intentionally or not.) >>>>> >>>>> 2026-06-24 17:00 GMT+02:00 Joseph Salowey via Datatracker >>>>> <[email protected] <mailto:[email protected]>>: >>>>>> This message initiates a new Working Group Last Call for >>>>>> draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key >>>>>> establishment for TLS 1.3. The main question before the working group >>>>>> is: "Should the working group publish a document specifying stand alone >>>>>> ML-KEM?". If there is rough consensus then we will push to refine and >>>>>> publish the document; otherwise, we will stop discussing the draft and >>>>>> not progress it. Please respond to this call indicating whether you >>>>>> support publishing a document specifying a stand alone ML-KEM. Please >>>>>> refrain from further discussion on this topic as most arguments have >>>>>> been discussed multiple times. >>>>>> >>>>>> Why are we holding this consensus call now? >>>>>> >>>>>> Significant developments have occurred both within this document and in >>>>>> the broader TLS ecosystem to address the concerns raised in the last >>>>>> WGLC. Therefore, the third consensus call is warranted. We ask the >>>>>> working group to consider document publication in light of these recent >>>>>> changes: >>>>>> >>>>>> - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a >>>>>> separate consensus call, the WG agreed to promote the X25519MLKEM768 >>>>>> hybrid group to Recommended: Y in the IANA registry. Consequently, the >>>>>> IANA registry will reflect a clear community preference for a hybrid >>>>>> because Recommended: Y clearly indicates this while the standalone >>>>>> ML-KEM groups defined in this draft remain Recommended: N. The updated >>>>>> security considerations in [1] reference the IANA registry to emphasize >>>>>> this preference. >>>>>> >>>>>> - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG >>>>>> recently reached consensus to explicitly prohibit key share reuse across >>>>>> connections in TLS 1.3. The new text changes the guidance from SHOULD >>>>>> NOT to a strict MUST NOT. This resolves the concerns regarding static >>>>>> key reuse and its associated privacy and forward-secrecy risks for >>>>>> ML-KEM. >>>>>> >>>>>> - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and hybrid >>>>>> KEM groups in TLS 1.3. This supports other results which show that KEMs >>>>>> are secure when used in TLS 1.3 and that hybrid groups are secure even >>>>>> if one of the components is compromised. >>>>>> >>>>>> - Liaisons: We received liaison statements from multiple SDOs including >>>>>> O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing support for the >>>>>> publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF >>>>>> to provide a stable normative reference. >>>>>> >>>>>> Please note that a third-party IPR disclosure exists [5] against this >>>>>> document regarding patents related to the underlying ML-KEM algorithm. >>>>>> This IPR declaration has not changed since the last WGLC. As a reminder, >>>>>> per BCP 79, the IETF takes no stance on the validity of patent claims, >>>>>> and the working group may decide to proceed with a technology despite >>>>>> IPR disclosures if it decides that such use is warranted. >>>>>> >>>>>> Conduct Reminder: Given the heated nature of previous discussions on >>>>>> this topic, participants are strongly reminded to adhere to the IETF >>>>>> Code of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep >>>>>> feedback professional, technical, and focused on the document's text. >>>>>> >>>>>> This working group last call will end on 2026-07-08. >>>>>> >>>>>> Joe and Sean >>>>>> >>>>>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ >>>>>> [2] https://datatracker.ietf.org/liaison/2198/ >>>>>> [3] https://datatracker.ietf.org/liaison/2151/ >>>>>> [4] https://datatracker.ietf.org/liaison/2148/ >>>>>> [5] >>>>>> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem >>>>>> >>>>>> _______________________________________________ >>>>>> 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] >>> >>> _______________________________________________ >>> 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]
