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

Michael Richardson <> Sun, 17 November 2019 16:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4BFA120123; Sun, 17 Nov 2019 08:15:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rzgFT-LIVHPT; Sun, 17 Nov 2019 08:15:49 -0800 (PST)
Received: from ( [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A69F912006D; Sun, 17 Nov 2019 08:15:48 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPS id DCE961F450; Sun, 17 Nov 2019 16:15:45 +0000 (UTC)
Received: by (Postfix, from userid 179) id 02FB21295; Sun, 17 Nov 2019 21:06:50 +0800 (CST)
From: Michael Richardson <>
To: Roman Danyliw <>
cc: Christian Huitema <>, "" <>, "" <>, "" <>, The IESG <>, "" <>
In-reply-to: <359EC4B99E040048A7131E0F4E113AFC01E709807E@marchand>
References: <> <> <359EC4B99E040048A7131E0F4E113AFC01E709807E@marchand>
Comments: In-reply-to Roman Danyliw <> message dated "Tue, 05 Nov 2019 23:19:32 +0000."
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-sha256"; protocol="application/pgp-signature"
Date: Sun, 17 Nov 2019 21:06:49 +0800
Message-ID: <>
Archived-At: <>
Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Nov 2019 16:15:51 -0000

Roman Danyliw <> wrote:
    > 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.

I've used your suggested text in -30.

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

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 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 <>, Sandelman Software Works
 -= IPv6 IoT consulting =-