Outside of time checks, are there other ways to determine metadata freshness?

[jhdalek55]

This is a spin-off from Issue #45. While that issue focuses on the effects of a Time Server key compromise, the original author had speculated on the thread about whether an implementer could use other methods to determine if metadata is malicious or not. This thread solicits suggestions for what methods could be proposed that would not serve this function without introducing new threats.

[jhdalek55]

There has been no comment on this Issue since it was introduced in January. What do we need to move this forward?

[mnm678]

There are other ways that metadata can be malicious, but Uptane leaves that up to the developers/testing environment. If a vulnerability is discovered, metadata can be revoked so that future updates do not use the compromised image.

I think that the detection of malware is out of scope for Uptane, but we should ensure that the deployment pages make it clear what implementers can do if malware is discovered.

[jhdalek55]

Should we add "detection of malware" to the "non-goals for the Standard"? And, what would implementers do in this case?

[mnm678]

And, what would implementers do in this case?

If a role dev, which was delegated from the top-level targets, issues metadata that includes malware, implementers could do one of two things, depending on how the malware ended up being deployed, and who is able to respond:

• dev can issue new metadata that replaces/removes the malware. Snapshot and timestamp will ensure that clients only use this new metadata, and not the metadata that includes malware.
• The top-level targets can issue new metadata that removes dev.

If dev's signing keys were compromised, the top-level targets role could also replace these compromised keys.

These steps should be taken on both repositories.

[jhdalek55]

This issue deals with the use of secure monotonic counters, a tamper-resistant counter embedded in a device whose value, once incremented, cannot be reverted back to a previous value.

[jhdalek55]

@mnm678 since you have already commented on this, can you go ahead and make the suggested changes?

[jhdalek55]

We are holding off on dealing with this issue for now. It will not be considered for 2.0.0

[JustinCappos]

While not urgent and not related to the time server, some recent TUF specification / implementation issues are loosely related to the concept of doing further verification. We should take a look at the Uptane spec and try to reconcile it with TUF to ensure we are applying the same checks everywhere (unless there is a reason not to).

theupdateframework/specification#227
theupdateframework/go-tuf#293
theupdateframework/go-tuf#292

[jhdalek55]

This is helpful. I'll take a look and try to set up as an issue(s) that we can use for future discussions.

[jhdalek55]

Refer to this as a freshness issue instead. Maybe rephrase this.

[jhdalek55]

There are a few unresolved components of this issue to address.

1. Justin's suggestion about looking at the Uptane spec and trying "to reconcile it with TUF to ensure we are applying the same checks everywhere (unless there is a reason not to)" is a good one and it's one we should resolve to do sooner rather than later. I can make this one of my early 2023 projects but it would be helpful to have someone with more technical expertise do a pass as well.

2. I re-titled the issue to make this a freshness issue, as we had discussed over the summer. But, does the question itself require a re-write to better clarify what we are seeking to address? I think, like other issues, the focus has drifted and we need to remind ourself of what quandary we were seeking to resolve.