<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br><p class="airmail_on">On December 15, 2017 at 12:59:51 PM, The IESG (<a href="mailto:iesg-secretary@ietf.org">iesg-secretary@ietf.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>A new IETF WG has been formed in the Security Area. For additional

information, please contact the Area Directors or the WG Chairs.

<br>

<br>Software Updates for Internet of Things (suit)

<br>-----------------------------------------------------------------------

<br>Current status: Active WG

<br>

<br>Chairs:

<br>  Dave Thaler <<a href="mailto:dthaler@microsoft.com">dthaler@microsoft.com</a>>

<br>  David Waltermire <<a href="mailto:david.waltermire@nist.gov">david.waltermire@nist.gov</a>>

<br>  Russ Housley <<a href="mailto:housley@vigilsec.com">housley@vigilsec.com</a>>

<br>

<br>Assigned Area Director:

<br>  Kathleen Moriarty <<a href="mailto:Kathleen.Moriarty.ietf@gmail.com">Kathleen.Moriarty.ietf@gmail.com</a>>

<br>

<br>Security Area Directors:

<br>  Kathleen Moriarty <<a href="mailto:Kathleen.Moriarty.ietf@gmail.com">Kathleen.Moriarty.ietf@gmail.com</a>>

<br>  Eric Rescorla <<a href="mailto:ekr@rtfm.com">ekr@rtfm.com</a>>

<br>

<br>Mailing list:

<br>  Address: <a href="mailto:suit@ietf.org">suit@ietf.org</a>

<br>  To subscribe: <a href="https://www.ietf.org/mailman/listinfo/suit">https://www.ietf.org/mailman/listinfo/suit</a>

<br>  Archive: <a href="https://mailarchive.ietf.org/arch/search/?email_list=suit">https://mailarchive.ietf.org/arch/search/?email_list=suit</a>

<br>

<br>Group page: <a href="https://datatracker.ietf.org/group/suit/">https://datatracker.ietf.org/group/suit/</a>

<br>

<br>Charter: <a href="https://datatracker.ietf.org/doc/charter-ietf-suit/">https://datatracker.ietf.org/doc/charter-ietf-suit/</a>

<br>

<br>Vulnerabilities in Internet of Things (IoT) devices have raised the need

<br>for a secure firmware update mechanism that is also suitable for constrained

<br>devices.  Security experts, researchers, and regulators recommend that all IoT

<br>devices be equipped with such a mechanism.  While there are many proprietary

<br>firmware update mechanisms in use today, there is no modern interoperable

<br>approach allowing secure updates to firmware in IoT devices. In June of 2016

<br>the Internet Architecture Board organized a workshop on 'Internet

<br>of Things (IoT) Software Update (IOTSU)', and RFC 8240 documents various

requirements and challenges that are specific to IoT devices.

<br>

<br>A firmware update solution consists of several components, including:

* A mechanism to transport firmware images to compatible devices.

<br>* A manifest that provides meta-data about the firmware image (such as a

<br>firmware package identifier, the hardware the package needs to run, and

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

<br>

<br>This group will focus on defining a firmware update solution (taking into

<br>account past learnings from RFC 4108 and other firmware update solutions) that

<br>will be usable on Class 1 (as defined in RFC 7228) devices, i.e., devices with

<br>~10 KiB RAM and ~100 KiB flash.  The solution may apply to more capable

<br>devices as well.  This group will not define any new transport or discovery

<br>mechanisms, but may describe how to use existing mechanisms within the

architecture.

<br>

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

<br>* An IoT firmware update architecture that includes a description of the

involved entities, security threats, and assumptions.

* One or more manifest format specifications.

<br>

<br>To support specification of manifest format(s), this group will first develop

<br>the information model for the contents of a manifest. Once there is general

<br>agreement on the contents, the group will pick a small number of

<br>serialization formats such as CBOR and/or ASN.1 (and their associated

<br>cryptographic mechanisms) to encode the manifest. A small number of formats

<br>is preferred to reduce the complexity of a firmware management solution,

<br>where each IoT device would typically only support one format, but the same

<br>tool or service might support all such formats. To support a wide range of

<br>deployment scenarios, the formats are expected to be expressive enough to

allow the use of different firmware sources and permission models.

<br>

<br>This group does not aim to create a standard for a generic application

<br>software update mechanism, but instead this group will focus on firmware

<br>development practices in the embedded industry. Software update solutions

<br>that target updating software other than the firmware binaries (e.g.,

applications) are also out of scope.

<br>

<br>This group will aim to maintain a close relationship with silicon vendors and

OEMs that develop IoT operating systems.

<br>

<br>Milestones:

<br>

Jan 2018 - Adopt "Architecture" document as WG item.

<br>

Mar 2018 - Adopt a manifest information model as a WG item.

<br>

<br>  Mar 2018 - Calendar item: First interoperability event at IETF 101.

<br>

Mar 2018 - Adopt initial manifest serialization format(s) as WG item(s).

<br>

<br>  Jul 2018 - Calendar item: Second interoperability event at IETF 102.

<br>

<br>  Jul 2018 - Submit manifest information model to the IESG for publication as

<br>  Informational.

<br>

<br>  Nov 2018 - Submit an initial manifest serialization format to the IESG for

publication as a Proposed Standard.

<br>

<br>

<br></div></div></span></blockquote> <div id="bloop_sign_1513363568552111104" class="bloop_sign"></div></body></html>