Timestamp rollback check should also check for snapshot rollback

This updates section 5.2.2 to also state that when updating the
`timestamp` role, we should also check to make sure new `timestamp`
role's `snapshot` version is greater than or equal to the trusted
`timestamp`'s `snapshot` version.

This is an important check when initializing a TUF database. For
example, say we had the following TUF metadata:

* `root`, which has signed all the below metadata
* `snapshot` version 1, which points at a target with a compromised package
* `snapshot` version 2, which points at a target with a fixed package
* `timestamp` version 2, which points at snapshot version 2

Lets say an attacker has stolen the `timestamp` keys, they could forge a
new `timestamp` role which points at `snapshot` version 1. In the normal
case where we have a fully initialized TUF database with a trusted
`root`, `timestamp` version 2, and `snapshot` version 2, this malicious
timestamp would get rejected because of the section 5.3.2 snapshot
rollback check.

However, consider a partially initialized repository, where we only
trust `root` and `timestamp` version 2, and for some reason were not
able to fetch the rest of the metadata. In this setup, we won't have a
trusted `snapshot` available for the 5.3.2 rollback check. Thus, the
rollback attack would succeed.

To fix this, I've adopted the language in section 5.3.3, where when
updating the `snapshot` role, we do explicitly check to see if the listed
`targets` or any delegated `targets` version is always greater than or
equal to the trusted versions of those roles.

Author: erickt

tuf-spec.md

@@ -1158,11 +1158,22 @@ as FILENAME.EXT.
   file.  If the new timestamp metadata file is not properly signed, discard it,
   abort the update cycle, and report the signature failure.
 
-  * **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 the new timestamp metadata file.  If the new timestamp metadata
-  file is older than the trusted timestamp metadata file, discard it, abort the
-  update cycle, and report the potential rollback attack.
+  * **2.2**. **Check for a rollback attack.**
+
+    * **3.3.1**. Note that the trusted timestamp metadata file may be checked
+    for authenticity, but its expiration does not matter for the following
+    purposes.
+
+    * **2.2.2**. The version number of the trusted timestamp metadata file, if
+    any, must be less than or equal to the version number of the new timestamp
+    metadata file.  If the new timestamp metadata file is older than the
+    trusted timestamp metadata file, discard it, abort the update cycle, and
+    report the potential rollback attack.
+
+    * **2.2.3**. The version number of the snapshot metadata file in the
+    trusted timestamp metadata file, if any, MUST be less than or equal to its
+    version number in the new timestamp metadata file.  If not, discard the new
+    timestamp metadadata file, abort the update cycle, and report the failure.
 
   * **2.3**. **Check for a freeze attack.** The latest known time should be
   lower than the expiration timestamp in the new timestamp metadata file.  If
@@ -1210,7 +1221,7 @@ non-volatile storage as FILENAME.EXT.
     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 snaphot metadadata file, abort the update cycle,
+    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