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

[Eric Rescorla <[e-mail]>]

I think it's important to separate a number of points here.

First, the requirement is not that implementations *use* P-256 but
rather that they implement it. For example, until recently, browsers
typically supported both P-256 and X25519, but most Web connections
negotiated X25519. This is totally RFC 8446 compliant. What wouldn't
be compliant is if you supported *just* X25519. Browsers now generally
support P-256, X25519, and MLKEM+X25519 (as well as potentially some
other groups). This is also compliant. For the same reason if if you
have an implementation which supports P-256, X25519, MLKEM+X25519, and
pure MLKEM, that's also compliant, because it still supports P-256.

What's *not* compliant is if you have an implementation which doesn't
support P-256, no matter what other groups it supports.  This includes
both non-P-256 EC groups such as X25519, pure PQ groups like MLKEM, or
even hybrid groups like MLKEM+P-256. I recognize that that last
example may be counterintuitive, but it's important to remember that
the point of the MTI is to ensure that there is an interoperable
algorithm, and an implementation which supports only P-256 can't
interoperate with an implementation which supports only MLKEM+P-256.

-Ekr



On Wed, Nov 26, 2025 at 3:50 PM Muhammad Usama Sardar <
[e-mail]> wrote:

> 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
>