Do you plan to add support for secp256r1mlkem768 and secp384r1mlkem1024?
Running the tlsfuzzer script against pq.cloudflareresearch.com I see
that it doesn't handle the errors correctly: it sends decode_error
instead of illegal_parameter for malformed client key shares.
Also, it looks to me like the encapsulation key checks are
missing/incorrect,
it accepts a malformed ML-KEM encapsulation key.
(You can find the test script in
https://github.com/tlsfuzzer/tlsfuzzer/pull/963)
On Tuesday, 15 October 2024 10:44:52 CEST, Bas Westerbaan wrote:
As of today, we support X25519MLKEM768 (0x11ec) on essentially
all websites served through Cloudflare.
Best,
Bas
On Fri, Sep 6, 2024 at 1:02 PM Bas Westerbaan <b...@cloudflare.com> wrote:
Hi all,
We are planning to replace X25519Kyber768Draft00 (0x6399)
with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-KEM-768 and
X25519.
We will support X25519Kyber768Draft00 and X25519MLKEM768 at the
same time for a while to allow clients the opportunity to
migrate without losing post-quantum security.
Apart from these two, we also supported X25519Kyber768Draft00
under codepoint 0xfe31 and X25519Kyber512Draft00 (0xfe30). We
logged zero uses of these two in the last week with a 1/100
sample rate. We will disable 0xfe31, 0xfe30 over the common
weeks.
Best,
Bas
PS. Not sure I shared it here already, but we have public graph
tracking client PQ key agreement
deployment: https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption
At the time of writing about 17% of all human traffic (by
request count) with us is using X25519Kyber768Draft00.
[1] https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
