Subject: [Suit] Review comments on draft-pagel-suit-manifest-00

From: Amyas Phillips <[email-masked]>
Date: Tue, 6 Nov 2018 13:32:29 +0000

I see this is on the agenda for Thursday so I have reviewed the document.
I'm an IETF newbie so apologies if sending review comments to the list is
not the done thing, please someone tell me if so.

1. The goal of eliminating the need for a parser is clear.  This certainly
has advantages.  It may have disadvantages.  A fixed manifest structure is
needed and would probably need to be customised to each device class (as
defined in draft-ietf-suit-information-model-01).  To create or read such a
manifest for a device, one would need to know what manifest structure it
expects.  To the extent that the firmware distribution system needs to
route the manifest and identify and validate the associated firmware, it
also needs to know the manifest structure for each device.  Whether this is
good or bad depends, I guess, on what the WG means by "interoperable" in
its charter.

2. It is stated that choice of compression and cryptographic algorithms can
be implicit.  The firmware maintainer needs to know what the target device
supports anyway, so this is maybe something to adopt whether this proposal
proceeds further or not.

3. I would appreciate a definition of "device platform".

4. The concept of software layers is introduced to motivate the idea of a
manifest set, each manifest within it specifying component payloads.  I
understand this as a fixed-format way of delivering interdependent payloads
to device components that may have different maintainers.  In
draft-ietf-suit-architecture-01 manifest dependencies are used for this
purpose.

5.  Page 3: ".. signed by the Network Operator".  The network operator is
the entity that has manifest set signing authority.  Is it necessarily a
network operator?

6.  The Type and Flags parameters are introduced to cue a handler with
arguments for each payload.  I find this approach clearer than the
componentID - storageID hierarchy in draft-ietf-suit-information-model-01.

7. p4 paragraph 2:  The idea that device platforms are subdivided into
models is introduces, and it is suggested to use the first and last ClassID
in a manifest set to identify them.  This seems unduly obscure. If device
platform and model are needed in addition to classID, componentID,
storageID and Type I guess they can be added
to draft-ietf-suit-information-model-01.

8. Transport layer encryption is recommended for confidentiality.  I read
this to mean payload encryption is not considered.  My view is that channel
encryption is often sufficient but not always, in particular when non-IP
links and/or multi-stage distribution are involved, so payload encryption
should be considered.

9.  Component ABIs are explicitly versioned and specified in component
dependencies.  Perhaps this can generalise to APIs generally.  Specifying
dependencies by API is generally preferable to specifying them by
componentID, but it is another layer of abstraction.  I would probably
incline against it, but maybe the group attending IETF-103 can discuss.

10. Shouldn't the ManifestSetHeader contain some kind of identifier of the
target device platform?  If the assumption is that the update service knows
by other means what devices to target, then I guess not.

11.  Instead of any old URIs in the manifest, specifically UUID-based image
descriptors called ImageUID are specified, with the advantages of being
smaller than URLs and (I guess) fixed size.  It is expected that devices
may request a URL for the payload with given UUID from an update server.  I
only mention this because it clarified for me that payloads are specified
as URIs not URLs, which I mistakenly had believed was the idea in
draft-ietf-suit-information-model-0 before I studied this.  Maybe it'll
clear that up for someone else too.

Overall I think the key question I think this submission raises for the WG
is what the charter means by "interoperability".  This proposal seems
capable of delivering a lighter-weight implementation on devices at the
cost, maybe, of being able to use off-the-shelf distribution services,
preparation tools and device-side libraries.

Thanks

Amyas Phillips

---

From: Martin Pagel <[email-masked]>
Date: Wed, 7 Nov 2018 05:23:53 +0000

Thanks, Amayas,
for the detailed review of the draft. I added some comments inline…
Martin

From: Suit <[email-masked]> On Behalf Of Amyas Phillips

1. The goal of eliminating the need for a parser is clear.  This certainly has advantages.  It may have disadvantages.  A fixed manifest structure is needed and would probably need to be customised to each device class (as defined in draft-ietf-suit-information-model-01).  To create or read such a manifest for a device, one would need to know what manifest structure it expects.  To the extent that the firmware distribution system needs to route the manifest and identify and validate the associated firmware, it also needs to know the manifest structure for each device.  Whether this is good or bad depends, I guess, on what the WG means by "interoperable" in its charter.
* This manifest format contains the generic manifest structure, but some details are left up as options for the platform to decide. Yes, that way the Update Server may have more variations to deal with, but hopefully it gets easier for the device to interpret the manifest.

2. It is stated that choice of compression and cryptographic algorithms can be implicit.  The firmware maintainer needs to know what the target device supports anyway, so this is maybe something to adopt whether this proposal proceeds further or not.
* yes, most simple devices only support a single crypto algorithm, therefore the Server needs to know which one to support anyways.

3. I would appreciate a definition of "device platform".
* I will make a note for the next revision. My understanding would be a specific MCU with its associated eco system.

4. The concept of software layers is introduced to motivate the idea of a manifest set, each manifest within it specifying component payloads.  I understand this as a fixed-format way of delivering interdependent payloads to device components that may have different maintainers.  In draft-ietf-suit-architecture-01 manifest dependencies are used for this purpose.
* yes, that’s correct.

5.  Page 3: ".. signed by the Network Operator".  The network operator is the entity that has manifest set signing authority.  Is it necessarily a network operator?
* good question… more generically it might be better to define it as the operator of the Update Server.

6.  The Type and Flags parameters are introduced to cue a handler with arguments for each payload.  I find this approach clearer than the componentID - storageID hierarchy in draft-ietf-suit-information-model-01.

7. p4 paragraph 2:  The idea that device platforms are subdivided into models is introduces, and it is suggested to use the first and last ClassID in a manifest set to identify them.  This seems unduly obscure. If device platform and model are needed in addition to classID, componentID, storageID and Type I guess they can be added to draft-ietf-suit-information-model-01.
* Some example: A manufacturer of a Wifi subsystem may provide (and sign) its firmware but it gets added to an OS for an ARM based MCU. Then the wifi subsystem would include one ManifestSet signed by the wifi provider and another Set by the OS provider.

8. Transport layer encryption is recommended for confidentiality.  I read this to mean payload encryption is not considered.  My view is that channel encryption is often sufficient but not always, in particular when non-IP links and/or multi-stage distribution are involved, so payload encryption should be considered.
* yes, for example if you want to distribute the images via broadcast over public Internet, you might want to encrypt them for privacy. The draft does not preclude the use of image encryption if the platform supports it, but not all MCUs will have enough storage and compute power.

9.  Component ABIs are explicitly versioned and specified in component dependencies.  Perhaps this can generalise to APIs generally.  Specifying dependencies by API is generally preferable to specifying them by componentID, but it is another layer of abstraction.  I would probably incline against it, but maybe the group attending IETF-103 can discuss.
* API changes are usually only done when a major revision is implemented and then several APIs change. To reduce the data for each API, it seemed reasonable to group them by component.

10. Shouldn't the ManifestSetHeader contain some kind of identifier of the target device platform?  If the assumption is that the update service knows by other means what devices to target, then I guess not.
* Usually the device would request a manifest for its platform from the Update Server. In case of broadcast distribution, the device could check the ClassId.

11.  Instead of any old URIs in the manifest, specifically UUID-based image descriptors called ImageUID are specified, with the advantages of being smaller than URLs and (I guess) fixed size.  It is expected that devices may request a URL for the payload with given UUID from an update server.  I only mention this because it clarified for me that payloads are specified as URIs not URLs, which I mistakenly had believed was the idea in draft-ietf-suit-information-model-0 before I studied this.  Maybe it'll clear that up for someone else too.

Overall I think the key question I think this submission raises for the WG is what the charter means by "interoperability".  This proposal seems capable of delivering a lighter-weight implementation on devices at the cost, maybe, of being able to use off-the-shelf distribution services, preparation tools and device-side libraries.
* yes, the Update Server and tooling would need to be slightly more complicated, but less burden on the device which is a quite important for low end MCUs.

---

From: Brendan Moran <[email-masked]>
Date: Fri, 16 Nov 2018 17:01:14 +0000

I'll add my review on to the below.

1. I do not understand how images are authenticated. I see no reference to an image digest. Are images concatenated inline within the structure? I see no reference to concatenation within the format definition.

2. This is a format for low-end devices (Section 1, paragraph 1)

The meaning of "low-end devices" is not described and no reference to RFC 7228 is made. Without this information, it is not possible to fully evaluate the claims in this document. Given the nature of this standard, the presence or absence of hardware-accelerated cryptographic primitives and/or ROM cryptographic functions is extremely important to device classification. I will assume that “low-end” means Class 0 and Class 1 devices, as defined by RFC7228.

The minimum usable size of the described format is 298 bytes. Assuming no URI, no signing key ID, the critical information for a Class 0 device is:

Sequence number (2 bytes should be adequate for Class 0)
Flags (2 bytes)
Vendor ID (16 bytes)
Class ID (16 bytes)
Payload digest (32 bytes)
Signature (64 bytes)

This format encodes 132 bytes into a 298 byte structure when used with a single image Class 0 device. This does not seem like an improvement over CBOR: draft-moran-suit-manifest-03 would encode this same information into 199 bytes

3. At IETF 103, there was discussion of devices with cryptographic accelerators. Public key acceleration is what is needed for update. Devices with public key acceleration are rare, but becoming more common. In surveying the available devices with ECDSA acceleration, the majority of devices I found had at least 512kiB of Flash, most vendors had offerings with 256KiB of Flash, there was only a single device family I could find with 128kiB of Flash, and none smaller. Each of these devices had 96kiB of RAM or more. These are not Class 0 or Class 1 devices; they are Class 2 or higher, with the possible exception of the 128kiB device, which seems to be somewhere in between.

Does the SUIT working group believe that the size of a minimal manifest parser/validator (<600 bytes) is relevant when compared to the signature verification library in Class 0 or Class 1 devices? Does the working group believe that the size of a more flexible parser (cn-cbor, for example) is relevant on a Class 2 or greater device, when it may have a cryptographic accelerator?

4. It is an advantage to extract data from a packed binary format, rather than a serialised format on low-end devices (Section 1, paragraph 1)

I don’t understand why it is considered an advantage to not run a parser. Parsers are just information accessors. Packed binary formats still need accessors.

Serialised formats do not imply general-purpose parsers. General-purpose parsers incur a lot of overhead, it is true, but specialised format accessors can operate at a similar cost to direct binary encoding. When a general-purpose parser is not appropriate, a serialised format can be consumed by a specialised format accessor can be used instead.

Since code size was raised as a concern, I wrote a validator/information accessor for manifest formats to evaluate the code size of each, when compiled on Arm Cortex-M4. A validator for a minimal subset of draft-moran-suit-manifest-03 consumed 560 bytes. A validator for a minimal subset of draft-pagel-suit-manifest-00 consumed 474 bytes. I would like to know if the working group believes that this savings of 86 bytes of code warrants using a packed binary format.

5. Implementers will pick a fixed format for each target device (Section 1, paragraph 2)

Implementers may well pick a fixed format however, as you note in Section 2, paragraph 1, if they need more than one, fixed binary formats will either incur a additional complexity and overhead. As more options become available in the format, the flexibility of a CBOR format becomes more attractive.

6. Platform providers will provide separate layers (Section 1, paragraph 3)

For Class 0 and Class 1 devices, I find it very unlikely that there will be software layers distributed in separate binaries, with the possible exceptions of: bootloaders, external hardware modules. Perhaps other members of SUIT can provide their views on how firmware is distributed to Class 0 and Class 1 devices.

For Class 2 devices and above, this is more likely. Bear in mind that, for an ABI to make sense, a software component must implement either software interrupts, jump tables, loadable modules, or multiple cores with a core-to-core communication mechanism.

7.  Each layer is signed independently (Section 1, paragraph 3)

For Class 0 and Class 1 devices, validating a signature comes with a high overhead. ECDSA validation can take more than 400ms (https://datatracker.ietf.org/meeting/92/materials/slides-92-lwig-3), which comes with significant energy consumption. I do not expect Class 0 and Class 1 devices to perform many signature verifications. Multiple signatures on a set of images on battery-powered devices, are likely to reduce device lifetime significantly.

draft-moran-suit-manifest-03 shares this challenge. How should devices validate the authenticity of multiple binaries that require different rights without the overhead of multiple signature verifications? I think this is an open area for improvement.

8. Component type implies payload format (Section 1, paragraph 4)

I do not see the benefit of conflating component type and payload format.

If component type implies payload format and both are implementation-defined (Section 1, paragraph 4), there is no way to do IANA registration of payload types. This poses several problems: It requires deep knowledge of each device’s component/type IDs in order to build tools to create manifests. It causes integration problems when using existing libraries for handling components from different vendors: imagine trying to build the updater for a device that has two radio modules—one wifi, one BLE, for example—and each vendor has provided an installer that depends on a type ID; there is no registry available to prevent conflicts between type IDs.

The chance of constructing an erroneous manifest is high because component-type’s meaning is different from target to target.

9. A single 16-bit flags field is sufficient to encode all vendor-specific information (Section 1, paragraph 4)

I don’t understand how the 16 bits in the manifest-set will be adequate to handle the use-cases described. How can a 16-bit integer specify both where to store a payload and to configure encrypted payload handling. The same considerations as 8. apply with regards to IANA registration.

10. No human-readable information is required (Implied, no text fields present in format)

How can a human operator know what a given manifest does without textual descriptions? What are the security considerations around any unauthenticated delivery of textual information?

11. Devices have software components with abstract APIs (Implied by Section 1, paragraph 7, presence of ABI fields in all manifests)

Most Class 1 and all Class 0 devices I have seen use statically linked applications, that effectively have no ABI. For the ABI Dependency information to make sense, it needs to be on a system with modules that communicate via software interrupt, loadable modules, jump tables, or script interpreters. These approaches are far more common in Class 2 or higher devices—devices where a generic CBOR parser would likely be available. The only exceptions that I have seen to this is with regards to boot loaders or external hardware modules, such as radio modules.

12. The manifest should report which ABIs are exposed by the components it contains (Section 1, paragraph 7)

There are many existing mechanisms for referring to ABI versions. I haven’t seen this one before. What are its advantages and disadvantages compared to existing mechanisms?

13. Payloads should be obtained by discovery, not by explicit direction (Section 1, paragraph 9)

This is a reasonable design decision for a system, but I would much rather if that design choice were left up to implementers, rather than enforced in the standard.

Fetching payload by discovery introduces a round-trip query for each device. How would this affect multicast and broadcast use-cases? A payload URI could potentially contain a broadcast interval or a receive slot for the payload. How would a device determine broadcast interval or receive slot without that information being provided in the manifest? I expect that the logic for (1. Authenticating with a remote service, 2. Querying that service for a URL, and 3. Initiating a download) would be much more expensive than resolving a URL in a manifest.

14. Basic devices are better served by binary formats due to space constraints (Section 2, paragraph 2)

Fixed binary formats cannot prune unused fields. This means that a minimal binary format cannot provide intermediate or advanced functionality, meanwhile, an intermediate or advanced fixed binary format is much larger than the space needed for a minimal use-case. To demonstrate this problem, a manifest constructed according to draft-pagel-suit-manifest-00 with a single manifest and a single image consumes 298 bytes. A manifest constructed according to draft-moran-suit-manifest-03 that contains a single image, with no URI consumes, text, or signer identifier, consumes 199 bytes.

15. Sophisticated devices should use CBOR manifests, since they are more flexible (Section 2, paragraph 3)

I agree, sophisticated devices are better served by CBOR manifests. I contend that basic devices are better served by CBOR as well since the format can be tailored exactly to the use-case, while remaining compatible with standard tooling.

16. Byte order is platform specific (Section 3, paragraph 1)

Tools must know the recipient in order to construct a manifest. The chance of constructing an erroneous manifest is high.

17. Signers should be identified by certificate fingerprint (fields described in Section 3)

Maybe this could be changed to Subject Key Identifier? By mandating the use of fingerprints, the implication is that public keys are delivered via certificate. Certificates imply DER parsing, which has far more overhead than a simple CBOR parser. If public keys are delivered via certificate, then the format of the manifest is irrelevant for a constrained device. Subject Key Identifiers allow the use of either certificates or bare keys, which reduces the parsing overhead for signature verification.

18. ManifestEntrySize (Section 3)

I don’t understand what this size is for. Doesn’t the version cover this already?

19. Build Date (Section 3)

This has been debated in the SUIT working group. The wg feels that there are too many problems with timestamped manifests and that a sequence number is more appropriate.

20. No differential updates (Section 4.8)

The draft seems to imply that IoT devices will not use differential updates. I am aware of several products that do use differential updates. Does the working group believe that we should not support differential updates?

21. Content Encryption Key Identifier (Section 4.11)

I don’t see a way for a device to specify an encryption key identifier. How would this be done?

Best Regards,
Brendan

On 7 Nov 2018, at 05:23, Martin Pagel <Martin.Pagel=[email-masked]<mailto:Martin.Pagel=[email-masked]>> wrote:

Thanks, Amayas,

From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Amyas Phillips

_______________________________________________
Suit mailing list
[email-masked]<mailto:[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: Martin Pagel <[email-masked]>
Date: Mon, 19 Nov 2018 23:40:33 +0000

Brendan,
See responses with * below:
Best
Martin

From: Brendan Moran <[email-masked]>

1. I do not understand how images are authenticated. I see no reference to an image digest. Are images concatenated inline within the structure? I see no reference to concatenation within the format definition.
* Each image can be downloaded and authenticated separately. The image file should have a digest, key identifier or thumbprint, and signature using a platform specific format at the end of the file.

* Brendan, I don’t understand why you think it would require 298 bytes to store 132 bytes, can you explain?
Also, the digest and signature are platform specific and only listed for reference. (if the device supports COSE, it might even use COSE putting it on par )

* public key crypto accelerators are quite small and easy to add even to a Class 1 MCU as we did with the MT3620. Driven by increasing security awareness, we expect more MCUs to support them.

* If you don’t use a parser, you not only save the parsing code (see my code in separate email), but you won’t need to a separate temporary buffer to load the manifest file into, too.

* yes, a binary format will increase the complexity to support variances in the data formats on the server side, but reduce the complexity for simple devices. The server needs to know a lot about each platform anyways, as it can’t expect that each device can handle any type of signature format, payload format etc. CBOR allows for flexibility but I believe that’s a flexibility a device shouldn’t have to worry about as it increases complexity and therefore code and data size and the risk for exposures. If the server ignores the fact, that a device won’t/can’t handle certain parameters, this may cause some very unexpected problems so you better develop the Update Server in a way it understands the capabilities of the devices it supports.

* Not sure what your point is…  Yes, I agree that you may not need ABI info for Class 0+1, it would be easy to leave that out.

For Class 0 and Class 1 devices, validating a signature comes with a high overhead. ECDSA validation can take more than 400ms (https://datatracker.ietf.org/meeting/92/materials/slides-92-lwig-3<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F92%2Fmaterials%2Fslides-92-lwig-3&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Cd0a33198464d446f423708d64be524b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636779844877229449&sdata=jNGDdmq%2F%2BMuP%2Bl2%2B7rVaOZb2kiYVEzZ0%2FjIB26G33hs%3D&reserved=0>), which comes with significant energy consumption. I do not expect Class 0 and Class 1 devices to perform many signature verifications. Multiple signatures on a set of images on battery-powered devices, are likely to reduce device lifetime significantly.

* I share your concern. Simple devices typically only have access to a single key associated with the Update Server. For such devices, the Update Server would need to verify the signatures from the various vendors and combine it into a single manifest with a single signature.

* I think the device’s installer for Class 0+1 devices would only support a few payload formats and not be able to launch separate installers. Just because a payload has IANA registration, the device won’t know how to deal with it. So either the vendor would have to provide the software in one such formats, or the Update Server may have to convert the format from the vendor’s format to one of the device’s format.

* It’s expected that the device installer understands certain image types and knows how and where to install them or how to decrypt them if it supports encryption. The flags will only be necessary in case the device offers any install options.

* My understanding was that this work group would focus on automated updates through an Update Server and not concern itself with human installations. Am I missing something?

* Yes, I agree that you may not need ABI info for Class 0+1, it would be easy to leave that out.

* We chose this implementation for its simplicity. Brendan, do you have a better method in mind?

* Installers for basic devices are usually configured for a particular update mechanism, meaning they watch a broadcast slot or can turn the ImageId into a URL and don’t necessarily need to make additional calls.

* the data structure for a single image is only 100 bytes (the size of the signature depends on the platform). If you want to eliminate portions (such as ABI dependencies), then you can define a custom data structure version, that’s what the Version parameter is for.

* most platforms now use the same byte order and you still need to do testing anyways.

* that would be fine

* it’s an optimization to make it a bit easier to find the signature portion, but not totally necessary.

* There may be some advantage for humans to interpret the timestamp, but I don’t have strong feelings either way.

* For large software systems, differential updates are certainly useful, but we didn’t feel that for class 0+1, the file size vs complexity is worth the effort in particular if the device may not be online for a long time, then it has to download the full image anyways once it comes online again.

* It could use a portion of the Flags parameter to identify the key. Btw, I have not seen any discussion on key management, did I miss this?

---

From: Brendan Moran <[email-masked]>
Date: Thu, 22 Nov 2018 16:13:49 +0000

Hi Martin,

Please see my responses below.

Best Regards,
Brendan

On 19 Nov 2018, at 23:40, Martin Pagel <[email-masked]<mailto:[email-masked]>> wrote:

Brendan,

From: Brendan Moran <[email-masked]<mailto:[email-masked]>>

Does that mean that this format mandates an additional signature per image on top of the one in the manifest? If there is another way to authenticate the image, I have not been able to spot it.

From what I understood in the draft, the minimum size of the manifest described was:

sizeof(ManifestSetHeader) = 10
sizeof(Manifest) = 130
sizeof(ImageManifestEntry) = 74
sizeof(ManifestSetFooter) = 84
============
298

The ManifestSetHeader appears to be mandatory because it’s the only block that contains Magic and Flags, both of which are necessary for the device to understand the manifest. If the ManifestSetHeader is necessary, then the ManifestSetFooter is mandatory too.

If the digest and signature are platform-specific, and no type is provided, how can intermediate systems validate the manifest?

Can you quantify what quite small means? The smallest ECDSA IP I found advertised 16000 gates. Class 0 and Class 1 CPUs run in the range of 12,000 gates for Cortex-M0+ to 33,000 gates for a Cortex-M3. Adding 16,000 gates to that size of CPU may be acceptable in some applications, but it likely won’t in others. I don’t think the working group should be reasoning about code size based on the availability of ECDSA accelerators when it’s not clear that devices targeted by SUIT will always have them. If we can get some clarity on the availability of ECDSA accelerators in Class 0 and Class 1 devices, then maybe we can adjust our reasoning.

I don’t understand how the MT3620 is relevant when discussing Class 1 devices. It’s a Cortex-A7 at 500MHz, 2 general purpose Cortex-M4 at 200MHz, and one special purpose Cortex-M4 integrated into the security subsystem. It has 16MiB of Flash and each M4 has 256kiB of RAM. That is so far beyond a Class 2 device that it’s not even possible to discuss in terms defined by RFC7228.

https://www.mediatek.com/products/azureSphere/mt3620

But access and validation still aren’t free. I will post my code in the next few days. It costs 474 bytes of Thumb2 code to extract necessary information and validate the structure. If you look at the CBOR parser that I shared, it uses no temporary buffers.

The draft-ietf-suit-architecture defines the creator of SUIT manifests as separate from the server. The author of a manifest, which is locked to a particular device class by the ClassID, should know what the capabilities of a device are. The reduction in complexity on simple devices is 86 bytes (See 4). CBOR encoding, however, reduces the size of the manifest: 199 bytes in draft-moran-suit-manifest-03 vs. 298 in draft-pagel-suit-manifest-00.

My point is that every piece of unused information in a manifest consumes space and must be validated. For example, if a device supports no ABIs (as expected in a single-image device), is it an error for it to specify an ABI dependency? I would think that it has to be an error, since that would imply that the device cannot operate. That means that the dependencies must be validated to be a NULL value—I have assumed that this is 0 in my code.

How many different manifest structures will be defined in this specification?

That introduces a single point of failure in a network-connected machine into the system. This breaks the end-to-end security guarantees of SUIT. draft-ietf-suit-architecture-01 explicitly separates the role of the update server from the Firmware Authority’s private key. There are some instances where this may be permissible, as raised in the discussion at IETF 101, but I don’t think this should be the default.

This isn’t about how the device handles IANA-registered types, it’s about how the tools for creating manifests work. If each device has different types, then there can’t be any standard tools: the tools need to be customised for every device.

I don’t see how this helps when the flags are in the ManifestSetHeader. How can the installer know which flags apply to which manifests/images? Or does a given device only accept a single configuration of manifests and images? The lack of specification for this field and the overloading that is necessary when there is no clear link between flags and manifests and images makes me worry that this will be very difficult to get right.

If you have multiple broadcast and encrypted images, then it’s going to be difficult to pack all the required options into the flags field, with no option to get more flags. You’ll need some bits to indicate the broadcast slot for each image and some bits to indicate the key identifier for each encrypted image. Does this limit the number of images that can be distributed in a single update if they are broadcast and encrypted? Or does it limit how many keys can be used? Or how many broadcast slots can be used?

Conflating flags from different manifests causes an authority problem too. How can the author of the ManifestSetHeader hold sole authority to specify any installation options, encryption keys, etc., when they are not the party responsible for that information? Shouldn’t all information relevant to a particular manifest be authenticated in that manifest?

Regardless of the level of automation, at some point, a human must have to make a decision to apply a particular firmware to a particular set of devices. If that human is NOT the creator of the ManifestSet, then how can they make a decision without human-readable information?

But this means that there will be two manifest structures instead of one. How many different versions of the same structure will be included in this draft?

The concern I have is that this is very difficult to interpret. How does the Update Server find missing dependencies? I would have expected something more like (Image UID + version identifier). Otherwise, each image has two different identifiers: the image UID and the ABI. What does ABI actually indicate? The definition is very light: I wouldn’t know how to construct a depends-on ABI, or a provides ABI, given the existing draft.

The draft specifies one behaviour: the device queries a known service for a URI, for each image, which it then fetches. How would these devices know which broadcast slot to watch? Or does this specification mandate that images are only ever broadcast in a particular slot? If the Flags field is the answer, then do all images in a given ManifestSet have to be broadcast in the same slot?

I don’t understand how it can be 100 bytes. The sizes of the structures defined in the draft are:

sizeof(ManifestSetHeader) = 10
sizeof(Manifest) = 130
sizeof(ImageManifestEntry) = 74
sizeof(ManifestSetFooter) = 84

Which parts of these are combined to make 100 bytes? And how can you use a subset when each part of these structures contains some necessary information?

ManifestSetHeader => flags
Manifest => Vendor/Class ID
ImageManifestEntry => Image ID, type, size
ManifestSetFooter => signature

Then that byte order should be specified. Otherwise, it will cause integration headaches.

* that would be fine

Most NB-IoT, LoRA, and LP-WAN devices in general require differential updates due to their very limited bandwidth. Likewise, satellite-connected devices will require differential update due to the very expensive bandwidth (both in power and in money).

This flags field is starting to contain a lot of data! I’ve seen it suggested to carry:
* Encryption key identifiers
* Install options
* Additional information about where to fetch images

Key management is explicitly out of scope for now, but that doesn’t mean we can’t assume that devices have access to keys that are referenced by some form of identifier.

---

From: Martin Pagel <[email-masked]>
Date: Wed, 28 Nov 2018 01:01:36 +0000

Thanks, Brendan, for your detailed questions!
See responses with * below:
Best
Martin

Does that mean that this format mandates an additional signature per image on top of the one in the manifest? If there is another way to authenticate the image, I have not been able to spot it.
* yes, makes processing simple, in particular if the device has a crypto processor. If that’s not the case, it might be better to include a digest in the ImageManifestEntry.

* For a fair comparison, you need to compare apples to apples. It might be good to compare a binary and a CBOR version of the same data fields and signature methods, for example either they support ABI version dependencies or they don’t.
Neither the magic nor the flags are always necessary. We have used the Manifest structure for simple applications by itself. Actually you could reduce the size further by eliminating some of the manifest and ImageManifestEntry fields like suggested in your CBOR minimum proposal.

https://www.mediatek.com/products/azureSphere/mt3620<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mediatek.com%2Fproducts%2FazureSphere%2Fmt3620&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Cff78e11c38054fc38fa008d650957ea5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636785000369806123&sdata=Ox%2BHm5BAag1pY39CGWAr%2FKQyBlmxWq7qQ%2B66spJ9DlQ%3D&reserved=0>

* Yes, good point, a better example: https://www.microchip.com/promo/sam-l10-and-l11-microcontroller-family which also includes a crypto processor

* I provided you minimal access code, there is no need for any access or validation code. Yes, I understand your minimal parser essentially returns pointers into the initial read buffer, but to do so it requires a lot of pointer calculation and dereferencing making for some lengthy and complex code increasing the complexity and potential risk for exposure whereas with the binary format you just have fixed offsets into the buffer which the compiler resolves without any need for pointer storage/handling.

Thanks again for providing the parser code. Min-parse.c shows nicely the header overhead the CBOR encoding incurs:
- 15 bytes for wrapper_to_signature
- 4 byte for manifest_to_seq
- 7 bytes for preinstall_prefix
- 3 bytes for classid_prefix
- 18 bytes for install_prefix
- 6 bytes for payload_prefix
- 11 bytes for payload_digest_prefix
For a total of 64 bytes of encoding overhead, correct, or am I missing something?

* No, CBOR adds 64bytes (see 4)

* I see the most important value of this standard the architecture and information model. There is some value in also showing common ways to encode a manifest, but I expect that each type of device will have slightly different needs and therefore will choose compression, encryption, and signature formats and the exact set of fields it expects in the manifest. You already proposed a bare minimum format for CBOR. I would expect a device manufacturer to drop fields from the binary format. If they ever need to change that set, they can support a new Manifest format, that’s what the Version parameter is for. The standard should have to mandate the permutations of fields, it should be up to the manufacturer to document what fields and formats it expects in a manifest for a particular device (VendorId/ClassId permutation) and its format (CBOR vs binary) so that intermediary systems can maintain the proper field mappings.

For Class 0 and Class 1 devices, validating a signature comes with a high overhead. ECDSA validation can take more than 400ms (https://datatracker.ietf.org/meeting/92/materials/slides-92-lwig-3<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F92%2Fmaterials%2Fslides-92-lwig-3&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Cff78e11c38054fc38fa008d650957ea5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636785000369816131&sdata=lHcR%2FOZMXyuTNZ4UugUbSOlmaqcyQE4Lgn1O4Z6p4DQ%3D&reserved=0>), which comes with significant energy consumption. I do not expect Class 0 and Class 1 devices to perform many signature verifications. Multiple signatures on a set of images on battery-powered devices, are likely to reduce device lifetime significantly.

* Do you suggest a different implementation to keep the number of signature validations to a minimum?

* Again, the tools already need to know what devices they target as they need to know what signature, image types etc each device supports. It won’t help if a tool generates a payload in a particular IANA type, if the device’s installer doesn’t support such type.

* The Flags are meant only for general installation options. If a particular image requires special processing such as decompression, a separate component Type should be used. Ultimately it’s all up to what the device’s installer can handle, that’s the ultimate authority.

* I believe the manifest format should be optimized for machine consumption and have not seen any requirements in the current spec for human consumption. But I could see that an update server may provide a separate version for human consumption or show/break up an existing manifest for such purpose.

* see 6

* good point, I can provide an example how we envision this to work, let me respond separately.

* The URI may either include a broadcast slot or, if the installer supports broadcast delivery, the service may return not just URI but also a broadcast slot.

* see 2

* An Update Server (or any other tool/intermediary system) is expected to understand the formats supported by each device including byte and signature format.

* that would be fine

Most NB-IoT, LoRA, and LP-WAN devices in general require differential updates due to their very limited bandwidth. Likewise, satellite-connected devices will require differential update due to the very expensive bandwidth (both in power and in money

*I wonder what the minimum data package size for LoRA is, do you know?
More complex device will use multiple images which can be updated separately. The simple devices will only have small software to update and may not have space for differential update code. So I wonder how important this feature is.

*If the device supports multiple signature keys, it may want to include a key thumbprint in the signature portion. On image download location: see 13

Best

Martin