Subject: [Suit] Make it clear that end-users MUST be able to NOT update

From: "David A. Wheeler" <[email-masked]>
Date: Wed, 15 Nov 2017 12:16:11 -0500 (EST)

I think a vitally-important requirement is that end-users MUST be able to NOT update software.

In many cases, it's valuable to automatically update software, and
internet-connected devices make that relatively easy.

But there are many situations where updates must NOT occur.
There's a disturbing trend where people who own the devices are
increasingly not allowed to control them.  In the end, the end-user/owner
should be able to decide if updates are acceptable, and when.

Thanks.

--- David A. Wheeler

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 16 Nov 2017 05:57:00 +0800

Hi David, all,

this is a really good point... but I think there might be some 
considerations that could complicate this view. For example, what are 
the considerations about the fact that if you decide not to upgrade 
(BTW, the majority of people who owns IoT would probably not even know 
what a firmware upgrade is...) and your device gets hacked and used to 
participate in botnets or to attack other devices in your own home 
network ? Even if the light bulb that was compromised does not have 
access/collect sensitive information per se, other devices connected to 
your network might. To make it all more scary, think about when you have 
some medical devices that are connected to your network (e.g., patient 
monitoring, etc.) that might be targeted via smaller / not updated 
devices...

IMHO, one of the biggest fears in IoTs is that this large number of 
devices with (most of the time) IP capabilities can be really dangerous 
because they can be used as botnet and gateways to deploy more 
sophisticated attacks. If we do not mandate for automatic upgrades that 
would (besides functional upgrades) fix security issues, the situation 
might be quite eerie.

This said, I am a big fan of the user to be (rightfully so!) in control 
of her own devices... so, what do we do ?

I do not really have an answer for this, but there might be the 
possibility do distinguish between devices that have User Interfaces 
(UIs) that the user can use to accept or deny updates and devices that 
do not.

Another aspect to consider is usability. In particular, how annoyed 
would you be if you had to accept/reject updates for all your 
home-installed IoTs (20 light bulbs) or, even worst, for all your 
work-installed IoTs (50k smart light bulbs) ?

If we take, for example, the situation today with OS updates/upgrades, 
we see that the vast vast vast majority of installations do leverage the 
deployment of automatic updates nevertheless the possibility for the 
user to opt-out.

Maybe a possible solution to this dichotomy would be to suggest using an 
update-by-default policies and for devices that might have a UI (or a 
controller that can more easily interact with the user) to provide the 
possibility to (a) follow the same policy by accepting automatic 
updates, or (b) allow the user to confirm/reject every update, or (c) 
allow the user to automatically reject (dangerous) any updates.

What do you think ?

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Thomas Eichinger <[email-masked]>
Date: Wed, 15 Nov 2017 14:11:24 -0800

Hi Max,

An earlier comment of mine was that updates should clearly be marked as security or feature updates (more fine grained differentiation would be possible) and ideally both should be mutually exclusive. 

This way, with the proper management tools at hand, a user can decide to still allow security updates being deployed automatically while being able to review others before consenting to install the updates. 

Best, 
Thomas 

> On Nov 15, 2017, at 1:57 PM, Dr. Pala <[email-masked]> wrote:
> 
> Hi David, all,
> 
> this is a really good point... but I think there might be some considerations that could complicate this view. For example, what are the considerations about the fact that if you decide not to upgrade (BTW, the majority of people who owns IoT would probably not even know what a firmware upgrade is...) and your device gets hacked and used to participate in botnets or to attack other devices in your own home network ? Even if the light bulb that was compromised does not have access/collect sensitive information per se, other devices connected to your network might. To make it all more scary, think about when you have some medical devices that are connected to your network (e.g., patient monitoring, etc.) that might be targeted via smaller / not updated devices...
> IMHO, one of the biggest fears in IoTs is that this large number of devices with (most of the time) IP capabilities can be really dangerous because they can be used as botnet and gateways to deploy more sophisticated attacks. If we do not mandate for automatic upgrades that would (besides functional upgrades) fix security issues, the situation might be quite eerie.
> This said, I am a big fan of the user to be (rightfully so!) in control of her own devices... so, what do we do ?
> 
> I do not really have an answer for this, but there might be the possibility do distinguish between devices that have User Interfaces (UIs) that the user can use to accept or deny updates and devices that do not.
> 
> Another aspect to consider is usability. In particular, how annoyed would you be if you had to accept/reject updates for all your home-installed IoTs (20 light bulbs) or, even worst, for all your work-installed IoTs (50k smart light bulbs) ?
> If we take, for example, the situation today with OS updates/upgrades, we see that the vast vast vast majority of installations do leverage the deployment of automatic updates nevertheless the possibility for the user to opt-out.
> 
> Maybe a possible solution to this dichotomy would be to suggest using an update-by-default policies and for devices that might have a UI (or a controller that can more easily interact with the user) to provide the possibility to (a) follow the same policy by accepting automatic updates, or (b) allow the user to confirm/reject every update, or (c) allow the user to automatically reject (dangerous) any updates.
> 
> What do you think ?
> 
> Cheers,
> Max
> 
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Justin Cappos <[email-masked]>
Date: Wed, 15 Nov 2017 17:24:34 -0500

What about a model where you can elect to either choose to manage the
application of updates yourself or let it be managed by the manufacturer?

It seems the consumer is in the best position to choose and understand what
works best for them.

Justin

On Wed, Nov 15, 2017 at 5:11 PM, Thomas Eichinger <[email-masked]>
wrote:

> Hi Max,
>
> An earlier comment of mine was that updates should clearly be marked as
> security or feature updates (more fine grained differentiation would be
> possible) and ideally both should be mutually exclusive.
>
> This way, with the proper management tools at hand, a user can decide to
> still allow security updates being deployed automatically while being able
> to review others before consenting to install the updates.
>
> Best,
> Thomas
>
> considerations that could complicate this view. For example, what are the
> considerations about the fact that if you decide not to upgrade (BTW, the
> majority of people who owns IoT would probably not even know what a
> firmware upgrade is...) and your device gets hacked and used to participate
> in botnets or to attack other devices in your own home network ? Even if
> the light bulb that was compromised does not have access/collect sensitive
> information per se, other devices connected to your network might. To make
> it all more scary, think about when you have some medical devices that are
> connected to your network (e.g., patient monitoring, etc.) that might be
> targeted via smaller / not updated devices...
>
> possibility do distinguish between devices that have User Interfaces (UIs)
> that the user can use to accept or deny updates and devices that do not.
>
> Another aspect to consider is usability. In particular, how annoyed would
> you be if you had to accept/reject updates for all your home-installed IoTs
> (20 light bulbs) or, even worst, for all your work-installed IoTs (50k
> smart light bulbs) ?
>
> If we take, for example, the situation today with OS updates/upgrades, we
> see that the vast vast vast majority of installations do leverage the
> deployment of automatic updates nevertheless the possibility for the user
> to opt-out.
>
> possibility to (a) follow the same policy by accepting automatic updates,
> or (b) allow the user to confirm/reject every update, or (c) allow the user
> to automatically reject (dangerous) any updates.
>
> What do you think ?
>
> Cheers,
> Max
>

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 16 Nov 2017 06:30:19 +0800

Hi Thomas,

initially I was thinking something along those same lines, but my 
personal experience with manufacturer/vendors (M/F) is that even that 
level of sophistication might be a bit too much if we go all the way 
down to security vs. feature (or more fine grained) differentiation.

Maybe a possible solution would be to have some flags that mark the 
update as containing (but not in a mutually exclusively fashion) a 
security-related fix indicator (i.e., maybe a simple flag in the 
manifest ?). I would be supportive of that idea, but I think that 
something more complicated could hinder the adoption by M/F.

AFTER we manage to have a solution out there that is adopted and that 
IoTs M/F can build their experience on (and for this, I would stress the 
need to keep any initial proposal/solution as simple as possible... but 
not simpler :D), we might extend the model and propose optional features 
(that inevitably will complicate the whole lifetime and management of 
firmware updates) that build on top of the initial work.

Would do you think ? Would this be a good path ?

Cheers,
Max

On 11/16/17 6:11 AM, Thomas Eichinger wrote:
> Hi Max,
>
> An earlier comment of mine was that updates should clearly be marked 
> as security or feature updates (more fine grained differentiation 
> would be possible) and ideally both should be mutually exclusive.
>
> This way, with the proper management tools at hand, a user can decide 
> to still allow security updates being deployed automatically while 
> being able to review others before consenting to install the updates.
>
> Best,
> Thomas
>
> On Nov 15, 2017, at 1:57 PM, Dr. Pala <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi David, all,
>>
>> (BTW, the majority of people who owns IoT would probably not even 
>> know what a firmware upgrade is...) and your device gets hacked and 
>> used to participate in botnets or to attack other devices in your own 
>> home network ? Even if the light bulb that was compromised does not 
>> have access/collect sensitive information per se, other devices 
>> connected to your network might. To make it all more scary, think 
>> about when you have some medical devices that are connected to your 
>> network (e.g., patient monitoring, etc.) that might be targeted via 
>> smaller / not updated devices...
>>
>> devices with (most of the time) IP capabilities can be really 
>> dangerous because they can be used as botnet and gateways to deploy 
>> more sophisticated attacks. If we do not mandate for automatic 
>> upgrades that would (besides functional upgrades) fix security 
>> issues, the situation might be quite eerie.
>>
>> This said, I am a big fan of the user to be (rightfully so!) in 
>> control of her own devices... so, what do we do ?
>>
>> (UIs) that the user can use to accept or deny updates and devices 
>> that do not.
>>
>> If we take, for example, the situation today with OS 
>> updates/upgrades, we see that the vast vast vast majority of 
>> installations do leverage the deployment of automatic updates 
>> nevertheless the possibility for the user to opt-out.
>>
>> Maybe a possible solution to this dichotomy would be to suggest using 
>> an update-by-default policies and for devices that might have a UI 
>> (or a controller that can more easily interact with the user) to 
>> provide the possibility to (a) follow the same policy by accepting 
>> automatic updates, or (b) allow the user to confirm/reject every 
>> update, or (c) allow the user to automatically reject (dangerous) any 
>> updates.
>>
>> What do you think ?
>>
>> Cheers,
>> Max
>>
>>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 16 Nov 2017 00:47:41 +0100

It would be nice to have a solution layer that is independent of
the interfaces supported by the device. button... display/more-buttons,
audio, GUI, holo-projector,... there is just way too much diverstiy
to be fair in any solution if we assume a specific one. And most
devices will only have some four-digit number printed on the product
label as the only interface anyhow (in support of initial authentication
happening via some other interface and the cloud).

One way we could think about defining the update experience in an
IETF compatible and IMHO even (gasp!) useful way is to think
that every device has a "cloud-based" device management service.
The management service would include the aspects of interest to us,
eg: establish device ownership, review, observe, control upgrade/downgrade,
etc. pp.

We could then define this cloud device management service as a yang
model and say it must be supported via restconf. Then we would have a standard
interfac on which even third parties could build all type software
supporting te variety of possible HW interfaces mentined above. The
most simple example of course is that this would enable the
"one-fits-all" app for the usrs smartphone that allows it now to control
all the IoT devices in the home, because they are all controlled via
the same yang model based cloud interface.

On Thu, Nov 16, 2017 at 06:30:19AM +0800, Dr. Pala wrote:
> personal experience with manufacturer/vendors (M/F) is that even
> that level of sophistication might be a bit too much if we go all
> the way down to security vs. feature (or more fine grained)
> differentiation.
> 
> AFTER we manage to have a solution out there that is adopted and
> that IoTs M/F can build their experience on (and for this, I would
> stress the need to keep any initial proposal/solution as simple as
> possible... but not simpler :D), we might extend the model and
> propose optional features (that inevitably will complicate the whole
> lifetime and management of firmware updates) that build on top of
> the initial work.
> 
> >An earlier comment of mine was that updates should clearly be
> >marked as security or feature updates (more fine grained
> >differentiation would be possible) and ideally both should be
> >mutually exclusive.
> >
> >This way, with the proper management tools at hand, a user can
> >decide to still allow security updates being deployed
> >automatically while being able to review others before consenting
> >to install the updates.
> >
> >Best,
> >Thomas
> >
> >>considerations that could complicate this view. For example,
> >>what are the considerations about the fact that if you decide
> >>not to upgrade (BTW, the majority of people who owns IoT would
> >>probably not even know what a firmware upgrade is...) and your
> >>device gets hacked and used to participate in botnets or to
> >>attack other devices in your own home network ? Even if the
> >>light bulb that was compromised does not have access/collect
> >>sensitive information per se, other devices connected to your
> >>network might. To make it all more scary, think about when you
> >>have some medical devices that are connected to your network
> >>(e.g., patient monitoring, etc.) that might be targeted via
> >>IMHO, one of the biggest fears in IoTs is that this large number
> >>of devices with (most of the time) IP capabilities can be really
> >>dangerous because they can be used as botnet and gateways to
> >>deploy more sophisticated attacks. If we do not mandate for
> >>automatic upgrades that would (besides functional upgrades) fix
> >>security issues, the situation might be quite eerie.
> >>
> >>possibility do distinguish between devices that have User
> >>Interfaces (UIs) that the user can use to accept or deny updates
> >>and devices that do not.
> >>
> >>Another aspect to consider is usability. In particular, how
> >>annoyed would you be if you had to accept/reject updates for all
> >>your home-installed IoTs (20 light bulbs) or, even worst, for
> >>all your work-installed IoTs (50k smart light bulbs) ?
> >>
> >>Maybe a possible solution to this dichotomy would be to suggest
> >>using an update-by-default policies and for devices that might
> >>have a UI (or a controller that can more easily interact with
> >>the user) to provide the possibility to (a) follow the same
> >>policy by accepting automatic updates, or (b) allow the user to
> >>confirm/reject every update, or (c) allow the user to
> >>automatically reject (dangerous) any updates.
> >>
> >>What do you think ?
> >>
> >>Cheers,
> >>Max
> >>
> >>

-- 
---
[email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Thu, 16 Nov 2017 00:34:25 +0000

Requiring counter-signing is one example of a solution that has been discussed which meets that requirement.
In any case, I agree with the requirement, and it should be is a policy decision.

Dave

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of David A. Wheeler
Sent: Thursday, November 16, 2017 1:16 AM
To: suit <[email-masked]>
Subject: [Suit] Make it clear that end-users MUST be able to NOT update

In many cases, it's valuable to automatically update software, and internet-connected devices make that relatively easy.

But there are many situations where updates must NOT occur.
There's a disturbing trend where people who own the devices are increasingly not allowed to control them.  In the end, the end-user/owner should be able to decide if updates are acceptable, and when.

Thanks.

--- David A. Wheeler

_______________________________________________
Suit mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7C7153ee99229344e61f7308d52c4c962a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636463629807425511&sdata=OdzMgch34ZkkEpzVuXTdNGuDuUCcTXgylLoPo9MX7N4%3D&reserved=0

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Nov 2017 02:05:53 +0000

That's a fair requirement, David.

I do believe, however, that this is something that has no impact on a manifest format. Particularly in the IoT context it often happens that the end user is not sitting in the front of the device nor may the device even have a UI. So, the consent needs to happen to "outside" .

What is your view on how the consent could influence the manifest?

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of David A. Wheeler
Sent: 16 November 2017 01:16
To: suit
Subject: [Suit] Make it clear that end-users MUST be able to NOT update

Thanks.

--- David A. Wheeler

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit
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: Dave Thaler <[email-masked]>
Date: Thu, 16 Nov 2017 02:21:36 +0000

My opinion: the only requirement I can think of is that the manifest format has to support multiple signatures (countersigning)
so that one could have a policy based on them.

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, November 16, 2017 10:06 AM
To: David A. Wheeler <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] Make it clear that end-users MUST be able to NOT update

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of David A. Wheeler
Sent: 16 November 2017 01:16
To: suit
Subject: [Suit] Make it clear that end-users MUST be able to NOT update

Thanks.

--- David A. Wheeler

_______________________________________________
Suit mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7C7215b35bed3043c20b6508d52c96a230%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636463947840714659&sdata=Xjz9tS4yuuiB%2Bp39yKYM%2B%2B00y4oKNqyBB8ddeSp%2Fr3U%3D&reserved=0
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.

_______________________________________________
Suit mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7C7215b35bed3043c20b6508d52c96a230%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636463947840714659&sdata=Xjz9tS4yuuiB%2Bp39yKYM%2B%2B00y4oKNqyBB8ddeSp%2Fr3U%3D&reserved=0

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Nov 2017 03:08:55 +0000

That's perfectly fine for me, Dave. We need this also for other purposes.

However, I don't think it is realistic for end users to assume that they have a firmware signing certificate (+ private key) to sign firmware updates as a way to demonstrate consent for an update.

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]]
Sent: 16 November 2017 10:22
To: Hannes Tschofenig; David A. Wheeler; suit
Subject: RE: [Suit] Make it clear that end-users MUST be able to NOT update

My opinion: the only requirement I can think of is that the manifest format has to support multiple signatures (countersigning) so that one could have a policy based on them.

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, November 16, 2017 10:06 AM
To: David A. Wheeler <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] Make it clear that end-users MUST be able to NOT update

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of David A. Wheeler
Sent: 16 November 2017 01:16
To: suit
Subject: [Suit] Make it clear that end-users MUST be able to NOT update

Thanks.

--- David A. Wheeler

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 16 Nov 2017 11:26:49 +0800

Hi Hannes, David,

+1 to multiple signatures.

The use case I have in mind, however, is not for the user to 
counter-sign the firmware but for one or more additional "deployment" 
authority to "bless" the update for deployment in its environment. We 
already have this in the cable industry and I think it would be a good 
feature to have.

Cheers,
Max

---

From: Roderick Chapman <[email-masked]>
Date: Thu, 16 Nov 2017 07:09:45 +0000

On 15/11/2017 22:11, Thomas Eichinger wrote:
> as security or feature updates 

This doesn't really sound plausible to me.  If only it were that simple.

In deploying a new "feature", a developer might introduce a bunch of new,

previously unknown security-related defects, making the system

worse, not better.

If a developer tells me "this update fixes bugs but doesn't add any new 
bugs"

why on earth should I believe them?

  - Rod

---

From: Justin Cappos <[email-masked]>
Date: Thu, 16 Nov 2017 09:41:18 -0500

Max: If you use delegations, you can have the flexibility to cover this
case, multiple signatures, and many other features.  It seems likely to
cover more cases than trying to pre-define different roles which all
perform the same task.

Thanks,
Justin

On Wed, Nov 15, 2017 at 10:26 PM, Dr. Pala <[email-masked]> wrote:

> The use case I have in mind, however, is not for the user to counter-sign
> the firmware but for one or more additional "deployment" authority to
> "bless" the update for deployment in its environment. We already have this
> in the cable industry and I think it would be a good feature to have.
>
> Cheers,
> Max
>
>
>
>> However, I don't think it is realistic for end users to assume that they
>> have a firmware signing certificate (+ private key) to sign firmware
>> updates as a way to demonstrate consent for an update.
>>
>> My opinion: the only requirement I can think of is that the manifest
>> format has to support multiple signatures (countersigning) so that one
>> could have a policy based on them.
>>
>> I do believe, however, that this is something that has no impact on a
>> manifest format. Particularly in the IoT context it often happens that the
>> end user is not sitting in the front of the device nor may the device even
>> have a UI. So, the consent needs to happen to "outside" .
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%
>> 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%
>> 7C01%7Cdthaler%40microsoft.com%7C7215b35bed3043c20b6508d5
>> 2c96a230%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636463
>> 947840714659&sdata=Xjz9tS4yuuiB%2Bp39yKYM%2B%2B00y4oKNqyBB8d
>> deSp%2Fr3U%3D&reserved=0
>> 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.
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%
>> 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%
>> 7C01%7Cdthaler%40microsoft.com%7C7215b35bed3043c20b6508d5
>> 2c96a230%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636463
>> 947840714659&sdata=Xjz9tS4yuuiB%2Bp39yKYM%2B%2B00y4oKNqyBB8d
>> deSp%2Fr3U%3D&reserved=0
>> 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: Brendan Moran <[email-masked]>
Date: Thu, 16 Nov 2017 14:44:51 +0000

I agree. Delegations and multiple signatures are the appropriate way to handle user consent. Signed policies-as-data might be an interesting way to handle switching between automatic updates, automatic security updates, and user consent required.

Thanks,
Brendan

On 16 Nov 2017, at 14:41, Justin Cappos <[email-masked]<mailto:[email-masked]>> wrote:

Max: If you use delegations, you can have the flexibility to cover this case, multiple signatures, and many other features.  It seems likely to cover more cases than trying to pre-define different roles which all perform the same task.

Thanks,
Justin

On Wed, Nov 15, 2017 at 10:26 PM, Dr. Pala <[email-masked]<mailto:[email-masked]>> wrote:
Hi Hannes, David,

The use case I have in mind, however, is not for the user to counter-sign the firmware but for one or more additional "deployment" authority to "bless" the update for deployment in its environment. We already have this in the cable industry and I think it would be a good feature to have.

Cheers,
Max

-----Original Message-----
From: Suit [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hannes Tschofenig
Sent: Thursday, November 16, 2017 10:06 AM
To: David A. Wheeler <[email-masked]<mailto:[email-masked]>>; suit <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] Make it clear that end-users MUST be able to NOT update

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of David A. Wheeler
Sent: 16 November 2017 01:16
To: suit
Subject: [Suit] Make it clear that end-users MUST be able to NOT update

Thanks.

--- David A. Wheeler

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7C7215b35bed3043c20b6508d52c96a230%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636463947840714659&sdata=Xjz9tS4yuuiB%2Bp39yKYM%2B%2B00y4oKNqyBB8ddeSp%2Fr3U%3D&reserved=0
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.

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7C7215b35bed3043c20b6508d52c96a230%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636463947840714659&sdata=Xjz9tS4yuuiB%2Bp39yKYM%2B%2B00y4oKNqyBB8ddeSp%2Fr3U%3D&reserved=0
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.

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

---

From: Brendan Moran <[email-masked]>
Date: Thu, 16 Nov 2017 14:51:21 +0000

On 15 Nov 2017, at 17:16, David A. Wheeler <[email-masked]<mailto:[email-masked]>> wrote:

Thanks.

--- David A. Wheeler

As much as I agree with this in principle, I think that it’s dangerous to require user consent by default:

https://insights.ubuntu.com/2016/12/15/research-consumers-are-terrible-at-updating-their-connected-devices/

Automatic updates must be the default behaviour. It’s fine for users to request and be granted update authorisation authority over their own devices, but by default manufacturers should assume that 69% of their users will apply security updates late or never.

Of those polled, nearly two thirds felt that it was not their responsibility to keep firmware updated. 22% believed it was the job of software developers, while 18% consider it to be the responsibility of device manufacturers.

I don’t think they are wrong.

Best Regards,
Brendan

---

From: "Dr. Pala" <[email-masked]>
Date: Fri, 17 Nov 2017 07:22:01 +0800

Hi Justin,

nice to read you again :D I hope everything is great with you :D

On 11/16/17 10:41 PM, Justin Cappos wrote:
> Max: If you use delegations, you can have the flexibility to cover 
> this case, multiple signatures, and many other features.  It seems 
> likely to cover more cases than trying to pre-define different roles 
> which all perform the same task.
Can you elaborate more about what you mean by "delegation" ? Keep in 
mind the constraints that these devices have (class1) - a 
delegation/role based model might be difficult to support or scare 
device vendors in case it is complex. Can you provide some more details 
about what you mean by using delegations ?

Cheers,
Max

---

From: Justin Cappos <[email-masked]>
Date: Fri, 17 Nov 2017 15:36:20 -0500

When you say class1, do you mean the Class 1 individual certificates
intended for individuals / email?

The delegation support I'm talking about is pretty straightforward (
https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf
https://isis.poly.edu/~jcappos/papers/kuppusamy_nsdi_16.pdf ).  It's
basically just letting one say what other keys to trust in addition to what
hashes to trust.

So, normally you might sign a piece of metadata with image / hash names
like this:

"""
foo-1.0.tgz ab1234...
bar-1.0.tgz fedcba...
bar-1.1.tgz 987654...
zap-2.0.tgz 938271...

SIGNATURE (ACME co):
XXX
"""

The problem is that ACME co may have a lot of different developers or
suppliers and now you need to sign everything with ACME co's key.  With
delegations, you can selectively enable different parties to sign for some
files like this:

"""
foo-1.0.tgz ab1234...
bar* Alice(Alice pub...)
zap* Zapco(Zapco pub...)

SIGNATURE (ACME co):
XXX
"""

Now you can have separate pieces of metadata for Alice and Zapco that sign
for the files they are trusted to provide.

This really simple and lightweight mechanism provides the ability to handle
a whole lot of very complex situations, including things like letting users
choose whether they should manage when updates are applied vs letting
vendors do so, situations where Alice gets an intern and wants them to
build test versions of software, prevents key sharing, makes key
compromises less impactful, etc.

Delegations are the fundamental basis for TUF (used in desktop systems /
cloud) and Uptane (used in embedded systems like automobiles).

Thanks,
Justin

On Thu, Nov 16, 2017 at 6:22 PM, Dr. Pala <[email-masked]> wrote:

> Can you elaborate more about what you mean by "delegation" ? Keep in mind
> the constraints that these devices have (class1) - a delegation/role based
> model might be difficult to support or scare device vendors in case it is
> complex. Can you provide some more details about what you mean by using
> delegations ?
>
> Cheers,
> Max
>
>

---

From: Justin Cappos <[email-masked]>
Date: Fri, 17 Nov 2017 17:57:48 -0500

Okay thanks for clarifying!  Class 1 devices look similar to what people
use for partial verification secondaries
<https://docs.google.com/document/d/1pBK--40BCg_ofww4GES0weYFB6tZRedAjUy6PJ4Rgzk/edit#heading=h.2xnymqq2dc48>
in Uptane...

Thanks,
Justin

On Fri, Nov 17, 2017 at 5:19 PM, Michael Richardson <[email-masked]>
wrote:

>
> Justin Cappos <[email-masked]> wrote:
> Unlikely.
> Probably class 1 device, according to RFC7228.
>
> https://tools.ietf.org/html/rfc7228#section-3
>
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 28 Nov 2017 21:58:05 -0700

I don't think we can pick any absolute way this work. I think we have to have a framework flexible enough to require this and not require it. Many firmware updates of devices come along with accepting a new Terms Of Service. Some people run systems, be they in a home, factory, or large network, and they want to ensure upgrades don't happen unless if is a version that has been verified tow work with the rest of the system. I'm not keen on an upgrade to a device in my house that add analytics that impact my privacy. 

So yes, some IoT device will be built to upgrade automatically whenever the vendor wants regardless of anyone else. But some other IoT device will allow for a model where someone other than the vendor can grant permission to install a certain upgrade. (I don't think this permission implies a need for second signature). I think what we do here needs to support both of these models. 

Similarly there is a downgrade issue. Some vendors will want to be able to downgrade their devices and in particular may want to support a factor reset that takes the device back to the version of the firmware it had when it left the factory. Obviously in some cases this reduces the security so some device will not allow it but it can reduce the odds of bricking a few million devices. Again, I think we will need to support both models. 

> On Nov 15, 2017, at 10:16 AM, David A. Wheeler <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Nov 2017 10:30:45 -0500

Cullen Jennings <[email-masked]> wrote:
    > I don't think we can pick any absolute way this work. I think we have
    > to have a framework flexible enough to require this and not require
    > it. Many firmware updates of devices come along with accepting a new
    > Terms Of Service. Some people run systems, be they in a home, factory,
    > or large network, and they want to ensure upgrades don't happen unless
    > if is a version that has been verified tow work with the rest of the
    > system. I'm not keen on an upgrade to a device in my house that add
    > analytics that impact my privacy.

At the IOTSF NYC meeting, a speaker mentioned that the entertainment system
was upgraded in-flight.... and then... because it didn't work, they went back
to a version from 2008 or something, and as a result none of the certificates
worked!
So clearly the airline (device owner!) needs to control this, yet the
manufacturer has to release the fixes as quickly as they can so that those
who want to upgrade can do so.

    > So yes, some IoT device will be built to upgrade automatically whenever
    > the vendor wants regardless of anyone else. But some other IoT device
    > will allow for a model where someone other than the vendor can grant
    > permission to install a certain upgrade. (I don't think this permission
    > implies a need for second signature). I think what we do here needs to
    > support both of these models.

I agree: a second signature is only one way to do this. It does have nice
scaling properties.

{am I the only one writing down movie plots as we go?}