From 7e710801563357442903070ede9cd1b536a83b18 Mon Sep 17 00:00:00 2001 From: Vladimir Diaz Date: Tue, 11 Jul 2017 17:01:09 -0400 Subject: [PATCH 1/2] Use consistent wording in the client workflow Fixes issue #458. --- docs/tuf-spec.txt | 64 +++++++++++++++++++++++------------------------ 1 file changed, 31 insertions(+), 33 deletions(-) diff --git a/docs/tuf-spec.txt b/docs/tuf-spec.txt index 250a4dfc..1ede38a7 100644 --- a/docs/tuf-spec.txt +++ b/docs/tuf-spec.txt @@ -949,14 +949,11 @@ Version 1.0 (Draft) 5.1. The client application - 0. **Load the previous root metadata file.** We assume that a good, trusted + 0. **Load the trusted root metadata file.** We assume that a good, trusted copy of this file was shipped with the package manager / software updater using an out-of-band process. - 0.1. **Check signatures.** The previous root metadata file MUST have been - signed by a threshold of keys specified in the previous root metadata file. - - 0.2. Note that the expiration of the previous root metadata file does not + 0.1. Note that the expiration of the trusted root metadata file does not matter, because we will attempt to update it in the next step. 1. **Update the root metadata file.** Since it may now be signed using @@ -965,7 +962,7 @@ Version 1.0 (Draft) do so, the client MUST download intermediate root metadata files, until the latest available one is reached. - 1.1. Let N denote the version number of the previous root metadata file. + 1.1. Let N denote the version number of the trusted root metadata file. 1.2. **Try downloading version N+1 of the root metadata file**, up to some X number of bytes (because the size is unknown). The value for X is set by @@ -975,27 +972,28 @@ Version 1.0 (Draft) available, then go to step 1.8. 1.3. **Check signatures.** Version N+1 of the root metadata file MUST have - been signed by: (1) a threshold of keys specified in the previous root + been signed by: (1) a threshold of keys specified in the trusted root metadata file (version N), and (2) a threshold of keys specified in the - current root metadata file (version N+1). + new root metadata file being validated (version N+1). - 1.4. **Check for a rollback attack.** The version number of the previous - root metadata file must be less than or equal to the version number of this - root metadata file. Effectively, this means checking that the version - number signed in the current root metadata file is indeed N+1. + 1.4. **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 + number of the new root metadata file (version N+1). Effectively, this means + checking that the version number signed in the new root metadata file is + indeed N+1. - 1.5. Note that the expiration of the current (intermediate) root metadata + 1.5. Note that the expiration of the new (intermediate) root metadata file does not matter yet, because we will check for it in step 1.8. - 1.6. Set the previous to the current root metadata file. + 1.6. Set the trusted root metadata file to the new root metadata file. 1.7. Repeat steps 1.1 to 1.7. 1.8. **Check for a freeze attack.** The latest known time should be lower - than the expiration timestamp in the current root metadata file. + than the expiration timestamp in the trusted root metadata file. - 1.9. **If the the timestamp and / or snapshot keys have been rotated, then - delete the previous timestamp and snapshot metadata files.** This is done + 1.9. **If the timestamp and / or snapshot keys have been rotated, then + delete the trusted timestamp and snapshot metadata files.** This is done in order to recover from fast-forward attacks after the repository has been compromised and recovered. A _fast-forward attack_ happens when attackers arbitrarily increase the version numbers of: (1) the timestamp metadata, @@ -1012,11 +1010,11 @@ Version 1.0 (Draft) FILENAME.EXT (e.g., timestamp.json). 2.1. **Check signatures.** The timestamp metadata file must have been - signed by a threshold of keys specified in the root metadata file. + signed by a threshold of keys specified in the trusted root metadata file. - 2.2. **Check for a rollback attack.** The version number of the previous + 2.2. **Check for a rollback attack.** The version number of the trusted timestamp metadata file, if any, must be less than or equal to the version - number of this timestamp metadata file. + number of the new timestamp metadata file. 2.3. **Check for a freeze attack.** The latest known time should be lower than the expiration timestamp in this metadata file. @@ -1036,24 +1034,24 @@ Version 1.0 (Draft) of this metadata file MUST match the timestamp metadata. 3.2. **Check signatures.** The snapshot metadata file MUST have been signed - by a threshold of keys specified in the previous root metadata file. + by a threshold of keys specified in the trusted root metadata file. 3.3. **Check for a rollback attack.** - 3.3.1. Note that the previous snapshot metadata file may be checked for + 3.3.1. Note that the trusted snapshot metadata file may be checked for authenticity, but its expiration does not matter for the following purposes. - 3.3.2. The version number of the previous snapshot metadata file, if any, - MUST be less than or equal to the version number of this snapshot metadata - file. + 3.3.2. The version number of the trusted snapshot metadata file, if any, + MUST be less than or equal to the version number of the new snapshot + metadata file. 3.3.3. The version number of the targets metadata file, and all delegated - targets metadata files (if any), in the previous snapshot metadata file, if - any, MUST be less than or equal to its version number in this snapshot + targets metadata files (if any), in the trusted snapshot metadata file, if + any, MUST be less than or equal to its version number in the new snapshot metadata file. Furthermore, any targets metadata filename that was listed - in the previous snapshot metadata file, if any, MUST continue to be listed - in this snapshot metadata file. + in the trusted snapshot metadata file, if any, MUST continue to be listed + in the new snapshot metadata file. 3.4. **Check for a freeze attack.** The latest known time should be lower than the expiration timestamp in this metadata file. @@ -1072,15 +1070,15 @@ Version 1.0 (Draft) FILENAME.EXT. 4.1. **Check against snapshot metadata.** The hashes (if any), and version - number of this metadata file MUST match the snapshot metadata. This is - done, in part, to prevent a mix-and-match attack by man-in-the-middle + number of this metadata file MUST match the trusted snapshot metadata. This + is done, in part, to prevent a mix-and-match attack by man-in-the-middle attackers. 4.2. **Check for an arbitrary software attack.** This metadata file MUST - have been signed by a threshold of keys specified in the latest root + have been signed by a threshold of keys specified in the trusted root metadata file. - 4.3. **Check for a rollback attack.** The version number of the previous + 4.3. **Check for a rollback attack.** The version number of the trusted targets metadata file, if any, MUST be less than or equal to the version number of this targets metadata file. From ca6a0422c3482e05ee40267bc9de9c143fc414a6 Mon Sep 17 00:00:00 2001 From: Vladimir Diaz Date: Wed, 12 Jul 2017 10:45:44 -0400 Subject: [PATCH 2/2] Update tuf-spec.txt Further edits to client workflow to replace instances of "this metadata file" with the specific metadata file. --- docs/tuf-spec.txt | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/docs/tuf-spec.txt b/docs/tuf-spec.txt index 1ede38a7..c729d675 100644 --- a/docs/tuf-spec.txt +++ b/docs/tuf-spec.txt @@ -1009,7 +1009,7 @@ Version 1.0 (Draft) filename used to download the timestamp metadata file is of the fixed form FILENAME.EXT (e.g., timestamp.json). - 2.1. **Check signatures.** The timestamp metadata file must have been + 2.1. **Check signatures.** The new timestamp metadata file must have been signed by a threshold of keys specified in the trusted root metadata file. 2.2. **Check for a rollback attack.** The version number of the trusted @@ -1017,7 +1017,9 @@ Version 1.0 (Draft) number of the new timestamp metadata file. 2.3. **Check for a freeze attack.** The latest known time should be lower - than the expiration timestamp in this metadata file. + than the expiration timestamp in the new timestamp metadata file. If so, + the new timestamp metadata file becomes the trusted timestamp + metadata file. 3. **Download and check the snapshot metadata file**, up to the number of bytes specified in the timestamp metadata file. @@ -1030,8 +1032,9 @@ Version 1.0 (Draft) the client MUST write the file to non-volatile storage as FILENAME.EXT. - 3.1. **Check against timestamp metadata.** The hashes, and version number - of this metadata file MUST match the timestamp metadata. + 3.1. **Check against timestamp metadata.** The hashes and version number + of the new snapshot metadata file MUST match the hashes and version number + listed in timestamp metadata. 3.2. **Check signatures.** The snapshot metadata file MUST have been signed by a threshold of keys specified in the trusted root metadata file. @@ -1054,7 +1057,9 @@ Version 1.0 (Draft) in the new snapshot metadata file. 3.4. **Check for a freeze attack.** The latest known time should be lower - than the expiration timestamp in this metadata file. + than the expiration timestamp in the new snapshot metadata file. If so, + the new snapshot metadata file becomes the trusted snapshot metadata + file. 4. **Download and check the top-level targets metadata file**, up to either the number of bytes specified in the snapshot metadata file, or some @@ -1070,20 +1075,21 @@ Version 1.0 (Draft) FILENAME.EXT. 4.1. **Check against snapshot metadata.** The hashes (if any), and version - number of this metadata file MUST match the trusted snapshot metadata. This - is done, in part, to prevent a mix-and-match attack by man-in-the-middle + number of the new targets metadata file MUST match the trusted snapshot metadata. + This is done, in part, to prevent a mix-and-match attack by man-in-the-middle attackers. - 4.2. **Check for an arbitrary software attack.** This metadata file MUST - have been signed by a threshold of keys specified in the trusted root + 4.2. **Check for an arbitrary software attack.** The new targets metadata file + MUST have been signed by a threshold of keys specified in the trusted root metadata file. 4.3. **Check for a rollback attack.** The version number of the trusted targets metadata file, if any, MUST be less than or equal to the version - number of this targets metadata file. + number of the new targets metadata file. 4.4. **Check for a freeze attack.** The latest known time should be lower - than the expiration timestamp in this metadata file. + than the expiration timestamp in the new targets metadata file. If so, + the new targets metadata file becomes the trusted targets metadata file. 4.5. **Perform a preorder depth-first search for metadata about the desired target, beginning with the top-level targets role.**