Fix IANA recommended supported groups, only use PQC X25519MLKEM768

[bwbroersma]

sed -ri "s/^(ssl_ecdh_curve\s+)[a-zA-Z0-9:]+/\1$(curl -sSf "https://www.iana.org/assignments/tls-parameters/tls-parameters-8.csv"|awk -F, '$4=="Y"{print$2}'|tac|tr '\n' :|head -c-1)/" docker/webserver/nginx_templates/tls.conf.template

Earlier IANA had zero recommended PQC ciphers, so we added all 3 ciphers from the draft Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3. See the earlier PR:

• Fix IANA recommended plus hybrid NCSC-NL-TLS-2025-05 compliant curves #1962

This however changed in the latest draft (tls-ecdhe-mlkem-05) which was published 2026-05-26, the non-diff link to the latest version is here: the section § 7 - IANA Considerations (tls-ecdhe-mlkem-05).

This removes the non-recommended supported groups:

• SecP256r1MLKEM768
• SecP384r1MLKEM1024

The proposed new configuration is almost equal to that of https://configurator.tlsref.org (https://github.com/mozilla/ssl-config-generator was archived at 2026-05-28 and points to the new organization https://github.com/tlsref), the only difference is x448, which I created an issue for:

• x448 is recommended by RFC 8447 tlsref/configurator#11

[Christian-NCSC-NL]

I read a little bit into this (for as far as I could) and I am not sure if we should remove SecP256r1MLKEM768 and SecP384r1MLKEM1024. From what I could read on the TLS mailinglist the main reason that X25519MLKEM768 is moved to recommended is because it is the most adopted PQC algoritm so far not because the other ones aren't "good" for any reason. SecP256r1MLKEM768 and SecP384r1MLKEM1024 are actually stronger than X25519MLKEM768 in terms of security. If I remember correctly: Browsers also support this (EDIT: Browsers only support X25519MLKEM768 it seems, see also: https://mailarchive.ietf.org/arch/msg/tls/eKWxJUTNKHLtg1uKKglDQ6aseSw/). I think the main reason that X25519MLKEM768 was picked as recommended is performance reasons and it being "good enough" (hopefully I can dive a bit deeper in this still).

(X25519MLKEM768 is ook niet FIPS compliant terwijl de andere twee dat wel zijn)

EDIT: Zie ook deze comment uit de IESG evaluatie van de draft (2026-06-12)

The main controversy was about which hybrid groups to mark as Recommended Y in
the IANA registry.  Consensus could not be reached on this point so all groups
defined in the document remain as Recommended N.  The general consensus of the
working group was to move forward with document publication as is.  Updating
the registry can be done in a future document if the working group can reach
consensus."

https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ballot/

Zie ook deze: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/writeup/

   There is significant implementation of the groups in this document.  In
   particular X25519MLKEM is widely support by browsers including chrome and
   firefox and by CDNs such as cloud flare.  Vendors such as RedHat and AWS also
   support the other groups in this document. Many TLS libraries already support
   or have announced plans to support one or more groups define in this doucment.

   This document has received review from the IETF cryptographic community
   involved in TLS and Post-Quantum Crypto algorithms.

[bwbroersma]

@Christian-NCSC-NL thanks for looking into this, I did not do that, and just wanted to make the script rules less custom. Especially interesting since apparently when x448 was made recommended, the same logic was not applied, but TLS ref did applied the logic, see related discussion:

• x448 is recommended by RFC 8447 tlsref/configurator#11

[Christian-NCSC-NL]

@bwbroersma This one might also be interesting:

https://mailarchive.ietf.org/arch/msg/tls/eKWxJUTNKHLtg1uKKglDQ6aseSw/

>> This is the breakdown of client support Cloudflare sees (relative to any PQ
>> support) in the last 24 hours by handshakes:
>> 
>> 94% X25519MLKEM768
>> 8.1% X25519Kyber768
>> 0.038% MLKEM768
>> 0.014% CECPQ2
>> 0.012% MLKEM1024
>> 0.002% SecP384MLKEM1024
>> 0.002% SecP256MLKEM768
>> 0.00005% MLKEM512
>> 0.0000003% SecP256Kyber768

Since browsers only seem to support x25519MLKEM768, almost all traffic is using that PQ algorithm for key exchange.