Re: [Anima] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28

[Dan Romascanu <[e-mail]>]

Hi Michael,

Sounds good. Thanks for addressing my comments.

Regards,

Dan


On Wed, Oct 16, 2019 at 9:04 PM Michael Richardson <[e-mail]>
wrote:

> On 2019-10-13 4:39 a.m., Dan Romascanu via Datatracker wrote:
> > Reviewer: Dan Romascanu
> > Review result: Ready with Issues
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
>
> Thank you for this.
> I will the majority of your issues with a -29 that I'll post this week.
> Given that most of your issues are minor, I don't think that they will
> affect the views of the IESG on Thursday, so I might not post it before
> Thursday's IESG call.
>
> Here is a diff though:  https://tinyurl.com/y5l4xz3z
>
> > I also observe that the document has consistent Operational implications
> but
> > there is no OPS-DIR review so far, as well as a YANG module and several
> other
> > references to YANG, but there is no YANG Doctors review. I hope that
> these will
> > be available prior to the IESG review.
>
> On the topic of YANG Doctor: I think that we did ask for a review at
> some point a long time ago.. Kent Watsen, one of the authors is also one
> of the YANG Doctors, so I feel pretty confident that we got that part
> right, but I agree, we could have asked more clearly. (Update: Tom has
> done one, and I'll act on it)
>
> I don't know why we have no OPS-DIR review.
> I see in the DT that an ARTART review is pending as well for today.
>
> > 1. The Pledge definition in section 1.2:
> >
> >> Pledge:  The prospective device, which has an identity installed at
> >        the factory.
> >
> > while in the Introduction:
> >
> >> ... new (unconfigured) devices that are called pledges in this
> >     document.
> >
> > These two definitions seem different. The definition in 1.2 does not
> include
> > the fact that the device is 'new (unconfigured'. Also, arguably 'identity
> > installed at the factory' may be considered a form of configuration.
>
> To me IDevID that is installed is not really any different than the fact
> that the device has firmware loaded. If a router needs to be told in the
> factory that it is a 24+4 switch, I don't consider that configuration,
> and this is really no different.
> There is no site-specific configuration is the point.
> I've made the text between the two places a bit more consistent.
>
> > 2. The document lacks an Operational Considerations section, which I
> believe is
> > needed, taking into consideration the length and complexity of the
> document.
> > There are many operational issues spread across the document concerning
> the
> > type and resources of devices, speed of the bootstrapping process,
> migration
> > pass, impact on network operation. I suggest to consider adding such a
> section
> > pointing to the place where these issues are discussed and adding the
> necessary
> > information if missing. Appendix A.1 in RFC 5706 can be used as a
> checklist of
> > the issues to be discussed in such a section.
>
> I took a look through 5706, and through the Appendix A.1.
> (I really like the RFC2119-non-text in 5706, and I will use it myself)
>
> I had already started two documents: Operational Considerations for
> Manufacturer Authorized Signing Authority, and Operational
> Considerations for BRSKI Registrar, but they are just skeletons.
> I think that a great deal of the ANIMA ACP Operational Considerations
> are covered in the ACP document.
>
> So while I agree that we need the content you are asking for, I'm
> reluctant to add this new section at this time.  Part of this is because
> I'm not sure that we know enough yet: there are only two known
> implementations of MASA, and we still have some interop gotchas that we
> haven't had time to solve those yet.
> Or to put it another way: trying to make up Operational Considerations
> is probably going to get in the way of actually gaining operational
> experience :-)
>
>
> > 3. Section 5.4:
> >
> >> Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
> >     REQUIRED.
> >
> > What is the reason for using 'encouraged'? Why not RECOMMENDED?
>
> RECOMMENDED is a synonym for SHOULD.
> SHOULD is too strong at this point.  There are no technical reasons why
> TLS 1.2 is good enough if you implement it wisely.
> We already had this discussion with SecAD, etc.
> A product manager might delay shipping in order to wait for the TLS 1.3
> libraries to get through FIPS if we wrote SHOULD, etc.
>
> > Nits/editorial comments:
> >
> > 1. The Abstract includes:
> >
> > 'To do this a Remote Secure Key Infrastructure (BRSKI) is created'
> >
> > Later in the document BRSKI is identified as a protocol. It would be
> good to
> > clarify if BRSKI = BRSKI protocol
>
> I have changed the abstract to say:
>
>          To do this a Secure Key Infrastructure is
>          bootstrapped.  This is done using manufacturer installed
>          X.509 certificates, in combination with a manufacturer's
>         authorizing
>          service, both online and offline.  We call this process the
>          Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol,
>          pronounced "brewski".
>
>
> > 2. In Section 1 - Introduction, 3rd paragraph:
> >
> > s/it's default modes/its default modes/
> > s/it's strongest modes/its strongest modes/
>
> fixed.
>
> > 3. Please expand non-obvious acronyms at first occurrence: EST protocol,
>
> Seems to be done correctly.
>
> > LLNs,
>
> fixed
>
> > REST interface,
> updated, and added reference.
>
> > LDAP,
>
> This is used once to say that we don't support it, despite RFC5280
> describing it.  We don't expand HTTP or FTP on that line though.
> I feel that the RFC5280 reference is good here.
>
>  > GRASP, CDDL, CSR
>
> done.
>
>
> > 4. I would suggest alphabetic order listing of the terms in section 1.2
>
> okay. Done.   (everyone sing the alphabet song...)
>
> >
> > 5. Section 1.3.1 - a reference for LDevID would be useful
>
> added. It's a 802.1AR term.
>
> > 6. Section 7:
> >
> > s/Use of the suggested mechanism/Use of the suggested mechanisms/
>
> fixed.
> I will post -29 once I have dealt with the new DISCUSS comments and YANG
> Doctor comments.
>
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>