IETF Logo Mail Archive

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

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

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA42126CB6; Mon, 1 Oct 2018 18:07:07 -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 Sz9bMKQdw1GF; Mon, 1 Oct 2018 18:07:06 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBC6124C04; Mon, 1 Oct 2018 18:07:05 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 13F5320090; Mon, 1 Oct 2018 21:07:04 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id B54B21537; Mon, 1 Oct 2018 21:07:04 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B09B6AE0; Mon, 1 Oct 2018 21:07:04 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Randy Bush <randy@psg.com>
cc: Christian Huitema <huitema@huitema.net>, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org, Security Directorate <secdir@ietf.org>
In-Reply-To: <m2murxi8ws.wl-randy@psg.com>
References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <m2sh1qkebi.wl-randy@psg.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <m2murxi8ws.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 21:07:04 -0400
Message-ID: <3785.1538442424@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/-d9a_8HUtHAQQPN0GkEAvrneqDg>
Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Oct 2018 01:07:07 -0000

Randy Bush <randy@psg.com> wrote:
    >> The BRSKI specification is a tradeoff and that's why I would really
    >> like to see the tradeoff explained in clear terms in the spec. It is
    >> designed to prevent hijacking of the device during its registration in
    >> the buyer's network.

    > if, to actually own a device i bought, i need to manage my own
    > security, then i will take that.

I think that this is already the case, and I see BRSKI as a mechanism by
which to safely handoff control from the manufacturer to the owner.

If the manufacturer doesn't want to do this, BRSKI isn't very useful to
them.  They should retain control of the device via their cloud
infrastructure, and not let the end user have any control at all.

    > the manufactures have very small incentive to lower drm barriers.  i
    > can point to a jillion current examples.  my favorite of the week is
    > john deere.

You are right.   But at least it's clear that john deere actually owns the
tractor, not the farmer and walk away from the mortgage.    It's not a
pretty picture, but I don't think we are making the situation worse: there is
already DRM and TPM.

What we are doing is making it clear that the tractor is actually owned,
and not p0wned.   However, I'm not sure that BRSKI has a value for large
devices with real user interfaces.  Maybe it has value for implements though.

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

v2.23.0 | Report a Bug | By Email