Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

From: Roman Danyliw <[email-masked]>
Date: Tue, 5 Nov 2019 23:19:32 +0000

Hi Michael!

Pruning the thread ...

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Michael Richardson
> Sent: Thursday, October 17, 2019 4:57 PM
> To: Roman Danyliw <[email-masked]>; Christian Huitema
> <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; The IESG <[email-masked]>; [email-masked]
> Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-
> bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
> 
> 
> {please excuse me if this is a resend}
> 
> {ALSO responding to Christian's third review comments.
>   https://datatracker.ietf.org/doc/review-ietf-anima-bootstrapping-keyinfra-
> 28-secdir-telechat-huitema-2019-10-12/ }
> 
> Roman Danyliw via Datatracker <[email-masked]> wrote:
>     > ----------------------------------------------------------------------
>     > DISCUSS:
>     > ----------------------------------------------------------------------

Thanks for the updated text in -29.  I've cleared the DISCUSS in the tracker.

>     > ----------------------------------------------------------------------
>     > COMMENT:
>     > ----------------------------------------------------------------------

Thanks for addressing these other comments (which I have removed from the thread).

>     > ** Section 10.3.  Per “[t]he so-called "call-home" mechanism that
>     > occurs as part of the BRSKI-MASA connection standardizes what has
> been
>     > deemed by some as a sinister mechanism for corporate oversight of
>     > individuals. ([livingwithIoT] and [IoTstrangeThings] for a small
>     > sample).”
> 
>     > -- Thanks for including this text about the “call-home” mechanism.
>     > However the references don’t seem like a fit.  Both references appear
>     > to focus on the regular “call home” activity of these device rather
>     > than the narrow, on-time one-time onboarding process.  The nature of
>     > the “call-home” isn’t just about privacy (as these articles imply), but
>     > also lock-in.
> 
> While I agree with you, the devices mentioned in the above references die if
> they can't call home AT ANY TIME.  Not just at onboarding.   So, the
> oversight present in BRSKI is just less effective than other devices.

I'm not disputing the phenomenon of devices not working if they aren't connected to the network.  I'm struggling to find that message in the provided references.

[livingwithIoT]
https://www.siliconrepublic.com/machines/iot-smart-devices-reality

[IoTstrangeThings]
https://www.welivesecurity.com/2017/03/03/internet-of-things-security-privacy-iot-update/

Unrelated, with [livingwithIoT], did you really mean the siliconrepublic content or the link to the gizmodo article it makes to:

https://gizmodo.com/the-house-that-spied-on-me-1822429852

>     > -- It isn't appropriate to characterize concerns about the BRISKI-MASA
>     > link as “sinister mechanisms ...”.
> 
> Did you read the review comments back in November/December 2018? :-) if
> you are arguing that I'm using too alarmist language, I will accept suggests for
> less alarmist language.

I did ;-) But it isn't clear to me that future readers will remember this discussion.  I'd advocate for stand-alone language. The less alarmist text I would propose is: 

OLD:

The so-called "call-home" mechanism that occurs as part of the BRSKI-
   MASA connection standardizes what has been deemed by some as a
   sinister mechanism for corporate oversight of individuals.
   ([livingwithIoT] and [IoTstrangeThings] for a small sample).

   As the Autonomic Control Plane (ACP) usage of BRSKI is not targeted
   at individual usage of IoT devices, but rather at the Enterprise and
   ISP creation of networks in a zero-touch fashion, the "call-home"
   represents a different kind of concern.

NEW:

With consumer-oriented devices, the "call-home" mechanism in IoT devices raises significant privacy concerns.  See [livingwithIoT] and [IoTstrangeThings] for exemplars.  The Autonomic Control Plane (ACP) usage of BRSKI is not targeted at individual usage of IoT devices, but rather at the Enterprise and ISP creation of networks in a zero-touch fashion where the "call-home" represents a different class of privacy and lifecycle management concerns. 

>     > ** Section 10.7.  Per “It is anticipated that specialist service
>     > providers will come to exist that deal with the creation of vouchers in
>     > much the same way that many companies have outsourced email,
>     > advertising and janitorial services.”, I don’t think this is a fair
>     > analogy.  Delegating the voucher process to an entity would take active
>     > cooperation of the manufacturer.  If the manufacture is out of
>     > business, there is not guarantee this would have been put in place (or
>     > those assets were acquired in the liquidation)
> 
> Recent changes remind that the manufacturer needs to escrow their keys.
> If the manufacturer is out of business, then where will you get security
> updates from?  Do you want to enable a secondary market for devices with
> decade old security holes?

I'm questioning the analogy to advertising or janitorial services.  To me, both of these examples are instances of a service being provided to the existing company rather than demonstrating how asset hand-off or continued maintenance would occur in the case of bankruptcy/liquidation.
 
>     > ** Section 11.5.2.2 prescribes that the operator of a MASA “MUST issue
>     > a firmware update to all devices that had that key as a trust anchor”.
>     > This suggests a required capability to update trust anchors.  However,
>     > Section 7.4.3 discusses a similar (albeit more flexible) practice but
>     > this is non-normative and deemed reduced security.  Why the
> dissidence?
> 
> If you lose your key, you'll have to update the firmware to update the
> anchors.
> If you have implemented 7.4.3, then it might be that you can do less.
> However, in one version of 7.4.3, a factory reset might restore the original
> (lost) keys, which is why a firmware update would in general be needed.

Got it.  Thanks for the clarification.
Thanks.

Regards,
Roman

---

From: Michael Richardson <[email-masked]>
Date: Sun, 17 Nov 2019 21:06:49 +0800

> With consumer-oriented devices, the "call-home" mechanism in IoT
    > devices raises significant privacy concerns.  See [livingwithIoT] and
    > [IoTstrangeThings] for exemplars.  The Autonomic Control Plane (ACP)
    > usage of BRSKI is not targeted at individual usage of IoT devices, but
    > rather at the Enterprise and ISP creation of networks in a zero-touch
    > fashion where the "call-home" represents a different class of privacy
    > and lifecycle management concerns.

I've used your suggested text in -30.

    >> Recent changes remind that the manufacturer needs to escrow their
    >> keys.  If the manufacturer is out of business, then where will you get
    >> security updates from?  Do you want to enable a secondary market for
    >> devices with decade old security holes?

    > I'm questioning the analogy to advertising or janitorial services.  To
    > me, both of these examples are instances of a service being provided to
    > the existing company rather than demonstrating how asset hand-off or
    > continued maintenance would occur in the case of
    > bankruptcy/liquidation.

It has been standard practice in every non-open source software organzation I have
ever worked at (going back to 1993) to dump software build trees to backup
media and escrow that to a lawyer.  That used to be to 150M QIC tapes at the
time, and I used to have a filing cabinet of the second copy of these things.

I don't see why the MASA keys wouldn't be part of Business Continuity
backups, and that any Hardware Security Modules that would contain critical keys
like this would be duplicated along with the software escrow.
If the company dies so catastrophically that even that is gone, then there
won't be any more security patches either, and maybe the device OUGHT to be
replaced.  Customers are sometimes SOL when they deal with companies like
that...  Having said that, Nortel Contivity VPN boxes were still in use
at gc.ca years after Nortel died, and may still be running now.
Someone got the tapes and was contracted to do patches is what I heard.

Noting that without the MASA keys, you can't do autonomic enrollment for a
device that has lost it's configuration and had to go through factory
default, or if you pull spare equipment out of cold storage.
You can still plug in a console cable and tell it bootstrap from a specific
IP, which is what you'd have to without BRSKI.  If it's a $3 smartlightbulb,
and the company went under, maybe that's regretable landfill. If you had
100,000 of them in the warehouse, well... that's government procurement :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Nov 2019 09:31:11 +0100

Just a reminder that the -30 draft posted last week resolves, I think, all of
your COMMENTS and DISCUSS points.