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 <[email protected]> Sent: Thursday, November 27, 2025 8:17 AM To: Muhammad Usama Sardar <[email protected]> Cc: [email protected]; [email protected]; [email protected] 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 <[email protected] <mailto:[email protected]> > wrote: On 26.11.25 22:35, Eric Rescorla wrote: On Wed, Nov 26, 2025 at 1:17 PM Muhammad Usama Sardar <[email protected] <mailto:[email protected]> > 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
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
