Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 11 July 2019 19:55 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 37FA6120121; Thu, 11 Jul 2019 12:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WdLnFWVEiQbB; Thu, 11 Jul 2019 12:55:36 -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 EB96F12008B; Thu, 11 Jul 2019 12:55:35 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C2923818F; Thu, 11 Jul 2019 15:53:28 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DAA984E9; Thu, 11 Jul 2019 15:55:33 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Adam Roach <adam@nostrum.com>
cc: The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, anima-chairs@ietf.org, anima@ietf.org
In-Reply-To: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com>
References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.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: Thu, 11 Jul 2019 15:55:33 -0400
Message-ID: <17580.1562874933@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/DHkLRrjek5Hh3Mag64RLpD_knqE>
Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
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: Thu, 11 Jul 2019 19:55:38 -0000

EXECSUM: Please stop beating us up for having solved the problem that the WG
         charter said we we should solve, and for having not solved a
         problem that the WG charter said was out-of-scope.

Adam Roach via Datatracker <noreply@ietf.org> wrote:
    > In short, beyond the user-hostile effects of these two issues, I have
    > ethical issues with the IETF publishing a protocol that promotes the
    > unnecessary creation of e-waste; and, unless handled properly, that will
    > be the inevitable result of the two factors I cite above.

I really hate e-waste.  More than many, I think.

I have worked very hard in my spare time in years past on projects like
cyanogen (when it was a thing) to continue to support perfectly good phones
that were abandonned by their manufacturers.

Much of the effort of supporting these phones has been because there is no
protocol for the manufacturers to pass on the real ownership keys to the
physical owner.   BRSKI can do exactly this.

  *** but manufacturers have to want to do it ***

I actually considered abandonning this document a year ago rather than build
something that could potentially lock in relationships.  Slowly I remembered
that outside of the open source operating system on x86 platform (which now
is ubiquitiously successful in the data center space), or openwrt
on semi-documented SoC,  everything else already is locked to the vendor.

My opinion is that pretty much every IoT product out there is pretty much
already e-waste because it does not support SUIT, RATS and BRSKI.

But, ANIMA is not chartered to do residential IoT, but rather Enterprise/ISP
equipment, and while we expect to use constrained-BRSKI for 6tisch, 6tisch is
about industrial IoT equipment.
In each case, the equipment is essentially e-waste as soon as the
manufacturer stops producing security updates.

So I totally understand and agree with your reluctance: if BRSKI gets into
residential IoT, in the fly-by-night vendors that ship crap and then shut
down, then I agree that it could be pretty user and environmentally hostile.
Do I think that will happen?  No: the fly-by-night vendors can't keep
their telnetd debug ports closed, and they aren't going to implement BRSKI
until such time as it's just there without them knowing it, and they start
buying IoT system platforms from Intel/ARM/Microsoft/etc.  at which point
it will the manufacturers' *AUTHORIZED* signing authority. (Not the manufacturer)

    > While this isn't part of my DISCUSS, I can't in good conscience ballot "No
    > Objection" to a document that doesn't normatively address those issues.  I
    > urge the authors and working group to add text that does so.  I do, however,
    > recognize that the prospect of this happening at this stage of the process is
    > vanishingly small. In the absence of such admittedly unlikely action, I plan
    > to Abstain after my DISCUSS issue has been addressed.

I am saddened by your cynicism, but I understand it.
(I feel you might need a hug at this point)

Can we write a protocol to replace trust anchors?  Yes, easily.
It's a one page yang model.  There are vestiages of it a key
anchor/management document that Kent Watsen wrote... I can't find it right
now.  We wanted to use in the early 6tisch zero-touch system that evolved
into BRSKI.  Can I force manufacturers to implement it?  No.  We aren't
mandating any kind of CLI, NETMOD, SNMP, COMI, etc. interface in the BRSKI
document, and we'd need at least one of them.

We also had this debate back in November/December/January.
I sure wish that your view had come forward then, rather than now.
I don't know how to fix things to satisfy the resale problem, while not at
the same time, opening the barn door to supply chain installed trojans.

Please stop beating us up for having solved the problem that the WG charter
said we we should solve, and for having not solved the problem that the WG
charter said was out-of-scope.

I'm curious if anyone has read Verner Vinge's Rainbow's End.

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