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