Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-plane-27: (with DISCUSS and COMMENT)

Toerless Eckert <> Fri, 11 September 2020 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB3543A0D3F; Fri, 11 Sep 2020 05:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.164
X-Spam-Status: No, score=-0.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qJCtRTmSxPsK; Fri, 11 Sep 2020 05:59:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD2C33A0BF6; Fri, 11 Sep 2020 05:59:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EAC45548621; Fri, 11 Sep 2020 14:59:39 +0200 (CEST)
Received: by (Postfix, from userid 10463) id E5099440059; Fri, 11 Sep 2020 14:59:39 +0200 (CEST)
Date: Fri, 11 Sep 2020 14:59:39 +0200
From: Toerless Eckert <>
To: Roman Danyliw <>
Cc: The IESG <>, "" <>, "" <>, "" <>, Sheng Jiang <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-plane-27: (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: Fri, 11 Sep 2020 13:00:01 -0000

Thanks Roman

Listing all diffs just in case and so i don't have to create separate mail headers ;-)
replies to discuss/comments after diff URLs.


Full diff -28 to current -29 version:

(this includes conversion XMLv2->v3 and addition of contributor section).

Diff for Roman Danyliw discuss/comments reply:

Diff for Ben Kaduk discuss/comments reply:

Diff for Barry Leiba discuss/comments reply:

Diff for Erik Kline discuss/comments reply:

Diff for Robert Wilton comments reply:

On Tue, Aug 11, 2020 at 01:22:22AM +0000, Roman Danyliw wrote:
> Hi Toerless!
> Thanks for your detailed follow-up both in the form of the -28 and the helpful explanations below.  I think everything is cleaned up but the last discuss, I will update my ballot so it's easier to manage.
> Roman
[... snip ...]

> I reread the Section 11 with your explanation in mind and see your perspective -- it's difficult to be specific without mandating a specific protocol.  However, there seems to be two concrete, normative elements of this architecture -- EST and GRASP.  The latter for bootstrapping and the formal for renewal.  It isn't clear then why their Sec Considerations don't apply.  Furthermore, the protocols and practices of the bootstrapping process are out of scope of this document but seem like a security building block on which ACP is being built.

Please check out the out the expanded version of the bullet list in section 11,
it should close the discuss. 

As Brian already explained on the list, ACP is rather the security mechanism of
ACP-GRASP, so it is ACPs choice of TLS for ACP-GRASP end-to-end that provides the
security to ACP-GRASP. I therefore just detailled the explanation how intercepting
or faking GRASP announcements for EST can cause issues.

As a corollary to the now hopefully good explanation of how registrars are out of scope,
i do now include text that says about BRSKI what i think is appropriate and helpfull
(aka: for 'ANI class' ACP nodes).

The main points that you didn't mention explicitly but that dawned on me when reviewing
the issue was mentioning of the security of the ACP certificate and beenfits and
security of an IDevID.

Given how you are always interested for security to be normative if possible:
I think it is quite appropriate to discuss those node implementation
issues ONLY informally (and not normatively) in the security considerations
section, because aspects such as secure boot, enforcment of (only) trusted software
execution and TPM for storage of certificates is really out of scope of this
doc, and AFAIK also IETF (and i wouldn't know what an appropriate set of 
TCG standards is that we might want to refer to...). Aka: None of these aspects
are specific to ACP  but apply really to any secure and trustworthy system that
deals with certificates.

Lastly, there is also a new requirement in that is meant to prohibit the
misconfiguration or attack vector of making a node announce being an EST server,
when it can actually not talk to the right CA (not sure if this is easy to implement

[... snip ...]
> > > ** Section 11.  Per ???Security can be compromised by implementation
> > > errors (bugs), as in all products???, given the generic nature of this
> > > statement, couldn???t it also be a configuration error in the product too?
> > 
> > ;-) Not really because the claim of ACP is that all the core parts of ACP have no
> > configuration. See section 9.5.
> Short of some formally verified systems, this statement seems true of almost every system.  I didn't consider it actionable and would have removed it (again just editorial feedback in this case).

Sentence removed.

Thanks a lot for the review!