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.

[pattivacek]

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).

I've been wondering about this for ages: there are subtle differences between TUF and Uptane, where I would assume they should be identical. I can't say if that's actually desirable or possible, but it gets confusing when changes are made to one but not the other.

[JustinCappos]

I'd prefer to have TUF as effectively a subset of Uptane. (This might be modulo a few TAPs.)

…

On Mon, Dec 5, 2022 at 3:05 AM Patti Vacek ***@***.***> wrote: 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). I've been wondering about this for ages: there are subtle differences between TUF and Uptane, where I would assume they should be identical. I can't say if that's actually desirable or possible, but it gets confusing when changes are made to one but not the other. — Reply to this email directly, view it on GitHub <#92 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD7XDWYHPBWAM5QBRETWLWO5VANCNFSM4WWCXLZA> . You are receiving this because you commented.Message ID: ***@***.***>

[pattivacek]

I'd prefer to have TUF as effectively a subset of Uptane.

I 100% agree! That would make life so much easier for implementers. In fact, I would love it if used the same text, formatting, etc. to the extent possible. If not, then I think Uptane sections that are derived from TUF should contain explicit references to the TUF section that it was derived from.

[jhdalek55]

@JustinCappos can you expand on how TUF could be made "effectively a subset of Uptane"? This sounds like a fundamental repositioning of the two projects that we should make a priority in the New Year. Some guidance in moving this idea forward would be appreciated.

[jhdalek55]

I believe this TUF/Uptane positioning piece should be moved to its own issue as it certainly is larger than the "metadata freshness" check that the original question asks.

[jhdalek55]

@JustinCappos has opened a new issue (Issue #141 ) to address the TUF/Uptane positioning question. As for the original question, about alternatives to time checks to confirm freshness, is this a question we want to engage with, or should we just let it be for now?

[jhdalek55]

Consider this for 2.2