> working on _removing_ the NSA curves from specs that have been infected by > them.
While I don’t see any use for P-256, P-384 in the future, I find this statement awful. DES, P-cirves, SHA-2, and ECDSA have served us very well and made the world a more secure place. I would like governments to be more involved in security standardization and would love to see them publish more algorithms. I really liked Speck, Simon, GLEVIAN, and VIGORNIAN. Sent from Commodore VIC-20 ________________________________ From: D. J. Bernstein <[email protected]> Sent: Saturday, October 11, 2025 11:52:18 AM To: [email protected] <[email protected]> Subject: [TLS] Re: [External] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 Yaroslav Rosomakho writes: > TR-02102-2 [1] is quite specific about recommended TLS 1.3 groups. In Table > 9 of the section 3.4.2 it lists secp256r1, secp384r1, secp521r1, > brainpoolP256rltls13, brainpoolP384rltls13, brainpoolP512rltls13, > ffdhe3072 and ffdhe4096. Thanks---I was looking at TR-02102-1 rather than TR-02102-2. Content-wise, I don't see how Table 9 in TR-02102-2 supports the notion that SecP256r1MLKEM768 or SecP384r1MLKEM1024 is required for compliance with something. On the contrary, if the table's recommendations are "regulatory requirements" then group 4587 (SecP256r1MLKEM768) is _prohibited_, as are the other groups in the draft under discussion. The table lists only groups 23, 24, 25, 31, 32, 33, 257, and 258. Furthermore, https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20251011090852%2Fhttps%3A%2F%2Fwww.ssllabs.com%2Fssltest%2Fanalyze.html%3Fd%3Dwww.bsi.bund.de&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C6cd31964b30243fe53e408de08ac0e7a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638957732234318699%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6dl4etVdNLtqsMi7ivrdjyivESQfX20qqir4Vrkp%2Fdw%3D&reserved=0<https://web.archive.org/web/20251011090852/https://www.ssllabs.com/ssltest/analyze.html?d=www.bsi.bund.de> says every modern web client uses X25519 for https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bsi.bund.de%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C6cd31964b30243fe53e408de08ac0e7a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638957732234339007%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EGNkXGG8LRCNdVoX%2FNd6AANUUHT5EztkFrw%2BGTdkHis%3D&reserved=0<https://www.bsi.bund.de/>, so it doesn't seem that BSI actually prohibits X25519 in the real world. The claim up thread that there are "regulatory requirements" sounds impressive, but I'd like to see a complete argument that (1) pinpoints the "regulatory requirements" we're talking about, (2) lays out how SecP256r1MLKEM768 and SecP384r1MLKEM1024 are necessary for meeting those requirements, and (3) explains how this produces an important improvement for the "deployability" goal in the charter, outweighing the damage done to the "security" goal in the charter. It seems to me that both deployability and security are best served by eliminating the NSA curves everywhere, so that implementors can stick to the simplicity of Montgomery x-coordinate ECDH. But this means working on _removing_ the NSA curves from specs that have been infected by them. Certainly drafts shouldn't just slouch into allowing those curves. ---D. J. Bernstein ===== NOTICES REGARDING IETF ===== It has come to my attention that IETF LLC believes that anyone filing a comment, objection, or appeal is engaging in a copyright giveaway by default, for example allowing IETF LLC to feed that material into AI systems for manipulation. Specifically, IETF LLC views any such material as a "Contribution", and believes that WG chairs, IESG, and other IETF LLC agents are free to modify the material "unless explicitly disallowed in the notices contained in a Contribution (in the form specified by the Legend Instructions)". I am hereby explicitly disallowing such modifications. Regarding "form", my understanding is that "Legend Instructions" currently refers to the portion of https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20250306221446%2Fhttps%3A%2F%2Ftrustee.ietf.org%2Fwp-content%2Fuploads%2FCorrected-TLP-5.0-legal-provsions.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C6cd31964b30243fe53e408de08ac0e7a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638957732234352384%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fj8hDNaDZhqZ7nC%2Ft7p6fgNxDq53OUsXrIa78kjzFzw%3D&reserved=0<https://web.archive.org/web/20250306221446/https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf> saying that the situation that "the Contributor does not wish to allow modifications nor to allow publication as an RFC" must be expressed in the following form: "This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft". That expression hereby applies to this message. I'm fine with redistribution of copies of this message. There are no confidentiality restrictions on this message. The issue here is with modifications, not with dissemination. For other people concerned about what IETF LLC is doing: Feel free to copy these notices into your own messages. If you're preparing text for an IETF standard, it's legitimate for IETF LLC to insist on being allowed to modify the text; but if you're just filing comments then there's no reason for this. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
