Why are snapshot role hashes not provided in the timestamp role?

[lsd-cat]

From the TUF spec, 5.5.2:

Check against timestamp role’s snapshot hash. The hashes of the new snapshot metadata file MUST match the hashes, if any, listed in the trusted timestamp metadata. This is done, in part, to prevent a mix-and-match attack by man-in-the-middle attackers. It is safe to check the hashes before the signatures, because the hashes come from the timestamp role, which we have already verified in the previous step; it is also a quick way to reject bad metadata. If the hashes do not match, discard the new snapshot metadata, abort the update cycle, and report the failure.

It seems like no hashes are published https://tuf-repo-cdn.sigstore.dev/timestamp.json. They mention man-in-the-middle, but I guess the same could be achieved by a server compromise, so TLS would protect in one case but not the other. Is there a reason why this is not considered useful?

[jku]

There is an advantage to using hashes but it's not in my opinion a massive one:

• Lack of hashes does not meaningfully enable mix-and-match attacks with current TUF spec (with "consistent snapshot" feature): if repository gives the client an old snapshot, the client will refuse because the version is incorrect
• the potential protection covers the json parsing and canonicalization ( because after that point we can verify the actual signatures which are a significantly stronger protection than the hashes). This is certainly an attack surface but...
• a malicious repository could just stop using hashes whenever it wants -- there's no repository level flag that says "this repository always uses hashes". So the hash protection really only works against someone who can e.g. replace snapshot metadata with malicious data but can't for some reason do the same attack on root or timestamp metadata (which are not protected by hashes)...

So using hashes could be useful but not a game changer. The main reason hashes are not currently used (in addition to making the metadata files larger) is that maintaining the repository becomes a little more complicated with hashes -- while tuf-on-ci tool was being developed we really tried to keep it simple and did not originally implement hashes. We could consider adding that now that things seem to be working solidly.

Another reason some people might avoid the hashes is that it does prevent a use case where additional signatures are added after the metadata is published (Imagine a case where published metadata was signed by threshold of signers but not all of the signers, and then the remaining signers still want to sign) . To be fair this sounds unusual and tuf-on-ci certainly does not do this.

[lsd-cat]

Hey, thank you for the detailed explanation. I am mostly asking for both curiosity of TUF internals and being sure I implement a reasonably secure client. This really helps.