Skip to content

CONCEPT Cited by 4 sources

Key rotation

Definition

Key rotation (in DNS terminology, a rollover) is the planned replacement of a cryptographic key with a new one while keeping the system operational. It limits the time any single private key is exposed, bounds the damage from an undetected compromise, and — just as importantly — exercises the machinery of generating, distributing, and retiring keys so that process is reliable when it genuinely matters.

Rotation difficulty scales with where the key sits in the chain of trust. Rotating a leaf key is routine (a parent re-signs it). Rotating the trust anchor at the top is the hard case: nothing above it can vouch for the replacement, so the new key must be distributed out of band and every verifier must independently come to trust it before the switch.

Rotate before you must, to rehearse the hard path

A recurring lesson: the value of a routine rotation is partly the rehearsal. Trust-anchor distribution, verifier updates, and old-key retirement can fail even when the cryptography itself is sound. Performing regular, low-stakes rotations keeps that muscle warm for the high-stakes change (an algorithm rollover, or a post-quantum migration) where failure is not an option. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)

Canonical instance: the DNS root KSK rollover

The hardest rotation on the public Internet is the root key-signing key (KSK) rollover in DNSSEC — replacing the one key that has no parent to vouch for it, which every validating resolver on Earth must trust.

KSK-2024 → KSK-2017 (October 11, 2026):

  • New KSK-2024 (key tag 38696) replaces KSK-2017 (key tag 20326) as the signer of the root DNSKEY set. Both use RSA/SHA-256 — a key rollover, not an algorithm rollover.
  • Distribution began long before the switch: KSK-2024 was published in the root DNSKEY set since 2025-01-11 (for RFC 5011 auto-updating resolvers, which hold a new anchor ≥ 30 days before accepting it) and added to Cloudflare resolver built-in anchors in July 2024.
  • Retirement is a separate, later step: ICANN plans to revoke KSK-2017 in 2027, remove it from the root zone, and delete its private key. "Stopping a key from signing and removing trust in that key are separate steps."
  • This is only the second root KSK rollover ever (the first was 2017/2018). IANA's idealized interval is three years; the gap stretched due to pandemic disruption and HSM upgrades.

(Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)

Key rollover vs algorithm rollover

A key rollover swaps the key pair but keeps the same signing algorithm (KSK-2024 keeps RSA). An algorithm rollover additionally changes the method — and is strictly harder, because verifiers need both a new trust anchor and software that can verify the new signatures. ICANN has proposed a future root algorithm rollover to ECDSA P-256 (smaller keys/signatures; not post-quantum), and ultimately a post-quantum KSK will require yet another rollover. Keeping the algorithm fixed during routine rollovers lets operators test trust-anchor distribution in isolation. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)

ZSK vs KSK rotation cadence

DNSSEC's two-key split (see concepts/dnssec) exists partly to make rotation tractable: the zone-signing key (ZSK) rotates often and cheaply (it's not the anchor), while the key-signing key (KSK) — the trust anchor — rotates rarely and with heavy ceremony. Note that rotating a lower key more often does not substitute for protecting a higher one: an attacker targets the weakest key highest in the chain and forges everything below it ("break once, forge everywhere"). (Source: sources/2026-09-10-cloudflare-1111-post-quantum-dnssec)

Implicit rotation: a key derived from a time bucket

Not every rotation is an event. A seal key can be derived from a coarse time bucket, so it rolls over automatically each bucket with no explicit rollover ceremony and no new key material to distribute. Meta's NTS cookie seal key is the canonical instance: HKDF-SHA256(master, salt = BE32(day), info = "fbnts-cookie-seal-v1"), where day is whole Unix epoch days — a daily rotation whose schedule is implicit in the salt. Because every server derives the same key for the same day from the shared master, there is no key ring to replicate; the only coordination needed is a skew-tolerant acceptance window (Meta accepts two days back, one forward) so clients and servers slightly out of sync still interoperate across a day boundary. The window is the single knob trading key-lifetime against skew-tolerance: too narrow and clock-skewed clients fail at the boundary; too wide and a leaked derived key stays valid longer. See patterns/stateless-token-via-time-derived-key for the full design. (Source: sources/2026-10-06-meta-nts-authenticated-time-at-meta)

This contrasts with the DNSSEC KSK rollover above on nearly every axis: the KSK is a trust anchor rotated rarely, out-of-band, with heavy ceremony and a separate revocation step; a time-derived seal key is a non-anchor rotated continuously, in-band, by pure derivation, with the old bucket aging out of the acceptance window instead of being formally revoked.

Epoch-based soft vs hard rotation (key-wrapping systems)

A key-wrapping system that distributes wrapped keys globally gets a third rotation shape: rotate the wrapping root, versioned by an epoch, and choose how aggressively to retire old epochs. Cloudflare's GeoKey Manager names the two modes (Source: sources/2026-10-23-cloudflare-pq-geokey-manager):

  • Soft rotation — mint a new epoch for the regional root key while retaining controlled access to a bounded number of previous epochs. New customer keys are wrapped under the latest epoch; older wrapped keys stay usable during the transition. The number of retained epochs is the knob trading key-lifetime against transition smoothness. Cloudflare's analogy: a credit-card issuer letting a previous card keep working for recurring charges while you move to the new one. This is the same re-wrap-the-small-key-not-the-big-data property as envelope encryption — only the derived/wrapped keys move, not the underlying secured material.
  • Hard rotation — rewrap affected customers' wrapped keys under a replacement epoch so access to the previous epoch can be fully removed. Analogy: the issuer refusing the old card under any circumstances. This is the revocation-grade path; it costs a rewrap pass but closes the window on a suspected-compromised epoch.

The epoch is part of each wrapped key's metadata triple (service context, regional boundary, epoch), so a verifier knows which root generation a key belongs to and can reject keys whose epoch is no longer accepted — a fail-closed check analogous to the DNSSEC revocation step above.

Seen in

  • sources/2026-10-23-cloudflare-pq-geokey-manager — epoch-versioned soft/hard rotation of a geo-fenced wrapping root. GeoKey Manager rotates the per-region symmetric root key by minting a new epoch; soft rotation keeps a bounded set of prior epochs valid for a grace period (credit-card analogy), hard rotation rewraps affected keys to revoke an old epoch outright. Separate from this is the membership refresh (which datacenters constitute a region), which Zinc updates several times a day with no key change.
  • sources/2026-10-06-meta-nts-authenticated-time-at-meta — implicit daily rotation via epoch-day key derivation. Meta's NTS cookie seal key is HKDF-SHA256(master, salt = BE32(day), ...); rotation is automatic per Unix-epoch-day with a 2-back/1-forward acceptance window for clock skew — no key ring, no distribution event, the old key simply ages out.
  • sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready — the KSK-2024 root rollover: key-vs-algorithm distinction, RFC 5011 distribution, built-in anchors, separate revocation step, and the "rotate-to-rehearse" rationale for the eventual PQ migration.
  • sources/2026-09-10-cloudflare-1111-post-quantum-dnssec — why rotating a zone key more frequently doesn't defend against a compromised key higher in the chain.
Last updated · 854 distilled / 2,448 read