Re: [Suit] Call for adoption on manifest draft

[Michael Richardson <[e-mail]>]

1) I think we should adopt.

Brendan Moran <[e-mail]> wrote:
    > I believe that the behavioural (or procedural) approach has many
    > benefits, but I want to stress that this is not about solving some
    > arbitrarily complex problem; it’s about compact encoding, meeting the
    > requirements we have, and enabling precisely defined device behaviour.

I wonder if we could uplevel the "commands" a bit?

    > First, I have three observations about firmware update:

    > 1. To eliminate a source of user error, simplify management, etc., we
    > can’t have many similar formats, there needs to be just one.  2. Making
    > a parser small and easy to validate requires a simple format, with few
    > unique structures and low nesting depth.  3. Almost all user stories
    > and security requirements are implemented with a small number of
    > fundamental operations.

I agree with these goals.

I think that you have done a good job of eliminating nesting (stack depth) by
allowing the manifest to be processed multiple times, with antecendent
conditions causing already executed steps to be skipped/elided.

    > simple to process. This should mean that we are able to achieve parser
    > simplicity goals for a constrained device without sacrificing
    > capabilities needed only on larger devices.

I'm having difficulties understanding how the less complex devices would have
less complex parsers.  What I see is that simpler devices will have shorter
SUIT_Directive.

    > 6. Extensible

I'd like to suggest that we consider an way for a boot firmware manufacturer
(1) to indicate what things are supported on a particular device, such that a
device manufacturer (2-Author) would know which directives are valid, and so that
a network operator (3) can know what's possible.

Just to fill in numbered blanks above, I think we are missing some
terminology:
(1) - would be the entity that built the Manifest parser, etc.  I perceive
    that in your ecosystem, this is you (ARM).  I don't know what to call
    this role.

(2) - this is the Author as per suit-architecture.

(3) - the network operator does not seem to be in the suit-architecture as a
    term.

    > 7. Comprehensible by an intermediate system

In particular, I am concerned about an audit function that (3) might wish to
perform.  Being able to support such an activity is one of the reasons we
want a standard format.  And it is here that Extensible and proceedural
causes a problem.

    > There are two classes of metadata used in firmware update, with two
    > very different sets of constraints.  A. The metadata consumed by a
    > constrained node in order to consume the firmware update.  B. The
    > metadata used by an intermediate system to make decisions about the
    > update

    > A) has to be small and easy to parse and process and B) has to be easy
    > to reason about. In previous drafts, these have been the same. I now
    > think this is detrimental to the constrained node.

I take your point.

    > However, there are
    > challenges posed by dividing metadata into consumer and intermediate
    > metadata. I think we can resolve these issues in one of two ways:
    > either by using tooling to extract relevant data from the “byte code”
    > of the behavioural manifest, or by encoding two sets of metadata using
    > severable sections, as previously discussed—this will be the default
    > with encrypted or partially encrypted manifests anyway.

Fair enough. "Encryption" by encoding as byte-code/VLIW is as opaque to humans as
encryption by AES128 :-)

    > If the suit-wg chooses to pursue the behavioural manifest approach, I
    > think we should focus on tooling to extract information. I don’t
    > believe it’s complex to implement, and I’ll endeavour to prove
    > that. However, there is certainly some value in being able to encode
    > data for an intermediate system in a severable section. Since this has
    > costs in manifest size, I think the best way to do this is to add a
    > JSON blob as one possible element in the already severable text
    > section.

My concern is that the extraction is not the truth, but rather a (falliable,
spoofable) interpretation of what is there.  That the potential is there to
slip something past the audit stage.  That the encodings are now complex
enough that we wind up writing an assembly language for it.

    > However, I think there is one more consideration: implied
    > behaviour. When a manifest is sent to a device, it is an instruction to
    > do something. I think this makes procedural information a much better
    > match. If the content of that manifest is purely declarative, then the
    > behaviour of the device is implied.

Fair enough.  You are saying that there will always be proceedural code.
It's between the the implied (and secret) proceedural code in the
SUIT-interpreter, vs the explicit (and auditable) proceedural code in the
manifest.  I take this point strongly!

    > should do. As long as each information element is isolated, this is
    > achievable, but if information elements interact, this quickly leads to
    > a combinatorial explosion in the specification.

I think that this is the part that you are concerned mostly about.
I'm not convinced that many (or all) combinations really will make sense.
I'd like to have a system (via i.e. "IANA Considerations") that lets new
combinations come into play.

I think, lacking the experiences you have, that a device from a particular
*Author* will generally do upgrades in two or three ways at most.  Even a
device with N images that needed loaded probably doesn't have N!
combinations.

This is not the same view from a SoC vendor, where you have to support a much
larger number of Authors.

    > If the behaviour of the
    > device for any arbitrary combination of information elements is not
    > explicit in the specification, then the specification will be open to
    > interpretation, which will inevitably yield surprising results. For a
    > security-critical system, like firmware update, the last thing we want
    > is surprising results.

I agree that surprising results are a bad thing.
But, can you give me an example of a device with an arbitrary combination of
information elements?   The only way to I can get there is to assume
something like an Android device where the APKs (Apps) are in scope, and I
was pretty sure we already said that was out-of-scope.

    > target. They do present two challenges: interpretation on intermediate
    > systems and construction by an unskilled (in behavioural manifests)
    > user. I think that we can solve these challenges and I think that the
    > interpretation challenge, at least, is less complex than it
    > appears.

    > I’m willing to trade complexity on intermediate/authoring
    > systems for simplicity on a constrained node. What remains to be seen
    > is whether the suit-wg agrees with my approach or not.

To be clear, this is not blocking issue for me.

I think that we can improve the descriptions of the directives better.
We will need some examples.
Are you open to the idea that some of the constructions (sequences of
directives) that we might make for the examples might be better as primitives?

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-