> > > Security is not easy to evaluate. Asking random users to make > > > security decisions is a recipe for disaster. Blaming users for the > > > resulting failures simply perpetuates the problem. > And you would have a point if this was a decision between a known broken > scheme and a known to be secure construction.
The point is much broader than that extreme case. Beyond merely avoiding demonstrated attacks, the TLS WG has made many decisions designed to proactively reduce security risks. Random example: RFC 8446 says that the new TLS 1.3 KDF design "allows easier analysis by cryptographers". Looking at what has been broken is useful (see some examples below), but conflating not-publicly-demonstrated-to-be-broken with "secure" would be a dangerous regression from established WG practices. > As it stands, ML-KEM is a secure cryptographic scheme https://kyberslash.cr.yp.to demonstrated fast recovery of secret keys from the reference Kyber/ML-KEM software in various environments. After two rounds of patches for that, the reference Kyber/ML-KEM software was broken again by https://github.com/antoonpurnal/clangover in various environments, prompting further patches. That was in June. As far as I know, the reference Kyber/ML-KEM software maintainers never issued a security announcement telling users that the previous software was broken and that an upgrade is required. But the KyberSlash demo is online with full reproduction instructions. There's no actual dispute about the break. > certainly secure enough that a sophisticated user might want to choose > it over 0x11ec. Why does it make sense to take that security risk? The answer we keep hearing boils down to various claims that NSA is throwing a lot of money at this. Even if that's true---where exactly is the evidence? how do we reconcile this with NSA in https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf asking for two cryptographic layers "to mitigate the ability of an adversary to exploit a single cryptographic implementation"?---it's not a valid argument for IETF to endorse something. As I said before, it sounds crazy to let NSA buy IETF endorsement of specs that violate normal common-sense security practices. > With the United States government, there is at least one such, fairly large > user who would like to make that decision, and while you can say many > things about the NSA, lack of cryptographic expertise is not one of them. So we should standardize Dual EC for TLS, releasing full Dual EC output? Page 60 of https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-90a.pdf repeats NSA's claim that Dual EC's unpredictability is "assured by the difficulty of finding a solution to ... the elliptic curve discrete logarithm problem". Pages 90--91 repeat NSA's claim that "certain guarantees can be made about the uniform distribution" of outputs from Dual EC if, and only if, one _doesn't_ truncate more output bits. More recently, NSA's Dickie George is on video claiming that NSA generated the Dual EC points randomly and that Dual EC is secure. Yes, NSA has deep cryptographic expertise. This does _not_ mean that we should be trusting NSA's recommendations. An internal NSA history book (which NSA successfully kept secret for many years) shows NSA deciding to manipulate public standards to make sure they were "weak enough" for NSA to break. See https://blog.cr.yp.to/20220805-nsa.html for quotes and further examples. > By recommending 0x11ec, the average user will be guided to make the > slightly more conservative choice, but I do not feel like it would be a > dereliction of my duty as a cryptographer to merely allow the use of pure > ML-KEM, a statement I would not make about RC4. To clarify: Are you claiming that lattice-based cryptography has held up better than RC4? If so, are you talking about marketing, or about security? > > BCP 188 says that "The IETF Will Work to Mitigate Pervasive > > Monitoring". This implies an obligation to proactively address > > security risks. Rubber-stamping specs, rather than evaluating > > security, is contrary to that; even worse, it's inviting attackers > > to once again manipulate the standardization process. > No rubberstamping is taking place. If we were rubberstamping things, we > wouldn't be having this discussion. The _proposed_ rubber-stamping is to let NSA buy TLS WG endorsement of this spec. As I wrote before: 'The draft author claimed at the outset that hybrids were currently a "big 'maybe' at best" under "FIPS / CNSA 2.0 compliance guidelines" and would be prohibited by 2033. Scott's message was simply explicit about the money flow ("more importantly for my employer, that's what they're willing to buy. Hence, Cisco will implement it"). There have been many similar claims about what NSA supposedly requires.' Obviously the people who have already spoken up to object, including me, aren't supporting this rubber-stamping. Unfortunately, the content of the objections isn't being addressed. Instead we're being told again and again that this is what NSA wants (e.g., the citation-free "would like to make that decision" claim in the message I'm replying to now). > This is also far from the first time > this topic has come up, and least from what I did see, the draft has been > discussed on its merits thoroughly, Citation needed. I see a few bursts of discussion, with a big split between (1) ~"NSA wants this" and (2) objections on security grounds. I wouldn't describe #1 as a discussion of merits, and meanwhile there are many unanswered objections. > both on list and in meetups, and has prevailed. Sorry, is this a claim that a decision was made at a WG meeting? What was the supposed decision, and which meeting supposedly made that decision? Anyway, decisions at meetings have to be confirmed on-list. ---D. J. Bernstein _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
