Re: [Last-Call] Intdir telechat review of draft-ietf-teep-architecture-18

[Mingliang Pei <[e-mail]>]

Hi Bob,

Thank you very much for your comments and suggestions. Please see inline.

Ming


On Sat, Aug 27, 2022 at 4:35 PM Bob Halley via Datatracker <[e-mail]>
wrote:

> Reviewer: Bob Halley
> Review result: Ready with Nits
>
> I am an assigned INT directorate reviewer for
> draft-ietf-teep-architecture-18.
> These comments were written primarily for the benefit of the Internet Area
> Directors. Document editors and shepherd(s) should treat these comments
> just
> like they would treat comments from any other IETF contributors and resolve
> them along with any other Last Call comments that have been received. For
> more
> details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
> <https://datatracker.ietf.org/group/intdir/about/>.
>
> Based on my review, if I was on the IESG I would ballot this document as
> YES.
>
>
[Ming] Thank you!


> This document is well written, and I liked the extensive definitions
> section.
>
> While for me it did not rise to the level of DISCUSS or NO OBJECTION, I was
> nevertheless concerned about one part of the document from a networking
> point-of-view.  In section 4.1 it says
>
>       As shown in Figure 1, the TAM cannot directly contact a TEEP
>       Agent, but must wait for the TEEP Broker to contact the TAM
>       requesting a particular service.  This architecture is intentional
>       in order to accommodate network and application firewalls that
>       normally protect user and enterprise devices from arbitrary
>       connections from external network entities.
>
> I am not completely sure how to interpret this.  It's clear from the
> definition
> of TEEP Broker that it is always an intermediary between the TAM and the
> TEEP
> Agent, so it would always be true that the TAM cannot "directly contact"
> the
> TEEP Agent.  Yet this text says that the broker must contact the TAM
> "requesting a particular service".  This is unclear; does it mean "the TEEP
> Agent must ask the broker to initiate a TAM connection", or "the broker can
> intiate the connection, but only when it has some specific service it
> wants",
> or something else?  While I understand the rationale to permit broker
> initiation of connections to avoid firewall issues, it seems overly
> restrictive
> to require it.  In particular, if this is meant to imply that the broker is
> periodically polling the TAM to see if it has anything for its TEEP Agents,
> then this seems a poor choice for certain use cases.  Some networking
> techologies have paging or push services that could be used by a TAM to
> wake up
> a device.  IoT devices are in scope in this document, and some IoT devices
> are
> extremely power-constrained and also often very numerous.  In "the TEEP
> Agent
> must ask" interpretation this is expensive as all of the TEEs have to waste
> energy polling for updates.  In the "broker initiates" interpretation,
> this is
> still expensive polling if the broker is necessarily on the same device as
> the
> diagrams seem to imply.  This would preclude, for example, a local mesh
> network
> of IoT devices where the broker was NOT on the same device as the TEEs it
> was
> serving.  Assuming I have not misread the document, it may be worth making
> the
> architecture a bit more flexible in where things are and who can
> initiate.  At
> the higher level, the architecture is fine: you have TEEP Agents that don't
> have direct Internet/WAN connectivity, but can talk to the TEEP Broker
> somehow.
>  The broker does have Internet/WAN capability and is not power constrained
> in
> the way the TEEs might be, and it talks to TAMs for them.
>
>
[Ming] Right, we didn't elaborate what triggers a TEEP Broker to contact
TAM in this definition section. It was elaborated in the later section, for
example, 4.3 where it says

"When a TEEP Broker receives a request (see the RequestTA API in Section
6.2.1
<https://www.ietf.org/archive/id/draft-ietf-teep-architecture-18.html#apis>)
from an Untrusted Application to install a Trusted Component...".

This is the most common case where a TA is installed and provisioned via an
UA. By this, the call to TAM is on-demand, not too many. On the other hand,
there could be periodic policy checks with a TAM if an application designs
to do so, which the architecture allows it and leave the choice to an
application.

Do you think the text is OK as is or would like to add a sentence to point
the TEEP Broker triggering to the later sections in the definition?

In section 9.4 and 9.6, I wondered if the certificate validation, updatable
> Trust Anchors, and malicious TA removal was enough, or if there should be
> additional tools to increase security for TEEs that wanted it.  For
> example, I
> imagined an "apply this update after you've heard from the TAM for 7 days
> in a
> row" feature, but I realized you could do this via some future version of
> the
> SUIT manifest.  I don't think anything needs changing here.
>
>
[Ming] yes.


> The following are minor issues (typos, misspelling, minor text
> improvements)
> with the document:
>
> The definition of "Device User" has this sentence fragment: "Relates to
> Device
> Owner and Device Administrator."   I don't think noting the relation is
> needed
> given the definitions are right next to each other and you'll have gotten a
> sense about the device user already, but if it is going to be noted, it
> would
> be better to do it with a complete sentence.
>
>
[Ming] Thanks for the suggestion. I recall we used that to compare with an
owner or admin (for corp use case). The three definitions together have had
it clear. So I tend to delete it as you suggested.


> In Figure 1 and 2, "App-1" and "App-2" should probably emphasize that they
> are
> Untrusted Applications, so perhaps "UA-1" and "UA-2" would be better.
> Also in
> these figures, the Trusted Applications are labeled "TA1" and "TA2" which
> is a
> little strange as all of the other labels have "-", so "TA-1" and "TA-2"
> would
> be better.
>
>
[Ming] Good catch. Agreed. Will update it.


> In the section 4.1 definition of Trusted Application Manager, it says
>
>       The TAM is trusted by a device if the TAM's public key is, or
>       chains up to, an authorized Trust Anchor in the device.
>
> If you have read carefully and remember the definiton of Trust Anchor, you
> realize this means the TAM is trusted subject to the constraints on its
> authority, but it might be good to reiterate this point here, as it reads
> like
> "is unconditionally trusted" if you don't remember the definition.  Also,
> it
> was not clear if the chaining process could have further restricted the
> scope
> of the TAM, e.g. due to additional restrictions on certificates beneath the
> trust anchor.
>
>
[Ming] Agreed. Will update it to not lose the meaning that a constraint may
be also in force. How about the following revision?

"The TAM is trusted by a device if the TAM's public key is, or
 chains up to, an authorized Trust Anchor in the device, *and *
* conforms with all constraints defined in the Trust Anchor.*"

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