The issue with saying that "there's a 60/40 split, therefore there's no consensus" is that the IETF explicitly documents that that isn't the case: RFC 7282, Section 7, "Five people for and one hundred people against might still be rough consensus" (https://datatracker.ietf.org/doc/html/rfc7282#section-7).
The working group chairs have to decide if all of the objections have been "addressed". However, "addressed" doesn't mean "fixed via changes in the document", it can also mean "debunked on the mailing list" or "dismissed out of hand as irrelevant". So your argument that there obviously isn't consensus doesn't actually hold up.
What I said was "It makes much more sense to argue there is no consensus […] can be argued even in a "60:40" situation regardless of direction".
Not "there's a 60/40 split, therefore there's no consensus".
Can be argued even in. That's a statement of allowance, not sufficiency. And I was speaking in the context of contrasting against a vote. You can't argue with a vote's tally.
This is not an unbiased article about the situation unfolding on the TLS Working Group mailing list; this is a call to action to join one specific side of the argument that has been ongoing for over a year now. It's an appeal to authority, an attempt to garner support for one side of the debate simply because DJB says so, as part of his effort to flood the zone with messages in opposition.
This tactic is explicitly called out in RFC 7282, and named as a "degenerate", "pathological", and "dysfunctional" state for the working group to be in. Shame on DJB for attempting to drive the working group into terminal dysfunction.
Is that what he's trying to do? I am no cryptographer, but when I read his post, his arguments about ECC+PQ make intuitive sense.
I'm out of fresh tin-foil hats as well, but it would not surprise me in the least if any government was actively engaged in weakening security and privacy protections.
Literally look at what they are all doing in almost every sphere. The current political zeitgeist is all about automated surveillance everywhere. The motivations are worn on their sleeves.
DES key-size weakening is consistent with NOBUS (given the computational dominance of the US at the time). DUAL_EC_DRBG is consistent with NOBUS. DES S-box strengthening (vs linear/differential cryptanalysis, I forget which) is also consistent with NOBUS.
There have been *no* proposed mechanism that would allow NSA to have a NOBUS-style attack against ML-KEM.
Separately, this RFC (pure ML-KEM) is marked "recommended to implement = N". It is highly likely all browsers etc will use hybrids. In certain areas (say hardware) it is not free to use a hybrid. You all of a sudden need both a SHA2 and SHA3 implementation, for example. Some organizations that view the threat of quantum computers as more credible may also not want to drag around the ECC component (which is known to be broken, once a CRQC appears. Google and the US government have publicly stated concerns this may occur within the next ~5 years after recent QC breakthroughs).
Clearly, NOBUS can work at multiple levels. DJB previously posted about DES (besides it being weak enough): NSA wanted DES to "drive out competitors", to "reduce the field that NSA had to be concerned about".
Simply reducing the complexity of the standard to "pure ML-KEM" could already be considered enough "NOBUS" to be workable, such that the focus of attacks can be only on it (and bonus NOBUS if weaknesses are already known).
Sure, it's not completely free, but the hardware and implementation points seem relatively minor. Once CRQC exists the capacity will certainly not be unlimited, so there will surely still be use for encryption using ECC and "dragging it around" is not so bad.
Your comment being top of thread, and you seemingly being conversant in the details of the issue, would be exceptionally well-placed to make an argument on the merits of the subject matter. Character portraits are sometimes useful, but technical detail is often conclusive.
What's the steelman of djb's position and why does it fail scrutiny? To the uninitiated, it sounds like his preference for the hybrid classical/BQP scene is prudent given the marginal computational burden.
But I'm guessing, it would be better if an expert weighed in with details.
Sure, you make a good point. I certainly didn't expect to end up at the top of this thread, and stopped paying attention immediately after posting it (for the same reason I don't read every message on the TLS WG list).
The kindest reading of DJB's position is simple: pure ML-KEM is strong against fewer potential future scenarios than hybrid algorithms are, so people should use hybrid algorithms instead.
And in fact, I agree with this statement! The marginal cost of hybrid algorithms is very small, and the extra safety provided by being hybrid is (in my opinion) slightly larger than that cost. My cost/benefit analysis says that hybrid is the way to go for most people.
However, there are two major flaws with DJB's actual argument:
1. He's making the jump from "most people shouldn't use pure ML-KEM by default" to "the ability to use pure ML-KEM shouldn't be standardized at all". He's making overblown assertions about the power and meaning of an Informational IETF document, and using those to attempt to prevent simple interoperability standardization. Just because I think hybrids are the safer default in general doesn't mean that pure ML-KEM should be verboten; people deserve options, and the role of this document is to provide interoperability instructions for that option.
2. He's resorting to character attacks to imply that ML-KEM simply isn't safe at all. He frequently points to support from NSA and GHCQ as evidence that ML-KEM has been suborned in the same way as DUAL_EC_DRBG, despite widespread agreement in the cryptography community that the ML-KEM parameter space simply doesn't allow such attacks. He frequently points to support from cryptographers at Google and Cisco in the same breath, implying that they too are in the pay of the NSA. He's refusing to acknowledge that his implications that ML-KEM is unsafe imply that he should also oppose standardization of ML-KEM hybrids.
So while there's a kernel of truth to DJB's argument, I strongly believe that he has both taken the conclusion too far, and taken his argumentation tactics too far. It has lowered my respect for him as a person even further than it already was by his defense of Jacob Applebaum.
What? It's not being described a theorem (the technical term for a mathematical proposition for which there is a proof). It's an experienced cryptographer saying that a certain operation should be more conservatively designed than it is. He makes arguments that fall short of proof but are the best we can hope for, given the current state of knowledge.
As for the NSA, yes, he documents what is happening pretty well, though it's done through above board channels rather than envelopes full of cash. He quotes an NSA person as saying hybrid protocols are unlikely to receive approval for use in government systems. That is, "if you want the government to buy your stuff ($$$$$), it better not implement hybrid". Similar to Dual_EC_DRBG.
None of the NSA (or even ex-NSA) people I know have participated in this discussion at all. I imagine they're preoccupied with the current administratiom's stupid decisioms disrupting their work.
This (also not unbiased) comment doesn't provide any substantive arguments other than a character attack on DJB. You'd also be hard-pressed to find an appeal to authority in this article. Lastly, I'm pretty sure the comment I'm replying to is at least partially LLM-generated.
Ironically, it's the incredibly weak pro-standardization arguments that appear to be the most convincing evidence that the proposed standard is actually an instance of NSA meddling.
djb has always been as outlandishly activist and combative as he is intelligent and competent.
Anyone who attributes public motives or activity or blame to "the NSA" automatically gets dropped into the "conspiracy theorist" bin, as far as I'm concerned.
DJB is the same person who created qmail, the mail transfer agent which was ridiculously secure because of a series of over-the-top design decisions; for example, each file in the mail queue was named after the inode it was stored in, meaning you couldn't copy your mail queue to another server if your original one was having issues (unless you cloned the whole filesystem). Also, all configuration was done at compile time, including what UIDs and GIDs to run as, meaning it was very difficult to build it once and re-use it on multiple systems unless you were very careful to make them identical, which is fine because you weren't allowed to distribute compiled binaries.
He maintained that it was the most secure option available, which was technically true until the technology around mail transfer started improving with things like SPF records. qmail didn't support them and wouldn't support them, patches weren't accepted, and the only way to use things like SPF (to reduce spam) was through unofficial community patches that could never be upstreamed.
qmail was far better than sendmail at the tiume, and honestly it probably still is to a large degree, but, like forcing users to change their password every week, it was a case of security being so tight that users had to break it in order to make the system functional.
All this to say that, while DJB is undoubtedly insightful and intelligent, I'm wary of any of his claims of 'this isn't secure enough' because of his past history of making things so secure as to be inflexibly unmanagable.
Funny thing about conspiracy "theory" is that a lot of the time the theory turns out to be true. In my view, the impulse to dismiss any suggestion of clandestine group activity (except if it's China's government, or Russia's, or Iran's, or...) as a "theory" is most likely the result of a psychological operation.
The Dale Gribbles of the world are not a particularly common character to meet in real life but that's the image evoked by "conspiracy theorist" no matter who the pejorative is aimed at, no matter the arguments they make nor the evidence they present. "Conspiracy theorist" is a thought-stopping, ad hominem cliché, with no place in serious discussion, yet it is widely used in exactly that; the possibility of conspiracy itself is what is eschewed in such discussions.
> Funny thing about conspiracy "theory" is that a lot of the time the theory turns out to be true.
I would love to see any sources on this claim.
A lot of "conspiracy theories" end up being true in some vague way; "the NSA is spying on all of us", yeah, that was true. The NSA is using satellites to read our thoughts? Not so much. Still, people will point to things like the Snowdon leaks to prove that the US government cannot be trusted (which is true) and therefore all the other claims that people make are also true.
The reality is that most conspiracy theories are impossible, either from a technical sense or a logistical one. The extreme examples, like "the earth is flat and the governments are hiding it" or "COVID isn't real and the vaccine is going to kill everyone but every government and doctor on earth is secretly in on it" get shrugged off as "well, not THOSE ones obviously", but most of the rest I've ever seen are also completely unbelievable.
Here's the thing: anyone can come up with a theory and stitch together the most circumstantial "evidence" to "prove" it, combining misinformation, misunderstanding, and misrepresentation to produce something that feels like it could be true on its face if people don't do any real digging, and most don't. I've yet to see a "conspiracy theory" backed by any actual hard evidence; they seem to entirely spring from an overactive imagination and are then "justified" and "proven" by finding other facts to fit the narrative retroactively.
Is there clandestine activity? Absolutely. Are there groups of people trying to manipulate situations and lie to the public for their own gain? Almost certainly. Do people with unsourced, unproven conspiracy theories make it easier for governments to get away with whatever they want because the rampant proliferation of crackpot theories allows for a convenient smokescreen whenever the truth starts to come out? Also yes.
Even if only 10% of conspiracy theories are true, which they are not, the people repeating them do more harm than good by doing so in a way that discredits themselves and others.
The idea of the conspiracy theorist is a hyperbole fabricated in the public mind by the "almost certain" activity of "groups of people trying to manipulate situations and lie to the public for their own gain". It's not that a reasonably plausible theory being discussed will logically lend credence to less plausible and unrelated ones, it's that the public is conditioned to believe that it does. That way, public discussion of any conspiracy in theory is verboten by the "conspiracy theory" thought-stopper, regardless of the theory's plausibility. Because, as you say yourself, it makes it easier for conspiracy in practice to go unnoticed in the public sphere. From a Bayesian perspective, the problem is less likely caused by the crazy people who have a poor grasp on reality than the people who not only have a reason to emphasize the crazy people (because it de-emphasizes themselves), but also the means.
Our code for sending stuff to CT logs is fully open source. But that's the tiniest slice of our compliance regime -- the vast majority of it is things like audit logging certain events, preserving audit logs in specific ways for certain amounts of time, ensuring dual-controls on all systems, being both audited and penetration tested annually, maintaining firewalls and vulnerability scanning tools, etc.
It's absolutely possible to spin up another new CA; lots of folks have done so over the years. But having time, and money, and prior experience all help a lot.
Yep, the "shortlived" (6-day) profile will be available to the general public later this week. But at this time we explicitly encourage only mature organizations with stable infrastructure and an oncall rotation to adopt that profile, as the risks associated with a renewal failing at the beginning of a holiday long weekend are just too high for many sites.
Honest reply: because the infrastructure isn't ready to support 1-day certificates yet. If your cert is only valid for one day, and renewal fails on a Saturday, then your site is unusable until you get back to work on Monday and do something to fix it. There are things that can be done to mitigate this risk, like using an ACME client which supports fallback between multiple CAs, but the vast majority of sites out there today simply aren't set up to handle that yet.
The point of the CA/BF settling on 47-day certs is yes, to strongly push automation, but also to still allow time for manual intervention when automation fails.
FWIW, we're acutely aware of the operational risks of super short lifetimes and frequent renewals. That's why our `shortlived` profile is clearly documented as only being appropriate for orgs that have high operational maturity and an oncall rotation. We carry pagers too, and if LE goes down for 48 hours, we'll be desperately trying not to take out a huge chunk of the Internet.
Yep! Should be available to the general public (as long as you're using an ACME client that can be configured to request a specific profile) later this week.
It's a good question! I know that our first root (ISRG Root X1) used that naming scheme simply because it was cross-signed by IdenTrust's root (DST Root CA X3) which used that same scheme. But where they got the scheme from, I don't know.
Using Y to denote the "next generation" of roots is a scheme I came up with in the past year while planning our YE/YR ceremony, so it's certainly not something that people were thinking about when they named the first roots.
Certificates that look like renewals -- for the same set of names, from the same account -- are exempt from rate limits. This means that renewing (for example) every 30 days instead of every 60 days will not cost any rate limit tokens or require any rate limit overrides.
Organizations with many frontends/loadbalancers all serving the same site tend to adopt one of four solutions:
- Have one node with its own ACME account. It controls key generation and certificate renewal, and then the new key+cert is copied to all nodes that need it. Some people don't like this solution because it means you're copying private keys around your infrastructure.
- Have one node with its own ACME account. The other nodes generate their own TLS keys, then provide a CSR to the central node and ask it to do the ACME renewal flow on their behalf. This means you're never copying keys around, but it means that central node needs to (essentially) be an ACME server of its own, which is a more complex process to run.
- Have one ACME account, but copy its account key to every node. Have each node be in charge of its own renewal, all using that shared account. This again requires copying private keys around (though this time its the ACME key and not the TLS key).
- Give every node its own ACME account, and have each node be in charge of its own renewal.
The last solution is arguably the easiest. None of the nodes have to care about any of the others. However, it might run into rate limits; for example, LE limits the number of new account registrations per IPv6 range, so if you spin up a bunch of nodes all at once, some of them might fail to register their new accounts. And if your organization is large enough, it might run into some of LE's other rate limits, like the raw certificates-per-domain limit. Any of the above solutions would run into that rate limit at the same time, but rate limit overrides are most easily granted on a per-account basis, so having all the nodes share one account is useful in that regard.
Another factor in the decision-making process is what challenge you're using. If you're using a DNS-based challenge, then any of these solutions work equally well (though you may prefer to use one of the centralized solutions so that your DNS API keys don't have to live on every individual node). If you're using an HTTP-based challenge, you might be required to use a centralized solution, if you can't control which of your frontends receives the HTTP request for the challenge token.
Anyway, all of that is a long-winded way to say "there's no particularly wrong or right answer". What you're doing right now makes sense for your scale, IMO.
The working group chairs have to decide if all of the objections have been "addressed". However, "addressed" doesn't mean "fixed via changes in the document", it can also mean "debunked on the mailing list" or "dismissed out of hand as irrelevant". So your argument that there obviously isn't consensus doesn't actually hold up.