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

[Mingliang Pei <[e-mail]>]

Hi Rob,

Thank you very much for your review, comments and suggestions. Thank you
for your patience to our late reply; we have started to incorporate all
reviews in the last few days and target to be done in a day or two for all.
Please see my comments inline for some of your questions.

Thanks again,

Ming


On Tue, Sep 6, 2022 at 3:27 AM Robert Wilton via Datatracker <
[e-mail]> wrote:

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

Ming: we intended to not indicate who does it in concern of being
restrictive. Some lab tests programally install apps into many devices. It
is still some admin's decision to install but this gets vague or
disagreement from some readers when we start to say "a user". So shall we
just keep it out, assuming an Untrusted App install is generally understood
in various contexts?


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

Ming: you are right; that one was confusing. We move 3 below 2a and 2b. See
a current PR #252 and the change:
https://github.com/ietf-teep/architecture/pull/252/files


>
> (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".
>
>
Ming: good catch. We should say "TAs in the TEEs will be allowed to be
personalized by the TAM". A TA can have personalization data, and it is a
TA that will be the target of a personalization.


> (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?
>
>
Ming: right, we won't consider the need to encrypt the entire messages
except the sensitive payload, at least, not making it mandatory for a
protocol.


> (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.
>
>
Ming: the protocol APIs are very specific via a separate RFC. These Broker
APIs are illustrative or "conceptual" only, which we cannot specify exactly
what forms it take, which is up to the provider, usually a TEE provider or
device provider to bundle some TEEP Broker that can work with the TEE they
embed.


> (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"?
>
>
Ming: it tries to mean "device manufacture time" for putting on various
device software etc. Is this fine or would you suggest an alternative word?


> (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?
>
>
Ming: we considered "Compromised TEE" out of scope for this. The device
provider or owner needs to monitor and patch the entire device. There isn't
much the TA that the protocol manages here can do.

On compromised TA, we do have some description on it about replacing
malicious or buggy TAs, see 9.6 Malicious TA Removal. We have this line:

"It may happen that a TA was previously considered trustworthy but is later
found to be buggy or compromised. In this case, the TAM can initiate the
removal of the TA by notifying devices..."

Is this fine?


> 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?
>

Ming: good catch. I think we can revise this to "Untrusted Application can
fully function". An Untrusted app can depend on a number of TAs. Its
installation doesn't have to stop or not complete when TAs are not
completely installed. It is a decision by the installer, which SUIT can
specify for hard or soft dependency. If a TA is missing, only some function
in the Untrusted app may not work but other functions may be just fine. How
about this?


>
> (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.
>
>
Ming: how about "e.g., OP-TEE, an open source TEE)?

Thanks,
> Rob
>
>
>
>

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