Paul wrote: > I am very concerned by the consensus-manipulating efforts of the previous > WGLCs that continue into this current WGLC
I’ve already contributed enough to this heated discussion so I’ll keep this brief. Just noting for the record that Paul is a former AD for this very TLS WG that was found to have misrepresented the results of a previous WGLC on this very draft (declared rough consensus when there was none), and who shortly thereafter left his AD position after his false declaration of rough consensus was overturned, which is why we’re having this consensus call. Nadim Kobeissi Symbolic Software • https://symbolic.software > On 3 Jul 2026, at 11:43 PM, Paul Wouters <[email protected]> > wrote: > > On Wed, 24 Jun 2026, Joseph Salowey via Datatracker wrote: > >> 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: > > I support the publication of draft-ietf-tls-mlkem-08. > > There is a clear demand from some communities, including global SDO's. > > The algorithm is well researched and secure (See > https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ ) > > When quantum computers become prevalent, this would become the algorithm > to migrate to, as hybrids will lose its seat belt capability. So it is > healthy to have a clear stable RFC backed code point baked into software > and available, to allow different people to switch to non-hybrid based > on their own personal risk assessment. > > No one is mandated to use pure MLKEM, and the IETF consensus of preferring > hybrids is made clear via the TLS IANA registry. > > Previous discussions saw three groups of people. Those in favour, > strongly against, and those opposed because it didn't clearly state > concerns. I notice this last group has mostly cleared their objections > with the -08 draft version. > > Previous attempts to set policy so all algorithms would not get an RFC > but just a code point failed, so this algorithm now shouldn't be the only > one not getting an RFC number, as that misinterprets IETF consensus. The > arguments for getting an RFC number are the same reasons as applicable > to others who got an RFC and the same reasons for the lack of consensus > for withholding RFCs for all algorithms. That is, whether we like it or > not, vendors use (IETF stream) RFCs (vs drafts or ISE RFCs) to determine > stable code points worthy of implementing. Other SDOs have policies > requiring RFCs for supporting features, some opensource libraries do > not write or compile in support for non-RFC items. > > The people who claim that pure MLKEM does not need an RFC seem to overlap > strongly with those who said the SSH NTRUprime+X25519 hybrid, despite > being massively deployed, still absolutely needed an RFC number. It > seems this argument is not used objectively in IETF discussions, but > more as stand-in argument to get one's own preferences codified. > > The IETF facilitates interoperability via internet standards, and should > not take on the role of the Internet Protocol Police. > > I am very concerned by the consensus-manipulating efforts of the previous > WGLCs that continue into this current WGLC, such as via social media > influencers and via the filing of infinite appeals which have all been > denied after time consuming procedures. > > Paul > > _______________________________________________ > 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]
