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

[Nico Williams <[e-mail]>]

On Sun, Mar 07, 2021 at 11:19:49PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> On 3/7/21, 17:36, "TLS on behalf of Nico Williams" <[e-mail] on behalf of [e-mail]> wrote:
> >
> >    On Sun, Mar 07, 2021 at 09:57:40AM +0000, Peter Gutmann wrote:
> >    > Nico Williams <[e-mail]> writes:
> >    > > When expirations are short, you will not forget to renew.  That's
> >    > > part of the point of short-lived certificates.
> >    > 
> >    > 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*.

I'm not sure what it is you're imagining.  What actually happens in the
cases I'm familiar with is that there is one very long-lived root of
trust (e.g., an endorsement key in a TPM) credential that is used to get
all the short-lived credentials, and this is fully automated.  In some
cases the short-lived credentials are obtained by apps using the host's
credentials, and then only when the application is running but still,
periodically.

The benefits of this arrangement are: a) no need for revocation of
short-lived credentials, b) no need to worry about credential
expiration (because the process is automated).

I've also seen environments with very long-lived credentials where
someone has to remember to renew them.  I've seen lots of failures in
those, but none in the case described above.

Nico
--