On Sun, Jun 22, 2025 at 4:40 PM Viktor Dukhovni <ietf-d...@dukhovni.org> 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 -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > -- 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.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
