*   …they’d prefer straight ML-KEM/ML-DSA, but if the industry insisted on 
hybrid crypto, they’d go along.
This is my understanding, too:
“Even though hybrid solutions may be allowed or required due to protocol 
standards, product availability, or interoperability requirements, CNSA 2.0 
algorithms will become mandatory to select at the given date, and selecting 
CNSA 1.0 algorithms alone will no longer be approved."

It seems that CNSA may go along with hybrids, while “in transition”, if these 
hybrids combine CNSA-approved algorithms. We are actively working to clarify 
this.

From: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>
Sent: Wednesday, June 5, 2024 9:49 AM
To: John Mattsson <john.matts...@ericsson.com>; Watson Ladd 
<watsonbl...@gmail.com>; Andrei Popov <andrei.po...@microsoft.com>
Cc: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>; tls@ietf.org
Subject: RE: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

On the other hand, I was at a recent conference, and asked an NSA 
representative (William Layton, Cryptographic Solutions Technical Director) 
about “hybrid crypto”, and he responded that the NSA was “ambivalent” (his 
word); that they’d prefer straight ML-KEM/ML-DSA, but if the industry insisted 
on hybrid crypto, they’d go along.

Hence, I don’t believe that CNSA 2.0 is taking quite as hard of a stand as the 
summary states…

From: John Mattsson 
<john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>>
Sent: Wednesday, June 5, 2024 11:52 AM
To: Watson Ladd <watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>>; Andrei 
Popov <andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>>
Cc: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu<mailto:u...@ll.mit.edu>>; 
Scott Fluhrer (sfluhrer) <sfluh...@cisco.com<mailto:sfluh...@cisco.com>>; 
tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

>I really do not understand this argument, given that the DoD has explicitly 
>said they aren't doing that.

I think it is a bit unclear what CNSA 2.0 says:
- They say that CNSA 2.0 compliant browsers need to support ML-KEM-1024 by 2025.
- The also say that “NSA does not approve using pre-standardized or 
non-FIPS-validated CNSA 2.0 algorithms (even in hybrid modes)”.

I don’t see how you can combine fulfill both of these if estimates for when 
FIPS compliant implementations will be ready. My five cents would be that 
P-384+ML-KEM-1024 is CNSA 1.0 compliant until ML-KEM gets FIPS validated and 
then it becomes CNSA 2.0 compliant.

https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
Cheers,
John

From: Watson Ladd <watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>>
Date: Wednesday, 5 June 2024 at 17:39
To: Andrei Popov <andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>>
Cc: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu<mailto:u...@ll.mit.edu>>, 
Scott Fluhrer (sfluhrer) <sfluh...@cisco.com<mailto:sfluh...@cisco.com>>, John 
Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>>, 
tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On Wed, Jun 5, 2024 at 8:38 AM Andrei Popov
<Andrei.Popov=40microsoft....@dmarc.ietf.org<mailto:Andrei.Popov=40microsoft....@dmarc.ietf.org>>
 wrote:
>
> This is my understanding too, and I believe a lot of deployments limited to 
> P384 will want to use a P384-based hybrid, at least “in transition”. The 
> duration of this transition could be years…

I really do not understand this argument, given that the DoD has
explicitly said they aren't doing that.

>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> From: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu<mailto:u...@ll.mit.edu>>
> Sent: Wednesday, June 5, 2024 7:59 AM
> To: Scott Fluhrer (sfluhrer) 
> <sfluhrer=40cisco....@dmarc.ietf.org<mailto:sfluhrer=40cisco....@dmarc.ietf.org>>;
>  John Mattsson 
> <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:john.mattsson=40ericsson....@dmarc.ietf.org>>;
>  tls@ietf.org<mailto:tls@ietf.org>
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
> CNSA 1.0 requires P-384 or RSA-3072, and does not allow P-256.
>
>
>
> CNSA 2.0 requires ML-KEM, and does not approve any of the ECC curves. But 
> there’s a “transition period”, during which P-384 could presumably be used.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> From: Scott Fluhrer (sfluhrer) 
> <sfluhrer=40cisco....@dmarc.ietf.org<mailto:sfluhrer=40cisco....@dmarc.ietf.org>>
> Date: Wednesday, June 5, 2024 at 09:54
> To: John Mattsson 
> <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:john.mattsson=40ericsson....@dmarc.ietf.org>>,
>  tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>>
> Subject: [EXT] [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
> If we’re talking about CNSA, well CNSA 2. 0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft… From: John Mattsson <john. mattsson=40ericsson. com@ 
> dmarc. ietf. org>
>
> ZjQcmQRYFpfptBannerStart
>
> This Message Is From an External Sender
>
> This message came from outside the Laboratory.
>
> ZjQcmQRYFpfptBannerEnd
>
> If we’re talking about CNSA, well CNSA 2.0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft…
>
>
>
> From: John Mattsson 
> <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:john.mattsson=40ericsson....@dmarc.ietf.org>>
> Sent: Wednesday, June 5, 2024 1:56 AM
> To: tls@ietf.org<mailto:tls@ietf.org>
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
> Andrei Popov wrote:
>
> >CNSA requires P384, so we’ll also need a hybrid that includes this EC.
>
>
>
> Yes, I am not sure about the statement that P-256 is required. The 
> requirement for FIPS in the next few years should be one of the NIST 
> P-curves. I think P-384 is the most required of the NIST P-curves.
>
>
>
> Scott Fluhrer wrote:
> >I believe that it is unreasonable to expect that a single combination would 
> >satisfy everyone’s needs.
>
> Yes, that is completely unreasonable. TLS is MUCH larger than the Web. There 
> will clearly be registrations for combinations of most current curves 
> (P-curves, X-curves, Brainpool, SM, GOST) with most PQC KEMs (ML-KEM, 
> BIKE/HQC, Classic McEliece, FrodoKEM, future Isogeny? (Isogenies was the 
> hottest topic at Eurocrypt this year) ). European countries say that hybrids 
> will be a must for a long-time.
>
>
>
> Cheers,
>
> John
>
>
>
> From: Andrei Popov 
> <Andrei.Popov=40microsoft....@dmarc.ietf.org<mailto:Andrei.Popov=40microsoft....@dmarc.ietf.org>>
> Date: Wednesday, 5 June 2024 at 07:24
> To: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>>, Stephen Farrell 
> <stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>>
> Cc: tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>>
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
> CNSA requires P384, so we’ll also need a hybrid that includes this EC.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> From: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>>
> Sent: Monday, June 3, 2024 12:53 PM
> To: Stephen Farrell 
> <stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>>
> Cc: Loganaden Velvindron <logana...@gmail.com<mailto:logana...@gmail.com>>; 
> Andrei Popov <andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>>; 
> Salz, Rich <rs...@akamai.com<mailto:rs...@akamai.com>>; 
> tls@ietf.org<mailto:tls@ietf.org>
> Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
>
>
>
>
>
>
> On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell 
> <stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>> wrote:
>
>
> I'm afraid I have no measurements to offer, but...
>
> On 03/06/2024 19:05, Eric Rescorla wrote:
> > The question is rather what the minimum set of algorithms we need is. My
> >   point is that that has to include P-256. It may well be the case that
> > it needs to also include X25519.
>
> Yep, the entirely obvious answer here is we'll end up defining at least
> x25519+PQ and p256+PQ. Arguing for one but not the other (in the TLS
> WG) seems pretty pointless to me. (That said, the measurements offered
> are as always interesting, so the discussion is less pointless than
> the argument:-)
>
>
>
> Yes, this seems correct to me.
>
>
>
> -Ekr
>
>
>
>
>
>
>
>
> Cheers,
> S.
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>



--
Astra mortemque praestare gradatim
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Reply via email to