Subject: [Suit] Suit - Charter Considerations and Thoughts

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 23 Oct 2017 17:28:22 -0700

Thanks for bringing this work into IETF.  A bunch of us at Cisco,  agree
that a good way to do IoT firmware update needs to do this work and are
very much interested in contributing as well. We are planning to submit few
drafts in that effect before the deadline. Much of this comes from the
experience of shipping phones like the 7960 which had very limited memory
and firmware and keeping them upgraded across 100+ countries and every
continent including Antartica. Making things that can upgrade over a
satellite link, or inside a secure facility, and at web scale are all
problems that we deal with everyday. Having a standardized approach to this
would really help.

However, we would love to have discussions on few aspects of the charter
and it would be great if the BOF can help have the discussions.

Topics that we would like to discuss include roughly :

    Proposal for the IOT device to discover the Firmware server.

    Manifest to support newer formats  like JSON, CBOR and their secure
variants (JOSE/COSE).

    Firmware download protocol semantics and transport protocol options.

    Proposal for being agnostic of firmware image type and dependencies.

To summarize, we are very excited about the possibility of an IETF WG on
secure firmware download, but we think this charter needs substantial
changes before it is ready. We look forward to being able to discuss this
and refine this at the BOF.

Thanks

Suhas Nandakumar

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Oct 2017 12:00:25 +0000

Hi Suhas,

Sorry that I missed this mail; it somehow ended up in my spam folder.

Great that you expressed interest in this work. While a phone does not necessarily qualify as an IoT device IMHO but it is a good experience given all the several issues you had encountered.

Regarding the charter comments I believe you misunderstand this effort a bit. The proposed work is actually not about the download of the firmware but instead focuses about the meta-data and security wrapper around the firmware/software.

The format discussion is included in the charter; this is always a favourite discussion topic in the IETF (besides finding names for groups and protocols).

Regarding the firmware server discovery and transport I hope you know that there has been substantial standardization already in other SDOs, for example at the OMA with LwM2M where many of the industry players (such as Nokia, Huawei, Ericsson, Qualcomm, and ARM) have contributed to. If you are unfamiliar with LwM2M you may find this recorded webinar useful: https://os.mbed.com/blog/entry/LWM2M-Meet-the-Experts-webinar/. If you care about standardizing a discovery mechanism and the transport feel free to request your own working group.

I am not sure what you mean by “Proposal for being agnostic of firmware image type and dependencies.”. The solution proposal we submitted is agnostic to the firmware image type. How are can be agnostic to dependencies is not clear to me though.

Ciao
Hannes

From: Suit [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: 24 October 2017 02:28
To: [email-masked]
Subject: [Suit] Suit - Charter Considerations and Thoughts

Thanks for bringing this work into IETF.  A bunch of us at Cisco,  agree that a good way to do IoT firmware update needs to do this work and are very much interested in contributing as well. We are planning to submit few drafts in that effect before the deadline. Much of this comes from the experience of shipping phones like the 7960 which had very limited memory and firmware and keeping them upgraded across 100+ countries and every continent including Antartica. Making things that can upgrade over a satellite link, or inside a secure facility, and at web scale are all problems that we deal with everyday. Having a standardized approach to this would really help.

However, we would love to have discussions on few aspects of the charter and it would be great if the BOF can help have the discussions.

    Manifest to support newer formats  like JSON, CBOR and their secure variants (JOSE/COSE).

To summarize, we are very excited about the possibility of an IETF WG on secure firmware download, but we think this charter needs substantial changes before it is ready. We look forward to being able to discuss this and refine this at the BOF.

Thanks

Suhas Nandakumar

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: Cullen Jennings <[email-masked]>
Date: Tue, 24 Oct 2017 06:35:13 -0600

> On Oct 24, 2017, at 6:00 AM, Hannes Tschofenig <[email-masked]> wrote:
> 

The whole point of having a BOF is to try and figure out what the scope of the work should be.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Oct 2017 12:45:14 +0000

> The whole point of having a BOF is to try and figure out what the scope of the work should be.

I am sure you have been aware that there have been efforts to form a WG without having a BOF, an option ADs have at their disposal.

Ciao
Hannes

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Oct 2017 09:04:10 -0400

Sent from my iPhone

> I am sure you have been aware that there have been efforts to form a WG without having a BOF, an option ADs have at their disposal.

If there's no open discussion on the charter and it's been sufficiently addressed, a charter can be approved.  If it needs to be discussed, a BoF is helpful for high bandwidth conversations.

The charter is in internal review right now, then goes to external review.  It doesn't complete external review until the discussions have completed (in some way).

More should weigh in on this thread to help with scope and determine if this proposal would fit or require a second WG.

Best regards,
Kathleen 
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Oct 2017 10:15:37 +1100

> The whole point of having a BOF is to try and figure out what the scope of the work should be.

If there are people interested in the problem of firmware acquisition
as opposed to the narrower scope of the proposed effort which
concentrates on how to determine if a blob of bits should be applied
once acquired, that might be worth a second working group.  On the
other hand, if what Suhas suggests is correct and the description of
the blob necessarily depends on the means by which it is acquired,
then we should discuss that.  Hannes seems to believe that this isn't
a necessary dependency, and I would have to say that I can't see any
evidence to support the claim that the two are co-dependent.

We could also decide that the scope of the proposed work should be
expanded to include other things without having that discussion.
Personally, I like the fact that this is a narrowly focused effort.  I
can see plenty of opportunity for disagreement, but also a fairly
rapid (and successful) conclusion.

---

From: Brendan Moran <[email-masked]>
Date: Mon, 30 Oct 2017 13:57:09 +0000

The manifest format, as drafted, shouldn’t have any explicit dependency on any transport. One of the original goals of defining the payload references as URIs was to ensure that a URN could be used. This would allow a device to iterate through a list of known transports with different cost metrics, searching for an available source of the named payload.

This iteration process allows the update to be fully decoupled from the transport, but to still name a location. A URN could specify the name of the payload by hash, for example, then the client would check known sources of payloads for that hash.

Best Regards,
Brendan

> On 25 Oct 2017, at 00:15, Martin Thomson <[email-masked]> wrote:
>