Re: [Anima] Last Call: <draft-ietf-anima-bootstrapping-keyinfra-20.txt> (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

Toerless Eckert <tte@cs.fau.de> Tue, 04 June 2019 19:28 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 DE087120397; Tue, 4 Jun 2019 12:28:53 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 OOyPuefPeeBw; Tue, 4 Jun 2019 12:28:52 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 EB3CD1202E7; Tue, 4 Jun 2019 12:28:48 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DE4B354807D; Tue, 4 Jun 2019 21:28:43 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CBFCC440041; Tue, 4 Jun 2019 21:28:43 +0200 (CEST)
Date: Tue, 04 Jun 2019 21:28:43 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Eliot Lear <lear@cisco.com>
Cc: IETF discussion list <ietf@ietf.org>, ibagdona@gmail.com, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, anima@ietf.org, tte+ietf@cs.fau.de
Message-ID: <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de>
References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/z8ao5j4N_FTBRZOeuQouOsr445g>
Subject: Re: [Anima] Last Call: <draft-ietf-anima-bootstrapping-keyinfra-20.txt> (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard
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, 04 Jun 2019 19:28:54 -0000

Thanks, Eliot,

re-reading 10.3, my impression is: 

a) The use of TOFU in 10.3 seems to exceed the explanatory definition in 1.2.
The sentence stubs in 103 mentioning TOFU also don't seem to add value, the text
doesn't become IMHO worse if they are simply removed. And i am sure
there can easily be similar non-cyptographic leap of faiths in sales integration,
or consortium memberships trust chaing establishment.

b) The text could IMHO be crisper:

"will have no problem collaborating with it's MASA" ->
"will have no problem collaborating with it's malicious MASA" ->

"the domain (registrar) still needs to trust the manufacturer" ->
"the domain (registrar) still needs to authenticate the MASA" ?
(i hope the latter is the correct interpretation of the text)

Cheers
    Toerless

On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote:
> Just on this text:
> 
> In Section 10.3 the following text exists:
> 
>    o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
>       upon seeing a manufacturer's trust anchor for the first time, and
>       then the trust anchor would be installed to the trusted store.
>       There are risks with this; even if the key to name is validated
>       using something like the WebPKI, there remains the possibility
>       that the name is a look alike: e.g, c1sco.com, ..
> 
> First, this isn???t REALLY Trust-On-First-Use, and I would prefer that the term be replaced with something like "out-of-band approval".  This would also be a good area for certification services to step in to indicate the trustworthiness of a manufacturer.
> 
> Eliot
> 
> > On 21 May 2019, at 23:21, The IESG <iesg-secretary@ietf.org> wrote:
> > 
> > 
> > The IESG has received a request from the Autonomic Networking Integrated
> > Model and Approach WG (anima) to consider the following document: -
> > 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)'
> >  <draft-ietf-anima-bootstrapping-keyinfra-20.txt> as Proposed Standard
> > 
> > This is a second Last Call. IoT Directorate review was done after the ANIMA
> > WG Last Call and consensus to request the publication, and that review resulted
> > in substantial changes to the document.
> > 
> > The IESG plans to make a decision in the next few weeks, and solicits final
> > comments on this action. Please send substantive comments to the
> > ietf@ietf.org mailing lists by 2019-06-04. Exceptionally, comments may be
> > sent to iesg@ietf.org instead. In either case, please retain the beginning of
> > the Subject line to allow automated sorting.
> > 
> > Abstract
> > 
> > 
> >   This document specifies automated bootstrapping of an Autonomic
> >   Control Plane.  To do this a remote secure key infrastructure (BRSKI)
> >   is created using manufacturer installed X.509 certificate, in
> >   combination with a manufacturer's authorizing service, both online
> >   and offline.  Bootstrapping a new device can occur using a routable
> >   address and a cloud service, or using only link-local connectivity,
> >   or on limited/disconnected networks.  Support for lower security
> >   models, including devices with minimal identity, is described for
> >   legacy reasons but not encouraged.  Bootstrapping is complete when
> >   the cryptographic identity of the new key infrastructure is
> >   successfully deployed to the device but the established secure
> >   connection can be used to deploy a locally issued certificate to the
> >   device as well.
> > 
> > 
> > 
> > 
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
> > 
> > IESG discussion can be tracked via
> > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/
> > 
> > The following IPR Declarations may be related to this I-D:
> > 
> >   https://datatracker.ietf.org/ipr/2816/
> >   https://datatracker.ietf.org/ipr/3233/
> >   https://datatracker.ietf.org/ipr/2463/
> > 
> > 
> > 
> > The document contains these normative downward references.
> > See RFC 3967 for additional information:
> >    rfc8368: Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) (Informational - IETF stream)
> > 
> > 
> > 
> > _______________________________________________
> > Anima mailing list
> > Anima@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima
> 



> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


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