Pros and cons of 90-day certificate lifetimes


#388

then how about using must.staple in longer certs?


#389

Must-Staple is not available in any browser except Firefox. It wouldn’t make sense for Let’s Encrypt to make policy decisions based on hypothetical future support of Must-Staple (which would take a couple of years to roll out anyway). The relevant fact is that revocation is broken today.


#390

The argument for this whole project is that we want encryption everywhere. Everywhere includes a range of hardware with web server interfaces that can take certs, but only with manual effort. It’s better if that stuff gets real certs, rather than the self-signed ones it tends to run with. That will help us get our users out of the habit of just accepting the certs, which we now for practical reasons have to sometimes encourage them to do.

With the level of verification this project is based on, anyone who can subvert an authoritative DNS server can obtain good certs from here for the domains controlled by it. Whatever damage someone will do who has just done that is likely to be done within weeks, not months. Having the certs expire 3 months after the DNS is fixed isn’t much more useful than having it be 12 months – 3 months is already long enough that the domain is basically toast. Even if you fix the DNS problem at the authoritative servers, for the next 3 months anyone who pushes the bad listing to, say, users’ cable routers can pull them into the forged site.


#391

That’s a simplified version of Let’s Encrypt’s mission. This is one of the key principles:

Secure: Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.

One of the best practices Let’s Encrypt chose to enforce are short-lived certificates. This is not something Let’s Encrypt came up with - Google, for example, has been an advocate for short-lived certificates for years, and almost all other browser vendors agree. 90 days is a good compromise between making the attack window smaller and not running into issues caused by failing automation due to the youth of the ecosystem. I don’t think it’s gonna stay at that forever, and we might see even shorter lifetimes where revocation becomes a non-issue eventually.

Sometimes, not supporting certain use-cases in order to push the industry forward is better than catering to every possible user scenario. Offering longer lifetimes - even optionally - would not have the same effect on the industry.


#392

If you want to take over the industry, “embrace and extend” is a proven road. You need to get a critical mass of users. The way to do that is to offer us what we already have, but free. What we already have is one-year certs. If the project were to issue one-year certs for several years, at that point it will have attained market dominance. Then it can start “extending” control by shortening the validity to 6 months, then 3 months, then 1 month as you suggest. It also gives time for folks to build standard forms of automation for diverse platforms to automate it so that the time-scale doesn’t remain an issue as it is now.

If you only get 5% of the market, you have no leverage. Start with the strategy to maximize market share, then turn the screws. You can even announce that schedule up front and succeed with it. But if the choice meanwhile is to invest several hours of staff time every 90 days, or stick with longer-duration commercial certs that are cheaper than that staff time is worth, you’ll lose the market share competition, just get the hobbiests who squeeze every dime, and your leverage is nothing.


#393

You’re making this argument based on your use-case, where automation is not feasible. The vast majority of web servers on the internet are running something like apache, nginx, HAProxy or IIS, where the initial setup probably takes about as long as figuring out how to purchase and install a certificate from a traditional CA. After that, things just work, and you save both labour and the cost of buying a certificate.

This is not going to have any significant effect on market share or adoption.


#394

You skipped replying to my strongest argument, which is:

With the level of verification this project is based on, anyone who can subvert an authoritative DNS server can obtain good certs from here for the domains controlled by it. Whatever damage someone will do who has just done that is likely to be done within weeks, not months. Having the certs expire 3 months after the DNS is fixed isn’t much more useful than having it be 12 months – 3 months is already long enough that the domain is basically toast. Even if you fix the DNS problem at the authoritative servers, for the next 3 months anyone who pushes the bad listing to, say, users’ cable routers can pull them into the forged site.

If this project were based on a stronger level of verification, then the shorter-term argument would hold weight.

As for your argument that automation is less-prone to error, the answer, whether that’s true or not, is: Errors of automation can result in far more going wrong, at once, than errors in manual processes. Nobody manually updates a certificate without manually checking that the update was effective. I’ve been doing this on multiple sites since certs first existed. I’ve never got it wrong that I didn’t catch and correct it within a minute or two. Yes, automation can be rigged so it sends alerts on failure. Do all the cert-renewal bots for this do that now? What happens when the email address used to set them up goes south? Sure, I have Nagios watching the validity of all my certs. But most admins don’t have that. So better to install and check by hand in their case.

Still, it’s the first argument here that should carry the day. The weakest point is control of DNS, not the length of cert validity. Focusing on the second is locking the window while leaving the front door open.


#395

I’m not sure what the level of validation performed by Let’s Encrypt has to do with the possibility of MitM’ing client connections, or how long the vulnerability window would be. I have replied to your argument that 3 months is just as bad: Google has settled on three months, and the browser community as a whole agrees that shorter equals better. Reasonable people can disagree, but policy that’s based on what Google does and other browser vendors support seems reasonable to me. When the next Heartbleed strikes, maybe 60% of the internet will only be vulnerable for 1.5 months on average instead of 1-3 years.

It seems to me that if you don’t have monitoring enabled for your services, they can’t be all that critical.


#396

[quote=“pfg, post:395, topic:4621, full:true”]
I have replied to your argument that 3 months is just as bad: Google has settled on three months, and the browser community as a whole agrees that shorter equals better.[/quote]
Your “most other browser makers agree” link above doesn’t read as what you claim. It’s about a vote where 4 in 5 browser makers favored a definition of:

There’s nothing there indicating that 4 in 5 browser makers believe 90 days would be more effective than 365 days. The only claim your link supports is that they believe that it would be good to have a class of certificates that is valid for no more than 4 days. (It also shows a majority of certificate authorities are against that.)

I can, and will, argue that certificates good for only 4 days would be a tremendously good thing; while also arguing that if it’s going to be 90 days, it may as well be 365. Also, your claim that Heartbleed remained a vulnerability for “60% of the internet” for 1-3 years is based on … what? Like many of us, I run a browser plugin to check for Heartbleed, and have since the first days of it. All major commerce and banking sites I checked were fixed within the first week – certainly well within 90 days. How are you measuring your “60%”? Let’s go to Wikipedia:

[quote]Heartbleed is a security bug disclosed in April 2014…

At the time of disclosure, some 17% (around half a million) of the Internet’s secure web servers certified by trusted authorities were believed to be vulnerable to the attack…

As of May 20, 2014, 1.5% of the 800,000 most popular TLS-enabled websites were still vulnerable to Heartbleed.[/quote]
So of the 17% initially vulnerable in April, 98+% had been fixed before June. Wikipedia can be wrong, but this agrees with other reports I recall from the time.


#397

Why would they support such an effort if they didn’t think it would improve security in general? It demonstrates that browser vendors agree that short-lived certificates are a good thing, which was my claim. The fact that Google uses 3 months as well still remains, by the way.

Indeed, it shows that CAs generally move very slowly. If you’ve been following the CA/B Forum at all, you’ll have noticed that browser vendors generally push for stricter requirements, while CAs are often concerned with trying to push for exceptions, extensions for deprecations (SHA-1), etc. I’m simplifying quite a bit, and there are plenty of CAs that do not fit this description, but it definitely puts things into perspective. Whenever I see a vote where the vast majority of browsers votes yes, while most CAs vote no, my alarm bells ring. :smile:

Admittedly, 60% was not exactly accurate. I seem to have forgotten that older openssl versions were not affected, which probably saved us a lot of trouble. I guesstimated based on “Linux/Unix marketshare for web servers”.

The point I wanted to make is not that no one fixed Heartbleed (almost everyone did), but that Heartbleed leaked your private key, and a large percentage of sites affected by Heartbleed did not revoke those certificates - and even if they did, revocation does not work anyway. If the average certificate lifetime at the time Heartbleed was detected would’ve been 1.5 months, we wouldn’t still have a huge number of keys in active use that could’ve been previously leaked through Heartbleed. Fixing the vulnerability would have no effect on that.

On a final note, since you agree that short-lived certificates are a good idea: Look at 90-day certificates as a compromise that pushes the industry towards automation (which would be absolutely necessary for 4-day certs), while still allowing for a manual or semi-manual process until the ecosystem matures.


#398

but google doesnt have the problem of doing validation and stuff all the time with a CA because they have their own intermediate, which is an important point that you (=everyone who keeps using google as argument) forget or dont say.

with a technicaly restricted (to our domain) intermediate (we wont get one for dure but just saying) the stuff yould be a bit easier because a machine that doesnt allow access from the outside (a raspi would enough for this purpose) could run a cron to sign cert cert and scp it over to the server


#399

FWIW, I’d put a lot of money on the fact that the validation logic Google uses for their internal CA is probably even more involved than what ACME does. :smile:

Plus, I’m not using Google as an argument that automation/short-lived certificates aren’t hard to implement for a number of use-cases (I don’t doubt that!). My argument is basically: Google has one of the best security teams in the industry. Google uses 90-day certs. Following that choice is probably not a bad thing.


#400

Seriously? I’ve seen multiple personal attacks by you in this thread.


#401

Because the 365’ers are NOT actually against LE issuing short lifetime (90 day) certificates. Automated or otherwise. They are against LE’s refusal to issue longer certs via the “manual” process.


#402

well google has generally a lot more power and are not just some small stuff but technically you wouldnt need to verify your domain publicly if google would let the CA server just push the cert into the servers I mean google knows their servers and considering that SSH runs on pubkey crypto that part of a validation that you are at the right server actually isnt hard.
also as google can get wildcards (and they literally spam it in their certs, although you may not see it everytime, probably depending on the server you hit. once cert where I actually saw it was serial number 51:E4:7E:D1:28:A4:43:6E ( https://crt.sh/?id=22333100 ) with FORTY wilds and a few other domains.

well they probably also have a larger team to manage all that stuff than most other things.


#403

…and you needed to respond two months later to point that out?

Yes, understood. And at least 90% of the “con” posts in this thread are raising issues already mentioned in the OP. IOW, the LE team already know of them, so mentioning them again (and again, and again, and again) adds nothing to the discussion.


#404

The message from jsha didn’t seem to sink in.

In your opinion.

Tell McDonalds to stop advertising. We’ve heard their message before. Pounding it into our brain adds nothing to their sales. You obviously don’t get the concept of persuasion and the power of persistence. Or maybe you do and it is concerning to you that it may get traction and be successful against your desires. So you try to discourage it with nonsense like you just posted.


#405

I agree that repeating the same arguments over and over again isn’t going to lead anywhere. Derailing the discussion with meta-posts is not really a contribution to the discussion either.

This is obviously not an issue with simple black-and-white logic. There are tradeoffs and priorities involved. This thread exists so that we can discuss these tradeoffs, find use-cases from various perspectives where short-lived certificates can be problematic, and determine whether supporting these use-cases is worthwhile in exchange for the added security benefits of short-lived certificates and the push towards automation. It is not a place for propaganda and/or brigading, nor is it a place to exchange personal attacks. I hope all participants in this discussion can accept that.


#406

Just to re-iterate my concern from an earlier comment here (Pros and cons of 90-day certificate lifetimes)

The current implementation of the clients and behavior of the registry does not offer a commitment or expectation to keep things backwards compatible for a window of time. This can be somewhat scary when you have 90day certifications and need to rely on automated systems that routinely update against something that could break.

Within the next 90 days, the intermediate signing authority could change – and it could be changed to a root that is not enabled on our test devices or production clients by default.

It would be great if there were some sort of compatibility commitment, and a notification system that people can opt-into for upcoming platform changes (such as cycling keys).


#407

Major changes will be announced to subscribers via email, that’s why those addresses are being collected (plus expiration mails, of course). Protocol changes are always done with backwards compatibility in mind - new ACME versions, for example, will run on a new API endpoint.

Regarding key rollover, I agree that this can be problematic. The nice bit about ACME is that all these things are first-party components of the protocol - issuer certificates are part of it, and there’s even supports multiple issuer certificates so that clients can pick one that it thinks works best, or just serve all of them. The Integration Guide has a section called “Plan for Change” which captures this sentiment quite nicely.

There are always going to be things that break in unexpected ways (like the Windows bug that was triggered when the issuer certificate was changed), but as a whole the ecosystem should become more stable and reliable as a result of this. There are a lot of parallels to the DevOps vs. traditional sysadmin discussion, I think.