Re: [Suit] [EXTERNAL] Improvements to draft-moran-suit-manifest-03

Cody Addison <c-addison@ti.com> Thu, 07 February 2019 22:52 UTC

Return-Path: <c-addison@ti.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 7E6CE130EB0 for <suit@ietfa.amsl.com>; Thu, 7 Feb 2019 14:52:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ti.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 yHtNipjEfa90 for <suit@ietfa.amsl.com>; Thu, 7 Feb 2019 14:52:05 -0800 (PST)
Received: from fllv0015.ext.ti.com (fllv0015.ext.ti.com [198.47.19.141]) (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 EC151130EB1 for <suit@ietf.org>; Thu, 7 Feb 2019 14:52:04 -0800 (PST)
Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id x17MpwSL023129; Thu, 7 Feb 2019 16:51:58 -0600
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1549579918; bh=3LQ/7eZUce1UEfg9krO5czzdZwOSim+LYXkSza43Uxk=; h=References:From:To:CC:Subject:In-Reply-To:Date; b=yosIPeq+woKqvtiyVbLQ1GtXCAGl+/WnDxGF37DQnqX70Ev9XKp7OG5K0Q5/7cqb5 Q+rFs5KRsLMgP+784kDHyi+MOnAvpTvb20X4ogvpTQNvXGy8UHJbg55jANGRWdK6lF QmhmCakYbDkIZQpNCQF5YvIZPorPqkWY+wiy/ZxY=
Received: from DLEE103.ent.ti.com (dlee103.ent.ti.com [157.170.170.33]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x17Mpw5v041379 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 Feb 2019 16:51:58 -0600
Received: from DLEE113.ent.ti.com (157.170.170.24) by DLEE103.ent.ti.com (157.170.170.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 7 Feb 2019 16:51:58 -0600
Received: from dlep33.itg.ti.com (157.170.170.75) by DLEE113.ent.ti.com (157.170.170.24) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1591.10 via Frontend Transport; Thu, 7 Feb 2019 16:51:58 -0600
Received: from LC02T30BGGTFM (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id x17MpvoO018586; Thu, 7 Feb 2019 16:51:57 -0600
References: <78FF2A20-1AF3-425F-B4BB-6F520E85DE46@arm.com>
User-agent: mu4e 1.1.0; emacs 26.1
From: Cody Addison <c-addison@ti.com>
To: Brendan Moran <Brendan.Moran@arm.com>
CC: "suit@ietf.org" <suit@ietf.org>, "hannes.tschofenig@gmx.net" <hannes.tschofenig@gmx.net>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
In-Reply-To: <78FF2A20-1AF3-425F-B4BB-6F520E85DE46@arm.com>
Date: Thu, 07 Feb 2019 16:51:57 -0600
Message-ID: <m1sgwzw6sy.fsf@ti.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/ba8hL4MVtUAAmMZ-AIweqhFnPMs>
Subject: Re: [Suit] [EXTERNAL] Improvements to draft-moran-suit-manifest-03
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: Thu, 07 Feb 2019 22:52:07 -0000

Brendan,

Thanks for the update. I agree with the changes and think they make the spec easier to understand. I have two followup questions:

How do you propose embedding payloads in the manifest? Is the plan to handle this in the payload-installation-info referenced below or do you have another proposal?

When do you plan on releasing manifest version 4? I have a need to deliver a prototype SUIT container in the next few months and would like to base it off version 4.

Brendan Moran writes:

> Following IETF103, I have been collecting more use cases and user stories to influence the development of the manifest.
>
> Three points have become very clear:
>
> First, the processing tree is too complicated. There are many possible configurations that would never be used. There is plenty of room for error. In reality, the configurations that seem to be usable are all the combinations of these three operations:
> * decrypt
> * decompress
> * unpack (delta, relocate, hex, etc.)
>
> I have yet to find a use-case where these operations do not appear in this order, or where there is another operation that is missing from this list.
>
> That being the case, a processing tree, while very general-purpose is extra overhead that is not needed. With that in mind, I would like to propose changing the payload model back to something more conventional.
>
> The payload-installation-info structure contains information about
> * where to store the firmware image (install-component),
> * where to retrieve it (uris),
> * whether the firmware image is encrypted and with what algorithm (encrypt-info),
> * whether a compression algorithm has been applied to the firmware image and what algorithm has been used (compression-algorithm),
> * whether the image is a binary diff or requires relocation (unpack), and
> * an indication whether these fields may be overridden by an authorized party (allow-override).
>
> Here is a proposed CDDL snippet for draft-moran-suit-manifest-04:
>
> payload-installation-info = {
>    install-component => component-identifier,
>    ? allow-override => bool,
>    ? uris => uri-list,
>    ? encrypt-info => COSE_Encrypt0 / COSE_Encrypt,
>    ? compression-algorithm => compression-algorithm-ids,
>    ? unpack => [
>        unpack-algorithm : unpack-algorithm-ids, ; binary diff, or relocation, or binary-to-text algorithm identifier
>        ? unpack-arguments : bytes                 ; private config for the unpack algorithm selected
>    ]
> }
>
> This should be much easier to understand and implement.
>
>
> The second point is that regen-info is frequently misunderstood and misused. After some discussion with suit participants, it’s become clear that the regen-info block should be represented as a dedicated “digest algorithm” which solves the same problem as the regen-info block currently does. When incorporated with the changes recommended by Jim Schaad, the result is that we replace COSE_Digest with SUIT_Digest and we remove regen-info. Here is a CDDL snippet that represents SUIT_Digest:
>
> SUIT_Digest = [
>    digest-algorithm-id: int,
>    digest: bytes,
>    ? digest-extra-info: bytes
> ]
>
> Any needed regen-info can then be contained in the digest-extra-info section with an appropriate algorithm identifier.
>
>
> The third point of clarity is that we need to do some work in making the manifest easier to parse and process in a constrained environment. I don’t have a simple change to enable that, but we’re working on it.
>
> 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.
> _______________________________________________
> Suit mailing list
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit