[Fud] My notes

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 20 July 2017 15:11 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 59716131CFC for <fud@ietfa.amsl.com>; Thu, 20 Jul 2017 08:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 PX0GgtbVHlhB for <fud@ietfa.amsl.com>; Thu, 20 Jul 2017 08:11:22 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C84131CD1 for <fud@ietf.org>; Thu, 20 Jul 2017 08:11:21 -0700 (PDT)
Received: from [192.168.91.200] ([31.133.137.21]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LeNGL-1dxhAL07ht-00qBb8 for <fud@ietf.org>; Thu, 20 Jul 2017 17:11:20 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
To: fud@ietf.org
Message-ID: <ad75252e-1e87-6efa-6a46-b3994a1c7535@gmx.net>
Date: Thu, 20 Jul 2017 17:11:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:BPsH4+pLGoDv1rvk/SUYfU6HPG7Oy4fJB/ZZlo1PMI26eVuYrUz 1SyeRhe1vYSvMTl8NPoAU0yi9aB98GsGb0g0CgsCtE728vOcVFL0/giHDhmfM1ABv62XCCO N3l/KtgAweRYUJEBUUU3rGYkyKPuVzx7fLo0Ql02DMQaUeaVrDKOUPrxW6WzIrFnYh93YNS zaD5Kw17Ltd8+DiGk5EbQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:CJeoRPNN1hw=:6evbJpVM3ZoumI2mON7JzI 3qM8Unn06TYOgvocDRbdhZCwFRbaXbLj0BOXvZkMWDVPzKRvnd4g+mfVcKLQyNVaFtoMxaa7R 762oA0DfP6WFl+PbqvNooReXpiJh6XfgpcfBzvlWsYbC4bQZVO3ohDTHm2yMnoge5zbGBPQaA Rdc4EKJuVWSxbhPE6SJaK2HBUMyiM6VXJA3ftKJhXPnGwkOtzFh6WJEeTVzGaEuc6UEpb+Uoc 3fmSSAHcokKXzkyBLemRoQkA4lbeH75IE3JStzvoJrNaUieOILhzj/rptCjKzh9ipN7FTVrcU Emzd5SVMKjUIcRtJKS3lN3wA0DqqRC1awe3sDpznAXluSuvCCOQiP55ycCDowpLVaTNmJvADB SqG9gi1nX+XvLScl1h1u8jcUpUZQCjY8lClVQJ50Ej0O5xljQDc6HkzNTc6aa3nE+hiwCzP41 i7lkYT00cPQh3Ejs3BhPn+6mygPx9RRqqB2yK9pH0CXFjqtKS9tOclO11eeMy8H9ujj547pQ5 lueHq2yE0aEqdkRq0EMhE1+0LdJsGQVeR0wcOsbOnpnaT24GA4MqWMu7XqvfhMzo1chMixatu X/EogwLQ0DC3ErYXxyu57UxgB5hdu0gX5bADVSQ/ttOkRmrd1pS6uLQ0ZI74lIoXC4Yjd4X0G rgwb6aplCj/lPKX9N4J2uZ8MUiYO8VBjqQ7azZLh8i+Xt6YFYqVEPQ4R8VRQHOJmrSvgSqFTj N/jIRWVYp3aFLmkYdiA4NwyyltXMBQbooA97T7tiaNWn1rNQGe5wATqwDpvFr7hGQ847t1FoP +IQm5I8jc300B5cHID4aNKt1YAmvwd16avBu4JDqQluYkNhXw8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/mj8d4t-mUD6QJJ8Fekfq8aLYRIU>
Subject: [Fud] My notes
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: Thu, 20 Jul 2017 15:11:24 -0000

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.