[Rats] Re: Foundational document about TEE capabilities

[Yogesh Deshpande <[e-mail]>]

Hello Markus,

Remote Attestation via RATS Architecture, can provide limited security guarantees of a TEE via Claims made about the state of HW, the Measurement
of the Firmware running on the platform, etc.

It may provide dynamic trustworthiness, however, if one wants a much richer inspection of the system, then other protocols covered in IETF needs to be integrated in an effective manner to establish an End-to-End Trust provided by a TEE.

Few examples, given below:

1. Does the TEE has adequate threat model document?
2. Does the TEE undergo any security certification via Common Criterion or other such similar schemes?
3. Any other security related objectives met or not?

These are the claims which need much more detailed information about the static aspects of the system before dynamic trust can be established.

Once a TEE Vendor fulfils such requirements, it can publish the Non-Repudiation claims in a IETF SCITT based Append ONLY log and can connect the same to the Dynamic Aspects covered by
RATS. Similarly, Attested TLS (in SEAT WG) can guarantee a secure End to End TLS Connection with Remote Attestation to establish a secure connection to a Confidential VM,
before secrets can be released.

In short, based on the requirements/use case, one needs to integrate multiple security initiatives undertaken in various Working Groups in IETF, to achieve the desired security end goal.

If a specific gap is identified, then certainly this can be taken further!

From your description, it seems the work is already covered by other IETF security verticals.

Regards,
Yogesh Deshpande




-----Original Message-----
From: Markus Rudy <mr=[e-mail]>
Sent: Sunday, August 2, 2026 10:45 AM
To: RATS <[e-mail]>
Subject: [Rats] Foundational document about TEE capabilities

Hey RATS,

I've been wondering lately whether we're missing a foundational document that specifies capabilities and guarantees provided by TEEs, on an abstract level.

By TEE, I'm referring to "encryption in use" technologies, like SEV-SNP, SGX, TDX or ARM CCA. Some protocols that want to depend on RATS make more sense (or, only make sense at all), in combination with TEEs. The RATS architecture, however, is designed to also fit other attestable systems with different guarantees, such as TPM-measured boot. For protocols that require some sort of confidentiality guarantee it would be helpful if we had a doc that specified what those are, and what guarantees hold by attestation verification alone and don't need to be ensured by the protocol.

An example: I have software that generates an ephemeral asymmetric key inside a TEE. The TEE binds the key to an attestation report. I verify the report and software: can I now assume that this key is only known by the TEE?

1. The orthodox answer would be: yes, of course, that's what they're designed for.
2. The inquisitive answer could be: maybe - did you verify that debug mode is off? Are all mitigations applied? Is the software covered by the TEE measurements? Is the expected attack vector covered by the threat model?

While the second line of thought is very interesting, and a discussion worth having, I find that it distracts from protocol design. It would be easier if we had a common abstract "interface" to TEEs when integrating them into other protocols, and leave ensuring the guarantees to the specific TEE verification process.

In my mind, the doc could have a shape like this:

1. The TEE measures the software running inside. These measurements can't be falsified by an outside attacker, nor by the inside software (but may be updatable, as with runtime measurements). After evidence appraisal according to spec, integrity of the code running inside of it can be assumed by the relying party.
2. The TEE makes runtime memory inaccessible to anything but the guest software. After evidence appraisal, according to spec, confidentiality of data originating from the TEE, or passed to the TEE over a secure channel, can be assumed by the relying party.
3. The TEE allows the software to generate evidence with some data provided by the application. After evidence appraisal, according to spec, the relying party can assume that this piece of data was indeed passed by the genuine software. (This is a crucial feature for building anything on top, but often just assumed to be possible)

What do you think, is this something worth specifying? Am I missing properties? How are you dealing with these in other drafts?

I'd be particularly happy to see comments from people at hardware vendors!

Cheers, Markus
_______________________________________________
RATS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.