Subject: Re: [Suit] Introducing draft-moran-suit-behavioural-manifests-00

From: Brendan Moran <[email-masked]>
Date: Fri, 14 Jun 2019 13:45:15 +0000

Hi Michael,

Thanks for brining up these concerns. I’ve done my best to address them. To summarise, the point of this draft is NOT flexibility. The point is: a single encoding with few optional fields for many use cases that’s easy to parse and where it’s plausible that a small number of tools will be adequate.

See below for additional details.

Best Regards,
Brendan

> On 20 Apr 2019, at 20:37, Michael Richardson <[email-masked]> wrote:
>
>
> I've been through the document and I've read the thread, and I watched the
> IETF104 video (I had a conflict).   I have a number of concerns.
>
> I find some of the conversation about the details of the operations
> indicative that coming to agreement for an proceedural mechanism may be
> rather difficult to get consensus on; but I could be wrong here.

Could you point out which operations you see as concerning?

> I feel that this proposal brings us away from a declarative manifest that can
> be reasoned about without regard to time.  I'm not exactly sure I understand
> the rational for the flexibility that is presented.
> It could be that I just don't understand this well enough; I tend to
> understand things by writing code, and I haven't written any code around
> this.

This absolutely does, deliberately, move us away from a declarative document. The rationale is NOT one of flexibility; that’s just a happy side-effect.

We have many use cases. This creates a lot of complex information that needs to be transferred to a recipient. There are three obvious ways that we can deal with this:
1. We can eliminate use cases to make the format simpler
2. We can use a per-use-case encoding
3. We can use a hierarchical encoding that wraps the required information for each use case.

Each of these has a problem. 1 limits the applicability of this standard, leading to potentially many overlapping standards. 2 causes problems for the user experience of device management: when each type of device uses a different encoding, it can be easy to make mistakes and this is multiplied when different vendors use different tools. 3 causes a high degree of complexity in the tooling. It also makes it hard for users to select the correct use case among many similar use cases. If some, but not all tools implement a particular use case, a user may end up needing to choose among many similar tools in an effort to find the one that implements the encoding for a particular use case. Hierarchical formats also naturally introduce more complexity in the parser: a separate tree description/parser stub/validator needs to be constructed for each use-case container.

All of these approaches also suffer from another problem: implied behaviour. When we imply behaviour in response to a declarative document, we leave room open for misinterpretation. What is the exact behaviour of a device for any given use case?

So, it appeared that another approach was needed. In attempting to construct a better hierarchical format, it became apparent quite quickly that virtually all firmware update and secure execution use cases were composed of the same operations with different endpoints, different algorithms, and different orders. What if, instead of telling a device what an update *is*, we were to tell the device what to *do*. This eliminates, at a stroke, any room for misinterpretation of intended behaviour. It also makes it simple for a tool to encompass many use cases without extensive special case behaviours. It also dramatically simplifies the device-side parser.

The simplicity of device-side parser is the real goal here. We want a simple device-side parser without constructing the UX confusion of devices that implement a narrow slice of a hierarchical format or require a specialised encoding, specific to their use-case.

> I feel that this proposal brings us away from a declarative manifest that can
> be reasoned about without regard to time

This is still a question. However, I think it’s reasonable to say that devices should not pay the penalty for intermediate systems reasoning about an update; we can fix the reasoning question with additional tooling. I have a few ideas about how to manage this that we can dig into later.

> Is there an example (maybe in the draft that I mis-understood) that would
> provide a pair of use cases where being able to do things in different
> orders, *at the control of the firmware update author* would make sense?
> If product A always needs to do action-1 before action-2, and product B
> always needs to do action-2 before action-1, I see no value in a behaviour
> manifest.
> It's when product A sometimes should do action-1 before action-2, and
> sometimes action-2 before action-1 that the behaviour makes sense.

Yes, if it were solely about the flexibility, then I would agree. However, there’s more to it than that.

>
> Again, maybe I just don't understand the proposal.
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
> _______________________________________________
> 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.