This "dark future" concern only exists if you believe ML-KEM or ML-DSA are insecure. In which case, you shouldn't be hybridizing them either, but refraining from using them at all.
On Sun, Jun 7, 2026 at 1:44 PM Andrew Lee <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
