Which attacks do TUF's snapshot and timestamp metadata each prevent?

## The threat model these two roles answer Signatures alone answer "did an authorised party say this?". They do not answer "is this what that party is saying *now*?", and they do not answer "do these files belong together?". An attacker who has taken over a mirror, a regional distribution point, or the network path in front of a client may hold no signing keys at all and still do real damage, purely by choosing which correctly signed bytes to hand over. TUF names three such attacks, and snapshot and timestamp exist to close them. ## Rollback A rollback attack serves an older, still-validly-signed version of metadata or an artifact, pushing the client back onto software with a known flaw. The primary defence is client state: a TUF client records the version number of every metadata file it has accepted and refuses anything with a lower version number. That is strong — but only relative to what the client has already seen. A freshly imaged machine, or one that has been offline for months, has no high-water mark to compare against, so version checks alone do not carry it. ## Mix-and-match This is the attack snapshot is specifically for. In a repository with many targets metadata files — typically one per delegated namespace — each file is signed independently. Without a role that binds them, an intermediary can serve version 40 of one namespace's targets alongside version 12 of another's, every signature valid, in a combination that never existed upstream. Consider a regional distributor sitting between a central repository and an internal fleet: by replaying a mix of older individually-valid metadata files it can construct a dependency set that no upstream release ever shipped, and the audit trail afterwards will show only valid signatures. Snapshot metadata defeats this by signing, as one statement, the version number of *every* targets file that is current at that instant. The client accepts the set or nothing. ## Freeze (and indefinite freeze) The hardest case is the attacker who alters nothing. A compromised distribution host can simply keep serving the last complete, correct, fully signed set forever. Every signature verifies; every version number is the highest the client has ever seen; the client concludes it is up to date and stops asking. Picture an over-the-air update service for a warehouse robot fleet whose update host has been taken over by someone who cannot mint new metadata: keeping every robot pinned to the last release with a known motion-control defect is a safety incident, and nothing about the cryptography looks wrong. TUF's answer is that freshness has to be an *assertion someone signs*, not an absence of evidence. Every metadata file carries an `expires` timestamp, and clients reject expired metadata outright. Timestamp metadata is re-signed on a short cycle chosen by the repository operator, so the attack window is bounded by that cycle rather than being open-ended. Crucially, the failure is loud: past expiry the client stops accepting the stale set and reports an error, converting a silent freeze into a visible denial of service. That is a deliberate trade — TUF prefers a client that says "I cannot verify anything current" to one that quietly runs vulnerable software believing it is patched. Expiry here is a freshness contract, not certificate lifetime and not a cache hint. Long expiries on the roles that change rarely (root) and short expiries on the role that exists only to prove liveness (timestamp) are the intended shape. ## How the two combine Timestamp names the version *and hash* of the current snapshot, so an attacker cannot mix a fresh timestamp with an old snapshot either. The chain is: timestamp proves the answer is recent; snapshot proves the targets versions are mutually consistent; targets proves the artifact bytes are the intended ones. Remove timestamp and consistency is preserved but staleness becomes invisible. Remove snapshot and each file is fresh-ish but the set is assemblable at will. ## Related protections in the same layer Two smaller ones often come up as follow-ups. Metadata records the expected **length** as well as the hash of the file it points to, so a hostile server cannot stream an endless response at a client to exhaust it — the download is capped and a mismatch is rejected. And when a role's keys are replaced after a compromise, TUF expects version numbers to be reset, so an attacker who published an absurdly high version number cannot lock legitimate future versions out forever. ## What these roles do not do Neither role protects against an attacker who holds the offline targets key: that is authorship, and it is a different failure. Neither role makes a vulnerable dependency safe. Their entire job is to ensure the client sees a *current, coherent* view of what the repository actually publishes.