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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 22 August 2017 17:19 UTC

Return-Path: <mcr@sandelman.ca>
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 <fud@ietfa.amsl.com>; 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 <fud@ietfa.amsl.com>; 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 <fud@ietf.org>; 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 <fud@ietf.org>; 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 <mcr+ietf@sandelman.ca>
To: fud@ietf.org
In-reply-to: <eb247364-e4d6-1c22-c882-0e53df6c2902@gmx.net>
References: <C64FB690-1EB9-46A0-989F-DAC57E1CA819@riot-os.org> <eb247364-e4d6-1c22-c882-0e53df6c2902@gmx.net>
Comments: In-reply-to Hannes Tschofenig <hannes.tschofenig@gmx.net> 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: <https://mailarchive.ietf.org/arch/msg/fud/fbK1geZYbkR9SN7u6rKsmirgGI8>
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: Tue, 22 Aug 2017 17:19:16 -0000

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 =-