Subject: [Suit] Call for adoption on manifest draft

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 17 Jun 2019 14:53:43 +0000

At IETF 104, we had some good discussion on the manifest format and discussed moving it forward with a call for adoption after the meeting.

Based on the discussion so far, the chairs would like to start a call for adoption on draft-moran-suit-manifest.  Specifically, the chairs want to hear from the WG if this draft is a good starting point for a WG manifest format?

The latest version of draft-moran-suit-manifest can be found here: https://datatracker.ietf.org/doc/draft-moran-suit-manifest/

If you believe that this document is not an acceptable starting point, please state the rationale.

This call for adoption concludes on July 8, 2019 at 12:01am UTC.

Regards,
SUIT Chairs

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Jun 2019 12:47:26 -0400

Waltermire, David A. (Fed) <[email-masked]> wrote:
    > At IETF 104, we had some good discussion on the manifest format and
    > discussed moving it forward with a call for adoption after the meeting.

    > Based on the discussion so far, the chairs would like to start a call
    > for adoption on draft-moran-suit-manifest.  Specifically, the chairs
    > want to hear from the WG if this draft is a good starting point for a
    > WG manifest format?

    > The latest version of draft-moran-suit-manifest can be found here:
    > https://datatracker.ietf.org/doc/draft-moran-suit-manifest/

    > please state the rationale.

I am happy with this document.
The SUIT_Manifest is a map rather than an array, and that was my major beef
with previous versions.

(I had to go look at the document to be sure I knew which document was which,
as I feel very uncomfortable with the proceedural stuff in draft-moran-suit-behavioural-manifest.
But, that's not the document you are asking about)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brendan Moran <[email-masked]>
Date: Tue, 18 Jun 2019 08:05:41 +0000

Hi Michael,
I think it should be pointed out that draft-morean-suit-manifest-04 incorporates the concepts of draft-moran-suit-behavioural-manifest. Can you explain what it is that makes you uncomfortable about the procedural approach?

Thanks,
Brendan

> On 17 Jun 2019, at 17:47, Michael Richardson <[email-masked]> wrote:
>
>
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Jun 2019 16:46:25 -0400

Brendan Moran <[email-masked]> wrote:
    > Hi Michael, I think it should be pointed out that
    > draft-morean-suit-manifest-04 incorporates the concepts of
    > draft-moran-suit-behavioural-manifest. Can you explain what it is that
    > makes you uncomfortable about the procedural approach?

okay, so I wasn't really sure as I re-read things quickly.
In my quick re-reading, I though that the definition of the proceedures was
still to come.  I guess I read too quickly!!!

Bluntly, it's the stopping problem :-)

But, before we worry about programs that do not terminate due to loops,
(because that issue can be solved... I maintain libpcap afterall!), the
problem that I have is the inability to reason about what the manifest does
by just looking at it.  I'm coming back to this paragraph after the ones
below: I think you've invented a proceedural machine that is trying really
hard not to be proceedural, but as a result it is even less understandable!

Are the problems we are trying to solve so complex, varied and unknown that
we need this?   Assuming that the answer really is yes, then who/what is
going to write these proceedures that we need?  It seems like a highly
technical job, if it's really a proceedure.

Looking at SUIT_Condition, (8.12) again, let me say that maybe the
description of this as a proceedure is really incorrect.  It looks
totally declarative to me.

Where I think it gets less declarative, as I understand it that
SUIT_Directive_RUN_Sequence can take a list of SUIT_Condition, evaluate them,
and then do stuff?   Basically, this is how we do if/then, I think.
The Coerce condition explanation could be better.

SUIT_Directive_Process_Dependancy seems like a way to invoke matching methods
on dependant manifests.    SUIT_Directive_Run, could just be called, "and
now, download stuff, and magic happens".  Yes, okay, it's all signed and the
like, but it seems rather hard to reason about.

I kept reading in detail, to section 9, and I wonder if I understand option 2
correctly.  A device with multiple images to load (and that needs to do in a
specific order, and there might be multiple levels), might have a proceedure
that looks like:

programA:
   if component-one-version < 4
   then
      load manifest for component-one-version=4; process.
   else if component-two-version < 5
   ...

where "load manifest" could effectively overwrite "programA" with the "component-one-program".
After that, the firmware finds it needs to upgrade, and starts programA
again, but this time, component-one is okay, so it proceeds?

I think that section 11, pseudo-code has "SHA256 A", when it should say
"SHA256 B", btw.

I didn't understand if "condition-component-offset" was a test or a action.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Jun 2019 20:26:03 -0400

Michael Richardson <[email-masked]> wrote:
    > Are the problems we are trying to solve so complex, varied and unknown
    > that we need this?

The most complicated situation that I see is one where there are multiple
firmwares images and they need to be upgraded in a particular order, or
things stop working.  The Android case of KERNEL image vs RADIO/BASEBAND
image is perhaps the simplest example of this.  (On some phones, you'll
not just lose LTE if they are mis-matched, but maybe WIFI too, and often
you'll get a kernel panic.)

{At this point, I wandered through the document and then into the
architecture document looking for the terminology for where a firmware image
goes into.  The best I came up was that it was a component.  Above, in my
android case, there were RADIO and KERNEL as slots for firmware}

I can readily imagine Industrial applications where it could even take
multiple passes:
    1) upgrade component A to version 1.99 (which tolerates B being at 2.00)
    2) upgrade component B to version 2.00
    3) upgrade component A to version 2.00

It should, I think be possible to express this process in a single master
manifest (with dependancies, I think) rather than staging it somehow via an operator
action.  It might be that each step takes mulitple hours to days to transfer
the image, and the device needs to be operational the rest of the time
(double-buffering).

I think that the current document can accomplish the above rather simply, but
it seems to go a lot further.  (To infinity... and beyond!... so good work!)

I think that the directives tries to assume some kind of universal firmware
updating system that is identical everywhere, rather than assuming a
universal firmware package format, with firmware updaters in specific to each
device.  Perhaps this comes from being a SoC vendor that is trying to support
customers with a large variability in uses, but wanting to provide them all
with an identical baked-in-internal-flash firmware system.

I would be interested in David Brown's view on this.

ps: I think it's only the directives which are the problem. I think the
SUIT_Conditions are perfect, btw.

---

From: Brendan Moran <[email-masked]>
Date: Thu, 20 Jun 2019 13:53:29 +0000

Hi Michael,

Thank you for all your feedback. I agree that some of the wording could be much clearer. I think I also should lay out the motivations for this change from declarative to procedural much better.

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.

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.

This makes behavioural manifests interesting. Because they are naturally shallow, repetitive encodings, they are simple to parse. Because the information contained in the manifest is very closely related to the operation the device must perform, they are 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.

However, this simply makes behavioural manifests interesting, it doesn’t justify them for use in suit. For that, we need to look at the whole picture. A rough set of requirements for a manifest format in suit are:

1. Meets the information model requirements for usability and security
2. Simple to parse on a constrained node
3. Simple to process on a constrained node
4. Expressive enough to enable advanced use-cases on unconstrained(?) nodes, e.g. Linux.
5. Compact encoding
6. Extensible
7. Comprehensible by an intermediate system
8. Constructible by a moderately skilled user

I suspect that 1-6 are not up for debate and that 7, 8 are the contentious points. For 7, I think it’s important to look at the different systems we have in the constrained node use-case.

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

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.

To resolve 8, what we need is tooling that can construct a manifest to deliver one or more images, based on whatever capabilities are reported. We probably need to discuss what this looks like. A simple version would work by using templates for a set of standard use cases, but allow users to produce more advanced operations if needed.

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. This means that the specification must make explicit what each information element implies a device 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. 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 believe that the behavioural manifests are the best match for constrained nodes because they simplify the parser and the processor. They make the behaviour of the device explicit, rather than implicit. They are extensible without undue complexity on the 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.

Best Regards,
Brendan

> On 19 Jun 2019, at 01:26, Michael Richardson <[email-masked]> wrote:
>
>