Hello, I have not previously commented on this matter, but I disagree with the points raised here and in the numerous other threads on this topic.
The fact that a document is published as an RFC does not mean that all Internet users, implementers, or operators are expected to deploy it. I think the issue raised by Roger applies to an extraordinarily narrow population. The vast majority of internet users are not aware of the IETF or RFCs and cannot have the misconception that Roger raises. Of those aware of the IETF and the nearly 10,000 RFCs published thereby, I think that most understand that they are not expected or required to abide by each and every one of those RFCs in their day to day operations. Many RFCs and indeed entire working groups focus on niche issues and applications. Does each internet user take RFC 10014, Guidelines for Characterizing the Term "OAM", as an "official standard"? That one is even a Best Current Practice, but I think that the vast majority of internet users will not go out of their way to implement that RFC in their usage of the internet. Similarly, publication of this document is not, by itself, a mandate that the protocol or mechanism specified be universally adopted. That distinction matters here. As I understand the draft, its purpose is to define ML-KEM key establishment options for TLS 1.3 and to register the corresponding TLS Supported Groups code points. That seems valuable even for deployments that ultimately prefer hybrid key exchange. Organizations that choose to support standalone ML-KEM should have a clear and interoperable specification for doing so, and applications which prefer hybrid key exchange should have the option to fall back to post quantum algorithms rather than falling back to algorithms vulnerable to quantum cryptanalysis when hybrids are not available on both sides of a channel. ML-KEM is a mature, tested, and standardized cryptosystem. Due to NIST's adoption of it in FIPS 203, and because this algorithm has been subject to broad scrutiny without any substantial vulnerabilities being detected, this algorithm should be available for those organizations to use via a standardized specification and code point. I think that the record supports treating this as a "recommended" algorithm. Nevertheless, if the community believes that only hybrids may be recommended, this RFC with recommended=N still provides the standardized documentation and codepoint assignment needed to ensure that those choosing to support this algorithm are able to do so in an interoperable way. In that regard, I think that publication of this draft is clearly a net positive. Finally, I noticed many emails have been sent to this list, often creating new threads (implying that they did not correctly reply to the existing conversation), often stating only their desired outcome without any argument in support or opposition to publication. This appears to be a pattern of "astroturfing" - in other words, it appears that some number of email addresses have subscribed to this list solely to assert a "yes" or "no" position on this topic without engaging on the technical merits. It is worth noting that this means that the total or net number of comments in either direction may be biased due to the biases of those who have publicized this discussion, and those of the audiences to whom it has been shared. It is important that the decision makers weigh the overall merits in this case. Regards, Dan Collins On Tue, Jul 7, 2026 at 11:54 PM Chris Miller <chris.miller= [email protected]> wrote: > I agree and therefore, I do not support the publication of this document. > > Chris Miller > Verified Privacy - vp.net > > > On Tue, Jul 7, 2026 at 11:57 AM Roger Grimes <roger= > [email protected]> wrote: > >> I do not support the publication of this document. >> >> >> >> Too many people take every RFC, either officially “recommended” or not, >> as an “official standard”. >> >> >> >> Requiring dual encryption doesn’t add that much overhead and adds a great >> layer of additional protection. >> >> >> >> >> ******************************************************************************************************************************************** >> >> *Roger A. Grimes >> >> * e:[email protected], LinkedIn: >> https://www.linkedin.com/in/rogeragrimes/, Twitter:@rogeragrimes, >> Mastodon: infosec.exchange/@rogeragrimes, [email protected] >> >> *Author or co-author of 16 books and over 1600 articles on cybersecurity >> >> *Amazon Author Page: amazon.com/author/rogeragrimes >> >> *past weekly InfoWorld and CSO columns: >> www.csoonline.com/author/Roger-A.-Grimes >> >> *Any opinions expressed are purely mine own and not of my employers >> >> * >> >> *Blatant book plugs: >> >> *A Data-Driven Computer Security Defense ( >> https://www.amazon.com/Data-Driven-Computer-Defense-Should-Using/dp/B0BR9KS3ZF >> ) >> >> *Latest book: How AI and Quantum Impact Cyber Threats and Defenses ( >> https://www.amazon.com/dp/B0GGB7Y855) >> >> *Ransomware Protection Playbook ( >> https://www.amazon.com/Ransomware-Protection-Playbook-Roger-Grimes/dp/1119849128 >> ) >> >> *Hacking Multifactor Authentication ( >> https://www.amazon.com/Hacking-Multifactor-Authentication-Roger-Grimes/dp/1119650798 >> ) >> >> *My quantum book, Cryptography Apocalypse ( >> https://www.amazon.com/Cryptography-Apocalypse-Preparing-Quantum-Computing/dp/1119618193 >> ) >> >> *Hacking the Hacker, ( >> https://www.amazon.com/Hacking-Hacker-Learn-Experts-Hackers/dp/1119396212/ >> ) >> >> >> ********************************************************************************************************************************************* >> >> >> _______________________________________________ >> 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
