[secdir] dealing with many the secdir and genart comments

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 29 November 2018 22:37 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36A51276D0; Thu, 29 Nov 2018 14:37:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.401
X-Spam-Level:
X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no 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 ldjKHNv-v1dP; Thu, 29 Nov 2018 14:37:08 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEB3128D68; Thu, 29 Nov 2018 14:37:04 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [148.122.187.2]) by relay.sandelman.ca (Postfix) with ESMTPS id 2E6AA1F8BD; Thu, 29 Nov 2018 22:37:02 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 98AA82878; Thu, 29 Nov 2018 17:36:14 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jari Arkko <jari.arkko@piuha.net>, Christian Huitema <huitema@huitema.net>
cc: gen-art@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org, secdir@ietf.org
Reply-To: anima@ietf.org
In-Reply-To: <153874289877.989.15433226866680411112@ietfa.amsl.com>
References: <153826253306.18743.9250084704876465818@ietfa.amsl.com>, <153874289877.989.15433226866680411112@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
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 29 Nov 2018 22:36:14 -0000
Message-ID: <24358.1543530974@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/lm9JiZ9bHVjKMLv9FQhhGIfoh3E>
Subject: [secdir] dealing with many the secdir and genart comments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Nov 2018 22:37:10 -0000

{This is the first of many replies to the various reviews}

Jari Arkko <jari.arkko@piuha.net> wrote:
> My first bigger comment is that I believe the security and privacy
> considerations section should have provided an actual in-depth
> analysis of the characteristics offered by the protocol, perhaps under
> several different situations, as the protocol can be operated in
> different modes.

The authors seriously believe that this will result in an attempt to boil the
ocean.  Yes, BRSKI is exciting for many and opens many doors, but in
the context of the *ANIMA* Charter, we strongly think that this
document should leave the oceans alone, and deal only with the
ANIMA ACP usage.

Other users of BRSKI *SHOULD* write a new profile.
Would it be acceptable for us to provide a section that might be
entitled:
        "The ACP mode of operation of BRSKI"

or perhaps some other section that would clarify the applicability of this
document?

We would list the assumptions and maybe even reduce the options for use
in the ACP?

The authors do not object to writing more documents about more situations
where BRSKI might be used, but we think that putting it all into one
document is a way for continuing scope creep.

In accepting the constrained work into the ANIMA WG, the chairs and area
director have already been very generous.

> My second comment is that the protocol as defined is quite focused on
> manufacturer-controlled situations. As Christian mentioned, there is
> some discussion of other situations in the document (Section 6.4), but
> not much, and there's little information on what happens if one tries
> to use the protocol in this way.

The above comments would seem to apply to this as well.

As I previously indicated when you first wrote this, we have turned your
comments into a series of issues on github, and we will be closing those
issues as quickly as we can.

Some will come with proposed text changes, but a number will need discussion,
and we will start new subject lines in this thread for them.   I don't want
to innudate you, so I've set the Reply-To.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


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