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

[Roman Danyliw <[e-mail]>]

Hi Michael!

Pruning the thread ...

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Michael Richardson
> Sent: Thursday, October 17, 2019 4:57 PM
> To: Roman Danyliw <[e-mail]>; Christian Huitema
> <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; The IESG <[e-mail]>; [e-mail]
> 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 <[e-mail]> 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