Re: [Anima-bootstrap] keyinfra-03 review

Toerless Eckert <> Wed, 17 August 2016 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 065D012B008 for <>; Tue, 16 Aug 2016 23:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1Wqd0Fl5ODl7 for <>; Tue, 16 Aug 2016 23:59:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02898127077 for <>; Tue, 16 Aug 2016 23:59:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9034; q=dns/txt; s=iport; t=1471417182; x=1472626782; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8NZ2qW764xv171Ai13vIxku6nFd9BKv+bN9K76ev1Zo=; b=RGX7AsQvRYjjbYNw3L+yS3CwpujFUvP7C+JoiFsP4641uzQkoVhX0/2x 3TybBym6OMfVnvJpb1tf+W7wDQNbIIXtU17hF5Uv6RVy1CQImuBAgXZmG NgUkJsPBwRgpfyEm463P9Zm+1AWvc4eNxYRjZOr12ZxZu+7fO5/FC7ffo o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAgBtCrRX/40NJK1UCoNEVny5UoF9J?= =?us-ascii?q?IV5AoFcOBQCAQEBAQEBAV4nhF8BBQEBJRM0BAcQCxgJJQ8FE0mIMQ6/CwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARcFineEGBKDQoIvBY8SijKPEwqBa4RciQGMOYN4H?= =?us-ascii?q?jaEGhwyhR4rgRgBAQE?=
X-IronPort-AV: E=Sophos;i="5.28,529,1464652800"; d="scan'208";a="311731986"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Aug 2016 06:59:41 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u7H6xfvW000311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Aug 2016 06:59:41 GMT
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id u7H6xeJE015515; Tue, 16 Aug 2016 23:59:40 -0700
Received: (from eckert@localhost) by (8.13.8/8.13.8/Submit) id u7H6xeZZ015514; Tue, 16 Aug 2016 23:59:40 -0700
Date: Tue, 16 Aug 2016 23:59:40 -0700
From: Toerless Eckert <>
Message-ID: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
Archived-At: <>
Cc: Anima-bootstrap <>
Subject: Re: [Anima-bootstrap] keyinfra-03 review
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Aug 2016 06:59:45 -0000

Thank you very much, Peter!

On Wed, Aug 17, 2016 at 08:51:25AM +0200, peter van der Stok wrote:
> Hi Max,
> In Berlin you asked for more reviews of the keyinfra (bootstrapping) 
> draft.
> Below my efforts from a constrained device/network point of view.
> I hope the review helps to get the validity of this document for the 
> constrained world better understood.
> Greetings,
> Peter
> __________________________________________________________________________________________________________________
> Anima-bootstrapping-keyinfra-03
> In general:
> I think this is quite an important document to standardize autonomous 
> security bootstrapping in the control plane, but its relation to 
> constrained devices could be improved and clarified.
> I found it difficult to review the document because there is much 
> overlapping text that describes the same protocol or function but in 
> different words. Also I recommend the use of consistent terminology. For 
> example, the terms new entity, device and new device, probably denoting 
> the same thing, are used throughout the document. A consistent choice 
> would help the reader. The terms vendor service, MASA, or just vendor 
> could be aligned in figures and text.  As a result this is a quite 
> high-level review, in which I mainly try to point out ways to improve 
> the readability.
> In more detail:
> There are two authorizations in the document: a provisional one and a 
> definite one. Giving them different names and referring to them by these 
> names would help. For the moment a reader has to guess what 
> ???authorized??? means in different parts of the text. The term Zero-touch 
> approach could be explained in section 1.1.
> Page 4.
> The 4 questions at the top of page 4 need rephrasing. Especially the 
> words ???who???, ???mine???, ???it???, and ???I??? are ambiguous.
> Suggest to remove in the second paragraph: ???The domain???s decisions ???. 
> Auditable fashion???. This is difficult to follow and needs information 
> provided later.
> Optimal security (remove optimal)
> ???Bootstrapping  ??? secure???. Remove, does not help.
> Last phrase before 1.1: reduce to: Support of alternative key 
> infrastructures is discussed.
> Page 5: DomainID. Remove ???(a string value ??? is used)???. This 
> information does not help me.
> Pledge: to at the factory (which one to or at?)
>  belongs with this network (you mean domain?)
> section 1.2. I find the discussion in this section very hard to follow. 
> The general message I receive, is ???constrained networks??? are out of 
> scope (NO 802.15.4); unless you execute only parts of the bootstrapping 
> protocol. But executing parts of the protocol is not allowed. On the 
> other hand an argument is made about the size of the messages being 
> prohibitive; but it is not clear what sizes we discuss. Later in the 
> document (section 5.7.5) a discussion about CoAP and DTLS follows; but 
> the relation with this section is unclear.
> My suggestion is to clarify the end state expected from the key 
> distribution as explained in section 3.1.7. Explain that constrained 
> devices may need this state, mention the intended use of coap (section 
> 3.2.1) and point out where the bootstrapping communication may be long 
> (transport of certificates) and will need the block option of CoAP.
> Page 9: Is ownership tracker part of MASA? In the rest of the document 
> its existence seems not essential.
> Section 3. The first paragraph about autonomic fashion should go to 
> section 1, where the relation with ACP could be clarified. In general: 
> Ignoring non autonomic aspects will help the readability of this 
> document.
> Figure 2 is quite helpful, but why is there a figure 5 and 6 on pages 29 
> and 30; and what are the differences?
> Section 3.1 I don???t understand: ???A new entity???. been configured??? 
> Why not; I assume the protocol detects this behaviour.
> Page 12: identify itself AND authenticate Registrar (they have equal 
> importance)
> Page 13: point 3: why the text about nonce? This will be treated several 
> times later in the text.
> Point 4: Very confusing to me. Many terms are used that are explained 
> much later, like: Audit token, ownership voucher, Registrar server 
> certificate.
> Point 5 ???e.g. EST???. Why e.g. it seems to be the only option later in 
> the text. If not can it be made more explicit that other methods are 
> supported.
> Section 3.1.1 Discovery. The standardization of the discovery of the 
> proxy (registrar) does not seem necessary to me. The bootstrapping 
> protocol is not affected at all when different discovery protocols are 
> used. Just citing GRASP and mDNS as examples within their context seems 
> more than sufficient to me.
> Section 3.1.2 phrase 1; to what? does the new entity identify itself?
> Paragraph 2: What is the bootstrapping protocol server here? The proxy 
> or the Registrar? Is it the data received from the registrar that is not 
> trusted? But the data from the new entity is trusted? And why is a TLS 
> connection needed, if no data is trusted?
> Page 15, last phrase before 3.1.3: bootstrapping server -> registrar? 
> New device -> new entity?
> Section 3.1.3. Is this where EST is started? Might be helpful to 
> indicate which parts are already fixed by EST.
> The phrase: ???Since client authentication occurs during TLS handshake??? 
> is confusing. Is this the TLS handshake discussed under 3.1.2 or a new one? 
> Neither is it clear if this is the provisional authentication or the 
> final one.
> This section in general needs more clarification and description of the 
> flow on how redirections to a different Registrar works.
> Section 3.1.4 why cite the non autonomic (and non used) enrolment 
> protocols?
> The audit token provides sufficient information to continue, but the 
> ownership voucher does not?
> Section 3.1.5. Why this last paragraph about time distribution?
> Section 3.1.6 mentions audit token and ownership voucher; but only 
> discusses audit token afterwards to start RFC7030 process.
> Section 3.1.7 specifies the final purpose of the key distribution? IMO 
> part of this text should go to the introduction to motivate the 
> bootstrapping protocol and also show its validity for constrained 
> devices and networks.
> 3.2 facilitates communication between ???. According to figure 2 the 
> registrar is not necessarily configured on the Proxy.
> What is a control plane CPU? Probably text has gone missing.
> Not clear from the text how/why a device becomes a proxy and by whom/how 
> it is configured with the relevant information like the Registrar???s 
> address.
> Section 3.2.1 The choice between DTLS and TLS appears all of the sudden. 
> All former text discussed TLS; I suggest that a different section is 
> dedicated to use of CoAP, describes the http/TLS to coap/dtls mapping, 
> and the draft consistently uses TLS for clarity. Section 3.2.1. is then 
> more dedicated to the discovery and keeping proxy stateless.
> Section 3.2.2 suggests multiple options to proxy the connection to the 
> Registrar. Can other methods be used beyond that are listed here.
> Section 3.3.1 should the out of band be cited here? The draft describes 
> autonomic behaviour.
> End of section 3.3.2; why the emphasis on homenet?
> Section 3.3.3, 2nd paragraph; examples might be handy?
> Section 3.3.3 Claims for an unauthenticated Registrar are only???; Is this 
> a viable approach?
> Section 3.4 Factory provider?
> Section 3.5 As the devices have a common trust anchor??? Please make 
> devices more explicit.
> Section 3.5.1. device -> new entity
> The new entity can validate the domain membership after joining? You 
> mean it can act as proxy?
> Section 3.6 Network access Control? Where does this term come from?
> What does ???having sufficient connectivity??? mean?
> Section 4.4 Zero-touch is an unknown term.
> Already enrolled devices -> proxies.
> Section 4.5 What are central control functions?
> Section 5 repeats much of earlier sections. I suggest to remove text in 
> earlier sections (or make more abstract) to minimize duplication.
> What is an ???air-gapped??? network? Referring in the text to fig 5 and fig 
> 6 and pointing out the differences helps readability.
> Here my review stops; The technology seems already quite solid if the 
> proxy behaviour with IPIP encapsulation of the TLS messages are better 
> clarified. The text needs quite some editing to remove duplication, 
> improve consistency, and remove many of the design decision discussions. 
> I hope my comments may help.
> Greetings,
> Peter
> -- 
> Peter van der Stok
> _______________________________________________
> Anima-bootstrap mailing list

Toerless Eckert,