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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 2 Jul 2018 19:07:53 +0000

Hi all,

I have just submitted version -01 of the architecture document. I have incorporate feedback from the working group, such as

*         New terminology,

*         Updates on the operating modes

*         New architecture figures,

*         New use cases (by David Brown)

Here is the new version:
https://tools.ietf.org/html/draft-ietf-suit-architecture-01

Here is the diff:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-suit-architecture-01.txt

Feedback is appreciated.

Ciao
Hannes
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: Denis <[email-masked]>
Date: Tue, 3 Jul 2018 11:58:47 +0200

Hannes,

It is well known that software updates are often done to address a 
security issue. The same applies
to firmware updates. The current draft is lacking to address protections 
against the downloading of
an old firmware version. The threat should be mentioned in the security 
considerations section.

The main body of the document should mention mechanisms to prevent the 
replay of an old version
of the firmware.

Denis

> Hi all,
>
> I have just submitted version -01 of the architecture document. I have 
> incorporate feedback from the working group, such as
>
> ·New terminology,
>
> ·Updates on the operating modes
>
> ·New architecture figures,
>
> ·New use cases (by David Brown)
>
> Here is the new version:
>
> 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.
>
>
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Brendan Moran <[email-masked]>
Date: Tue, 3 Jul 2018 10:05:53 +0000

Hi Denis,

Is the rollback question adequately covered in the information model?

Thanks,
Brendan

On 3 Jul 2018, at 10:58, Denis <[email-masked]<mailto:[email-masked]>> wrote:

Hannes,

It is well known that software updates are often done to address a security issue. The same applies
to firmware updates. The current draft is lacking to address protections against the downloading of
an old firmware version. The threat should be mentioned in the security considerations section.

The main body of the document should mention mechanisms to prevent the replay of an old version
of the firmware.

Denis

Hi all,

I have just submitted version -01 of the architecture document. I have incorporate feedback from the working group, such as
•         New terminology,
•         Updates on the operating modes
•         New architecture figures,
•         New use cases (by David Brown)

Here is the new version:

Here is the diff:

Feedback is appreciated.

Ciao
Hannes

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 3 Jul 2018 14:59:24 +0000

Hi Denis,

I think the risk of installing an old firmware version is covered in the information model document, which goes into the details of what a manifest has to contain. See Section 3.2.1 of https://tools.ietf.org/html/draft-ietf-suit-information-model-01

There are essentially three types of documents the working group is aiming to produce: an architecture document, the information model for the manifest and one or multiple serialization formats. You have been looking at the architecture but the appropriate document to read is the information model spec.

Ciao
Hannes

From: Suit [mailto:[email-masked]] On Behalf Of Denis
Sent: 03 July 2018 11:59
To: [email-masked]
Subject: Re: [Suit] draft-ietf-suit-architecture-01

Hannes,

Denis

Hi all,

*         New terminology,

Here is the new version:

Here is the diff:

Feedback is appreciated.

Ciao
Hannes

Suit mailing list

---

From: David Brown <[email-masked]>
Date: Tue, 03 Jul 2018 09:59:10 -0600

I had an interesting conversation with someone building a device (a battery powered device, where network traffic is expensive). When they update the firmware, they keep the previous version around, and have an ability to roll back to that version in case there are issues.

I presented the argument that the correct answer is to re-release the older firmware, with a new higher monotonic value. Their counterargument was that this was costly in terms of power, because it requires the image to be resent.

I think the best answer here is to have them issue a new manifest that describes this old image (the one kept around), that has a new monotonic value. That way, only the manifest has to be sent (something has to be sent to tell the device to revert the image anyway). I think this model is covered in our current docs, since we don’t really define how a “built-in” image is referred to.

But, this does make me realize that there are times that things can be spelled out clearly, usually for security reasons, that end up getting disabled due to what someone thinks is a practical reason. I agree that preventing rollback is important for security, but I’ve found myself arguing against these practical cases multiple times.

I wonder if it would be worth writing up a use case to capture this particular revert case, and how that can be addressed with the model we currently have.

David

From: Suit <[email-masked]> on behalf of Hannes Tschofenig <[email-masked]>
Date: Tuesday, July 3, 2018 at 8:59 AM
To: Denis <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Suit] draft-ietf-suit-architecture-01

Hi Denis, 

Ciao

Hannes

Hannes,

Denis

Hi all, 

I have just submitted version -01 of the architecture document. I have incorporate feedback from the working group, such as 
New terminology, 
Updates on the operating modes 
New architecture figures, 
New use cases (by David Brown)

Here is the new version: 

Here is the diff: 

Feedback is appreciated. 

Ciao

Hannes

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. _______________________________________________ Suit mailing list [email-masked] https://www.ietf.org/mailman/listinfo/suit

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 3 Jul 2018 16:14:15 +0000

Hi David,

Thanks for sharing this use case. I agree it would be worthwhile to document it and a user story in the information model document would probably the best place to do so.

Ciao
Hannes

From: David Brown [mailto:[email-masked]]
Sent: 03 July 2018 17:59
To: Hannes Tschofenig; Denis; [email-masked]
Subject: Re: [Suit] draft-ietf-suit-architecture-01

David

Hi Denis,

Ciao
Hannes

Hannes,

Denis

Hi all,

  *   New terminology,

Here is the new version:

Here is the diff:

Feedback is appreciated.

Ciao
Hannes

Suit mailing list

---

From: Denis <[email-masked]>
Date: Wed, 4 Jul 2018 10:18:36 +0200

Hannes,

In the security considerations section, it would be worthwhile to 
indicate that the threats are addressed in details
in section 3.2 (Threat Descriptions) from [I-D.ietf-suit-information-model].

Denis

> Hi Denis,
>
> I think the risk of installing an old firmware version is covered in 
> the information model document, which goes into the details of what a 
> manifest has to contain. See Section 3.2.1 of 
> https://tools.ietf.org/html/draft-ietf-suit-information-model-01
>
> There are essentially three types of documents the working group is 
> aiming to produce: an architecture document, the information model for 
> the manifest and one or multiple serialization formats. You have been 
> looking at the architecture but the appropriate document to read is 
> the information model spec.
>
> Ciao
>
> Hannes
>
> *From:*Suit [mailto:[email-masked]] *On Behalf Of *Denis
> *Sent:* 03 July 2018 11:59
> *To:* [email-masked]
> *Subject:* Re: [Suit] draft-ietf-suit-architecture-01
>
> Hannes,
>
>     I have just submitted version -01 of the architecture document. I
>     have incorporate feedback from the working group, such as
>
>     ·New terminology,
>
>     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.
>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Brendan Moran <[email-masked]>
Date: Thu, 12 Jul 2018 14:19:58 +0000

Hi David,

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.

So, how do we prevent this scenario while providing a lightweight way to trigger an authentic rollback?

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.

Notwithstanding the above, the way to refer to a “built-in” image is to refer to it by uri: 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?

Thanks,
Brendan

On 3 Jul 2018, at 16:59, David Brown <[email-masked]<mailto:[email-masked]>> wrote:

David

From: Suit <[email-masked]<mailto:[email-masked]>> on behalf of Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 3, 2018 at 8:59 AM
To: Denis <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] draft-ietf-suit-architecture-01

Hi Denis,

Ciao
Hannes

From: Suit [mailto:[email-masked]] On Behalf Of Denis
Sent: 03 July 2018 11:59
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] draft-ietf-suit-architecture-01

Hannes,

Denis

Hi all,

  *   New terminology,

Here is the new version:

Here is the diff:

Feedback is appreciated.

Ciao
Hannes

Suit mailing list

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. _______________________________________________ Suit mailing list [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/suit
_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

---

From: David Brown <[email-masked]>
Date: Fri, 13 Jul 2018 09:46:50 -0600

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.
>
>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.
>

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Jul 2018 11:37:48 +0000

Good idea. I will do that.

From: Denis [mailto:[email-masked]]
Sent: 04 July 2018 04:19
To: Hannes Tschofenig; [email-masked]
Subject: Re: [Suit] draft-ietf-suit-architecture-01

Hannes,

In the security considerations section, it would be worthwhile to indicate that the threats are addressed in details
in section 3.2 (Threat Descriptions) from [I-D.ietf-suit-information-model].

Denis
Hi Denis,

Ciao
Hannes

Hannes,

Denis

Hi all,

*       New terminology,

Here is the new version:

Here is the diff:

Feedback is appreciated.

Ciao
Hannes

Suit mailing list

---

From: Michael Richardson <[email-masked]>
Date: Sat, 21 Jul 2018 12:10:40 -0400

Brendan Moran <[email-masked]> wrote:
    > Notwithstanding the above, the way to refer to a “built-in” image is
    > to refer to it by uri: file:///, for example. I don’t think there’s a
    > uri namespace for numerically addressed storage (raw flash). I should

There is also the ni: URL type, see: rfc6920.
That let's one name things with hashes, and that might make more sense
than using file://

But, the manifest already has a hash of the firmware in it, so I think that
the manifest should continue to say where to get it, if a device does not
already have it.  I think it's reasonable for a device with storage for
more than one copy of the firmware to keep track of the hashes of what
it has stored.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-