Internet.nl Should we start checking for PQC ?

Maybe don't assign a score to it yet - but already start checking?

Possibly relevant:

https://www.ncsc.nl/documenten/publicaties/2022/juli/guidelines-for-quantum-safe-transport-layer-encryption/guidelines-for-quantum-safe-transport-layer-encryption

Jan 28 '25 17:01 mdavids

Version 1.0, May 2022. This information is not legally binding. It is to be updated yearly.

👀 How should I read this?

Seems to be only one (one-off?) publication in English and no Dutch version, it's linked from the Dutch news article "NCSC publiceert beveiligingsrichtlijnen voor kwantumveilige transportlaag encryptie" by NCSC-NL, 2022-07-06T12:06.

Jan 28 '25 22:01 bwbroersma

Since we follow NCSC guidelines for testing I was hoping they had something on PQC, but it's not much. Meanwhile, PQC-algo's are being deployed (like for instance on Cloudflare) and it is a 'hot' topic. That is why I wanted to bring it up anyway.

Jan 31 '25 10:01 mdavids

These are all still draft RFC's right? E.g. draft-kwiatkowski-tls-ecdhe-mlkem.

Maybe some PQC will land in the TLS guidelines, if so, this can be checked.

https://tldr.fail/

Jan 31 '25 15:01 bwbroersma

This will be nice to support as it can promote PQC.

BoringSSL supports X22519MLKEM768 for longer time and yesterday released OpenSSL 3.5 also added suport for this algo and it is enabled by default.

Apr 09 '25 15:04 JakubOnderka

Alpine v3.22.0 (Released May 30, 2025^1) contains openssl v3.5.0-r0. The latest alpine nginx docker container still uses Alpine v3.21, if this is updated openssl 3.5 and should be able to add the configuration:

ssl_ecdh_curve X25519MLKEM768;

However it could also be included in a custom build nginx (module) step (e.g. like this but with less modules):

#1797

Jun 11 '25 17:06 bwbroersma

Background and status:

NCSC-NL lately published updated TLS guidelines: https://www.ncsc.nl/documenten/publicaties/2025/juni/01/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2025-05
These guidelines also cover PQC. The following hybrid algorithms are considered quantum-safe and are the only algorithms that qualifiy as "GOOD": X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024
These algorithms are currently still in draft: https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
For corresponding IANA values: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
Note that PQC algo's most probably will only be supported in TLS 1.3 and NOT n TLS 1.2: https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/
Since v3.50 OpenSSL supports these ML-KEM algorithms : https://openssl-library.org/post/2025-04-08-openssl-35-final-release/
Currently nassl does not support OpenSSL 3: https://github.com/nabla-c0d3/nassl/issues/114

Implementation:

"PQC readiness" could be a separate subtest under "HTTPS" (website test) and "STARTTLS and DANE" (mail test).
The subtest should not impact score.
The subtest could probably have the following three possible verdicts:

✔️ Your server supports PQC algo's
⚠️ Your server does NOT support PQC algo's and incorrectly rejects any connection from clients that support PQC (https://tldr.fail/ and for mail servers see https://list.sys4.de/hyperkitty/list/[email protected]/thread/ZDR54KQTAHVL35CQERXXB6NVVRR7XM42/)
ℹ️ Your server does NOT support PQC algo's

Jun 26 '25 16:06 baknu

Maybe don't assign a score to it yet - but already start checking?

Possibly relevant:

https://www.ncsc.nl/documenten/publicaties/2022/juli/guidelines-for-quantum-safe-transport-layer-encryption/guidelines-for-quantum-safe-transport-layer-encryption

Yes, we should start checking. Question - Which openssl version are you using at the back-end? I will be happy to share what I am using myself. -Santosh

Oct 07 '25 10:10 beatquantum