[Suit] AD Review of draft-ietf-suit-architecture-11

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-suit-architecture-11.  I have a few editorial comments and some places where additional clarity would be helpful.  These can be handle in parallel to the IETF LC.

** Abstract.  "... a solid and secure firmware update mechanism ...", "solid" seems imprecise?

** Abstract. Typo. s/Incorporating such update mechanism/Incorporating such an update mechanism/

** Abstract.  "Incorporating such [an] update mechanism ... is recommended by security experts", is there a reference for those experts.  Obviously it can'' be cited in the abstract, but I was expecting this claim to be backed somewhere in the subsequent text.  Is it perhaps the [RFC8240]?

** Section 1.  "When developing Internet Of Things (IoT) devices, one of the most difficult problems to solve ...", I don't disagree.  Is there a reference that can be used to back this claim?

** Section 1.  Editorial. s/into used software libraries/into the software libraries used/ 

** Section 1.  Editorial. Per "[t]his version of the document assumes ... Future versions ...", this language confused me a bit.  It seems to me that this document specifies some particular assumptions.  However, an updated specification might say something else.  Practically, there isn't going to be a "future version of _this_ document". 

** Section 2.  Typo. s/the the/the/

** Section 2.  Typo. s/succesfully/successfully/

** Section 2.  Typo. s/interchangably/interchangeably/

** Section 2.  Per the definition of the status tracker, it would be helpful to also note the diversity of options on who operates it, in addition to the deployment models.  The operator could be the author, device owner, or even a third party.

** Section 3.3. Per "For confidentiality protection of the firmware image, it must be done in such a way that every intended recipient can decrypt it", is there a missing (very obvious) qualifier to add - "... and no one else".   

** Section 3.3.  Per "Due to the nature of unchangeable code in ROM ... the use of post-quantum secure signature mechanisms ...are attractive", what is one to do with this (correct) observation.  It doesn't seem aligned with the style/framing of the other text/requirements - i.e., what does "attractive" mean?

** Section 3.3. Typo. s/[I-D.ietf-suit-manifest]}/ [I-D.ietf-suit-manifest]/

** Section 3.5.  Per "A power failure at any time must not cause a failure of the device", this seems to be specifying things outside the scope of the update mechanism.

** Section 3.5.  Per "One way to achieve this functionality ...", no disagreement, but this seems to veer into how to satisfy the requirement rather than articulating it (which is what this section seems to be about)

** Section 3.7.  Per "Since parsers are known sources of bugs they must be minimal", "minimal" how?  How do I know I have a "small parser"?  To give an ridiculous example, I could strip out all error handling from my parser to make it's binary footprint be small?   I'm not thinking this needs to be precisely defined, but are we talking about complexity? Including only the bare necessary features? Possible to implement without a lot of external library dependencies?

** Section 3.7.  Per "Additionally, it must be easy to parse only those fields that are required to validate at least one signature or MAC with minimal   exposure", what is "minimal exposure" in this context?  

** Section 3.9.  This section didn't read like a requirement.  It reads like a statement of what the architecture is.

** Section 3.10.  This section didn't read like a requirement.  It reads like a statement of what the architecture is.

** Section 3.11.  Per "Later it turns out that other use cases may benefit from a standardized manifest format also for conveying software and even    personalization data alongside software.", I'm confused about the distinctions between made here.

--  "... may benefit from a standardized manifest format also for conveying software ...", right, what's new use case?  All along "software" or "firmware" (interchangeable words per Section 2) have been the focus.  What's different about the software here?

-- why is "... personalization data" special?  Section 1 already noted that "configuration data" is part of the software?  Is it that there is some kind of additional user interaction?

** Section 3.11. Editorial. s/format also for/format for also/

** Section 5.  Per "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", no issues with this guidance.  However, Section 1 notes that PSK wouldn't be discussed (i.e., Section 1 = "This version of the document assumes asymmetric cryptography and a public key infrastructure.  Future versions may also describe a symmetric key approach for very constrained devices.")

** Section 5.  The narrative for Figure 4 doesn't seem complete.  For example, it doesn't explain the sequencing of the manifest vs. firmware delivery, or the role of the status tracker.

** Section 8.  Per "Hence, the following building blocks are necessary for a firmware update solution: ...", I read the bullet as these are "must haves" for the device.  However, I thought that integration with the device management server per the operating model requirement in Section 3.10 was only applicable to server-initiated and hybrid?  Do I need the device management server in system that only supports client-initiated operation?

** Section 8.  Per "... ability to access security algorithms, such as SHA-256, to compute a fingerprint over the firmware image and a digital signature algorithm ", 
-- would it be worthwhile to drop the reference to SHA-256 to make the text more generic?
-- would it be more accurate to say: "... ability to use a cryptographic library or API to compute a fingerprint and verify the digital signature of the firmware image" 

** Figure 5. Typo.  In Title.  s/Upate/Update/

** Section 9.  Editorial.
OLD
   Figure 6 shows an example follow with the device using a status
   tracker.  

NEW
Figure 6 illustrates an example where a device using a status tracker.

** Section 9.  Per "At a later point in time the author uploads a new firmware along with the manifest to the ... the status tracker ...", given that there are multiple ways in which the status tracker could learn about these updates beyond the author explicitly uploading it (and that this is the only example with the status tracker), it might be helpful to clarify the other possibilities too.

** Section 11.  This section makes a robust list of what is important, but out of scope.  Such a list is helpful.  I think what would also be helpful to restate the requirements for the security properties of this architecture, even if this is done by reference to text in Section 3.  I'd recommend saying something like:

-- No reliance on link, network or transport layer security properties (Section 3.2)
-- Authentication of the identity of the manifest and firmware image author (Section 3.3)
-- End-to-end integrity of the manifest between the author and device (Section 3.3)
-- End-to-end integrity of the firmware image between the author and the device (Section 3.3) 
-- to include confidentiality, integrity and authentication
-- Rollback protection for the device (Section 3.4)
-- Support for expressive authorization permissions (Section 3.9)

Regards,
Roman