[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[Muhammad Usama Sardar <[e-mail]>]

On 26.11.25 22:35, Eric Rescorla wrote:

> On Wed, Nov 26, 2025 at 1:17 PM Muhammad Usama Sardar 
> <[e-mail]> wrote:
>
>     I think the draft should have a statement somewhere stating that
>     it is no longer compliant with the base TLS specs, with pointer to
>     section 9.1 of RFC 8446bis.
>
> I don't think that's correct.

Yeah, sorry, as mentioned in the thread, please take my comments with a 
large grain of salt, since I haven't yet worked with PQ. I am most 
likely missing something from implementation perspective, from PQ 
perspective, from terminology perspective or interpretation of terms. So 
please feel free to ignore.

My general feedback for this draft was that since it is the first draft 
on pure PQ that we have, I would have expected it to give a much better 
introduction and motivation than a couple of sentences that basically 
tell me nothing about why this draft even exists. For example, "users 
that want ..." is too generic of a motivation that would apply to almost 
any draft of the IETF. Specifically, I would like to know more about 
those users to be able to reach out to them to ask whether they also 
want attestation. If motivation comes from compliance, I would like to 
read those regulations to understand whether these regulations also 
require attestation. And if the answer to any of those is yes, then 
check out whether these users have any preference about intra-handshake 
attestation vs. post-handshake attestation, etc.

> An implementation could choose to implement just the new algorithm and
> not the MTI algorithm(s) in the same class, in which case the 
> implementation
> would be noncompliant, but it's possible to be noncompliant based purely
> on the algorithms registered in RFC 8446, for instance by implementing
> just P-384 and not P-256.

Sure, but I feel like there is a difference. In this case, the 
implementers /choose/ not to implement P-256 while still having the 
possibility, whereas in pure PQ, implementers have /no possibility/ to 
support P-256. Isn't it?

That is, I don't understand how pure PQ can support P-256. So my point 
was that implementations which have pure PQ cannot be "TLS-compliant 
applications", as per section 9.1 of 8446bis.

-Usama