On Sun, Mar 07, 2021 at 11:19:49PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> > > So instead of getting one chance a year for your control system to break
> > > itself if the renewal fails, you get hundreds of them?
> >
> > Yes. Exactly. It's a human factors problem. And this solution works.
>
> With all due respect, *absolutely not*.
Well, it works when fragile manual processes (likely to be entirely
forgotten until things break) that are almost good enough to get by
on every year or two, become plainly unreasonable when exercised every
month or every week. In other words, short-lived certs force:
- Active monitoring
- Automation of preëmptive renewals (with sufficient time
to retry more than once on failure).
The tools to make this possible need to be available before we ask
people to invent this for themselves, but the effect on operational
discipline is real.
If either monitoring or automation are skipped, then sure, you have
a recipe for failure. But if the signal is not ignored, and proper
automation is applied, reliability actually improves.
I see this effect in the stability of DANE deployments at domains that
are using Let's Encrypt with "mailinabox.email" which automates the
lifecycle including TLSA record updates, ..., v.s. DYI MTAs with certs
are only renewed every year or two (often wildcard shared by all MTAs
for the domain).
The mailinabox systems do a far better job of keeping their certs valid.
Despite the fact that they make up 1/3 of the deployed MXs, they make up
a much smaller fraction of the domains I ping when the DANE survey finds
poorly managed cert chains that fail authentication.
Does this mean that a nuclear reactor's cooling system should shut down
when a cert expires? Probably not, ... but if one is going to manage
certificates that do expire, my bet is that the short-lived ones are
better managed, and will exhibit fewer total hours of downtime, despite
the more frequent expirations.
--
Viktor.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
