Fast-forward recovery and rollback prevention

tuf-spec.md

@@ -214,7 +214,7 @@ repo](https://github.com/theupdateframework/specification/issues).
 
       * This version (1.0.0) of the specification adheres to the following TAPS:
 
-        - [TAP 3](https://github.com/theupdateframework/taps/blob/master/tap3.md): 
+        - [TAP 3](https://github.com/theupdateframework/taps/blob/master/tap3.md):
             Multi Role Delegations
         - [TAP 4](https://github.com/theupdateframework/taps/blob/master/tap4.md):
             Multiple Repository Consensus on entrusted targets
@@ -1116,16 +1116,26 @@ 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
-  paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf)
+  * **1.9**. **Fast-forward attack recovery** 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. 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.
 
+    * **1.9.1**. **Targets recovery** If a threshold of targets keys are removed
+    from the root metadata, delete the old top-level targets, snapshot, and
+    timestamp metadata files.
+
+    * **1.9.2**. **Snapshot recovery** If a threshold of snapshot keys are
+    removed from the root metadata, delete the old snapshot and timestamp
+    metadata files.
+
+    * **1.9.3**. **Timestamp recovery** If a threshold of timestamp keys are
+    removed from the 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).
 
@@ -1222,36 +1232,50 @@ 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
+  * **4.5**. **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.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**. **Fast-forward attack recovery** If a threshold of
+      delegated targets keys for the current delegation are removed from the
+      delegating targets metadata (either the top-level targets or delegated
+      targets metadata that provided the current delegation), delete the old
+      delegated targets metadata for the current delegation along with the
+      snapshot and timestamp metadata. Skip this step if the current delegation
+      is the top-level targets role.
+
+      * **4.5.2.1**. 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).
 
-      * **4.4.2.2**. If the current delegation is a terminating delegation,
+      * **4.5.2.2**. 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
+      * **4.5.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.
 
@@ -1381,7 +1405,7 @@ non-volatile storage as FILENAME.EXT.
     snapshots are not written by the repository, then the attribute may either
     be left unspecified or be set to the False value.  Otherwise, it must be
     set to the True value.
-    
+
     Regardless of whether consistent snapshots are ever used or not, all
     released versions of root metadata files should always be provided
     so that outdated clients can update to the latest available root.