> For the record (and the inevitable blog post), I support publication provided that the draft has had at least some review by the FATT.
What other triage would be needed beyond what you have already cited? On Sat, Feb 21, 2026, 1:41 PM Peter C <[email protected]> wrote: > OFFICIAL > > Nadim Kobeissi writes: > > This document introduces pure ML-KEM as a NamedGroup, substituting the > > ML-KEM shared_secret into the TLS 1.3 key schedule in place of the > > (EC)DHE shared secret (Section 4.3, Figure 1). That substitution > > directly affects a component of the TLS 1.3 key schedule that has been > > formally modeled and analyzed, including in: > > > > - Bhargavan, Blanchet, Kobeissi, "Verified Models and Reference > > Implementations for the TLS 1.3 Standard Candidate," IEEE S&P 2017, DOI > > 10.1109/SP.2017.26. > > > > - Dowling, Fischlin, Gunther, Stebila, "A Cryptographic Analysis of > > the TLS 1.3 Handshake Protocol," Journal of Cryptology, 2021, DOI > > 10.1007/s00145-021-09384-1 (cited in the draft as [DOWLING]). > > The same is true of draft-ietf-tls-hybrid-design: it also substitutes a > KEM shared secret into the TLS 1.3 key schedule in place of the > (EC)DHE shared secret. > > As already pointed out by Thom, the proof by Dowling et al applies > essentially unchanged with an IND-1CCA KEM since this equivalent > to the snPRF-ODF assumption for ECDH. If you don't trust Thom's > thesis, then look at section 5 of: > > - L. Huguenin-Dumittan, S. Vaudenay, "On IND-qCCA Security in > the ROM and Its Applications: CPA Security Is Sufficient for TLS 1.3", > EUROCRYPT 2022, DOI 10.1007/978-3-031-07082-2_22. > > > The prior analyses modeled the (EC)DHE input as a freshly generated > > ephemeral value. My own 2017 work explicitly modeled TLS 1.3 client key > > shares as ephemeral. As Muhammad Usama Sardar noted on this list on > > February 20, and as John Mattsson confirmed, this draft introduces a > > materially different assumption: Section 5.3 of -07 explicitly permits > > ML-KEM key share reuse. > > draft-ietf-tls-hybrid-design includes the same assumption. Section 2 of > that draft states: > > While it is recommended that implementations avoid reuse of > KEM public keys, implementations that do reuse KEM public keys > MUST ensure that the number of reuses of a KEM public key > abides by any bounds in the specification of the KEM or subsequent > security analyses. > > > From direct knowledge of the 2017 proof, I can confirm that its > > security arguments do not straightforwardly extend to a static key share > > case. The proof relies on the ephemerality of client key shares at a > > structural level. Substituting a potentially reused ML-KEM encapsulation > > key for a fresh ephemeral (EC)DHE value changes the adversarial model > > the proof operates under. > > Again quoting from the same paragraph of draft-ietf-tls-hybrid-design: > > TLS 1.3 does not require that ephemeral public keys be used only > in a single key exchange session; some implementations may reuse > them, at the cost of limited forward secrecy. > > If the analysis does not extend to the case where key shares are reused > then this would also seem to be a problem for TLS 1.3 with ECDH. > > > Under the FATT charter, the chairs were expected to determine whether > > FATT review was warranted at adoption time. I have been unable to find a > > public record that FATT was engaged for this document: there is no FATT > > point person named in the FATT repository, and no FATT assessment > > appears in the shepherd write-up (which shows no shepherd assigned). > > > > I would appreciate it if the chairs could clarify on the record whether > > FATT triage was initiated and, if so, what the outcome was. This is a > > straightforward process question, and answering it would help the > > working group understand whether this document has received the formal > > analysis review that our own processes call for. > > Clarification is always useful, but I don't see how the outcome for this > draft > can be any different from the outcome for draft-ietf-tls-hybrid design > which > has already passed WGLC. > > For the record (and the inevitable blog post), I support publication > provided > that the draft has had at least some review by the FATT. > > Peter > > OFFICIAL > > _______________________________________________ > 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]
