[Fud] My notes

[Hannes Tschofenig <[e-mail]>]

A small group attended the informal FUD meeting today and I started with
an explanation of what we had been doing with firmware updates at ARM by
going through the two documents I recently submitted. The manifest
format is inspired by RFC 4108, uses asymmetric crypto only, and an
ASN.1-based encoding. (Not in the scope of the standardization effort in
FUD is the actual delivery mechanism but we have been using LwM2M.)

We spoke about the difference between a software update mechanism and
firmware updates and Emmanuel (working on the RIOT OS) mentioned that
they have use cases where IoT devices run an embedded version of
JavaScript and need to also get code/scripts in addition to the firmware
and he wants to have that use case covered as well.

In this context the issue of the class of IoT devices we are targeting
and Emmanuel argued that we should aim for class #1 devices (based on
RFC 7228). This means ~ 10 KiB RAM and ~ 100 KiB flash. There have been
doubts whether this is possible.

Henk posted a link to the mailing list pointing to the firmware manifest
description based on RFC 4108. Here is the document:
https://tools.ietf.org/html/draft-ietf-sacm-coswid-02#appendix-B
So, we looked at the SACM COSWID work and were wondering about the need
to also support alternative encoding formats for the manifest (in
addition to an ASN.1 format), such as CBOR.

Erik Nordmark asked for a more detailed threat description and we talked
about the threat where an attacker blocks access to the update server.
This lead to a discussion about what we should cover in the architecture
document even if it is outside the scope of the standardization effort
of the manifest format itself.

Russ suggested to also take hash-based signatures into account (see
https://tools.ietf.org/html/draft-housley-cms-mts-hash-sig-07 and
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-07), as it was
already suggested at the IOTSU workshop. There was an agreement among
the participants that we should explore this option. Russ argued that
the performance is for verifier is good. The signature size is rather
large in comparison to an ECDSA signature but given that the firmware
image size it may not matter much.

Steve mentioned ongoing activities by NTIA about firmware/software
updates that are relevant to this effort, namely "Multistakeholder
Process; Internet of Things (IoT) Security Upgradability and Patching"
https://www.ntia.doc.gov/other-publication/2016/multistakeholder-process-iot-security

We talked a bit about the use case where a device consists of multiple
microcontrollers that all need to be updated and how the individual
components are identified and how this use case is captured within the
manifest. The 'dependencies' attribute was used in the
draft-moran-fud-manifest-00.

Finally, we spoke about the next steps, namely

(1) reaching out to various IoT OS developers and middleware providers.
We need more implementers of this technology in the group. Emanuel
promised to send a message to the folks from the Contiki OS and the
MCUBoot project (see https://github.com/runtimeco/mcuboot). I will reach
out to the guys from the IAB IOTSU workshop and to ARM partners.

(2) starting to draft a charter text with the focus of standarding a
manifest and to capture the overall architecture.

The plan is to charter a working group before the next IETF meeting.