[TLS] Re: [External⚠️] Re: Certificate Update in TLS

[Yaroslav Rosomakho <[e-mail]>]

On Sun, Jun 22, 2025 at 4:40 PM Viktor Dukhovni <[e-mail]>
wrote:

> On Sun, Jun 22, 2025 at 04:27:59PM +0100, Yaroslav Rosomakho wrote:
>
> > > This appears to be the case at first blush, but I wonder which is more
> > > likely:
> > >
> > >     - The key was already compomised when the connection was first
> > >       established, and a later failure to perform certificate update
> > >       helps to limit the duration of a compromise of which the node
> > >       operator might not otherwise have been able to learn in a
> > >       similarly timely manner.
> > >
> >
> > Another set of problems as discussed previously is "revocation of
> > identity". That is, a party is no longer supposed to be using the claimed
> > identifier.
>
> It suffices for the operator of the affected node in question to reset
> all active connections when the node's role changes to no longer include
> the function formerly served.  Why should that be detected via a
> failure to perform a certificate update???
>

It suffices indeed, but as explained previously this does not always
happen. Operator may move service to a different hosting provider, update
DNS but forget to shutdown previous instance and keep connections up.
Operator could also loose access to the instance before getting a chance to
shut it down.
Sadly, this does happen.

Certificate Update would be a failsafe.


> It seems to me that the simplest way to not disrupt long-lived
> connections is to NOT disrupt them at all, i.e. not perform certificate
> updates.  Let the connection run as-is indefinitely.  If necessary, in
> exception situations, either operator can reset their node or the
> connection.
>
> Which *operational* problem does certificate update actually solve that
> cannot be solved an alternative operational process?
>

The operational problem is reduction of private key risk or identity
compromise.
As discussed previously, this is one of the reasons certificates expire -
and one of the reasons behind the new 6-day WebPKI offerings.

Bad actors do not always announce widely when they compromise certificates.
Certificate holder may not be aware that a memory dump was taken from their
VM or some interesting side channel attack was performed via the hypervisor
and certificate private key was copied. In-band Certificate Update with
reasonably short lived certificates would mitigate those risks.

The only alternative process I can think of is implementing Exported
Authenticators or a similar mechanism on application layer that would
signal updated certificate. This will require modification of every
relevant higher level protocol. Doing it on TLS layer instead is much more
straightforward, universal and carries lower risks.


> This feels like a heavy-weight technical proxy, that itself risks
> connection stability, for what should be rare operator intervention.
>
> --
>     Viktor.
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>

-- 


This communication (including any attachments) is intended for the sole 
use of the intended recipient and may contain confidential, non-public, 
and/or privileged material. Use, distribution, or reproduction of this 
communication by unintended recipients is not authorized. If you received 
this communication in error, please immediately notify the sender and then 
delete all copies of this communication from your system.