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]
