Subject: Re: [Suit] A few comments on draft-ietf-suit-manifest-02

From: Brendan Moran <[email-masked]>
Date: Tue, 4 Feb 2020 17:27:56 +0000

Hi Russ,

Thanks again for your comments. I have finished most of the resulting updates. I’m planning to publish two versions in sequence to limit the diff noise. The first version will contain spelling and formatting updates. The second will contain changes of greater substance.

I have some proposals related to your comments on which I would like some feedback from the list. Please see comments and proposals inline.

Best Regards,
Brendan

On 20 Jan 2020, at 21:32, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

I have a few comment on draft-ietf-suit-manifest-02:

General: The RFC Style Guide says to use American English spelling. Please change it now to avoid confusion later (e.g., Behaviour --> Behavior).

Section 2: Please add a sentence before all fo the definitions.  Otherwise, the "as shown here" from the RFC 8174 citation is easy to read incorrectly.

Section 2: The last 4 paragraphs are not really about conventions or terminology at the same level as the rest of the section.  They are CBOR specific, and I wonder if they would bit better toward the end of Section 4 or the beginning of Section 5 in a subsection of their own.

I have moved these to Section 7, which discusses CBOR format, since that seems most relevant.

Section 4: The bullets and numbered items in 4.1 end with periods, but the ones in 4.2 and 4.3 do not.  Please pick one style and use it everywhere.

Section 4.2: In the five steps, is there a problem if an implementations swaps steps 1 and 2?  If so, please explain.  If not, the document should say that conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. That is, any algorithm may be used by a particular implementation so long as it produces the correct result.

I’ve added a new section in response to this comment. Here’s the proposed text:

### Pre-Authentication Compatibility Checks

The RECOMMENDED process is to verify the signature of the manifest prior to parsing/executing any section of the manifest. This guards the parser against arbitrary input by unauthenticated third parties, but it costs extra energy when a device receives an incompatible manifest.

If a device:

1. expects to receive many incompatible manifests.
2. expects to receive few manifests with failing signatures--for example if it is behind a gateway that checks signatures.
3. has a power budget that makes signature verification undesirable.

Then, the device MAY choose to parse and execute only the SUIT_Common section of the manifest prior to signature verification. The guidelines in [Creating Manifests](#creating-manifests) require that the common section contain the applicability checks, so this section is sufficient for applicability verification. The manifest parser MUST NOT execute any command with side-effects outside the parser (for example, Run, Copy, Swap, or Fetch commands) prior to authentication and any such command MUST result in an error.

Section 4.2 says: "If verification and running is implemented in bootloader, then the".  Please complete the thought.

Section 4.4: I think that "specifies behaviours in a linearised form" can simply be "specifies linear behavior".

Section 4.4: I wonder if "authenticated by the appropriate identity have access to operate" is the right concept.  I think the point is that the process will reject software that is not authenticated to an identity on the ACL.

I’ve expanded this thought a bit:
Developing a robust permissions system works in this model too. The Recipient can use a simple ACL that is a table of Identities and Component Identifier permissions to ensure that operations on components fail unless they are permitted by the ACL. This table can be further refined with individual parameters and commands.

Section 5.1: RFC 4108 includes the concept of a "stale version".  Please see Section 1.2.3.2 of RFC 4108.  Do we want a capability to prevent roll-back to a previous version that has a disastrous flaw?

This is an important consideration. The simplest part of the change is to add a line in section 5.1 about receiving a critical flaw notice. We have a complex interplay between the two requirements: resilience and security.

The intent of the manifest sequence number is to prevent exactly this sort of situation. However, for resilience it is necessary for devices to be able to accept a manifest that is not the latest. This conflicts with the non-rollback requirements that is detailed in the information model.

So how do we revoke a particular manifest? And is it the manifest’s job to contain that information? It sounds suspiciously like CRLs. If we were to include “do not use” sequence numbers in manifests, that could cause a few problems:

  1.  What happens if there is a valid manifest which invalidates the only usable firmware, but fails to provide a new one, e.g. through connection errors?
  2.  What happens if a device misses the manifest that invalidates the flawed firmware?
  3.  Who is authorised to prevent a flawed firmware from being used? Is it only someone with rights to the targeted components? Or is someone else allowed to have those rights?

To me, it looks like the updater’s job to invalidate flawed firmware. The updater should have access rights to non-active firmware manifests—it may or may not have access to the active firmware manifest, depending on the system architecture. An updater can invalidate a flawed firmware simply by erasing its manifest.

Should we have a command to invalidate a manifest? If so, should it identify the manifest by digest or by sequence number?

Section 7: I find the numbering confusing.  the is a top-level "1" without a "2".  Perhaps typical outline numbering would be more clear.

Section 7 and 11: We need to come up with a presentation that will keep the line length under 73 characters.  Maybe something like:

  SUIT_Common = {
      ? suit-dependencies
            => bstr .cbor [ + SUIT_Dependency ],
      ? suit-components
            => bstr .cbor [ + SUIT_Component_Identifier ],
      ? suit-dependency-components
            => bstr .cbor [ + SUIT_Component_Reference ],
      ? suit-common-sequence
            => bstr .cbor SUIT_Command_Sequence,
  }

Section 12: Please say in the introduction what one-way hash function is used.

Section 13: Please provide the rules for additions to each of the IANA registries that are identified.

Russ

_______________________________________________
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: Russ Housley <[email-masked]>
Date: Tue, 4 Feb 2020 12:43:41 -0500

Brendan:

> What happens if there is a valid manifest which invalidates the only usable firmware, but fails to provide a new one, e.g. through connection errors?
> What happens if a device misses the manifest that invalidates the flawed firmware?
> Who is authorised to prevent a flawed firmware from being used? Is it only someone with rights to the targeted components? Or is someone else allowed to have those rights?
> 

Rollback is needed because mistakes happen.  The ability to mark some old manifest as stale is needed because mistakes happen.

I'd like to see a mechanism that does not have any linkage to the storage or distribution model of manifests.  For that reason, I would like to see a command that implements "rollback prevented for sequence numbers before" X.

Russ