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

[Brendan Moran <[e-mail]>]

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=[e-mail]<mailto:Martin.Pagel=[e-mail]>> wrote:

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

From: Suit <[e-mail]<mailto:[e-mail]>> 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.



_______________________________________________
Suit mailing list
[e-mail]<mailto:[e-mail]>
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.