Remove delegated targets fast-forward check

This removes the fast-forward check for delegated targets,
and adds an explanation of fast-forward attack recovery
for delegated targets to the snapshot fast-forward check.

Signed-off-by: Marina Moore <[email protected]>

Author: mnm678

tuf-spec.md

@@ -1320,14 +1320,14 @@ it in the next step.
 
 11. **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
+  timestamp, snapshot, targets, or delegated targets metadata. The attacker's 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)
+  version.  To recover from a fast-forward attacks after the repository has been
+  compromised and recovered, certain metadata files need to be deleted as
+  specified in this section. If a delegated targets file is subjected to a
+  fast-forward attack, the snapshot role's keys should be replaced. Please see
+  [the Mercury paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf)
   for more details on fast-forward attacks.
 
     1. **Targets recovery** If a threshold of targets keys have been
@@ -1489,18 +1489,13 @@ it in the next step.
     1. Let DELEGATEE denote the current target role TARGETS is
        delegating to.
 
-    2. **Fast-forward attack recovery.** If a threshold of
-    delegated targets keys for the current delegation are removed from the
-    TARGETS metadata, delete the trusted DELEGATEE metadata, if any, and the
-    previously trusted snapshot metadata.
-
-    3. **Check for a rollback attack via snapshot.** The version number of the
+    2. **Check for a rollback attack via snapshot.** The version number of the
     DELEGATEE metadata in the previous trusted snapshot metadata, if any, MUST
     be less than or equal to its version number in the new trusted snapshot
     metadata. If this is not the case, abort the update cycle, and report the
     potential rollback attack.
 
-    4. **Download the DELEGATEE targets metadata file**, up to either
+    3. **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
@@ -1513,40 +1508,40 @@ it in the next step.
        in the snapshot metadata file.  In either case, the client MUST write the
        file to non-volatile storage as FILENAME.EXT.
 
-    5. **Check against snapshot metadata.** The hashes (if any), and
+    4. **Check against snapshot metadata.** The hashes (if any), and
        version number of the new DELEGATEE metadata file MUST match the trusted
        snapshot metadata, if any.  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.
 
-    6. **Check for an arbitrary software attack.** The new DELEGATEE
+    5. **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.
 
-    7. **Check for a rollback attack on the DELEGATEE metadata.**
+    6. **Check for a rollback attack on the DELEGATEE metadata.**
        The version number of the trusted DELEGATEE metadata file, if any, MUST be
        less than or equal to the version number of the new DELEGATE 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.
 
-    8. **Check for a freeze attack.** The latest known time
+    7. **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.
 
-    9. If the current delegation is a multi-role delegation,
+    8. 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). Otherwise, abort the update cycle, and
        report the failure.
 
-    10. If the current delegation is a terminating delegation,
+    9. If the current delegation is a terminating delegation,
        then jump to step [[#fetch-target]].
 
-    11. Otherwise, if the current delegation is a non-terminating
+    10. Otherwise, if the current delegation is a non-terminating
        delegation, continue processing the next delegation, if any, by repeating
        the preorder depth-first search with DELEGATEE as the current TARGET role.
        Stop the search, and jump to step [[#fetch-target]]. as soon as a