Subject: [Suit] WG Review: Software Updates for Internet of Things (suit)

From: The IESG <[email-masked]>
Date: Fri, 03 Nov 2017 09:32:03 -0700

The Software Updates for Internet of Things (suit) WG in the Security Area of
the IETF is undergoing rechartering. The IESG has not made any determination
yet. The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG mailing
list ([email-masked]) by 2017-11-13.

Software Updates for Internet of Things (suit)
-----------------------------------------------------------------------
Current status: BOF WG

Chairs:
  Dave Thaler <[email-masked]>
  David Waltermire <[email-masked]>
  Russ Housley <[email-masked]>

Assigned Area Director:
  Kathleen Moriarty <[email-masked]>

Security Area Directors:
  Kathleen Moriarty <[email-masked]>
  Eric Rescorla <[email-masked]>

Mailing list:
  Address: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/suit
  Archive: https://mailarchive.ietf.org/arch/search/?email_list=suit

Group page: https://datatracker.ietf.org/group/suit/

Charter: https://datatracker.ietf.org/doc/charter-ietf-suit/

Vulnerabilities in Internet of Things (IoT) devices have raised the
need for a secure firmware update mechanism that is also suitable for
constrained devices.  Security experts, researchers, and regulators
recommend that all IoT devices be equipped with such a mechanism.  While
there are many proprietary firmware update mechanisms in use today, there
is a lack of a modern interoperable approach of securely updating the
software in IoT devices.

A firmware update solution consists of several components, including:
  *  A mechanism to transport firmware images to IoT devices.
  *  A manifest that provides meta-data about the firmware image
     (such as a firmware package identifier, the hardware the package
     needs to run, and dependencies on other firmware packages), as
     well as cryptographic information for protecting the firmware
     image in an end-to-end fashion.
  *  The firmware image itself.

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 the work done with RFC 4108 to be revisited.
This group will focus on defining a firmware update solution for Class
1 devices, as defined in RFC 7228, that is -- IoT devices with ~10 KiB
RAM and ~100 KiB flash.  The solution may apply to more capable devices
as well.  This group will not define any transport mechanisms.

In June of 2016 the Internet Architecture Board organized a workshop on
'Internet of Things (IoT) Software Update (IOTSU)', which took place at
Trinity College in Dublin, Ireland.  The main goal of the workshop was
to foster a discussion on requirements, challenges, and solutions for
bringing software and firmware updates to IoT devices. This workshop
also made clear that there are challenges with misaligned incentives
and complex value chains.  It is nevertheless seen as important to
create standard building blocks that help interested parties implement
and deploy a solid firmware update mechanism.

In particular this group aims to publish three 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.

The initial focus of this group will be development of a manifest approach
based on CMS and the ASN.1 encoding. This work will result in a revision of
RFC 4108 that reflects the current best practices. Use of the ASN.1 encoding
is desirable due to existing ASN.1 support in crypto libraries used within
current IoT operating systems. The group may later adopt alternate manifest
formats using other serialization approaches (e.g., CBOR). This group does
not aim to create a standard for a generic software update mechanism for use
by rich operating systems, like Linux, but instead this group will focus on
software development practices in the embedded industry.  "Software update
solutions that target updating software other than the firmware binary (e.g.
updating scripts) are also out of scope.

This group will aim to maintain a close relationship with silicon vendors
and OEMs that develop IoT operating systems.

Milestones:

  Dec 2017 - Adopt RFC 4108bis document as WG item.

  Dec 2017 - Adopt "Architecture" document as WG item.

  Dec 2017 - Adopt "Manifest Format" specification as WG item.

  Jan 2018 - Adopt "Architecture" to the IESG for publication as an
  Informational RFC.

  Mar 2018 - Calendar item: Release initial version of the manifest creation
  tools as open source.

  Apr 2018 - Calendar item: Release first version of manifest test tools as
  open source.

  Jun 2018 - Calendar item: Release first IoT OS implementation of firmware
  update mechanisms as open source.

  Nov 2018 - Submit RFC 4108bis document to the IESG for publication as a
  Proposed Standard.

  Nov 2018 - Submit "Manifest Format" to the IESG for publication as a
  Proposed Standard.

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 3 Nov 2017 16:43:12 +0000

Going forward I'd like to focus our discussion of the charter around specific textual changes that need to be made to this charter. Please focus your comments around proposing new text to address any concerns you might have.

I will keep a working copy of the charter based on the conversation going forward, which we will review at the IETF 100 SUIT BoF on Monday, November 13, 2017 in Singapore.

Regards,
Dave

> -----Original Message-----
> From: Suit [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Friday, November 03, 2017 12:32 PM
> To: IETF-Announce <[email-masked]>
> Cc: [email-masked]
> Subject: [Suit] WG Review: Software Updates for Internet of Things (suit)
> 
> informational purposes only. Please send your comments to the IESG mailing list
> ([email-masked]) by 2017-11-13.
> 
>   To subscribe:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iet
> f.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdavid.waltermire%40
> nist.gov%7Cd192afbbaa384fa3a58d08d522d86ca6%7C2ab5d82fd8fa4797a93
> e054655c61dec%7C1%7C0%7C636453235286858513&sdata=QztGtSdbI9GjF
> Ui%2BtcbEirxM026iG%2BT0Yztmex4Ghbo%3D&reserved=0
>   Archive:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchi
> ve.ietf.org%2Farch%2Fsearch%2F%3Femail_list%3Dsuit&data=02%7C01%7Cd
> avid.waltermire%40nist.gov%7Cd192afbbaa384fa3a58d08d522d86ca6%7C2a
> b5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636453235286858513&s
> data=xbYnoky%2FpcGtkA9EJJwjeMBJO5k6gB5PyE5A0PGDQ%2Bw%3D&reserv
> ed=0
> 
> Group page:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fgroup%2Fsuit%2F&data=02%7C01%7Cdavid.waltermire%40nis
> t.gov%7Cd192afbbaa384fa3a58d08d522d86ca6%7C2ab5d82fd8fa4797a93e0
> 54655c61dec%7C1%7C0%7C636453235286858513&sdata=1wVU3kU%2FtTw
> 7YpjxNyGV1Dj5P20FcxzE%2FbaLYrJ8%2F%2BQ%3D&reserved=0
> 
> Charter:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fcharter-ietf-
> suit%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cd192afbbaa384
> fa3a58d08d522d86ca6%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0
> %7C636453235286858513&sdata=W7XS6qSxpFjmjTgv9SUtJh%2FhGV67IaQr
> 11e6dMTd9lM%3D&reserved=0
> 
> Vulnerabilities in Internet of Things (IoT) devices have raised the need for a
> secure firmware update mechanism that is also suitable for constrained devices.
> Security experts, researchers, and regulators recommend that all IoT devices be
> equipped with such a mechanism.  While there are many proprietary firmware
> update mechanisms in use today, there is a lack of a modern interoperable
> approach of securely updating the software in IoT devices.
> 
> More than ten years have passed since the publication of RFC 4108, and greater
> experience with IoT deployments has led to additional functionality, requiring
> the work done with RFC 4108 to be revisited.
> 1 devices, as defined in RFC 7228, that is -- IoT devices with ~10 KiB RAM and
> ~100 KiB flash.  The solution may apply to more capable devices as well.  This
> group will not define any transport mechanisms.
> 
> 'Internet of Things (IoT) Software Update (IOTSU)', which took place at Trinity
> College in Dublin, Ireland.  The main goal of the workshop was to foster a
> discussion on requirements, challenges, and solutions for bringing software and
> firmware updates to IoT devices. This workshop also made clear that there are
> challenges with misaligned incentives and complex value chains.  It is
> nevertheless seen as important to create standard building blocks that help
> interested parties implement and deploy a solid firmware update mechanism.
> 
> The initial focus of this group will be development of a manifest approach based
> on CMS and the ASN.1 encoding. This work will result in a revision of RFC 4108
> that reflects the current best practices. Use of the ASN.1 encoding is desirable
> due to existing ASN.1 support in crypto libraries used within current IoT
> operating systems. The group may later adopt alternate manifest formats using
> other serialization approaches (e.g., CBOR). This group does not aim to create a
> standard for a generic software update mechanism for use by rich operating
> systems, like Linux, but instead this group will focus on software development
> practices in the embedded industry.  "Software update solutions that target
> updating software other than the firmware binary (e.g.
> This group will aim to maintain a close relationship with silicon vendors and
> OEMs that develop IoT operating systems.
> 
> Milestones:
> 
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iet
> f.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdavid.waltermire%40
> nist.gov%7Cd192afbbaa384fa3a58d08d522d86ca6%7C2ab5d82fd8fa4797a93
> e054655c61dec%7C1%7C0%7C636453235286858513&sdata=QztGtSdbI9GjF
> Ui%2BtcbEirxM026iG%2BT0Yztmex4Ghbo%3D&reserved=0

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Nov 2017 18:48:21 +0100

I’m slightly confused by this charter proposal.
The recent mailing list discussion went into a different direction.
Is this the current proposed text?

Grüße, Carsten

> On Nov 3, 2017, at 17:32, The IESG <[email-masked]> wrote:
> 
> https://www.ietf.org/mailman/listinfo/suit
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Nov 2017 18:49:50 +0100

Grüße, Carsten

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 03 Nov 2017 11:04:03 -0700

On 3 Nov 2017, at 10:49, Carsten Bormann wrote:

>> RFC 4108 that reflects the current best practices.

> Is this the current proposed text?

I agree with Carsten: that's not what the recent list traffic was aiming 
for. The draft charter from a month ago didn't force the WG into ASN.1, 
and I don't see any list traffic asking for that.

Also: is RFC 4108 really a "current best practice"? There seems to be 
nearly no implementations of that in the IoT space, or at least none 
that have spoken up about it.

>> Use of the ASN.1 encoding
>> current IoT operating systems.

The same could be said for CBOR/COSE. It is probably inaccurate to cite 
"ASN.1 support" given that different parts of a system might each 
implement its own ASN.1 stack.

>> The group may later adopt alternate manifest
>> formats using other serialization approaches (e.g., CBOR).

Why not let the WG decide which it wants?

--Paul Hoffman

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 3 Nov 2017 18:43:57 +0000

Paul and Carsten,

My comments are inline below.

> >> The initial focus of this group will be development of a manifest
> >> approach based on CMS and the ASN.1 encoding. This work will result
> >> in a revision of RFC 4108 that reflects the current best practices.
> 
> I agree with Carsten: that's not what the recent list traffic was aiming for. The
> draft charter from a month ago didn't force the WG into ASN.1, and I don't see
> any list traffic asking for that.

The guidance we received from the IESG is that they want the question around one or more formats resolved during the chartering process. We have had a number of views expressed on the list. We need to focus in on what the consensus within the group is. We need to identify what our initial work items will be regarding format(s).

To that end, this text can be updated. Do you have alternate text to propose?

> Also: is RFC 4108 really a "current best practice"? There seems to be nearly no
> implementations of that in the IoT space, or at least none that have spoken up
> about it.
> 
> >> is desirable due to existing ASN.1 support in crypto libraries used
> >> within current IoT operating systems.
> 
> "ASN.1 support" given that different parts of a system might each implement its
> own ASN.1 stack.

How would you change this text to improve it?

> >> The group may later adopt alternate manifest formats using other
> >> serialization approaches (e.g., CBOR).
> 

This statement is intended to do that. We need to figure out what we are working on initially and reflect that in the charter and milestones. Are you suggesting that the text should be made more clear? If so, then how?

> --Paul Hoffman

Thanks,
Dave

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 06 Nov 2017 07:48:34 -0800

On 3 Nov 2017, at 11:43, Waltermire, David A. (Fed) wrote:

> The guidance we received from the IESG is that they want the question 
> around one or more formats resolved during the chartering process.

That's not the way that I read the charter balloting comments on this 
list.  The mailing list clearly has no consensus yet, and nothing in the 
proposed manifest contents so far would make using ASN.1 or CBOR a more 
obvious choice.

> We have had a number of views expressed on the list. We need to focus 
> in on what the consensus within the group is. We need to identify what 
> our initial work items will be regarding format(s).
>

The initial focus of this group will be development of the contents of a 
manifest.
Once there is general agreement on the contents, the group will pick one 
format
(and its associated cryptographic mechanisms) to encode the manifest.

> How would you change this text to improve it?

Two likely candidates for encoding are ASN.1 and CBOR, both of which 
already have
support in current IoT crypto libraries.

--Paul Hoffman

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 6 Nov 2017 17:14:24 +0100

Dear Paul, all,

> Le 6 nov. 2017 à 16:48, Paul Hoffman <[email-masked]> a écrit :
> 
>> The guidance we received from the IESG is that they want the question around one or more formats resolved during the chartering process.
> 
> That's not the way that I read the charter balloting comments on this list.  The mailing list clearly has no consensus yet, and nothing in the proposed manifest contents so far would make using ASN.1 or CBOR a more obvious choice.

I agree with this one. Lots of things changed from the proposed charter discussed on the mailing list and the approved proposed one. (which is of course something to work out around the BoF) (It seems to me that there is a pretty wide interest in the topic, so at least that one seems a spot-on.)

We’ve already had a very interesting mail from Philip Hallam-Baker that had strong arguments AGAINST ASN.1, and I have not seen a response to it on the ML. If anyone has a view on this I would be very interested in having more information.

Best,
Alexander

> 
>> We have had a number of views expressed on the list. We need to focus in on what the consensus within the group is. We need to identify what our initial work items will be regarding format(s).
>> 
> The initial focus of this group will be development of the contents of a manifest.
> Once there is general agreement on the contents, the group will pick one format
> Two likely candidates for encoding are ASN.1 and CBOR, both of which already have

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Nov 2017 16:17:41 +0000

➢ We’ve already had a very interesting mail from Philip Hallam-Baker that had strong arguments AGAINST ASN.1, and I have not seen a response to it on the ML. If anyone has a view on this I would be very interested in having more information.
    
I agree with Philip that we should not be creating new data structures in ASN.1; there are simpler, performant, formats readily available.

(I’m a member of the development team of OpenSSL, and while we’ll never get away from ASN.1/DER for crypto work, there’s enough schadenfreude in the world that we don’t need to add to it.)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Nov 2017 11:23:20 -0500

>> > I’m slightly confused by this charter proposal.  > The recent
    >> mailing list discussion went into a different direction.  > Is this
    >> the current proposed text?
    >> 
    >> I agree with Carsten: that's not what the recent list traffic was
    >> aiming for. The draft charter from a month ago didn't force the WG
    >> into ASN.1, and I don't see any list traffic asking for that.

    > around one or more formats resolved during the chartering process. We
    > have had a number of views expressed on the list. We need to focus in
    > on what the consensus within the group is. We need to identify what our
    > initial work items will be regarding format(s).

I can understand why the IESG would like the question resolved in the charter
so that we can make progress rather than have a format war.

I do not believe that we have consensus for an RFC4108/ASN.1 based format,
and I think that writing that into the charter at this time will render
the WG dysfunctional. (People will go elsewhere).

I'm not convinced that we have consensus that we must have a single firmware
container format (a few people say it must be a single format).  
I also do not think that we have consensus that multiple formats is bad,
there is still a tuscle here.

I think that the problem may be solved by splitting the manifest semantics
contents from the implementation format.  We have done this in ANIMA
with draft-ietf-anima-voucher: we abstracted to YANG, and then present
examples based upon a CMS/PKCS based solution as an example. We did this
based upon feedback from some developers that they needed this, yet we want
to move forward to JOSE and COSE/CWT solutions. 

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Nov 2017 08:24:11 -0800

On Mon, Nov 6, 2017 at 8:14 AM, Alexander Pelov <[email-masked]> wrote:

> aiming for. The
> I agree with this one. Lots of things changed from the proposed charter
> discussed on the mailing list and the approved proposed one. (which is of
> course something to work out around the BoF) (It seems to me that there is
> a pretty wide interest in the topic, so at least that one seems a spot-on.)
>
> We’ve already had a very interesting mail from Philip Hallam-Baker that
> had strong arguments AGAINST ASN.1, and I have not seen a response to it on
> the ML. If anyone has a view on this I would be very interested in having
> more information.
>

I don't feel strongly about this, but RFC 4108 already is in ASN.1, so
presumably the argument is "we're revising that"

-Ekr

> in on what the consensus within the group is. We need to identify what our

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 6 Nov 2017 16:47:07 +0000

Paul said:

> Two likely candidates for encoding are ASN.1 and CBOR, both of which already have support in current IoT crypto libraries.

While an ASN.1 parser is pretty much in every crypto library the use of CBOR (particularly with COSE) is still at a very early stage.

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: "Paul Hoffman" <[email-masked]>
Date: Mon, 06 Nov 2017 09:12:20 -0800

> presumably the argument is "we're revising that"

I have not seen much desire for actually revising RFC 4108 on the 
mailing list. There is definitely interest in looking at the manifest in 
RFC 4108 and using the appropriate parts. RFC 4108 was an individual 
submission for a specific use case that preceded the idea of 
almost-unmanaged lightweight IoT devices, and thus might not be 
appropriate for revision in the eventual WG.

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Nov 2017 15:40:52 -0500

> (and its associated cryptographic mechanisms) to encode the manifest.

This seems good for me.

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 6 Nov 2017 23:50:35 +0100

Hello,

my intend is not to annoy anyone, really, but I think I have to ask this one question: If the initial focus is not about format (+1) - in respect to rfc3444 - does this imply that the initial focus will be about a data model, including data types and the interconnected relationship of its contents?

Viele Grüße,

Henk

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Nov 2017 19:02:26 -0500

Henk Birkholz <[email-masked]> wrote:
    >    my intend is not to annoy anyone, really, but I think I have to ask
    > this one question: If the initial focus is not about format (+1) - in
    > respect to rfc3444 - does this imply that the initial focus will be
    > about a data model, including data types and the interconnected
    > relationship of its contents?  
    > initial focus is to create a data model, including data types?^

If you mean, are we writing YANG (or some other meta-language), then then
answer could yes, but I interpret things to mean that it doesn't have to
be.  It could be just english.

Having said this, I have read draft-moran-suit-manifest-00 finally, and I
think that I could live with this specification.

---

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

Henk,

we could of course separate the encoding from the semantic of the information we want to convey. If we do (using RFC 3444 terminology) that then we would be working on the information model in one document and in one or more documents on the data models.

This would just delay the discussion about encodings not necessarily resolve it. That may help since people have more time to think about it. On the other hand, we didn’t want to turn this into a lifelong project.

Ciao
Hannes

From: Suit [mailto:[email-masked]] On Behalf Of Henk Birkholz
Sent: 06 November 2017 23:51
To: [email-masked]; Michael Richardson; The IESG
Subject: Re: [Suit] WG Review: Software Updates for Internet of Things (suit)

Viele Grüße,

Henk

that the initial focus is to create a data model, including data types?^
On November 6, 2017 9:40:52 PM GMT+01:00, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

</bloc

--

Sent from my Android device with K-9 Mail. Please excuse my brevity.kquote>
This seems good for me.

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 7 Nov 2017 14:02:22 +0100

Hi Hannes,

that was why I suggested a data model and not an information model in 
this scope. A data model can be serialized in several encodings - the 
only requirement is that the encoding can represent the types required 
by the data model - at least on a level that enables 
unambiguous/canonical transcoding and therefore interoperability.

In a small scope like suit ("small" being relative in respect to other 
charters), I think one could start laying out a data model without 
requiring the extra steps of "finding the information elements".

I also have to voice to support the approach to "learn" from CMS and 
RFC 4108 - and not just refactoring the concepts/contents.

Also I would like to voice support for Phillip's and Rich's approach 
"that we should not be creating new data structures in ASN.1" as "there 
are simpler, performant, formats readily available."

Just yesterday I met with a vendor that does firmware upgrades in 
isolated computing context slices of singular things - and they were 
amazed that "providing the capability of indicating block-device 
lables/indexes", "block-offsets in a block-device" and semantic 
relationships, such as "requires", "supersedes", or "patches" is not an 
obvious thing to be included in a manifest. The literal question they 
voiced was: "Why going through the hassle of creating a manifest for 
metadata, if you are not going to put useful metadata in it?" And I 
could understand their point of view.

Additionally - on one hand - I would like to support the term claim in 
respect to the mix of terms highlighted by Martin:

> It's not just terminology.  There are three discrete fields in the
> draft for conditions, directives and extensions.  I am suggesting that
> there only needs to be one.

On the other hand, I am not so certain about this statement, Martin:

> storageIdentifier seems especially problematic.  If you have a device
> type identifier, then that should suffice for those cases where there
> are multiple update targets on a device.  That is, you can identify by
> generically identifying the type of thing that this update applies to:
> "vendor foo alarm clock configuration" rather than "vendor foo alarm
> clock" and it all works neatly.  Right now the storageIdentifier is
> all tied up in the way that the update is identified.

Optional standard claims that MAY be used to provide additional 
semantics to a manifest do not sound so bad to me. Am I missing 
something here?

Viele Grüße,

Henk

On 11/07/2017 12:33 PM, Hannes Tschofenig wrote:
> Henk,
> 
> we could of course separate the encoding from the semantic of the 
> information we want to convey. If we do (using RFC 3444 terminology) 
> that then we would be working on the information model in one document 
> and in one or more documents on the data models.
> 
> This would just delay the discussion about encodings not necessarily 
> resolve it. That may help since people have more time to think about it. 
> On the other hand, we didn’t want to turn this into a lifelong project.
> 
> Ciao
> Hannes
> 
> *From:*Suit [mailto:[email-masked]] *On Behalf Of *Henk Birkholz
> *Sent:* 06 November 2017 23:51
> *To:* [email-masked]; Michael Richardson; The IESG
> *Subject:* Re: [Suit] WG Review: Software Updates for Internet of Things 
> (suit)
> 
> 
> my intend is not to annoy anyone, really, but I think I have to ask this 
> one question: If the initial focus is not about format (+1) - in respect 
> to rfc3444 - does this imply that the initial focus will be about a data 
> model, including data types and the interconnected relationship of its 
> contents?
> 
> Viele Grüße,
> 
> Henk
> 
> On November 6, 2017 9:40:52 PM GMT+01:00, Michael Richardson 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> Paul Hoffman <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Nov 2017 13:12:24 +0000

Hi Henk,

Hi Hannes,

that was why I suggested a data model and not an information model in this scope. A data model can be serialized in several encodings - the only requirement is that the encoding can represent the types required by the data model - at least on a level that enables unambiguous/canonical transcoding and therefore interoperability.

[Hannes] Maybe our understanding of what RFC 3444 tries to say may differ (which would probably also explain the confusion in the area of semantic interoperability for IoT).

In a small scope like suit ("small" being relative in respect to other charters), I think one could start laying out a data model without requiring the extra steps of "finding the information elements".

[Hannes] That sounds reasonable to me.

I also have to voice to support the approach to "learn" from CMS and RFC 4108 - and not just refactoring the concepts/contents.

Also I would like to voice support for Phillip's and Rich's approach "that we should not be creating new data structures in ASN.1" as "there are simpler, performant, formats readily available."

[Hannes] I agree with those statements.

Just yesterday I met with a vendor that does firmware upgrades in isolated computing context slices of singular things - and they were amazed that "providing the capability of indicating block-device lables/indexes", "block-offsets in a block-device" and semantic relationships, such as "requires", "supersedes", or "patches" is not an obvious thing to be included in a manifest. The literal question they voiced was: "Why going through the hassle of creating a manifest for metadata, if you are not going to put useful metadata in it?" And I could understand their point of view.

[Hannes] I am not sure I understand their comment.

> all tied up in the way that the update is identified.

Optional standard claims that MAY be used to provide additional semantics to a manifest do not sound so bad to me. Am I missing something here?

[Hannes] Martin would like to combine elements while we had proposed to separate them. To me it feels like defining an attribute 'name' vs. having two attributes, 'first name' and 'last name'. I personally don't have a strong opinion about this topic.

Ciao
Hannes

Viele Grüße,

Henk

On 11/07/2017 12:33 PM, Hannes Tschofenig wrote:
> Sent from my Android device with K-9 Mail. Please excuse my
> brevity.kquote> This seems good for me.
>
> 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: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Nov 2017 13:26:49 +0000

Hi Paul,

Just a few notes.

> I agree with Carsten: that's not what the recent list traffic was aiming for. The draft charter from a month ago didn't force the WG into ASN.1, and I don't see any list traffic asking for that.

There is a chicken-and-egg problem here: if there is no working group it is difficult to bring the community working on embedded operating systems, which are the guys who are ultimately having the implementation burden, to the IETF. We have reached out to various companies and encouraged their participation but, as you for sure know, this is difficult to do since many of them have no experience with the IETF.

> Also: is RFC 4108 really a "current best practice"? There seems to be nearly no implementations of that in the IoT space, or at least none that have spoken up about it.

It is hard to judge how well connected you are in the embedded industry and how many embedded OS vendors you have spoken with. Just yesterday I had an email exchange with a company that has implemented RFC 4108 and asked us about the difference between our work and that RFC. I encouraged them to join the list and participate in the discussion.

FWIW, we are both biased with regards to the encoding format: you are the co-author of CBOR and we have implemented an ASN.1 based solution.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Nov 2017 07:15:43 +0000

Hi Paul,

In a private mail I was made aware that my email response to you below could be interpreted as a personal attack. Sorry. That was obviously not my intention.

Let me therefore re-phase the response, which may give the group some insight: You have spoken to (embedded) companies about their update mechanism and you said that they didn't use RFC 4108. Who did you talk to and, probably of more interest, what did they use?

Ciao
Hannes

-----Original Message-----
From: Hannes Tschofenig
Sent: 07 November 2017 14:27
To: 'Paul Hoffman'; The IESG
Cc: [email-masked]
Subject: RE: [Suit] WG Review: Software Updates for Internet of Things (suit)

Hi Paul,

Just a few notes.

Ciao
Hannes

---

From: Brendan Moran <[email-masked]>
Date: Wed, 8 Nov 2017 10:19:20 +0000

On 7 Nov 2017, at 13:02, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Here are some thoughts on the differences between the manifest proposal and RFC 4108:

The initial submission of the [FUD] manifest format shares many properties RFC4108, such as serial numbers (Device IDs), community identifiers (Device Class IDs), and the Cryptographic Message Syntax. The current [Suit] manifest format still shares most of these properties, but uses COSE instead of CMS.

  *   RFC4108 specifies that signing should occur after encryption. This causes some problems:
     *   The entire package must be downloaded, then verified, then decrypted in-place, then installed, requiring double the flash cycles as decrypting in-RAM, then verifying after decryption.
     *   The installed binary cannot have its signature verified.
     *   It is preferable to include multiple hashes of the firmware package in different states, such as:
        *   Ciphertext
        *   Plaintext
        *   Installed
        *   (Others, dependent on firmware format)
  *   RFC4108 defines a wrapped firmware object, whereas the [Suit] draft intentionally separates the metadata from the firmware. This has several benefits:
     *   Signature verification can be done early, to ensure that the signer(s) has the correct rights (in aggregate, for multiple signers) to perform installation
     *   Manifests are small and can be distributed over a pre-established link, even if it is expensive. The manifest can contain discovery hints for firmware acquisition, (e.g. a ranked list of URIs to search) which allows distribution over low-cost links.
        *   An example here is distribution in mesh networks. The manifest is small enough to be sent to every node, via LwM2M, for example, and the manifest can contain a URI/directive that instructs the device to listen for a broadcast firmware, which the whole of the mesh will receive. Only devices that have been primed with a manifest will store the firmware. The rest will just participate in mesh broadcast.
     *   Storage is simpler. The same firmware can be distributed in multiple batches to different sets of devices without uploading multiple copies of the firmware. Because it is merely linked by the manifest, rather than contained within a signed object, many manifests can refer to the same firmware.
  *   Key distribution is not well-specified in RFC4108. The only specified option uses the EnvelopedData mechanism from RFC5652, and comes with drawbacks where broadcast (physical, or logical, i.e. untrusted CDNs) distribution is used.
     *   The [Suit] draft no longer specifies key table distribution. Some of this can be handled within COSE, however there is some specification work to be done on how encrypted payloads can be made broadcast-friendly. I expect either tables of encrypted COSE Keys, or tables of key-wrapped bare keys to play a role.
  *   Firmware component naming is conflated with versioning. This is problematic for rollback protection, since the version number may require text processing.

   Preferred firmware package names are a combination of the firmware
   package object identifier and a version number.

  *   A fat boot loader is mandated by the standard, which makes unbrickable updates of network stacks problematic:

   The bootstrap loader MUST have access to a physical interface and any
   related driver or protocol software necessary to obtain a firmware
   package.

Best Regards,
Brendan Moran