TUF client update happens only when timestamp expires

[rdimitrov]

Description

The following issue affects the TUF client implemented in sigstore/sigstore/pkg/tuf.

An application using the TUF client from sigstore/pkg/tuf cannot ensure it has the latest trusted TUF state (metadata files) unless its timestamp expires or the user manually clears its cache.

The logic here means the state of the TUF client is only updated:

• if it’s a forced update (which happens only during cosign initialize for example)
  or
• its Timestamp metadata has expired

The issue is about the second use case as this directly affects the client update workflow described in the TUF specification and thus undermines what TUF promises.

In case of a vulnerability in the trusted root repository affecting its metadata and/or its target files, client applications (i.e. cosign, gitsign, etc.) will not be able to tell there was a problem and, even if they knew, they will not be able to update their TUF metadata. That is even if the trusted root repository was already recovered by generating new metadata files/targets.

The client will take into account the updated metadata not until either its cached timestamp expires or the user clears its cache/reinitialize manually.

The impact is that existing sigstore/pkg/tuf client applications can ensure their metadata(thus their target files/keys) is up-to-date probably only once a week (when their Timestamp expires). If exploited, the possible impact can range depending on the impact of having malicious TUF metadata and target files(keys for Rekor, Fulcio, etc.) used within a client application.

Version

<= 1.6.2

[bobcallaway]

@haydentherapper @asraa

[haydentherapper]

Copying in an edited response from Asra from an offline discussion:

"This was 'working as intended' due to feedback that people didn't want to constantly update their TUF roots. Now with the project more mature, we've recommended instead that in airgapped environments people handle their TUF root mirror updates by themselves depending on their own security posture.

For now, we've recommended other clients DON'T repeat this behavior (so sigstore-python will always update).

There's a bunch of discussion about it in this doc https://docs.google.com/document/d/1QWBvpwYxOy9njAmd8vpizNQpPti9rd5ugVhji0r3T4c/edit"

Agreed that we can fix this. Side effect will be more frequent calls to the CDN/GCS bucket to fetch metadata. I also think we should update our bundled root and targets while we're at it.

[asraa]

I think a good recomendation is that we can fix this in sigstore/sigstore with a new release, but ideally the new TUF client in sigstore-go would be modeled after the advice we give to sigstore-python and other newer TUF clients - to always update.