Re: [Teep] Review of draft https://tools.ietf.org/html/draft-ietf-teep-otrp-over-http-06

[Dave Thaler <[e-mail]>]

The power of us using RATS and SUIT is that the TEEP protocol gets lots of stuff for free.
We don’t need TEEP protocol methods for things that can be done as RATS claims or
SUIT manifest commands.

From: Mingliang Pei <[e-mail]>
Sent: Friday, July 17, 2020 6:21 PM
To: Dave Thaler <[e-mail]>
Cc: [e-mail]
Subject: Re: Review of draft https://tools.ietf.org/html/draft-ietf-teep-otrp-over-http-06

Hi Dave,

TEEP protocol itself defines what TEEP protocol does for TA. It doesn’t list what is not allowed; implementation still has freedom to add management for dependencies it needs.

My concern is whether additional protocol methods should be defined if TEEP is used to manage other non-TA code. We can choose to not mention it which doesn’t mean it disallows them.

If we choose to include non-TA, we could mention that TEEP extensions later may be added for those to move on.

Thanks,

Ming
Sent from iPhone


On Jul 17, 2020, at 5:37 PM, Dave Thaler <[e-mail]<mailto:[e-mail]>> wrote:

My point is that saying you cannot update OP-TEE in a SUIT manifest would be like saying
you are not allowed to create an SD in a SUIT manifest workflow.   I think trying to disallow such things
would be counterproductive and would just result in people using a protocol other than TEEP.

Dave

From: Mingliang Pei <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 17, 2020 4:44 PM
To: Dave Thaler <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Review of draft https://tools.ietf.org/html/draft-ietf-teep-otrp-over-http-06

Hi Dave,

Our architecture document starts with the following abstract:


"This architecture document

   motivates the design and standardization of a protocol for managing

   the lifecycle of trusted applications running inside such a TEE."
>> TEEP is for provisioning TEEs
To me, TEEP is to provision trusted applications to TEEs. This scope is consistent with what architecture doc says.

>> whether that is creating an SD or updating OP-TEE
We have had good elaboration about SD, and decided to not include it in TEEP. These example artifacts (SD or TEE update) are internal implementation choices, which TEEP doesn't need to define. They are underlying dependencies but TEEP doesn't need to cover whether and how a TEE updates itself and whether a TEE will use SD to host a TA or not.

Agreed that this most probably needs WG consensus. This is one word simple change but important about getting on the same page. Hope to hear additional comments.

Thanks,

Ming


On Fri, Jul 17, 2020 at 4:15 PM Dave Thaler <[e-mail]<mailto:[e-mail]>> wrote:
Mingliang Pei [e-mail]<mailto:[e-mail]> wrote:
> 1) Abstract section says "is used to manage code and configuration data"
>
> Should it just say manage "Trusted Applications" as this can
> assume the context defined in TEEP architecture and TEEP protocol
> document.

No. TEEP can also be used to manage code that isn't a "TA" per se.
For example, it could also be used to update OP-TEE (or any other TEE "OS").

MP: Non-TA code management is out of scope for TEEP. TEEP architecture doc only targets to support TA management per use cases and scope sections; it doesn't have design to update OP-TEE or any other TEE OS. TEEP protocol doesn't have methods for non-TA code. It defines only two methods:

TrustedAppInstall
TrustedAppDelete
The transport is to support TEEP protocol doc. I suggest that we limit the scope of TA management across all three docs.


I disagree with the above.   TEEP is for provisioning TEEs, and TEE architectures vary.
For example, CreateSD in OTrP manages a TEE but is not about a TA per se.

And in the TEEP protocol we use a SUIT manifest which can express dependencies
among TAs, and dependencies on system components, and install (or install updates to)

such dependencies as part of SUIT manifest processing.  That means if you have

TA1 that depends on TA2 that depends on having the latest version of trusted firmware
or OP-TEE or whatever, the RATS attestation can include the current state, and the

SUIT workflow can install/update it.   The fact that the TEEP protocol uses a TA

as the leaf/trigger doesn’t mean it can’t also do things that it depends on,

whether that is creating an SD or updating OP-TEE.   Trying to make some dependencies

be out of scope and other dependencies not be out of scope would be arbitrary,

complicate the protocol (by saying some SUIT manifests would be illegal, as opposed
to just using a SUIT processor), and create discrepancies between TEE implementations

(e.g., SGX vs OP-TEE/TrustZone) that in my opinion would not make sense and provide

no value.



This sounds like something that needs WG consensus either way but I feel strongly about this one.



Dave