Hi Filippo, I am one of the people who decided to join after seeing Dan's post about it.
I was a researcher in the EU project PQCRYPTO. I have been doing research in crypto since 1998 (my first paper appeared at SAC 1999, on a cipher called SKIPJACK). I was a member of ISO/IEC JTC1 SC27 WG2 and WG3 for some years (up until recently), and was involved in multiple discussions about large scale designs and deployments, e.g., the Israeli COVID certificates. (and this is just a concise version of my credentials, I guess some supporters of the proposal also know me and can attest to some of my credentials and experience). The way I see this is as follows: There is a discussion about issuing an informational RFC (and you may saw my previous message suggesting that outside IETF, many people don't care if it is informational or not) about MLKEM-only standardization (after a such a support was "allowed" in TLS). There are several reasons for this which I deem valid: * There are a few implementations of the feature which may not be consistent with each other. * Simpler and easier to maintain code base/operational procedures with MLKEM over MLKEM+ECDH. At the same time, there is a noteworthy security downgrade - the new proposal offers less algorithmic security, and increases the chances of a black-swan events. I'm putting aside the discussion on the number of years between RSA being introduced and being an RFC, or the way attack vectors have developed between 1982 and 2026, the hardness of implementation (which is very subjective), and/or the importance of constant time implementations. We have a decent codebase for ECDH, we will eventually have a decent codebase for MLKEM (decent does not mean - perfect, it means not much worse than a mature code as we have now). I am also putting aside many of the other aspects that were discussed on this mailing list on the topic. Most notably, I am putting aside regulators claiming that they want it. I support regulations, and I think that regulation in general is a good idea, but I am not sure the IETF (or ISO, or any international organization for that matter) should decide to (informationally) standardize something because the regulator of the banking industry in Wakanda decided to demand something [and yes, I know that the world is unfair, and if it is China or US or Russia it is quite different than if Trindad and Tobago would have asked this]. So from my perspective the discussion is between increasing security through interoperability and simplicity vs. reducing security through increased chance for a catastrophe. Now, I think that the view which supports the publication is a legitimate one, but I personally find the opposition to be more convincing - so if it is not clear so far - I oppose the publication of this informational RFC. However, this is an email on why I've joined the mailing list following Dan's social media activities. After reading his webpages, I've looked at the process here, consulted with some colleagues here whether the summary of Dan is accurate enough (putting aside his personal observations and thoughts on the matter, independent of whether I agree with them or not), and decided that it seems like there is a sufficiently good reason for me to actually "dive in" and vote. 1. It seems to be acceptable in the rules of the game - so ok from my point of view. 2. It seems to have been done BEFORE by the people who support the proposal - without that in the previous rounds, I would not need to write this email, 3. If you want to amend the IETF rules to avoid that in the future (to something more wikipedia-like - must be involved in X discussions before you can vote), fine by me, but if you are at it, I would suggest to add some good-faith clauses preventing people who get paid (or got paid in the last 5 years) by organizations whose task is to undermine standards cannot participate in voting. Cheers, Orr [BTW, if I hadn't answered/posted using the correct mechanism - my apologies, we were forcibly migrated to some service cloud provider by my university, and I can no longer use my beloved (al)pine mailer to send emails where I can actually see all the headers] On Thu, Jul 2, 2026 at 12:05 PM Filippo Valsorda <[email protected]> wrote: > 2026-06-28 11:08 GMT+02:00 Filippo Valsorda <[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://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://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]>: > > 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] > 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]
