From c43045a85a637a5e2922af2dc1af08691e496780 Mon Sep 17 00:00:00 2001 From: Joshua Lock Date: Tue, 11 Jan 2022 10:12:37 +0000 Subject: [PATCH] Remove ambiguity in update root after a failed attempt (#196) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In section 5.3. Update the root role the specification suggests, in multiple steps (5.3.4, 5.3.5 and 5.3.10) that should the client fail to verify the updated root metadata the downloaded data should be discarded, the error reported, and: > On the next update cycle, begin at step § 5.3 Update the root role and > version N of the root metadata file. This directive only makes sense if the client application continues running between update cycles and therefore still has initial trusted root metadata loaded and a fixed update start time recorded. For at least python-tuf and go-tuf this is not how the update workflow is implementated. Avoid confusion by removing the recommendation to start at 5.3 on the next update cycle and instead leave only the suggestion to remove unverified data. Logically, the next update cycle starts at the first step -- loading the initial trusted root metadata. Signed-off-by: Joshua Lock --- tuf-spec.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index de4742d..1ca9b0a 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -16,7 +16,7 @@ Boilerplate: copyright no, conformance no Local Boilerplate: header yes Markup Shorthands: css no, markdown yes Metadata Include: This version off, Abstract off -Text Macro: VERSION 1.0.27 +Text Macro: VERSION 1.0.28 Note: We strive to make the specification easy to implement, so if you come @@ -1312,8 +1312,7 @@ it in the next step. the trusted root metadata file (version N), and (2) a threshold of keys specified in the new root metadata file being validated (version N+1). If version N+1 is not signed as required, discard it, abort the update cycle, - and report the signature failure. On the next update cycle, begin at step - [[#update-root]] and version N of the root metadata file. + and report the signature failure. 5. **Check for a rollback attack.** The version number of the trusted root metadata file (version N) MUST be less than or equal to the version @@ -1321,8 +1320,7 @@ it in the next step. checking that the version number signed in the new root metadata file is indeed N+1. If the version of the new root metadata file is less than the trusted metadata file, discard it, abort the update cycle, and report the - rollback attack. On the next update cycle, begin at step [[#update-root]] - and version N of the root metadata file. + rollback attack. 6. Note that the expiration of the new (intermediate) root metadata file does not matter yet, because we will check for it in step 5.3.10. @@ -1338,8 +1336,7 @@ it in the next step. 10. **Check for a freeze attack.** The expiration timestamp in the trusted root metadata file MUST be higher than the fixed update start time. If the trusted root metadata file has expired, abort the update cycle, - report the potential freeze attack. On the next update cycle, begin at step - [[#update-root]] and version N of the root metadata file. + report the potential freeze attack. 11. **If the timestamp and / or snapshot keys have been rotated, then delete the trusted timestamp and snapshot metadata files.** This is done