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

[Mingliang Pei <[e-mail]>]

Hi Roman,

Thank you very much for your review. Sorry for the late reply. We are
revising the draft to incorporate your suggestions along with others. We
have captured the fix in this issue and follow up comments:

https://github.com/ietf-teep/architecture/issues/255

Would you mind reviewing the response there? I can reply inline below too
otherwise.

Thank you very much,

Ming

On Wed, Sep 7, 2022 at 6:25 PM Roman Danyliw via Datatracker <
[e-mail]> wrote:

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

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.