[Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Thu, 17 October 2019 01:09 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: anima@ietf.org
Delivered-To: anima@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD2F120019; Wed, 16 Oct 2019 18:09:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.105.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <157127457937.7863.815173980398917672.idtracker@ietfa.amsl.com>
Date: Wed, 16 Oct 2019 18:09:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/tHsngXmkuTvXfHZHlJSV0CoB7Gs>
Subject: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 01:09:39 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-28: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

One remaining item of clarity in the Section 7 from my previous DISCUSS
position:

** Section 7.  Per “This section is considered non-normative in the generality
of the protocol.  Use of the suggested mechanism here MUST be detailed in
specific profiles of BRSKI, such as in Section 9.”

-- Can you please clarify “non-normative in the generality of the protocol”? 
If I take the perspective of an implementer, it seems like a black-and-white
issue – either this section is normative or not (I either have to conform or
not).

-- what this MUST is requiring isn’t clear.  Practically, why would using any
of these mechanisms in this section require further elaboration?

I’d offer an alternative introduction to this section to address these
ambiguities:

OLD
   A common requirement of bootstrapping is to support less secure
   operational modes for support specific use cases.  The following
   sections detail specific ways that the pledge, registrar and MASA can
   be configured to run in a less secure mode for the indicated reasons.

   This section is considered non-normative in the generality of the
   protocol.  Use of the suggested mechanism here MUST be detailed in
   specific profiles of BRSKI, such as in Section 9.

NEW
A common requirement of bootstrapping is to support less secure operational
modes for support specific use cases.  This section suggests a range of
mechanisms that would alter the security assurance of BRSKI to accommodate
alternative deployment architectures and mitigate lifecycle management issues
identified in Section 10.4 – 10.7.  They are presented here as informative
(non-normative) design guidance for future standardization activities.  It
would be expected that subsets of these mechanisms could be profiled with an
accompanying applicability statements similar to the one described in Section 9.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my previous COMMENTS.

I remain concerned that the current text continues to only normatively specify
the behavior in the first part of the lifecycle that BRSKI-enabled equipment
might see -- equipment on first sale as long as the manufacturer supports it or
stays in business.  I appreciate that this scope is the consensus of the WG. 
Therefore, thank you for all of the efforts made in recent version of the draft
to more substantively document (if not fully specify) these later lifecycle
activities.

** Abstract.  Per “Support for lower security models, including devices with
minimal identity, is described for legacy reasons but not encouraged.”, the
rational for the lower security models as described in Section 7 do not appear
to be “legacy”.

** Section 1.5  Per “Upon successfully validating a voucher artifact, a status
telemetry MUST be returned.  See Section 5.7.”  Is a “voucher artifact” the
same as a “voucher”?

** Section 5.9.4. Per “In the case of a SUCCESS the Reason string is omitted. 
The SubjectKeyIdentifier is included so that the server can record the
successful certificate distribution.”.  Given the single example in Figure 18,
it isn’t clear how to represent the SubjectKeyIdentifier in JSON.

** Section 10.3.  Per “[t]he so-called "call-home" mechanism that occurs as
part of the BRSKI-MASA connection standardizes what has been deemed by some as
a sinister mechanism for corporate oversight of individuals. ([livingwithIoT]
and [IoTstrangeThings] for a small sample).”

-- Thanks for including this text about the “call-home” mechanism.  However the
references don’t seem like a fit.  Both references appear to focus on the
regular “call home” activity of these device rather than the narrow, on-time
one-time onboarding process.  The nature of the “call-home” isn’t just about
privacy (as these articles imply), but also lock-in.

-- It isn't appropriate to characterize concerns about the BRISKI-MASA link as
“sinister mechanisms ...”.

** Section 10.7.  Per “It is anticipated that specialist service providers will
come to exist that deal with the creation of vouchers in much the same way that
many companies have outsourced email, advertising and janitorial services.”, I
don’t think this is a fair analogy.  Delegating the voucher process to an
entity would take active cooperation of the manufacturer.  If the manufacture
is out of business, there is not guarantee this would have been put in place
(or those assets were acquired in the liquidation)

** Section 11.5.2.2 prescribes that the operator of a MASA “MUST issue a
firmware update to all devices that had that key as a trust anchor”.  This
suggests a required capability to update trust anchors.  However, Section 7.4.3
discusses a similar (albeit more flexible) practice but this is non-normative
and deemed reduced security.  Why the dissidence?

** Please respond to Christian Huitema’s new SECDIR review items (thank you
again, Christian!) on clarifying the TLS version negotiation and certificates
for MASA authentication.

** Editorial Nits:

Section 3.4.  Typo. s/occurence/occurrence/

Section 4.  These sentences didn’t parse for me – “This section applies is
normative for uses with an ANIMA ACP.   The use of GRASP mechanism part of the
ACP.”

Section 4.  Reference expansion issue?.  s/{{RFC8446}}/[RFC8446]/

Section 5.1.  Typo.  s/progess/progress/

Section 5.2.  Editorial. Per “The media type is the same as defined in
[RFC8366].  and is also …”, the start of the second sentence shouldn’t be “and
is …”

Section 5.2. Editorial.  s/then there a On-Path Attacker (MITM)/then there is
an On-Path Attacker (MITM)/

Section 4.1.  Recommend clarity on the non-normative behavior.  s/While the
GRASP M_FLOOD mechanism is passive for the pledge, the optional other methods
(mDNS, and IPv4 methods) are active./While the GRASP M_FLOOD mechanism is
passive for the pledge, the non-normative, optional methods (mDNS, and IPv4
methods) described in Appendix A are active./

Section 5.7.  Editorial
s/The client HTTP POSTs the following to the server at the URI ".well-known URI
"/voucher_status"./ The client sends an HTTP POSTs to the server at the URI
".well-known URI "/voucher_status".

Section 7.2.  Typo.  s/dependant/dependent/

Section 7.4.1. Typo.  s/A MASA has the option of not including a nonce is in
the voucher/A MASA has the option of not including a nonce in the voucher/

Section 7.4.2.  Typo.  s/ nuissance/nuisance/

Section 7.4.3.  Typo. s/overwitten/overwritten/

Section 7.4.3.  Typo.  s/responsability/responsibility/

Section 10.2.  Duplicate word. s/the the/the/

Section 10.2. Typo. s/ arbitrary/ arbitrary/

Section 10.2 Typo. s/coorelate/correlate/

Section 10.3.  Typo. s/the the/the/

Section 10.4.  Typo. s/absense/absence/

Section 10.6.  Typo. s/gratuitiously/gratuitously/

Section 10.6.  Duplicate Word. s/Section Section/Section/

Section 10.6.  Duplicate Word. s/an an/an/

Section 11.2. Typo. s/particulary/particularly/

Section 11.3.  Typo.  s/occurence/occurrence/

Section 11.5.  Typo. s/proceedures/procedures/

Section 11.5. Sometime is amiss with reference expansions –
s/{{cabforumaudit}}/[CABFORUMAUDIT]/ and s/{{dnssecroot}}/[DNSSECROOT]/

Section 11.5.2.1.  Typo. s/opportunies/opportunities/

==[ summary of old DISCUSS ]==
(1) Section 5.7.  The format of a pledge status telemetry message seems
underspecified.

(2) Section 5.8.1.  The format of the MASA audit log seems underspecified.  Is
the JSON snippet presented here normative to describe the MASA audit log
response?

(3) Why is Section 7.x in this document if it explains how to use BRSKI but is
considered non-normative?

(4) Thank you for documenting “manufacturer control issues” in Sections 10.3
and 10.4.  It helpfully lays justifies the current design approach.  I strongly
concur with the premise that “facilitate[ing] a few new operat[i]onal modes
without making any changes to the BRSKI protocol” is exactly what is needed.

My concern is that even with the current applicability statement in Section 9,
the current text appears to have only standardized the first part of the
lifecycle that BRSKI equipment might see -- equipment on first sale as long as
the manufacturer supports it or stays in business.  The text doesn’t appear to
cover the practical aspects of the proposed mitigations in Section 10.5 or the
situations described in Section 10.3/10.4 – various situations possible in the
full lifecycle usage of a BRSKI device and needed support the “additional
operational modes”.  Specifically:

** There appears to be little discussion on how owners/manufacturers/vendors
can facilitate second sale/used equipment beyond narrative words (in Section
10.3 and 10.4)

** There is appears to be little discussion on how to practically implement a
MASA (i.e., the offline use case).  For example, (Per Section 10.5) “A
manufacturer could provide a mechanism to manage the trust anchors and built-in
certificates (IDevID) as an extension.  This is a substantial amount of work,
and may be an area for future standardization work”.  Without the ability to
change anchors on the device the additional operational modes such as offline
mode seems challenging.