[Rats] Re: Foundational document about TEE capabilities

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

> Ionut, all,
> 
> On your question - no, I think you have the context right, and I want
> to add one thing from having tried to write the assumption down.
> 
> You put the example as "Can this key be extracted from the TEE?" The
> form I needed was adjacent: was the signing operation gated by a
> contemporaneous user-verification event. Different property, same
> structure, and it failed in the same place - not because the answer
> was unknown, but because it was two answers.
> 
> What I could not write was a fact. What I could write was a rule for
> determining which answer applies:
> 
>   Where the platform attestation conveys the property, a Verifier
>   MUST cross-check the claim against it and MUST NOT accept the claim
>   as self-asserted when the cross-check was available.
> 
>   Where the attestation surface does not convey it, the Verifier MUST
>   NOT treat the property as attested.
> 
> That rule needs no SDO to have defined what a TEE guarantees. It
> needs only that a Verifier can tell, from the attestation in front of
> it, whether the property is carried. Everything downstream follows
> from that determination rather than from the guarantee itself.
> 
> Which is why I read Jeremy's point as narrower than a veto. The
> security-level claim failed because it tried to agree on what the
> levels contain. What I needed was not the contents - it was the
> ability to distinguish a claim that has been checked against
> something from one that has not. That distinction is protocol-level,
> it does not require agreement on any TEE's actual guarantees, and it
> is the part that is missing today.
> 
> So on your two-level framing: I would put it slightly differently.
> The SDO documents define what the guarantees are. What is missing is
> not a layer above those - it is a vocabulary for the case where the
> document exists and the attestation surface still does not carry the
> field the protocol needs. That case is common, and today every
> protocol author solves it privately and inconsistently.
> 
> The concrete failure mode, since it is the reason I care: both
> branches produce a token that passes signature verification and looks
> identical on the wire. A relying party that cannot tell which branch
> it is on has no way to know it is relying on a documented trust
> assumption rather than on verification. It is not that the assumption
> is unacceptable - it is that it is invisible.
> 
> Ned's reputation point and Michael's public-norms point are, I think,
> the same observation from two directions. Reputation is a reasonable
> fallback. Being unable to tell that you are on the reputation branch
> is not.
> 
> Whether that belongs in SEAT, in a RATS document, or nowhere, I do
> not have a view worth much - I have written one profile, not a
> standard. But if it is written anywhere, my suggestion is that it
> carry the determination procedure rather than the guarantees.
> 
> Separately, and still open from my thread here last week, since it is
> the same kind of question and this list is where it belongs.
> 
> Thomas Fossati's review sent me back to Section 4.2.1.1, and I think
> I may have the wrong claim rather than the wrong derivation. The value
> my profile puts in ueid is re-derived when the device identifier is
> regenerated - a factory reset, or on iOS the loss of the Keychain
> entry. Section 4.2.1.1 says a UEID is permanent and MUST NOT change
> for a given entity. Section 4.2.2 describes a value that MAY change on
> entity life-cycle events, gives factory reset as an example, and lets
> a profile specify the triggering events and carry a label.
> 
> Read that way, a per-deployment value that changes on a life-cycle
> event is an SUEID and not a UEID. I did not see it when I wrote the
> profile.
> 
> I have a revision built and held on that question. If the permanence
> requirement is meant to bite here, I would rather move the claim once,
> deliberately, than ship a revision that corrects a derivation and
> leaves the claim selection wrong. A one-line view from anyone who was
> in the room for 4.2.1 and 4.2.2 would settle it.
> 
> 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/