From nobody Fri Aug 4 11:28:53 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA52613218F for ; Fri, 4 Aug 2017 11:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_oc65PyHMEu for ; Fri, 4 Aug 2017 11:28:49 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0136.outbound.protection.outlook.com [23.103.201.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5035513218E for ; Fri, 4 Aug 2017 11:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3yj6AJHJmCezRj49yjND0lpiSstS6VujeA5k6Vrtkk8=; b=LODwh6fe6k4Xy+SC9os8vkb7BHddScFLOUlGno9/t6w7IUM/2sowUTW2Ca6Jcx9VdRPyg3GHFgN1VQB0IZtYf+iyrmM/hHjQ1m/dVtbX9Jw7zFBTzaHqY8GpeUhuGkB4viOnnDLbsan8mw63ZXBcCzSNgcJysmAKUp40+kQaBDQ= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Fri, 4 Aug 2017 18:28:47 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.1304.025; Fri, 4 Aug 2017 18:28:47 +0000 From: "Waltermire, David A. (Fed)" To: "fud@ietf.org" Thread-Topic: FUD Datatracker Page Thread-Index: AdMNTz23ki8jv2TZTbSR1zZySaxomw== Date: Fri, 4 Aug 2017 18:28:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 6:GcJajs+mx5inv7S6KVb5suBJeGNqV3EYj+Rcg/inF6NKuvuqorfhhAhutv89IgK0cn9vYEgiz2MHocUkJsmmwOhZlZFjVBuJNLOx08kAaMEJN3NiAEc5je0Fv9YLPoiDurXBssGrnKWtUP6pR9qDjNqicy2hGdBC6XX1I9aHpg6+NbKqScq22FclbVSnw56by5bRA8feO3LWWj9JizSaM0zUY4AgnogpcPsNV+IouybTfcMh5Xjg6ySeOmQnEpoEO85TZiw4iJeFIx1N62YK5qR41bTyN559goTiRpmFbF6IFTAuYO9Ralx2gPCiz72yNdbe/wxedJKXZDVmOsDLzQ==; 5:hBfR6SuLm+uen2J3oGLU9XOcN+WbZdWk28CePQQ2dH24nydGhyGjHKaX+1VVm/jo1zefdB1ROgCzUc2/A7IiVxxwh49Ht8E9KANTS1XL9eoH41lxK0qpWXwNjGSEP34pupDvJ80t+vfGYA2ryylQ0Q==; 24:F1xhiiVWAwqoR/9XI3MgNTdVJMlKQ9kF058yU75dgC8dWHnNGBMGKZVCFX/z2tmN4cGej5y3V9DK95JF4PkjUwE4PtoN6XLpomTUJwWOSX0=; 7:ldhBjpfRLSVaayjvdwdBL4clEmuG2iYa0WyNUMlUsaqBeepzU/LzBnJ9IlegRBSby558KWEUz5ELFqd4LxYj0W4ws1/WFPZilNZNT4tgE4HXptXKtiExQ9qRfc05Un4wLqztEWAGezCVkH0ewrsAEbyRAsimllFG0j87p/UbNs9r9KQhCVWR1EdrAJCcW3T4tisvVWKxsZirlWtS8tmRU5LinwpEe9rcjDMiB+4M6Uk= x-ms-office365-filtering-correlation-id: 0fd0508a-464e-42fd-3c9f-08d4db66a582 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR09MB1437; x-ms-traffictypediagnostic: MWHPR09MB1437: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR09MB1437; x-forefront-prvs: 0389EDA07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39410400002)(39450400003)(39860400002)(39840400002)(199003)(189002)(2351001)(25786009)(110136004)(97736004)(66066001)(3280700002)(14454004)(1730700003)(74316002)(5660300001)(3660700001)(558084003)(106356001)(966005)(6916009)(7116003)(81166006)(81156014)(38730400002)(54356999)(6506006)(50986999)(8676002)(7696004)(77096006)(8936002)(478600001)(305945005)(2501003)(99286003)(6306002)(53936002)(9686003)(101416001)(55016002)(86362001)(7736002)(3480700004)(5640700003)(2906002)(102836003)(189998001)(68736007)(33656002)(105586002)(6436002)(6116002)(3846002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2017 18:28:47.4443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Subject: [Fud] FUD Datatracker Page X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 18:28:52 -0000 We now have a newly minted Datatracker page for FUD: https://datatracker.ietf.org/wg/fud/about/ Now we need to get the charter done. Have a good weekend! Regards, Dave From nobody Mon Aug 7 03:32:13 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9965132195 for ; Mon, 7 Aug 2017 03:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuVZzGGToes6 for ; Mon, 7 Aug 2017 03:32:09 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD5E1293E1 for ; Mon, 7 Aug 2017 03:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v77AW1Cf018322; Mon, 7 Aug 2017 12:32:01 +0200 (CEST) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:301:224:d6ff:fe13:2040]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xQv3N6S4WzDMQW; Mon, 7 Aug 2017 12:32:00 +0200 (CEST) From: Olaf Bergmann To: Emmanuel Baccelli Cc: fud@ietf.org, Hannes Tschofenig References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> Date: Mon, 07 Aug 2017 12:32:00 +0200 In-Reply-To: (Emmanuel Baccelli's message of "Sat, 22 Jul 2017 09:57:33 +0200") Message-ID: <87d187oehr.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 10:32:11 -0000 Emmanuel Baccelli writes: > thanks a lot for the strawman! Reads well in my opinion.=20 +1 > At high level, I have the following comments & suggestions: > > - we have the case of software updates, not only firmware updates, so > I'd rather we talk about the more general case of software updates. Is > there a strong reason against this? This is more a question of whether a module is regarded as part of the firmware (cf. "firmware package" in the text). Some application-specific JavaScript code may or may not fall under this category. (You could, e.g., discuss if Ethereum contracts are "software" in this sense. But I am not sure that this would be addressed in this WG?) Gr=C3=BC=C3=9Fe Olaf From nobody Tue Aug 8 03:30:01 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA6F132191 for ; Tue, 8 Aug 2017 03:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCmIlDE3x5of for ; Tue, 8 Aug 2017 03:29:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA46131D28 for ; Tue, 8 Aug 2017 03:29:55 -0700 (PDT) Received: from [192.168.91.202] ([80.92.121.224]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MBFgr-1dogwG00bl-00AIfY; Tue, 08 Aug 2017 12:29:53 +0200 To: Emmanuel Baccelli , fud@ietf.org References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <76330c36-4e99-3013-e6bf-61e9c627ba46@gmx.net> Date: Tue, 8 Aug 2017 12:29:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Td324ZIvJSkoBTwHv5gDAYbLNRvt3ObO03fxTUT6/e6E/kT6Gog UBfT9rf7r1o5nzbHPaDKtLzhSB0RJ9L3/DZo8/pmXP9GhXTVahIakOaH/Qx0DGNVHHsC0W1 Fe2F/fEVg93NlCnJ0NFdDQ4Qn3QqS6sgPRbBs+02qV/SlcIQUZmnJJQY56p2MzqU2Px2xS3 hgVNijghyClCzp0mAyLpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:k1nhABc0MJI=:DEOCEOWjLYkjBYSDmnKOLw YrX1DlmRwH8hp4uCc4MMcvZiLarKNlVqQYRDAkuD3wF+zLd0SKDZGC7YDbRW3TKV99uE96Ylr 4TiF3IK6N2jkiN2fKcFf1aucnMfDFOGSSpnI6Jyd2ycBWSYNQFV1PpptZsRLNwAJNlwvQh117 rixIH/t75WrCQ5Mi4QnnNxDXiLe4D6gF7dlzcaiKCUIlfw97FQdNQ4I3960z0J85ptUU9c3Jg atHuKwlv1R2rcF8FbVEmVq+TTasGQXymlvdOCikAF0ERDdN67JV/atYecybpLK5d9kH2F7drt 8AHghJ10W9+Jvxx7Ld3xqFZNr9KR8CJCbtmc0MirunhFCYxrTlJFCEwo+QD5fGTwVtH37zVei j/jmxT6CZtzjKxscOonMF2Vcmc8ulMSpyq3vEpQ9GWGJtZNhnolymDk/2lkCP3+wjpJB61JDe sFLqtRlZfEl62QcigE13lNpmO9Z5EncZS9OFhFyOH3BiAWxyrx+EIab2Dkmvc3lFud4flCpnL lb6GowqDsVeTpubu9CqCp1xdpVWbtNygawpZFhYyxWJV7yPLJHgtJebNIYk0sig0NuarU6m6J hifMGbKm8oTdJyHlwwK8kwvgl/vcd42d8D/4in9+Mq+3hhA5tekdFjKbRBWM4VGxwuikY46hu VV7M6NMGUiC/gbPlqcyi1JQOk5N/nzjEqmDpW/7rnI+B8sF5F4kKxfkjQbjBFwf7zDNxfkSha UmpmySGiKiGYDdu3CN/aV7oMgen3A01OZ1mzTCbz1xR2XWob56VGzmEZh9kyrRlol9/rnpzMV uOdjK/u/UA3Pz0ACJZ+nd42NPeevtztRnjzkTagpBTCwnL4oaU= Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 10:29:59 -0000 Hi Emmanuel sorry for the delay in responding to your review (due to vacation). On 07/22/2017 09:57 AM, Emmanuel Baccelli wrote: > Hi Hannes, > > thanks a lot for the strawman! Reads well in my opinion. > > At high level, I have the following comments & suggestions: > > - we have the case of software updates, not only firmware updates, so > I'd rather we talk about the more general case of software updates. Is > there a strong reason against this? There are several reasons why I wanted to focus on firmware updates: (a) In ARM we have worked on firmware updates for M-class devices and A-class devices. The constraints, developer experience, business models, the involved parties, security concerns, etc. between these two classes of devices are different. We don't see a lot of guys running special versions of Java, JavaScript/JerryScript, etc. on M-class devices even though we have been experimenting with these ideas as well (see https://developer.mbed.org/javascript-on-mbed/). My personal opinion is that those are nice fun projects but not useful for anything serious. (b) We wanted to have it focused in the hope that this work can be finished in a somewhat timely manner. (c) There are many software update mechanisms for regular OSs available already. I am not sure there is need for more work. (d) We have also proposed a software update mechanism for trusted applications running on a TEEs with the work in TEEP. The requirements are different there since we also need an attestation concept. (There may, however, be some synergies between this work and TEEP.) > > - many people think IoT= RaspberryPi, so I think we should be very very > clear that we are also targeting constrained devices as defined in RFC7228. > In particular, I'm convinced we can (and should) explicitly include > Class 1 devices as also being a target for such software updates. That's a good suggestion. What about adding a paragraph that says something like: " This group focuses on defining a firmware update solution for Class 1 devices, as defined in RFC 7228, i.e., IoT devices with ~10 KiB RAM and ~100 KiB flash. " This is clearly quite ambitious since you will typically need a bit more flash to store a second firmware image (to have a robust firmware update solution). I would probably feel a bit more comfortable talking about ~20 KiB RAM and ~200 KiB flash if we are talking about a system that uses public key cryptography. I just want to avoid that we rule out public key crypto and also have the freedom to explore ideas Russ suggested regarding hash-based signatures. Just working on a system that only offers symmetric key crypto is IMHO not enough. > > - FUD is quite an unfortunate acronym. Here's an alternative name > proposal for the working group: how about SUIT (Software Updates for > Internet of Things). Fine for me. I let the chairs decide about the best possible name for the working group. > > (there is a heavy similarity between the above comments and the ones I > put forward during the f2f meeting in Prague, as well as with the> comments I posted on the manifest+arch drafts you submitted this week ;) Thanks for summarizing your feedback made during the face-to-face meeting. Ciao Hannes > > Cheers, > > Emmanuel > > > > On Fri, Jul 21, 2017 at 11:52 PM, Hannes Tschofenig > > wrote: > > Here is a strawman proposal for a charter text. Suggestions welcome! > > ---- > > Firmware Updating Description (FUD) > > Vulnerabilities with 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 are equipped with such a mechanism. While > there are many proprietary firmware update mechanisms in use today there > is a lack of an modern interoperable approach of securely updating IoT > devices. > > A firmware update solution consists of several components, including a > mechanism to transport firmware images to IoT devices and a manifest > that provides meta-data about the firmware image as well as > cryptographic information for protecting the firmware image in an > end-to-end fashion. With RFC 4018 the IETF standardized a manifest > format that uses the Cryptographic Message Syntax (CMS) to protect > firmware packages. > > Since the publication of RFC 4108 more than 10 years have passed and > more experience with IoT deployments have lead to additional > functionality requiring the work done with RFC 4108 to be revisited. The > purpose of this group is to standardize a version 2 of RFC 4108 that > reflects best current practices. This group will not define any > transport mechanism. > > In 2016 the Internet Architecture Board organized a workshop on > 'Internet of Things (IoT) Software Update (IOTSU)', which took place at > Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. 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 lack of regulatory requirements, and misaligned incentives. It is > nevertheless seen as important to standardize the building blocks that > help interested parties to implement and deploy a solid firmware update > mechanism. > > In particular this group aims to publish two documents, namely > * an IoT firmware update architecture that includes a description of > the involved entities, security threats and assumptions, and > * the manifest format itself. > > This group does not aim to standardize a generic software update > mechanism used by rich operating systems, like Linux, but instead > focuses on software development practices in the embedded industry. > > This group will aim to develop a close relationship with silicon vendors > and OEMs that develop IoT operating systems. > > Milestones > > Dec 2017 Submit "Architecture" document as WG item. > > Dec 2017 Submit "Manifest Format" specification as WG item. > > Jul 2018 Submit "Architecture" to the IESG for publication as an > Informational RFC. > > Nov 2018 Submit "Manifest Format" to the IESG for publication as a > Proposed Standard. > > > Additional calendar items: > > Mar 2018 Release initial version of the manifest creation tools as > open source. > > Apr 2018 Release first version of manifest test tool suite as open > source. > > Jun 2018 Release first IoT OS implementation of firmware update > mechanisms as open source. > > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud > > > From nobody Tue Aug 8 03:39:31 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4250F132198 for ; Tue, 8 Aug 2017 03:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWCXRjLH1oZd for ; Tue, 8 Aug 2017 03:39:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F082132193 for ; Tue, 8 Aug 2017 03:39:28 -0700 (PDT) Received: from [192.168.91.202] ([80.92.121.224]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M6jMS-1dSq7F3uGi-00wR7M; Tue, 08 Aug 2017 12:39:18 +0200 To: Olaf Bergmann , Emmanuel Baccelli Cc: fud@ietf.org References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> <87d187oehr.fsf@aung.informatik.uni-bremen.de> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56ebab2e-86d2-bab4-be48-303fc0da0c81@gmx.net> Date: Tue, 8 Aug 2017 12:39:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <87d187oehr.fsf@aung.informatik.uni-bremen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:VzjL3aAgs/s3gIqH9CS3EDR+tmVNkn+qlrULiahEvs0a+XCESq3 f7fj/Sw5Ynqeg50fPSsOy37Vl1wzUTUcQEd3QMnEI3ApdJrEVWp5POKSVHIJIVbQfesbJpN GrjslNFjIcY6E73uSncQ8Fd5OfmQe0FPRENJVWc10fMwVYnrO1H6beeA/TVWyqTkObuk2yl QK0lWgBI+qZEEtWck3M3A== X-UI-Out-Filterresults: notjunk:1;V01:K0:0vW0zSbZKaw=:j0KP21IpMTWDHqb10VUvsK cTUA4tkZWUwrK/DUpPyenj2c9xFCM/OlkQubkW5RV8PDJUFPiekfi2+SzCEkrZkVgiD57Tw/p tUQytZDXuSKNPH9rJ/V1tQLfQz1MXgcFDezS2OIoTqQQjSm4DMiD42FM3c3Rq7o8eVQAFCqqV Wny/fLpUKztTVtkp8r2WE0fJzTYrjEJw9HXa7TKr2V2lKzKeHyZG/7mZ8l8hb4NhNlbVDYUoJ QFrpVvKb11PIEzf2Jr1jvc9cBsPJGXiqJX+UKbERQFU8r2+YyvCn4f9cY3P/43lx4TMzaw700 nsGY+rSBkjHldYJuirRSKHordke8ocf8uNRVmmuLJlbPKPjQ9M7hdpKF3ttp3po7iOSgopuy7 IhkI7QQPBE74o2RucIP71zYdUyO7WLaaRUrSNmECzSvYymuPVwZbGp/KCfPT85N9RB5cPCdX9 t+GO08nZ8jl+71OXb5LsD59V2HwgjUjn/dm+o6zTFJXNQoXRoZZ9JVLl8EPkoPdLWkapoJHrE AKVCGwYtVMw1nqMk71HDJPsibGYieSCpMpeQO316jNRWDaC+noVrJj/Hk4FHz3ziH13F+dvoN opDiSMJEoYjcpnxrtjxQODe9phHq4DrPjV9nTNkPLswO41usi2ksb8wUbYE3bVmYzkJVCewqM GH8arS+UjfpQ9H/xOsjRX1FflEPsMsaIZ9az61OLcSy6tyupmcOLFvBnbE7X09r8jvF7rvyKJ WQo4XGQHI6xmEWVoSIjCRTuZEWN6ov29slLZJpFZU6247A6Pg5IiKauh2A9eCTRt52YSu9APL S12IZYH4zyIie55avpPslxPUKadmPwyC2BDHuOYJPS+t2FrRBI= Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 10:39:30 -0000 Hi Olaf, >> - we have the case of software updates, not only firmware updates, so >> I'd rather we talk about the more general case of software updates. Is >> there a strong reason against this? > > This is more a question of whether a module is regarded as part of the > firmware (cf. "firmware package" in the text). Some application-specific > JavaScript code may or may not fall under this category. (You could, > e.g., discuss if Ethereum contracts are "software" in this sense. But I > am not sure that this would be addressed in this WG?) I believe Emmanuel needs to tell us a bit more about the use case he has in mind. The use cases I would like to cover are: - a developer creates a single firmware image, which may consist of source code from various parties and may also contain binaries from third parties. - a developer creates multiple firmware images (since the device has multiple microcontrollers that need to be updated). In this model the update service on a microcontroller gets code from a single source only (at least for the device it appears so since it does not know whether an included library was written by a different developer). What I specifically want to exclude is a model like JavaScript where you can get code from multiple different sources dynamically during code execution. Not only does this lead to challenges for code execution on these constrained devices but it also raises all sorts of security issues, which are difficult to solve on these low end devices. While there are isolation techniques available (like the MPU on Cortex M class devices and TrustZone for v8-M in upcoming devices) they have their limits. Ciao Hannes PS: I consider Smart Contracts also outside the scope of this group. Maybe an IRTF research group should work on them. > > Grüße > Olaf > From nobody Tue Aug 8 03:50:28 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BA8132324 for ; Tue, 8 Aug 2017 03:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l64fz6Y0DTHc for ; Tue, 8 Aug 2017 03:50:24 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA444132321 for ; Tue, 8 Aug 2017 03:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v78AoIpG006043; Tue, 8 Aug 2017 12:50:18 +0200 (CEST) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:301:224:d6ff:fe13:2040]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xRWQ221CWzDLHj; Tue, 8 Aug 2017 12:50:18 +0200 (CEST) From: Olaf Bergmann To: Hannes Tschofenig Cc: Emmanuel Baccelli , fud@ietf.org References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> <87d187oehr.fsf@aung.informatik.uni-bremen.de> <56ebab2e-86d2-bab4-be48-303fc0da0c81@gmx.net> Date: Tue, 08 Aug 2017 12:50:18 +0200 In-Reply-To: <56ebab2e-86d2-bab4-be48-303fc0da0c81@gmx.net> (Hannes Tschofenig's message of "Tue, 8 Aug 2017 12:39:16 +0200") Message-ID: <87poc6l4et.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 10:50:26 -0000 Hi Hannes, Hannes Tschofenig writes: > I believe Emmanuel needs to tell us a bit more about the use case he has > in mind. And of course others as well. Hannes did a good outline of what he thinks should be addressed. Those who have use cases that are not covered by this should speak up. > The use cases I would like to cover are: > > - a developer creates a single firmware image, which may consist of > source code from various parties and may also contain binaries from > third parties. > > - a developer creates multiple firmware images (since the device has > multiple microcontrollers that need to be updated). > > In this model the update service on a microcontroller gets code from a > single source only (at least for the device it appears so since it does > not know whether an included library was written by a different developer= ). Yes, I agree in principle. What we have seen (not only at the IOTSU workshop but also on existing devices such as VoIP phones) is that firmware updates typically do not come as a monolithic package but that in modules that can be updated separately (the most common---and desirable---split is between the OS and the basic bootloader). I think that at least this should be addressed here. > What I specifically want to exclude is a model like JavaScript where you > can get code from multiple different sources dynamically during code > execution. I agree as well. Gr=C3=BC=C3=9Fe Olaf From nobody Thu Aug 10 04:47:50 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDAD132695 for ; Thu, 10 Aug 2017 04:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.9 X-Spam-Level: X-Spam-Status: No, score=-4.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmppCvV7EzlQ for ; Thu, 10 Aug 2017 04:47:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68A213250B for ; Thu, 10 Aug 2017 04:47:46 -0700 (PDT) Received: from [192.168.91.202] ([80.92.121.224]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lpbqo-1dAZW328la-00fOA1; Thu, 10 Aug 2017 13:47:37 +0200 To: Olaf Bergmann Cc: Emmanuel Baccelli , fud@ietf.org References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> <87d187oehr.fsf@aung.informatik.uni-bremen.de> <56ebab2e-86d2-bab4-be48-303fc0da0c81@gmx.net> <87poc6l4et.fsf@aung.informatik.uni-bremen.de> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Thu, 10 Aug 2017 13:47:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <87poc6l4et.fsf@aung.informatik.uni-bremen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:qEMntA7IDjcD5naPhj30H5mKtulA+ht7sF2ulDT2refXLUBsVhE tTK3JHA9/SIz5zH+7GfEEvG3SQjPJ16QhonPsTypdQl/nebRLyWP9RPT1yGaAC6A/seA2yp Azc4k2buGrvikLK7qqZ2HGTCrf2PQtiDRlS53O3X+2iR5+AbJrqAyY99T7OiowfAVXsxBPk ag7UhswbRhe7VM+Xsac9Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:jIeYrI1znwI=:QIVhAV4+BkAfLVvpsb2Z+n mbx4QVcFMmgLBPlswVNHGd5ZwgpE5qSMa4LP3Dz73TYiXbwhfVLzL65QH8b64j4uFsINdGkVn Y6rbX3pSXqQnF2Oryg+zWRtiU8u/1OuePjFxCNfw8IaOU6Ruvj2dDqdy+Z+yckcnnFvNHKD/j yJAbDfIH8rmCwvwGLE8ULF5h4ReF1CZSKw4ryqvISqfuUmKY4bvBoS9ACyvqKNCzPj6SMEOOj QcwwMmk/rbeXbcIhgLFGEU04AKLCHuAnAd6HO2xBcVI3DvN8FnwEGcv+l5ouytO6QgQiUQupQ 0SaAGaTmI18yWMTfkySAZJOJgHF2NQzbl2pUfJvg0wgeO7MSpkswNec4S1/oJzd0ZOEk47eSG qJ5I2fWr9tvwnX041d3W9ie5KaN/x+nxE6tFpqGfz3d+mYMClfOWUqcNVF4lYXIxs0yDcm3np z8/yF7J3PpQecqKUI96FmE1+nzIOXbgEOX6ICM0hTftFLGgXCfugQWf35Q1ptd9BguPLBLsLR UeR5H5VDteV9v7ecqy0i/PU41fJtiKd7DX/qM/LwLCdqYrhb1c19uiURJ3QtnffjkxJwNVSun H3NndU6qrvoGHjaXCOpyutoPyKsCGAep5u10Rn7IvWROQbcILWck1h6do8Seq6FteI4xsOORw fUz5YBgPzJzVe7VTOCBX7wNeSYN41qxdzqU9WuNhrHCzYjvZOYzt6b0zz8fq9y3Ge+Yi/aDbk N2+pAz2yLwUEHhHz9YkYWr8lXO7sil9ncbdQPbhNNTqHNJtng7NlhfbIkoQexUxtTO8E4RZOo cabxr9U5Rv3AKHzNODS2k2jgQ+a38SB9FNtzTjc57qm1xndNiw= Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 11:47:49 -0000 Hi Olaf, a few remarks below. On 08/08/2017 12:50 PM, Olaf Bergmann wrote: > Hi Hannes, > > Hannes Tschofenig writes: > >> I believe Emmanuel needs to tell us a bit more about the use case he has >> in mind. > > And of course others as well. Hannes did a good outline of what he > thinks should be addressed. Those who have use cases that are not > covered by this should speak up. Certainly. > >> The use cases I would like to cover are: >> >> - a developer creates a single firmware image, which may consist of >> source code from various parties and may also contain binaries from >> third parties. >> >> - a developer creates multiple firmware images (since the device has >> multiple microcontrollers that need to be updated). >> >> In this model the update service on a microcontroller gets code from a >> single source only (at least for the device it appears so since it does >> not know whether an included library was written by a different developer). > > Yes, I agree in principle. > > What we have seen (not only at the IOTSU workshop but also on existing > devices such as VoIP phones) is that firmware updates typically do not > come as a monolithic package but that in modules that can be updated > separately (the most common---and desirable---split is between the OS > and the basic bootloader). I think that at least this should be > addressed here. FWIW I would not consider VoIP phones in scope of the devices we would be looking at. I also recall discussions at the IoTSU workshop but I remember that there was some confusion between the concept of a monolithic firmware images and what is actually sent over the wire (full image vs. differential updates). I don't think we ever talked about bootloaders vs. the rest of the OS. > >> What I specifically want to exclude is a model like JavaScript where you >> can get code from multiple different sources dynamically during code >> execution. > > I agree as well. > > Grüße > Olaf > Ciao Hannes From nobody Thu Aug 10 09:16:05 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CD51323A4 for ; Thu, 10 Aug 2017 09:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eDPlSi7IAVH for ; Thu, 10 Aug 2017 09:16:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF36C13239E for ; Thu, 10 Aug 2017 09:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7AGFuCP006368; Thu, 10 Aug 2017 18:15:56 +0200 (CEST) Received: from aung.tzi.org (p57A630BD.dip0.t-ipconnect.de [87.166.48.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xStXr5C6mzDKwP; Thu, 10 Aug 2017 18:15:56 +0200 (CEST) From: Olaf Bergmann To: Hannes Tschofenig Cc: Emmanuel Baccelli , fud@ietf.org References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> <87d187oehr.fsf@aung.informatik.uni-bremen.de> <56ebab2e-86d2-bab4-be48-303fc0da0c81@gmx.net> <87poc6l4et.fsf@aung.informatik.uni-bremen.de> Date: Thu, 10 Aug 2017 18:15:56 +0200 In-Reply-To: (Hannes Tschofenig's message of "Thu, 10 Aug 2017 13:47:36 +0200") Message-ID: <87shgziekj.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 16:16:04 -0000 Hi Hannes, Hannes Tschofenig writes: > FWIW I would not consider VoIP phones in scope of the devices we would > be looking at. I do not say that we should look at VoIP phones in general (if they happen to be class 1 devices, they might be in focus here). I brought these up as an example that shows how multi-step firmware updates today are handled on devices that also have certain limitations on their RAM and flash memory. This brings me back to the charter text. It says: "Since the publication of RFC 4108 more than 10 years have passed and more experience with IoT deployments have lead to additional functionality requiring the work done with RFC 4108 to be revisited." Now, although it was already suggested (and you agreed) to mention RFC 7228 class 1 devices later in the charter, the quoted sentence may lead to the impression that this is merely a 4108bis which would address non-constrained devices as well. > I also recall discussions at the IoTSU workshop but I remember that > there was some confusion between the concept of a monolithic firmware > images and what is actually sent over the wire (full image vs. > differential updates). I don't think we ever talked about bootloaders > vs. the rest of the OS. It's never too late to start. As said before: Vendors do this already. Gr=C3=BC=C3=9Fe Olaf From nobody Thu Aug 10 14:51:15 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D813245E for ; Thu, 10 Aug 2017 14:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lx-1ynVOv-X for ; Thu, 10 Aug 2017 14:51:11 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A0D132379 for ; Thu, 10 Aug 2017 14:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7ALp7pX009335; Thu, 10 Aug 2017 23:51:07 +0200 (CEST) Received: from client-0031.vpn.uni-bremen.de (client-0031.vpn.uni-bremen.de [134.102.107.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xT1zb488yzDL5g; Thu, 10 Aug 2017 23:51:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <76330c36-4e99-3013-e6bf-61e9c627ba46@gmx.net> Date: Thu, 10 Aug 2017 23:51:06 +0200 Cc: Inria Paris , fud@ietf.org X-Mao-Original-Outgoing-Id: 524094666.785967-597143cddc62f394c1cf2db89cccc75c Content-Transfer-Encoding: quoted-printable Message-Id: <149A55E2-29FE-49CB-834D-8C6827460EAE@tzi.org> References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> <76330c36-4e99-3013-e6bf-61e9c627ba46@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 21:51:14 -0000 Hi Hannes, We always have this tension of different classes of hardware target. Most of the work of CoRE was about targeting class 1, but not in the = sense of targeting it exclusively, but just in the sense that class 1 = can be part of the solution as well as the higher classes (see also the = 7228bis for a way to extend the class nomenclature =E2=80=94 = https://lwig-wg.github.io/terminology/ ). On Aug 8, 2017, at 12:29, Hannes Tschofenig = wrote: >=20 >=20 > " > This group focuses on defining a firmware update solution for Class 1 > devices, as defined in RFC 7228, i.e., IoT devices with ~10 KiB RAM = and > ~100 KiB flash. > " Maybe s/for/that is applicable to/ (so it=E2=80=99s not just limited to = class-1, but can also work for class-2). Maybe add that the sweet spot (full range of capabilities) is likely to = start about factor 2 or 3 above those numbers, as you mentioned. And maybe also give an impression of where the range of applicability we = are shooting for will end (i.e., this is not meant for updating Linux, = which 7228bis calls J-group and ARM calls A-class). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 10 15:36:41 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42426132485 for ; Thu, 10 Aug 2017 15:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxNAERZTZIsv for ; Thu, 10 Aug 2017 15:36:38 -0700 (PDT) Received: from mail.stillroot.org (mail.stillroot.org [176.9.132.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAB1132484 for ; Thu, 10 Aug 2017 15:36:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.stillroot.org (Postfix) with ESMTP id C777642985; Fri, 11 Aug 2017 00:36:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ba.stillroot.org Received: from mail.stillroot.org ([127.0.0.1]) by localhost (mail.stillroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPJkVS2MS_Iu; Fri, 11 Aug 2017 00:36:32 +0200 (CEST) Received: from [192.168.1.66] (unknown [IPv6:2602:306:36e3:3580:30a0:4032:2ca8:aab3]) by mail.stillroot.org (Postfix) with ESMTPSA id 80AD142981; Fri, 11 Aug 2017 00:36:31 +0200 (CEST) From: "Thomas Eichinger" To: "Hannes Tschofenig" , fud@ietf.org Cc: "Emmanuel Baccelli" Date: Thu, 10 Aug 2017 15:36:27 -0700 Message-ID: In-Reply-To: <76330c36-4e99-3013-e6bf-61e9c627ba46@gmx.net> References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> <76330c36-4e99-3013-e6bf-61e9c627ba46@gmx.net> MIME-Version: 1.0 X-Mailer: MailMate (2.0BETAr6090) Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 22:36:40 -0000 Hi Hannes, Thanks for the proposal! Please see comments below. On 8 Aug 2017, at 3:29 PDT(-0700), Hannes Tschofenig wrote: > On 07/22/2017 09:57 AM, Emmanuel Baccelli wrote: >> >> At high level, I have the following comments & suggestions: >> >> - we have the case of software updates, not only firmware updates, so >> I'd rather we talk about the more general case of software updates. Is >> there a strong reason against this? > > > There are several reasons why I wanted to focus on firmware updates: > > (a) In ARM we have worked on firmware updates for M-class devices and > A-class devices. The constraints, developer experience, business models, > the involved parties, security concerns, etc. between these two classes > of devices are different. We don't see a lot of guys running special > versions of Java, JavaScript/JerryScript, etc. on M-class devices even > though we have been experimenting with these ideas as well (see > https://developer.mbed.org/javascript-on-mbed/). My personal opinion is > that those are nice fun projects but not useful for anything serious. Personally, from the charter text it is not clear what it considers part of the firmware and what it doesn't. The general definition of firmware is very blurry with different meanings for many people. So applications running in an OS or on top of a driver library are not necessarily considered firmware although maybe part of the same resulting monolithic binary image. Best, Thomas ps.: There is a reference of RFC4018 which is probably unintended. From nobody Thu Aug 10 15:37:39 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50911321EF for ; Thu, 10 Aug 2017 15:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMn5azRqsYVP for ; Thu, 10 Aug 2017 15:37:37 -0700 (PDT) Received: from mail.stillroot.org (mail.stillroot.org [176.9.132.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8E01F1321E9 for ; Thu, 10 Aug 2017 15:37:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.stillroot.org (Postfix) with ESMTP id 82F0142981 for ; Fri, 11 Aug 2017 00:37:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ba.stillroot.org Received: from mail.stillroot.org ([127.0.0.1]) by localhost (mail.stillroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dAjEk8NSa4S for ; Fri, 11 Aug 2017 00:37:02 +0200 (CEST) Received: from [192.168.1.66] (unknown [IPv6:2602:306:36e3:3580:30a0:4032:2ca8:aab3]) by mail.stillroot.org (Postfix) with ESMTPSA id 2A02C42985 for ; Fri, 11 Aug 2017 00:37:01 +0200 (CEST) From: "Thomas Eichinger" To: fud@ietf.org Date: Thu, 10 Aug 2017 15:37:00 -0700 Message-ID: MIME-Version: 1.0 X-Mailer: MailMate (2.0BETAr6090) Archived-At: Subject: [Fud] Comment on draft-moran-fud-manifest-00 X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 22:37:39 -0000 Hi, reading draft-moran-fud-manifest-00 I am wondering what people think about adding a component to the manifest classifying the described update as a security and/or feature update (others are imaginable) in a machine-readable manner. The use case I see is that users then can define rules to deploy security only updates in an automated timely fashion while being able to review others before. Similar to Directive.applyImmediately but not forced by the Author of the update. Any opinions on that? Best, Thomas From nobody Mon Aug 14 06:05:17 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADDC1321D0 for ; Mon, 14 Aug 2017 06:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKaUtam1ey0T for ; Mon, 14 Aug 2017 06:05:13 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFA31321A7 for ; Mon, 14 Aug 2017 06:05:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F3B45300558 for ; Mon, 14 Aug 2017 09:05:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vHFFIWqjn31l for ; Mon, 14 Aug 2017 09:05:11 -0400 (EDT) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 0F86330023A; Mon, 14 Aug 2017 09:05:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> Date: Mon, 14 Aug 2017 09:05:10 -0400 Cc: fud@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 13:05:16 -0000 I'm jumping into this conversation after vacation. I have read the = whole thread to date before composing this note. > Firmware Updating Description (FUD) The page that Kathleen set up call this group Firmware UpDate (FUD). > Vulnerabilities with 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 are equipped with such a mechanism. = While > there are many proprietary firmware update mechanisms in use today = there > is a lack of an modern interoperable approach of securely updating IoT > devices. >=20 > A firmware update solution consists of several components, including a > mechanism to transport firmware images to IoT devices and a manifest > that provides meta-data about the firmware image as well as > cryptographic information for protecting the firmware image in an > end-to-end fashion. With RFC 4018 the IETF standardized a manifest > format that uses the Cryptographic Message Syntax (CMS) to protect > firmware packages. There are some vital pieces of information that need to be conveyed, but = from the above text, it is not clear to me whether they are expected to = be in the manifest and meta-data. The vital data includes: - a firmware package identifier; - whether the package is a patch or upgrade; - the hardware the package needs to run; - dependencies on other firmware packages; and - if the package is encrypted to protect intellectual property, the = key needed to decrypt it. > Since the publication of RFC 4108 more than 10 years have passed and > more experience with IoT deployments have lead to additional > functionality requiring the work done with RFC 4108 to be revisited. = The > purpose of this group is to standardize a version 2 of RFC 4108 that > reflects best current practices. This group will not define any > transport mechanism. >=20 > In 2016 the Internet Architecture Board organized a workshop on > 'Internet of Things (IoT) Software Update (IOTSU)', which took place = at > Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. = The 13-14 June 2016 > 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 lack of regulatory requirements, and misaligned incentives. It is > nevertheless seen as important to standardize the building blocks that > help interested parties to implement and deploy a solid firmware = update > mechanism. >=20 > In particular this group aims to publish two documents, namely > * an IoT firmware update architecture that includes a description of > the involved entities, security threats and assumptions, and > * the manifest format itself. The text a few paragraphs ago made me think that rfc4108bis was an = output. Why is it not here? > This group does not aim to standardize a generic software update > mechanism used by rich operating systems, like Linux, but instead > focuses on software development practices in the embedded industry. This should be expanded to make it clear that JavaScript is not a goal = either. > This group will aim to develop a close relationship with silicon = vendors > and OEMs that develop IoT operating systems. >=20 > Milestones >=20 > Dec 2017 Submit "Architecture" document as WG item. >=20 > Dec 2017 Submit "Manifest Format" specification as WG item. >=20 > Jul 2018 Submit "Architecture" to the IESG for publication as an > Informational RFC. >=20 > Nov 2018 Submit "Manifest Format" to the IESG for publication as a > Proposed Standard. The text a few paragraphs ago made me think that rfc4108bis was an = output. Why is it not here? Russ From nobody Mon Aug 14 06:13:45 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1592C1321D2 for ; Mon, 14 Aug 2017 06:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mZN3uhnHIxL for ; Mon, 14 Aug 2017 06:13:42 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B821321D5 for ; Mon, 14 Aug 2017 06:13:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1C1E1300526 for ; Mon, 14 Aug 2017 09:13:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EniVQHX0UxYU for ; Mon, 14 Aug 2017 09:13:41 -0400 (EDT) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id BED5530023A; Mon, 14 Aug 2017 09:13:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Mon, 14 Aug 2017 09:13:39 -0400 Cc: fud@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Thomas Eichinger X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Fud] Comment on draft-moran-fud-manifest-00 X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 13:13:44 -0000 Yes, it makes sense to include that. I was wondering why you put all of the key management into the spec, = instead of defining a manifest content type that is carried inside = EnvelopedData. That would cover every form of key management that you = care about. This is the approach that was used in RFC 6486, although = they only care about encapsulation in SignedData. Russ > On Aug 10, 2017, at 6:37 PM, Thomas Eichinger = wrote: >=20 > Hi, >=20 > reading draft-moran-fud-manifest-00 I am wondering what people think = about > adding a component to the manifest classifying the described update as = a > security and/or feature update (others are imaginable) in a = machine-readable > manner. >=20 > The use case I see is that users then can define rules to deploy = security > only updates in an automated timely fashion while being able to review > others before. Similar to Directive.applyImmediately but not forced by = the > Author of the update. >=20 > Any opinions on that? >=20 > Best, > Thomas From nobody Mon Aug 14 13:51:19 2017 Return-Path: X-Original-To: fud@ietf.org Delivered-To: fud@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 057FE132423; Mon, 14 Aug 2017 13:51:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: Kathleen.Moriarty.ietf@gmail.com, fud@ietf.org, housley@vigilsec.com, fud-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150274387697.10461.2378272658310533398.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 13:51:16 -0700 Archived-At: Subject: [Fud] fud - New Meeting Session Request for IETF 100 X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:51:17 -0000 A new meeting session request has just been submitted by Russ Housley, a Chair of the fud working group. --------------------------------------------------------- Working Group Name: Firmware UpDate Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: lamps acme tls ipsecme sipcore stir ipwave sipbrandy curdle Second Priority: perc tcpinc uta ace saag oauth dispatch Third Priority: mtgvenue iasa20 People who must be present: Russ Housley Kathleen Moriarty David Waltermire Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Aug 14 14:23:18 2017 Return-Path: X-Original-To: fud@ietf.org Delivered-To: fud@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8B0132422; Mon, 14 Aug 2017 14:23:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: Kathleen.Moriarty.ietf@gmail.com, fud@ietf.org, david.waltermire@nist.gov, fud-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150274579635.10369.9376360056180158071.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 14:23:16 -0700 Archived-At: Subject: [Fud] fud - Update to a Meeting Session Request for IETF 100 X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 21:23:16 -0000 An update to a meeting session request has just been submitted by David Waltermire, a Chair of the fud working group. --------------------------------------------------------- Working Group Name: Firmware UpDate Area Name: Security Area Session Requester: David Waltermire Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: lamps acme tls ipsecme sipcore stir ipwave sipbrandy curdle mile sacm Second Priority: perc tcpinc uta ace saag oauth dispatch netmod Third Priority: mtgvenue iasa20 People who must be present: Russ Housley Kathleen Moriarty David Waltermire Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Aug 18 02:58:29 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F161323AD for ; Fri, 18 Aug 2017 02:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yljX3CJZjqyi for ; Fri, 18 Aug 2017 02:58:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B239B13243A for ; Fri, 18 Aug 2017 02:58:24 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.73]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MATlG-1dt35y2buM-00Bfmw; Fri, 18 Aug 2017 11:58:20 +0200 To: Thomas Eichinger , fud@ietf.org Cc: Emmanuel Baccelli References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> <76330c36-4e99-3013-e6bf-61e9c627ba46@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Fri, 18 Aug 2017 11:58:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZNEN1FMk4krX7JTev1zZ2oO+9rMgnh5rLhh8oZeQdXGNTtwYS2v NluEffDCFNcTt/8/+c52+jBaZyeYxIsJJGDVcpSFc2DyWC31SeEzOVk+mAU5Z2FX6lVZIcO 5w7Y+5IBpZm0fw2zia8xoPM0yqZMWeYCaXz4Bug2wT7gl7z3S+VOnXRAyurm9m58G2EMzD7 l1kcQzIfP0mdY7LawnIlw== X-UI-Out-Filterresults: notjunk:1;V01:K0:a/3KoxyFz6k=:i5o1Rtg7a2XDEez973ffD3 hnWx9MzQZcCoYlBJOZOVUo8C5c26FcSa4Iyq4a1+o/52RYTA+qlHrDQkfl/IyT7uaZ2FVoBPt Gpxnc4I5HtPh3skCMu3WUV8Oa3VR9611YNEyWQk8QMOYXKCisTwZHJI/AZbfIKlg4cXsU32Nf goSnr5o6bXbJE6/eewfXLEJqjsBdAUDqXgaPF+7j7D11OaNPwsVqOuT6THdMEplOYL1NWymOy mIK/chLjeig0dkpnK+3pCc9SUDpzXgi8xddYkzr7SN+C0IXSlWhTcqMDHIKh4k+NlpI79nC80 SB07GYmFC+UkFHm8Skzj0nPdUVusVSY8M1fK87ECNKD+vm01XdqfPIBrMZ4IVTyw8oKUXYJ/x +2f8MgJWdB8MnCMrEbP/0UJOBB5LXOxhzBHXNoCi4JGzwOsDHg0gxDcGXFLjljAObDiRlOJQ/ aTbiHvGc5tPUEbiTB0JFN2JXy78fjvT7X/zGr9p5swgNbcztYFdWP420GBgZwCYSuMnqgUXU8 FxQ9MD3tJmFPeIl39FvmRtFajd6KX8pBJwuvqdUcp3E4wsoMDj4EQv56OvLdpVT7pSFLhN0JG fFUMP/Ut38K38lm891mN8A4dvINN/1sJFO6pmjqTzNZaikJQCzVWobAjXUq2B8I6cCXatTlYm 9SIBuVTMpyYuJ4Q29uor9wzL99OSNqoQwvjVtubcKIEmwJ5AxhgQkDKM7IzthsgDxJHAmo9G6 q86shCUt6s+bouQgS0lLjy0j5B2em2YXtEcmY85eajR4vcbjj6om3djrBFRv6vgijYeiSkgo+ ewF247GM/tGM+FGRcQQQSKd8EL+LXDH1YfkTPkLqEP6rJPqi8Q= Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 09:58:27 -0000 Hi Thomas, thanks for your input.Quick response only... > ps.: There is a reference of RFC4018 which is probably unintended. Yes, this is a mistake. I should be RFC 4108 "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages" https://tools.ietf.org/html/rfc4108 Ciao Hannes > > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud > From nobody Fri Aug 18 02:58:38 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A346113243A for ; Fri, 18 Aug 2017 02:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p9Cz9FMcwGQ for ; Fri, 18 Aug 2017 02:58:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD121323AD for ; Fri, 18 Aug 2017 02:58:32 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.73]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lbi2Z-1dJzTy3YgF-00lGKl; Fri, 18 Aug 2017 11:58:30 +0200 To: Thomas Eichinger , fud@ietf.org Cc: Emmanuel Baccelli References: <8f8528da-d1eb-08c7-b3fe-b1f4febed595@gmx.net> <76330c36-4e99-3013-e6bf-61e9c627ba46@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <28386c4a-0df9-a9eb-81a6-30b93dbec2bb@gmx.net> Date: Fri, 18 Aug 2017 11:58:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hH8z3nLVdnI5o5wyNaM2+J9zRCETKYphH12ordKjsCDqHeWxANu MJVMy4/hpPm9xpoaFBVX9cnXsebT4jTR133vGnkiwhu6IEuHI9tGks0bydv6TjSVf08gWYt YD7Q+ILj0ewayAdHJsE7nB89usljUcEr438v/HrufRq94xEKS9mUtBXfdHZYAiam8zE3llV kxspDBo0kmR+NsmlBTeBQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:0QeDyvuNbeI=:fILvcoIIiQRyPvcr9EWMOC E1lWfXX2U5v6Q4FenAKE/+rZXm0UPvALfv4N6eWg3F80j59FtTWNbKrl5/TkxXMzX3zrd1nik Q575tottdAxe//y9+0ppXL6YrLzyPRWpY8qm8MLDxACfNVC0OPOjfJIDwiqDib4dn35FaXX8m 1YGYYtkw5fGymgsdLxwnhiflJE+NG/uuBhyg0mlV6Wd2EzWXM1PTa62saQKiyTRbWJFNJw2bQ uQgxtCm4lcHqY0/tT6/D/UBNYS3ezeDQDwpYPhLGToEpie+lGrT9lykfartEIlG6vFToT3yJW nlU6gbbeyCDCVPqb3VrlczOwpGGpHqfwANIp9wK2PdXfbAHXeS+WoCLbcZGQ/mEEOnphQXJc2 pvjOLAvVeDot2LIGGLC7yU2zDbJ1ZruYq/AQT39dcXlioXW3uUe3gY1wIUQe1a87I2QxB/qcA tcBdh1JvlJuSF81sJ9666BkRtHyy3pBONpPPqXcp5VnPEo/c903G1Bu6dERC1gTFP0YKU9qfa ++tYmIje1qudHBy2b1dL8In2NfrYJCX6tZmhrMrin1KUI0riM21sbmTPZ2r/jK7Tq5c9ZIht4 /DYmwxrViDxQptoxsFIlyYMP91iVPQqCiNAyuEm3/+lo+HLjZjXb5w10KhBP2fMCaRUUgDdZ9 z1wJNlT1nzPH5AXCWhPVBj7/Prtyw25MHa033v0PRQlXWYrWgyCgjfGzRT/Wrt4TymdmMXEoc q6QykMk7SJwU1gCr25368icQgL9ChkmhhMIZIu/pJHkEgHE7RBZK/aTHGLu3sXT0l3Udwy7Eh E3ZpVHK+XAirw8QX0HclI178jYTLjbaOmOBfvf6jEino4IrUSE= Archived-At: Subject: Re: [Fud] Charter Text X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 09:58:37 -0000 Hi Thomas, thanks for your input.Quick response only... > ps.: There is a reference of RFC4018 which is probably unintended. Yes, this is a mistake. It should be RFC 4108 "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages" https://tools.ietf.org/html/rfc4108 Ciao Hannes > > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud > From nobody Tue Aug 22 03:12:22 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7A0132949 for ; Tue, 22 Aug 2017 03:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kWKagq32-3s for ; Tue, 22 Aug 2017 03:12:17 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00063.outbound.protection.outlook.com [40.107.0.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E30132223 for ; Tue, 22 Aug 2017 03:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=x/CSVVbACX2aFkKJDW0yqA4wdweKSvzhvWj7WkdvmkA=; b=DPi+Qi1nmVlOdXe8xXHrNiCnQ8RNP3aOVY+Fp5AhOA8TEONmE88rO4ouniuydQeajqsMHtIsbqBeTKfq3JjU+9MpVVz/8celewDU+Ie6VQ855UDmMIa89BoXEbWL7XgEpFbntI1FZcuha6cW7782eughp/tGh1CVJ96C31FA8Y8= Received: from HE1PR08MB2841.eurprd08.prod.outlook.com (10.170.246.156) by HE1PR0801MB2716.eurprd08.prod.outlook.com (10.169.123.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Tue, 22 Aug 2017 10:12:14 +0000 Received: from HE1PR08MB2841.eurprd08.prod.outlook.com ([fe80::50d2:b68:d011:b75e]) by HE1PR08MB2841.eurprd08.prod.outlook.com ([fe80::50d2:b68:d011:b75e%13]) with mapi id 15.01.1341.019; Tue, 22 Aug 2017 10:12:14 +0000 From: Brendan Moran To: "fud@ietf.org" CC: Hannes Tschofenig Thread-Topic: [Fud] (quick) review of draft-moran-fud-architecture-00 Thread-Index: AQHTGy8g7ZRoo/ApOEeGlGDwWXMJgQ== Date: Tue, 22 Aug 2017 10:12:14 +0000 Message-ID: <8242BAEC-A5C4-48B0-94C2-C7AD28995455@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0801MB2716; 6:2f0rOMKDWSbZkt//pBh19Xam1kiWJqYVxwx9jKvqgjVWSUZESBr3rP6Bgl6qbvSicC3my6LTCAnxgNIZkj6su+YdnpcXqjZ2Itan4X2v75Iu+/+MkUtabU56vjLwd6tkGwGMVG1JYeIjtr1pVeO50OhkOyj3En0yYkas5LI/7P1EndHStVMoqBekknk49XNLvhep41kLPr+N/LoCPszois4Wp8Y9i1im57xa26rf5TlnGCZChmlMBbDh2mjeD0I/eNNMiQIhsR8oz249XZHvuf3mTS457TfgS7+NrCpBf2FQAxmN6C1JIQv8beynstf4M/Hn3Xy5dFQMB/eVRZ6U5g==; 5:R7xjc691pgMcTzJPBIHtaXV6oE6iWoARIWpGqZnIMDZ6aQxjCjzntuG+gw59ZovgX2i9CJLvaHWE8a6y1Grs7NUwXbZTHiU0ci4JoQqhR47CAN727f97vNKYVgnLmELoxhmpYDPtpU8VSnAOTzi02Q==; 24:sig1xDttYnFSwXavZDByuCUSMk6kOXe2gmWShqu+hx3uiAyeKhtID1lz0jHgLWKhQfv28UhjGCqtfkAxc4taKTtceEsrRRmFfbbIdBgUqno=; 7:3VIEFMMHn49e1E4xjsTqvFXcDDdoePz5TRaJ0QDzKyss/90XNGGcKMeI2f75noilhI45ix21Id3GE+8a1yiqaiZiqYl4KC9VQn5JoAt5TjzG/bx97zd76sDVqf7lQOo2YCb2hXP3H91DmUAkYFtzzvcDf6L1pv7LsX+UpzxBZB40H1m/HfV0eIPy3RiuzPboeETlC71HCbVf9FunHdmYCaSbxJ6DvUViYTjkr0dmcuY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 792a2db6-67da-48f1-33f6-08d4e94642cb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0801MB2716; x-ms-traffictypediagnostic: HE1PR0801MB2716: x-exchange-antispam-report-test: UriScan:(192374486261705)(131327999870524)(788757137089); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0801MB2716; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0801MB2716; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(24454002)(199003)(51444003)(40434004)(189002)(83716003)(478600001)(82746002)(5890100001)(101416001)(25786009)(2906002)(81156014)(1730700003)(66066001)(8676002)(81166006)(97736004)(2501003)(4326008)(14454004)(68736007)(8936002)(305945005)(7736002)(36756003)(6246003)(6506006)(6116002)(6486002)(5250100002)(57306001)(230783001)(105586002)(33656002)(102836003)(6916009)(3280700002)(99286003)(50226002)(2900100001)(6436002)(189998001)(3660700001)(50986999)(72206003)(2351001)(53936002)(229853002)(110136004)(86362001)(5660300001)(106356001)(5640700003)(3846002)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0801MB2716; H:HE1PR08MB2841.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <710EF41A3CE99846B35D000D953F4819@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2017 10:12:14.1647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB2716 Archived-At: Subject: Re: [Fud] (quick) review of draft-moran-fud-architecture-00 X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 10:12:21 -0000 Hi Emmanuel, Please see my comments inline. Best Regards, Brendan On Wed, 19 July 2017 18:33 UTC, Emmanuel Baccelli wrote: > =3D=3D=3D=3D=3D > General comments: > =3D=3D=3D=3D=3D > > 1. In the proposed architecture some trust is required in the storage > element, which is assumed to correctly: > - serve the latest manifest/firmware (if the device pulls) > - pushe/signal newer manifests to the device (if the author pushes) I think that we are conflating two storage elements/cloud services: 1. the service that stores/distributes firmware images 2. the service that stores/distributes manifests. These two services need not (and probably should not) the same. The manifes= t distribution service does require some trust: primarily to not deny servi= ce to the connected devices, and secondarily to not modify the manifests it= distributes, however, modification will result in the rejection of the man= ifests. A secure communication medium such as DTLS might be appropriate in = order to limit the possibility of MITM interference with the distribution o= f manifests. The service that stores or distributes the firmware is a bit different. It = can be completely untrusted. Because the firmware=92s hash is stored in the= manifest, any tampering with the firmware will be detected. From the point= of view of a single device, this is still problematic, however from the po= int of view of a whole network of devices, responses are possible. For exam= ple, if many devices report the same validation failure, the device manager= may upload the firmware to a different location and issue a new manifest t= hat points to the new location. > 2. What is specific to firmware in the document so far? > It seems to me that this could apply to any software module on an IoT > device, not necessarily a firmware. > For instance it could be "application" logic (We have use cases where we > are updating some software, but not the firmware). > Why not generalize somehow the terminology to something more generic like > "software update" or something similar? The design goals are what makes this format specific to firmware, rather th= an the format itself. For example, one design goal is for the whole manifes= t to be able to fit in the memory of a micro controller at one time so that= signature validation can progress before the manifest is stored into NVRAM= , which eliminates some problematic corner cases, such as tracking the veri= fication status of a manifest. This is a key distinction between this manif= est format and RFC4108. Whereas the manifest format links to a firmware ima= ge, RFC4108 includes the whole image, which requires storing it prior to si= gnature validation. > =3D=3D=3D=3D=3D > Some more detailed comments: > =3D=3D=3D=3D=3D > > # in Section 3: > why/how/what small bootloader? Why: One design goal of the firmware update architecture is to eliminate as many= any situations as possible in which a device could fail during an update. = Ultimately, this means that there needs to be at least one piece of firmwar= e that is never updated, since we assume that power could fail at any momen= t. If there is a piece of firmware that is never updated, it must be thorou= ghly tested and (as close as possible to) free of bugs. We also must minimi= ze the attack surface of the firmware so that we minimize the chance of a v= ulnerability being discovered. How: We call this piece of firmware the bootloader. The bootloader's role is to = take a candidate image, verify it, then replace the active image if it is v= alid. What: In practice, this seems to create two classes of bootloader, with different= absolute minimum requirements: - on-chip candidate image storage -- a flash driver to overwrite the active image -- a mechanism to validate the image (a digest algorithm) - off-chip candidate image storage -- a flash driver to overwrite the active image -- a mechanism to authenticate the image (e.g. HMAC, or CMAC) -- a mechanism to read the off-chip image (e.g. e.g. a SPI flash driver) N.B. these are the absolute minimum requirements. If advanced features are desired, such as boot from network or inplace upda= te over network, my recommendation is to use a 2-stage bootloader, where th= is minimal bootloader ensures that the second-stage bootloader is always up= datable. > why/how friendly to broadcast =3D> no TLS, Object security Why: I mean "broadcast" in two contexts: 1. literal broadcast, i.e. IP multicast, radio, satellite, etc. 2. storage in an untrusted Content Distribution Network. >From a security perspective, these two media are equivalent; any part of th= e image could be intercepted or tampered with. Broadcast has many benefits, especially in constrained radio networks and m= esh networks. Broadcasting a firmware update will dramatically speed up dep= loyment. This applies equally to hosting an image on a CDN and broadcasting= it into a mesh network. How: To make an image broadcast-friendly, it must not contain any per-recipient-= unique information. It must also be able to determine whether or not the im= age applies to it early. Where firmware encryption is used, there will alwa= ys be some recipient-specific information. The important aspect, however, i= s that the firmware itself is not specific to a particular recipient. The m= anifest itself may be specific to a recipient, however. For example, a device must be able to identify whether a broadcast image ap= plies to its hardware and software configuration. This could be done by mat= ching vendor and model identifiers. > but: are we really going to broadcast a (relatively large) firmware? I believe that this is the only way to distribute firmware efficiently. Nat= urally, it will be distributed in blocks. The mechanics of this process are= beyond the scope of the manifest draft and the firmware update architectur= e. > # in Section 3.4: > > "the device is required to provide a minimum of two storage locations for > firmware and one bootable location for firmware." > > Is reliability possible only with this approach? > This seems out of scope of the generic architecture. I think that this could be expressed better: The device is required to prov= ide a minimum of two storage locations for firmware, at least one of which = must be bootable. As described above, there can be multiple boot stages. I think it's importa= nt to make the most minimal set of firmware non-replaceable. Equally, all o= f the firmware necessary to acquire a new image should be atomically replac= eable. This could mean that the architecture has a slightly different struc= ture: +----------------------------+ | Stage 1 bootloader | +----------------------------+ | Stage 2 bootloader, slot A | +----------------------------+ | Stage 2 bootloader, slot B | +----------------------------+ | Application | +----------------------------+ Where: * The Stage 1 bootloader is non-replaceable * The Stage 2 bootloader is replaceable and capable of network upgrade of b= oth itself and the application * The application only gets a single slot, since the bootloader is capable = of recovery if the application update is interrupted. With this sort of layout, the requirement for two storage locations is sati= sfied, the requirement for resilience to failure is satisfied, but there is= still only one application slot. > # in Section 3.5: > How about rephrasing like: > "The approach must not require a large bootloader" I think that "minimal" conveys the spirit of the non-replaceablility requir= ement better. The more features there are in the bootloader, the more likel= y it is that it will have a critical bug, which cannot be fixed for reliabi= lity reasons. > # in Section 3.6 > Here I think the draft should reference examples of what "existing firmwa= re > formats" are alluded to. > In my opinion, this section could be removed for two reasons: > 1. because the metadata is anyways separate from the actual firmware, > 2. the software might not be firmware, but just a software module (as per > my comment above) I also think this is not clear enough. The point of this section is that th= e update mechanism should not place any requirements on the payload that it= conveys. > # in Section 3.7 > I would suggest to have this document focus primarily on single MCU devic= es. > Ideally: extensions to cover multi-firmware devices would either be in a > later part of the document or in a separate document. > > At this point in the document it is obscure what the distinctions are > between: > Author, Store, Apply, Approve, Qualify "Modules," in this context, was meant to mean that it would cover multiple = software modules within a single MCE, though this is naturally extensible t= o multiple MCUs. I'm not certain that "permissions" is the right word. The intent is that ea= ch storage location can assert a list of permissions that must all match in= a given update. There must then be sufficient signatures from certificates= that have those permissions to match each of the asserted permissions. For example, if a firmware storage location requires Author, Store, and App= ly, then an update will only be installed if an update is signed by a certi= ficate with the Author permission, a certificate with the Store permission,= and a certificate with the Apply permission. Alternatively, some certifica= tes may have more than one permission. This could allow some more complex use-cases, for example: If the update on= ly has the Author and Store signatures, then the update is cached, but not = installed until a new update referencing the same payload is dispatched wit= h the Apply signature. The permissions should be amended with descriptions: * Author: To compile, assemble, link, encode, etc., the firmware. This is t= he fundamental permission that encapsulates the right to create a payload t= hat a device consumes. * Store: To place a payload in storage without installing it * Apply: To take a stored payload and install it * Approve: To indicate that an owner or operator has agreed to install the = payload * Qualify: To assert that a payload has been tested within its expected ope= rating environment I have debated adding an additional "permission" that a CI system can use t= o assert that tests have passed. > # in Section 4: > How about being more assertive here, such as: > > The firmware image MAY be encrypted and MUST be integrity protected AS WE= LL > AS AUTHENTICATED/AUTHORIZED. > The meta-data MUST integrity protected and AUTHENTICATED. I'm happy with more assertive language, unless there is a good reason (i.e.= a use case it prohibits) not to. The wording, however, should align with R= FC2119: > The firmware image MAY be encrypted and MUST be integrity protected > and MUST be authenticated/authorized. The meta-data MUST be > integrity-protected and authenticated > # in Section 5: > > - When should the device apply the update? > out of scope? > > - How should the device apply the update? > out of scope? > > - Where should the firmware be stored? > out of scope? I'm not clear on why any of these items would be out of scope for a firmwar= e update architecture. Could you please elaborate? > - What kind of firmware binary is it? > is this different from the question "should it apply the firmware"? Yes, this is different. For example, a compressed binary and a raw binary a= re both written directly to flash (how) but the compressed binary must be d= eflated first (what). A binary wrapped in a CBOR wrapper is also written di= rectly to flash, but start pointer of the binary must be located. So the "h= ow" is the same, but the "what" is different. I realise that it seems easy to make these the same, however I have found, = working on the manifest format, that where there appears to be opportunity = for optimization by merging two fields, it frequently ends up causing a pro= blem later. > - Where should the update be obtained? > if we are not making the assumption that metadata and firmware are > stored in difference places, is this redundant? The device needs to answer this question, regardless of assumption. If you = make the assumption that the metadata and firmware are co-located, that sim= ply means that the device has a hard-coded answer to the question, not that= the question doesn't require an answer. > # in Section 6: > "information about when the firmware update has to be applied". > I guess the default should be "as soon as possible". > However, in cases when the time is no synchronized, I'm wondering how the > device > could interpret this "when" indication. There are some parts of this architecture which will not be applicable to a= ll devices. If a device has no notion of time, then it has two options: it = can install a payload immediately, or it can store the payload and wait for= a signal that authorises it to perform an installation. That is also a for= m of "when" information. > # in Section 7: > Typically the author will produce/transfer a new firmware and its > (manifest) metadata in one go. > In practice, firmware and manifest might even be bundled in a single file > (?). > Hence I would suggest to invert the order of the steps "Upload Firmware" > and "Create Manifest". This section is just an example of the split-manifest/payload flow. That do= esn't mean that contiguous manifest/payload is prohibited; this is just an = example. However, while contiguous metadata/payload may be current practice, that do= esn't mean it will scale well to many devices. As detailed above, there are= different trust requirements for manifest distribution and for payload dis= tribution. There are also different bandwidth requirements for manifests an= d for payloads. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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 nobody Tue Aug 22 04:33:21 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493AE132983 for ; Tue, 22 Aug 2017 04:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DeoIEtcHcHP for ; Tue, 22 Aug 2017 04:33:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51F8132977 for ; Tue, 22 Aug 2017 04:33:17 -0700 (PDT) Received: from [192.168.91.203] ([80.92.118.73]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MHokD-1dh6E20oY9-003i1g; Tue, 22 Aug 2017 13:33:15 +0200 To: Thomas Eichinger , fud@ietf.org References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 22 Aug 2017 13:33:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Spz5U15R842r3WYJCx6xwKQCFB68vdmK1CTNql81mdsrOmNTplw 9Z36dmFitlFHYIPcxEMHrZdXFwFpB70Y1SFw81HqcrN2GeilDYQ4lHJbF9svGBQSjMbcM0P Sj/QbjzjbwQcYzpZORMytWQYUlczCyH191CHmwEcUKW9vgtgHmPphoDCAR6ovhshx5kDxEC z+SpHgcxMgD0xHS4Qu+SA== X-UI-Out-Filterresults: notjunk:1;V01:K0:yE2U5XLcri8=:aaNyu7CEpjt15HBYX53hND N+ZT+QhwY5aLj4ugeK9CCtWETGiLbxXUUAU8hv+Ap972r1UBD9sR5ApI3P3k0UdkkJcIxPHzg a28qTxX+3Yhn+1ztAjLfoNDc872byzBrRdzOMWrXUpgQcmzv75crbzecjaxgEW+jblij3URvQ NNmN6uSgJvpKi/PTIv07jPn3qHVqFDlR6MESD7ZbxQeIx/QnVMdZS6lHeEnV8d4pSFYvOd8o2 xepEr7fPttxomt7aGCoVKHxYH6WLR2GcDu1q/paghQuXrnR5ytXAaGX8qliemtCAHDukwkJev btM6FyRbMPCF7xBD/oMjsC33FSGMaT6tyshClceMTR1QqagaN58XiNpx3Nsbg3Q9/FoT6ZgPf /ev36dnF9VXULgW6qWcNyXLiPqZFs2cjJTyq0buhhokXKllUlMnz8qjoEfoV8KP4+Rj+QMVE1 fzgxfZj1Cx/VL5iTT1q/GNFJ/BfuUHw95G9N/job92YCTsS4iEZBwNOJeGow9W5B/KY7Wd7uU w2nGtllREjkMxSBWPPytLpiJPKbVYcB4Yv5IPl2rfs6k7VQK3QRQNvw4KNRg5I9dr923FFpgo 9GkeGzJzbzGhuRMCyGxqj7gxbieWOpsFtyA/9ZkfiwZ7vp6OJX22dcycbxAjyC2j43JIOAksx LSBB6GTaDQSA1+7JQHDOqsaop0o3pWXeTFr3yzrIISR2FP1lM/aIDwgTJOAYWqbFdq3lHgZz2 0zLQ2k5586slPOdDYjFne3OSdetJahHmrHzsQHfeXQ2GdTQQ5vwk7S5xD2ZGN5XVAXyOF3NwM EnezO5OL3NHXPQTkGQUlWLhDTTaMxbDvObJgN9T78DgOlP3nbY= Archived-At: Subject: Re: [Fud] Comment on draft-moran-fud-manifest-00 X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 11:33:20 -0000 Hi Thomas, interesting idea. As an optional feature I don't see a problem with it. How exactly the approval process for applying a firmware update in a particular product looks like will of course vary a lot. At the IOTSU workshop we had people describing a healthcare setting where any code changes need to go through certification first. In smart home environments the firmware updates are most likely facing fewer regulatory restrictions. Ciao Hannes On 08/11/2017 12:37 AM, Thomas Eichinger wrote: > Hi, > > reading draft-moran-fud-manifest-00 I am wondering what people think about > adding a component to the manifest classifying the described update as a > security and/or feature update (others are imaginable) in a machine-readable > manner. > > The use case I see is that users then can define rules to deploy security > only updates in an automated timely fashion while being able to review > others before. Similar to Directive.applyImmediately but not forced by the > Author of the update. > > Any opinions on that? > > Best, > Thomas > > _______________________________________________ > Fud mailing list > Fud@ietf.org > https://www.ietf.org/mailman/listinfo/fud > From nobody Tue Aug 22 10:19:17 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B211323B5 for ; Tue, 22 Aug 2017 10:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXcuBWKJCWO8 for ; Tue, 22 Aug 2017 10:19:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FFC1323AB for ; Tue, 22 Aug 2017 10:19:12 -0700 (PDT) Received: from dooku.sandelman.ca (modemcable017.184-58-74.mc.videotron.ca [74.58.184.17]) by relay.sandelman.ca (Postfix) with ESMTPS id EA9D31F905 for ; Tue, 22 Aug 2017 17:19:10 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 05813296A; Tue, 22 Aug 2017 19:18:46 +0200 (CEST) From: Michael Richardson To: fud@ietf.org In-reply-to: References: Comments: In-reply-to Hannes Tschofenig message dated "Tue, 22 Aug 2017 13:33:14 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 22 Aug 2017 13:18:46 -0400 Message-ID: <525.1503422326@dooku.sandelman.ca> Archived-At: Subject: Re: [Fud] Comment on draft-moran-fud-manifest-00 X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 17:19:16 -0000 --=-=-= Content-Type: text/plain Hannes Tschofenig wrote: > Hi Thomas, > interesting idea. > As an optional feature I don't see a problem with it. > How exactly the approval process for applying a firmware update in a > particular product looks like will of course vary a lot. At the IOTSU > workshop we had people describing a healthcare setting where any code > changes need to go through certification first. In smart home > environments the firmware updates are most likely facing fewer > regulatory restrictions. I think that the regulated (e.g. health-care) situation is different than the security vs feature update situation. In the regulated situation, I can see two ways to go about the process: a) devices have a built-in policy that requires signatures from X,Y and Z before they will apply them. b) devices have a built-in policy that will accept updates on from Z (the regulator) Z has a policy where it only reviews things once X and Y have signed. Applying the signature from Z may remove the signature from X and Y (that's a space optimization only). As the device does not recognize X or Y, it would ignore those signatures. Whereas, Thomas is suggesting that when any of X, Y or Z signs, it would include some kind of flag (probably an OID?) saying the reason for the update. (Maybe we'd want to also have optional space for a URL pointing at update notes) > On 08/11/2017 12:37 AM, Thomas Eichinger wrote: >> Hi, >> >> reading draft-moran-fud-manifest-00 I am wondering what people think >> about adding a component to the manifest classifying the described >> update as a security and/or feature update (others are imaginable) in >> a machine-readable manner. >> >> The use case I see is that users then can define rules to deploy >> security only updates in an automated timely fashion while being able >> to review others before. Similar to Directive.applyImmediately but not >> forced by the Author of the update. >> >> Any opinions on that? >> >> Best, Thomas >> >> _______________________________________________ Fud mailing list >> Fud@ietf.org https://www.ietf.org/mailman/listinfo/fud >> > _______________________________________________ Fud mailing list > Fud@ietf.org https://www.ietf.org/mailman/listinfo/fud -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZnGd1AAoJEJVM4Vb9/EKQzBsH/295dYZBM3yJZ2E1yLWpwcPS hDn1RMxcG+32dfLH9IR4wnf+mVadaR82CrLZsHbC+fpuNmuT7W6dyEEiZhSsrKZh nsflc6PufkkVomG1vFtqSp3O6I0NU+5Yas3gtHptyyteWFjq/Z/VbLnWMO2OxWhu ba/jBP2FMhkgiIL/5oXB88yOJaC1mtihEVCBG7s+hEhLwnKmHdCZTaKlnodUwDEJ TKUMTiQ1ptlmk9F7h2NWnTb5Y4+UEtPkDyIhtF1DRIH+ul77qOFRk+Jc4yUeycSr gXNH+tUc39c6RZkdS+E4i4nYVvwG0yS0IzobLFhSqnwPbIsN8bJvdycckPFxGQY= =U5X6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 30 04:33:40 2017 Return-Path: X-Original-To: fud@ietfa.amsl.com Delivered-To: fud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B718132FD1 for ; Wed, 30 Aug 2017 04:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKgwShs9LFkk for ; Wed, 30 Aug 2017 04:33:35 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0049.outbound.protection.outlook.com [104.47.0.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02A5132FDF for ; Wed, 30 Aug 2017 04:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dn4h/QZF9X5o6x9p/4L7gdKWzkuO4xRBza8bjgq9hqo=; b=ZPXO4eo8BgRNgVNbdr/aO93yt+N/7TgxoVH8vVE/tUv573pqNKsy3+ZKtP4FXOhi/vRf5AxaerrpC1Xc89TMtTpxshAxchA2+tXEuAF7AbEc7N7zw8vb8NJNqFdvXIKrTSgaSiWV5WAnH7YnroFo1xXtroRJdWdpKZZHwC6iPkY= Received: from AM4PR08MB2836.eurprd08.prod.outlook.com (10.171.191.30) by AM4PR08MB2674.eurprd08.prod.outlook.com (10.171.190.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Wed, 30 Aug 2017 11:33:32 +0000 Received: from AM4PR08MB2836.eurprd08.prod.outlook.com ([fe80::b9a4:51df:9b8:731]) by AM4PR08MB2836.eurprd08.prod.outlook.com ([fe80::b9a4:51df:9b8:731%13]) with mapi id 15.01.1385.014; Wed, 30 Aug 2017 11:33:32 +0000 From: Brendan Moran To: "fud@ietf.org" CC: Emmanuel Baccelli Thread-Topic: [Fud] initial comments on draft-moran-fud-manifest-00 Thread-Index: AQHTIYPOfF1uss4rc0SEDiee3LeIeg== Date: Wed, 30 Aug 2017 11:33:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR08MB2674; 6:u1DbdA88pnt3/rQP/2gBUwrZ9Lz5IVYRUWVZ46h5F274lf9I06FumWjHbK6/MJ+GDBbJh9i11Vc9QXg/zCCX1XpALgi/FWctP7oRdMwviGDLHQpzN4lnq8T9IJOfcSazg0H2fQG7J7OeExz2NZcbTHV2eXpkdzH3HV1sVQNhr5UlSs14/TaMQRp0quxDWewUa+eVh6UlIpYEdE7peIcyl6d+iy5ySQQ5A3l91q02EoN5+92xPldIsbik4fJUnwwF+KlRiGsOHntznnaXEpR+SZ+hI0Jf/1n5LcGp8+UOqG4ft35lgDKhVkQzzlzQCxgUBVH5P9wZAjRfDSo/Xt6rcQ==; 5:NfamDirs2/bLbDu8MfWE4xQ57C5zo48eP1e1T+9HAJguqBe+isT5ATYxUpFbG0/fXzyW0RoWonKlsQv7KUiXWpFvMVtY3mZyNO0xdRr1zcsmvXjylxQNp4S84i060TdvVTwCeItYIqm5sKYNHa4RkQ==; 24:5n3+OtTmVM2GQEQ6kuNKIPNFbjBkM1TxzRoghs684WJRlmBAf9+xfaPvUeTVznE0zFtS1W3pQgh5TDkLxMhhGHbWvPKjF9RyAZjUNRuLN3s=; 7:HLi1HyScyM6UEgyTYpjr9oeDlR52tzQk4d9qQMg80Wes+QDDGwc9Ndx0DzpsGQQ2ttg7jQJu+yBsZYqSPCX4ykvArjvyW10geyvl71deRLjIOPOsRzcilMZIX+FQVs/9yq7FKFb2hWY95ffTwvavZDBN+DzuoKXk6HPnojGgHw17U5FE8eeX3+V0jWD6B2KdBRSYsDhUU2P/aEMtadycxfYPxz9MEpgHdCxrTa55+ns= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a3c2a245-4ff1-4967-699f-08d4ef9af185 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR08MB2674; x-ms-traffictypediagnostic: AM4PR08MB2674: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR08MB2674; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR08MB2674; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(40434004)(24454002)(199003)(189002)(97736004)(53936002)(6512007)(99286003)(106356001)(478600001)(68736007)(2906002)(83716003)(86362001)(6246003)(5250100002)(230783001)(5640700003)(6506006)(189998001)(2501003)(105586002)(6916009)(110136004)(2351001)(5890100001)(66066001)(1730700003)(50226002)(33656002)(36756003)(229853002)(101416001)(14454004)(3846002)(81156014)(5660300001)(6116002)(8676002)(102836003)(81166006)(3280700002)(4326008)(57306001)(25786009)(50986999)(7736002)(72206003)(6436002)(305945005)(82746002)(8936002)(6486002)(3660700001)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR08MB2674; H:AM4PR08MB2836.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9C181023FCFF0249B24D34EECEA260CD@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 11:33:32.1199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR08MB2674 Archived-At: Subject: Re: [Fud] initial comments on draft-moran-fud-manifest-00 X-BeenThere: fud@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FUD - Firmware Updating Description List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 11:33:38 -0000 SGkgRW1tYW51ZWwsDQoNCkkgaGF2ZSBwbGFjZWQgY29tbWVudHMgaW4tbGluZS4NCg0KQmVzdCBS ZWdhcmRzLA0KQnJlbmRhbg0KDQpPbiBXZWQsIDE5IEp1bHkgMjAxNyAxODozNyBVVEMsIEVtbWFu dWVsIEJhY2NlbGxpIHdyb3RlOg0KPiA9PT09PQ0KPiBHZW5lcmFsIGNvbW1lbnRzOg0KPiA9PT09 PQ0KPg0KPiBMZXQncyBtYWtlIHN1cmUgdGhhdCBhIG1pbmltYWxpc3RpYyB2ZXJzaW9uIG9mIHRo ZSBtYW5pZmVzdCBmb3JtYXQgaXMNCj4gYXBwbGljYWJsZQ0KPiBlYXNpbHkgdG8gbG93LWVuZCBJ b1QgZGV2aWNlczoNCj4gLSBjbGFzcyAxIGRldmljZXMgKFJGQzcyMjgpIHdpdGggYSBzaW5nbGUg TUNVLA0KPiAtIHZlcnkgbG93IGJhbmR3aWR0aCBuZXR3b3JrIGNvbm5lY3Rpb24sDQo+IC0gbWF5 IG5vdCBoYXZlIGFuICJpbnRlcm9wZXJhYmxlIiBub3Rpb24gb2YgYWJzb2x1dGUgdGltZSwNCj4g LSDigKYNCg0KQWdyZWVkLiBUaGUgZHJhZnRlZCBtYW5pZmVzdCBmb3JtYXQgc2hvdWxkIGJlIGNv bXBhdGlibGUgd2l0aCB0aGlzLCBob3dldmVyIHRoZXJlIG1heSBiZSBjb21wcm9taXNlcywgZS5n LiBpbiB0ZXJtcyBvZiB0aGUgdHlwZSBvZiBjcnlwdG9ncmFwaHkgdXNlZCBmb3Igc2lnbmluZy4N Cg0KPiBBcyBhZGRpdGlvbmFsIHJlZmVyZW5jZSBwb2ludHMsIGxldCdzIGFsc28gbG9vayBvdXQg dGhlICh3b3JrLWluLXByb2dyZXNzKQ0KPiBtZXRhZGF0YSBmb3JtYXQNCj4gb2YgUklPVCBpbWFn ZXMgWzFdLCBhbmQgb2YgTUNVQm9vdCBpbWFnZXMgWzJdIHdoaWNoDQo+IEluIHBhcnRpY3VsYXIs IHRoZSB3aG9sZSBtZXRhZGF0YSBvZiBhIFJJT1QgaW1hZ2UgZml0cyBpbiBsZXNzIHRoYW4gMjAw DQo+IGJ5dGVzLg0KPiBBIG5pY2UgZ29hbCBjb3VsZCB0aHVzIGJlIHRoYXQgd2UgYWltIHRvIGZp dCBhIG1pbmltYWwgKGJ1dCBjb21wbGlhbnQpDQo+IGZvcm1hdA0KPiBvZiB0aGUgbWFuaWZlc3Qg d2l0aGluIDI1NmJ5dGVzLg0KDQpUaGUgZGVmYXVsdCBzaXplIG9mIHRoZSBtYW5pZmVzdCBpcyA8 IDUxMiBieXRlcywgaG93ZXZlciBpdCBpcyBhIGJpdCBkaWZmZXJlbnQgdGhhbiB0aGUgUklPVCBt ZXRhZGF0YSBoZWFkZXIuIEluIGFkZGl0aW9uIHRvIHRoZSBjb250ZW50cyBvZiB0aGUgUklPVCBo ZWFkZXIsIHRoZSBtYW5pZmVzdCBpbmNsdWRlczoNCi0gdmVuZG9yIGFuZCBtb2RlbCBpZGVudGlm aWVycyB0byBwcmV2ZW50IGluc3RhbGxhdGlvbiBvZiBmaXJtd2FyZSBvbiB0aGUgd3JvbmcgZGV2 aWNlLiBUaGVzZSBhcmUgYWxzbyB1c2VkIHRvIGFsbG93IGEgZGV2aWNlIG1hbmFnZXIgdG8gaWRl bnRpZnkgdGhlIHByb3ZlbmFuY2Ugb2YgYW4gdXBkYXRlLg0KLSBhIGRpZ2VzdCBpZGVudGlmaWVy IHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBkaWdlc3QgYWxnb3JpdGhtDQotIGEgVVJJIHRv IGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiB0aGUgZGlzdHJpYnV0aW9uIG9mIHRoZSBmaXJtd2Fy ZSBpdHNlbGYgKHNlZSBjb21tZW50cyBhYm92ZSkNCi0gYSBub25jZSB0byBwcm90ZWN0IHRoZSBz aWduYXR1cmUgYWxnb3JpdGhtDQotIGEgc3RvcmFnZSBpZGVudGlmaWVyIHRvIGFsbG93IHRoZSB0 YXJnZXQgZGV2aWNlIHRvIGRlY2lkZSB3aGVyZSB0byBzdG9yZSB0aGUgcGF5bG9hZCBpbiBhIHN5 c3RlbSB0aGF0IHVzZXMgbW9yZSB0aGFuIG9uZSBhcmVhIG9mIGZpcm13YXJlIChmb3IgZXhhbXBs ZSBpZiB0aGUgbmV0d29yayBzdGFjayBpcyB1cGRhdGVkIGluZGVwZW5kZW50IG9mIG90aGVyIGNv bXBvbmVudHMpLiBUaGlzIGlzIHJvdWdobHkgZXF1aXZhbGVudCB0byBzdGFydF9hZGRyDQotIGEg Zm9ybWF0IHNwZWNpZmllciB0byBhbGxvdyBmb3IgbW9yZSBhZHZhbmNlZCB1cGRhdGUgc2NoZW1l cyBzdWNoIGFzIGNvbXByZXNzZWQgaW1hZ2VzDQotIGEgdGltZXN0YW1wIGZvciByb2xsYmFjayBw cm90ZWN0aW9uDQoNCkluIGFkZGl0aW9uLCBpdCB1c2VzIENNUyBmb3IgcHJvdmluZyB0aGUgYXV0 aGVudGljaXR5IGFuZCBpbnRlZ3JpdHkgb2YgdGhlIG1hbmlmZXN0LiBJbiB0aGUgbW9kZSB3ZSBo YXZlIHNlbGVjdGVkLCB0aGlzIGluY2x1ZGVzIHNldmVyYWwgYWRkaXRpb25hbCBPSURzIGFuZCBh biBhZGRpdGlvbmFsIGhhc2guDQoNCk1hbmlmZXN0cyBhcmUgYXBwcm94aW1hdGVseSA0MjAgYnl0 ZXMgd2l0aCB0aGVzZSBmZWF0dXJlcywgZXhjZXB0IHVzaW5nIGEgdHJpdmlhbCBzdG9yYWdlIGlk ZW50aWZpZXIgYW5kIG5vIHJlZmVyZW5jZSBVUkkuDQoNCklmIHRoZXNlIHZhbHVlcyBhcmUgbm90 IGluY2x1ZGVkIGluIHRoZSBtYW5pZmVzdCwgdGhlIHN5c3RlbSBtdXN0IGltcGx5IHRoZW0gaW4g c29tZSB3YXksIGVpdGhlciBieSBiZWluZyBhc3N1bWVkIG9yIGJ5IGJlaW5nIGhhcmQtY29kZWQu IFRoZXJlZm9yZSwgSSBiZWxpZXZlIHRoYXQgdGhlc2UgZmVhdHVyZXMgYXJlIG5lY2Vzc2FyeSBm b3IgdGhlIG1hbmlmZXN0IHRvIGFwcGx5IGJyb2FkbHkgdG8gSW9UIGRldmljZXMuDQoNCj4gIyBJ biBzZWN0aW9uIDMuMQ0KPg0KPiB0aW1lc3RhbXA6DQo+IElmIHdlIHdhbnQgdG8gY292ZXIgdGhl IGNhc2VzIHdoZW4gdGhlIGRldmljZSBoYXMgbm8gbm90aW9uIG9mICJub3ciLA0KPiAoaS5lLiBp cyBub3QgdGltZS1zeW5jaHJvbml6ZWQgd2l0aCB0aGUgYXV0aG9yL3NlcnZlci9zdG9yYWdlKQ0K PiB0aGUgZGV2aWNlIHdpbGwgb25seSBiZSBhYmxlIHRvIGludGVycHJldCB0aGlzIGZpZWxkIGFz IHNvbWUga2luZCBvZg0KPiBzZXF1ZW5jZSBudW1iZXIuIFRoaXMgZG9lcyBub3QgYnJpbmdpbmcg bXVjaCBtb3JlIGluZm9ybWF0aW9uIGNvbXBhcmVkIHRvDQo+IHRoZSB2ZXJzaW9uIG51bWJlciBm aWVsZC4NCj4gSW4gcGFydGljdWxhciwgSSdtIHdvbmRlcmluZyB3aHkgdGhlIHRpbWVzdGFtcCBh Y3R1YWxseSBwcm90ZWN0cyBmcm9tDQo+IGRvd25ncmFkZSBhdHRhY2tzOg0KPiBJIHN1cHBvc2Ug d2UgdHJ1c3QgdGhhdCBuZXdlciBzb2Z0d2FyZSB3aWxsIGhhdmUgbmV3ZXIgdmVyc2lvbiBudW1i ZXJzLg0KPiBJcyBpdCB0byBjb3ZlciB0aGUgY2FzZSB3aGVuIHRoZSB2ZXJzaW9uIG51bWJlciAi d3JhcHMgYXJvdW5kIj8NCg0KVGhlIHRpbWVzdGFtcCBpcyBlZmZlY3RpdmVseSBhIHNlcXVlbmNl IG51bWJlciBmb3IgdGhlIG1hbmlmZXN0LCBob3dldmVyLCBpdCBpcyBpbnRlbmRlZCB0byB3b3Jr IHdpdGggYSBtaW5pbXVtIG9mIGNoYW5jZXMgb2YgZXJyb3IuIElmIHNldmVyYWwgZmlybXdhcmUg YXV0aG9ycyB0YWtlIHR1cm5zIGlzc3VpbmcgbmV3IGZpcm13YXJlIGZvciBkZXZpY2VzLCB0aGVy ZSBpcyBhIGNoYW5jZSBmb3IgZXJyb3JzIHdoZW4gc2VsZWN0aW5nIHRoZSBjb3JyZWN0IHNlcXVl bmNlIG51bWJlciBkdWUgdG8gdGhlIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIGRpZmZlcmVudCBhY3Rv cnMuIFRoaXMgaXMgZXZlbiBtb3JlIHByb2JsZW1hdGljIHdoZW4gYSBuZXcgbWFuaWZlc3QgbXVz dCBiZSBpc3N1ZWQgZm9yIGFuIG9sZCBmaXJtd2FyZSAodGhlIHBlcm1pdHRlZCBmb3JtIG9mIHJv bGxiYWNrKS4gVGltZXN0YW1wcywgaG93ZXZlciwgYXJlIG1vbm90b25pY2FsbHkgaW5jcmVhc2lu ZyBhbmQgZ2xvYmFsbHkgc3luY2hyb25pemVkLg0KDQpXaGlsZSB0aGlzIGNvdWxkIGJlIGltcGxl bWVudGVkIGFub3RoZXIgd2F5LCB3aXRoIHVzZXItZGVmaW5lZCBzZXF1ZW5jZSBudW1iZXJzLCB0 aW1lc3RhbXBzIG1ha2UgaXQgZWFzeSB0byBnZXQgdGhlIHNlcXVlbmNlIG51bWJlciByaWdodCBh bmQgaGFyZCB0byBnZXQgaXQgd3JvbmcuIFRoZXkgYWxzbyBwcm92aWRlIGV4dHJhIGZlYXR1cmVz IGluIHN5c3RlbXMgdGhhdCBkbyBoYXZlIGEgY29uY2VwdCBvZiBsb2NhbCB0aW1lLg0KDQo+ICMg SW4gc2VjdGlvbiAzLjINCj4NCj4gSSB3b3VsZCBzdWdnZXN0IHdlIGFkZCB0aGUgZm9ybWF0IHR5 cGUgInNjcmlwdCIuDQo+IFdlIGhhdmUgdXNlIGNhc2VzIHdoZXJlIG1vZHVsZXMgbWlnaHQgYmUg c2NyaXB0cy4NCg0KSSdtIGhhcHB5IHRvIGFkZCBuZXcgZm9ybWF0IHR5cGVzLCBob3dldmVyICJz Y3JpcHQiIGlzIG5vdCBzcGVjaWZpYyBlbm91Z2ggd2l0aG91dCBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uLiBJIHN1Z2dlc3QgdGhhdCB3ZSBhbWVuZCB0aGUgZm9ybWF0IGFzIGZvbGxvd3M6DQoNCkZv cm1hdElkZW50aWZpZXIgOjo9IFNFUVVFTkNFIHsNCiAgIGZvcm1hdCAgICAgICAgICBDSE9JQ0Ug ew0KICAgICAgIGVudW0gICAgICAgIEVOVU1FUkFURUQgew0KICAgICAgICAgICByYXdCaW5hcnko MSksIGhleExvY2F0aW9uTGVuZ3RoRGF0YSgyKSwgZWxmKDMpLCBic2RpZmYoNCkNCiAgICAgICB9 LA0KICAgICAgIG9iamVjdElkICAgIE9CSkVDVCBJREVOVElGSUVSDQogICB9LA0KICAgcGFyYW1l dGVycyBBTlkgREVGSU5FRCBCWSBmb3JtYXQgT1BUSU9OQUwNCn0NCg0KUGF5bG9hZEluZm8gOjo9 IFNFUVVFTkNFIHsNCiAgIGZvcm1hdElkICAgICAgRm9ybWF0SWRlbnRpZmllciwNCiAgIGVuY3J5 cHRpb25JbmZvIEVuY3J5cHRpb25JbmZvIE9QVElPTkFMLA0KICAgc3RvcmFnZUlkZW50aWZpZXIg T0NURVQgU1RSSU5HLA0KICAgc2l6ZSBJTlRFR0VSLA0KICAgcGF5bG9hZCBDSE9JQ0Ugew0KICAg ICAgIHJlZmVyZW5jZSAgICBSZXNvdXJjZVJlZmVyZW5jZSwNCiAgICAgICBpbnRlZ3JhdGVkICAg T0NURVQgU1RSSU5HDQogICB9DQp9DQoNClRoaXMgd291bGQgYWxsb3cgInNjcmlwdCIgdG8gYmUg ZGVzY3JpcHRpdmUgYnkgYWRkaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW4gdGhlIHBhcmFt ZXRlcnMgc2VjdGlvbi4NCg0KPiBub25jZToNCj4gSSdtIG5vdCBzdXJlIHRoZSBjYXNlIG9mICJw cm9kdWNpbmcgbWFuaWZlc3RzIHRvbyBxdWlja2x5IiB3aXRoIHRoZSBzYW1lDQo+IHRpbWUtc3Rh bXANCj4gaXMgcmVhbGlzdGljLg0KPiBFdmVuIGlmIGl0IHdhcywgc2luY2UgYSBub25jZSBpcyBy YW5kb20sIHRoZSBub25jZSB3b3VsZCBub3QgaGVscCB0byBkZWNpZGUNCj4gd2hpY2gNCj4gZmly bXdhcmUgaXMgbmV3ZXIuDQo+IEhvd2V2ZXIsIHdlIGNvdWxkIGFzc3VtZSB0aGF0IHRoZSB2ZXJz aW9uIG51bWJlciB3b3VsZCBiZSBsZXhpY29ncmFwaGljYWxseQ0KPiBncmVhdGVyDQo+IGluIHRo ZSBuZXdlc3QgZmlybXdhcmUuDQo+IEhlbmNlLCBJIGFtIHVuc3VyZSB3aGF0IGlzIHRoZSBmdW5j dGlvbiBvZiB0aGUgbm9uY2UuDQoNClRoZSBwdXJwb3NlIG9mIHRoZSBub25jZSBpcyB0byBlbnN1 cmUgdGhhdCB0aGUgc2FtZSBkYXRhIGlzIG5ldmVyIHNpZ25lZCB0d2ljZS4gVGhpcyBwcm90ZWN0 cyB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobSBmcm9tIHNvbWUgY2xhc3NlcyBvZiBhdHRhY2suIE9u IG1vZGVybiBoYXJkd2FyZSwgaXQncyBxdWl0ZSBlYXN5IHRvIGdlbmVyYXRlIG1hbnkgbWFuaWZl c3RzIGluIGEgc2Vjb25kLCBzbyB0aGUgdGltZXN0YW1wIGlzIGluc3VmZmljaWVudCB0byBndWFy ZCBhZ2FpbnN0IG11bHRpcGxlIHNpZ25hdHVyZXMgb2YgdGhlIHNhbWUgZGF0YS4NCg0KPiBzdG9y YWdlSWRlbnRpZmllcjoNCj4gYXMgcGVyIG15IGNvbW1lbnRzIHRvIHRoZSBhcmNoaXRlY3R1cmUg ZHJhZnQsIEkgc3VnZ2VzdCB3ZSBmb2N1cyBmaXJzdCBvbg0KPiB0aGUgY2FzZQ0KPiB3aGVyZSB0 aGVyZSBpcyBvbmx5IG9uZSBNQ1UuDQo+IFNob3VsZCB0aGlzIGZpZWxkIGJlIG9wdGlvbmFsPw0K DQpUaGUgYmVoYXZpb3VyIG9mIHN0b3JhZ2VJZGVudGlmaWVyIGlzIGFwcGxpY2F0aW9uLXNwZWNp ZmljLiBJdCBjYW4gYmUgdXNlZCB0byBkZXNpZ25hdGU6IGEgZmlybXdhcmUgbW9kdWxlIGluIGEg bXVsdGktbW9kdWxlIHN5c3RlbSwgZm9yIGV4YW1wbGUgYSBib290bG9hZGVyLCB2cy4gYSBtYWlu IGFwcGxpY2F0aW9uLiBJdCBjYW4gYmUgdXNlZCB0byBkZXNpZ25hdGUgYSBwYXJ0aWN1bGFyIHBy b2Nlc3NvciBpbiBhIG11bHRpLXByb2Nlc3NvciBhcHBsaWNhdGlvbi4gVGhlIGludGVycHJldGF0 aW9uIG9mIHRoZSBzdG9yYWdlIGlkZW50aWZpZXIgaXMgZW50aXJlbHkgdXAgdG8gdGhlIGFwcGxp Y2F0aW9uLiBUaGlzIG1lYW5zIHRoYXQgaXQgY2FuIGV2ZW4gcmVwcmVzZW50IHRoZSBzdGFydCBh ZGRyZXNzIGlmIHRoYXQgaXMgZGVzaXJlZC4NCg0KPiAjIEluIHNlY3Rpb24gMy4zDQo+DQo+ICJB cHBseSBhbiB1cGRhdGUgb25seSB0byBkZXZpY2VzIHRoYXQgbWF0Y2ggdGhlIHZlbmRvcklkLCBj bGFzc0lkLCBkZXZpY2VJZA0KPiBhdHRyaWJ1dGVzIg0KPiBpcyB0aGlzIGNvbmRpdGlvbiBub3Qg bmVjZXNzYXJ5IGluIGFsbCBjYXNlcz8NCg0KVGhpcyB3YXMgYSBjb21wb3VuZCBjb25kaXRpb24u IFRoZXJlIGFyZSBzaXR1YXRpb25zIHdoZXJlIHlvdSBtYXkgd2FudCB0byBhcHBseSBhbiB1cGRh dGUgb25seSB3aXRoIGEgbWF0Y2hpbmcgZGV2aWNlSWQsIHRoZXJlIGFyZSBhbHNvIHNpdHVhdGlv bnMgd2hlcmUgeW91IG1pZ2h0IHdhbnQgdG8gYXBwbHkgYW4gdXBkYXRlIHRvIGEgbWF0Y2hpbmcg dmVuZG9ySWQgYW5kIGNsYXNzSWQsIGJ1dCB0byBtYW55IGRldmljZXMuIFNvLCB2ZW5kb3JJZCBh bmQgY2xhc3NJZCBtaWdodCBiZSBjb25zaWRlcmVkIHRvIGJlIGFsd2F5cyBtYW5kYXRvcnksIGhv d2V2ZXIsIGRldmljZUlkIGlzIG9wdGlvbmFsLiBIb3dldmVyLCBJIGRpc2xpa2UgZ2l2aW5nIHZl bmRvcklkIGFuZCBjbGFzc0lkIHRoZWlyIG93biBkZWRpY2F0ZWQgZW50cmllcywgYmVjYXVzZSBp dCBtYWtlcyB0aGUgZm9ybWF0IG1vcmUgY29tcGxleCB0byBwYXJzZSBhbmQgcHJvY2Vzcy4gSGF2 aW5nIHZlbmRvcklkIGFuZCBjbGFzc0lkIGluIHRoZSBjb25kaXRpb25zIHNlZW1zIGNsZWFuZXIu DQoNCj4gQ29uZGl0aW9ucyBvbiBhYnNvbHV0ZSB0aW1lOg0KPiBzZWUgbXkgYWJvdmUgY29tbWVu dHMgb24gYWJzb2x1dGUgdGltZSwgYW5kIHRpbWUgc3luY2hyb25pemF0aW9uDQo+IHJlcXVpcmVt ZW50cyB0aGF0IG1pZ2h0DQo+IG5vdCBiZSBtZXQgaW4gbG93LWVuZCBJb1QgZGV2aWNlcy4NCg0K WWVzLCB0aGlzIG1heSBiZSBhIHByb2JsZW0uIFByZXN1bWFibHksIHN1Y2ggYSBkZXZpY2UgY291 bGQgcmVwb3J0IGFuICJ1bmltcGxlbWVudGVkIGZlYXR1cmUiIGVycm9yLCBldGMuIEF1dGhvcnMg b2YgdXBkYXRlcyBuZWVkIHRvIGJlIHN1cmUgdGhhdCB0aGV5IGRvbid0IHVzZSBmZWF0dXJlcyB0 aGF0IGFyZW4ndCBpbXBsZW1lbnRlZCBvbiB0aGVpciB0YXJnZXRzLiBUaGlzIHdpbGwgY2F1c2Ug YSBmYWlsdXJlLCBidXQgdGhpcyBzaG91bGQgYmUgYSBncmFjZWZ1bCBmYWlsdXJlLCBzaW5jZSBh IGRldmljZSB3aWxsIGNvbnRpbnVlIHRvIG9wZXJhdGUgdW5oaW5kZXJlZCBpbiB0aGUgYXJjaGl0 ZWN0dXJlIGRlc2NyaWJlZC4NCg0KPiAjIEluIHNlY3Rpb24gMy40DQo+DQo+IEhlcmUgYWdhaW4g SSBwcm9wb3NlIHRvIGZvY3VzIG9uIHNpbmdsZSBNQ1UgY2FzZXMgZmlyc3QuDQoNCk11bHRpcGxl IGZpcm13YXJlIGltYWdlcyBkb2VzIG5vdCBuZWNlc3NhcmlseSBpbXBseSBtdWx0aXBsZSBNQ1Vz LiBUaGVyZSBtYXkgYmUgbXVsdGlwbGUgZmlybXdhcmUgaW1hZ2VzIG9uIGEgc2luZ2xlIGRldmlj ZS4gRm9yIGV4YW1wbGUsIGEgZGV2aWNlIHdpdGggYW4gaW50ZWdyYXRlZCBjcnlwdG9ncmFwaGlj IGFjY2VsZXJhdG9yIG1heSByZXF1aXJlIGEgc2VwYXJhdGUgaW1hZ2UgdG8gdXBkYXRlIHRoYXQg YWNjZWxlcmF0b3IuIExpa2V3aXNlLCB0aGVyZSBhcmUgV2lGaSBJb1QgZGV2aWNlcyB0aGF0IGRv d25sb2FkIGEgZmlybXdhcmUgaW1hZ2UgdG8gdGhlIFdpRmkgY2hpcCBvdmVyIFNESU8gb24gZXZl cnkgYm9vdC4gVGhlc2UgY291bGQgYmUgZGlzdHJpYnV0ZWQgYXMgc2VwYXJhdGUgaW1hZ2VzLCBk ZXNwaXRlIGJlaW5nIGhvc3RlZCBvbiBhIHNpbmdsZSBNQ1UuDQoNCj4gIyBJbiBzZWN0aW9uIDMu NS4yDQo+DQo+IG1ha2UgaXQgb3B0aW9uYWw/DQoNClRoaXMgY2Fubm90IGJlIG9wdGlvbmFsIGJl Y2F1c2UgaXQgaXMgdXNlZCBieSBkZXZpY2VzIHRvIG1hdGNoIGluY29taW5nIG1hbmlmZXN0cyB0 byB0aGVpciBoYXJkd2FyZS4NCg0KPiAjIEluIHNlY3Rpb24gNC4NCj4NCj4gRG8geW91IGhhdmUg YW4gZXN0aW1hdGUgYXMgaG93IG1hbnkgYnl0ZXMgdGhpcyBpcyBvdmVyIHRoZSBhaXIgZm9yIHRo ZQ0KPiBtYW5pZmVzdD8NCg0KVGhlIERFUi1lbmNvZGVkIG1hbmlmZXN0IGlzIGdlbmVyYWxseSBs ZXNzIHRoYW4gNTEyIGJ5dGVzLiBUaGlzIGNhbiB2YXJ5LCBkZXBlbmRpbmcgb24gY29udGVudC4g SWYgYSBjZXJ0aWZpY2F0ZSBpcyBpbmNsdWRlZCwgdGhhdCB3aWxsIGluY3JlYXNlIHRoZSBzaXpl LiBGb3Igc2VjcDI1NnIxIGN1cnZlcywgYSBjZXJ0aWZpY2F0ZSBpcyBhcHByb3hpbWF0ZWx5IDY1 MCBieXRlcy4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9y IGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg==