Re: [Fud] Charter Text

Emmanuel Baccelli <> Sat, 22 July 2017 07:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A310F131C4F for <>; Sat, 22 Jul 2017 00:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oDSfessxDyGh for <>; Sat, 22 Jul 2017 00:57:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC89912714F for <>; Sat, 22 Jul 2017 00:57:54 -0700 (PDT)
Received: by with SMTP id 80so56737253uas.0 for <>; Sat, 22 Jul 2017 00:57:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=a1wskhaSIbRjMbLMrqMnoiQ41lpHQ0ItRueyXDewPFY=; b=HKsp3rhgoCGY9LwsupGAGCko5OBsbZCq+pXy2WsUxAAG5M60DEX+uimga4JFx9bcrk gxwHQ7PIa/lMs7bv1/U6RBllobL1X6MOXCHAdGqaOgDIGjoysbb34iHK2oL1Orm1i+An 6Ks1f1z4aHzKJPMp+x41W26p+wpL3k7lzlfO7VDgV5Lq0a71GZtesF6fks9hej/0uNt6 ecgTTTIqyD8LfW/W3yN5rqgW1r9FLQWszkfQVjXoLB31EqhxVnLpp4VtL1+MEXNbJuHu idjDYWxHDnQYpkhsqkjkfGclh+jwoFqfIOlyfeeabVMXmVYbzBJgsZMsFAHkBSCfsn3H +33A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=a1wskhaSIbRjMbLMrqMnoiQ41lpHQ0ItRueyXDewPFY=; b=MqbTD6E0IDiRCehCo9zUZx6DS5V7yg8XtS2cvvH8F56luDFxkCSD8/UvVE2DABLf40 XM/lOxfbYbi89GHNaWxMDLUQmi+ha1YIXuzvsVKLr+aQEhns6YFhmmcCfOsHAihE7ROg uHgAlsY/VbJvfykFQESeYnDMxSJRpVym3cLaDyn9mp6ZBf9Fd0rNQtAhoF2YuU9/96Qj Z6RcUXdnyzKHs1EB5pz2gD6MrZqsREab1qya8DAf/cxNDfUVvzdcyAzabAvbws7CADuu RYkar2zRUGw89hhyu9hbpmTbX8vnR1hzInwcLck0cmxIdDiVxjmrNmLGRgAowNZNPh2g I1hA==
X-Gm-Message-State: AIVw110NIhmik+1hO8J/l+B1lFArGgFushCIrfaNf8KNIbSTRNe3AsXw Z/4z9MFMdVydfu91XFWVvkhy2BRk/w==
X-Received: by with SMTP id 34mr2811637uaz.5.1500710273848; Sat, 22 Jul 2017 00:57:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 22 Jul 2017 00:57:33 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Emmanuel Baccelli <>
Date: Sat, 22 Jul 2017 09:57:33 +0200
X-Google-Sender-Auth: h07wLfHuEsF-T70ggvehBz25Bhs
Message-ID: <>
Cc: Hannes Tschofenig <>
Content-Type: multipart/alternative; boundary="94eb2c122e54c899ef0554e3564f"
Archived-At: <>
Subject: Re: [Fud] Charter Text
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 22 Jul 2017 07:57:56 -0000

Hi Hannes,

thanks a lot for the strawman! Reads well in my opinion.

At high level, I have the following comments & suggestions:

- we have the case of software updates, not only firmware updates, so I'd
rather we talk about the more general case of software updates. Is there a
strong reason against this?

- many people think IoT= RaspberryPi, so I think we should be very very
clear that we are also targeting constrained devices as defined in RFC7228.
In particular, I'm convinced we can (and should) explicitly include Class 1
devices as also being a target for such software updates.

- FUD is quite an unfortunate acronym. Here's an alternative name proposal
for the working group: how about SUIT (Software Updates for Internet of

(there is a heavy similarity between the above comments and the ones I put
forward during the f2f meeting in Prague, as well as with the comments I
posted on the manifest+arch drafts you submitted this week ;)



On Fri, Jul 21, 2017 at 11:52 PM, Hannes Tschofenig <> wrote:

> Here is a strawman proposal for a charter text. Suggestions welcome!
> ----
> Firmware Updating Description (FUD)
> Vulnerabilities with 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 are equipped with such a mechanism. While
> there are many proprietary firmware update mechanisms in use today there
> is a lack of an modern interoperable approach of securely updating IoT
> devices.
> A firmware update solution consists of several components, including a
> mechanism to transport firmware images to IoT devices and a manifest
> that provides meta-data about the firmware image as well as
> cryptographic information for protecting the firmware image in an
> end-to-end fashion. With RFC 4018 the IETF standardized a manifest
> format that uses the Cryptographic Message Syntax (CMS) to protect
> firmware packages.
> Since the publication of RFC 4108 more than 10 years have passed and
> more experience with IoT deployments have lead to additional
> functionality requiring the work done with RFC 4108 to be revisited. The
> purpose of this group is to standardize a version 2 of RFC 4108 that
> reflects best current practices. This group will not define any
> transport mechanism.
> In 2016 the Internet Architecture Board organized a workshop on
> 'Internet of Things (IoT) Software Update (IOTSU)', which took place at
> Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. 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 are challenges
> with lack of regulatory requirements, and misaligned incentives. It is
> nevertheless seen as important to standardize the building blocks that
> help interested parties to implement and deploy a solid firmware update
> mechanism.
> In particular this group aims to publish two documents, namely
>  * an IoT firmware update architecture that includes a description of
> the involved entities, security threats and assumptions, and
>  * the manifest format itself.
> This group does not aim to standardize a generic software update
> mechanism used by rich operating systems, like Linux, but instead
> focuses on software development practices in the embedded industry.
> This group will aim to develop a close relationship with silicon vendors
> and OEMs that develop IoT operating systems.
> Milestones
> 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 "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 tool suite as open
> source.
> Jun 2018     Release first IoT OS implementation of firmware update
> mechanisms as open source.
> _______________________________________________
> Fud mailing list