Hi John, Noting that this characterization of my paper’s strong vs. weak contributions is completely fair and accurate.
Nadim Kobeissi Symbolic Software • https://symbolic.software > On 6 Jun 2026, at 12:44 PM, John Mattsson <[email protected]> wrote: > > Hi, > > I had some more time to read the Kobeissi paper (“FATT Chance”) and wanted to > share a few thoughts on its strengths and limitations. > > I think the paper’s genuinely strong contributions are, in the symbolic > (Dolev–Yao) model: > > 1. KEM-based key exchange in TLS 1.3 is secure. > 2. Hybrid key exchange following draft-ietf-tls-hybrid-design remains secure > unless both components are broken simultaneously. > 3. A compromise of the key exchange also compromises handshake > authentication, not just confidentiality. > 4. Key share reuse breaks forward secrecy. > > Unfortunately, some of the other findings seem to be attracting most of the > attention on the mailing list. > > 5. The observation that standalone key exchange is a single point of failure > does not require formal analysis; it is straightforward. > > 6. The claim that X25519MLKEM768 is robust is made under a classical > Dolev–Yao attacker model. The relevant threat model to analyze > quantum-resistant TLS is a quantum Dolev–Yao attacker. In that setting, ECDHE > is broken by assumption, and the hybrid “both must fail” guarantee reduces to > “ML-KEM must hold”, which is identical to the standalone assumption. > > I would support TLS specifications citing the paper for contributions 1–4, > but not for points 5–6 in its current form. > > X25519MLKEM768 is already the de facto standard. In addition to making it > RECOMMENDED=Y, I think it should be MTI. I also think that all > quantum-vulnerable algorithms should asap be RECOMMENDED=N and, in the > not-too-distant future, RECOMMENDED=D. > > I think the WG should discuss what the long-term (>2035) solution is: whether > X25519MLKEM768 is the long-term solution, whether it should be optimized by > moving to standalone ML-KEM-768, or whether the TLS WG wants robustness in > the relevant quantum threat model, which could be achieved with ML-KEM-768 + > HQC-KEM-192. > > Cheers, > John Preuß Mattsson > > From: Nadim Kobeissi <[email protected]> > Date: Saturday, 6 June 2026 at 10:44 > To: Deirdre Connolly <[email protected]> > Cc: Salz, Rich <[email protected]>; Andrew Lee > <[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 > > Deirdre, could you please add a statement to draft-ietf-tls-mlkem referencing > that hybrids are preferred, ideally citing my analysis once it hits ePrint? I > know that we have the RECOMMENDED=Y/N column, but I believe that adding this > statement to the draft could enrich it with context that reflects our current > understanding and provides valuable context to future readers. This is > especially the case since Table 2, for example, in my analysis provides a > granular and pedagogical overview of exactly how formal analysis has shown > differences between pure DH, pure ML-KEM, and hybrid constructions. > > Thanks, > > Nadim Kobeissi > Symbolic Software • https://symbolic.software > > On 5 Jun 2026, at 8:51 PM, Deirdre Connolly <[email protected]> wrote: > > Correct, all versions of draft-ietf-tls-mlkem including before adoption have > had Recommended=N for all parameter sets > > On Fri, Jun 5, 2026, 3:34 PM Salz, Rich <[email protected] > <mailto:[email protected]>> wrote: > This happened after a significant amount of time and was deliberately steered > toward the opposite of said result > > My recollection and view is the exact opposite. ML-KEM key exchange was > never going to be RECOMMENDED=Y. The system worked. The “outside > interference” just made it more complicated and caused a great deal of bad > blood and distrust. > > > _______________________________________________ > TLS mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]> > _______________________________________________ > 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]
