Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Nico Williams <[e-mail]>]

On Sat, Mar 06, 2021 at 06:55:52AM +0000, Peter Gutmann wrote:
> Nico Williams <[e-mail]> writes:
> 
> >I've seen 5 day server certificates in use.  
> 
> For IEC-62351 work you're far more likely to see certificates issued with an
> expiry date of never, because the last thing you want is your power grid to be
> taken offline due to a cert someone forgot to renew.

When expirations are short, you will not forget to renew.  That's part
of the point of short-lived certificates.

Set lifetime long enough that you have enough time to renew in most
outage scenarios (i.e., pick N days such that you expect no outage will
take longer than that to resolve, and be conservative for things like
power grids), but short enough that you simply must automate renewal.

> In terms of CRL updates the situation is similar, the spec may say you need to
> check once every X time interval but in practice you forget to perform the
> check in case it takes your grid offline.  Or set a flag saying "cert revoked"
> and continue anyway, I've seen both.  [...]

Sure.

>                               [...].  The 24-hour thing sounds like someone's
> checkbox requirement rather than anything practically useful, or usable.

Short-lived certs are a "checkbox requirement" where the theory is that
if it's short enough (doesn't have to be 1 day) then you will be forced
to automate renewal, so you'll never fail to renew.

It's about improving ops, not so much about security.

That it also helps with revocation -so you don't have to bother with it-
is also an ops (and dev) benefit.

Nico
--