Regardless whether the algos are secure or not [1], implementation issues happen all the time, especially in the earlier days of development in seemingly benign ways like with the rust ML DSA signature malleability bug.
In a hybrid approach; even a simple one with authentication occurring with verification against both ML-DSA44 and Ed25519 separately but requiring both, even if someone exploited a ML-DSA bug, they would have failed the Ed25519 verification. There simply isn’t an argument as of June 7, 2026 that negates hybrids. [1] Participants on the list are literally the people I look up to when determining whether it’s safe to consider something secure. That said, proper security posture dictates a defense in depth approach; assume everything will fail and minimize exposure blast radius per each failure. On Sun, Jun 7, 2026 at 3:23 PM Soatok Dreamseeker <[email protected]> wrote: > 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]
