On Sun, Jun 22, 2025 at 6:08 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Sun, Jun 22, 2025 at 05:13:06PM +0100, Yaroslav Rosomakho wrote: > > [ I do understand the stated reasons by the way, they superficially > make some sense, but I think they're worth a critical look. ] > [ I know that - and I consider this to be a productive discussion to find some form of consensus and explore if this is a corner case that should belong to the land of proprietary custom solutions or a generic enough problem that should have a solution in a form of an open standard ] But the TLS private keys in question are *authentication* keys, if the > key was lost after the connection was established, there is no risk to > the already established session. If the key compromise happend prior, > and connection establishment was not under an MiTM attack, the > connection is still secure. Only if the connection is to a rogue device > that cannot refresh the certificate, and the other end is not made aware > of the compromise, does certificate update potentially address a problem, > Fully agree. > Is it believed that the MiTM would be unable to obtain a fresh > certificate, or compromise the next key in the same manner as the first > if the attack has not been discovered? I other words, I rather think > that the scenario that really matters is a *known* post-compromise > scenario, and in that case, the best response is operator intervention. > And this is where I respectfully disagree. If this was the only scenario that matters we would not need to ever expire certificates. Just revoke them if a compromise happens. After all, expired non-revoked certificates normally prevent new connections from being established for a good reason. > And I suspect that certificate update is more often likely to contribute > to intermittent failure than to prevent continuation of compromised > connections. > Similarly one could claim that certificate expiration is more likely to contribute to failures affecting service availability for new connections (in some cases with catastrophic consequences). However instead of producing certificates with longer validity to mitigate these availability risks PKI policies tend to go other direction and dramatically reduce certificate validity. > So the question is whether the potentially rare cases in which the risks > are well managed, processes well oiled, and the protocol change is useful, > justify the complexity and effort to get this done, as opposed to > putting the effort into improving operator diligence (a pre-requisite to > security IMHO, unmonitored security is subject to bitrot). > In my opinion, these are complimentary matters. Guardrails of protocols and technologies help operators limit the effects of operational failures. > > 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. > > Assuming that the bad actor isn't able to repeat the undetected > comromise, or refresh the certificate now that the previous key is in > hand. > > Perhaps with sufficient guidance on pros/cons, sufficiently diligent > operators could benefit from an additional capability of this shape, > but I'd also expect this to be misunderstood, and misued more often > than used appropriately. > If there is enough appetite to eventually accept and work on Certificate Update, I would expect this to be an optional TLS extension for specific categories of use cases. Based on these conversations, I can see that additional applicability text should be added to the draft as well as clearly outlined availability risks. Thanks again for the detailed arguments! > -- > 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
