Re: [Suit] Introducing draft-moran-suit-manifest-04

Rønningstad, Øyvind <Oyvind.Ronningstad@nordicsemi.no> Fri, 21 June 2019 08:32 UTC

Return-Path: <Oyvind.Ronningstad@nordicsemi.no>
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 23944120186 for <suit@ietfa.amsl.com>; Fri, 21 Jun 2019 01:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level:
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.onmicrosoft.com
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 9HKMaNuMc-kj for <suit@ietfa.amsl.com>; Fri, 21 Jun 2019 01:32:03 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60061.outbound.protection.outlook.com [40.107.6.61]) (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 C517D12017E for <suit@ietf.org>; Fri, 21 Jun 2019 01:32:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.onmicrosoft.com; s=selector2-nordicsemi-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HeUwgKVc//LxKb8AYdAdyi7opE0BB/2hNZioMAzKchc=; b=pivFMmRkY8nRqkGE1ARr+MGJR4Zr8gwI64YCHM4VBqptb7XOhU0hsEEUSVCgjuWsQq1AuamuefHekmS8TkW/FdAOKA4RFJx9tHLI8KGWc8Y4SCMEoS0gECJTABWQ0t8fFPg/pwEzsIyUr5lBwO6ZvcYmZMT9dCl8KZTwPtz8NrA=
Received: from HE1PR05MB3228.eurprd05.prod.outlook.com (10.170.243.14) by HE1PR05MB3498.eurprd05.prod.outlook.com (10.170.244.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.15; Fri, 21 Jun 2019 08:31:58 +0000
Received: from HE1PR05MB3228.eurprd05.prod.outlook.com ([fe80::3db5:a53:23b9:4233]) by HE1PR05MB3228.eurprd05.prod.outlook.com ([fe80::3db5:a53:23b9:4233%7]) with mapi id 15.20.1987.014; Fri, 21 Jun 2019 08:31:58 +0000
From: =?utf-8?B?UsO4bm5pbmdzdGFkLCDDmHl2aW5k?= <Oyvind.Ronningstad@nordicsemi.no>
To: Brendan Moran <Brendan.Moran@arm.com>
CC: suit <suit@ietf.org>, =?utf-8?B?S3ZhbXRyw7gsIEZyYW5rIEF1ZHVu?= <frank.kvamtro@nordicsemi.no>
Thread-Topic: Introducing draft-moran-suit-manifest-04
Thread-Index: AQHU2L81dzELNCQKcEaCHfQ8cPehA6Y2x2+wgABw2OCAYxNsgIAMA9ew
Date: Fri, 21 Jun 2019 08:31:58 +0000
Message-ID: <HE1PR05MB32285F303789FF86E4080C5B88E70@HE1PR05MB3228.eurprd05.prod.outlook.com>
References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> <HE1PR05MB32285B66AB7015921D83F852882F0@HE1PR05MB3228.eurprd05.prod.outlook.com> <HE1PR05MB32285EE3C40D73345D217935882F0@HE1PR05MB3228.eurprd05.prod.outlook.com> <45E47993-636B-4275-B3D8-1885F23BECAC@arm.com>
In-Reply-To: <45E47993-636B-4275-B3D8-1885F23BECAC@arm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Oyvind.Ronningstad@nordicsemi.no;
x-originating-ip: [2001:8c0:5140:12:81ff:e6e0:2da3:8526]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8542e0f3-e4b7-4f62-bb9e-08d6f622ecf2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR05MB3498;
x-ms-traffictypediagnostic: HE1PR05MB3498:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <HE1PR05MB349886EE9FD3727DE82D4DE888E70@HE1PR05MB3498.eurprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0075CB064E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(136003)(366004)(376002)(346002)(199004)(51914003)(189003)(54896002)(14454004)(966005)(8936002)(9686003)(74482002)(236005)(85182001)(6246003)(53936002)(76116006)(6436002)(99286004)(6506007)(53546011)(229853002)(186003)(6306002)(55016002)(316002)(54906003)(6116002)(7696005)(66556008)(64756008)(66446008)(2906002)(102836004)(66946007)(790700001)(68736007)(478600001)(66574012)(14444005)(52536014)(6916009)(73956011)(71200400001)(476003)(86362001)(71190400001)(11346002)(66476007)(76176011)(85202003)(256004)(5660300002)(107886003)(8676002)(33656002)(81166006)(74316002)(81156014)(7736002)(25786009)(4326008)(46003)(446003)(606006)(486006)(72206003)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR05MB3498; H:HE1PR05MB3228.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nordicsemi.no does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: a6HUeVooQBlbQqeE+IXlOL6lvWqEFNFWcdJHBb2yh9vp+FUPJy8raxiWij1ZXE9+OrN182DTim63p8rbW6boK4fy1UiRsS/MoRhEXS/hl9LWyflzqmoWZI4LieTyAfqHREBocxF1eIrhiG9+u8cnLzDt6ctu/EyGDIrupM5UCnrM+SiQI8gZSnucNJx8OcyRut8Pe9DCQsuuG0x2s63l0m3NhEKTGJ4TVQl/WA32jo2JwH9tDOyeY8S2w0SJewIABx0jst/mh1K+5fqJ13zHQwYY/aWeNc72rHrbDTEP5CdCrBtQO6LAwOFeN2AurtBbuD1BS2chze2h6z40aSV+SK/c1iCk0QRsgS3FYlHlwdRc/3W5nYwj4xy5GKrgMUPmVXFMys31Poy0qw6de1ojQeZxhrW88DLX1Z60UsrgS30=
Content-Type: multipart/alternative; boundary="_000_HE1PR05MB32285F303789FF86E4080C5B88E70HE1PR05MB3228eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nordicsemi.no
X-MS-Exchange-CrossTenant-Network-Message-Id: 8542e0f3-e4b7-4f62-bb9e-08d6f622ecf2
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2019 08:31:58.2676 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 28e5afa2-bf6f-419a-8cf6-b31c6e9e5e8d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oyvind.ronningstad@nordicsemi.no
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR05MB3498
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/I2qiM0eruri9MfAIRG4O2SnVO-I>
Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04
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: Fri, 21 Jun 2019 08:32:08 -0000

Hi Brendan, thanks for the in-depth answers. I have some more questions/comments below.

Thanks,
Øyvind

From: Brendan Moran <Brendan.Moran@arm.com>
Sent: Thursday, June 13, 2019 17:42
To: Rønningstad, Øyvind <Oyvind.Ronningstad@nordicsemi.no>
Cc: suit@ietf.org; Kvamtrø, Frank Audun <frank.kvamtro@nordicsemi.no>
Subject: Re: Introducing draft-moran-suit-manifest-04

The algorithm identifiers are borrowed directly from the Naming Things with Hashes RFC (RFC 6920). https://www.iana.org/assignments/named-information/named-information.xhtml. If possible, I would like to avoid constructing another IANA registry for digest algorithm identifiers. I confess, I do find it a bit strange that RFC 6920 has IDs for SHA3-224 and SHA256-128, but not for SHA224. If we need to construct a new registry, so be it, however I would rather not. Perhaps there is another digest algorithm registry that is appropriate?

Why do we need an IANA registry? I imagine two possible reasons, both of which are invalid in my opinion (for this case):

  1.  As a source of algorithm identifiers (numbers). Since we create our own type (SUIT_Digest), there’s nothing to retain compatibility with. Doesn’t this make the numbers arbitrary?
  2.  So the list will be curated without the need to make new RFCs. This would indeed be good to have. The thing is that RFC 6920 contains algorithms that should NEVER EVER be used by SUIT implementations, so they should not be part of SUIT_Digest. This means we need to curate the curated list, which makes using the Named Information registry no better than not using a registry. This is obvious when looking at the goals of the registry (naming things), compared to our goal (security): They don’t align at all.
If you want to take IDs from the registry, that’s no problem, but do remove the algorithms known to be insecure. It’s not worth the chance that even a single user uses them.

One solution is to amend the Named Information registry so it also covers security use cases. I think this was mentioned by David Waltermire.
Another solution is to follow TLS’s recommendations, or to copy their process of specifying exactly what combinations of algorithms are supported in each version.
If we create or amend a registry ourselves, we should probably attempt to cooperate with other WGs, since such a registry would be useful beyond just SUIT.


Currently, the design calls for manifests to be referenced by digest. If that is the case, then a manifest’s digest (and, therefore, sequence number) must be known at time of creation. For fuzzy dependencies, such as those based on version matching, the direct dependency mechanism clearly doesn’t work. This was originally modelled as mutually independent components (those that are not updated together). Does this need to be made more explicit, or does it require a new or modified dependency mechanism?

I think I misunderstood the purpose of the version condition. So to clarify: Version conditions are checked only against existing components? That makes sense for upgrade manifests, but how do you envision it for when SUIT is used for boot manifests?


The purpose of suit-dependency-components is to enumerate the components that are described by the dependencies. This may or may not be necessary. As I have described it in draft-moran-suit-manifest-04, it is a list of all components that are affected by all dependencies. This is useful for three reasons: 1) it allows the device to evaluate whether or not it implements the targeted components prior to downloading the whole manifest tree, 2) for a single-pass processor, it allows the device to verify that it has enough storage to store the variables that will be used by each component. For a multi-pass processor, it allows the device to iterate through affected components, handling each one in turn.

There are tradeoffs here. If many components are listed in a deeply nested tree, it will make the top-level manifest enormous. This is a problem that is not well-addressed by this model. It was chosen for small numbers of components in a small tree on small devices. We may need to consider whether it will continue to be the correct choice for larger systems. Perhaps we should consider the option of making the field optional and specifically for multi-pass processors.

I haven’t thought deeply about it, but making it optional makes sense to me.


I think there's a quirk with the versions where comparisons can be subverted. If you have a dependency on version 1.x of something, it's hard (impossible in the general sense) to express those bounds with the greater/lesser comparisons. This is because there is no well-defined highest or lowest version with a given prefix such as "1." (unless the version list has bounded length).  If you have a bound on the length of the version list, you could express the upper bound e.g. as "Lesser or equal than 1.INTMAX.INTMAX..." etc. which isn't very pretty. Can we find some better way? I'm assuming 1.1 is equivalent (equal) to 1.1.0 etc.

I’m not sure I understand the problem. The test is: >=1,<2. In this instance, any version that has a prefix >=1 will pass that comparison, and any version that has a prefix <2 will pass that part of the comparison. The number of elements in the list to process is assumed to be defined by the test.

Ok, so when comparing versions with different lengths, the longest is to be truncated? That does indeed solve the problem nicely. That rule should be explicit in the document (I assumed incorrectly that the shortest was to be padded with 0s). To make sure I understand: Could I actually achieve my example with a single condition: ==1?