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.
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.
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.
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.
"CT Logs" are Certificate Transparency Logs, which are cryptographically provable append-only data structures hosted by trusted operators. Every certificate issued is publicly logged in two or more CT Logs, so that browsers can ensure that CAs aren't lying about what certs they have or have not issued.
Reducing the lifetime of certificates increases the number of certificates that have to be issued, and therefore the number of certs that are logged to CT. This increases the cost to CT operators, which is unfortunate since the set of operators is currently very small.
However, a number of recent improvements (like static-ct-api and the upcoming Merkle Tree Certs) are making great strides in reducing the cost of operating a CT log, so we think that the ecosystem will be able to keep up with reductions in cert lifetime.
Please don't suggest pinning a publicly-trusted intermediate. The CA may change which intermediate they're using at any time for any reason with no warning, and then the app which pinned that intermediate is hosed.
(Disclaimer: I am tech lead of Let's Encrypt software engineering)
I'm also concerned about LE being a single point of failure for the internet! I really wish there were other free and open CAs out there. Our goal is to encrypt the web, not to perpetuate ourselves.
That said, I'm not sure the line of reasoning here really holds up? There's a big difference between this three-hour outage and the multi-day outage that would be necessary to prevent certificate renewal, even with 6-day certs. And there's an even bigger difference between this sort of network disruption and the kind of compromise that would be necessary to take LE out permanently.
So while yes, I share your fear about the internet-wide impact of total Let's Encrypt collapse, I don't think that these situations are particularly analogous.
That's not leverage that a CA can use. If half the internet suddenly displays TLS warning interstitials, it doesn't make people mad at the CA, and it doesn't make people mad at their browser: it just _trains them to ignore such warnings_. That's a bad outcome all around, and one that a CA whose core purpose is improving security for end-users cannot condone.
The "tlsclient" profile will not be TLSClientAuth-only: it will have both the TLSServerAuth and TLSClientAuth profiles, like the default profile does today. It will exist solely for the purpose of helping people transition off of using Let's Encrypt certificates for mTLS. If they've been unaware of these conversations, their systems will break when the TLSClientAuth EKU is removed from the default profile. That will be their wake-up call, and then they can temporarily select the "tlsclient" profile to get a brief grace period to migrate their systems before the TLSClientAuth EKU is removed entirely.
This is exactly why the LE IP certs will be limited to 6 days: this exact attack is possible today against any IP address cert, and such certs in general are allowed to have lifetimes up to 398 days. LE isn't comfortable with that situation, so IP certs will have the shortest feasible lifetimes.
For what it's worth, the person you're replying to is the founder and executive director of Let's Encrypt, the non-profit free and open CA which decidedly isn't a money-printing machine.