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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2017 16:51:10 +0200

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 <[email-masked]> 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
>     >> [email-masked] https://www.ietf.org/mailman/listinfo/fud
>     >>
> 
>     > _______________________________________________ Fud mailing list
>     > [email-masked] https://www.ietf.org/mailman/listinfo/fud
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Fud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fud
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Sep 2017 15:59:01 -0400

> too much policy for the device to consider. While this is not

I agree with you, and that's situation (b) that I described.

    >> As the device does not recognize X or Y, it would ignore those

The question is, can the signatures from X and Y *remain* for the purposes
of auditing?  Removing them then becomes an option, rather than a requirement.

---

From: Brendan Moran <[email-masked]>
Date: Wed, 13 Sep 2017 21:02:03 +0000

I think this comes down to a matter of configuration. Devices need to be configured to either:

  1.  require at least one signature to match
  2.  require all signatures to match

I don't see a reason not to support both modes of operation.

Brendan

________________________________
From: Fud <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Sent: Wednesday, September 13, 2017 8:59:01 PM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Fud] Comment on draft-moran-fud-manifest-00

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Thomas Eichinger" <[email-masked]>
Date: Tue, 19 Sep 2017 16:59:14 -0700

Hi Hannes,

First, I'm sorry for the massive latency.

I'd be ok with having it as an optional feature but maybe bound to an 
optional textual description.
Meaning if you provide a textual description also provide a machine 
readable classification or only a classification one or neither. What do 
you think?

Totally agree with you regarding certification and regulation. The 
proposed addition in my opinion just allows for a wider variety of 
update strategies while some others might just ignore it.

Best,
Thomas

On 22 Aug 2017, at 4:33 PDT(-0700), Hannes Tschofenig wrote:

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