On Monday, 6 January 2025 11:35:57 CET, John Mattsson wrote:
I also have a hard time too see why it is needed.
MLKEM1024 is the CNSA 2.0 approved key exchange
https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html
secp384r1 is the CNSA 1.0 approved key exchange
https://www.rfc-editor.org/rfc/rfc9151.html
If SecP3841MLKEM1024 is CNSA 1.0 compliant (treating MLKEM102
like a non-security part), then X25519MLKEM768 is CNSA 2.0
compliant (treating X25519 like a non-security part).
X25519MLKEM768 is NOT CNSA 2.0 compliant, CNSA 2.0, as you pointed out,
requires ML-KEM-1024.
The justification for both SecP3841MLKEM1024 and SecP256r1MLKEM768 is the
same:
compliance in situation where you have certification for the ECDH part but
don't have one yet for the PQC part. It's just the one targets CNSA 1.0 (or
more broadly Common Criteria Protection Profile) and the second one "just"
FIPS compliance.
From: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org>
Date: Monday, 6 January 2025 at 11:18
To: Kris Kwiatkowski <k...@amongbytes.com>
Cc: tls@ietf.org <tls@ietf.org>
Subject: [TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448
Didn't CNSA 2 only allow hybrids if there is no alternative?
There is a codepoint for MLKEM1024 in TLS now.
On Mon, Jan 6, 2025 at 9:57 AM Kris Kwiatkowski <k...@amongbytes.com> wrote:
Sure, but for the record the same applies to SecP3841MLKEM1024
I think the main motivation for ECDH/P-384 is CNSA compliance,
so I don't think it is "the same applies". Yes,
it is slower than x25519 or ECDH/p256.
--
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
