Subject: [Suit] Suit Charter: Working Group Objectives - Another Try

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 22 Nov 2017 15:39:45 -0800

Hello All

The current charter has following text on the deliverables for this working
group. Having explicitly listing out of the objectives might be really
helpful here.

Also the current text misses elements on firmware server discovery that
gathered support during the BOF discussions as seen in the current charter
text

"""

In particular this group aims to publish several documents, namely:

- An IoT firmware update architecture that includes a description of the
involved entities, security threats, and assumptions.

- One or more manifest format specifications.”

 """

Below (in italicized) is an an attempt to help clarify the WG objectives.
Please let me know your thoughts.

This WG will work on developing an interoperable secure firmware upgrade
solution for IoT devices that are constrained in their resources (such as
RAM, Flash). The solution must enable firmware upgrades for the IoT devices
under various deployment options (such as, deployments under constrained
network access typically controlled by an Enterprise IT department or
factory OT group as well as with open Internet access deployments).

An extensible manifest format to describe metadata about the firmware and
its security properties will be developed by this WG. The working group
will also develop and architect solution that enable the IoT devices to
locate the firmware update server (and manifest) via existing transport
protocol mechanisms.

In particular, this WG will perform the following work:

   -

   Document that defines the requirements for secure firmware upgrade
   solution.
   -

   Define a general architecture that enables secure IoT firmware upgrade
   describing involved elements, security threats, update server discovery and
   assumptions.
   -

   Document that describes the data model  that captures metadata and
   security properties about the firmware in the form of a manifest.
   -

   Define one or more encoding formats for the manifest.
   -

   Document describing use of existing transport and protocol mechanisms to
   locate and download the firmware.
   -

   A best current practices document that defines firmware installation
   process on the IoT device.

I believe something on the similar lines clearly identifies the working
objectives and deliverables for this effort.

Cheers
Suhas Nandakumar

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Nov 2017 07:30:56 +0000

Hi Suhas,

The previous charter text did not separate requirements from the architecture. That was done intentionally since requirements on their own have turned out to be pretty meaningless. For this reason the IESG has been pushing back on pure requirements documents.

Regarding the data model depending on how you read RFC 3444, which defines the difference between a data model and an information model, a data model may already provide the encoding format. Hence, I prefer to avoid the term data model altogether and just say “Document that captures metadata and security properties about the firmware in the form of a manifest.”

Ciao
Hannes

From: Suit [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: 23 November 2017 00:40
To: [email-masked]
Subject: [Suit] Suit Charter: Working Group Objectives - Another Try

Hello All

The current charter has following text on the deliverables for this working group. Having explicitly listing out of the objectives might be really helpful here.

Also the current text misses elements on firmware server discovery that gathered support during the BOF discussions as seen in the current charter text

"""

- An IoT firmware update architecture that includes a description of the involved entities, security threats, and assumptions.

 """

Below (in italicized) is an an attempt to help clarify the WG objectives. Please let me know your thoughts.

This WG will work on developing an interoperable secure firmware upgrade solution for IoT devices that are constrained in their resources (such as RAM, Flash). The solution must enable firmware upgrades for the IoT devices under various deployment options (such as, deployments under constrained network access typically controlled by an Enterprise IT department or factory OT group as well as with open Internet access deployments).

An extensible manifest format to describe metadata about the firmware and its security properties will be developed by this WG. The working group will also develop and architect solution that enable the IoT devices to locate the firmware update server (and manifest) via existing transport protocol mechanisms.

·       Document that defines the requirements for secure firmware upgrade solution.

·       Define a general architecture that enables secure IoT firmware upgrade describing involved elements, security threats, update server discovery and assumptions.

·       Document that describes the data model  that captures metadata and security properties about the firmware in the form of a manifest.

·       Define one or more encoding formats for the manifest.

·       Document describing use of existing transport and protocol mechanisms to locate and download the firmware.

·       A best current practices document that defines firmware installation process on the IoT device.

I believe something on the similar lines clearly identifies the working objectives and deliverables for this effort.

Cheers
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: Michael Richardson <[email-masked]>
Date: Thu, 23 Nov 2017 12:44:46 -0500

Suhas Nandakumar <[email-masked]> wrote:
    > Below (in italicized) is an an attempt to help clarify the WG

Not everyone will see your italics.
Please stick to text/plan if you want to be universally understood.

    > objectives. Please let me know your thoughts.

I don't like putting the number of documents into the charter as it
restricts the WG from splitting or merging documents as it sees fit.

Documents will get listed in the milestones which are much more easily
mutable (they require only the AD to approve).

Instead, I'd rather discuss the topics that need to be covered.

    > This WG will work on developing an interoperable secure firmware
    > upgrade solution for IoT devices that are constrained in their
    > resources (such as RAM, Flash). The solution must enable firmware
    > upgrades for the IoT devices under various deployment options (such
    > as, deployments under constrained network access typically controlled
    > by an Enterprise IT department or factory OT group as well as with
    > open Internet access deployments).

I like that you have included Enterprise IT and OT in this list.
References to IOTSF meeting and RFC7228 terminology as was in the posted
document will help many people keep us in the right context.

The reference to 4108 as posted online is now much less prescriptive, and I
actually can live with the sentence that was there:
         RFC 4108 provides a manifest format that uses the Cryptographic
         Message Syntax (CMS) to protect firmware packages. More than ten years have
         passed since the publication of RFC 4108, and greater experience with IoT
         deployments has led to additional functionality, requiring a contemporary
         standardized solution to be defined.

as it no longer mandates us to do anything other than acknoledge that it
existed, and might have some good ideas.

    > An extensible manifest format to describe metadata about the firmware
    > and its security properties will be developed by this WG. The working
    > group will also develop and architect solution that enable the IoT
    > devices to locate the firmware update server (and manifest) via
    > existing transport protocol mechanisms.

    > *   Document that defines the requirements for secure firmware upgrade
    > solution.

"The requirements for secure firmware upgrade will be documented"

    > *   Define a general architecture that enables secure IoT firmware
    > upgrade describing involved elements, security threats, update
    > server discovery and assumptions.

    > *   Document that describes the data model that captures metadata and

"An extensible data model that captures metadata and security properties
about the firmware will be developed and codified in a manifest"

    > *   Define one or more encoding formats for the manifest.

    > *   Document describing use of existing transport and protocol
    > mechanisms to locate and download the firmware.

"One or more optional mechanisms will be described that use existing
transport and discovery protocols to locate and transfer the firmware"

    > *   A best current practices document that defines firmware
    > installation process on the IoT device.

I'm unclear what this means.  I suggest that it be left out, and instead we
write:

"Future work, presently out of scope, could include a best current practices
document that defines firmware installation process on the IoT device."

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