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

[Benjamin Kaduk <[e-mail]>]

Hi Christian,

Thanks for taking the time to re-review this epic.  It's reassuring to have
the extra opinion that the document is much improved!  I asked the authors
to respond to your few remaining comments and am holding a Discuss ballot
for a couple of boring points about clarity of protocol details.

-Ben

On Sat, Oct 12, 2019 at 09:53:35PM -0700, Christian Huitema via Datatracker wrote:
> 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".
> 
>