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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 16 Oct 2019 18:09:39 -0700

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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Oct 2019 22:56:30 +0200

{please excuse me if this is a resend}

{ALSO responding to Christian's third review comments.
  https://datatracker.ietf.org/doc/review-ietf-anima-bootstrapping-keyinfra-28-secdir-telechat-huitema-2019-10-12/ }

    > issue – either this section is normative or not (I either have to conform or

Section 7 is a pallette of items that might apply.
If you are in the applicability as defined by Section 9 (ACP), then you need
to read the MUSTs in that section.

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

...

    > A common requirement of bootstrapping is to support less secure operational

I've adapted it slight to read:

   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.  They are presented here as informative (non-normative)
   design guidance for future standardization activities.  Section 9
   provides standardization applicability statements for the ANIMA ACP.
   Other users would be expected that subsets of these mechanisms could
   be profiled with an accompanying applicability statements similar to
   the one described in Section 9.

    > to more substantively document (if not fully specify) these later lifecycle

I also continue to be concerned.  I have started some work on a more complex
voucher mechanism that would support the second sale.
Roman Danyliw via Datatracker <[email-masked]> wrote:

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

I will truncate the sentence after "minimal identity"

    > ** 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”?

Yes. RFC8366 describes "voucher artifacts", and so we try to use that term
consistently to describe the object.

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

Hmm. Thank you.
In the success situation, one would have used a TLSClientCertificate to
connect, so it would come from there.  In the failure situation, I'm not
sure; I haven't implemented that code yet.  I will consult with my co-authors.

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

While I agree with you, the devices mentioned in the above references die if
they can't call home AT ANY TIME.  Not just at onboarding.   So, the
oversight present in BRSKI is just less effective than other devices.

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

Did you read the review comments back in November/December 2018? :-)
if you are arguing that I'm using too alarmist language, I will accept
suggests for less alarmist language.

    > ** 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)

Recent changes remind that the manufacturer needs to escrow their keys.
If the manufacturer is out of business, then where will you get security
updates from?  Do you want to enable a secondary market for devices with
decade old security holes?

    > ** 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?

If you lose your key, you'll have to update the firmware to update the anchors.
If you have implemented 7.4.3, then it might be that you can do less.
However, in one version of 7.4.3, a factory reset might restore the original
(lost) keys, which is why a firmware update would in general be needed.

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

{Things which originate from the datatracker like these reviews seem to miss
my inbox, or maybe my eyes think it's spam; yet I get list traffic in
general.  I've had words with my spam filter supplier, but I wonder if it's
really my frontal cortex}

Christian asks:
   I have a minor concern with the text on TLS usage in section 5.1 and
   5.2. In section 5.1, BRSKI-EST TLS establishment details, I read "Use of
   TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED." Does that
   mean that BRSKI-EST TLS servers MAY reject connection attempts using a TLS
   version lower than 1.2, or maybe that pledges SHOULD refuse connections if
   the server tries to negotiate a TLS version lower than 1.2? We have
   experience in other deployments that even "low end" vendors will not cheap
   lower security solutions if that leads to interop failures, and that
   having at least some implementations being strict in what they accept is a
   good way to raise the bar for everybody.  Same issue in section 5.2,
   regarding BRSKI MASA connections.

BRSKI-EST TLS SHOULD reject TLS versions lower than 1.2.
Is there another other than:
   TLS 1.2 or newer is REQUIRED

to say this?

Christian also complains:

    In section 5.4.1, "This document does not make a specific recommendation"
    (regarding whether to use public PKI, DANE, or pinned certificates for
    MASA authentication. That's probably fine from a security point of view,
    but the absence of at least one recommended solution ay well end up
    causing interesting interoperability issues.

There is perhaps some confusion here.  I am extending the sentence to be
clearer:

    This document does not make a specific recommendation on how the
    MASA authenticates the Registrar

I learnt yesterday at RIPE that increasing amounts of HTTPS traffic is no longer
browser originated but rather APIs with pinned keys or TLSA/DANE keys, and
keys pinned by DNSSEC in DANE are growing in utility for non-browser use.

I think that we would have liked to specify DANE, but have been reluctant to
do so.

In general we do not think that CABFORUM certificates are likely to fit the
required policy for Registrars, as they likely use a key from a private
enterprise/domain CA.

I have addressed Christian's nits and your nits as well.

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

This sentence has already been replaced.

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

fixed.

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

fixed.

    > Section 10.2. Typo. s/ arbitrary/
                             arbitrary/

Not sure... did we both typo something?

    > s/{{cabforumaudit}}/[CABFORUMAUDIT]/ and s/{{dnssecroot}}/[DNSSECROOT]/

fixed already

    > ==[ 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?

CDDL added for this.

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

I want to ask again if we think that equipment without access to security
patches should be resold.
(I buy Dan Geer premise at https://www.youtube.com/watch?v=nT-TGvYOBpI, btw)
1) Anyone who can security patch the system after the manufacturer goes out of
   business can fix the trust anchors.

2) customers have asked for source code escrow for decades.  I remember
   preparing 150M QIC tapes for the Blackhole firewall for the lawyers back
   in 1995.   If I had BRSKI, the signing keys would be on that tape.
   This is just not new.  If Nortel customers failed to ask for that, well...

3) However, there are concerns in the (public) transportation industry about having
   the manufacturer be aware of when spares are deployed.
   I have started a document that would make the pledge evaluation of the
   voucher more complex, but would effectively fill in the offline and/or
   second sale process.

If the WG feels that this document should wait an additional 12-24 months for
that work to reach some level of maturity (including running code), then let's wait!

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

I have proposed a BOF/WG to deal with Lifecycle Security issues in IoT devices to
Ignas. A number of people believe that it would attempt to boil the ocean.
I think that with proactive charing and diligent work that we can make progress.
I did a talk today at RIPE79 about the quarantine/remediation life cycle
possibilities.   I'm not sure operators/ISPs are ready for this yet.

Changes so far are at:
   https://tinyurl.com/y5l4xz3z

I will post -29 once I get through the YANG DOCTOR comments and Ben's comments.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-