Re: [Fud] Charter Text

Hannes Tschofenig <> Tue, 08 August 2017 10:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CA6F132191 for <>; Tue, 8 Aug 2017 03:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oCmIlDE3x5of for <>; Tue, 8 Aug 2017 03:29:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EA46131D28 for <>; Tue, 8 Aug 2017 03:29:55 -0700 (PDT)
Received: from [] ([]) by (mrgmx002 []) with ESMTPSA (Nemesis) id 0MBFgr-1dogwG00bl-00AIfY; Tue, 08 Aug 2017 12:29:53 +0200
To: Emmanuel Baccelli <>,
References: <> <>
From: Hannes Tschofenig <>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <>
Date: Tue, 8 Aug 2017 12:29:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:Td324ZIvJSkoBTwHv5gDAYbLNRvt3ObO03fxTUT6/e6E/kT6Gog UBfT9rf7r1o5nzbHPaDKtLzhSB0RJ9L3/DZo8/pmXP9GhXTVahIakOaH/Qx0DGNVHHsC0W1 Fe2F/fEVg93NlCnJ0NFdDQ4Qn3QqS6sgPRbBs+02qV/SlcIQUZmnJJQY56p2MzqU2Px2xS3 hgVNijghyClCzp0mAyLpA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:k1nhABc0MJI=:DEOCEOWjLYkjBYSDmnKOLw YrX1DlmRwH8hp4uCc4MMcvZiLarKNlVqQYRDAkuD3wF+zLd0SKDZGC7YDbRW3TKV99uE96Ylr 4TiF3IK6N2jkiN2fKcFf1aucnMfDFOGSSpnI6Jyd2ycBWSYNQFV1PpptZsRLNwAJNlwvQh117 rixIH/t75WrCQ5Mi4QnnNxDXiLe4D6gF7dlzcaiKCUIlfw97FQdNQ4I3960z0J85ptUU9c3Jg atHuKwlv1R2rcF8FbVEmVq+TTasGQXymlvdOCikAF0ERDdN67JV/atYecybpLK5d9kH2F7drt 8AHghJ10W9+Jvxx7Ld3xqFZNr9KR8CJCbtmc0MirunhFCYxrTlJFCEwo+QD5fGTwVtH37zVei j/jmxT6CZtzjKxscOonMF2Vcmc8ulMSpyq3vEpQ9GWGJtZNhnolymDk/2lkCP3+wjpJB61JDe sFLqtRlZfEl62QcigE13lNpmO9Z5EncZS9OFhFyOH3BiAWxyrx+EIab2Dkmvc3lFud4flCpnL lb6GowqDsVeTpubu9CqCp1xdpVWbtNygawpZFhYyxWJV7yPLJHgtJebNIYk0sig0NuarU6m6J hifMGbKm8oTdJyHlwwK8kwvgl/vcd42d8D/4in9+Mq+3hhA5tekdFjKbRBWM4VGxwuikY46hu VV7M6NMGUiC/gbPlqcyi1JQOk5N/nzjEqmDpW/7rnI+B8sF5F4kKxfkjQbjBFwf7zDNxfkSha UmpmySGiKiGYDdu3CN/aV7oMgen3A01OZ1mzTCbz1xR2XWob56VGzmEZh9kyrRlol9/rnpzMV uOdjK/u/UA3Pz0ACJZ+nd42NPeevtztRnjzkTagpBTCwnL4oaU=
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: Tue, 08 Aug 2017 10:29:59 -0000

Hi Emmanuel

sorry for the delay in responding to your review (due to vacation).

On 07/22/2017 09:57 AM, Emmanuel Baccelli wrote:
> 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?

There are several reasons why I wanted to focus on firmware updates:

(a) In ARM we have worked on firmware updates for M-class devices and
A-class devices. The constraints, developer experience, business models,
the involved parties, security concerns, etc. between these two classes
of devices are different. We don't see a lot of guys running special
versions of Java, JavaScript/JerryScript, etc. on M-class devices even
though we have been experimenting with these ideas as well (see My personal opinion is
that those are nice fun projects but not useful for anything serious.

(b) We wanted to have it focused in the hope that this work can be
finished in a somewhat timely manner.

(c) There are many software update mechanisms for regular OSs available
already. I am not sure there is need for more work.

(d) We have also proposed a software update mechanism for trusted
applications running on a TEEs with the work in TEEP. The requirements
are different there since we also need an attestation concept.
(There may, however, be some synergies between this work and TEEP.)

> - 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.

That's a good suggestion.

What about adding a paragraph that says something like:

This group focuses on defining a firmware update solution for Class 1
devices, as defined in RFC 7228, i.e., IoT devices with ~10 KiB RAM and
~100 KiB flash.

This is clearly quite ambitious since you will typically need a bit more
flash to store a second firmware image (to have a robust firmware update
solution). I would probably feel a bit more comfortable talking about
~20 KiB RAM and ~200 KiB flash if we are talking about a system that
uses public key cryptography.

I just want to avoid that we rule out public key crypto and also have
the freedom to explore ideas Russ suggested regarding hash-based
signatures. Just working on a system that only offers symmetric key
crypto is IMHO not enough.

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

Fine for me. I let the chairs decide about the best possible name for
the working group.

> (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 ;)

Thanks for summarizing your feedback made during the face-to-face meeting.


> Cheers,
> Emmanuel
> 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
> <>
>     <>