From 1ce55566ca5314e6157e210a460e2feb35300d65 Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Sat, 28 Mar 2026 05:29:38 +1100 Subject: [PATCH 1/2] spec: s6.1: add links for root.json This better matches the rest of the spec's linking of each *.json reference. Signed-off-by: Aleksa Sarai --- tuf-spec.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 38e0066..c65f8a5 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1588,11 +1588,11 @@ should be encrypted and stored, and so it is left to implementers of this document to decide how best to secure them. To replace a compromised root key or any other top-level role key, the root -role signs a new root.json file that lists the updated trusted keys for the -role. When replacing root keys, an application will sign the new root.json -file with both the new and old root keys. Any time such a change is -required, the root.json file is versioned and accessible by version number, -e.g., 3.root.json. +role signs a new root.json file that lists the updated trusted keys for +the role. When replacing root keys, an application will sign the new +root.json file with both the new and old root keys. Any time such a +change is required, the root.json file is versioned and accessible by +version number (e.g., 3.root.json). Clients that have outdated root keys can update to the latest set of trusted root keys, by incrementally downloading all intermediate root metadata From 81f82b9fd42f844f44f1470dc3531cd6c8041f7f Mon Sep 17 00:00:00 2001 From: Aleksa Sarai Date: Sat, 28 Mar 2026 05:32:57 +1100 Subject: [PATCH 2/2] spec: s6.1: recommend aggressive timestamp key rotation The previous text tried to minimise the risk of the root.json freeze attack, but in practice the expiry of root.json is set to several years to reduce the usage of the incredibly critical root role keys -- if an attacker freezes root.json they can buy themselves time to try to access a threshold of keys even if you try to key rotate your way out of it. The core issue that allows the root.json freeze attack is that the new root.json is the only thing signed by the new root keys, so there is no way for a user to detect that they are being blocked from seeing a new root.json. However, a very simple workaround (and arguably good general policy) is to rotate other keys that are used to sign (comparatively) short-expiry metadata. By rotating all of the timestamp keys, an attacker blocking root.json will cause clients to error out as soon as they either see a new timestamp.json (because it is signed by keys the client does not recognise) or an old timestamp.json after a short delay (because the short expiry has elapsed). The client cannot conclusively determine that the attack was actually a root.json freeze attack or just a malicious mirror providing completely invalid signatures, but the attack is no longer silent. Unlike other alterative workarounds (such as including the hash and revision number of root.json in snapshot.json), this approach does not open the door to lower-trust keys being able to cause DoSes or fast-forward attacks by including bogus information about root.json. This new recommendation just boils down to simply rotating a few extra keys when updating root.json. This does open the door to possible races with naive repository storage media (such as a client erroring out after seeing a mismatched root.json and timestamp.json, because one file was updated before another) but those are already the case with any other key rotation and there are well-known workarounds (such as using transactions to ensure that all metadata files are updated together). Signed-off-by: Aleksa Sarai --- tuf-spec.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index c65f8a5..fa4f51c 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -3,7 +3,7 @@ Title: The Update Framework Specification Shortname: TUF Status: LS Abstract: A framework for securing software update systems. -Date: 2026-01-22 +Date: 2026-03-28 Editor: Justin Cappos, NYU Editor: Trishank Karthik Kuppusamy, Apple Editor: Joshua Lock, Verizon @@ -1612,8 +1612,15 @@ versions. See step [[#update-root]] of the client application workflow for more Note that an attacker, who controls the repository, can launch freeze attacks by withholding new root metadata. The attacker does not need to -compromise root keys to do so. However, these freeze attacks are limited by -the expiration time of the latest root metadata available to the client. +compromise root keys to do so. +Such freeze attacks are limited by the expiration time of the latest root +metadata available to the client, but given the expiration time of the root +metadata is usually set to be very long (in order to limit the usage of such +important keys) this is not a large hurdle for attackers. +In order to make such attacks detectable by clients, repository operators +should always replace all timestamp keys each time a new version of the root +metadata is created. Doing this will narrow the window of a root metadata +freeze attack to the expiry of timestamp.EXT (which is usually very short). To replace a delegated developer key, the role that delegated to that key just replaces that key with another in the signed metadata where the