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