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

Toerless Eckert <tte@cs.fau.de> Tue, 16 July 2019 22:03 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 2E8E3120106; Tue, 16 Jul 2019 15:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 ErKP8WT2SPRt; Tue, 16 Jul 2019 15:03:13 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DD41200F5; Tue, 16 Jul 2019 15:03:13 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D7A1054800B; Wed, 17 Jul 2019 00:03:07 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C5A29440041; Wed, 17 Jul 2019 00:03:07 +0200 (CEST)
Date: Wed, 17 Jul 2019 00:03:07 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Adam Roach <adam@nostrum.com>
Cc: Eliot Lear <lear@cisco.com>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>, The IESG <iesg@ietf.org>, Toerless Eckert <tte+ietf@cs.fau.de>, anima@ietf.org
Message-ID: <20190716220307.c5ajnwyjgskyjtqk@faui48f.informatik.uni-erlangen.de>
References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <ACEB4033-707F-47AF-B58A-5227B444BEAB@cisco.com> <1692.1563030627@localhost> <A85B0B81-842C-4826-BDEB-8A2124F33622@cisco.com> <77BE2D94-9701-417C-9703-BD6727A0FC4B@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <77BE2D94-9701-417C-9703-BD6727A0FC4B@nostrum.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/wtwnbJsUX3-UCXlWtb7k19k7BLE>
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: Tue, 16 Jul 2019 22:03:15 -0000

Adam,

Not sure if you saw my reply to Alissas comments, but my biggest concern
no only to fudge more and more bits and pieces into thre tailend of this
draft (+1 to birans comment), but also to continue fudge them as protocol
extensions into the BRSKI protocol when in reality the problems we should
solve are at the architectural level, whatever protocol we use. All the
things discussed here, and i think including Eliots idea would for example
equally apply to RFC8572, so we would IMHO do a better job overall if from
now on we would try to figue out a way to define extensions to the voucher
system (or secure node behavior) in a protocol independent fashion (architecturally)
first, and then just have simple adoptions to the specific protocols
that want to have those extensions (BRSKI, NetConf, or whatever IoT
derivations i am sure will come up).

Not sure yet how to best do that, hopefully something we can discuss @105.

Wrt to Eliots suggestion: Its quite interesting and maybe the only one
for some slice of products, but If was thinking what really would mean 
"owning" to me, then thats the ability to replace the root trust
anchor(s) in the device with my own. And there are cases where products
at least support ADDING such trust anchors in a way that factory reset
won't remove them (and only leave vendor TAs). 

Cheers
    Toerless

On Mon, Jul 15, 2019 at 10:52:02AM -0500, Adam Roach wrote:
> 
> 
> > On Jul 15, 2019, at 02:39, Eliot Lear <lear@cisco.com> wrote:
> > 
> > To Adam???s broader point, there are at least several ways to approach this.  We can leave it to the vendor to decide which is correct, and we can continue to look to standardize ideas such as the one Michael had in the message I???m replying to now.
> 
> Yes; I think this is the important thing, and that specific mechanisms ??? if we believe they are useful to define ??? could be worked on later. 
> 
> /a
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
tte@cs.fau.de