IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 10 July 2019 20:59 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 9C31212001B; Wed, 10 Jul 2019 13:59:37 -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 2POHPgRwqOtH; Wed, 10 Jul 2019 13:59:36 -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 DF4CC120025; Wed, 10 Jul 2019 13:59: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 8F6A13818E; Wed, 10 Jul 2019 16:57:30 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7762FA8A; Wed, 10 Jul 2019 16:59:34 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Roman Danyliw <rdd@cert.org>
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: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com>
References: <156277529950.15124.2390956674545685683.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: Wed, 10 Jul 2019 16:59:34 -0400
Message-ID: <4390.1562792374@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/_xHcg3E4-GvduRi-f3w0DWUA9IY>
Subject: Re: [Anima] Roman Danyliw'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: Wed, 10 Jul 2019 20:59:38 -0000

Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
    > (3) Why is Section 7.x in this document if it explains how to use BRSKI
    > but is
    > considered non-normative?

    > -- How should implementers take this language?
    > -- Why are normative sections, like Section 11, discussing it?

1) It's non-normative for proper/full operation of the ANIMA ACP

2) We think that some of the mechanisms that 7.2 describes may be needed
   in order for operators to have ways to work around infrastructure
   failures, such as manufacturers going out of business.
   We don't want to standardize
   I see that we use 2119 language in this section, and maybe that
   does not belong.  or maybe the section should be normative, but
   consist of a series of "MAY" statements?

   If vendors are going to provide work arounds ("back-doors")
   it would be best if they did something we can identify and reason about.
   So to use the back-door to the building analogy: we want to define
   fire-exits in the building code rather that doors that are insecure.

A lot of the text in Section 7 was originally sprinkled elsewhere, but that
confused things.  As shown by the long thread from concerned operators,
this move towards a secure-onboarding-by-default scares people who
are used to improvising things in an emergency.

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

v2.23.0 | Report a Bug | By Email