From 9da1787c8467eba211d4ec4bf31e6fba4595804a Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Thu, 14 Nov 2019 12:45:07 +0100 Subject: [PATCH 1/3] Fix inconsistency in root key migration paragraph Updates an outdated paragraph in section 6.1 that explained how root keys are rotated by backwards-verifying signatures from the latest root file available on the repository back to the latest root file available on the client. The correct (new) workflow, which is also described in step 1 of the client application workflow of section 5, performs verification in a forward-directed manner, i.e. starting at the latest root on the client and going forward to the latest root on the repo. --- tuf-spec.md | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index e293a2e..762b078 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1292,22 +1292,23 @@ non-volatile storage as FILENAME.EXT. 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 update the set of trusted root keys by requesting - the current root.json and all previous root.json versions, until one is - found that has been signed by a threshold of keys that the client already - trusts. This is to ensure that outdated clients remain able to update, - without requiring all previous root keys to be kept to sign new root.json - metadata. - - In the event that the keys being updated are root keys, it is important to - note that the new root.json must at least be signed by the keys listed as - root keys in the previous version of root.json, up to the threshold listed - for root in the previous version of root.json. If this is not the case, - clients will (correctly) not validate the new root.json file. For example, - if there is a 1.root.json that has threshold 2 and a 2.root.json that has - threshold 3, 2.root.json MUST be signed by at least 2 keys defined in - 1.root.json and at least 3 keys defined in 2.root.json. See step 1 in - Section 5.1 for more details. + 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 + files, and verifying that each root metadata at a given version is signed by + a threshold of keys defined in the previous version of root, and a threshold + of keys defined in that given version of root. + For example, if there is a 1.root.json that has threshold 2 and a + 2.root.json that has threshold 3, 2.root.json MUST be signed by at least 2 + keys defined in 1.root.json and at least 3 keys defined in 2.root.json. + The client starts the root keys update update process with the latest + version of root metadata available on the client, and stops when no newer + root metadata is available from the repository. This ensures that an + outdated client can always correctly re-trace the chain of trust across + multiple root key updates, even if the latest set of root keys on the client + dates back multiple root metadata versions. See step 1 of the client + application workflow in Section 5 for more details. 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 From 085d453b57c80f8fadefe121cefa342763f1c5f2 Mon Sep 17 00:00:00 2001 From: lukpueh Date: Fri, 15 Nov 2019 11:34:56 +0100 Subject: [PATCH 2/3] Refine wording in root key migration paragraph Co-Authored-By: mnm678 Co-Authored-By: Trishank Karthik Kuppusamy <33133073+trishankatdatadog@users.noreply.github.com> --- tuf-spec.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 762b078..0309937 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1296,19 +1296,20 @@ non-volatile storage as FILENAME.EXT. Clients that have outdated root keys can update to the latest set of trusted root keys, by incrementally downloading all intermediate root metadata - files, and verifying that each root metadata at a given version is signed by - a threshold of keys defined in the previous version of root, and a threshold - of keys defined in that given version of root. + files, and verifying that each current version of the root metadata is + signed by a threshold of keys specified by its immediate predecessor as well + as a threshold of keys specified by itself. For example, if there is a 1.root.json that has threshold 2 and a 2.root.json that has threshold 3, 2.root.json MUST be signed by at least 2 - keys defined in 1.root.json and at least 3 keys defined in 2.root.json. - The client starts the root keys update update process with the latest - version of root metadata available on the client, and stops when no newer - root metadata is available from the repository. This ensures that an - outdated client can always correctly re-trace the chain of trust across - multiple root key updates, even if the latest set of root keys on the client - dates back multiple root metadata versions. See step 1 of the client - application workflow in Section 5 for more details. + keys defined in 1.root.json and at least 3 keys defined in 2.root.json. The + client starts the root key update process with the latest version of root + metadata available on the client, and stops when no version N+1 (where N is + the latest trusted version) of the root metadata is available from the + repository. This ensures that an outdated client can always correctly + re-trace the chain of trust across multiple root key updates, even if the + latest set of root keys on the client dates back multiple root metadata + versions. See step 1 of the client application workflow in Section 5 for + more details. 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 From 890b38349c3a80e6429d2dada2f3840a599d3574 Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Fri, 15 Nov 2019 11:55:13 +0100 Subject: [PATCH 3/3] Mention freeze attack in root migration paragraph --- tuf-spec.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tuf-spec.md b/tuf-spec.md index 0309937..74b57a8 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1311,6 +1311,11 @@ non-volatile storage as FILENAME.EXT. versions. See step 1 of the client application workflow in Section 5 for more details. + 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. + 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 delegation is done.