Add TAP enabling a verifiable chain of TUF metadata versions #157
Conversation
|
Hash-chaining(?): I dig it. I think we informally tawked about this idea with Mercury... |
It would help detect forking attacks, but only in conjunction with something like an append-only log (e.g., Rekor, Bitcoin blockchain), or a gossip protocol. |
Signed-off-by: Aditya Sirish <[email protected]>
adityasaky
force-pushed
the
metadata-archival-tap
branch
from
ece5279 to
0ca11f0
Compare
There was a problem hiding this comment.
Thank you for putting this together! We (the TAF team) have not put too much thought into what would happen if snapshot keys got revoked and it makes a lot of sense for a currently valid snapshot file to store hashes of older ones. Just shared some thoughts that crossed my mind while reading this, hope they make sense.
| important to consider what the meaning of validity of a since-replaced metadata | ||
| file is when examined at some point in the future. | ||
|
|
||
| ## Archiving Revoked Snapshot Roles |
There was a problem hiding this comment.
How do you know which Root metadata to use for old Snapshot metadata?
There was a problem hiding this comment.
Do you mean to identify which keys to use to verify signatures of a particular old Snapshot metadata file?
There was a problem hiding this comment.
Yes: how do you know which root metadata file is associated with which snapshot metadata files?
There was a problem hiding this comment.
I should clarify that the signatures on the older snapshot metadata files aren't verified (and it may not be possible to verify them anymore). Some older metadata is trusted to be correct at that time because it was the one the next version pointed to when the next version was verifiable using its corresponding root and so on. Tracing back from the current snapshot metadata (whose signatures you can verify using the current root) means you have a way of validating if a prior version was ever the right snapshot metadata. Does this help?
There was a problem hiding this comment.
The chain back from the current to whatever previous snapsht metadata gives me some guarantees it's trustworthy, but not completely, because what if I want to go deeper and actually verify targets in there? How do I know which keys to use? That's why clients would need to know which root keys to use. Does this mean that snapshot should list the root again? @mnm678 @JustinCappos
There was a problem hiding this comment.
If there are use cases for this, recording the root should be fine. We should more strongly emphasize that the chain shouldn't include illegitimate snapshot metadata files signed after a key compromise in this case.
There was a problem hiding this comment.
(Conversation with @mnm678) Perhaps the snapshot could hint at the root by storing only the version number rather than the hash of the root. The snapshot role shouldn't be trusted to unambiguously identify the root metadata.
There was a problem hiding this comment.
Yes, version number is fine. Now, another problem is: should clients trust the legitimacy of the snapshot chain (and hence the root metadata), and if they don't, how can they verify that a snapshot is pointing to the right, unexpired root?
| when looking back, it is only possible to claim some Snapshot metadata file was | ||
| legitimate when starting from the current legitimate role. | ||
|
|
||
| # Security Analysis |
There was a problem hiding this comment.
The TAP might also like to briefly discuss how Transparent Logs (e.g., gosumdb, Rekor) can be used to detect forking attacks of the Snapshot metadata (i.e., that the repository "lied" about which Snapshot metadata was issued around that time).
Signed-off-by: Renata <[email protected]>
Signed-off-by: Aditya Sirish <[email protected]>
Signed-off-by: Aditya Sirish <[email protected]>
Signed-off-by: Aditya Sirish <[email protected]>
Signed-off-by: Aditya Sirish <[email protected]>
adityasaky
force-pushed
the
metadata-archival-tap
branch
from
98dadac to
44695a7
Compare
Signed-off-by: Aditya Sirish <[email protected]>
adityasaky
force-pushed
the
metadata-archival-tap
branch
from
d220fed to
5606679
Compare
There was a problem hiding this comment.
Overall this feels like adding complexity to the spec for fairly small benefit:
- Trishank already brought up transparency logs: if you really need to know when things were made available, something like that sounds more useful
- for storing and auditing valid repository states, just archiving all metadata versions seems like a simpler solution (obviously you need a bit of software to validate a specific old repository version based on that archive, but that should not be a massive job)
EDIT: That last bullet point was meant to be more like a question - am I missing something or would that approach work for this use case?
| were not modified or replaced. This TAP proposes that new Snapshot files must | ||
| record the currently active Root role and the previous Snapshot file, creating a | ||
| traversable chain of all Snapshot metadata files that were ever valid for the | ||
| repository. This way, at any point in time, the "current" Snapshot role can be | ||
| used to work back to the original Snapshot role, essentially enabling the | ||
| examination of every valid state the TUF repository was at. |
There was a problem hiding this comment.
I think the claims in this section are too extensive: Snapshots (and by extensions targets metadata), even when correctly signed, were part of a valid repository only if they were included in a correctly signed timestamp.
|
|
||
| # Backwards Compatibility | ||
|
|
||
| This TAP has no impact on backwards compatibility. This is because TUF's update |
There was a problem hiding this comment.
The specification defines the snapshot "meta" contents as top-level targets metadata and delegated targets metadata [filenames]. I wouldn't expect practical incompatibilities considering how it is used but strictly speaking this does not feel compatible.
| Second, by making prior states verifiable, we gain the ability to check if one | ||
| or more Targets metadata files were ever valid, concurrently or otherwise. | ||
| Essentially, this property establishes a verifiable archive of all Targets | ||
| metadata issued by the TUF repository. One example of a system that needs to | ||
| verify old metadata is | ||
| [The Archival Framework (TAF)](https://github.com/openlawlibrary/taf), whose | ||
| main goal is to protect digital law. After laws are published, they need to be | ||
| authenticable for decades or even centuries. As such, the semantics described in | ||
| this TAP enable the auditability of all TUF metadata issued by the repository. |
There was a problem hiding this comment.
Couldn't this level of auditability could be reached by just storing all versions of metadata that are created? What is the advantage of this proposal in comparison?
There was a problem hiding this comment.
I don't quite understand the purpose of the root role in this proposal. If I ask snapshot to tell me what key it has been signed with, doesn't snapshot become its own (much weaker) root of trust? Even if I walk the chain of root metadata until the version snapshot hints at, that version of root could have been rendered meaningless by a subsequent version of root. I think the freshness of root metadata is indeed crucial.
As an example: snapshot v1 tells me that it has been signed with keys in root v1, but there already is a root v2, which tells me to not trust any keys from root v1 anymore. Now what's the value of verifying any signatures with keys from root v1?
As for chaining snapshots, can't we just use the already existent chaining properties of TUF metadata? That is: strictly incrementing timestamps - it doesn't even have to be every timestamp, only the ones that bump snapshot --, where each timestamp is the root of a consistent snapshot tree of metadata.
|
Thanks for the reviews everyone! We've been discussing it and think that there are several valid points here re whether this should utilize mechanisms built into TUF or not. For now, I'm going to close this PR and withdraw this TAP. We'll focus on its bigger sibling #156 and re-think if we need the mechanisms described in this one. |
Overview: The idea with this TAP is to provide a way to verifiably track back from the latest metadata and examine all previous legitimate versions of Snapshot metadata. This in turn acts as an archive of all the legitimate Targets metadata issued in the repository.
Discussion: I'm looking for overall feedback on this approach and any thoughts folks may have. It's a rather small TAP but enables in-band recording of historical metadata that is important for some auditability specific use cases.