I think we’re still missing a code point for secp384r1mlkem1024:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-mlkem-02.html#name-iana-considerations

Cheers,

Andrei

From: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>
Sent: Tuesday, October 15, 2024 7:36 AM
To: Alicja Kario <hka...@redhat.com>; Bas Westerbaan <b...@cloudflare.com>
Cc: <tls@ietf.org> <tls@ietf.org>; p...@ietf.org
Subject: [EXTERNAL] [TLS] Re: [EXT] [Pqc] Re: Planned changes to Cloudflare's 
post-quantum deployment

I second the request to add support for secp384r1mlkem1024, as that’s the only 
hybrid KEX that makes sense for us.

Thank you!
--
V/R,
Uri

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                
                                                        C. A. R. Hoare

I was a shepherd to fools
Causelessly bold or afraid.
They would not abide by my rules.
Yet they escaped. For I stayed.
                                    R. Kipling “Epitaphs of the War. Convoy 
Escort”


From: Alicja Kario <hka...@redhat.com<mailto:hka...@redhat.com>>
Date: Tuesday, October 15, 2024 at 09:33
To: Bas Westerbaan <b...@cloudflare.com<mailto:b...@cloudflare.com>>
Cc: <tls@ietf.org<mailto:tls@ietf.org>>, p...@ietf.org<mailto:p...@ietf.org> 
<p...@ietf.org<mailto:p...@ietf.org>>
Subject: [EXT] [Pqc] Re: Planned changes to Cloudflare's post-quantum deployment
!-------------------------------------------------------------------|
  This Message Is From an External Sender
  This message came from outside the Laboratory.
|-------------------------------------------------------------------!

On Tuesday, 15 October 2024 14:49:06 CEST, Bas Westerbaan wrote:
> On Tue, Oct 15, 2024 at 1:52 PM Alicja Kario 
> <hka...@redhat.com<mailto: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/

sure, but I'm thinking about clients that won't be able to use
x25519mlkem768 at all until they have a FIPS certified implementation of
ML-KEM...

--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com<http://www.cz.redhat.com/>
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

--
Pqc mailing list -- p...@ietf.org<mailto:p...@ietf.org>
To unsubscribe send an email to pqc-le...@ietf.org<mailto:pqc-le...@ietf.org>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Reply via email to