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

[Mingliang Pei <[e-mail]>]

Thanks Dave. Please see replies inline. Ming

On Thu, Jul 16, 2020 at 6:02 PM Dave Thaler <[e-mail]> wrote:

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

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.


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

MP: good


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

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.

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

MP: Good


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

MP: fine

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

MP: good

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

MP: this is fine.

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

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.

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

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.

These changes will be in draft -07.
>
>
>
> Dave
>