TUF client workflow - Do we need to update roots first?

[haydentherapper]

Description

https://theupdateframework.github.io/specification/latest/#update-root notes that the root should be updated before fetching the timestamp. Should we do the same? Currently, we initialize from the local cache rather than make any network calls.

@asraa

[asraa]

Should this be in a client repository?

If you're speaking of the timestmap.json check for cache validity: note that this isn't part of the TUF client workflow start, this is a decider on starting the TUF update or not.

[asraa]

I think though, Sigstore deployments and clients are in a lot of different environments, and some may prefer to configure WHEN to perform the TUF client workflow. See this doc for the proposed cache-ability and configurability and the justification for that choice: https://docs.google.com/document/d/1QWBvpwYxOy9njAmd8vpizNQpPti9rd5ugVhji0r3T4c/edit#

[joshuagl]

Yes, we should update root before we fetch and verify timestamp. We need to better define how often Sigstore clients should run the TUF client workflow, would be good to get your feedback on the doc Asra linked to.

[haydentherapper]

Yea, didn't know if I should put this in sigstore/sigstore or here, I'd rather just discuss here cause this is where most TUF work happens now. This is specifically about https://github.com/sigstore/sigstore/blob/main/pkg/tuf/client.go

Is there any risk with the current client not checking for updated roots first?

[joshuagl]

There is a risk, yes. If we update the TUF metadata, whether due to a scheduled root update or a proactive rotation of a compromised key, then a cosign client which already has a cached copy of timestamp will not know about the rotation until the locally cached timestamp has expired.

We should do something different. The doc Asra linked to suggests that by default a client will at least check for updates every 3 days (aiming to reduce that to every day) and that a client should be able to both 1) require a metadata update on every invocation and 2) using the cached data until the timestamp has expired – this is how cosign works today but the design suggests this should be configurable and default to not using this behaviour.

[asraa]

default to not using this behaviour.

+1 This might address your concern @haydentherapper : I think the issue context is likely around the SCT rotation and how long-lived clients aren't updating proactively.

Is there any risk with the current client not checking for updated roots first?

Santiago put it aptly that this default and not proactively initiating the TUF update is effectively a "freeze attack" for those days.