[Teep] Artart last call review of draft-ietf-teep-architecture-16

Russ Housley via Datatracker <noreply@ietf.org> Mon, 28 March 2022 22:07 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: teep@ietf.org
Delivered-To: teep@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F073A198F; Mon, 28 Mar 2022 15:07:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Russ Housley via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-teep-architecture.all@ietf.org, last-call@ietf.org, teep@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164850526406.21554.6982960206540476351@ietfa.amsl.com>
Reply-To: Russ Housley <housley@vigilsec.com>
Date: Mon, 28 Mar 2022 15:07:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/HwvM6mWn2ze3VueGXboCuoxVcyg>
Subject: [Teep] Artart last call review of draft-ietf-teep-architecture-16
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2022 22:07:44 -0000

Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned ARTART reviewer for this Internet-Draft.

Document: draft-ietf-teep-architecture-16
Reviewer: Russ Housley
Review Date: 2022-03-28
IETF LC End Date: 2022-04-07
IESG Telechat date: unknown

Summary: Almost Ready

Major Concerns: None.


Minor Concerns:

Section 3.3 says:

   Weak security in Internet of Things (IoT) devices has been posing
   threats to critical infrastructure that relies upon such devices.

I'm a bit confused by this opening sentence.  IoT devices usually depend
upon an infrastructure.  This seems to be talking about an infrastructure
that depends upon a collection of IoT devices.  I suggest a minor edits
to help the reader understand that this sentence is not talking about
network infrastructure.

Section 9.3 says that a compromised REE "might drop or delay messages".
This discussion should be expanded to include the replay of messages.

Section 9.4 says:

   A root CA for TAM certificates might get compromised or its
   certificate might expire, or a Trust Anchor other than a root CA
   certificate may also expire or be compromised.

I do not understand the difference between a Root CA and a Trust Anchor.
These are usually used a synonyms.  Please explain the difference that
in intended here.


Nits:

Section 1 says:

   ... The problems in the bullets above, on the
   other hand, require a new protocol, i.e., the TEEP protocol, for TEEs
   that can install and enumerate TAs in a TEE-secured location and
   where another domain-specific protocol standard (e.g., [GSMA],
   [OTRP]) that meets the needs is not already in use.

Recommend breaking this long sentence up into at least two sentences.
There are two points.  First, the need for a protocol to address the
items listed earlier.  Second, where an existing domain-specific
protocol does not already exist, a new more general protocol is needed.

Section 4.4 says:

   ... Implementations must support encryption of
   such Personalization Data to preserve the confidentiality of
   potentially sensitive data contained within it, and must support
   integrity protection of the Personalization Data.

Why not say that implementation must support mechanisms for the
confidentiality and integrity protection of such Personalization Data?
Also, it seems like draft-ietf-suit-firmware-encryption offers one
mechanism for such protection.  Should it be referenced here?

Section 4: Is an "App Store" a place where apps are stored, or is it a
place where apps a purchased?  The term seems to be used both ways, and
in one place, the document is very general by saying, "an app store
or other app repository".  Elsewhere, the term "Trust Anchor Store" is
clearly a place for storage of trust anchors.

Section 9.7: Please consider changing the section title to be something
like: "TEE Certificate Expiry and Renewal".  There is an earlier section
that talks about expiration of Root CA certificates.