Hi Andrew, Andrew Lee <[email protected]> wrote: >Further, standard setting should take into consideration the state of our >current reality as opposed to a future goal not yet reached. Secondly, >layering three schemes doesn't provide any benefit; in this case, ML-DSA is >young with strong potential, whereas Ed25519 etc. are mature and battle >tested. There's a purpose for layering these two since, luckily in this case, >you do get the best of both worlds. It's the same reason you wouldn't launch >and start using Daemon N+1 into a live userbase on day 1: the live userbase >isn't the beta test network.
Note that this thread is about standalone and hybrid ML-KEM, not ML-DSA. EdDSA is not widely deployed in TLS; in fact, I don't think I have ever encountered a TLS deployment that uses it. >layering three schemes doesn't provide any benefit >There's a purpose for layering these two since, luckily in this case, you do >get the best of both worlds This seems contradictory. With well-designed composite KEMs, you can indeed obtain the best of both worlds, i.e., security corresponding to Max(PQ, T). However, the "T" component of PQ/T should soon no longer be considered to provide meaningful security, particularly for key exchange. In that case, the effective security becomes Max(PQ, 0), which is simply PQ. In practice, the situation can be even worse. Implementation bugs in hybrid signature schemes are surprisingly common and can result in systems that deliver the worst of both worlds rather than the best, i.e., Min(PQ, T). Furthermore, some of the composite signature constructions under discussion do not, even in theory, achieve the security of the stronger component. Instead, their security fall below that of either constituent scheme, i.e., < Min(PQ, T). Cheers, John Preuß Mattsson From: Andrew Lee <[email protected]> Date: Monday, 8 June 2026 at 05:48 To: Peter Gutmann <[email protected]> Cc: Soatok Dreamseeker <[email protected]>; [email protected] <[email protected]> Subject: [TLS] Re: FATT Chance: On the Robustness of Standalone and Hybrid ML-KEM Key Exchange in TLS 1.3 On Sun, Jun 7, 2026 at 8:32 PM Peter Gutmann <[email protected]<mailto:[email protected]>> wrote: Hybrids are useful if you've got people clamoring for PQC but don't want to take the risk of committing to something that we have almost no deployment experience with compared to the 30-50 years of practical experience with conventional PKC algorithms. Exactly this. Further, standard setting should take into consideration the state of our current reality as opposed to a future goal not yet reached. Secondly, layering three schemes doesn't provide any benefit; in this case, ML-DSA is young with strong potential, whereas Ed25519 etc. are mature and battle tested. There's a purpose for layering these two since, luckily in this case, you do get the best of both worlds. It's the same reason you wouldn't launch and start using Daemon N+1 into a live userbase on day 1: the live userbase isn't the beta test network. The rust ML-DSA crate's '<' vs '<=' bug was committed initially as a fix, this year. Unfortunately, it led to signature malleability. Luckily, again, this was only an implementation flaw but said flaw undiscovered would make it unusable for verification/authentication. Even if an implementation flaw exists, Ed25519 keeps things from crashing out so to speak. In terms of audits, I agree it's not the IETF's mandate to police wild code, but standard setting, again, should take into consideration the state of implementations out there and their hardening, or lack thereof.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
