Ming's comments on draft -06

[dthaler]

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.

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

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.

4) Section 2 says "and TEEP Broker, and Rich Execution Environment (REE)"

The first "and" could be removed?

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

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?

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.

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

9) Step 8 says "Back on the TEEP Agent side"

Does it mean "TEEP Broker side"?

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

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

Nits:

Section 4: s/upon a following such a redirect/upon following such a redirect Section 5.1: s/the TEEP/HTTP Client attempts to create session state/the TEEP/HTTP Client attempts to create a session state

[dthaler]

Partial responses:

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

[dthaler]

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

[dthaler]

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 documents 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:

To be secure against malware, a TEEP implementation (referred to as a TEEP "Agent" on the client side, and a "Trusted Application Manager (TAM)" on the server side) must themselves run inside a TEE.

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

[dthaler]

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.

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.

[dthaler]

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.

[dthaler]

In https://mailarchive.ietf.org/arch/msg/teep/iCEuI2V8AEYpnZ6Y_fIZNBllWT0/ Ming confirmed that all changes were acceptable except:

• point 3 needed a change from "must" to SHOULD (now done in PR #18)
• point 1 needs discussion at IETF

[dthaler]

Fixed in draft -07

[dthaler]

IETF 108 TEEP minutes say:

16 Ming's comment on draft 06

Varius editorial fixes, TEE is a SHOULD (not a MUST)
Proposed change in scope of TEEP protocol
    Dependencies on RATS and SUIT mean that it would be "unnatural" to restrict the scope of TEEP in such a way that it excluded the elements those dependencies might require.