Feedback-ID: i2e91459c:Fastmail
MIME-Version: 1.0
Date: Sun, 28 Jun 2026 11:08:32 +0200
From: "Filippo Valsorda" <filippo@ml.filippo.io>
To: "joe@salowey.net" <joe@salowey.net>, draft-ietf-tls-mlkem@ietf.org,
 tls-chairs@ietf.org, tls@ietf.org
Message-Id: <cf7aa1c4-efa1-40de-b5b6-5d6adc11ca63@app.fastmail.com>
In-Reply-To: 
 <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
References: 
 <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
Content-Type: multipart/alternative;
 boundary=281d8a0744e70d0816e90e1f05ab4bb01ae52452
Message-ID-Hash: 6SYAXE7VG66VU236V63GJJZHCERT3LGV
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_WG_Last_Call=3A_draft-ietf-tls-mlkem-08_=28Ends_20?=
	=?utf-8?q?26-07-08=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/ZBpcicZX1Dxnam2gMaa4-UPtmHk>

--281d8a0744e70d0816e90e1f05ab4bb01ae52452
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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/

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 <noreply@ietf.org>:
> 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 -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
> 

--281d8a0744e70d0816e90e1f05ab4bb01ae52452
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>I want the W=
G and the chairs to be aware that Bernstein is now coordinating a campai=
gn to get dissenting opinions emailed to the list.</div><div><br></div><=
div>&gt;&nbsp;<span class=3D"color" style=3D"color:rgb(0, 0, 0);">You ca=
n have your voice heard too. All you have to do is&nbsp;</span><a href=3D=
"https://mailman3.ietf.org/mailman3/lists/tls.ietf.org/">join the IETF T=
LS mailing list</a><span class=3D"color" style=3D"color:rgb(0, 0, 0);">&=
nbsp;(under your real name, please!) and send a message to the mailing l=
ist&nbsp;</span><a href=3D"https://web.archive.org/web/20260625052729/ht=
tps://mailarchive.ietf.org/arch/msg/tls/ol2otAvtdDrdz_xY0_eKcuY1om0/">by=
 7 July 2026</a><span class=3D"color" style=3D"color:rgb(0, 0, 0);">&nbs=
p;under the subject line "Re: [TLS] WG Last Call: draft-ietf-tls-mlkem-0=
8 (Ends 2026-07-08)" saying that you do not support the publication of t=
his document.</span></div><div><br></div><div><a href=3D"https://web.arc=
hive.org/web/20260627234614/https://nsa.2026.action.cr.yp.to/">https://w=
eb.archive.org/web/20260627234614/https://nsa.2026.action.cr.yp.to/</a><=
br></div><div><br></div><div>There is no way to know for sure, but the l=
ast three emails to the list are indeed negative opinions with subject l=
ine "[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)" =
but no&nbsp;In-Reply-To header (which is slightly annoying to produce wh=
en one was not a participant in the list previously).<br></div><div><br>=
</div><div>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 parti=
cipated in the WG in the past should be part of how their opinion is wei=
ghted into calling the consensus of the WG. (Note that this is different=
 from restricting membership.)<br></div><div><br></div><div>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.</div><div><br></div><div><span class=3D"color" style=3D=
"color:rgb(0, 0, 0);">Bernstein also refers to WG members as "NSA's mini=
ons" in his call to action. I don't know if this has been repeated or li=
nked to on list because I have a filter sending his emails to trash, but=
 if it has I ask the chairs to <i>please</i> take moderation action, as =
discussed previously in&nbsp;</span><a href=3D"https://mailarchive.ietf.=
org/arch/msg/tls/v2OS0KLqwG8nohJwB34mV2_ktQQ/">https://mailarchive.ietf.=
org/arch/msg/tls/v2OS0KLqwG8nohJwB34mV2_ktQQ/</a>.</div><div><br></div><=
div>(It is particularly frustrating that the work I should be doing inst=
ead of writing this is&nbsp;<i>implementing post-quantum signing in Sunl=
ight for Merkle Tree Certificates</i>.&nbsp;I am convinced Bernstein has=
 been by far the most successful actor in slowing down the post-quantum =
transition, intentionally or not.)</div><div><br></div><div>2026-06-24 1=
7:00 GMT+02:00 Joseph Salowey via Datatracker &lt;<a href=3D"mailto:nore=
ply@ietf.org">noreply@ietf.org</a>&gt;:</div><blockquote type=3D"cite" i=
d=3D"qt" style=3D""><div>This message initiates a new Working Group Last=
 Call for draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key e=
stablishment 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 publi=
sh the document; otherwise, we will stop discussing the draft and not pr=
ogress it. Please respond to this call indicating whether you support pu=
blishing a document specifying a stand alone ML-KEM. Please refrain from=
 further discussion on this topic as most arguments have been discussed =
multiple times.</div><div><br></div><div>Why are we holding this consens=
us call now?</div><div><br></div><div>Significant developments have occu=
rred both within this document and in the broader TLS ecosystem to addre=
ss the concerns raised in the last WGLC. Therefore, the third consensus =
call is warranted. We ask the working group to consider document publica=
tion in light of these recent changes:</div><div><br></div><div>- Promot=
ion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a separate conse=
nsus call, the WG agreed to promote the X25519MLKEM768 hybrid group to R=
ecommended: 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 t=
his draft remain Recommended: N. The updated security considerations in =
[1] reference the IANA registry to emphasize this preference.</div><div>=
<br></div><div>- Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis=
: The WG recently reached consensus to explicitly prohibit key share reu=
se 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 s=
tatic key reuse and its associated privacy and forward-secrecy risks for=
 ML-KEM.</div><div><br></div><div>- 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 t=
hat hybrid groups are secure even if one of the components is compromise=
d.</div><div><br></div><div>- Liaisons: We received liaison statements f=
rom multiple SDOs including&nbsp; O-RAN[2], IEEE 802.11[4] and from 3GPP=
[3]&nbsp; expressing support for the publication of draft-ietf-tls-mlkem=
 as an RFC as they rely on the IETF to provide a stable normative refere=
nce.</div><div><br></div><div>Please note that a third-party IPR disclos=
ure exists [5] against this document regarding patents related to the un=
derlying ML-KEM algorithm. This IPR declaration has not changed since th=
e 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 w=
ith a technology despite IPR disclosures if it decides that such use is =
warranted.</div><div><br></div><div>Conduct Reminder: Given the heated n=
ature of previous discussions on this topic, participants are strongly r=
eminded 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.</div><div><br></div><div>This working group las=
t call will end on 2026-07-08.</div><div><br></div><div>Joe and Sean</di=
v><div><br></div><div>[1]&nbsp;<a href=3D"https://datatracker.ietf.org/d=
oc/draft-ietf-tls-mlkem/">https://datatracker.ietf.org/doc/draft-ietf-tl=
s-mlkem/</a></div><div>[2]&nbsp;<a href=3D"https://datatracker.ietf.org/=
liaison/2198/">https://datatracker.ietf.org/liaison/2198/</a></div><div>=
[3]&nbsp;<a href=3D"https://datatracker.ietf.org/liaison/2151/">https://=
datatracker.ietf.org/liaison/2151/</a></div><div>[4]&nbsp;<a href=3D"htt=
ps://datatracker.ietf.org/liaison/2148/">https://datatracker.ietf.org/li=
aison/2148/</a></div><div>[5]&nbsp;<a href=3D"https://datatracker.ietf.o=
rg/ipr/search/?submit=3Ddraft&amp;id=3Ddraft-ietf-tls-mlkem">https://dat=
atracker.ietf.org/ipr/search/?submit=3Ddraft&amp;id=3Ddraft-ietf-tls-mlk=
em</a></div><div><br></div><div>________________________________________=
_______</div><div>TLS mailing list --&nbsp;<a href=3D"mailto:tls@ietf.or=
g">tls@ietf.org</a></div><div>To unsubscribe send an email to&nbsp;<a hr=
ef=3D"mailto:tls-leave@ietf.org">tls-leave@ietf.org</a></div><div><br></=
div></blockquote><div><br></div></body></html>
--281d8a0744e70d0816e90e1f05ab4bb01ae52452--