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

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 30 September 2018 21:29 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 0935E130E18; Sun, 30 Sep 2018 14:29:34 -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 vPWpiJP9Zbqm; Sun, 30 Sep 2018 14:29:31 -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 8F9E1130E14; Sun, 30 Sep 2018 14:29:31 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BBBE20090; Sun, 30 Sep 2018 17:29:27 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id E7D49AE0; Sun, 30 Sep 2018 17:29:27 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E4287ACB; Sun, 30 Sep 2018 17:29:27 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Randy Bush <randy@psg.com>
cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Christian Huitema <huitema@huitema.net>, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat <ietf@ietf.org>, anima@ietf.org, Security Directorate <secdir@ietf.org>
In-Reply-To: <e5e77a61-b8cf-cb8d-dfc3-05b8312b3adb@joelhalpern.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>
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: Sun, 30 Sep 2018 17:29:27 -0400
Message-ID: <3136.1538342967@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/la_mVnRZAzeFNgXMbycGueK69NY>
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: Sun, 30 Sep 2018 21:29:34 -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.

Whether or not the device continues to work after you take onwership is not
about this protocol.

Second, the only time the manufacturer's servers need to be alive is when
device ownership is claimed.   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.  However, if anything, we feel that as BRSKI creates a
strong connection between the device (the "pledge"), and the owner, that it
is much easier for the device to operate under the control of the owner
rather than exclusively the manufacturer's servers.


Joel M. Halpern <jmh@joelhalpern.com>; wrote:
    > That answer seems to imply that if the MASA is down before I try to transfer
    > my device, and if the MASA is still down when the recipient tries to get my
    > device working, it won't work.

    > Which seems to mean that once a MASA goes down permanently, any new can not
    > get a device reliant on that MASA to work.

    > Seems a pretty severe limitation.

You are answering a different question than Randy asked, I think.
You are answer the question about whether the device can be resold.

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.

It fundamentally depends upon a number of things which unfortunately, the
manufacturer has ultimate decision making about.  I hope that the market
will express itself, and the answers will result in environmentally
sustainable solutions rather than landfills.

Those things are:
   1) trivially, is the manufacturer alive, and willing to issue a new
      voucher to a new owner.  This is the easiest situation.

   2) if the manufacturer's software allows the domain owner to replace the
      MASA trust anchor with another one, then a different MASA could authorize
      the resale.

   3) if the manufacturer allows the entire software stack to be replaced,
      then in effect, a new manufacturer can be selected. (Think OpenWRT
      here)

In essence, all of these questions are about the degree to which the
manufacturer lets the owner control the software.  This is a tussle between
manufacturers that want to control it all, and owners who feel they should
control what the system does.

We think that BRSKI does not force either situation, but does deal with
some situations where a third party has inserted software between the point of
manufacturer and the owner.


--
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
 -= IPv6 IoT consulting =-