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

[Russ Housley <[e-mail]>]

Brendan:

>> 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:
> 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?
> 
> 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? 

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