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

Michael Richardson <> Sun, 18 August 2019 20:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58EF81200CD; Sun, 18 Aug 2019 13:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1_OfoDq93pwB; Sun, 18 Aug 2019 13:09:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A4DE1200B9; Sun, 18 Aug 2019 13:09:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 72DCD380BE; Sun, 18 Aug 2019 16:08:56 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 6B1DEB2D; Sun, 18 Aug 2019 16:09:50 -0400 (EDT)
From: Michael Richardson <>
To: Benjamin Kaduk <>, Adam Roach <>
cc: The IESG <>, Christian Huitema <>,,,,
In-Reply-To: <>
References: <> <17440.1565636744@localhost> <> <14902.1565888325@localhost> <>
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: Sun, 18 Aug 2019 16:09:50 -0400
Message-ID: <3614.1566158990@localhost>
Archived-At: <>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Aug 2019 20:09:54 -0000

Benjamin Kaduk <> wrote:
    > That specific construction would seem like an "optional feature" per
    > ...

I re-read this, and this as to do with References, and so anything optional
referenced in section 7 would still need to be a Normative Reference.

The stickler I see right now is [I-D.ietf-netconf-keystore].
I don't want to hang on MISREF on that document; it's just one of many that
could be used, and I do not want to tell manufacturers that they have
to use this specific protocol to update trust anchors.
There are many other protocols that they presently support which they could
use, in particular, a CLI interface would be fine.

I think that this 7.4.3 section that creates a factory default which isn't
the default from the factory should be worry people who care about remote
attestation of software.

Adam has been particularly vocal about the need to specify something
normative that manufacturers have to provide in order to resale and operation
with the availability of the MASA.

It seems that we might need another round of discussion on this topic.
I feel that we are being pushed to describe the entire security lifetime of
the device; that we need to solve the entire management problem of devices in
our document.  (i.e. the 25 years of SNMPv3, plus YANG...) Maybe I just don't
understand what would be a reasonable answer, if what I've written is not enough.

Maybe a virtual interim discussion!   If so, please let me know.
ANIMA/Iot-Onboarding has some time booked already:

ps: (s/IPv6 NAT44/IPv4 NAT44/ for section 7.4.2, btw)

    >> section 9:
    >> In recognition of this, some mechanisms are presented in
    >> Section 7.2.  The manufacturer MUST provide at least one of the one-
    >> touch mechanisms described that permit enrollment to be proceed
    >> without availability of any manufacturer server (such as the MASA).

    > ... but this is a somewhat different construction.  In isolation, it looks
    > more like "MUST do at least one of X, Y, Z" without condition on "wish to
    > do W", and if X, Y, and Z are all in the same place, that place seems
    > normative to me.  (I will confess I've rather lost track of exactly why
    > we're debating if this is normative or not; I guess it's just the
    > disclaimer in Section 7 about "considered non-normative in the generality
    > of the protocol".)

Yes, it's MUST do one of X,Y,Z.
So that implies: MAY do X, MAY do Y, MAY do Z, but not the case of all being false.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-