There's been some discussion here in other threads, but in general I expect any "production" site to use multiple CAs, to allow for one CA to be down. This is already the case for some sites (Wikipedia is a prominent example), and some ACME clients make this easier than others, but hopefully ACME client software will continue to make configuring such a multi-CA setup easier.
Note that a week-long CA-unable-to-sign-things outage is already a problem, even with 90-day-or-longer certificates, because Let's Encrypt needs to sign an OCSP and/or CRL response every week (or more often) saying what certificates are or aren't revoked. Many browsers might not check, so a site might not "go down" in as visible a way as a certificate expiring, but part of what these shorter certificates are trying to solve is specifically that a browser might be trusting that a cert is still good even though it really shouldn't be anymore.
So if Let's Encrypt are down for 7 days then it's not their plan you need to be concerned with because they are either already well and truly in disaster recovery mode.
So the answer is: What is your plan if Let's Encrypt suffer a serious outage.
Realistically that's a plan for switching CA. Some ACME clients support automated CA fallback (Caddy, Certify The Web, maybe a few others), most don't that I know of and that's an exercise left up to you, so you need to practice that in advance and document the process, which would literally be a plan.
That depends on the software you are using to renew your certificates.
Regarding the debate around certificate lifetimes, that's subjective depending on your priorities but it mainly centers around short term certificates having a significantly reduced requirement for revocation checking:
Personally I don't really mind how long/short certs are valid for because mine are well and truly automated (dynamically renewing at 75% of their lifetime, not based on a number of days), however Let's Encrypt plan to stick with 90 day certificates as the default for now as far as I know (and in fact to even make the switch over you would need to upgrade to an ACME client that support "profiles", then opt into the correct profile). So you can just ignore them for now if you want to, as most other people will do.
Security wise, sure, but the 90 days certs include OCSP currently (that's going away), so that would mean a lot more certs to sign and a heck of a lot more OCSP responses to sign, which has a terrible performance impact.
The fact that short lived certs don't need OCSP or CRL makes that they don't increase the load that much.
How would more frequent renewal cause more OCSP requests to LE? (apart from OCSP stapling, which reduces OCSP load)
The number of deployed certificates (configured on a server) would stay the same.
OCSP responses need to be signed regularly during the lifetime of a certificate. This is done by the Hardware Security Modules (HSMs) too, which also do the certificate signing.
If you increase the amount of certificates signed per unit of time while not decreasing their lifetime, you get a total increase of valid certificates in the ecosystem. And thus the requirement of signing more and more OCSP responses for those total amount of certificates.
If you increase the amount of certificates signed per unit of time while also decreasing their lifetime, the total amount of certificates does not vary (for the sake of argument, but because you'd renew early, you'd get an increase nonetheless).
Now, removing OCSP and CRL entirely for short lived certs entirely will forgo with the extra signing of revocation stuff, so only the signing of the cert itself puts load on the HSMs.
OCSP stapling does not matter at all with regard to the HSM signing of the OCSP responses, that only matters for data transfers/bandwidth.
Sure, on a server, but not "out there". Any publicly trusted certificate needs to have valid OCSP responses during their lifetime, even if they're not in use.
As far as I know, yes, they are generated up front and pushed to the CDN. Although perhaps there is something "smart" going on, I'm not familiar with the details.
Ok, I didn't know that. In that case, there's indeed more (useless) work for the OCSP server if certificates get issued more frequently when not also reducing their valid lifetime.
For the record, we used to pre-sign OCSP responses and push them to the CDN, but we no longer do so. We discovered that the distribution of OCSP-requests-per-certificate is highly lopsided: some certificates never have OCSP requested across their entire lifetime, while others get OCSP requests thousands of times per second. So now we sign OCSP responses on-demand, resulting in slightly more signatures for very popular certs (due to details of CDN caching behavior), but significantly fewer signatures for unpopular certs.
Regardless, the statement that 90-day certs replaced every 6 days are equivalent to 6-day certs is also incorrect. Part of the point of short-lived certs is that they expire quickly even if they are compromised or issued to a bad actor due to a compromise. A 90-day cert does not have that feature.
This has been an interesting discussion. I suppose if I were running a bank or some other high risk site, 6 day certificates might improve my overall risk profile. Operating a low-risk site, my primary concern is that users would start getting security warnings or fail to connect at all if something went wrong. It's good to know that the 6 day option shouldn't concern me.
Looks like I'm remembering old info, sorry about that @ghen 