Respectfully, it is not the IETF's place to worry about implementation
issues beyond reasonable measures in the design itself. See also: "We're
not the protocol police."
If one wants to take the "defense in depth approach" position here, why are
you doing ML-{KEM,DSA} + ECC hybrids rather than, say, Module Lattices +
McEliece + hash-based three-way composites? After all, that maximizes one's
defense-in-depth.
The obvious answer to this line of reasoning is that cryptographic security
is not the ONLY consideration that matters for these discussions.
Performance, bandwidth, and developer ergonomics must all fit into the
decision calculus. (See also: Avi Douglen's Stack Exchange posts on
usability vs security over the years.)
ML-DSA has the best developer ergonomics of any signature algorithm I've
implemented and worked with. Hands down. It uses a hedged construction
(deterministic + synthetic additional randomness) by default. You have to
dig back to Dilithium 1.0 and invent new hypothetical implementation bugs
to find anything to critique, but anyone that uses the Wycheproof test
vectors will catch those mistakes immediately. You don't have to ponder
Exclusive Ownership [1] or SUF-CMA vs EUF-CMA; those are solved problems.
A hybrid/composite ML-DSA + ECC signature has no sensible threat model.
"Defense in depth" as a general practice doesn't justify algorithmic
layering of safety blankets [2] nor introducing complexity and performance
hits. Citing the existence of potential vulnerabilities in implementations
as a reason to block an IETF RFC is overstepping the IETF's scope.
If you're genuinely concerned about implementation bugs (and if you say
that you are, I *am* inclined to believe you), focus your time, money, and
attention on auditing the implementations for the mistakes you're imagining
and contribute new test cases to Wycheproof to catch them in all other
implementations (which will act as a force multiplier).
[1] - https://soatok.blog/2023/04/03/asymmetric-cryptographic-commitments/
[2] -
https://soatok.blog/2026/04/13/hybrid-constructions-the-post-quantum-safety-blanket/
On Sun, Jun 7, 2026 at 7:22 PM Andrew Lee <[email protected]> wrote:
> 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]
