Dear members of the TLS working group, many and most of whom I consider my seniors and superiors in this field,
> On Jun 7, 2026, at 3:08 AM, Deb Cooley <[email protected]> wrote: > > Andrew, > > With my AD hat on: > > This is an explicit warning that making accusations about people's > motivations is not acceptable on the TLS mailing list (see RFC 7154 section > 2). > > Deb Cooley > Sec AD > I want to acknowledge the AD's reminder in reference to RFC 7154 section 2. My earlier message was driven by deep concern due to the events that took place, but I should have been more selective with my language therewith. I appreciate the warning to help me put myself in check. I'd also like to address my previous message. After sending my response for clarification yesterday, I've been thiking more about what RECOMMENDED=N actually means in reality, and I want to correct something I said earlier about whether or not the IETF's processes are working as intended. I was treating the RECOMMENDED=Y for hybrids and RECOMMENDED=N for solo ML-KEM as a win. If you're one of the likely < 100 people actively reading these threads, it could feel that way; and I was not an exception. After taking a step back and thinking about how development and security decisions really work, I do not believe this is enough. CSO/CISOs and developers building TLS implementations generally don't parse recommendation flags. They see an RFC number, see that it was published through the IETF, and treat that as endorsement. The nuance between RECOMMENDED=Y and RECOMMENDED=N is just a line in a document that, for even those who read said document, will be glossed over. I'm not a cryptographer. I like to consider myself, however, an applied cryptographer. I consume the primitives that researchers far greater (and smarter) than me discover and standardize. I integrate libs, make implementation decisions, and yes, in some cases I've had to roll my own based on those primitives (not often). Nearly a decade ago when I implemented a TLS HTTPS proxy with SNI, or an IRC bouncer, I opened the relevant RFCs and absolutely did not read the majority of the text. I went straight to the protocol syntax and implementation details. I didn't scrutinize recommendation flags or comb through security considerations looking for caveats, because that's what RFCs (request for comments) are for: the questions and comments have been answered so I can focus on getting the implementation right. There are many others like me, and there are far more developers who don't even know what the term "hybrid" means in this context. When the IETF makes decisions, it can't optimize only for the PhD researchers who will carefully parse every flag and footnote. It has to account for the applied cryptographers, the integration engineers, and the developers who will see an RFC and treat it as a green light... because that's exactly what we do. Sadly, the only reason I'm even aware of this issue is because I'm a member on this list, already "deep" in the space, and already have the highest of respect for researchers like Dr. Kobeissi, Dr. Bernstein, and others, who thankfully raised the alarm. If I weren't already here, I would have had no idea. That's the case for 99.99% of the people whose security depends on the decisions made on this list. They will never read this thread or see RECOMMENDED=N. They will simply see an RFC exists, and they will implement it. Looking toward an even darker future, TLS is considered to be a reference standard. When teams building other custom protocols, messaging systems, or custom encryption see that TLS published an RFC for solo PQ key exchange, they will take that as validation that solo PQ is an acceptable approach. This sets a bad precedent where every protocol designer who looks to TLS for guidance will conclude that if TLS did it, it must be fine. I don't have to tell you all that key exchange is the most significant part of contemporary cryptographic privacy. If you can't exchange the key securely, everything that follows is completely meaningless theater. Further, people are using Claude/ChatGPT as their oracle; I went ahead and asked it if it was okay to use solo PQ if there is a published RFC. This is what it said: "The existence of the RFC signals that the community considers standalone ML-KEM a legitimate option, not a reckless one." [Claude] It didn't go deep enough to check or ask if RECOMMENDED=N. It treated the RFC's existence as the endorsement. I said earlier that the process needs a refactor. I still believe that, but I was too quick to treat the current outcome as sufficient. Treating RECOMMENDED=N as enough is like saying adopted doesn't mean adopted... oh wait. Sincerely, Andrew _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
