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

From: Dave Thaler <[email-masked]>
Date: Fri, 17 Jul 2020 01:02:12 +0000

Thanks Ming for the review!  I entered your feedback as
https://github.com/ietf-teep/otrp-over-http/issues/16
and made changes to the doc that you can review at
* https://github.com/ietf-teep/otrp-over-http/pull/17
* https://github.com/ietf-teep/otrp-over-http/pull/18

Responses below:

> 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").

> 2) It also says "a Trusted Application Manager (TAM) service
>    is used to manage TEEs in devices that can initiate communication to
>    the TAM."
>
> A TAM doesn't manage TEEs. Suggest change it to "manage Trusted Applications".
> TEEs don't initiate communication to the TAM. Suggest change it to "TEEP Agent".

Changed to:
"is used to manage code and data in TEEs on devices that can initiate communication to
the TAM."

> 3) Section 1 says "a "Trusted Application Manager(TAM)" on the server side) must
> themselves run inside a TEE."
>
> This specification shouldn't set this as a requirement. A TAM in a secure data
> center that passes certain security requirements could be acceptable to some devices.

Context for the quote is that it was prefixed by "To be secure against malware,"
and I still claim that to be secure against malware, a TAM would need to run
in a TEE as well. However, I do agree that a TAM that is not fully secure
against malware could be acceptable to some devices, and that was my original
intent as well but I have clarified as:

"... must themselves run inside a TEE, although a TAM running outside a TEE
is also supported."

> 4) Section 2 says "and TEEP Broker, and Rich Execution Environment (REE)"
>
> The first "and" could be removed?

Yes, done.

> 5) Section 3: The hyperlink of "Section 6" doesn't point to the TEEP architecture document.

No hyperlink is in the draft. I think it's a bug in the html viewer for
Internet drafts, which seems to be a little too smart in adding a hyperlink
where it shouldn't.

> 6) Section 5.1: "The TEEP/HTTP Client then informs the TEEP implementation" and
> "The TEEP implementation will either (a) pass no data back,..."
>
> Should this TEEP implementation mean the "TEEP Agent" inside the TEE?

Yes, Section 1 explains the terminology:
> ..., a TEEP implementation (referred to as a
> TEEP "Agent" on the client side, and a "Trusted Application Manager
> (TAM)" on the server side) ...

But since the sentence in 5.1 is specifically about the client side then
yes TEEP Agent is more precise.  Will update throughout, for both
TEEP Agent and TAM.

> 7) Section 5.4 says "An implementation MUST provide a way to periodically check for TEEP
>    policy changes."
>
> TEEP policy hasn't been defined so far yet. Good to provide some examples of this,
> and where they are defined and who defines them. Will it mean TEEP client policy
> or TEEP server policy? The TA revocation status check in B) may not mean a policy; the
> time frequency to check TA revocation would be a policy.

Updated text to clarify with examples:

   An implementation MUST provide a way to periodically check for TAM policy
   changes, such as a Trusted Application needing to be deleted from a TEE
   because it is no longer permitted, or needing to be updated to a later
   version.

> 8) Section 7 says "The TEEP/HTTP Client calls the TEEP implementation's "RequestTA"
>         API, passing TA Needed = X."
>
> Should it be calling "TEEP Agent"? So far, we assume that all communications to
> TEEP in TEE will go through TEEP Agent. In step 3 below, it indicates that
> "The TEEP Agent passes the TAM URI..."

Same as point 6.

> 9) Step 8 says "Back on the TEEP Agent side"
>
> Does it mean "TEEP Broker side"?

No. There can be a TEEP Broker on both the agent side and the TAM side if
the TAM is in a TEE, so "TEEP Broker" isn't a side.

> 10) Step 9: shouldn't the TEEP Agent be involved in this communication?

Same as point 6.

> 11) Step 11 says "passes
>         the payload up to the TAM implementation."
>
> To be consistent with step 5 above, "TAM implementation" changes to "TEEP implementation"
> or "TAM TEEP Implementation".

Updated as part of changes for point 6.

> Nits:
>
> Section 4: s/upon a following such a redirect/upon following such a redirect

Done, thanks.

> Section 5.1: s/the TEEP/HTTP Client attempts to create session state/the TEEP/HTTP Client attempts to create a session state

Disagree with grammatical change. "State" is used in the same sense as
"data".  You create "data" not "a data", and you create "state", not
"a state" which would sound like a specific state in a state machine.

These changes will be in draft -07.

Dave

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 16 Jul 2020 18:36:22 -0700

Thanks Dave. Please see replies inline. Ming

> For example, it could also be used to update OP-TEE (or any other TEE

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.

> "is used to manage code and data in TEEs on devices that can initiate

MP: good

> "... must themselves run inside a TEE, although a TAM running outside a TEE

MP: I would use the word "SHOULD", not "MUST". I think that there are other
ways to be secure against "malware". "Must run inside a TEE" implies that
this is the only method.

> > The first "and" could be removed?

MP: Good

> Internet drafts, which seems to be a little too smart in adding a hyperlink

MP: fine

> yes TEEP Agent is more precise.  Will update throughout, for both

MP: good

>    because it is no longer permitted, or needing to be updated to a later

MP: this is fine.

> the TAM is in a TEE, so "TEEP Broker" isn't a side.

MP: the full paragraph reads

"8. Back on the TEEP Agent side, the TEEP/HTTP Client gets the HTTP
        response, extracts the TEEP message and pass it up to the TEEP
        implementation"

The above message means:

- it is inside TEE (On the TEEP agent side)
- gets HTTP response and extracts TEEP message
- passes it to "TEEP implementation" which is actually TEEP Agent here.

On the client side, it is the TEEP Broker that extracts HTTP response, and
passes it to the TEEP Agent. To avoid the vague side meaning, how is
something like:

"Back on the client side, the TEEP/HTTP Client gets the HTTP response,
extracts the TEEP message and passes it up to the TEEP Agent"

I will leave it to you to decide.

> > Section 5.1: s/the TEEP/HTTP Client attempts to create session state/the
> TEEP/HTTP Client attempts to create a session state
>
>
>

MP: I saw some call out "session state data" if it means data, and some use
"a session state"...

https://www.c-sharpcorner.com/UploadFile/de41d6/view-state-vs-session-state-vs-application-state/
"By default, an ASP.NET session state is enabled for all ASP.NET
applications. Session state data is shared across all the web pages..."

But I trust you have the right usage. Good for me.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 17 Jul 2020 23:15:57 +0000

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

---

From: Mingliang Pei <[email-masked]>
Date: Fri, 17 Jul 2020 16:44:07 -0700

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 <[email-masked]> wrote:

> Mingliang Pei [email-masked] wrote:
>

---

From: Dave Thaler <[email-masked]>
Date: Sat, 18 Jul 2020 00:37:14 +0000

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 <[email-masked]>
Sent: Friday, July 17, 2020 4:44 PM
To: Dave Thaler <[email-masked]>
Cc: [email-masked]
Subject: Re: Review of draft https://tools.ietf.org/html/draft-ietf-teep-otrp-over-http-06

Hi Dave,

>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

TrustedAppInstall
TrustedAppDelete

no value.

Dave

---

From: Mingliang Pei <[email-masked]>
Date: Fri, 17 Jul 2020 18:21:11 -0700

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 <[email-masked]> wrote:
> 
>

---

From: Dave Thaler <[email-masked]>
Date: Sat, 18 Jul 2020 01:34:15 +0000

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 <[email-masked]>
Sent: Friday, July 17, 2020 6:21 PM
To: Dave Thaler <[email-masked]>
Cc: [email-masked]
Subject: Re: Review of draft https://tools.ietf.org/html/draft-ietf-teep-otrp-over-http-06

Hi Dave,

Thanks,

Ming
Sent from iPhone

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

Dave

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

Hi Dave,

Thanks,

Ming

TrustedAppInstall
TrustedAppDelete

no value.

Dave