[Teep] draft-ietf-teep-protocol-05

Russ Housley <housley@vigilsec.com> Wed, 03 March 2021 20:56 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8431C3A1ACE for <teep@ietfa.amsl.com>; Wed, 3 Mar 2021 12:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYFj7Oc3m3M3 for <teep@ietfa.amsl.com>; Wed, 3 Mar 2021 12:56:15 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E853A1ACB for <teep@ietf.org>; Wed, 3 Mar 2021 12:56:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E6B72300B48 for <teep@ietf.org>; Wed, 3 Mar 2021 15:56:12 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YOcpofMDWs6w for <teep@ietf.org>; Wed, 3 Mar 2021 15:56:11 -0500 (EST)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 9F150300B0C for <teep@ietf.org>; Wed, 3 Mar 2021 15:56:11 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Wed, 03 Mar 2021 15:56:11 -0500
References: <161403830667.29287.12752318662076741729@ietfa.amsl.com>
To: teep <teep@ietf.org>
In-Reply-To: <161403830667.29287.12752318662076741729@ietfa.amsl.com>
Message-Id: <4891DF28-2482-4507-A023-FF676A23DD80@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/UOvK1AMGBTpaL869eGdkVGlHGmw>
Subject: [Teep] draft-ietf-teep-protocol-05
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 03 Mar 2021 20:56:19 -0000

In preparation for IETF 110, I read draft-ietf-teep-protocol-05.  I am writing to share my comments from that review.


TECHNICAL QUESTIONS AND SUGGESTIONS

In Section 4.2, tes discussion of token says:

      The TAM MUST expire the token value after receiving the first
      responce from the device and ignore any subsequent messages that
      have the same token value.

Should this say the first response that has a valid signature?  Otherwise, we are creating an opportunity for an attacker to quickly respond with a matching token but otherwise garbage.  Then a legitimate responder will be ignored.

In Section 4.2, the discussion of ocsp-data says: "certificates up to the root certificate".  I do not think we want an OCSP response for the trust anchor (a.k.a., root certificate).  I suggest: "certificates up, but not including, to the root certificate".

In Section 7, I think that future ciphersuites should allow MAC algorithms other than HMAC, such as GMAC.

In Section 9, please say whether future registrations will allow integrity-without-confidentiality ciphersuites.  Let's settle this now instead of dumping on the IANA Expert.

For the reference to OCSP, please use RFC 6960 (not RFC 2560).

The document talks about certificates, so it should reference RFC 5280.


EDITORIAL SUGGESTIONS

The document uses "trust anchor" and "root certificate".  Please pick one.  I greatly prefer trust anchor for alignment with RFC 5280.

In Section 3, the text says: "This specification defines five messages." For me, it would have been helpful for the five to be listed here before the description of the flows.  I suggest: "This specification defines five messages: QueryRequest, QueryResponse, Update, Success, and Error."

In Section 4.2: s/Listing supporting SUIT commands/Listing supported SUIT commands/

In Section 4.2: s/by the TAM A value of 0/by the TAM. A value of 0/

In Section 4.3, it says:

   tc-manifest-sequence-number
      The minimum suit-manifest-sequence-number value from a SUIT
      manifest for the Trusted Component.  If not present, indicates
      that any version will do.

Please reword to clarify the meaning of "version".  Elsewhere in this document, version is talking about the TEEP protocol version, but that is not the meaning here.

Russ