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

[Emmanuel Baccelli <[e-mail]>]

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
applicable
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
bytes.
A nice goal could thus be that we aim to fit a minimal (but compliant)
format
of the manifest within 256bytes.


[1] RIOT Image Metadata (work in progress)
https://github.com/RIOT-OS/RIOT/wiki/%5BWIP%5D-Draft-RIOT-Image-Metadata
[2] MCUBoot Image Metadata (work in progress)
https://github.com/runtimeco/mcuboot/blob/master/doc/design.txt

=====
Some more detailed comments:
=====

# In section 3.1

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

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

storageIdentifier:
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
attributes"
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
manifest?