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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 02 October 2018 00:28 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45D9126CB6; Mon, 1 Oct 2018 17:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7c8TWRr-MIe; Mon, 1 Oct 2018 17:28:09 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [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 ietfa.amsl.com (Postfix) with ESMTPS id 35074124C04; Mon, 1 Oct 2018 17:28:09 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9265720090; Mon, 1 Oct 2018 20:28:07 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 3D3FF1537; Mon, 1 Oct 2018 20:28:08 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 38EBBAE0; Mon, 1 Oct 2018 20:28:08 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Randy Bush <randy@psg.com>
cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org, Security Directorate <secdir@ietf.org>
In-Reply-To: <m2tvm5ihlz.wl-randy@psg.com>
References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <m2sh1qkebi.wl-randy@psg.com> <0cbdf93d-c432-57f5-5000-8595b006d6d0@gmail.com> <e5e77a61-b8cf-cb8d-dfc3-05b8312b3adb@joelhalpern.com> <3136.1538342967@localhost> <m2tvm5ihlz.wl-randy@psg.com>
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: <https://mailarchive.ietf.org/arch/msg/secdir/oevpdCCD47aKtKalS_63STar8t0>
Subject: Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Oct 2018 00:28:12 -0000

Randy Bush <randy@psg.com>; 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 <mcr+IETF@sandelman.ca>;, Sandelman Software Works
 -= IPv6 IoT consulting =-