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

Hi Hannes

You're right, I rushed the answer. You would only need to perform the CRL
check on all existing connections, not re-authenticate. This would then
kill the session for the recently revoked certificate.

So I've mainly worked on solutions involving mobile devices; laptops and
phones. Normally if the device is lost/stolen it's gone and assumed
compromised. You wont be issuing it a new certificate for that device.

cheers

On Sun, Mar 7, 2021 at 3:50 PM Hannes Tschofenig <Hannes.Tschofenig@arm.com>
wrote:

> Focusing on one sentence from below:
>
>
>
>    - 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.
>
>
>
> Why would you trigger re-authentication of all connections? You could
> terminate the connection of the device with the compromised certificate.
>
>
>
> In your IPSec VPN scenario, how do you get a new certificate to the
> compromised device?
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS <tls-bounces@ietf.org> *On Behalf Of * Graham Bartlett
> *Sent:* Sunday, March 7, 2021 12:16 PM
> *To:* Peter Gutmann <pgut001@cs.auckland.ac.nz>
> *Cc:* John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>; TLS
> List <tls@ietf.org>
> *Subject:* Re: [TLS] Question to TLS 1.3 and certificate revocation
> checks in long lasting connections
>
>
>
> 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
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>