Re: [Fud] Editorial Charter Update

Carsten Bormann <cabo@tzi.org> Wed, 04 October 2017 17:31 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: fud@ietfa.amsl.com
Delivered-To: fud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8981A132076 for <fud@ietfa.amsl.com>; Wed, 4 Oct 2017 10:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 1i1pwN0oqHK2 for <fud@ietfa.amsl.com>; Wed, 4 Oct 2017 10:31:31 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 74B091326ED for <fud@ietf.org>; Wed, 4 Oct 2017 10:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v94HVRnU018236; Wed, 4 Oct 2017 19:31:27 +0200 (CEST)
Received: from [10.0.4.24] (unknown [94.142.34.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y6jcZ3l0LzDLD8; Wed, 4 Oct 2017 19:31:26 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail-D349A029-3335-4259-AF13-981FA0EECB54"
Mime-Version: 1.0 (1.0)
From: Carsten Bormann <cabo@tzi.org>
X-Mailer: iPhone Mail (15A402)
In-Reply-To: <578DD8B8-E786-4913-AE6A-65FFA29019AD@vigilsec.com>
Date: Wed, 04 Oct 2017 20:31:21 +0300
Cc: "Fud@ietf.org" <fud@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <FD3975C8-C252-4E70-8D96-29918FC0DAB3@tzi.org>
References: <c14c92bf-cf99-efdb-6693-0e33519fbb0a@gmx.net> <578DD8B8-E786-4913-AE6A-65FFA29019AD@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/XPs46jA7K6EbNwYislwNzWIdKq8>
Subject: Re: [Fud] Editorial Charter Update
X-BeenThere: fud@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <fud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fud>, <mailto:fud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fud/>
List-Post: <mailto:fud@ietf.org>
List-Help: <mailto:fud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fud>, <mailto:fud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Oct 2017 17:31:33 -0000

Hi Russ, 

I had a comment about a possible misunderstanding of the FUD/suit WG being misunderstood as the rfc4108 bug fixing and tweaking WG. I'm not sure that had been addressed. I'm mostly offline in the next seven days or so. 

Sent from mobile

> On 3. Oct 2017, at 16:43, Russ Housley <housley@vigilsec.com> wrote:
> 
> Here is an update to the charter text based on the comments.
> 
> Note that the WG name is still FUD.  Any name change will be handled by the IESG.
> 
> Russ
> 
> = = = = = = =
> 
> Firmware Updating Description (FUD)
> [Alternative proposal: SUIT (Software Updates for Internet of Things)]
> 
> Vulnerabilities in Internet of Things (IoT) devices have raised the
> need for a secure firmware update mechanism that is also suitable for
> constrained devices.  Security experts, researchers, and regulators
> recommend that all IoT devices be equipped with such a mechanism.  While
> there are many proprietary firmware update mechanisms in use today, there
> is a lack of a modern interoperable approach of securely updating the
> software in IoT devices.
> 
> A firmware update solution consists of several components, including:
>  *  A mechanism to transport firmware images to IoT devices.
>  *  A manifest that provides meta-data about the firmware image
>     (such as a firmware package identifier, the hardware the package
>     needs to run, and dependencies on other firmware packages), as
>     well as cryptographic information for protecting the firmware
>     image in an end-to-end fashion.
>  *  The firmware image itself.
> 
> RFC 4108 provides a manifest format that uses the Cryptographic Message
> Syntax (CMS) to protect firmware packages.
> 
> More than ten years have passed since the publication of RFC 4108, and
> greater experience with IoT deployments has lead to additional
> functionality, requiring the work done with RFC 4108 to be revisited.
> The purpose of this group is to produce a second version of RFC 4108
> that reflects the current best practices.  This group will focus on
> defining a firmware update solution for Class 1 devices, as defined in
> RFC 7228, that is -- IoT devices with ~10 KiB RAM and ~100 KiB flash.
> This group will not define any transport mechanisms.
> 
> In June of 2016 the Internet Architecture Board organized a workshop on
> 'Internet of Things (IoT) Software Update (IOTSU)', which took place at
> Trinity College in Dublin, Ireland.  The main goal of the workshop was
> to foster a discussion on requirements, challenges, and solutions for
> bringing software and firmware updates to IoT devices.  This workshop
> also made clear that there is a lack of regulatory requirements, which
> contributes to challenges associated with misaligned incentives.  It is
> nevertheless seen as important to create standard building blocks that
> help interested parties implement and deploy a solid firmware update
> mechanism.
> 
> In particular this group aims to publish three documents, namely:
>  *  An IoT firmware update architecture that includes a description of
>     the involved entities, security threats, and assumptions.
>  *  The manifest format.
>  *  A revision to RFC 4108 that reflects the current best practices.
> 
> This group will use draft-moran-fud-architecture as a starting point for
> discussion of the "Architecture" document.
> 
> This group will use draft-moran-fud-manifest as a starting point for
> discussion of the "Manifest Format" specification.
> 
> This group does not aim to create a standard for a generic software
> update mechanism for use by rich operating systems, like Linux, but
> instead this group will focus on software development practices in the
> embedded industry.  "Software update solutions that target updating
> software other than the firmware binary (e.g. updating scripts) are
> also out of scope.
> 
> This group will aim to develop a close relationship with silicon vendors
> and OEMs that develop IoT operating systems.
> 
> 
> Milestones:
> 
> Dec 2017     Submit RFC 4108bis document as WG item.
> 
> Dec 2017     Submit "Architecture" document as WG item.
> 
> Dec 2017     Submit "Manifest Format" specification as WG item.
> 
> Jul 2018     Submit "Architecture" to the IESG for publication as an
>             Informational RFC.
> 
> Nov 2018     Submit RFC 4108bis document to the IESG for publication as
>             a Proposed Standard.
> 
> Nov 2018     Submit "Manifest Format" to the IESG for publication as
>             a Proposed Standard.
> 
> 
> Additional calendar items:
> 
> Mar 2018     Release initial version of the manifest creation tools as
>             open source.
> 
> Apr 2018     Release first version of manifest test tools as open
>             source.
> 
> Jun 2018     Release first IoT OS implementation of firmware update
>             mechanisms as open source.
> 
> _______________________________________________
> Fud mailing list
> Fud@ietf.org
> https://www.ietf.org/mailman/listinfo/fud
>