Re: [Fud] Comment on draft-moran-fud-manifest-00

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 13 September 2017 14:51 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 16FA2132DFB for <fud@ietfa.amsl.com>; Wed, 13 Sep 2017 07:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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, 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 NXPE0QMuV017 for <fud@ietfa.amsl.com>; Wed, 13 Sep 2017 07:51:17 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 B2377132949 for <fud@ietf.org>; Wed, 13 Sep 2017 07:51:16 -0700 (PDT)
Received: from [192.168.91.203] ([131.111.5.143]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M9Jss-1dipsX2cyU-00Cm7h; Wed, 13 Sep 2017 16:51:11 +0200
To: Michael Richardson <mcr+ietf@sandelman.ca>, fud@ietf.org
References: <C64FB690-1EB9-46A0-989F-DAC57E1CA819@riot-os.org> <eb247364-e4d6-1c22-c882-0e53df6c2902@gmx.net> <525.1503422326@dooku.sandelman.ca>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <3d78ce15-553e-2423-3185-95e789fca3d5@gmx.net>
Date: Wed, 13 Sep 2017 16:51:10 +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: <525.1503422326@dooku.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:FCQ4WhQE+EmuVJP4kBwnYExhXe7ilMcIBVHzpIKlBWnSBcdOVaa 9DwiZJl04Pn56Vo0z7r9d47YG2JNfU9Snf1toOCsN7rrbRimmsugt3FLclYc8l3lJABmGSp ju5WGjf1DpGXjjxPRZaxBwc0z/YyvKgMerEyl/pss0OJ83+PD5JRw/7s6PxCckHvQopcE4T wJ1lotq4PgPBWVF2Ya4kA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ofsMZusZHpM=:lKPcTjwrON5g0OZZHPwJ6i THH7ljA0DFLVYyojSo90KzVc8eFUHXXmPSleD41t4W2YkVC5Ntq5zwy+MCFcR4+lree2sToVP IUKi7BYSwXC05N7kDnJM5mV/NLgKP47lg6mT4NDhUsBTn6caEBWHZfbg70WNVrVJzl/ZI2E59 0EL97O5BUjSCKU3W/MdbLTEU55G45+O1zbqROqRXEnQkek0sinb1rnonl8bgtHQAdtrf+tMPO lWohy5NQv1bt/HJpY3OuPbpMVfrLBAMivDVi/JcAsw+LlqdY7/528me6okq5bKpKXtFfnd/K6 VCiLTHbTyZ6Lt3qo8/HzxM3xROx1iw7iSZHuCdAOqCnTEd6LHCgtmklkROg8GRAZro6/33xm0 yXROsRGTthBzm04Lrz0Yod107D3zKXMLjoQSlHwRldIxdcHhTUXZ7nPA3/RbPOsJj6DHSzFPL 9HShwIEnnKz+k5yTHwropxULWux8RQQK9ofjCsBqdIGBG/v2FjiHZH/KYXKemQAM+33KtT4oR /MpFkoMiu2Ujp30/sUxhL/7vtgDha10JnNIWeDJmzEJCv28MmMa9fLAVNeiQe3AXldQ6tksOF Rwlr9+lqmt8Mq8u0mBpObBGKgGeA0tyj8wCNtssipOCvqD3vtf7qfV+d/217i5CNkIRF8PklQ JYtFBmLA/AQHirnysWRve5TAY3tu9BjCgFLg5VKa8+CM7MrB9xb78E65EHG0WYXV3zhNWrRAq 5C2QUITVl/9p/T9VZLy05FIl3Uk3gL8dAJnXRXk+q4dk2I3YwskLQR+pS3K6buHVSXxqQdTj9 KpWg6Z95kR1yy6EHt3H/I4Xw3Ju6yGiRvYFoUiR4ig44om9BQg=
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/rYF2_l_wtxQejRwj2C9_GakRFHw>
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 <fud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fud>, <mailto:fud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fud/>
List-Post: <mailto:fud@ietf.org>
List-Help: <mailto:fud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fud>, <mailto:fud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Sep 2017 14:51:24 -0000

Hi Michael,

here is my take on this issue: I don't think that the idea of having
multiple parties sign the manifest so that the device can check all the
signatures in order to decide whether the vendor, enterprise operator,
and regulator "agreed" on deploying a specific firmware update for a
medical device. I think that this is a too heavy for an IoT device and
too much policy for the device to consider. While this is not impossible
to do (even with the proposed manifest format) I believe it is more
likely that the party providing the firmware update to the IoT device
will make that policy decision (which will typically involve humans).

Hence, I think we need to make sure that the common case works well. If
someone wants to do research on the other option that's fine for me as
well.

Ciao
Hannes


On 08/22/2017 07:18 PM, Michael Richardson wrote:
> 
> Hannes Tschofenig <hannes.tschofenig@gmx.net> 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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Fud mailing list
> Fud@ietf.org
> https://www.ietf.org/mailman/listinfo/fud
>