Insight on domain dependency behavior by Verifier

[nedmsmith]

The domain-dependency-triple-record lists target environments and the other environments, usually attesting environments, the target depends on for trust establishment.

It may be unclear what behavior the Verifier should take if a target environment appears in Evidence, but does not have a corresponding dependency triple.

A concern is that if an env is compromised (after its measurement / evidence is collected), the compromised env could measure an additional (attack) env, with evidence, that the Verifier will accept.

Note: There may be other ways to detect this attack. The compromised env could have been issued a DICE certificate that excludes the ECA key purpose OID. The compromised env could have been issued an X.509 certificate with a pathlen value=0. Given there may be multiple evidence formats that don't have these mitigations, the dependency triple may be an additional form of mitigation.

However, to mitigate this attack, there needs to be conventions for its use. If the dependency triples are a closed set. Then only attack environments will not show up in dependency triples. Can CoRIM assert this requirement?

Verifier behavior should be clear whether it detects this attack.

If the verifier should detect the attack using RIMs, then RIM authors MUST specify dependency triples.

Detection requires an all-or-nothing approach. All the target envs MUST be included in RIMs, or the verifier is not expected to detect the attack. Otherwise, the possibility of unnamed, but trusted environments could exist. The Verifier is undecided as to which is legitimate.

Do we think CoBOM plays a role toward identifying tags that contain dependency triples?

[yogeshbdeshpande]

@nedmsmith to add the more realistic use case.

[nedmsmith]

Edited description to make the attack scenario more clear and included alternative ways to detect the attack.

[deeglaze]

I think that dependency triples being a closed set is a SHOULD situation to avoid a downgrade attack, but real deployments may have to fudge things and it'll be down to verifier policy which to trust. You could improve the situation with CoBOM maybe, but those are optional.

I'm still unclear what the verifier's expected processing of these triples is supposed to be. Is it that if you find that for an appraisal session that when you convert evidence into ACS entries, you create subgoals that must be discharged to first establish trust in the domains it depends on? When that's the case, I would think that an appraisal session would need all the evidence for the environments of the sum total of dependent domains that are active among the domain membership triples.

When the domains are not cryptographically bound together in a chain of measurements, I don't know what the hope is for these triples. When the binding is there, the attestation scheme requires verifying the whole chain. Taking a step back, what is the use case scenario for this DAG structure (is it required to be a DAG? I really hope it's required to be a DAG. It's not spec'd to be a DAG)?

---

Speculation:

I can see maybe implicit in certain layers of access to a system, you might not get to see the whole measurement history. For example, a container's attestation shouldn't get to know about the attestation of other containers that have run on that pod: only the policy of the launcher that launched the container. The launcher signs its own attestations for workloads launched, and the certificate for that launcher is known to be issue by a CA that only issues certificates to launchers that prove they're in an approved environment themself. The kernel may even protect the key to do the signing only for a process that had a specific measurement that the CA knew...

So for that system, you say the container is in the domain of the launcher, and the launcher is in the domain of the node, and the node is in the domain of both the measurement technology and the CSP that signs certificates that the chip id in the measurement corresponds to their property that's running in a certain locality. These are all aspects I would think to understand as part of an appraisal policy of what in a complete measurement to see as salient. I understand domains more as the certificates for keys that sign the claims that I depend on, and that I have policy that certain claims should only be signed by certain authorities. Yeah, still missing the point :(