New tlog & sct insecure CLI options - are they really insecure ?

[biehl1]

Hello,

Throughout cosign version 1.x.x it was possible to verify images by just providing a public key file and an image reference alone, without integration with transparency log (which was experimental, if i'm not mistaken)

With 2.0.0, transparency log verification enforcement is on by default and, in order to opt out, we have to use the flag insecure-ignore-tlog.

About that insecure part there: If one did not rely on a transparency log up to this point (as it was an experimental feature), is this practice necessarily considered "insecure" from this point? Checks backed by a transparency log adds security, but does it deem working without it as totally bad practice?

Otherwise, this option could just be named as --ignore-tlog?
Same goes for insecure-ignore-sct I suppose.

Also, when running with these flags, the program outputs:

**Warning** Skipping tlog verification is an insecure practice that lacks of transparency and auditability verification for the signature.

Maybe, word it like:

**Warning**, Skipping tlog - signature will not be checked against public transparency logs

Thanks

[haydentherapper]

Cosign as a client is opinionated on what should be required, and we view transparency as a core part of Sigstore. In 1.x, since the transparency service was not yet fully productionized, the defaults were to not use the log. Now that the service is productionized, the default has flipped to leveraging transparency for both key-based and identity-based signing, with the option to opt out. Transparency is valuable in both cases, because it allows signers to audit when their signing material is used.

For private deployments of Sigstore, transparency might not be necessary. We're aware of this and open to suggestions on how to improve the UX.

[biehl1]

Hey @haydentherapper totally get your point. Makes sense (as its part of the whole Sigstore ecosystem). Perfect.

However, it is still a valid use-case like you said yourself - for private deployments (full Sigstore or parts of it, e.g. using purely cosign) - and not necessarily insecure.

As a suggestion, I would take the "insecure" wording out of those options and from the program output. It can be potentially misleading and raise user questions. Why is it suddenly insecure?

Thanks

[haydentherapper]

Even in private deployments, it is “insecure” in that you lose out on immutable auditability, which can defend against insider risk. I would encourage private deployments to still leverage transparency logs, unless they understand the impact of removing them.

We may end up creating separate commands for private deployments, there’s a few other issues we’d like to fix with custom PKI. For most users though, it makes sense to leave this as-is to inform them of the lack of transparency when verifying.

[znewman01]

See #2648 for proposed alternate UX (specifically, it would look more like --transparency-log-validation=none-insecure).

I'm inclined to continue to call deployments that don't have the security features of the public instance "insecure" by default.

Correspondingly, I'm hesitant to take away the warnings unless presented with positive evidence that omitting transparency logs is an acceptable risk. So, we could hide the warning if somehow we told cosign that we were in "private deployment mode." Or we could have users opt to hide specific messages by saying cosign i-promise-i-understand-what-the-tlog-does --force.

[biehl1]

Maybe I am missing something, but so far (until 1.13.1) unintentionally missing transparency log integration (except for experimental) was not explicitly stated as being a critical insecure or declared bad practice.

That being the case, since 1.0.0 cosign, this should be labeled as an insecure singing / verification tool - except if you opt-in to experimental features (e.g. so do not use in your production solutions).

I'm strongly against continuing to use "insecure" label here - both on program flag AND in output warnings.

Whoever has been using cosign and distributing contractually their public keys, both images and corresponding signatures to their private registries and advising consumers to use those for verification will be now forcefully having to advise those same consumers to use "insecure" features, highlighting insecure practices (which in fact are not really). I believe you can see this is not nice.

Besides, verifying signature artifacts against known public keys are not necessarily an insecure practice, is it? Maybe - tlogs, and whatnot are extra layer there, tying things up, but this layer does not mean the first use alone is bad practice. Unless of course, I am missing big part of the link here, and so perhaps does the documentation: If such practices are so insecure, as you say, that threat model should be very clear and stated widely in docs - first page material.

Without taking into the fact that the "buy-in" usability and convenience of having zero infrastructure around signature and verification process (besides having your OCI registry) was widely preached since cosign became mainstream - without preaching in the insecurity that came along with not having that transparency log feature on.

Plus - using cosign without a transparency log backing it should be taken into deprecation and removed in future, if so insecure.

But thats just my opinion of course. Please ignore, and feel free to close this comment if invalid.

Thank you

[haydentherapper]

Cosign 1.x was a big UX improvement on existing signing and verification tooling, but without the services being battle-tested, we didn't want those being the default. The end goal was transparent signing. Making it easier to sign and verify in general improves supply chain security, and transparency improves it further.

It's not inherently insecure to use keys without transparency, but it provides no way for the signer to monitor how their key (or identity) is used. This same shift happened with the Web PKI ecosystem. TLS certificates could be generated without any way for domain owners to monitor issuances. Certificate transparency made that possible, and so it's considered insecure to verify a TLS certificate that does not come with a proof of transparency.

https://docs.sigstore.dev/security outlines Sigstore's security model, and we're working on publishing a more thorough threat model. We definitely need to answer the questions you're asking!

Plus - using cosign without a transparency log backing it should be taken into deprecation and removed in future, if so insecure.

Cosign is a bit of a swiss army knife, so we have to find the balance between being very opinionated and offering optionality. Our goal is to make the default have the strongest security guarantees, while providing flags for those who have different use-cases.

[biehl1]

Thanks for adding in, makes total sense (the backing features of a monitored tlog + enforced checks).

Our goal is to make the default have the strongest security guarantees, while providing flags for those who have different use-cases.

Wording-wise I believe --private-repository as mentioned here (just now I see this one), or --transparency-log-validation=none (without the insecure part) would have been fine - backed by Sigstore's security model.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.