[Teep] Robert Wilton's No Objection on draft-ietf-teep-architecture-18: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-teep-architecture-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document, I found it pretty easy to read.

Minor level comments:

(1) p 17, sec 4.5.  Entity Relations

   At step 3, a user will go to an Application Store to download the
   Untrusted Application (where the arrow indicates the direction of
   data transfer).

I note that this diagram doesn't actually include the user, possibly consider
changing "3. Install to 3. User Install"

(2) p 17, sec 4.5.  Entity Relations

   At step 4, since the Untrusted Application depends on the TA,
   installing the Untrusted Application will trigger TA installation via
   communication with a TAM.  The TEEP Agent will interact with the TAM
   via a TEEP Broker that faciliates communications between the TAM and
   the TEEP Agent.

I found this quite unclear from the diagram, it looked like the messaging is
initiated from the TAM to the Device with the TEE.  I also found the time flow
in this diagram to be somewhat unclear, since normally time flows downwards
with sequence diagrams, but I wasn't convinced that was the case here.  E.g. TA
-- 2b is lower than 3. Install.

(3) p 21, sec 5.4.  Scalability

   factory.  Likewise, new TAMs can join the ecosystem, providing they
   are issued a TAM certificate that chains to an existing root whereby
   existing TEEs will be allowed to be personalized by the TAM without
   requiring changes to the TEE itself.

It isn't clear to me what is meant by "personalized by the TAM".

(4) p 21, sec 5.5.  Message Security

   These messages are signed end-to-end between a TEEP Agent and a TAM.
   Confidentiality is provided by encrypting sensitive payloads (such as
   Personalization Data and attestation evidence), rather than
   encrypting the messages themselves.  Using encrypted payloads is
   important to ensure that only the targeted device TEE or TAM is able
   to decrypt and view the actual content.

It's not obvious to me why you would only encrypt the payload and not the
messages themselves.  Is this so that 'routing information' is readily
available or something else?

(5) p 23, sec 6.2.1.  TEEP Broker APIs

   The following conceptual APIs exist from a TEEP Broker to a TEEP
   Agent:

I'm slightly surprised that the conceptual TEEP Broker APIs are contained in
this document when the other equivalent TEEP APIs are not.

(6) p 24, sec 6.2.2.  TEEP Broker Distribution

   The Broker installation is commonly carried out at OEM time.  A user
   can dynamically download and install a Broker on-demand.

It is unclear to me what is meant by "OEM time"?

(7) p 27, sec 9.  Security Considerations

I note that there is no security considerations for a compromised TEE.  Should
this be considered, or is it the case that TEEs cannot be compromised? 
Similarly, is a compromised TA something that should be considered here?

Nit level comments:

(8) p 3, sec 1.  Introduction

   *  An installer of an Untrusted Application that depends on a given
      TA wants to request installation of that TA in the device's TEE so
      that the Untrusted Application can complete, but the TEE needs to

Should this be "so that the installation of the Untrusted Application can
complete?

(9) p 16, sec 4.4.2.  Example: Application Delivery Mechanisms in Arm TrustZone

   A trusted OS running in the TEE (e.g., OP-TEE) that supports loading
   and verifying signed TAs from an untrusted filesystem can, like SGX,
   use classic file distribution mechanisms.

I suggest expanding OP-TEE, it wasn't obvious to me what this was.

Thanks,
Rob