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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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:
----------------------------------------------------------------------

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