Last Call Review of draft-ietf-anima-bootstrapping-keyinfra-20
review-ietf-anima-bootstrapping-keyinfra-20-secdir-lc-huitema-2019-06-04-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

I think the document is now "ready with nits".

In my previous review of draft-ietf-anima-bootstrapping-keyinfra-16, I raised a
number of concerns. The new version draft-ietf-anima-bootstrapping-keyinfra-20
addresses these concerns in two main ways: an applicability statement that
restricts usage of the protocol to the "Autonomous Networking" scenario, and an
improved security section. My main request is that the applicability discussion
does not present the trade-off between between ease of bootstrap and increased
manufacturer control. This should be easy to fix.

The new version introduces applicability restriction in the Introduction,
stating that the draft "provides for the needs of the ISP and Enterprise
focused ANIMA Autonomic Control Plane (ACP)" and that other scenarios will
require separate applicability statements. This is developed in section 8,
"Applicability to the Autonomic Control Plane". This is a welcome change. It
addresses some of the concerns raised in the previous review, such as use of
BRSKI in consumer IOT scenarios.

The previous review also raised a series of concerns related to the balance of
power between manufacturer and owner of the device. These concerns are
discussed in section 9, Privacy Considerations. The text in sections 9.2 points
out that leakage of information is limited to the one-time bootstrap of the
device. Section 9.3 addresses concerns expressed during the review about resale
of devices, and points out that any mechanism intended to prevent theft will
also prevent resale. That's true, but the mechanism designed to enable
legitimate sales is only vaguely sketched: "the initial owner could inform the
manufacturer of the sale, or the manufacturer may just permit resales unless
told otherwise." Could and may, but there is no protocol element describing
either option. Similarly, the section addresses manufacturer decisions to "end
of life" a device by essentially stating that such devices will only be usable
if they are never reset to factory default. Section 9.4 goes on explaining how
the protocol can be used to thwart grey-market sales and resales, and simply
state that it is legitimate for manufacturers to do that.

As a whole, these three subsections of section 9 read very much like a
justification of the original design. They could be summarized by stating that
involving the manufacturer in the one-time bootstrapping provides new device
owners with an automated and secure way to bootstrap devices, at the cost of
increased manufacturer control on the devices' lifetime and resale. That
trade-off may not be acceptable by every potental owner. Section 9.5 describes
an interesting mitigation. It explains that manufacturer controls could be
bypassed by replacing the certificate built in the device, and pointing it to a
new MASA. That's obviously true, but I don't believe that the mechanisms for
doing that are stated in the draft. In the absence of that mechanism, I would
suggest to present the tradeoff between ease of bootstrap and increased
manufacturer control in the introduction, perhaps in the same paragraph that
states the domain of applicability of the draft.

The security section covers several of the issues pointed out in the previous
review. Section 10.1 explains how MASA availability issues (e.g. DoS attacks)
are mitigated (10.1) by availability of nonceless vouchers. Section 10.2
explains how attacks by fake registrars could be detected by examining audit
logs from the MASA. Section 10.3 discusses attacks by misbehaving MASA, and
effectively conclude that they are not worse than if the device was
bootstrapped without MASA. Continuous availability of MASA private key is
discussed in 10.4.

My previous review asked whether devices were expected to issue random numbers,
and whether they should be equipped with appropriate random number generators.
The protocol itself does not rely on random numbers generated by the device --
it only requires that the device be capable of generating a nonce. On the other
hand, the protocol relies on HTTPS and thus TLS, which itself does require
devices capable of generating cryptographically secure random numbers. The
concern there is that BRSKI is engaged after the device is "reset to factory
condition". This is probably easily mitigated, but might require a mention
somewhere.

A small nit about section 2.3 example:Text of first example says "The assertion
leaf is indicated as 'proximity'", but there is no "assertion" leaf in the
example voucher. Is this leftover from previous draft version?

I also noticed a number of typos, especially in the added text. Running a spell
check would help.