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

[Mingliang Pei <[e-mail]>]

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]> 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]> 
> Sent: Friday, July 17, 2020 4:44 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,
>  
> 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]> wrote:
> Mingliang Pei [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
>