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

[Graham Bartlett <[e-mail]>]

Hi

Ref

'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.'

I would imagine that the implementation would pull the session down once
the certificate expires, so the session only lasts for the lifetime of the
certificate.

I know that some IPsec implementation does this.

cheers



On Sun, Mar 7, 2021 at 11:53 AM Deb Cooley <[e-mail]> wrote:

> 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 <[e-mail]>
> 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 <[e-mail]>
>> 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?
>>>
>>> Peter.
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>