-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ambiguity around rotating keys and deleting metadata #71
Comments
I opened #74 to address the first two points you made and clarify what rotation means in this context, please review/comment. I will leave the last point to @lukpueh in #65. If that does not answer the question @erickt, we can move the discussion there. As for your third point, the trusted snapshot metadata will always need to be deleted after a fast-forward attack because it will list the fast-forwarded version of the timestamp or other metadata. I am not sure that this holds for the timestamp (if only snapshot is compromised, the timestamp metadata can still be trusted). However, if online keys are used for both of these roles, in practice it would make sense to rotate (revoke and replace) both timestamp and snapshot in the event of a compromise. @trishankatdatadog @JustinCappos is there another attack that is prevented by deleting both timestamp and snapshot? Either way, I think it would be safer to continue to delete both the timestamp and snapshot metadata as part of compromise recovery. |
@mnm678: Timestamp needs to be deleted, even if only snapshot was compromised, because it could list the fast-forwarded version number of snapshot. Exactly how snapshot needs to be deleted, even if only (delegated) targets were compromised. |
IIUC it should be enough, if the client only deletes the trusted timestamp, when any of timestamp, snapshot or targets had a threshold of keys removed via root. Because the client will be forced via new timestamp to fetch a new snapshot, and in turn forced via snapshot to fetch new targets metadata. However, this approach requires a PR that does for snapshot what #65 does for targets, i.e. that removes the old-to-new-snapshot version comparison, in favor of the snapshot version check via timestamp. I prefer this strategy because it seems like a cleaner separation of roles -- only timestamp should be responsible for freshness -- and thus reduces complexity. |
As described above, I think it's enough to require the client to only delete the timestamp metadata autonomously upon key rotation, because the new timestamp allows an automatic chain of updates of the rest of the metadata. Currently we only say that timestamp or snapshot "rotation" requires deleting old trusted metadata. I think we need to add targets as well. I suggest the following wording based on #74:
@mnm678, what do you think? |
This would work to prevent the fast forward attack, but I think it would make a rollback attack possible. Timestamp verification does not have the per-target rollback check that is performed by snapshot, so if this check were removed in snapshot there would be no explicit rollback protection for targets files. |
In case no keys are compromised, there still is implicit rollback protection for target files. Because timestamp specifies the latest snapshot, and snapshot specifies the latest targets. However, I realize now that my suggestion leaves rollback protection entirely to the timestamp role. That is, if we don't check directly on snapshot and targets metadata that a new version is higher than the last trusted version, then a compromise of timestamp would be enough to successfully launch rollback attacks. OTOH, if we leave these checks, a rollback attacker would have to compromise timestamp, snapshot and (delegated) targets. So I propose,
(a), (b) and (c) should be clarified in section 1.9, and (d) probably between 4.4 and 4.5. of the client workflow. @mnm678, does this make sense? |
@lukpueh That makes sense. It adds a few extra steps to the fast-forward recovery, but I think having rollback protection outside of just the timestamp roll is important. |
In section 5.1.9, it states:
There some ambiguity here:
Thanks again!
The text was updated successfully, but these errors were encountered: