[Avamander]

Kind-of. But there are worse things than outages when it's PKIs we're talking about. DNSSEC is also extremely opaque and unmonitored. Any compromise will not be noticed. Nor will anyone have any recourse against misbehaving roots.

Fun fact, CloudFlare has used the same KSK for zones it serves more than a decade now.

[daneel_w]

Which is fine. Not because KSK rollover is supposedly complicated, but if you can't manage to keep your private keys and PKI safe in the first place then key rotation is just a security circus trick. But if you do know how to keep them safe, then...

[Avamander]

It is not fine. Keeping key material safe is not a boolean between "permanently safe" and "leaks immediately".

Keeping key material secure for more than a decade while it's in active use is vastly more complex than keeping it secure for a month, until it rotates.

For all we know, some ex-employee might be walking around with that KSK, theoretically being able to use it for god knows what for an another decade.

[daneel_w]

Yeah, theoretically. They "only" need continued access to CF's internal systems. Surely you're aware that the ZSK is confined to your zone and can be rotated as much as you want without having to involve the root/registrar, and with none of the risks or consequences of not knowing how to perform a KSK rollover?

What's your take on the conundrum of Amazon Trust's 20+ year root cert, with which they sign a 5+ year intermediate, with which they sign a 2-month leaf?

[cyberax]

> Keeping key material secure for more than a decade while it's in active use is vastly more complex than keeping it secure for a month, until it rotates.

Nope. Key material rotation is just circus when it's done for the sake of rotation.

> For all we know, some ex-employee might be walking around with that KSK, theoretically being able to use it for god knows what for an another decade.

Or maybe an employee has compromised the new key that is going to be rotated in, while the old key is securely rooted in an HSM?

[tptacek]

The point of rotation for these kinds of keys is that it limits the blast radius of what happens if an employee compromises such a key. This is sort of like how there are one or two die-hard PGP advocates who have come up with a whole Cinematic Universe where authenticated encryption is problematic ("it breaks error recovery! it's usually not what you want!") because mainstream PGP doesn't do it. Except here, it's that key rotation is bad, because of how often DNSSEC has failed to successfully pull off coordinated key rotations.

[cyberax]

I can see the periodic rotations used as a way to keep up the operational experience. This is indeed a valid reason, although it needs to be weighted against the increased risk of compromise due to the rotation procedure itself.

I'm just saying that rotating the key just in case someone compromised it is not a great idea. Doubly so if it's done infrequently enough for the operational experience to atrophy between rotations.

And yeah, I fully agree that anything surrounding the DNSSEC operations is a burning trash fire. It doesn't have to be this way, but it is.

[tptacek]

I'm glad we agree about DNSSEC, but the rationale I'm giving you for key rotation is the same reason we use short-lived secrets everywhere in modern cryptosystems. It's not controversial (except among Unix systems administrators).

[Avamander]

> Or maybe an employee has compromised the new key that is going to be rotated in, while the old key is securely rooted in an HSM?

Also possible, but that'd be an active threat that has some probability of being caught.

Never replacing keys allows permanent compromise that can only be caught if someone directly observes misuse.

Though nobody monitors DNSSEC like that, nor uses it, so it's fine from that aspect I guess.

[jcgl]

> Nope. Key material rotation is just circus when it's done for the sake of rotation.

I'm a mere sysadmin and not a cybersecurity expert. But this is always something that leaves me torn.

On the one hand, yes, rotation periods for many/most credentials are long enough that you're not really de-risking yourself all that much.

On the other hand, doing regular rotations allows you to tighten up your threat model. A regularly-rotated credential allows you to say "I implicitly trust that this credential has not been compromised prior to the previous rotation."[0] Whereas, without credential rotation, you're saying "I implicitly trust that this credential has not been compromised ever."

The latter to me seems clearly like the inferior model. The question is just whether the cost-benefit pencils out. And that is obviously very situationally dependent. That calculus doesn't pencil out when dealing with user-owned passwords for instance (i.e. the costs of regular password rotation dominate the benefits of the improved threat model). Human limitations with memory and such are the main issue there. However, that doesn't apply to e.g. hypothetical sufficiently developed DNSSEC infrastructure. Does that calculus pencil out there? I don't know. But it seems plausible at least.

[0] Modulo attackers having been able to pivot into a persistent threat with a previously-compromised credential.