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? > > 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. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
