[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 Date: Wednesday, 5 June 2024 at 17:39 To: Andrei Popov Cc: Blumenthal, Uri - 0553 - MITLL , Scott Fluhrer (sfluhrer) , John Mattsson , tls@ietf.org Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? On Wed, Jun 5, 2024 at 8:38 AM Andrei Popov 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 > Sent: Wednesday, June 5, 2024 7:59 AM > To: Scott Fluhrer (sfluhrer) ; John > Mattsson ; 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) > Date: Wednesday, June 5, 2024 at 09:54 > To: John Mattsson , 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 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 > Sent: Wednesday, June 5, 2024 1:56 AM > To: 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 > Date: Wednesday, 5 June 2024 at 07:24 > To: Eric Rescorla , Stephen Farrell > Cc: 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 > Sent: Monday, June 3, 2024 12:53 PM > To: Stephen Farrell > Cc: Loganaden Velvindron ; Andrei Popov > ; Salz, Rich ; tls@ietf.org > Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? > > > > > > > > > > On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell > 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
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
Since I was quoted, I should say that my words may have made more sense in context, and if not I apologize. To be clear, we do not anticipate supporting hybrid in NSS due to the increased development time and validation burden. In those cases where it is necessary due to protocol constraints, such as IKEv2 key establishment, we are not opposed to such systems. -Bill ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
> In other words, will another curve be allowed once it's added to NIST SP > 800-56A? For a (large) subset of the services, I believe this would allow Azure to enable X25519. There would still remain services and environments where P384 is required (e.g., anywhere CNSA applies). This is a significant chunk for Azure, but perhaps less of an issue for some other operators. > Maybe faster: would the short-term problem be addressed if we can convince > NIST to announce that it will consider X25519 and X448 for a revision of SP > 800-56A, and doesn't intend to enforce conformance of cryptographic modules > with SP 800-56A until the revisions are done? This is a complicated compliance question. I'm not qualified to comment on this option. > Or are you saying that, independently of NIST's decisions, the services in > question are for some reason specifically requiring what's typically called > the "NIST curves", namely the fifteen NSA curves that NIST standardized? No, not saying this. There may be customers who prefer NIST curves, but I have no data showing that this is common. Cheers, Andrei -Original Message- From: D. J. Bernstein Sent: Wednesday, June 5, 2024 1:01 PM To: tls@ietf.org Subject: [EXTERNAL] [TLS]Re: Curve-popularity data? Andrei Popov writes: > I support this change, willing to implement it in the Windows TLS > stack. We have thousands of customers concerned about increased > latencies due to the enablement of TLS 1.3. The services they connect > to require NIST curves and HRR is required to get TLS clients to send > appropriate key shares. To clarify, when you say "require NIST curves", do you mean "require conformance with NIST SP 800-56A"? In other words, will another curve be allowed once it's added to NIST SP 800-56A? Maybe faster: would the short-term problem be addressed if we can convince NIST to announce that it will consider X25519 and X448 for a revision of SP 800-56A, and doesn't intend to enforce conformance of cryptographic modules with SP 800-56A until the revisions are done? Or are you saying that, independently of NIST's decisions, the services in question are for some reason specifically requiring what's typically called the "NIST curves", namely the fifteen NSA curves that NIST standardized? Or the subset of those that NIST hasn't deprecated yet? Thanks in advance for the clarification. ---D. J. Bernstein ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[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. 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) Date: Wednesday, 5 June 2024 at 18:50 To: John Mattsson , Watson Ladd , Andrei Popov Cc: Blumenthal, Uri - 0553 - MITLL , 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 Sent: Wednesday, June 5, 2024 11:52 AM To: Watson Ladd ; Andrei Popov Cc: Blumenthal, Uri - 0553 - MITLL ; Scott Fluhrer (sfluhrer) ; 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 mailto:watsonbl...@gmail.com>> Date: Wednesday, 5 June 2024 at 17:39 To: Andrei Popov mailto:andrei.po...@microsoft.com>> Cc: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>, Scott Fluhrer (sfluhrer) mailto:sfluh...@cisco.com>>, John Mattsson mailto:john.matts...@ericsson.com>>, tls@ietf.org<mailto: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 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 mailto:u...@ll.mit.edu>> > Sent: Wednesday, June 5, 2024 7:59 AM > To: Scott Fluhrer (sfluhrer) > mailto:sfluhrer=40cisco....@dmarc.ietf.org>>; > John Mattsson > 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) > mailto:sfluhrer=40cisco@dmarc.ietf.org>> > Date: Wednesday, June 5, 2024 at 09:54 > To: John Mattsson > mailto:john.mattsson=40ericsson@dmarc.ietf.org>>, > tls@ietf.org<mailto: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 dmarc. ietf. org> > > ZjQcmQRYFpfptBannerStart > > This Message Is
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
* …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) Sent: Wednesday, June 5, 2024 9:49 AM To: John Mattsson ; Watson Ladd ; Andrei Popov Cc: Blumenthal, Uri - 0553 - MITLL ; 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 mailto:john.matts...@ericsson.com>> Sent: Wednesday, June 5, 2024 11:52 AM To: Watson Ladd mailto:watsonbl...@gmail.com>>; Andrei Popov mailto:andrei.po...@microsoft.com>> Cc: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>; Scott Fluhrer (sfluhrer) 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 mailto:watsonbl...@gmail.com>> Date: Wednesday, 5 June 2024 at 17:39 To: Andrei Popov mailto:andrei.po...@microsoft.com>> Cc: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>, Scott Fluhrer (sfluhrer) mailto:sfluh...@cisco.com>>, John Mattsson mailto:john.matts...@ericsson.com>>, tls@ietf.org<mailto: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 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 mailto:u...@ll.mit.edu>> > Sent: Wednesday, June 5, 2024 7:59 AM > To: Scott Fluhrer (sfluhrer) > mailto:sfluhrer=40cisco....@dmarc.ietf.org>>; > John Mattsson > 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) > mailto:sfluhrer=40cisco@dmarc.ietf.org>> > Date: Wednesday, June 5, 2024 at 09:54 > To: John Mattsson > mailto:john.mattsson=40ericsson@dmarc.ietf.org>>, > tls@ietf.org<mailto: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 dmarc. ietf. org> > > ZjQcmQRYFpfptBannerStart > > This Message Is From an External Sender > > This message came from outside the Laboratory. > > ZjQcmQ
[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 Sent: Wednesday, June 5, 2024 11:52 AM To: Watson Ladd ; Andrei Popov Cc: Blumenthal, Uri - 0553 - MITLL ; Scott Fluhrer (sfluhrer) ; 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 mailto:watsonbl...@gmail.com>> Date: Wednesday, 5 June 2024 at 17:39 To: Andrei Popov mailto:andrei.po...@microsoft.com>> Cc: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>, Scott Fluhrer (sfluhrer) mailto:sfluh...@cisco.com>>, John Mattsson mailto:john.matts...@ericsson.com>>, tls@ietf.org<mailto: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 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 mailto:u...@ll.mit.edu>> > Sent: Wednesday, June 5, 2024 7:59 AM > To: Scott Fluhrer (sfluhrer) > mailto:sfluhrer=40cisco@dmarc.ietf.org>>; > John Mattsson > 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) > mailto:sfluhrer=40cisco....@dmarc.ietf.org>> > Date: Wednesday, June 5, 2024 at 09:54 > To: John Mattsson > mailto:john.mattsson=40ericsson@dmarc.ietf.org>>, > tls@ietf.org<mailto: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 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 > 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 unreasona
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
* I think we are closer to going in the other direction and allow TLS1.3 spec-compliant implementations aiming at post-quantum support to drop support for P-256 entirely. I don’t know whether there are any IETF rules about this, but changing MTI algorithms does not sound appropriate in a -bis document. Cheers, Andrei From: Bas Westerbaan Sent: Wednesday, June 5, 2024 7:22 AM To: Dennis Jackson Cc: tls@ietf.org Subject: [EXTERNAL] [TLS]Re: Curve-popularity data? One more thing: we are finalizing RFC 8446-bis right now, so if there is WG consensus to require that clients offer all MTI curves in the key_shares of their initial CH, then that would be a straightforward text change. I think we are closer to going in the other direction and allow TLS1.3 spec-compliant implementations aiming at post-quantum support to drop support for P-256 entirely. Agreed. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On Wed, Jun 5, 2024 at 8:38 AM Andrei Popov 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 > Sent: Wednesday, June 5, 2024 7:59 AM > To: Scott Fluhrer (sfluhrer) ; John > Mattsson ; 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) > Date: Wednesday, June 5, 2024 at 09:54 > To: John Mattsson , 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 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 > Sent: Wednesday, June 5, 2024 1:56 AM > To: 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 > Date: Wednesday, 5 June 2024 at 07:24 > To: Eric Rescorla , Stephen Farrell > Cc: 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 > Sent: Monday, June 3, 2024 12:53 PM > To: Stephen Farrell > Cc: Loganaden Velvindron ; Andrei Popov > ; Salz, Rich ; tls@ietf.org > Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? > > > > > > > > > > On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell > 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 > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
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… Cheers, Andrei From: Blumenthal, Uri - 0553 - MITLL Sent: Wednesday, June 5, 2024 7:59 AM To: Scott Fluhrer (sfluhrer) ; John Mattsson ; 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) mailto:sfluhrer=40cisco@dmarc.ietf.org>> Date: Wednesday, June 5, 2024 at 09:54 To: John Mattsson mailto:john.mattsson=40ericsson@dmarc.ietf.org>>, tls@ietf.org<mailto: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 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 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 mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>> Date: Wednesday, 5 June 2024 at 07:24 To: Eric Rescorla mailto:e...@rtfm.com>>, Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>> Cc: tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? CNSA<https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF> requires P384, so we’ll also need a hybrid that includes this EC. Cheers, Andrei From: Eric Rescorla mailto:e...@rtfm.com>> Sent: Monday, June 3, 2024 12:53 PM To: Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>> Cc: Loganaden Velvindron mailto:logana...@gmail.com>>; Andrei Popov mailto:andrei.po...@microsoft.com>>; Salz, Rich 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 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 To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
> if, when using a hybrid KEM, we're heading to a world where one large set of > clients emit x25519 and x25519+pq and another large set emit p256 and p384+pq? We are already in the world where a large set of servers will HRR to get the client to send a 25519 key share, while another large set of servers will HRR to get the client to send a NIST curve key share. TLS 1.3 with HRR is somewhat higher-latency than the TLS 1.2 2-RTT handshake, so enabling TLS 1.3 can increase connection latency for some deployments. With traditional groups, clients have an option of offering both 25519 and NIST key shares. With PQC/hybrids, this will likely become impractical, this is why I believe TLS key share prediction (https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-00.html) becomes more important. Cheers, Andrei -Original Message- From: Stephen Farrell Sent: Wednesday, June 5, 2024 12:20 AM To: John Mattsson ; tls@ietf.org Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? On 05/06/2024 06:56, John Mattsson wrote: > I think P-384 is the most required of the NIST P-curves. I've heard that some. Oddly, I use a test server that only supports p384 as a way to trigger HRR when testing ECH, which seems to work for most clients who test with my servers, so I wonder if, when using a hybrid KEM, we're heading to a world where one large set of clients emit x25519 and x25519+pq and another large set emit p256 and p384+pq? I guess if that meant there wasn't a real need for much use of p256+pq that might be a small saving and worth documenting somewhere even if we do define a codepoint for p256+pq. Cheers, S. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[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) Date: Wednesday, June 5, 2024 at 09:54 To: John Mattsson , 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 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 Sent: Wednesday, June 5, 2024 1:56 AM To: 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 mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>> Date: Wednesday, 5 June 2024 at 07:24 To: Eric Rescorla mailto:e...@rtfm.com>>, Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>> Cc: tls@ietf.org <mailto:tls@ietf.org> mailto:tls@ietf.org>> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? CNSA <https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF> requires P384, so we’ll also need a hybrid that includes this EC. Cheers, Andrei From: Eric Rescorla mailto:e...@rtfm.com>> Sent: Monday, June 3, 2024 12:53 PM To: Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>> Cc: Loganaden Velvindron mailto:logana...@gmail.com>>; Andrei Popov mailto:andrei.po...@microsoft.com>>; Salz, Rich 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 > 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. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[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 Sent: Wednesday, June 5, 2024 1:56 AM To: 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 mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>> Date: Wednesday, 5 June 2024 at 07:24 To: Eric Rescorla mailto:e...@rtfm.com>>, Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>> Cc: tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? CNSA<https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF> requires P384, so we’ll also need a hybrid that includes this EC. Cheers, Andrei From: Eric Rescorla mailto:e...@rtfm.com>> Sent: Monday, June 3, 2024 12:53 PM To: Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>> Cc: Loganaden Velvindron mailto:logana...@gmail.com>>; Andrei Popov mailto:andrei.po...@microsoft.com>>; Salz, Rich 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 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 To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On 05/06/2024 06:56, John Mattsson wrote: I think P-384 is the most required of the NIST P-curves. I've heard that some. Oddly, I use a test server that only supports p384 as a way to trigger HRR when testing ECH, which seems to work for most clients who test with my servers, so I wonder if, when using a hybrid KEM, we're heading to a world where one large set of clients emit x25519 and x25519+pq and another large set emit p256 and p384+pq? I guess if that meant there wasn't a real need for much use of p256+pq that might be a small saving and worth documenting somewhere even if we do define a codepoint for p256+pq. Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[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 Date: Wednesday, 5 June 2024 at 07:24 To: Eric Rescorla , Stephen Farrell Cc: tls@ietf.org Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? CNSA<https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF> requires P384, so we’ll also need a hybrid that includes this EC. Cheers, Andrei From: Eric Rescorla Sent: Monday, June 3, 2024 12:53 PM To: Stephen Farrell Cc: Loganaden Velvindron ; Andrei Popov ; Salz, Rich ; tls@ietf.org Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell 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 To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
CNSA<https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF> requires P384, so we’ll also need a hybrid that includes this EC. Cheers, Andrei From: Eric Rescorla Sent: Monday, June 3, 2024 12:53 PM To: Stephen Farrell Cc: Loganaden Velvindron ; Andrei Popov ; Salz, Rich ; tls@ietf.org Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell 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 To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
Bas Westerban wrote >X25519+ML-KEM will be acceptable for FIPS Yes. I don’t see any need for P-256 hybrids. X25519+ML-KEM or just ML-KEM will both be acceptable for FIPS and should be enough for most users. I think it is very important to choose very fast algorithms. More ephemeral key exchange leads to better security and privacy. People wanting to do pervasive monitoring often argue for purely symmetrical key exchange. Cheers, John Preuß Mattsson Sent from Outlook for iOS<https://aka.ms/o0ukef> From: Bas Westerbaan Sent: Monday, June 3, 2024 10:32 PM To: Stephen Farrell Cc: Andrei Popov ; Salz, Rich ; tls@ietf.org Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? X25519+ML-KEM will be acceptable for FIPS, just like P-256+Kyber is today. We just need to wait for the final standard, and (crucially) for the verified modules with ML-KEM. On Mon, Jun 3, 2024 at 8:56 PM Stephen Farrell 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:-) 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> ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
Given that it will be some years before we have verified modules with ML-KEM, it seems like P-256 + ML-KEM (as an evolution of P-256 + Kyber) will have utility for some time, for those who care about validation. --Richard On Mon, Jun 3, 2024 at 4:32 PM Bas Westerbaan wrote: > X25519+ML-KEM will be acceptable for FIPS, just like P-256+Kyber is today. > We just need to wait for the final standard, and (crucially) for the > verified modules with ML-KEM. > > On Mon, Jun 3, 2024 at 8:56 PM Stephen Farrell > 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:-) >> >> Cheers, >> S. >> ___ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
X25519+ML-KEM will be acceptable for FIPS, just like P-256+Kyber is today. We just need to wait for the final standard, and (crucially) for the verified modules with ML-KEM. On Mon, Jun 3, 2024 at 8:56 PM Stephen Farrell 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:-) > > Cheers, > S. > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell 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 To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
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:-) Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
There are also companies in the US which ship X25519, but as Andrei says, there are also situations where P-256 is required. 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. Most of our customers (those who have informed opinions) prefer X25519, but our FedRAMP customers must have P256. Without comment, I point out that the IETF has a long history of “ignoring” US Government standards except when convenient to support them. Perhaps that’s changing. Even recently, we still seem to prefer that NIST, etc., accommodates what we do rather than vice-versa. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On Mon, Jun 3, 2024 at 10:49 AM Loganaden Velvindron
wrote:
>
>
> On Mon, Jun 3, 2024, 20:59 Andrei Popov 40microsoft@dmarc.ietf.org> wrote:
>
>> Correct; e.g., Microsoft Azure is one of these environments that require
>> NIST curves. Some Azure services have exceptions allowing 25519, however
>> generally 25519+MLKEM will not be acceptable for Azure services, for both
>> regulatory and security reasons.
>>
>>
>>
>
> There are companies from africa that swear by 25519. They build products
> that ship with those.
>
> In this part of the world, companies (and people) aren't so focused on
> compliance with NIST standards as north american companies are.
>
There are also companies in the US which ship X25519, but as Andrei says,
there are also situations where P-256 is required. 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.
-Ekr
>
>
> Cheers,
>>
>>
>>
>> Andrei
>>
>>
>>
>> *From:* Eric Rescorla
>> *Sent:* Monday, June 3, 2024 9:31 AM
>> *To:* David Adrian
>> *Cc:* Salz, Rich ; tls@ietf.org
>> *Subject:* [EXTERNAL] [TLS]Re: Curve-popularity data?
>>
>>
>>
>> Indeed. I'd like to pull this back a bit to the question of what we
>> specify/mandate.
>>
>>
>>
>> As I understand the situation, there are a number of environments that
>> require P-256, so it seems like it would not be practical to just
>> standardize/mandate X25519 + MLKEM if we want to get to 100% PQ algorithms.
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 3, 2024 at 7:20 AM David Adrian wrote:
>>
>> I don't really see why popularity of previous methods is relevant to
>> picking what the necessarily new method will be is, but from the
>> perspective of Chrome on Windows, across all ephemeral TCP TLS (1.2 and
>> 1.3, excluding 1.2 RSA), the breakdown is roughly:
>>
>>
>>
>> 15% P256
>>
>> 3% P384
>> 56% X25519
>> 26% X25519+Kyber
>>
>>
>>
>> On Mon, Jun 3, 2024 at 10:05 AM Filippo Valsorda
>> wrote:
>>
>> 2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
>>
>> More importantly, there are servers that will HRR to X25519 if presented
>> a P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I
>> don't have data at hand how often that happens.
>>
>>
>>
>> Are you saying that some of the 97.6% of servers that support P-256 still
>> HRR to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported
>> groups list, and that's BoringSSL's default behavior? I find that very
>> surprising and would be curious about the rationale.
>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On Mon, Jun 3, 2024, 20:59 Andrei Popov wrote:
> Correct; e.g., Microsoft Azure is one of these environments that require
> NIST curves. Some Azure services have exceptions allowing 25519, however
> generally 25519+MLKEM will not be acceptable for Azure services, for both
> regulatory and security reasons.
>
>
>
There are companies from africa that swear by 25519. They build products
that ship with those.
In this part of the world, companies (and people) aren't so focused on
compliance with NIST standards as north american companies are.
Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Eric Rescorla
> *Sent:* Monday, June 3, 2024 9:31 AM
> *To:* David Adrian
> *Cc:* Salz, Rich ; tls@ietf.org
> *Subject:* [EXTERNAL] [TLS]Re: Curve-popularity data?
>
>
>
> Indeed. I'd like to pull this back a bit to the question of what we
> specify/mandate.
>
>
>
> As I understand the situation, there are a number of environments that
> require P-256, so it seems like it would not be practical to just
> standardize/mandate X25519 + MLKEM if we want to get to 100% PQ algorithms.
>
>
>
> -Ekr
>
>
>
>
>
>
>
> On Mon, Jun 3, 2024 at 7:20 AM David Adrian wrote:
>
> I don't really see why popularity of previous methods is relevant to
> picking what the necessarily new method will be is, but from the
> perspective of Chrome on Windows, across all ephemeral TCP TLS (1.2 and
> 1.3, excluding 1.2 RSA), the breakdown is roughly:
>
>
>
> 15% P256
>
> 3% P384
> 56% X25519
> 26% X25519+Kyber
>
>
>
> On Mon, Jun 3, 2024 at 10:05 AM Filippo Valsorda
> wrote:
>
> 2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
>
> More importantly, there are servers that will HRR to X25519 if presented a
> P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't
> have data at hand how often that happens.
>
>
>
> Are you saying that some of the 97.6% of servers that support P-256 still
> HRR to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported
> groups list, and that's BoringSSL's default behavior? I find that very
> surprising and would be curious about the rationale.
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Re: Curve-popularity data?
Correct; e.g., Microsoft Azure is one of these environments that require NIST
curves. Some Azure services have exceptions allowing 25519, however generally
25519+MLKEM will not be acceptable for Azure services, for both regulatory and
security reasons.
Cheers,
Andrei
From: Eric Rescorla
Sent: Monday, June 3, 2024 9:31 AM
To: David Adrian
Cc: Salz, Rich ; tls@ietf.org
Subject: [EXTERNAL] [TLS]Re: Curve-popularity data?
Indeed. I'd like to pull this back a bit to the question of what we
specify/mandate.
As I understand the situation, there are a number of environments that require
P-256, so it seems like it would not be practical to just standardize/mandate
X25519 + MLKEM if we want to get to 100% PQ algorithms.
-Ekr
On Mon, Jun 3, 2024 at 7:20 AM David Adrian
mailto:davad...@umich.edu>> wrote:
I don't really see why popularity of previous methods is relevant to picking
what the necessarily new method will be is, but from the perspective of Chrome
on Windows, across all ephemeral TCP TLS (1.2 and 1.3, excluding 1.2 RSA), the
breakdown is roughly:
15% P256
3% P384
56% X25519
26% X25519+Kyber
On Mon, Jun 3, 2024 at 10:05 AM Filippo Valsorda
mailto:fili...@ml.filippo.io>> wrote:
2024-06-03 15:34 GMT+02:00 Bas Westerbaan
mailto:b...@cloudflare.com>>:
More importantly, there are servers that will HRR to X25519 if presented a
P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't have
data at hand how often that happens.
Are you saying that some of the 97.6% of servers that support P-256 still HRR
to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported groups
list, and that's BoringSSL's default behavior? I find that very surprising and
would be curious about the rationale.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
