Re: [Suit] draft-ietf-suit-architecture-01

[David Brown <[e-mail]>]

On Thu, Jul 12, 2018 at 02:19:58PM +0000, Brendan Moran wrote:

>I think there’s insufficiently precise language somewhere in the architecture
>document. This is absolutely not the intent of the architecture.
>Locally-initiated rollback is a necessary feature for guaranteeing the
>reliability of a device.
>
>The specific threat we’re trying to defend against is:
>
> 1. Device X has firmware A.
> 2. Firmware Authority releases firmware B
> 3. Device X is updated to firmware B
> 4. Malicious actor finds vulnerability in firmware A that is no longer present
>    in firmware B.
> 5. Malicious actor reissues firmware A to device X
> 6. Device X reverts to firmware A
> 7. Malicious actor exploits device using firmware A.
>
>This means that it is dangerous to have any remote triggers for rollbacks
>without strong guarantees of authenticity.

I agree here.  The problem I've encountered is when it comes to people
implementing actual devices in the field, they ignore this security
requirement, favoring the ability to easily trigger a revert.

>I think this is actually an optimisation problem. Is the client smart enough to
>look for a local copy of a resource before fetching it remotely? Does this need
>to be addressed in the manifest directly? I haven’t seen a compelling argument
>for that yet.

Unfortunately, I think we're giving too much ability to the "client".
At least originally, our charter was intended to include very
resource-constrained devices.  I'm going to write up a few more emails
about some specifics, but I think we need to at least make it possible
for the client to not be very smart.  I think it would be better for
the instructions to be more explicit, and maybe explicitly state
something like "move firmware in slot 1 into slot 0".  More likely,
something like:

  1. Verify slot one contains hash XXX.
  2. Swap slot 1 and 0.

But, let me write this up in a separate email.

>Notwithstanding the above, the way to refer to a “built-in” image is to refer
>to it by uri: [1]file:///, for example. I don’t think there’s a uri namespace
>for numerically addressed storage (raw flash). I should note that URIs are
>optional. That is intended for use when a device knows where to look for
>updates without being told, and behaviour is implementation-defined. An
>appropriate approach to a manifest that has no URI is to walk through available
>sources of resources by cost, checking if they have the specified payload (by
>hash). The lowest cost is the local storage, which would solve this problem, I
>think.
>
>Does that address the problem?

Remember, some of this decision has to be made on every boot, based on
one or more manifests.  Having to hash multiple firmware slots would
not be ideal.

David