[Rats] Re: Foundational document about TEE capabilities

[Mohamad Khalil Yossif <[e-mail]>]

> Markus, all,
> 
> Your worked example is the question I had to answer normatively, and I
> can offer what happened when I tried rather than an opinion about
> whether the document should exist.
> 
>   "I verify the report and software: can I now assume that this key is
>   only known by the TEE?"
> 
> I write a profile whose entire claim rests on a related assumption: a
> signature was produced by a key whose signing operation was gated by a
> contemporaneous user-verification event. Not confidentiality of the
> key, but a property of the environment holding it — the same shape of
> question, and it fails in the same place.
> 
> What I found is that the answer is not yes or no. It is two answers,
> and which one applies depends on something outside the protocol:
> 
> Where the platform attestation conveys the property, a Verifier can
> cross-check the claim against the attestation and reject on
> contradiction. The property is attested.
> 
> Where the attestation surface does not convey it, the claim is signed
> and tamper-evident but rests on a documented trust assumption about
> the authenticator. It is asserted.
> 
> Both pass signature verification. Both look identical on the wire. The
> profile has to say, normatively, that a Verifier MUST NOT accept the
> second as though it were the first where the cross-check was
> available, and MUST NOT treat presence as attested where the surface
> cannot convey it.
> 
> Two things that cost me something to learn, offered because they bear
> on what such a document would need to contain.
> 
> First, "the attestation conveys the property" is not a yes/no fact
> about a TEE class. It is a fact about a specific attestation format
> and what fields it carries, on a specific platform, at a specific
> version. Two devices with the same silicon can differ. A document
> written at the level of SEV-SNP or TDX would not have let me write the
> rule I needed; what I needed was per-attestation-surface, and I ended
> up stating the conditional rather than the fact.
> 
> Second, and this is where Ned's point bites: the fallback for the
> unattested branch is a documented trust assumption, which is another
> way of saying reputation. I could not do better and I do not think a
> profile can. But a Verifier that cannot tell which branch it is on has
> no way to know it is relying on reputation rather than on
> verification, and that is the failure mode worth a document — not the
> guarantees themselves, but a way for a relying party to determine
> which guarantees it actually got.
> 
> So my answer to the framing question is narrower than either
> orthodoxy. A foundational document that enumerates TEE guarantees
> would not have helped me. One that gave protocol authors a vocabulary
> for "attested versus asserted, and how a Verifier determines which"
> would have — and Michael's point about public norms is, I think, the
> same point: the value is in making the difference legible, not in
> asserting that the guarantee holds.
> 
> For whatever it is worth as a worked instance rather than a proposal:
> 
>   https://datatracker.ietf.org/doc/draft-yossif-psea/
> 
> Section 3.7.1 is the two-branch rule. I would rather it were read as
> one attempt that a better document could improve on than as a model.
> 
> Mohamad Khalil-Yossif
> 
>   draft-yossif-psea
>   https://datatracker.ietf.org/doc/draft-yossif-psea/
>   draft-yossif-agent-mandate-problem
>   https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/
>   draft-yossif-enrollment-problem
>   https://datatracker.ietf.org/doc/draft-yossif-enrollment-problem/