Re: [Suit] Suit manifest with variable recipients

[Michael Richardson <[e-mail]>]

Not sure why I'm explicitely in the CC, reply-all I guess.

Brendan Moran <[e-mail]> wrote:
    > There is another possibility that I don’t think we’ve discussed. It has
    > some pros and a really big con. For the sake of completeness, here it
    > is: We keep the COSE_Encrypt exactly as it is and allow standard
    > manifest overrides via dependencies. This is good because it means that
    > only authorised parties can edit the recipients list. This is bad
    > because it means that the unused recipients structures cannot be
    > severed.

It's a tussle.

    > However in our situation, an on-path attacker upstream of the Device
    > Operator gains fine-grained control of which of the Device Operator’s
    > devices are upgraded. This is scalable and difficult to detect. A
    > Device Operator would need to communicate with the Firmware Author to
    > determine why certain devices were not upgraded before the attack was
    > discovered, giving attackers a window of opportunity. Depending on
    > implementation details, competency, level of automation, and any other
    > coincident attacks launched by the threat actor, this window could be
    > longer or shorter.

    > I don’t believe that this is inline with our goals, however this
    > specific threat is not listed in the threat model within
    > draft-ietf-suit-information-model—evidence that threat models are
    > living documents, I suppose! Perhaps this threat should be discussed in
    > draft-ietf-suit-firmware-encryption?

I think that such an on-path attacker can also drop the entire update, right?
Or such an on-path attacker could selectively suppress the manifest getting
to specific devices anyway.  The summary is that this is not something new
that is enabled by fine-grained control of the encryption.

    > I think the solution, though less than ideal, is to place some metadata
    > in the manifest about the COSE_Encrypt within the manifest. In short,
    > if COSE_Encrypt is external to the manifest, it must be authenticated
    > by the manifest. If it is altered by an authorised party, that must be
    > explicit and authenticated as well.

I think that this barks up the wrong tree.
Let's go back to the architecture (now RFC9019: woohoo!)
Isn't the Status Tracker supposed to keep track of what version each device
is running, and let it know that there is something new?

AFAIK, standardization of the status tracker was not a goal in this round of
SUIT.  I'm unclear if we this was an ordering/chartering decision, or if it
was because we really didn't think we could accomplish this without boiling
oceans.  RFC9019 mentions that LwM2M already has this functionality, and so
maybe we will never ever have a single standard, but maybe it's time to
identify what other places we can place the Status Tracker functionality.

We have also been discussing SBOM pointers via MUD and/or Remote Attestation.

At this time, I think that the manifest has became a bit of a hammer, and
we'e actually run out of nail-shaped things.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide