[secdir] Secdir telechat review of draft-ietf-anima-bootstrapping-keyinfra-28

[Christian Huitema via Datatracker <[e-mail]>]

Reviewer: Christian Huitema
Review result: Has Nits

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.

The summary of the review is ready with nits.

The draft-28 is much improved from the version that I originally reviewed, or
even from the intermediate version 20. The issues flagged in the original
review are now addressed. The draft now develops options for "nonceless
vouchers", which allows for offline onboarding scenario and addresses one of
the concerns expressed in my initial review. It also develops a TOFU option for
MASA servers, which has different security properties than the initial design.
That may be a useful mode of operation, and the related security issues are
discussed in subsection 11.4 of the security consideration sections.  Draft 28
addresses scenarios like "death of a manufacturer" that were flagged in the
first reviews. Generally, I find the revised security consideration section
much more developed and comprehensive than in the original drafts.

Draft 28 adds an extended privacy consideration section, which is welcome. On
the other hand, the authors may consider toning down the commentary text in
section 10.3, "The 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." That text was already in
draft-20, but feels a bit too petulant for standard track RFC.

I flagged a couple of technical nits:

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.

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.

Editorial Nits:

In section 1.4, the text says "The major intended beneficiary is that it
possible to use the credentials deployed by this protocol to secure the
Autonomic Control Plane (ACP) ([I-D.ietf-anima-autonomic-control-plane])." I
think you mean "benefit" instead of "beneficiary".

In section 2.3.1, the text says "The serialNumber fields is defined in
[RFC5280], and is a SHOULD field in [IDevID]." I understand that you mean that
according to [IDevId] the field SHOULD be present, but calling that a "SHOULD
field" is jargon.

In section 7.4.1, I read that "A MASA has the option of not including a nonce
is in the voucher, and/or not requiring one to be present in the
voucher-request." The "is in" looks like some kind of typo.

In section 10.2, typo, "arbtirary" for "arbitrary".