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

Benjamin Kaduk <> Wed, 04 September 2019 03:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9379F12008A; Tue, 3 Sep 2019 20:02:53 -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 x1J5EzG0q99P; Tue, 3 Sep 2019 20:02:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E63E412008F; Tue, 3 Sep 2019 20:02:50 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x8432X8Z003112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 3 Sep 2019 23:02:37 -0400
Date: Tue, 03 Sep 2019 22:02:32 -0500
From: Benjamin Kaduk <>
To: Michael Richardson <>
Cc: Adam Roach <>, The IESG <>, Christian Huitema <>,,,,
Message-ID: <>
References: <> <17440.1565636744@localhost> <> <14902.1565888325@localhost> <> <3614.1566158990@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3614.1566158990@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
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: Wed, 04 Sep 2019 03:02:54 -0000

Whoops, this one apparently got skipped over amid some other deluge in my
inbox; sorry.

On Sun, Aug 18, 2019 at 04:09:50PM -0400, Michael Richardson wrote:
> 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.

I think I'm going to have to leave this one to Adam et al.

> 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.

If "ignore all of Section 7.2" is not an option, then at least some part of
it is normative.  "You just get to choose which part" :)