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 <[email protected]>
Sent: Tuesday, October 15, 2024 7:36 AM
To: Alicja Kario <[email protected]>; Bas Westerbaan <[email protected]>
Cc: <[email protected]> <[email protected]>; [email protected]
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 <[email protected]<mailto:[email protected]>>
Date: Tuesday, October 15, 2024 at 09:33
To: Bas Westerbaan <[email protected]<mailto:[email protected]>>
Cc: <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>>
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 
> <[email protected]<mailto:[email protected]>> 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 -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to