Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

Michael Richardson <> Tue, 02 October 2018 00:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B45D9126CB6; Mon, 1 Oct 2018 17:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v7c8TWRr-MIe; Mon, 1 Oct 2018 17:28:09 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35074124C04; Mon, 1 Oct 2018 17:28:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9265720090; Mon, 1 Oct 2018 20:28:07 -0400 (EDT)
Received: by (Postfix, from userid 179) id 3D3FF1537; Mon, 1 Oct 2018 20:28:08 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 38EBBAE0; Mon, 1 Oct 2018 20:28:08 -0400 (EDT)
From: Michael Richardson <>
To: Randy Bush <>
cc:,, Security Directorate <>
In-Reply-To: <>
References: <> <> <> <> <3136.1538342967@localhost> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Mon, 01 Oct 2018 20:28:08 -0400
Message-ID: <26848.1538440088@localhost>
Archived-At: <>
Subject: Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Oct 2018 00:28:12 -0000

Randy Bush <> wrote:
    >>> a stunning review as usual.  but i have two questions which you kind
    >>> of finessed.  they are simple binary, i.e. yes/no, questions that the
    >>> end user, to whom the IETF is ultimately responsible, really cares
    >>> about.
    >>> if the manufacturer's servers go down, either permanently or even for
    >>> a day, does the device i have purchased still work?  i.e. is it fail
    >>> soft? [0]
    >> First, BRSKI as used by ANIMA is specifically not targetted at Things.
    >> (We are developing profiles of BRSKI that are about Things, but I
    >> think that this internet-draft should not be be evaluated on that
    >> basis).
    >> It's targetted at routers and other devices found at ISPs or
    >> Enterprises.

    > i missed where i said light bulbs.  i do have some of those, but i run
    > routers, servers, etc.; and do not want $vendor to break my network for
    > *any* reason.

Then I suggest that you never patch the OS or apply firmware updates :-)

The reality is that they can break your network trivially if they want to.
But, you have a contract that says that they won't do that.

    >> Second, the only time the manufacturer's servers need to be alive is
    >> when device ownership is claimed.

    > i.e. when i sell the router to some other op.  that was my second
    > question.

Yes, so when you sell the router, whether or not the buyer gets firmware
updates, the export firmware, or even a license is also up to the vendor, and
so the vendor already has a say.  This really changes nothing, except that it
formalizes the arrangement in computer code rather than legal code.

I'm not particularly happy about this, btw, but I don't see a way to both do
secure imprinting and liberate the end user from vendor control.  If you have
a way to solve this tussle, I'd really like to know.

    >> Once the device is claimed, it joins *YOUR* network, and trusts your
    >> infrastructure, not the manufacturer.  Whether or not the device will
    >> *operate* without the manufacturer's servers is really outside of
    >> BRSKI.

    > ahhh.  we just sell the guns, we do not say how they are used.

naw, we just sell 3D printers, we do not say how they are used.

    >> This is a pretty important question and we have discussed it at
    >> length.  I remain concerned, but as far as I can see, we have this
    >> problem already.

    > if i understand correctly, it creates a new problem, needing the
    > manufacturer's consent for me to resell my light^Hrouter.

Yes, but operators already had this problem.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-