Use vs Exfiltration: Provenance - Authenticated

[pkmooreanaconda]

First swing at adding some text that separates illegitimate use of authentication-related material from exfiltration of said material. Sebastien and I have been bouncing this back and forth a bit and wanted to get something out to drive discussion.

I think one thing that makes this text difficult is accounting for different mechanisms use different means to protect the provenance. Were we just talking about digital signatures, it would be straightforward to say something that boils down to "don't let people steal or misuse the signing materials." Keeping things generic means inventing a term like "authentication-related materials."

This is related to issue #187

[netlify[bot]]

✅ Deploy Preview for slsa ready!

Name	Link
🔨 Latest commit	0329b85d79e19716b68a1dd82a03f2ae2d2d84d9
🔍 Latest deploy log	https://app.netlify.com/sites/slsa/deploys/63505c91c056ec0009e912ef
😎 Deploy Preview	https://deploy-preview-494--slsa.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[awwad]

Fundamentally, it should not be possible for builders / users of the build system to cause (through ... essentially whatever means fall within the threat model) a consumer of the package provenance information to accept a provenance that was not produced by the appropriate, automated build system.

But how to put that exactly......

[mlieberman85]

Can you clarify the goal a bit?

[abacchi]

"don't let people steal or misuse the signing materials." Keeping things generic means inventing a term like "authentication-related materials."

Are you able to provide examples of authentication-related materials other than signing materials?

[awwad]

I think there are two different conversations here. Preston and I are primarily concerned with the signing scenario. Existing text was written in such a way as to permit other means of data authentication. (I suppose that that would include things like published hashes of provenance information, or transport authentication like TLS 🫤). Some of the ambiguous language in this PR is there to try not to interfere with this prior flexibility.

Our actual goal, though, is to clarify what seemed to us to be unclear when we were deciding on whether we meet this criterion. The existing text seems like it could include a system with completely unreachable keys but wide open access to make signing requests to those well-hidden keys (i.e. just signs whatever anyone throws at it) and exclude a system with reasonable key rotation mechanisms but better use-related protections.

[MarkLodato]

Thanks for the PR, and sorry for the delay in reviewing!

I suggest that we make this change to v1.0 rather than v0.1.

I like what @awwad suggested. To take it a step further, I believe there are three separate concerns:

• Tampering outside of the build service. In other words, consumers know that it really came from the build service.
• Tampering during the build by tenants. This includes getting access to key material or causing invalid junk to get signed.
• Compromise of the build service itself (e.g. rogue admin, compromised credential, physical access), which is then used to forge provenance that is accepted by consumers.

What do you think about making each requirement hit exactly one of these? Right now "Authenticated" kind of covers all three, but not to a very deep extent.

• "Authenticated" would cover tampering outside of the build.
• "Service generated" and "Non-falsifiable" would cover tampering by tenants, the latter being a stronger version of the former.
• The proposed v1.0 evidence of build security claims would cover the compromise of the build service itself.

Fundamentally, it should not be possible for builders / users of the build system to cause (through ... essentially whatever means fall within the threat model) a consumer of the package provenance information to accept a provenance that was not produced by the appropriate, automated build system.

👍 👍

The existing text seems like it could include a system with completely unreachable keys but wide open access to make signing requests to those well-hidden keys (i.e. just signs whatever anyone throws at it)

In my suggestion above, that is the "tampering during the build by tenants", which would be covered by "Service generated" + "Non-falsifiable".

[MarkLodato]

Hey folks, do we want this for v1.0?

/cc @kpk47 @lehors @arewm @Nikokrock (some folks not on this thread who might be interested since you've touched similar topics recently)

[arewm]

I feel like a lot of the comments here have already been addressed in the v1 specification as it currently is (i.e. provenance authenticity and accuracy with build system isolation). I think that questions/clarification around "best effort provenance completeness" and what should be included for the threat model at a build L3 are related to this and might be able to arrive at similarly interesting details and refinement.

[MarkLodato]

I'll close it for now to reduce clutter on the "open pull requests" page. Anyone feel free to pick this up and either reopen or create a new PR when ready for review.