IETF Logo Mail Archive

Re: [Suit] Dependency index

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 29 September 2022 12:27 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07BBC14CE39 for <suit@ietfa.amsl.com>; Thu, 29 Sep 2022 05:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL3B__ZMU7Zc for <suit@ietfa.amsl.com>; Thu, 29 Sep 2022 05:27:23 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61810C14F693 for <suit@ietf.org>; Thu, 29 Sep 2022 05:27:23 -0700 (PDT)
Received: from dooku.sandelman.ca (host-87-4-189-54.retail.telecomitalia.it [87.4.189.54]) by relay.sandelman.ca (Postfix) with ESMTPS id 2A91F1F455; Thu, 29 Sep 2022 12:27:22 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id A5E6E1A0753; Thu, 29 Sep 2022 14:27:21 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brendan Moran <brendan.moran.ietf@gmail.com>, "suit@ietf.org" <suit@ietf.org>
In-reply-to: <CAPmVn1M7kiq+4DpxE+exXox0N1Lbe_6BX4bC5DP4xyKoV_fYmA@mail.gmail.com>
References: <AM9PR05MB7668E6AB4E64EB56A55B1F6088519@AM9PR05MB7668.eurprd05.prod.outlook.com> <CAPmVn1OD8Fs7AnJPpmyLojPxfzs0XujnC7b9HAF9f4kYb7Ot0Q@mail.gmail.com> <92479.1664363403@dooku> <CAPmVn1M7kiq+4DpxE+exXox0N1Lbe_6BX4bC5DP4xyKoV_fYmA@mail.gmail.com>
Comments: In-reply-to Brendan Moran <brendan.moran.ietf@gmail.com> message dated "Thu, 29 Sep 2022 12:11:41 +0100."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 29 Sep 2022 14:27:21 +0200
Message-ID: <32925.1664454441@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/HpCpjyNbqbqYXo32Mpbn1-T5UMI>
Subject: Re: [Suit] Dependency index
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2022 12:27:27 -0000

what a great email!

Brendan Moran <brendan.moran.ietf@gmail.com> wrote:
    > I mean that, due to supply-chain considerations the least trusted nodes
    > in a manifest tree are closest to the root, or indeed the root itself,
    > while the most trusted nodes are typically leaves. This means that, due
    > to implementation considerations in the manifest processor, less
    > trusted nodes in the tree invoke "process dependency" on more trusted
    > nodes, effectively choosing whether and when to invoke a more trusted
    > node's command sequence. This is effectively a privilege inversion--and
    > acknowledged as such from the beginning. The result was adding the
    > manifest processor required checks.

okay, I get this inversion now.

...
    > I think that if we move forward on giving dependency manifests
    > component IDs, there will be several required changes to the existing
    > format and workflows

At this point, I couldn't follow anymore,because I lack the deep
implementation experience required :-(

    > I don't think these requirements are too onerous. This could
    > potentially simplify implementations of multiple trust domains quite a
    > bit since it removes the need for a secure key/value store. I think the
    > requirements above do deal with the potential security consideration I
    > was discussing earlier.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email