Do we always need to download snapshot and targets?

[erickt]

I'm updating rust-tuf to work with TUF-1.0.30. As part of reading through the spec, I that @rdimitrov changed the spec in #209 to allow us to exit the update-cycle early in update-timestamp 5.4.3.1. Should we apply this same logic to snapshots and targets?

rust-tuf currently implements this, where it will exit early if:

• When updating the snapshot metadata, check if the trusted timestamp role's snapshot version matches the trusted snapshot version, and has the correct hash value, if present.
• When updating the targets metadata, check if the trusted snapshot role's targets version matches the trusted targets version, and has the correct hash value, if present.
• When updating a delegated targets metadata, check if the delegating targets role's version matches the trusted delegated targets version, and has the correct hash value, if present.

Is this optimization allowed? If so, should we describe it in the spec? If not, why is this dangerous?

[JustinCappos]

Thanks for the feedback / question!

The timestamp role contains the hash, version, and size of the snapshot. These should either all match, or all fail together if the information is mismatched.

• When updating a delegated targets metadata, check if the delegating targets role's version matches the trusted delegated targets version, and has the correct hash value, if present.

The snapshot role contains the version of all of the targets metadata files (top-level or delegated). So in this case, I think you may mean to say snapshot file (or I am confused about what you are saying).

On Thu, May 19, 2022 at 1:29 PM Erick Tryzelaar @.***> wrote:

I'm updating rust-tuf to work with TUF-1.0.30. As part of reading through the spec, I that @rdimitrov https://github.com/rdimitrov changed the spec in #209 https://github.com/theupdateframework/specification/pull/209 to allow us to exit the update-cycle early in update-timestamp 5.4.3.1 https://theupdateframework.github.io/specification/latest/#update-timestamp. Should we apply this same logic to snapshots and targets?

rust-tuf currently implements this, where it will exit early if:

• When updating the snapshot metadata, check if the trusted timestamp role's snapshot version matches the trusted snapshot version, and has the correct hash value, if present.
• When updating the targets metadata, check if the trusted snapshot role's targets version matches the trusted targets version, and has the correct hash value, if present.
• When updating a delegated targets metadata, check if the delegating targets role's version matches the trusted delegated targets version, and has the correct hash value, if present.

Is this optimization allowed? If so, should we describe it in the spec? If not, why is this dangerous?

— Reply to this email directly, view it on GitHub https://github.com/theupdateframework/specification/issues/227, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD3I2XLRZMTTKRTSKHLVKXGTZANCNFSM5WK7BZ7Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[joshuagl]

Yes, I would say this optimisation is allowed. If the metadata on-disk matches what is described (version, hashes) by the describing^ verified/trusted metadata (timestamp->snapshot, snapshot->targets), we do not need to download the metadata.

python-tuf also implements these optimisations.

^ Do we have a good term for this?

[erickt]

Since it’s now optional for us to have the hashes of the metadata, do you still think this optimization is safe if we don’t have hashes? The metadata signatures should still protect us from forgery.

[erickt]

The snapshot role contains the version of all of the targets metadata files (top-level or delegated). So in this case, I think you may mean to say snapshot file (or I am confused about what you are saying).

Oops, yeah I meant the snapshot file.

[JustinCappos]

Short answer: Yes, it is safe to only have version numbers of targets files listed in snapshot.

Long answer: https://www.usenix.org/system/files/conference/atc17/atc17-kuppusamy.pdf

On Thu, May 19, 2022 at 10:05 PM Erick Tryzelaar @.***> wrote:

Since it’s now optional for us to have the hashes of the metadata, do you still think this optimization is safe if we don’t have hashes? The metadata signatures should still protect us from forgery.

— Reply to this email directly, view it on GitHub https://github.com/theupdateframework/specification/issues/227#issuecomment-1131736355, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD7HYDJP7UYBFDNR4XDVKZDDNANCNFSM5WK7BZ7Q . You are receiving this because you commented.Message ID: @.***>

[lukpueh]

... describing^ ... metadata (timestamp->snapshot, snapshot->targets) ...

^ Do we have a good term for this?

I have wondered that too. I think I've seen "signs metadata for" in some TUF diagrams. If we find a good term, we should put it in a glossary.

[erickt]

FYI I started exploring this in #226.

I have wondered that too. I think I've seen "signs metadata for" in some TUF diagrams. If we find a good term, we should put it in a glossary.

@joshuagl / @lukpueh - In rust-tuf, we call this MetadataDescription, but it always felt a little awkward. Maybe "Descriptor", although that also seems a little vague.