[root v11] online-signing tweaks

sigstore / root-signing

TUF repository for Sigstore trust root

Apache License 2.0

85 stars 81 forks source link

[root v11] online-signing tweaks #1339

Open jku opened 1 month ago

jku commented 1 month ago

Assuming the migration in #1323 goes as planned, the timestamp expiry period in root v10 is 7 days and the signing period is 4 days meaning we sign a new timestamp every three days. We should consider signing timestamp more often (maybe daily?):

clients that follow the spec will always download timestamp.json: whether the timestamp is new or not does not change the bandwidth or time requirements
signing more often makes the repository less likely to break (as it means we will have 6 days to react to any issues rather than 4)

jku commented 1 month ago

related: #1347 -- we should change the incorrect KMS key id

haydentherapper commented 1 month ago

I'd be supportive of reducing to a day, but we should try to get community input on this given it would increase the frequency of online queries during verification.

jku commented 1 month ago

it would increase the frequency of online queries during verification

That's the thing:

if the clients operate as tuf spec requires, it's the same number of requests: once every startup
even if they use an "old" but valid timestamp (against tuf spec but seems like a possible choice too), the expiry time remains the same, so should not lead to more requests

haydentherapper commented 1 month ago

if the clients operate as tuf spec requires

This is the issue, at least for the Go client, it allows for configuration that doesn't follow the spec. In Cosign, we would cache targets up to the timestamp validity and then refresh only once the timestamp as expired. In the new sigstore-go TUF client, the default behavior is to follow the TUF spec, but it can be configured. I'm not sure what other clients are doing.

haydentherapper commented 1 month ago

Oh sorry, I re-read, you're saying to keep the timestamp validity the same but just up the frequency of signings. Gotcha, that seems good!

Though I think we should think about decreasing the timestamp validity as well, to let us handle key rotations faster.

jku commented 1 month ago

decreasing the timestamp validity as well

I'm not sure about this, the main reason I suggest this change (signing more often) is to increase the time we would have to deal with failures -- current 4 days feels very, very tight to me:

shorter timestamp expiry only protects clients that are not spec compliant -- this feels like the wrong focus
in practice the current expiry/signing periods mean two working days to fix issues. This is not a lot for root causing, potentially fixing and releasing tuf-on-ci and upgrading root-signing
there are failure scenarios (like some sort of KMS disaster) where we need to fix something and then need signatures from 3 root signers. This is not reasonable in two days

jku commented 1 month ago

This change is now live in root-signing-staging https://github.com/sigstore/root-signing-staging/pull/171