Subject: [Suit] Thoughts on requirements and scope

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Nov 2017 17:45:27 +1100

Given that we are having a BOF, it's most appropriate to concentrate
on requirements and scope.

I've reviewed draft-moran-* and draft-nandakumar-* and I think that
there is considerable overlap in stated requirements.

The two key points of contention seem to be:

1. whether the firmware retrieval mechanism is in scope or not (I'm
including discovery here)

  I don't see any easy path to agreeing on an MTI for delivery
mechanism - these things are just to disparate - and that would be the
primary outcome of taking on that part of the work.  That said, it
would be a huge win if an agreement could be reached.

   Here, draft-moran-suit-manifest confuses things by insisting on the
presence of a field that identifies the location of the firmware
image.  If delivery/retrieval mechanisms are intentionally out of
scope, then a named-data approach would avoid any need to reference
them (i.e., identify using a hash or the via the signature of an
authorization).

2. manifest format, whether it be specific or not

  Frankly, I don't find the claims in draft-nandakumar-* to be
convincing.  Flexibility in terms of format needs some pretty strong
justification.  If this is done well, the cost of implementing the
manifest format will be dwarfed by the cost of the crypto code.

Other than those two issues, I don't see much divergence.

There is the minor point about encryption of images that Suhas makes.
I don't think that we *need* to fight about this one.  If a vendor
wants to encrypt their images, then they can create a package format
that encrypts the update without touching the manifest in any way.
That would move the encryption keys (and cryptography) to the update
itself.  In other words, it could be proprietary.  There is some loss
of value to the ecosystem in not having a generic, vetted design, so
I'd say that the question instead boils down to whether the group
wants to take on the work. Based on the solutions in front of us, it
looks like encryption could easily be done as an extension.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 6 Nov 2017 09:31:49 +0000

Hi Martin,

Thanks for the reviewing the drafts and for your questions.

1. whether the firmware retrieval mechanism is in scope or not (I'm including discovery here)

  I don't see any easy path to agreeing on an MTI for delivery mechanism - these things are just to disparate - and that would be the primary outcome of taking on that part of the work.  That said, it would be a huge win if an agreement could be reached.

[Hannes] I will be impossible to agree on the distribution / retrieval mechanism since many companies already have ways to do so and different deployments require different firmware distribution mechanisms. TFTP, for example, is not used to send firmware updates to Bluetooth Low Energy devices nor is HTTP.

   Here, draft-moran-suit-manifest confuses things by insisting on the presence of a field that identifies the location of the firmware image.  If delivery/retrieval mechanisms are intentionally out of scope, then a named-data approach would avoid any need to reference them (i.e., identify using a hash or the via the signature of an authorization).

[Hannes] There are two possible ways to provision firmware, namely either by attaching the firmware image to the manifest or by separating it from the manifest. For the former the field just points to the "body" where the firmware image is found. In the latter case the firmware image needs to be obtained from somewhere. As said above, that can happen using a number of ways. A common mechanism today is to download it from an HTTPS server. Since the URL is included in the manifest there is no need for discovery. Fetching a file from a server isn't rocket science either and does not require standardization. (A multicast distribution mechanism, as also discussed on the list, might, however require standardization.)

The named data approach sounds nice but leads to the question of how the device then finds the firmware image.

Note that we are not arguing the firmware distribution mechanism shouldn't be standardized at all. However, that's not what we would be starting with since
* there is already ongoing work in standardization in context of the larger device management framework (e.g., from OMA DM, OIC)
* there is nothing to standardize (e.g., HTTP transporting a blob),
* or the work falls outside the scope of the IETF (e.g., defining an new service and characteristic in Bluetooth Low Energy),
* or would potentially require a fair amount of standardization (e.g., the multicast mechanism discussed on the list). Maybe such work should better be done in the transport area, IMHO.

There is the minor point about encryption of images that Suhas makes.
I don't think that we *need* to fight about this one.  If a vendor wants to encrypt their images, then they can create a package format that encrypts the update without touching the manifest in any way.
That would move the encryption keys (and cryptography) to the update itself.  In other words, it could be proprietary.  There is some loss of value to the ecosystem in not having a generic, vetted design, so I'd say that the question instead boils down to whether the group wants to take on the work. Based on the solutions in front of us, it looks like encryption could easily be done as an extension.

[Hannes] I am somewhat surprised to hear that there are people in the industry that do not believe that encrypting firmware isn't a requirement frequently raised. Note that this is not a requirement we at ARM came up with. It is a requirement coming from the industry partners. course, we can make everything proprietary as we do today. If some people don't want to use encrypted firmware images then they do not need to use that part of the spec.

Ciao
Hannes

_______________________________________________
Suit mailing list
[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: Martin Thomson <[email-masked]>
Date: Mon, 6 Nov 2017 21:38:45 +1100

Hi Hannes,

I think perhaps I'm not communicating clearly enough.  Just a few responses.

> The named data approach sounds nice but leads to the question of how the device then finds the firmware image.

I see, so you would still insist on pointing to the image somehow, but
you don't want to define the mechanism (or play kingmaker for existing
mechanisms).  But that's where the seams start to show.  You need to
pick a framework into which this fits, because the assumptions about
delivery mechanisms matter if you are relying on the locator to
actually find you the firmware.

If, as you suggest, this is done as part of a larger framework that
addresses delivery, why could you not assume that the update and
manifest are already present?  That the larger framework can be
responsible for matching manifest to update?  For example, if you
choose HTTP, link relation between one and t'other would be simple
enough and neatly put finding firmware out of scope for the manifest.
Then you avoid having the manifest deal with the messy details of
locators (which is the area in the draft that is messiest, at least in
my view).

(Something in one of the previous discussions suggested to me that
there might be multiple manifests.  That is, claims about validity
could be made independently.  What do you think of that?)

> [Hannes] I am somewhat surprised to hear that there are people in the industry that do not believe that encrypting firmware isn't a requirement frequently raised. Note that this is not a requiremen…

You will note that I did not contest the requirement, I'm just
questioning whether it is necessary to do up front, or even as
critical part of the manifest.  I observed that it is not strictly
necessary to define where proprietary solutions exist, but also
suggested that an extension might be reasonable.  An extension would
allow us to a) concentrate on finishing a core, and b) allow for more
detail.  I can't make a whole lot of sense of the design the draft
proposes, probably because it is missing critical descriptions of how
keys are expected to be managed.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 6 Nov 2017 11:05:11 +0000

Hi Martin,

Here is my perspective on the topic of distribution.

I see the manifest as a building block. There are various organizations working on their story for IoT security and the firmware update functionality is just one piece of it. As they define ways to interact with the devices, they can then use the defined building block and indicate how they want to carry the manifest and the firmware image to the respective device.

I have no expectations that the delivery mechanism for a VoIP phone, BLE heartrate sensor, and a LoRa-based precision farming device will be the same.

Does this make more sense?

Ciao
Hannes

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]]
Sent: 06 November 2017 11:39
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Suit] Thoughts on requirements and scope

Hi Hannes,

> The named data approach sounds nice but leads to the question of how the device then finds the firmware image.

I see, so you would still insist on pointing to the image somehow, but you don't want to define the mechanism (or play kingmaker for existing mechanisms).  But that's where the seams start to show.  You need to pick a framework into which this fits, because the assumptions about delivery mechanisms matter if you are relying on the locator to actually find you the firmware.

If, as you suggest, this is done as part of a larger framework that addresses delivery, why could you not assume that the update and manifest are already present?  That the larger framework can be responsible for matching manifest to update?  For example, if you choose HTTP, link relation between one and t'other would be simple enough and neatly put finding firmware out of scope for the manifest.
Then you avoid having the manifest deal with the messy details of locators (which is the area in the draft that is messiest, at least in my view).

(Something in one of the previous discussions suggested to me that there might be multiple manifests.  That is, claims about validity could be made independently.  What do you think of that?)

> [Hannes] I am somewhat surprised to hear that there are people in the industry that do not believe that encrypting firmware isn't a requirement frequently raised. Note that this is not a requiremen…

You will note that I did not contest the requirement, I'm just questioning whether it is necessary to do up front, or even as critical part of the manifest.  I observed that it is not strictly necessary to define where proprietary solutions exist, but also suggested that an extension might be reasonable.  An extension would allow us to a) concentrate on finishing a core, and b) allow for more detail.  I can't make a whole lot of sense of the design the draft proposes, probably because it is missing critical descriptions of how keys are expected to be managed.
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: Michael Richardson <[email-masked]>
Date: Mon, 06 Nov 2017 10:33:24 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > [Hannes] I am somewhat surprised to hear that there are people in the
    > industry that do not believe that encrypting firmware isn't a
    > requirement frequently raised. Note that this is not a requirement we
    > at ARM came up with. It is a requirement coming from the industry
    > partners. course, we can make everything proprietary as we do today. If
    > some people don't want to use encrypted firmware images then they do
    > not need to use that part of the spec.

I believe that we are all in agreement that integrity checks for the firmware
image is mandatory.  There are different ways that we can accomplish this,
but if we go the way of using an already specified container format that
supports signatures, it's usually the case that one can have encryption as
well.

Container formats would include: CMS, JOSE, COSE.

Signatures are sort of easy as the creator of the firmware signs it, and the
devices validate it with a (public) key.

The challenge with encryption is that one has to figure out how the
decryption key is distributed.  Of course, it could be baked in symmetric
key, but many would suggest that is as good as no key at all.

I think that this difficulty is where the conflict comes from.

So my suggestion is that we should be focused on containers that support
encryption, even if we choose not to provide a standard way to distribute the
decryption key(s).

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Nov 2017 10:50:18 -0500

> locators (which is the area in the draft that is messiest, at least in

I want to make sure that I understand you correctly.
You are saying, if the device found the manifest at:
    https://example.com/foo/bar/device/manufest.ext

and the manifest says the load firmware, "XQN456.bin"
that one would find it at:
    https://example.com/foo/bar/device/XQN456.bin

and if it came from:
    tftp://192.168.1.1/foo/bar/device/manufest.ext
that the firmware is at:
    tftp://192.168.1.1/foo/bar/device/XQN456.bin

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Nov 2017 11:26:09 +0000

Hi Michael,

> So my suggestion is that we should be focused on containers that support encryption, even if we choose not to provide a standard way to distribute the decryption key(s).

I completely agree with you. We should focus on the requirements rather than what is easy to do.

Funny enough, it turns out that we have already a standardized way to distribute keys.

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 06 November 2017 16:33
To: [email-masked]
Subject: Re: [Suit] Thoughts on requirements and scope

    > not need to use that part of the spec.

I believe that we are all in agreement that integrity checks for the firmware image is mandatory.  There are different ways that we can accomplish this, but if we go the way of using an already specified container format that supports signatures, it's usually the case that one can have encryption as well.

Signatures are sort of easy as the creator of the firmware signs it, and the devices validate it with a (public) key.

The challenge with encryption is that one has to figure out how the decryption key is distributed.  Of course, it could be baked in symmetric key, but many would suggest that is as good as no key at all.

So my suggestion is that we should be focused on containers that support encryption, even if we choose not to provide a standard way to distribute the decryption key(s).

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Nov 2017 13:25:02 -0500

Hannes Tschofenig <[email-masked]> wrote:
    >> So my suggestion is that we should be focused on containers that
    >> support encryption, even if we choose not to provide a standard way to
    >> distribute the decryption key(s).

    > I completely agree with you. We should focus on the requirements rather

good...

    > Funny enough, it turns out that we have already a standardized way to

We already have *A* method?   :-) :-)

I know of many standardized non-interactive ways in which to distribute keys
to groups, (from SMIME asymmetric methods to kerberos method). Then there are
online ways like MIKEY, and we can also use ACE mechanisms too now!

I think that all of them require that the identities of the devices that will
receive the keys be known to some entity/controller. If not in advance, then
perhaps online.

I think there are a very diverse set of situations and resulting
requirements, which is why I'm surprised to learn that we have a solution
that solves them all.

(and... even the DVDCSS method has some merit in some scenarios)

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Nov 2017 18:32:30 +0000

I guess I should have said that we already have plenty of ways .... ;-)

I know of many standardized non-interactive ways in which to distribute keys to groups, (from SMIME asymmetric methods to kerberos method). Then there are online ways like MIKEY, and we can also use ACE mechanisms too now!

I think that all of them require that the identities of the devices that will receive the keys be known to some entity/controller. If not in advance, then perhaps online.

I think there are a very diverse set of situations and resulting requirements, which is why I'm surprised to learn that we have a solution that solves them all.