On Tue, Oct 15, 2024 at 1:52 PM Alicja Kario <hka...@redhat.com> wrote:
> Do you plan to add support for secp256r1mlkem768 and secp384r1mlkem1024? > Not at this time. We want clients to guess correctly which PQ kex the server supports, and that's easier if there are fewer deployed. Hopefully clients will adopt https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/ > 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. > Thanks for checking. This was a slight oversight in BoringSSL, which has been fixed last month [1], but we've not rebased our patches yet. To state the obvious: this does not affect security in any way. > Also, it looks to me like the encapsulation key checks are > missing/incorrect, > it accepts a malformed ML-KEM encapsulation key. > We will add the encapsulation key check once we remove Kyber support from our edge. Again, this does not affect security. > (You can find the test script in > https://github.com/tlsfuzzer/tlsfuzzer/pull/963) > Thanks for putting this test suite together. Best, Bas [1] https://boringssl.googlesource.com/boringssl/+/72a60506ded3407454d6ddc1d848c266020c0c82 > > 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
