Re: [Fud] FUD BarBOF Location

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 06 April 2017 15:47 UTC

Return-Path: <mcr@sandelman.ca>
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 3D6E2126BF7 for <fud@ietfa.amsl.com>; Thu, 6 Apr 2017 08:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 ksik5HBmE1NW for <fud@ietfa.amsl.com>; Thu, 6 Apr 2017 08:47:11 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE361129538 for <fud@ietf.org>; Thu, 6 Apr 2017 08:46:58 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id 45CDF1F8F5 for <fud@ietf.org>; Thu, 6 Apr 2017 15:46:57 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id CCF362918; Thu, 6 Apr 2017 10:46:54 -0500 (CDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: fud@ietf.org
In-reply-to: <85D18E4E-0859-4DB0-BAE2-8D258C219893@tzi.org>
References: <32221986-c3cd-60a5-0b72-5576303af3b3@gmx.net> <72189668-4154-c0f5-92a9-5fdf7c184939@gmx.net> <CANK0pbavhd6248bNzuDskwtV3Ewg6iAsj3k1-s0huUiWMNc_Bw@mail.gmail.com> <85D18E4E-0859-4DB0-BAE2-8D258C219893@tzi.org>
Comments: In-reply-to Carsten Bormann <cabo@tzi.org> message dated "Wed, 05 Apr 2017 15:31:27 +0200."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 06 Apr 2017 11:46:54 -0400
Message-ID: <23163.1491493614@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/x4IvEWOzhQCHKAfsVPv1xTlWz9I>
Subject: Re: [Fud] FUD BarBOF Location
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, 06 Apr 2017 15:47:13 -0000

Carsten Bormann <cabo@tzi.org> wrote:
    > — firmware updates for general purpose class computers (Linux etc.,
    > “A-class”, OpenWRT routers, ...) are rather different from those for
    > microcontrollers (“M-class”)

well, Hannes kept saying that, and a number of us kept saying that in fact
it wasn't true.   Writing a 1GB image onto a 1.1GB NAND boot partition
could be as difficult to get right as writing a 31K image into a 32K NAND
partition.  The only difference being what you can fit in the "extra" space.
(100M of bootloader space vs 1K of bootloader space...)

OpenWRT routers and Smartphone updates are very much closer to M-class than
they are to "Linux" desktops. It's a signed blob, and often there isn't space
to double buffer it at all.

If it is useful for me to write up my minimal (D)TLS receiver concept for
firmware updates, I will do that.

    > — we should probably look specifically at the latter

Agreed.

    > — initial focus on complete firmware replacement (we did talk about
    > bootloaders vs. primary/recovery loaders etc.)

    > — the next step could be defining what set of metadata should be
    > provided for a such a firmware image
    > — RFC 4108 is out there but may not exactly be what is needed for M-class today
    > — coswid (no, not the Trojan horse) might be one format to look at

I think that we should consider updates to 4108.
If we don't like 4108, then we should consider a non-ASN1, non-PKIX format
format (JOSE for instance).


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-