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

[Michael Richardson <[e-mail]>]

{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/ }

Roman Danyliw via Datatracker <[e-mail]> wrote:
    > ----------------------------------------------------------------------
    > 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).

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
    > ambiguities:

...

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


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

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 <[e-mail]> 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?

    > Section 11.5. Sometime is amiss with reference expansions –
    > 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-