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

[Michael Richardson <[e-mail]>]

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.