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

[[e-mail]]

To achieve maximum compatibility, ZT Browser’s algorithm priority order is Pure PQC algorithm like MLKEM/MLDSA first, then hybrid PQC like X25519MLKEM or SM2MLKEM, third is traditional algorithm like ECC P256, X25519, SM2, RSA.

 

Best Regards



Richard Wang

 

From: Eric Rescorla <[e-mail]> 
Sent: Thursday, November 27, 2025 8:17 AM
To: Muhammad Usama Sardar <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

 

 

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] <mailto:[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] <mailto:[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