On 23.02.26 22:00, Eric Rescorla wrote:
On Mon, Feb 23, 2026 at 7:10 AM Muhammad Usama Sardar <[email protected]> wrote:On 23.02.26 13:34, Eric Rescorla wrote:On Mon, Feb 23, 2026 at 12:20 AM Muhammad Usama Sardar <[email protected]> wrote: Since this draft clearly seems to be controversial, I am still failing to see why chairs are not asking for expert review of FATT to resolve the matter. So, I once again request the chairs to initiate FATT process. Maybe chairs can collect all related analysis and send these pointers along with the request. It's not clear to me what you're hoping to learn from the FATT analysis. Is there some question about the properties of the combination of ML-KEM with TLS assuming that ML-KEM is in fact IND-CCA secure? I understand the question to be about the security of ML-KEM proper, which the FATT process is not designed to assess.I may be misunderstanding what you are saying here but as I have mentioned several references of my existing and ongoing works in my previous email, it breaks all of them. As Nadim has confirmed, it breaks his proofs too. Presumably then those proofs are also broken for echdhe-mlkem, under the assumption that ECDHE is broken, no?
Thanks, I /think/ I now understand better.[ Caution: The following is /intuition/ only; not formally checked; and with a reminder that I am new to this encapsulation decapsulation thingy ]
ECDHE is broken means ECDHE shared secret is leaked, right? If so, you are right because the proofs are based solely on ECDHE. But note that under the assumption that ECDHE shared secret is leaked, the original proofs for non-PQ are broken too. So I see no difference.
Different way to look at it is: for ECDHE-MLKEM, for showing that my existing proofs are preserved, I may not necessarily need to do additional /computational/ (cryptographic vs. /symbolic/) proofs for ML-KEM because the ECDHE in key schedule is replaced by ECDHE secret concatenated with ML-KEM secret [0,1]. So some ECDHE bytes (e.g., 32 or 48) are still there. The relevant property here is also different, namely the adversary has to compromise /both/ ECDHE and ML-KEM secrets to be successful.
On the other hand, for pure ML-KEM, where ECDHE in key schedule is completely replaced by ML-KEM secret, I would have appreciated FATT's confirmation on whether they consider the existing works on ML-KEM as sufficient. Absent that confirmation, I would either need to do /computational/ proofs for ML-KEM or thoroughly check someone else's /computational/ proof. Both are extensive works of the order of several months of effort for me (for others, it may be different, depending on their background of computational proofs) for no strong motivation being demonstrated until now.
Does it sound more reasonable now? Does that answer your original question?
The question of key reuse seems orthogonal, as key reuse in this draft is allowed to essentially the same extent as it is allowed with traditional ECC algorithms. Again, what is it you're expecting formal review to tell us?For "essentially the same extent": That's not my reading. RFC8446bis [1] seems to be using normative SHOULD NOT, whereas this draft [2] seems to be changing that to simply a non-normative recommendation "[...] recommended that implementations avoid reuse [...]". Did I miss something?Yes. This text does not override the text form 8446bis, which is still in force.
[ Apologies, my phrasing particularly "changing" was a bit confusing. ]Sure, I was asking for clarification on "essentially the same extent" and sharing my understanding of why I believe they are not "essentially the same extent". Does my statement in previous email make more sense now? Am I (still) missing something?
Thanks. -Usama[0] https://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-04.html#section-4.3
[1] https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-13.html#section-3.3
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
