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

So we can break this down into 2 categories:

expiry
revocation

for both clients and servers.

Expiry:  for the server/client.  I suspect this is mostly a 'don't care',
except in the case where a certificate *should* be revoked after it is
expired (nobody does that, right?).  Is this worth addressing?  I suspect
not.

Revocation:  The RP* can check this whenever it desires.  If one has
designed a long lived connection, then the RP needs to handle it.  Does
TLS, the protocol need to handle it?  Don't know.

Short lived certificates:  I think these are a good idea.  And if one does
this, rekey/renewal early and often is the way to prevent breakage.
IMHO....

On Sun, Mar 7, 2021 at 6:16 AM Graham Bartlett <graham.ietf@gmail.com>
wrote:

> Hi
>
> I have a fair amount of hands on experience with IPsec VPNs, and many
> organisations look to use TLS in a similar manner.
>
> To give you an example of where you might look to perform a regular
> revocation check on long lived connections;
>
> Solution with many remote devices (think remote access, so phones,
> laptops, IoT devices etc)
> A remote device is compromised, on the gateway there could be 1000s of
> devices connected.
> I've found that most vendor solutions aren't geared up for an admin to
> easily determine the compromised device and prevent this reconnecting. Most
> organisations have a disconnect between the SOC, PKI team and the team that
> manages the remote access gateway, getting a process that'll involve all 3
> teams usually doesn't work.
>
> I've found that the best method to prevent the device from connecting is
> for the certificate to be revoked, the CRL refreshed and then a
> re-authentication performed on all active connections.
>
> I'm not as familiar with TLS as I am IPsec, but hope that this explains
> a scenario where I feel re-authentication would be very valuable.
>
> cheers
>
> On Sun, Mar 7, 2021 at 9:58 AM Peter Gutmann <pgut001@cs.auckland.ac.nz>
> wrote:
>
>> Nico Williams <nico@cryptonector.com> 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?
>>
>> Peter.
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>