Should we start checking for PQC ?

[mdavids]

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

[bwbroersma]

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.

[mdavids]

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.

[bwbroersma]

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.

Related:

• https://tldr.fail/

[JakubOnderka]

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.

[bwbroersma]

Alpine v3.22.0 (Released May 30, 2025¹) 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):

• Add (static) compression to static files #1797

Footnotes

1. https://alpinelinux.org/downloads/ ↩

[baknu]

Background and status:

1. NCSC-NL lately published updated TLS guidelines: https://www.ncsc.nl/documenten/publicaties/2025/juni/01/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2025-05
2. 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
3. These algorithms are currently still in draft: https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
4. For corresponding IANA values: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
5. 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/
6. Since v3.50 OpenSSL supports these ML-KEM algorithms : https://openssl-library.org/post/2025-04-08-openssl-35-final-release/
7. Currently nassl does not support OpenSSL 3: Support OpenSSL 3 nabla-c0d3/nassl#114

Implementation:

1. "PQC readiness" could be a separate subtest under "HTTPS" (website test) and "STARTTLS and DANE" (mail test).
2. The subtest should not impact score.
3. 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/dane-users@list.sys4.de/thread/ZDR54KQTAHVL35CQERXXB6NVVRR7XM42/)
• ℹ️ Your server does NOT support PQC algo's

[beatquantum]

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