Subject: Re: [Suit] Some proposals for updates to the SUIT manifest specification

From: Koen Zandberg <[email-masked]>
Date: Wed, 8 Jul 2020 15:32:58 +0200

Hi,

Here are some of the promised numbers.

The numbers here are the flash space occupied in the binary for a SAM
R21 Xplained Pro (Cortex-M0+) with -Os,  assertions and logging disabled
and without link-time optimization. The application is the suit update
example[1] provided by RIOT and updated to draft-ietf-suit-manifest-07

Version,           CBOR,   COSE,  SUIT,   Total image
suit-manifest-07,  1100 B, 900 B, 1933 B, 73915 B
suit-manifest-03,  1100 B, 900 B, 2068 B, 74083 B

Note that the total image is the full image size and includes more than
the sum of the mentioned sub components and is provided here to put the
numbers in perspective. The takeaway message here is that the numbers
didn't change much the last few iterations which I consider a good thing.

I've also took a closer look at the bstr wrapping and where they improve
the manifest parsing, see inline below. In most cases it boils down to
whether the object might potentially

>>>> My opinion on each of the bstrs is:
>>>>
>>>> 1) We must keep the bstr wrappers around all envelope elements.
>> Yes please, this is one of the few places where they really help.

After another look I believe it is okay to remove the bstr wrapping
around the SUIT_Authentication_Wrapper. Parsing or skipping is easy
enough as long as the individual SUIT_Authentication_Block's are bstr
wrapped.

>>>> 3) I’m not entirely sure we should keep the bstr wrapper around the
>>>> common block, but I think it’s useful. It always lives within the
>>>> extent of the current manifest, so overruns will be detected on the
>>>> first pass by the parser, and the extent of the common block can be
>>>> recorded prior to the execution of any command sequences.

I can live without this being wrapped I think. In my case the full
common block is always parsed and there is no situation where it should
be skipped for later parsing.

>>>> 4) I would not argue against removing the bstr wrappers around
>>>> command sequences, provided that we register a tag for either the
>>>> command sequence or the SUIT Digest.
>
> I think the other option is that we could use separate keys for digest
> and for command sequence. What I don’t like about that option is that
> it’s not clear what a device should do if both are present and one of
> the goals of this specification is to eliminate that kind of
> uncertainty. That being the case, I think I would want a SUIT_Digest
> tag or a SUIT_Command_Sequence tag. Probably a Command Sequence tag,
> since that would make the manifest smaller when including digests.
I don't really see the point in swapping a bstr wrapper for a tag,
depending on the tag value and the bstr length, this might save a byte.
Anything I'm missing here that would make this beneficial?

>>>> 5) I think we could safely remove the bstr wrappers around the
>>>> elements inside of the common block, including the command
>>>> sequence. This incurs a negligible execution time overhead when
>>>> accessing some common elements, but produces manifests that are a
>>>> few bytes smaller.

I strongly prefer to keep the bstr wrappers around the
SUIT_Command_Sequence when used as argument for the
suit-directive-run-sequence and the suit-directive-try-each. Especially
in the case of the suit-directive-try-each, the full
SUIT_Command_Sequence must be skipped if a condition inside the sequence
fails. This is significantly easier on the parser if it is bstr wrapped.

Cheers,
Koen

[1]:
https://github.com/bergzand/RIOT/tree/pr/suit/ietf_v7/examples/suit_update