[Suit] Some proposals for updates to the SUIT manifest specification

Brendan Moran <Brendan.Moran@arm.com> Wed, 24 June 2020 11:28 UTC

Return-Path: <Brendan.Moran@arm.com>
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 2E8163A0D6A for <suit@ietfa.amsl.com>; Wed, 24 Jun 2020 04:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=74wrZW9o; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=74wrZW9o
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 EbbUsY-qVbg2 for <suit@ietfa.amsl.com>; Wed, 24 Jun 2020 04:28:50 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10045.outbound.protection.outlook.com [40.107.1.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EF23A0D69 for <suit@ietf.org>; Wed, 24 Jun 2020 04:28:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qbhjCs5LiySJREQJixynQy4VRmz2eCAM/AcufM7yijQ=; b=74wrZW9oI/jJNEpL+U08QOmHDi0jemJySHJuJCW0Z7Ls6yMjLH7Xgf9H6vTbbVMv8yfZeQfbp4jMwrEGq7gYynY6/xBJWemG/jPJrebqgT1eR30VT+LU5MN+8nDy+m5iwM47+wATgS3hoxCHZADMk58ew+W2WLId3NiRZ8ogs5w=
Received: from DB6PR0301CA0081.eurprd03.prod.outlook.com (2603:10a6:6:30::28) by AM5PR0801MB1665.eurprd08.prod.outlook.com (2603:10a6:203:3b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 24 Jun 2020 11:28:46 +0000
Received: from DB5EUR03FT045.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:30:cafe::a9) by DB6PR0301CA0081.outlook.office365.com (2603:10a6:6:30::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Wed, 24 Jun 2020 11:28:46 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT045.mail.protection.outlook.com (10.152.21.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Wed, 24 Jun 2020 11:28:46 +0000
Received: ("Tessian outbound 147ff5d152c1:v59"); Wed, 24 Jun 2020 11:28:46 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: dcebff8a5e79eedb
X-CR-MTA-TID: 64aa7808
Received: from 7083ecda894a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7D285E32-1836-4366-9BDB-491CDD46CBB1.1; Wed, 24 Jun 2020 11:28:40 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 7083ecda894a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 24 Jun 2020 11:28:40 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HXRvvhO035tAujlqzdP6Km19pdK2IczUoTGtJRDOqv0bpXkxHYM4DyeuP4qumQV3rFGmMiUfypxT0EZFGsAs+Ik0xD/ZgmwF8B5o9dfamqCJOsbiZkb+2hxrHGPqnfqspKB07WAliIifXvjQ9Ka1+PrTymDuUo1+mCzy3WSAmIwFcE7KvUHAsNbt9pU5d93UKG5pfY3LBqL6F4XfwkrLGGxTYunehrAcszaX+pS+Ao8E8s/T217hn9bqiYKgmS6jlQodS/2z2ycpaeDAZ0L4TNZiNdOeFh1CsoOTSUagd6exFKXYvO10pYPTSUtMNp+vlnnQNdh8n/u9UlMY0dp0hw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qbhjCs5LiySJREQJixynQy4VRmz2eCAM/AcufM7yijQ=; b=jVdSeiJ/HHk9pQkxCiYYTWSfMdsSL6Rxtt7Z05vBWGba7sSkWWio0CufZFR9OCboAB1pICilWTTakTgMpX9oTNx4HoJFjIEUfMP19nSWCaXk+ds/EKSZWQi1l9BjiastSym2aOuF/mHzPoUaNV1wXIOGqQpRR/ouyTAU07OguoR49Nq1/GKN3oSAZd7RBhFZ15kfre/3vyS08PeX5nVUJVovMdfDq0vRufGFteLBQ6N8TeQ1mBlgHmogr/rejO1LmMlaOQmgduZOI/0mJXsbTO98lqSnsyJvxEnO/KWtipEUZibPuXddDGafIfu+A7MCTSMBXsGWlPS3zf92dAUE9g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qbhjCs5LiySJREQJixynQy4VRmz2eCAM/AcufM7yijQ=; b=74wrZW9oI/jJNEpL+U08QOmHDi0jemJySHJuJCW0Z7Ls6yMjLH7Xgf9H6vTbbVMv8yfZeQfbp4jMwrEGq7gYynY6/xBJWemG/jPJrebqgT1eR30VT+LU5MN+8nDy+m5iwM47+wATgS3hoxCHZADMk58ew+W2WLId3NiRZ8ogs5w=
Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM5PR0801MB1745.eurprd08.prod.outlook.com (2603:10a6:203:3a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 24 Jun 2020 11:28:39 +0000
Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::208a:431d:b171:9615]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::208a:431d:b171:9615%3]) with mapi id 15.20.3131.020; Wed, 24 Jun 2020 11:28:39 +0000
From: Brendan Moran <Brendan.Moran@arm.com>
To: suit <suit@ietf.org>
CC: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Koen Zandberg <koen.zandberg@inria.fr>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Thread-Topic: Some proposals for updates to the SUIT manifest specification
Thread-Index: AQHWShqbFYlFIQ7qD0ivO12T8G5lDg==
Date: Wed, 24 Jun 2020 11:28:39 +0000
Message-ID: <AB1A6457-665A-44CE-8A62-AFB8100A1B36@arm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.80.23.2.2)
Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com;
x-originating-ip: [82.20.19.206]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 0227867d-b07e-4f7d-3cc2-08d81831c21a
x-ms-traffictypediagnostic: AM5PR0801MB1745:|AM5PR0801MB1665:
x-ms-exchange-transport-forked: True
X-Microsoft-Antispam-PRVS: <AM5PR0801MB1665CFFB022AE21B8D61A7F7EA950@AM5PR0801MB1665.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0444EB1997
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: +FO4tAnra09rIpTrB8BobsxE/uyt8C27C20xjZO2NsfsxqrRqjBTxPKQzTDQSFrO4nNOtYCYjNvwS/pdLf0FvBHvL3OB13T8mbeCmchmaUQiDoqaeyPiyc8Cm+lJT3zJLebuflRnqWAAdW9EwS1/9Y4RSSeBvNKe0Dafe+ZuGasTIFPa6WYx5X+l59DuXc904tTlmnHP1X/YD51Y9FAt2H46oCzJuWIRE7/TxR3hB4km/hK4R1JfNMVI3i3CFPQULOKsWYpkOHFwcb4slaFI6MYG0ToWloEe3llRgviRNZOHp3nK6SL+UDx4TuIBu0D4avKKeMvGiUXvXwJ8fmygXw==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(346002)(376002)(396003)(136003)(2616005)(4326008)(15650500001)(6916009)(66476007)(36756003)(71200400001)(33656002)(316002)(54906003)(6486002)(478600001)(83380400001)(6506007)(5660300002)(66446008)(6512007)(26005)(8936002)(186003)(66556008)(66946007)(86362001)(2906002)(8676002)(91956017)(76116006)(64756008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: YwWx05w22V48ZOrDbAF2116GJnzVqPx/YddMr7NZPLX+8caXAiAjSwQPZiU1QHT+gVe4pERr7CaUyDv6yXkyjadSdZmbLc7DkZKHqpxNk7LeL2H9eZcT2Bd+h21PROOWZ98n7hIdr+MiZEu2sMs81wmrOatnZdH8KSlpSJgxIq8FbybniCOzzwqNw/fXUMGqu2QGPRVlekuooyeRSTBjGxENVfpc4jq7KDJOk3uj0J+XK8TcdlBG03JeI+C9BCle6ojadQqF6dbj1DKqFk4tWpHk7pdqDrHIKx85D4N1dMsxv3CcqxXvMdcW+C3jSlGdJLALPY29tTg/Fp6IM9Or03xw5cbNoromoMrBPIblZmNhSTQbQTrLHa8Cdn5eTAUViliQbxMtOsLCSri6Vno4r1qx4mWaah5fqmN8WyzvtDHyChMdW7QBGcHA5xz+1AISmX0gGD0CHJ49ZWzG2JCpGgUSjbJXNcLBZeWVhCayNQo=
Content-Type: text/plain; charset="utf-8"
Content-ID: <ADE27B0DA86FCA4C8077417E0F607FD7@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1745
Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT045.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(46966005)(6506007)(2616005)(6916009)(86362001)(15650500001)(186003)(26005)(5660300002)(70586007)(356005)(81166007)(83380400001)(70206006)(2906002)(82310400002)(47076004)(498600001)(33656002)(336012)(8676002)(4326008)(54906003)(36756003)(6512007)(6486002)(8936002); DIR:OUT; SFP:1101;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 4c3b801b-b593-4aa0-3926-08d81831bde8
X-Forefront-PRVS: 0444EB1997
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: m3haxFex2qNtruczc47X43Yk1Yt5nLYifbv9xIcAPABB6S7DCPGDj5IsRZ0Ls2+Goil3cp1H80SkRIvzbokb7J/2Rsrf1YYILX9d+wgDl8ND6h+Kg9wvWljML0WUcbIBmsCW9pqxf2MSRVwsofRW5BcuidvYQZ3ZDx3op88l+wQ1Df+uWoWz8jOc7m/uVjYxvMpOYmFBezE7zp+DXQS4UT0DrkyMy+awbW9p2caOAYpsrtYKFFcRtNe1PSt/MZvfbRLRMtYYLDtHsR4/Qmf6iL6HSRo9FqWFtWHZXzu/nQ7xD/JtUmBSJR180IfwNpNwi6XpLRsyr9hYQuA0tZkAQzqk1C2QPTje3s4yedqvUWmkZ1UzJlJqwtScGVyHx75rq73ooXIVDKAIvSHjjurQYw==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2020 11:28:46.1808 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0227867d-b07e-4f7d-3cc2-08d81831c21a
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1665
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/cVU6asesWlU7K5fXUTO9hnctoRg>
Subject: [Suit] Some proposals for updates to the SUIT manifest specification
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 24 Jun 2020 11:28:52 -0000

The other authors and I have been working on refining the specification and filling in some empty parts. There are three topics we’d like to discuss with the working group: First, the text section. Second, the list of Dependency Components. Finally, bstr wrapped fields.



The text section has been misaligned with the rest of the document since multiple components were introduced. Currently, there’s no way to provide a list of component versions, for example. To remedy this, we're proposing a small change to the text section. Today, the text section says:

> SUIT_Text_Map = {SUIT_Text_Keys => tstr}

This should really be:

> SUIT_Text_Map = { SUIT_Text_Keys }
> SUIT_Text_Keys = (
>  ? suit-text-manifest-description => text,
>  ? suit-text-update-description => text,
>  ? suit-text-vendor-name => text,
>  ? suit-text-model-name => text,
>  ? suit-text-vendor-domain => text,
>  ? suit-text-model-info => text,
>  ? suit-text-component-description => text,
>  ? suit-text-manifest-json-source => text,
>  ? suit-text-manifest-yaml-source => text,
>  * $$suit-text-key-extensions)
> )


Notice that there is only one component-specific field, but it is plain text. This is a poor match for the current structure of the suit manifest.

Here is our proposal to correct the mismatch between the manifest and the text section:

> SUIT_Text_Map = {
>  * SUIT_Component_Identifier => { SUIT_Text_Component_Keys },
>  SUIT_Text_Keys,
> }

This will allow any set of components to be described.



The second point is Dependency Components. This information element was introduced to help distinguish between components that are defined in the current manifest and those that are defined by its dependencies. This is a loose definition, however, and I don’t believe that it fits the current definition of the manifest. I believe we should remove Dependency Components. There are two consequences of this action:

1) A parser must validate that all components of a given interdependent set are specified in a given tree of manifests. This was necessary anyway due to Access Control requirements: A parser cannot trust the root manifest to list all components if the signer of that manifest does not have access rights for every component. The result is that this makes the security story clearer.

2) A parser cannot inspect the root manifest to determine whether it can handle enough components to process all component IDs simultaneously. The same security considerations as 1) apply here: the list could only ever have been treated as a hint, it had to be verified during tree traversal. To resolve the missing component count evaluation, The parser can compute the number of required components during either the dependency resolution step (Update flow) or the system validation step (Secure boot flow) in order to test whether it has sufficient memory to handle the components in parallel, or if it must handle them sequentially.



Finally, I have a question regarding the fields wrapped in byte strings. Are the byte strings necessary? I’d like to hear from those who have implemented the specification. Are the byte strings helpful? Or are they pain points?

Here is the justification for them that I drafted to add to the design rationale section of the specification:

> Byte string wrappers are used in several places in the suit manifest. The primary reason for wrappers it to limit the parser extent when invoked at different times, with a possible loss of context.
>
> The elements of the suit envelope are wrapped both to set the extents used by the parser and to simplify integrity checks by clearly defining the length of each element.
>
> The common block is re-parsed in order to find components identifiers from their indices, to find dependency prefixes and digests from their identifiers, and to find the common sequence. The common sequence is wrapped so that it matches other sequences, simplifying the code path.
>
> A severed SUIT command sequence will appear in the envelope, so it must be wrapped as with all envelope elements. For consistency, command sequences are also wrapped in the manifest. This also allows the parser to discern the difference between a command sequence and a SUIT_Digest.
>
> Parameters that are structured types (arrays and maps) are also wrapped in a bstr. This is so that parser extents can be set correctly using only a reference to the beginning of the parameter. This enables a parser to store a simple list of references to parameters that can be retrieved when needed.


My opinion on each of the bstrs is:

1) We must keep the bstr wrappers around all envelope elements.
2) I think we should keep the bstr around structured parameters (Arrays/Maps). This is very useful for late parsing of parameters because they do not always live within the extent of the current manifest.
3) I’m not entirely sure we should keep the bstr wrapper around the common block, but I think it’s useful. It always lives within the extent of the current manifest, so overruns will be detected on the first pass by the parser, and the extent of the common block can be recorded prior to the execution of any command sequences.
4) I would not argue against removing the bstr wrappers around command sequences, provided that we register a tag for either the command sequence or the SUIT Digest.
5) I think we could safely remove the bstr wrappers around the elements inside of the common block, including the command sequence. This incurs a negligible execution time overhead when accessing some common elements, but produces manifests that are a few bytes smaller.



We would very much appreciate input on each of these three topics. Unless there are strong objections, we will modify the text section as described and remove the Dependency Components list. The status of the bstr wrappers is less clear, so we will wait for feedback.

Best Regards,
Brendan



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.