Add X25519MLKEM768.json to feature-json

[jannispinter]

@olokelo has already opened PR #7083 roughly a year ago for the pre-standard post-quantum key agreement scheme X25519Kyber768. Meanwhile, the standards landscape has changed, and the pre-standard draft X25519Kyber768 has been deprecated by most browsers. It was replaced by the standardized key agreement mechanism X25519MLKEM768 and gained support in major browsers quickly at the end of 2024. ML-KEM is the NIST standardized variant of Kyber.

This PR considers only the standardized X25519MLKEM768 as supported. I initially started out with flagging X25519Kyber768 as partially supported, but ultimately decided to remove it as it is incompatible with X25519MLKEM768 and uses a different codepoint.

This PR supersedes #7083 and solves #7072.

Data verification and testing
I carefully put together the data from official release notes and verified part of the data with my own tests. Test can be performed by visiting a test site, such as PQC Ninja's browser test (my own tool) or Cloudflare's test site.

Chrome

• Chrome initially experimented with pre-standard X25519Kyber768 from Chrome 115 onwards, where it was disabled by default. It was then accessible with the flag #enable-tls13-kyber in Chrome 116 and above (source).
• With Chrome 124, the flag #enable-tls13-kyber was enabled by default (source)
• Chrome then replaced X25519Kyber768 with X25519MLKEM768 in Chrome 130 (disabled by default) and enabled it by default in Chrome 131 (source)

Edge

• Just like Chrome, Microsoft enabled X25519Kyber768 in Edge 124 by default.
• Edge then replaced X25519Kyber768 with X25519MLKEM768 in Edge 131 and enabled it by default (source)

Safari

• As of today, Safari on iOS (18.5) and macOS does not support X25519MLKEM768 or X25519Kyber768 (tested and verified). I expect this to change with the release of iOS 26

Firefox

• Mozilla added support for pre-standard X25519Kyber768 in Firefox 124
• Mozilla then replaced X25519Kyber768 with X25519MLKEM768 in Firefox 132 (source), but did not ship support for it with QUIC/HTTP3, which came in Firefox 135 (source)

Firefox for Android

• As of today, Firefox for Android does not support X25519MLKEM768 or X25519Kyber768 (tested and verified). However, support for X25519MLKEM768 was enabled for nightly builds recently (source).

Samsung Internet for Android

• As of today, the current version (28) of Samsung Internet does not support X25519MLKEM768 or X25519Kyber768 (tested and verified)

Opera on Android
As Opera 89 is based on Chromium 132, it brings support for X25519MLKEM768 (tested and verified). This version is not yet listed with Caniuse, but just for completeness listed here

Other browsers listed by Caniuse

• IE 10/11 (released in 2013): Can safely set to unsupported, as the browser is too old
• Opera Mini (released in 2015): Can safely set to unsupported, as the browser is too old
• UC Browser for Android: Needs testing, currently unknown
• Android Browser: Needs testing, currently unknown (my device uses a different web view implementation)
• QQ Browser: Needs testing, currently unknown
• KaiOS Browser (released in 2021): Can safely set to unsupported, as the browser is too old

Note on SecP256r1MLKEM768 and SecP384r1MLKEM1024
As @jschauma pointed out in his comment, there are other hybrid post-quantum key agreement schemes available and standardized alongside with X25519MLKEM768. These should be tracked in a separate feature and are not part of this PR.

As far as I can tell from my quick research and testing, none of the major browsers seem to support SecP256r1MLKEM768 or SecP384r1MLKEM1024 today, and it is likely that those will not play a significant role in the near future either, as (all?) browsers use X25519MLKEM768 in their key share prediction. Usage of SecP256r1MLKEM768 or SecP384r1MLKEM1024 would therefore result in a slightly slower TLS handshake and - if I understood how things work in TLS correctly - an additional round trip.

[jschauma]

I think you want to point the spec at https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/. (The link you have is expired at this point; pointing to datatracker should get you to the up to date version going forward.)

[jannispinter]

Thank you, I've just updated the PR with the new spec link

[jschauma]

Perhaps add "hybrid" or "hybrid key agreement"?

[jannispinter]

Thank you, I've just updated the PR and added "hybrid key agreement" in the tag list

[kwinz]

I was surprised when I Google searched for "can i use X25519MLKEM768" and https://caniuse.com/ didn't show up because we aren't tracking this feature yet.

What is still missing so we can merge this pull?

Should we update with iOS 26 support which was released on September 15, 2025? https://support.apple.com/en-me/122756

[kwinz]

Related overview: https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-support/

[jannispinter]

Should we update with iOS 26 support which was released on September 15, 2025? https://support.apple.com/en-me/122756

Hi @kwinz, thank you for your comments. I have updated the PR with regards to iOS 26 and also updated the information for all other browsers and platforms.