Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-19

# Internet AD comments for {draft-ietf-teep-architecture-18}
CC @ekline

## Comments

* Thanks very much to Ines Robles for the IoT Directorate review.

  Please review the feedback at:

  https://datatracker.ietf.org/doc/review-ietf-teep-architecture-18-iotdir-telechat-robles-2022-09-04/

My colleagues already did a pretty thorough job.  I've only a few things to add.

The shepherd writeup is over a year old.  It lists Ben Kaduk as the responsible AD.

In Section 4.1, it says "Figure 1 shows the main components in a typical device with an REE and a TEE."  Where's the REE?  Is it the "Device"?

"SGX" should be expanded on first use (Section 4.1), but it's actually expanded in Section 4.4.1.

Nits:

Use of capitalization is inconsistent.  For instance, "Device User" is capitalized when defined, but never again; meanwhile, "Personalization Data" is always capitalized.

Section 1:

* "TEEs use hardware enforcement combined with software protection to secure TAs and its data." -- s/its/their/

Section 2:

* "Device User" is never used outside of the "Terminology" section; is it needed?

Thank you to Ben Schwartz for the SECDIR review. Please review his feedback.

** Section 1.
   The
   danger  of attacks on a system increases as the sensitivity of the
   applications or data on the device increases.  As an example,
   exposure of emails from a mail client is likely to be of concern to
   its owner, but a compromise of a banking application raises even
   greater concerns.

Based on the example, is it the “danger of attacks” or the “consequences of attacks”?

** Section 1. There are two different threat models implicitly described in this section.  The first paragraph seems outline the risk of multiple applications on the same devices and the complexity of those applications.  The fourth paragraph describes the threat of threat actors with physical access.  Are we talking about both?

** Section 3.1.  Is a “trusted user interface” something that needs to be defined?  Is it an example of a trusted TA?

** Section 3.3.
   A TEE can be the best way
   to implement such IoT security functions.

This seems like a strong but unsupported claim.  Consider something weaker.

** Section 4.4.
   Implementations must support encryption to
   preserve the confidentiality of such Personalization Data, which may
   potentially contain sensitive data.  Implementations must also
   support mechanisms for integrity protection of such Personalization
   Data.   

Please clarify what it means to “support encryption.”  Is this saying that all personalization data at rest must be encrypted?  No personalization data can be sent in the clear?

** Section 6.2
A TEEP Broker abstracts the message exchanges with a TEE in a device. 

What does it mean for the broker to “abstract” the message exchange?

** Section 7.  What is the relationship between the attestation process in Figure 6 and the conceptual message flow described in 6.2.1?

** Section 7.

   Different Verifiers may require different degrees of
   confidence in attestation proofs and not all attestations are
   acceptable to every verifier

Why is the first instance of “verifiers” a proper noun (capitalized) but the second is not?

** Section 9.  This section notes a few instances where a TEE should detect that something potentially suspect is happening.  How, if at all, should logging of this phenomenon occur?  How would someone managing devices become aware of it or be notified?

** Section 9.  From the SECDIR review:
==[ snip ]==
Nothing here seems to discuss attacks on the TEE's properties, and the
post-compromise implications of those attacks.  For example, if all instances
of a TA share a secret key, used for decrypting the Personalization Data, then
a single successful attack on a TEE is sufficient to decrypt all
Personalization Data (previous and future).  Given the prevalence of such
attacks (especially via hardware fault injection), it seems likely to be worth
mentioning. [1]
==[ snip ]==

** Section 9.1.  In the spirit of inclusive language, consider if there is an alternative term for “man-in-the-middle”.

** Section 9.1
   While a TEEP Broker broker can in effect make suggestions, it cannot
   decide or enforce what runs where.  

-- Editorial. s/Broker broker/Broker/

-- What suggestions can a Broker make?  Per Section 6.1, I thought the Broker only relayed messages between the Agent and the TAM.

** Section 9.3

   We have
   already seen examples of attacks on the public Internet with billions
   of compromised devices being used to mount DDoS attacks

Can a reference be provided for a single DDoS having billions of compromised devices as sources.

** Section 9.3.

   A compromised REE might also request initiating the full flow of
   installation of Trusted Components that are not necessary.  

With this technique, could a compromised RRE fill up all of the secure storage of a TEE preventing future legitimate installations from occurring?

** Section 9.7

  A TAM certificate usually has a moderate
   lifetime of 2 to 5 years

Is this a recommendation or an observation?  If the former, what is the basis of these numbers?

** Typos
-- Section 4.1.  Typo. s/Administators/Administrators/

-- Section 6. Typo. s/.././

I have very little to add, other than noting that I find Use-Case and Architecture documents to be really helpful.
They help "set the stage" when reading a new set of document, or deploying a new technology. Thank you!

Thanks for working on this specification. It was a good read for me. I will skip the nits but noted that "consensus boiler plate" entry is missing in the datatracker.

# GEN AD review of draft-ietf-teep-architecture-18

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/_PQLgwbAxaVsfWgfg62QZHYYlYs).

## Comments

### Unclear consensus

The datatracker state does not indicate whether the consensus boilerplate
should be included in this document. The shepherd writeup makes it pretty
clear that it should, so please change the datatracker metadata for the
document?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `man`; alternatives might be `individual`, `people`, `person`
 * Terms `she` and `he`; alternatives might be `they`, `them`, `their`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 4.1, paragraph 4
```
-       Administators may elect to use a TAM for remote administration of
+       Administrators may elect to use a TAM for remote administration of
+               +
```

#### Section 4.1, paragraph 5
```
-       Trusted Component Signers or Device Administators to use the TAM's
+       Trusted Component Signers or Device Administrators to use the TAM's
+                                                   +
```

#### Section 4.4.2, paragraph 1
```
-    a specific Untrused Application process lifetime as occurs in SGX.  A
+    a specific Untrusted Application process lifetime as occurs in SGX.  A
+                     +
```

#### Section 4.5, paragraph 8
```
-    via a TEEP Broker that faciliates communications between the TAM and
+    via a TEEP Broker that facilitates communications between the TAM and
+                                 +
```

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Grammar/style

#### Section 2, paragraph 8
```
ust resist modification against unauthorized insertion, deletion, and modifi
                                ^^^^^^^^^^^^
```
Do not mix variants of the same word ("unauthorized" and "unauthorised") within
a single text.

#### Section 4.5, paragraph 9
```
ed further in Section 5.3 below. Typically the same key TEE pair is used for
                                 ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Typically".

#### Section 6.1, paragraph 1
```
. ProcessTeepMessage: A message arriving on an existing TEEP session, to be d
                                ^^^^^^^^^^^
```
The usual preposition after "arriving" is "at", not "on". Did you mean
"arriving at"?

#### Section 7, paragraph 1
```
s, from trusted app updates for smart phones and tablets to updates of code 
                                ^^^^^^^^^^^^
```
Nowadays, it's more common to write this as one word.

#### Section 9.1, paragraph 3
```
AM certificates might get compromised or its certificate might expire, or a T
                                     ^^^
```
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 9.1, paragraph 4
```
EE certificates might get compromised or its certificate might expire, or a T
                                     ^^^
```
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 9.3, paragraph 1
```
oked by a timer or other event. Furthermore the policy in the Verifier in an
                                ^^^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Furthermore".

#### Section 9.3, paragraph 3
```
 certificates are expected to be long lived, longer than the lifetime of a d
                                 ^^^^^^^^^^
```
This word is normally spelled with a hyphen.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

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