> 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]
