Change:
happening on multiple CPUs, upgrading the two images atomically is challenging. <del> 8. </del> <ins> 6. </ins> <del> More devices today than ever before are being connected to the Internet, which drives the need for firmware updates to be provided over the Internet rather than through traditional interfaces, such as USB or RS232.  Updating a device over the Internet requires the device to fetch not only the firmware image but also the manifest. Hence, the following building blocks are necessary for a firmware update solution: </del> <ins> In order for a firmware consumer to apply an update, it has to make several decisions using manifest-provided information and data available on the device itself.  For more detailed information and a longer list of information elements in the manifest consult the information model specification I-D.ietf-suit-information-model, which offers justifications for each element, and the manifest, see I-D.ietf-suit-manifest}, for details about how this information is included in the manifest. manifest-info provides examples of decisions to be made. (1): A device presented with an old, but valid manifest and firmware must not be tricked into installing such firmware since a vulnerability in the old firmware image may allow an attacker to gain control of the device. Keeping the code size and complexity of a manifest parsers small is important for constrained IoT devices.  Since the manifest parsing code may also be used by the bootloader it is part of the trusted computing base. A manifest may not only be used to protect firmware images but also personalization data related to firmware or software.  Trusted Execution Environments (TEEs), for example, benefit from a protocol for managing the lifecycle of trusted applications (TAs) running inside a TEE.  TEEs may obtain TAs from different authors and those TAs may require personalization data, such as payment information, to be securely conveyed to the TEE. </ins> <del> the Internet protocol stack for firmware downloads (*), </del> <ins> 7. </ins> <del> the capability to write the received firmware image to persistent storage (most likely flash memory) prior to performing the update, the ability to unpack, decompress or otherwise process the received firmware image, the features to verify an image and a manifest, including digital signature verification or checking a message authentication code, a manifest parsing library, and integration of the device into a device management server to perform automatic firmware updates and to track their progress. (*) Because firmware images are often multiple kilobytes, sometimes exceeding one hundred kilobytes, in size for low end IoT devices and even several megabytes large for IoT devices running full-fledged operating systems like Linux, the protocol mechanism for retrieving these images needs to offer features like congestion control, flow control, fragmentation and reassembly, and mechanisms to resume interrupted or corrupted transfers. All these features are most likely offered by the application, i.e. firmware consumer, running on the device (except for basic security algorithms that may run either on a trusted execution environment or on a separate hardware security MCU/module) rather than by the bootloader itself. Once manifests have been processed and firmware images successfully downloaded and verified the device needs to hand control over to the bootloader.  In most cases this requires the MCU to restart.  Once the MCU has initiated a restart, the bootloader takes over control and determines whether the newly downloaded firmware image should be executed. The boot process is security sensitive because the firmware images may, for example, be stored in off-chip flash memory giving attackers easy access to the image for reverse engineering and potentially also for modifying the binary.  The bootloader will therefore have to perform security checks on the firmware image before it can be booted.  These security checks by the bootloader happen in addition to the security checks that happened when the firmware image and the manifest were downloaded. The manifest may have been stored alongside the firmware image to allow re-verification of the firmware image during every boot attempt.  Alternatively, secure boot-specific meta-data may have been created by the application after a successful firmware download and verification process.  Whether to re-use the standardized manifest format that was used during the initial firmware retrieval process or whether it is better to use a different format for the secure boot- specific meta-data depends on the system design.  The manifest format does, however, have the capability to serve also as a building block for secure boot with its severable elements that allow shrinking the size of the manifest by stripping elements that are no longer needed. In order to satisfy the reliability requirements defined in reliability, devices must always be able to return to a working firmware image.  This has implications for the design of the bootloader: If the firmware image contains the firmware consumer functionality, as described above, then the bootloader must be able to roll back to a working firmware image.  Alternatively, the bootloader may have enough functionality to fetch a firmware image plus manifest from a firmware server over the Internet.  A multi- stage bootloader may soften this requirement at the expense of a more sophisticated boot process. For a bootloader to offer a secure boot mechanism it needs to provide the following features: ability to access security algorithms, such as SHA-256 to compute a fingerprint over the firmware image and a digital signature algorithm. access keying material directly or indirectly to utilize the digital signature.  The device needs to have a trust anchor store. ability to expose boot process-related data to the application firmware (such as to the device management software).  This allows a device management server to determine whether the firmware update has been successful and, if not, what errors occurred. to (optionally) offer attestation information (such as measurements). While the software architecture of the bootloader and its security mechanisms are implementation-specific, the manifest can be used to control the firmware download from the Internet in addition to augmenting secure boot process.  These building blocks are highly relevant for the design of the manifest. </del> <ins> Using firmware updates to fix vulnerabilities in devices is important but securing this update mechanism is equally important since security problems are exacerbated.  Failure to secure the firmware update process will help attackers to take control over devices. </ins> <del> 9. </del> <ins> End-to-end security mechanisms are used to protect the firmware image and the manifest.  The following assumptions are made to allow the firmware consumer to verify the received firmware image and manifest before updating software: Authentication ensures that the device can cryptographically identify the author(s) creating firmware images and manifests. Authenticated identities may be used as input to the authorization process.  Not all entities creating and signing manifests have the same permissions.  A device needs to determine whether the requested action is indeed covered by the permission of the party that signed the manifest.  Informing the device about the permissions of the different parties also happens in an out-of- band fashion and is also a duty of the Trust Provisioning Authority. Integrity protection ensures that no third party can modify the manifest or the firmware image.  To accept an update, a device needs to verify the signature covering the manifest.  There may be one or multiple manifests that need to be validated, potentially signed by different parties.  The device needs to be in possession of the trust anchors to verify those signatures.  Installing trust anchors to devices via the Trust Provisioning Authority happens in an out-of-band fashion prior to the firmware update process. For confidentiality protection of the firmware image, it must be done in such a way that the intended firmware consumer(s) can decrypt it.  The information that is encrypted individually for each device must maintain friendliness to Content Distribution Networks, bulk storage, and broadcast protocols.  For confidentiality protection of firmware images the author needs to be in possession of the certificate/public key or a pre-shared key of a device.  The use of confidentiality protection of firmware images is optional. </ins> <del> firmware-update illustrates an example message flow for distributing a firmware image to a device starting with an author uploading the new firmware to firmware server and creating a manifest.  The firmware and manifest are stored on the same firmware server.  This setup does not use a status tracker and the firmware consumer component is therefore responsible for periodically checking whether a new firmware image is available for download. firmware-update2 shows an example follow with the device using a status tracker.  For editorial reasons the author publishing the manifest at the status tracker and the firmware image at the firmware server is not shown.  Also omitted is the secure boot process following the successful firmware update process. The exchange starts with the device interacting with the status tracker; the details of such exchange will vary with the different device management systems being used.  In any case, the status tracker learns about the firmware version of the devices it manages. In our example, the device under management is using firmware version A.B.C.  At a later point in time the author uploads a new firmware along with the manifest to the firmware server and the status tracker, respectively.  While there is no need to store the manifest and the firmware on different servers this example shows a common pattern used in the industry.  The status tracker may then automatically, based on human intervention or based on a more complex policy decide to inform the device about the newly available firmware image.  In our example, it does so by pushing the manifest to the firmware consumer.  The firmware consumer downloads the firmware image with the newer version X.Y.Z after successful validation of the manifest.  Subsequently, a reboot is initiated and the secure boot process starts. </del> <ins> A manifest specification must support different cryptographic algorithms and algorithm extensibility.  Due of the nature of unchangeable code in ROM for bootloaders the use of post-quantum secure signature mechanisms, such as hash-based signatures RFC8778, are attractive.  These algorithms maintain security in presence of quantum computers. </ins> <del> 10. </del> <ins> When a device obtains a monolithic firmware image from a single author without any additional approval steps then the authorization flow is relatively simple.  There are, however, other cases where more complex policy decisions need to be made before updating a device. </ins> <del> This document does not require any actions by IANA. </del> <ins> In this architecture the authorization policy is separated from the underlying communication architecture.  This is accomplished by separating the entities from their permissions.  For example, an author may not have the authority to install a firmware image on a device in critical infrastructure without the authorization of a device operator.  In this case, the device may be programmed to reject firmware updates unless they are signed both by the firmware author and by the device operator. </ins> <del> 11. </del> <ins> Alternatively, a device may trust precisely one entity, which does all permission management and coordination.  This entity allows the device to offload complex permissions calculations for the device. </ins> <del> Firmware updates fix security vulnerabilities and are considered to be an important building block in securing IoT devices.  Due to the importance of firmware updates for IoT devices the Internet Architecture Board (IAB) organized a 'Workshop on Internet of Things (IoT) Software Update (IOTSU)', which took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at the big picture.  A report about this workshop can be found at RFC8240.  A standardized firmware manifest format providing end-to- end security from the author to the device will be specified in a separate document. There are, however, many other considerations raised during the workshop.  Many of them are outside the scope of standardization organizations since they fall into the realm of product engineering, regulatory frameworks, and business models.  The following considerations are outside the scope of this document, namely installing firmware updates in a robust fashion so that the update does not break the device functionality of the environment this device operates in. </del> <ins> 8. </ins> <del> installing firmware updates in a timely fashion considering the complexity of the decision making process of updating devices, potential re-certification requirements, and the need for user consent to install updates. </del> <ins> firmware-update illustrates an example message flow for distributing a firmware image to a device.  The firmware and manifest are stored on the same firmware server and distributed in a detached manner. firmware-update2 shows an exchange that starts with the status tracker querying the device for its current firmware version.  Later, a new firmware version becomes available and since this device is running an older version the status tracker server interacts with the device to initiate an update. The manifest and the firmware are stored on different servers in this example.  When the device processes the manifest it learns where to download the new firmware version.  The firmware consumer downloads the firmware image with the newer version X.Y.Z after successful validation of the manifest.  Subsequently, a reboot is initiated and the secure boot process starts.  Finally, the device reports the successful boot of the new firmware version. </ins> <del> the distribution of the actual firmware update, potentially in an efficient manner to a large number of devices without human involvement. </del> <ins> 9. </ins> <del> energy efficiency and battery lifetime considerations. </del> <ins> This document does not require any actions by IANA. </ins> <del> key management required for verifying the digital signature protecting the manifest. </del> <ins> 10. </ins> <del> incentives for manufacturers to offer a firmware update mechanism as part of their IoT products. </del> <ins> This document describes terminology, requirements and an architecture for firmware updates of IoT devices.  The content of the document is thereby focused on improving security of IoT devices via firmware update mechanisms and informs the standardization of a manifest format. </ins>

Discussion:
First chunk of changes.
This is a really great set of edits. I think that it really improves the document as a whole! I have suggested a couple of minor edits.Quick partial language review