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

Russ Housley <housley@vigilsec.com> Tue, 04 February 2020 17:43 UTC

Return-Path: <housley@vigilsec.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 8EAC21208BC for <suit@ietfa.amsl.com>; Tue, 4 Feb 2020 09:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 Z8t9XwnmEVQN for <suit@ietfa.amsl.com>; Tue, 4 Feb 2020 09:43:44 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8BE1208A6 for <suit@ietf.org>; Tue, 4 Feb 2020 09:43:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5FC79300B06 for <suit@ietf.org>; Tue, 4 Feb 2020 12:17:02 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LsMkEKyDE9LV for <suit@ietf.org>; Tue, 4 Feb 2020 12:17:00 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id C26A030046F; Tue, 4 Feb 2020 12:17:00 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <75EE8839-D7A8-4DAF-B4CF-951839FA6E53@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B060D215-85DE-4C87-A458-DA40DA00FC16"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 4 Feb 2020 12:43:41 -0500
In-Reply-To: <B528204B-3F34-4BF4-BACC-5B060F1FB11F@arm.com>
Cc: suit <suit@ietf.org>
To: Brendan Moran <Brendan.Moran@arm.com>
References: <4AA317F5-5D50-4A28-8259-D054BD6D6435@vigilsec.com> <B528204B-3F34-4BF4-BACC-5B060F1FB11F@arm.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/PtFNCKgSq14R2lWRyoS5JC386Ik>
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:43:49 -0000

Brendan:

>> 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:
> 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?
> What happens if a device misses the manifest that invalidates the flawed firmware?
> 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? 

Rollback is needed because mistakes happen.  The ability to mark some old manifest as stale is needed because mistakes happen.

I'd like to see a mechanism that does not have any linkage to the storage or distribution model of manifests.  For that reason, I would like to see a command that implements "rollback prevented for sequence numbers before" X.

Russ