Dear Paul, You're a former Security Area Director whom the IAB characterized as, and I quote, "did not accurately describe the record."
In this message, you now make accusations against one who literally went head to head with the US government so that we can even be having this discussion about encryption and standardization in the first place, somehow find a way to reference "social media influencers" in a condescending way, and even somehow incorrectly claim an "infinite" number of appeals have been filed. To be clear, all this is taking place on a public mailing list where Dr. Bernstein has been unfairly moderated due to a footnote, and thus cannot respond in a meaningful timeframe. This was unnecessary content in a consensus thread and quite unbecoming of a former holder of the office of Security Area Director. Very SAD indeed! Was the moderator flag for this thread/list turned off? Sincerely, Andrew > On Jul 3, 2026, at 2: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]
