Hubert Kario wrote: >Because NIST is a trend-setter, many other compliance organisations reuse >those curves >(French ANSSI, German BSI, Japanese IPA, etc.).
I think IETF is also a very strong trend-setter among governments. Other governments follow NIST when they think NIST is doing a good job or when NIST algorithms is what is available on the market. They do the same with CFRG algorithms. Dutch NCSC recommends secp384r1, secp256r1, curve448, and curve25519 https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1 French ANSSI recommends NIST P-curves but also approves X25519 X448 and Brainpool file:///Users/emanjon/Downloads/anssi-guide-recommandations_de_securite_relatives_a_tls-v1.2.pdf Japanese IPA recommends both P-256 and X25519 https://www.ipa.go.jp/security/crypto/guideline/gmcbt80000005ufv-att/ipa-cryptrec-gl-3001-3.0.1.pdf German BSI recommends Brainpool and writes that NIST P-curves can be used if Brainpool curves are not available. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=6 China recommends SM2 and Russia recommends GOST. Government recommendations are not always suitable for industry. For military and government use cases performance and monetary costs are low priority. For many industry use cases performance and monetary costs are very important priorities that also affect security. If ephemeral key exchange is slow, the answer is often to use less ephemeral key exchange instead of decreasing performance. I think it would make sense to make both P-256 and X25519 MTI. I think forcing any key shares in CH is wrong. I also think registering hybrids as code points is wrong. If TLS did the right thing like IKEv2 we would just need to register ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as “groups” and everybody would be happy because there favorite standalone of hybrid would be supported. If the Web want to use a single hybrid I think that should be discussed in W3C. Cheers, John Preuß Mattsson From: Hubert Kario <hka...@redhat.com> Date: Thursday, 6 June 2024 at 12:37 To: D. J. Bernstein <d...@cr.yp.to> Cc: tls@ietf.org <tls@ietf.org> Subject: [TLS]Re: Curve-popularity data? On Wednesday, 5 June 2024 22:00:44 CEST, D. J. Bernstein wrote: > 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"? really depends on the deployment, some just want to use SP 800-56A curves, some need actual, real, to the letter, legal compliance with FIPS 140-2 or FIPS 140-3. > 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? Short-term problem won't be solved like that for everybody. For deployments that require FIPS compliance, the implementation itself needs to be certified. At this moment there's no way to get it certified, so we are at least 2-3 years away from a certified implementation of x25519 being available even if NIST marked x25519 as approved tomorrow. > 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? Because NIST is a trend-setter, many other compliance organisations reuse those curves (French ANSSI, German BSI, Japanese IPA, etc.). Similarly Common Criteria certifications, while they're international, they're similarly heavily influenced by what NIST and NSA recommends. All of them will have a lot of inertia. And to address what John Mattsson wrote in a separate email: yes, IETF is international and should not be bound by particular government requirements for IETF standards to be actually usable in practice, they do need to take into account what governmental bodies require. What gets published by IETF can be superset of what govs want. So, while I'd love to see x25519 in governmental standards, I think it's better to spend energy making sure that we deploy ML-KEM as soon as possible, in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256 and P-384). -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C7d179e055be44dd49e3608dc861497ed%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638532670205761504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=5Jmiz7ht8yFeq6ndilYxX2JVHLCcLWYEFYBL8jr3bhk%3D&reserved=0<http://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
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
