[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-07 (Ends 2026-02-27)

[Eric Rescorla <[e-mail]>]

On Mon, Feb 23, 2026 at 7:10 AM Muhammad Usama Sardar <
[e-mail]> wrote:

> On 23.02.26 13:34, Eric Rescorla wrote:
>
> On Mon, Feb 23, 2026 at 12:20 AM Muhammad Usama Sardar <
> [e-mail]> 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