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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
