diff --git a/tuf-spec.md b/tuf-spec.md
index f24d683..da8792d 100644
--- a/tuf-spec.md
+++ b/tuf-spec.md
@@ -1133,15 +1133,34 @@ repo](https://github.com/theupdateframework/specification/issues).
cycle, report the potential freeze attack. On the next update cycle, begin
at step 0 and version N of the root metadata file.
- * **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, (2)
- the snapshot metadata, and / or (3) the targets, or a delegated targets,
- metadata file in the snapshot metadata. Please see [the Mercury
+ * **1.9**. **Fast-forward attack recovery** A _fast-forward attack_ happens
+ when attackers arbitrarily increase the version numbers in any of the
+ timestamp, snapshot, targets, or delegated targets metadata. The attacker goal
+ is to cause clients to refuse to update the metadata later because the attacker's
+ listed metadata version number (possibly MAX_INT) is greater than the new valid
+ version. To recover from
+ fast-forward attacks after the repository has been compromised and recovered,
+ certain metadata files need to be deleted as specified in this section.
+ Please see [the Mercury
paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf)
- for more details.
+ for more details on fast-forward attacks.
+
+ * **1.9.1**. **Targets recovery** If a threshold of targets keys have been
+ removed in the new trusted root metadata compared to the previous trusted
+ root metadata, delete the old top-level targets and snapshot metadata
+ files. Note that delegated targets are suceptible to fast forward attacks,
+ because snapshot must be checked before a key rotation in the delegating
+ target role is known to the client. To fix this, nuke delegation or make
+ repository rotate the the snapshot key.
+
+ * **1.9.2**. **Snapshot recovery** If a threshold of snapshot keys have
+ been removed in the new trusted root metadata compared to the previous
+ trusted root metadata, delete the old snapshot and timestamp metadata
+ files.
+
+ * **1.9.3**. **Timestamp recovery** If a threshold of timestamp keys have
+ been removed from the new trusted root metadata compared to the previous
+ trusted root metadata, delete the old timestamp metadata file.
* **1.10**. **Set whether consistent snapshots are used as per the trusted
root metadata file** (see Section 4.3).
@@ -1207,14 +1226,13 @@ non-volatile storage as FILENAME.EXT.
metadata file, discard it, abort the update cycle, and report the potential
rollback attack.
- * **3.3.2**. The version number of the targets metadata file, and all
- delegated 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 trusted snapshot metadata file, if any, MUST continue to be
- listed in the new snapshot metadata file. If any of these conditions are
- not met, discard the new snapshot metadadata file, abort the update cycle,
- and report the failure.
+ * **3.3.2**. The version number of all targets metadata files in
+ the trusted snapshot metadata file, if any, MUST be less than or equal to
+ their version numbers in the new snapshot metadata file. Furthermore, any
+ targets metadata filename that was listed in the trusted snapshot metadata
+ file, if any, MUST continue to be listed in the new snapshot metadata file.
+ If any of these conditions are not met, discard the new snapshot metadadata
+ file, abort the update cycle, and report the failure.
* **3.4**. **Check for a freeze attack.** The latest known time should be
lower than the expiration timestamp in the new snapshot metadata file. If
@@ -1245,38 +1263,86 @@ non-volatile storage as FILENAME.EXT.
trusted root metadata file. If the new targets metadata file is not signed
as required, discard it, abort the update cycle, and report the failure.
- * **4.3**. **Check for a freeze attack.** The latest known time should be
+ * **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 the new targets metadata file. If the new targets metadata file is
+ older than the trusted targets metadata file, discard it, abort the update
+ cycle, and report the potential rollback attack.
+
+ * **4.4**. **Check for a freeze attack.** The latest known time should be
lower than the expiration timestamp in the new targets metadata file. If so,
the new targets metadata file becomes the trusted targets metadata file. If
the new targets metadata file is expired, discard it, abort the update cycle,
and report the potential freeze attack.
- * **4.4**. **Perform a preorder depth-first search for metadata about the
- desired target, beginning with the top-level targets role.** Note: If
- any metadata requested in steps 4.4.1 - 4.4.2.3 cannot be downloaded nor
- validated, end the search and report that the target cannot be found.
+ * **4.5**. **Perform a preorder depth-first search for metadata about the
+ desired target.** Let TARGETS be the current metadata, beginning with the
+ top-level targets metadata role.
- * **4.4.1**. If this role has been visited before, then skip this role (so
+ * **4.5.1**. If this role has been visited before, then skip this role (so
that cycles in the delegation graph are avoided). Otherwise, if an
application-specific maximum number of roles have been visited, then go to
step 5 (so that attackers cannot cause the client to waste excessive
bandwidth or time). Otherwise, if this role contains metadata about the
desired target, then go to step 5.
- * **4.4.2**. Otherwise, recursively search the list of delegations in order
+ * **4.5.2**. Otherwise, recursively search the list of delegations in order
of appearance.
- * **4.4.2.1**. If the current delegation is a multi-role delegation,
+ * **4.5.2.1**. Let DELEGATEE denote the current target role TARGETS is
+ delegating to.
+
+ * **4.5.2.2**. **Download the DELEGATEE targets metadata file**, up to either
+ the number of bytes specified in the snapshot metadata file, or some Z
+ number of bytes. The value for Z is set by the authors of the application
+ using TUF. For example, Z may be tens of kilobytes. IF DELEGATEE cannot be
+ found, end the search and report the target cannot be found. If
+ consistent snapshots are not used (see Section 7), then the filename used
+ to download the targets metadata file is of the fixed form FILENAME.EXT
+ (e.g., delegated_role.json). Otherwise, the filename is of the form
+ VERSION_NUMBER.FILENAME.EXT (e.g., 42.delegated_role.json), where
+ VERSION_NUMBER is the version number of the DELEGATEE metadata file listed
+ in the snapshot metadata file. In either case, the client MUST write the
+ file to non-volatile storage as FILENAME.EXT.
+
+ * **4.5.2.3**. **Check against snapshot metadata.** The hashes and
+ version number of the new DELEGATEE metadata file MUST match the hashes
+ (if any) and version number listed in the trusted snapshot metadata. This
+ is done, in part, to prevent a mix-and-match attack by man-in-the-middle
+ attackers. If the new DELEGATEE metadata file does not match, abort the
+ update cycle, and report the failure.
+
+ * **4.5.2.4**. **Check for an arbitrary software attack.** The new DELEGATEE
+ metadata file MUST have been signed by a threshold of keys specified in the
+ TARGETS metadata file. If the new DELEGATEE metadata file is not signed
+ as required, abort the update cycle, and report the failure.
+
+ * **4.5.2.5**. **Check for a rollback attack.**
+ The version number of the trusted DELEGATEE metadata file, if any, MUST be
+ less than or equal to the version number of the new DELEGATEE metadata
+ file. If the new DELEGATEE metadata file is older than the trusted
+ DELEGATEE metadata file abort the update cycle, and report the potential
+ rollback attack.
+
+ * **4.5.2.6**. **Check for a freeze attack.** The latest known time
+ should be lower than the expiration timestamp in the new DELEGATEE
+ metadata file. If so, the new DELEGATEE file becomes the trusted DELEGATEE
+ file. If the new DELEGATEE metadata file is expired, abort the update
+ cycle, and report the potential freeze attack.
+
+ * **4.5.2.7**. If the current delegation is a multi-role delegation,
recursively visit each role, and check that each has signed exactly the
same non-custom metadata (i.e., length and hashes) about the target (or
- the lack of any such metadata).
+ the lack of any such metadata). Otherwise, abort the update cycle, and
+ report the failure.
- * **4.4.2.2**. If the current delegation is a terminating delegation,
+ * **4.5.2.8**. If the current delegation is a terminating delegation,
then jump to step 5.
- * **4.4.2.3**. Otherwise, if the current delegation is a non-terminating
- delegation, continue processing the next delegation, if any. Stop the
- search, and jump to step 5 as soon as a delegation returns a result.
+ * **4.5.2.9**. Otherwise, if the current delegation is a non-terminating
+ delegation, continue processing the next delegation, if any, by repeating
+ step 4.5 with DELEGATEE as the current TARGET role. Stop the search, and
+ jump to step 5 as soon as a delegation returns a result.
**5**. **Verify the desired target against its targets metadata**.