> The _proposed_ rubber-stamping is to let NSA buy TLS WG endorsement of this spec.
No. I proposed this document because I want to be able to negotiate PQ-only key establishment without hybrid. It got codepoints and now is getting more support, which is nice. I wrote it because I wanted to use it. Enough. On Fri, Dec 13, 2024 at 6:07 PM D. J. Bernstein <d...@cr.yp.to> wrote: > > > > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
