theupdateframework
Prevent promiscuous delegations from violating security
Summary
Items 4.5.1-4.5.9 in the Detailed Workflows section (5.1) of the specification do not instruct the implementer in how to "process" the delegated role files, and there are tempting dangers here that must be averted.
Details
Consider this scenario (again... I know...):
- Targets delegates
/a/\*to A - Targets delegates
/b/\*to B - A delegates
/a/\*to C, expecting threshold 1, key kA - B delegates
/b/\*to C, expecting threshold 1, key kB - Targets, A, and B, are signed by all expected keys.
- C is signed by kA, but not by kB
Now, the client:
- updates top-level metadata, retrieving Root, Timestamp, Snapshot, and Targets.
- tries to get target info for target
/a/foo.txt.- gets A.json
- validates A.json based on the delegation info in Targets.json: valid
- gets C.json
- validates C.json based on the delegation info in A.json: valid, C.json was correctly signed by kA ((this step is not quite clear in the spec in 5.1:4.5.1+, but certainly implied))
- tries to get target info for target
/b/bar.txt- gets B.json
- validates B.json based on the delegation info in Targets.json: valid
- regardless of whether or not C.json is cached, or whether we know that C.json has previously been validated (on a different delegation pathway, seeking a different target), MUST perform validation again, making sure that C.json was correctly signed by kB (and not just kA, as we validated before).
At that last step, it is likely that the client has cached C.json, kept it in a way that signals that it has been validated, in much the way that the top-level roles should be kept if and only if they are validated. The prior validation expecting kA cannot be allowed to pre-empt the validation expecting kB. This should probably be clear in the spec, as it is probably too easy to fail to catch. It requires that the implementer carefully consider the implications of promiscuous delegations.
Fix
A possible fix is to consider adding, between the 2nd and 3rd sentences in 5.1:4.5.1 in the spec, something like "Check the signature on the delegated role file to make sure that it satisfies the requirements (threshold, keys, etc.) of the delegation that brought us to it." A little more rearrangement might be better, but this would probably work.
