[Fud] initial comments on draft-moran-fud-manifest-00

Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Wed, 19 July 2017 18:37 UTC

Return-Path: <emmanuel.baccelli@gmail.com>
X-Original-To: fud@ietfa.amsl.com
Delivered-To: fud@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 18C9812EAB0 for <fud@ietfa.amsl.com>; Wed, 19 Jul 2017 11:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Status: No, score=-1.698 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, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id K3fQ2Vbsejeg for <fud@ietfa.amsl.com>; Wed, 19 Jul 2017 11:37:13 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 40F7412711E for <fud@ietf.org>; Wed, 19 Jul 2017 11:37:13 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id f9so6190874uaf.4 for <fud@ietf.org>; Wed, 19 Jul 2017 11:37:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=cF7qi5TggVqLn6KlJiscloE7Y+4qtihcmiQ4ReEgU5A=; b=Vw9y9qx8vYMXKySp5YUKgJRsqH1UN8gGmI+q1tQVfaQHqOcJRYUbS5GFq8Z8RVgs8v /pqoi0rORcH5MMOioBK5nSm9TcHNIySWVCo8vLQ5zPO2uM+tGug9/1fL0m3LQw5UvHuH K/MaCwnH6RCy3K5lZv0mBZYfGqJtPbo4hraU7XrZcSUxJM/IUDYYeSLSrqNJa1GnBCTq NZVianMeeWwFJRM963eOGfSOYnZuqyT2WIWRSyAeYQhleVyMXCR6Mzv8fAm3SbkdUm1G SNXWjeY0RrSUf2wLpdUZprITiGd3Bl01TCZNOsPbzHzsn5NrxI4Qhp//xeUqUjZUL7By 3sQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=cF7qi5TggVqLn6KlJiscloE7Y+4qtihcmiQ4ReEgU5A=; b=IOnw/ha0Q/2F2ipw/BDOxybRU5awsvmGIhZuPotOuoVVkSXn4OF7SU7A2uDCQgXXRB Jzx5kfRjtjCA3goAhYNA13mWPl2fAM7FoSJFcPvac9KoDX5Y+aiL5MwuVDJyqWsno993 zLj0s18sT5WfN7SfbfKCslxlsWJOuTLr4QgmcnVk8aM9pt67ce6GPzFnDnkBpdHsDgf4 FS5R/1ORipNinsJblQVQMYclDFkeLMK/OSPCSEAUAgOKiehUGCwSkpfnsHXByjqzxM8T wxslDyLI0R7S6mWh73QTj6cvYesQVbMQqBfcsem5WrNF+HKA74bwSb7c7CYVlcCrGW1J XRXQ==
X-Gm-Message-State: AIVw112DlTTCYCjGtTRtQR+gfpAOyjMXCdRFGXIUS8dLC49QlcOeu70Q nxTaJjmTQ8AQ6CP6Kr3rXRqmBDcaAyjL
X-Received: by with SMTP id y3mr539633uag.21.1500489432120; Wed, 19 Jul 2017 11:37:12 -0700 (PDT)
MIME-Version: 1.0
Sender: emmanuel.baccelli@gmail.com
Received: by with HTTP; Wed, 19 Jul 2017 11:36:51 -0700 (PDT)
From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Date: Wed, 19 Jul 2017 20:36:51 +0200
X-Google-Sender-Auth: hLnnaRACmQ2GtJeRw1lp9T8zZu0
Message-ID: <CANK0pbYZnHyrDp_KoWp3xhtXmMGpUwHrWhmatgnsVRhdqpY8qw@mail.gmail.com>
To: fud@ietf.org
Content-Type: multipart/alternative; boundary="f403043c51c097438c0554afeb25"
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/MMNkNWGGpF30BLqGxKDnTbtYzBU>
Subject: [Fud] initial comments on draft-moran-fud-manifest-00
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: Wed, 19 Jul 2017 18:37:15 -0000

Hi again,

another quick review heading towards tomorrow.

Do you have an open source implementation of this somewhere,
running on IoT devices?
If so, could you point us to this code, and tell us which devices you
tested this on?

See below some comments, questions and suggestions.

General comments:

Let's make sure that a minimalistic version of the manifest format is
easily to low-end IoT devices:
 - class 1 devices (RFC7228) with a single MCU,
 - very low bandwidth network connection,
 - may not have an "interoperable" notion of absolute time,
 - ...

As additional reference points, let's also look out the (work-in-progress)
metadata format
of RIOT images [1], and of MCUBoot images [2] which
In particular, the whole metadata of a RIOT image fits in less than 200
A nice goal could thus be that we aim to fit a minimal (but compliant)
of the manifest within 256bytes.

[1] RIOT Image Metadata (work in progress)
[2] MCUBoot Image Metadata (work in progress)

Some more detailed comments:

# In section 3.1

If we want to cover the cases when the device has no notion of "now",
(i.e. is not time-synchronized with the author/server/storage)
the device will only be able to interpret this field as some kind of
sequence number. This does not bringing much more information compared to
the version number field.
In particular, I'm wondering why the timestamp actually protects from
downgrade attacks:
I suppose we trust that newer software will have newer version numbers.
Is it to cover the case when the version number "wraps around"?

# In section 3.2

I would suggest we add the format type "script".
We have use cases where modules might be scripts.

I'm not sure the case of "producing manifests too quickly" with the same
is realistic.
Even if it was, since a nonce is random, the nonce would not help to decide
firmware is newer.
However, we could assume that the version number would be lexicographically
in the newest firmware.
Hence, I am unsure what is the function of the nonce.

as per my comments to the architecture draft, I suggest we focus first on
the case
where there is only one MCU.
Should this field be optional?

# In section 3.3

"Apply an update only to devices that match the vendorId, classId, deviceId
is this condition not necessary in all cases?

Conditions on absolute time:
see my above comments on absolute time, and time synchronization
requirements that might
not be met in low-end IoT devices.

# In section 3.4

Here again I propose to focus on single MCU cases first.

# In section 3.5.2

make it optional?

# In section 4.

Do you have an estimate as how many bytes this is over the air for the