Re: [Suit] A few comments on draft-ietf-suit-manifest-02

Brendan Moran <Brendan.Moran@arm.com> Tue, 04 February 2020 17: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 9420012013B for <suit@ietfa.amsl.com>; Tue, 4 Feb 2020 09:28:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=N5PVQ5GP; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=N5PVQ5GP
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 9sC30M_GhrSL for <suit@ietfa.amsl.com>; Tue, 4 Feb 2020 09:28:08 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70075.outbound.protection.outlook.com [40.107.7.75]) (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 CB1FB120131 for <suit@ietf.org>; Tue, 4 Feb 2020 09:28:07 -0800 (PST)
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=7fyK0ARlvGFggww5SUz7osurqlVKeJisZyNpHJrkUao=; b=N5PVQ5GPgIeowtzQ25Yo7KwgjnsopBukK1EbNfSc2WF0M9taiEjbGYSdVXT0sqTdG3m3IDoWDVcFUIXfER8FLSZPlilIgirNhTcEx1TqaXMLyylzyvKXPMzxH6i0vmF86IV3j46IAbGpx182eX8uvxEyvL5gF+5vPUmXOCLS0oI=
Received: from AM6PR08CA0017.eurprd08.prod.outlook.com (2603:10a6:20b:b2::29) by AM0PR08MB4371.eurprd08.prod.outlook.com (2603:10a6:208:13f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.30; Tue, 4 Feb 2020 17:28:04 +0000
Received: from VE1EUR03FT043.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::202) by AM6PR08CA0017.outlook.office365.com (2603:10a6:20b:b2::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.34 via Frontend Transport; Tue, 4 Feb 2020 17:28:04 +0000
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 VE1EUR03FT043.mail.protection.outlook.com (10.152.19.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.18 via Frontend Transport; Tue, 4 Feb 2020 17:28:03 +0000
Received: ("Tessian outbound 3a0cbd311638:v42"); Tue, 04 Feb 2020 17:28:03 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: c552c61a56f5813b
X-CR-MTA-TID: 64aa7808
Received: from 93d1cc98ee85.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 5B53200D-8114-4121-A3BD-EDAB909521A5.1; Tue, 04 Feb 2020 17:27:58 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 93d1cc98ee85.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 04 Feb 2020 17:27:58 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bqZrNQEtawR/7u0inj1Zx0i6Q7hf4ygrSv2LE1jwwIQyBh/FcGj4IHluJKE2e0OEr1W1XRiZZh7P8WV8egO1JVzMijpqofd8QBuVW8DMKBfw2COHpLZgp43alhRAxip7G1mFKvXQemNHbC5fnGsMWDYSWnGY1Ymnmi0YgSL017LrjVtC2Rc7f5xxLFgaXhPSKcWoUHU4nTc5MEcnDdRuzYP+4pDh9KR24DmcsxMAOLzSbQ80NZbi3a7+gD0Nk1vUgEyALPAZGbiTcbZ5hyHZJxbrqyBrgAo4G8d3RJ+4f9FbRSGlLvRlK4MxrKlW4xU1dQHUPPCqD8ZxmbY1a3Bm5g==
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=7fyK0ARlvGFggww5SUz7osurqlVKeJisZyNpHJrkUao=; b=E+GWG1x55qJWuCMcgUTy1iRzh5X3en6BVwiDkxujyQ6QSsbvgbNeu461pEwOpE/QI43lHdHZima/7qNmbuIIiHm1gCMgymPkvjzCxv7Ol6+J7f85Hn6A6VZ3WEIeRslvgp70zzO7GgKCWm2bWr0cL1dzGBqFkrGeyQ1+e5NC+/W2pbGMeVmE/we7CEkVbag8aj6RzA3S4tyNBxh1h1GdqvPzHBchCrKPHRdhNeieQKcF2d+1WCgcb6HiimRDxhmfJfBpMp9wU+A0x6LmeNycapBFKCmCZGygX82E4jctwCGKim3yDgToKJoPFD7Rpd82ehJNhl2Ot491KsjVoiUqpQ==
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=7fyK0ARlvGFggww5SUz7osurqlVKeJisZyNpHJrkUao=; b=N5PVQ5GPgIeowtzQ25Yo7KwgjnsopBukK1EbNfSc2WF0M9taiEjbGYSdVXT0sqTdG3m3IDoWDVcFUIXfER8FLSZPlilIgirNhTcEx1TqaXMLyylzyvKXPMzxH6i0vmF86IV3j46IAbGpx182eX8uvxEyvL5gF+5vPUmXOCLS0oI=
Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (10.255.99.138) by AM6PR08MB5191.eurprd08.prod.outlook.com (10.255.121.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Tue, 4 Feb 2020 17:27:56 +0000
Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::99bb:dd46:a0a0:562a]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::99bb:dd46:a0a0:562a%7]) with mapi id 15.20.2686.034; Tue, 4 Feb 2020 17:27:56 +0000
From: Brendan Moran <Brendan.Moran@arm.com>
To: Russ Housley <housley@vigilsec.com>
CC: suit <suit@ietf.org>
Thread-Topic: [Suit] A few comments on draft-ietf-suit-manifest-02
Thread-Index: AQHVz9kz5u0XLw+rkEGsl5GfPYTlgqgLYSyA
Date: Tue, 4 Feb 2020 17:27:56 +0000
Message-ID: <B528204B-3F34-4BF4-BACC-5B060F1FB11F@arm.com>
References: <4AA317F5-5D50-4A28-8259-D054BD6D6435@vigilsec.com>
In-Reply-To: <4AA317F5-5D50-4A28-8259-D054BD6D6435@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3601.0.10)
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com;
x-originating-ip: [84.9.246.204]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 820ab2f3-e161-4997-9a02-08d7a9979754
X-MS-TrafficTypeDiagnostic: AM6PR08MB5191:|AM0PR08MB4371:
X-Microsoft-Antispam-PRVS: <AM0PR08MB43718F10A03C771708977871EA030@AM0PR08MB4371.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 03030B9493
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(376002)(346002)(39860400002)(136003)(189003)(199004)(66446008)(64756008)(66476007)(66946007)(66556008)(76116006)(91956017)(33656002)(2906002)(316002)(4326008)(966005)(478600001)(6512007)(6486002)(26005)(186003)(8936002)(81156014)(81166006)(6916009)(8676002)(6506007)(53546011)(86362001)(71200400001)(5660300002)(2616005)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB5191; H:AM6PR08MB4738.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: CR/53Ch2NX70u6I06qTzrGgS5x6Q7zsDlqSvoNNqVMgNyaA9N4fb9IdIH7BHNC8hZa9BW7rFNdtpUHaN9YiojAeTnAgwWKLhUkc+HsdvL0kA6MlOXKOoVJja4LzsAuf0ch1qlW0AiG1CUq9O7iaY8Ucpc32ZsgFdGWxVg+B45xjPWHU1geoeYdyI60w1ralH10YL22gS8Z+gB3GTKU+5jAJQUMC0xVt0775X+EyQZLjsrSH1oHPZUTDWzbRtzv3CeOx1fLi8eoGV2WFAaEBKrAbWFQADacLv5IxN2pJqOK7XAJk+C7geIj5hfXTAEl6mA/nwOdZtQUhPCW9jHqKtXQSAmR6BpdCq+hmnsebCTynci6x9v30VA7+VnMrDYloNYk/7uFavz4S1Tgi4RtfMK8gjAmPRApmq5pJjonvI87/QCRE+XTOKMnFsXPJduVP9GViFY8pZgnc/34Y5fsvX/ivDYFwewJnLvJ6wscuxr6BZdbppLrSGNnwmST9i3Zmhp7NByM3rvdFSFXLKPkVnRg==
x-ms-exchange-antispam-messagedata: avSj96ndVOzt1dkJ1KWMw+lZ7TcUfc81L9GwN/jkpIgle5CyCJtomQ7GhsuU8iqSLEUIM6nw0aZ2rKF8ukd7RxfaJfKPESjTI0GERAhW6WRl2nnXQCkU2SpEsz831DZ87kNlJpWPcYLaDQZifd5vbw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_B528204B3F344BF4BACC5B060F1FB11Farmcom_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5191
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT043.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(376002)(39860400002)(189003)(199004)(2906002)(6862004)(81156014)(8936002)(4326008)(336012)(81166006)(356004)(316002)(26826003)(966005)(478600001)(45080400002)(33656002)(30864003)(6512007)(8676002)(186003)(33964004)(86362001)(70586007)(36756003)(70206006)(5660300002)(2616005)(6486002)(53546011)(26005)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB4371; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: e35aeb21-45aa-49c2-e23c-08d7a99792df
X-Forefront-PRVS: 03030B9493
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: AytVKu/2lafCQiYNPxU8ciNiqIzEcxnPWwYw6mxovacBmfyVJOm1IY5b2hXar69OalFt0ipQgRKoFgcXFn+Cnt8h7Ww76qT+Oe/PtB/QgXrW6wi/YPxATUT9FlUlXyj6rwB2peIM5REcRp0AhDUtXSN6adHC/Op23Wh//8+a+9Li8FOVFmDikMT/V2Qfw5/AO+eGA1HIb7n1U83Ee6tKj5sK47LcKHDMRlUs2aQbE6z54flk2BDXEoFkFK8+lPXZBa9vHppK8j90XMMkpciguxhbhChiWfPkPenaR5RNPQA3kOjBq0mSRyEX6EEhyhNSuH70QkkfR7yLrkyXoTO8LJLCd31H6ti7cW3Y5Gqr10MU9X8wat/FjBs8fX0kqAE2KwTOIglPpP5Dkz+0yAkNS2BR4FV3owdISJIoe4uXaNw6i3yTjzzdtnwUe6TxqqTMScdsnJ8T8QNQQSfkpEKSvtgX2jfz5zBGbFwXOrc275ruG8ap199SrWDiz/J84izrUUDsCf7sWtmqRgPXfV3cng==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Feb 2020 17:28:03.8670 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 820ab2f3-e161-4997-9a02-08d7a9979754
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: AM0PR08MB4371
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/v4BijHwPDWbVK5ULzf6TXQko_FI>
Subject: Re: [Suit] A few comments on draft-ietf-suit-manifest-02
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: Tue, 04 Feb 2020 17:28:12 -0000

Hi Russ,

Thanks again for your comments. I have finished most of the resulting updates. I’m planning to publish two versions in sequence to limit the diff noise. The first version will contain spelling and formatting updates. The second will contain changes of greater substance.

I have some proposals related to your comments on which I would like some feedback from the list. Please see comments and proposals inline.

Best Regards,
Brendan

On 20 Jan 2020, at 21:32, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> wrote:

I have a few comment on draft-ietf-suit-manifest-02:

General: The RFC Style Guide says to use American English spelling. Please change it now to avoid confusion later (e.g., Behaviour --> Behavior).

Section 2: Please add a sentence before all fo the definitions.  Otherwise, the "as shown here" from the RFC 8174 citation is easy to read incorrectly.

Section 2: The last 4 paragraphs are not really about conventions or terminology at the same level as the rest of the section.  They are CBOR specific, and I wonder if they would bit better toward the end of Section 4 or the beginning of Section 5 in a subsection of their own.

I have moved these to Section 7, which discusses CBOR format, since that seems most relevant.

Section 4: The bullets and numbered items in 4.1 end with periods, but the ones in 4.2 and 4.3 do not.  Please pick one style and use it everywhere.

Section 4.2: In the five steps, is there a problem if an implementations swaps steps 1 and 2?  If so, please explain.  If not, the document should say that conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. That is, any algorithm may be used by a particular implementation so long as it produces the correct result.

I’ve added a new section in response to this comment. Here’s the proposed text:

### Pre-Authentication Compatibility Checks

The RECOMMENDED process is to verify the signature of the manifest prior to parsing/executing any section of the manifest. This guards the parser against arbitrary input by unauthenticated third parties, but it costs extra energy when a device receives an incompatible manifest.

If a device:

1. expects to receive many incompatible manifests.
2. expects to receive few manifests with failing signatures--for example if it is behind a gateway that checks signatures.
3. has a power budget that makes signature verification undesirable.

Then, the device MAY choose to parse and execute only the SUIT_Common section of the manifest prior to signature verification. The guidelines in [Creating Manifests](#creating-manifests) require that the common section contain the applicability checks, so this section is sufficient for applicability verification. The manifest parser MUST NOT execute any command with side-effects outside the parser (for example, Run, Copy, Swap, or Fetch commands) prior to authentication and any such command MUST result in an error.



Section 4.2 says: "If verification and running is implemented in bootloader, then the".  Please complete the thought.

Section 4.4: I think that "specifies behaviours in a linearised form" can simply be "specifies linear behavior".

Section 4.4: I wonder if "authenticated by the appropriate identity have access to operate" is the right concept.  I think the point is that the process will reject software that is not authenticated to an identity on the ACL.

I’ve expanded this thought a bit:
Developing a robust permissions system works in this model too. The Recipient can use a simple ACL that is a table of Identities and Component Identifier permissions to ensure that operations on components fail unless they are permitted by the ACL. This table can be further refined with individual parameters and commands.

Section 5.1: RFC 4108 includes the concept of a "stale version".  Please see Section 1.2.3.2 of RFC 4108.  Do we want a capability to prevent roll-back to a previous version that has a disastrous flaw?

This is an important consideration. The simplest part of the change is to add a line in section 5.1 about receiving a critical flaw notice. We have a complex interplay between the two requirements: resilience and security.

The intent of the manifest sequence number is to prevent exactly this sort of situation. However, for resilience it is necessary for devices to be able to accept a manifest that is not the latest. This conflicts with the non-rollback requirements that is detailed in the information model.

So how do we revoke a particular manifest? And is it the manifest’s job to contain that information? It sounds suspiciously like CRLs. If we were to include “do not use” sequence numbers in manifests, that could cause a few problems:

  1.  What happens if there is a valid manifest which invalidates the only usable firmware, but fails to provide a new one, e.g. through connection errors?
  2.  What happens if a device misses the manifest that invalidates the flawed firmware?
  3.  Who is authorised to prevent a flawed firmware from being used? Is it only someone with rights to the targeted components? Or is someone else allowed to have those rights?

To me, it looks like the updater’s job to invalidate flawed firmware. The updater should have access rights to non-active firmware manifests—it may or may not have access to the active firmware manifest, depending on the system architecture. An updater can invalidate a flawed firmware simply by erasing its manifest.


Should we have a command to invalidate a manifest? If so, should it identify the manifest by digest or by sequence number?

Section 7: I find the numbering confusing.  the is a top-level "1" without a "2".  Perhaps typical outline numbering would be more clear.

Section 7 and 11: We need to come up with a presentation that will keep the line length under 73 characters.  Maybe something like:

  SUIT_Common = {
      ? suit-dependencies
            => bstr .cbor [ + SUIT_Dependency ],
      ? suit-components
            => bstr .cbor [ + SUIT_Component_Identifier ],
      ? suit-dependency-components
            => bstr .cbor [ + SUIT_Component_Reference ],
      ? suit-common-sequence
            => bstr .cbor SUIT_Command_Sequence,
  }


Section 12: Please say in the introduction what one-way hash function is used.

Section 13: Please provide the rules for additions to each of the IANA registries that are identified.

Russ



_______________________________________________
Suit mailing list
Suit@ietf.org<mailto:Suit@ietf.org>
https://www.ietf.org/mailman/listinfo/suit

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.