>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.
That is my understanding as well, but they seem to take a hard stand on non-FIPS-validated algorithms. My understanding is that a non-FIPS-validated standalone ML-KEM-1024 would not be CNSA 1.0 and not CNSA 2.0 compliant. A FIPS-validated P-384 + non-FIPS-validated ML-KEM-1024 would to my understanding be CNSA 1.0 compliant. My feeling is that a FIPS-validated P-384 + non-FIPS-validated ML-KEM-1024 would be preferred over continuing with standalone P-384 for several years, but I think only NSA can answer this. Cheers, John From: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> Date: Wednesday, 5 June 2024 at 18:50 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 <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> Sent: Wednesday, June 5, 2024 11:52 AM To: Watson Ladd <watsonbl...@gmail.com>; Andrei Popov <andrei.po...@microsoft.com> Cc: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>; Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>; 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
