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

[Bob Halley via Datatracker <[e-mail]>]

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.

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.

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.

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.

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.

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.