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]
