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

From: Dan Romascanu via Datatracker <[email-masked]>
Date: Sun, 13 Oct 2019 01:39:20 -0700

Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-anima-bootstrapping-keyinfra-??
Reviewer: Dan Romascanu
Review Date: 2019-10-13
IETF LC End Date: None
IESG Telechat date: 2019-10-17

Summary: Ready with Issues

This document specifies automated bootstrapping of an Autonomic Control Plane
by creating a Remote Secure Key Infrastructure (acronym BRSKI) using
manufacturer installed X.509 certificates, in combination with a manufacturer's
authorizing service, both online and offline.

Christian Huitema and Jari Arkko have performed early reviews of previous
versions of the document for SecDir and Gen-ART. As far as I can tell, most if
not all of their major concerns concerning applicability and security have been
addressed in the latest versions. A few more minor issues described below would
better be clarified before approval.

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.

Major issues:

Minor issues:

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.

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.

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?

Nits/editorial comments:

1. The Abstract includes:

'To do this a Remote Secure Key Infrastructure (BRSKI) is created'

Later in the document BRSKI is idefined as a protocol. It would be good to
clarify if BRSKI = BRSKI protocol

2. In Section 1 - Introduction, 3rd paragraph:

s/it's default modes/its default modes/
s/it's strongest modes/its strongest modes/

3. Please expand non-obvious acronyms at first occurrence: EST protocol, LLNs,
REST interface, LDAP, GRASP, CDDL, CSR

4. I would suggest alphabetic order listing of the terms in section 1.2

5. Section 1.3.1 - a reference for LDevID would be useful

6. Section 7:

s/Use of the suggested mechanism/Use of the suggested mechanisms/

---

From: Esko Dijk <[email-masked]>
Date: Mon, 14 Oct 2019 14:50:23 +0000

Besides the minor issues mentioned in the Gen-ART review, there also still a couple of open issues in the tracker https://github.com/anima-wg/anima-bootstrap/issues 
Shouldn't these be resolved also? Or is it already planned to do that later?  Rejection of issues is also fine of course as long as all issues are closed before the document gets published!

Best regards
Esko

Esko Dijk IoT Consultancy |  Email/Skype: [email-masked]    |   +31 6 1264 2103

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Dan Romascanu via Datatracker
Sent: Sunday, October 13, 2019 10:39
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Anima] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28

Reviewer: Dan Romascanu

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

This document specifies automated bootstrapping of an Autonomic Control Plane by creating a Remote Secure Key Infrastructure (acronym BRSKI) using manufacturer installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline.

Christian Huitema and Jari Arkko have performed early reviews of previous versions of the document for SecDir and Gen-ART. As far as I can tell, most if not all of their major concerns concerning applicability and security have been addressed in the latest versions. A few more minor issues described below would better be clarified before approval.

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.

Major issues:

Minor issues:

      the factory.

   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.

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.

   REQUIRED.

Nits/editorial comments:

Later in the document BRSKI is idefined as a protocol. It would be good to clarify if BRSKI = BRSKI protocol

3. Please expand non-obvious acronyms at first occurrence: EST protocol, LLNs, REST interface, LDAP, GRASP, CDDL, CSR

6. Section 7:

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Oct 2019 22:23:33 +0200

Esko Dijk <[email-masked]> wrote:
    > Besides the minor issues mentioned in the Gen-ART review, there also
    > still a couple of open issues in the tracker
    > https://github.com/anima-wg/anima-bootstrap/issues Shouldn't these be
    > resolved also? Or is it already planned to do that later?  Rejection of
    > issues is also fine of course as long as all issues are closed before
    > the document gets published!

Mostly, I have just not closed them properly.

---

From: tom petch <[email-masked]>
Date: Tue, 15 Oct 2019 09:40:57 +0000

Dan

I had a quick look at the YANG and it does indeed need some work IMHO.
I have posted a separate e-mail listing what I saw.

Tom Petch

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 16 Oct 2019 10:57:23 -0400

Dan, thanks for your review. Tom, thanks for your response. I entered a DISCUSS ballot to make sure the issues with the YANG modules get fixed. I also noted the need for a response to the full Gen-ART review.

Alissa

> On Oct 15, 2019, at 5:40 AM, tom petch <[email-masked]> wrote:
> 
> Dan
> 
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Oct 2019 14:04:34 -0400

> 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

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

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

> 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 :-)

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

> Later in the document BRSKI is identified as a protocol. It would be good to

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

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

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

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 16 Oct 2019 22:46:48 +0300

Hi Michael,

Sounds good. Thanks for addressing my comments.

Regards,

Dan

---

From: tom petch <[email-masked]>
Date: Fri, 18 Oct 2019 12:13:42 +0000

Looking some more at this I-D, I have more concerns about the YANG
module. My review is informal - I recommend that the WG Chair request a
formal review because I may be missing something particularly in
connection with the 'refine' statements.

The I-D has
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-voucher-request";
  prefix "vch";
whereas RFC8366, which it augments, has
  namespace "urn:ietf:params:xml:ns:yang:ietf-voucher";
  prefix vch;
Different module, same prefix; this contradicts a SHOULD NOT in RFC8407.

Further, this I-D defines
  import ietf-voucher {
    prefix v;
i.e. does not use the prefix defined in RFC8366.  This contradicts a
MUST in RFC8407.

There is a discrepancy between the e-mail addresses of the authors of
the YANG module and of the I-D, for
    Author:   Kent Watsen
    Author:   Toerless Eckert
I note that the e-mail addresses for the YANG module are the same as
those for the YANG module in RFC8366; I do not know which are correct.

  contact
   "WG Web:   <http://tools.ietf.org/wg/anima/>
should be https: and usually points to datatracker.ietf.org not tools

Tom Petch

----- Original Message -----
From: "Alissa Cooper" <[email-masked]>
To: "tom petch" <[email-masked]>; "Dan Romascanu"
<[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, October 16, 2019 3:57 PM

Dan, thanks for your review. Tom, thanks for your response. I entered a
DISCUSS ballot to make sure the issues with the YANG modules get fixed.
I also noted the need for a response to the full Gen-ART review.

Alissa

>> versions of the document for SecDir and Gen-ART. As far as I can
tell,
> most if
>> pass, impact on network operation. I suggest to consider adding such
a
> section

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Oct 2019 18:06:23 -0400

> The I-D has namespace
    > "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; prefix "vch";
    > whereas RFC8366, which it augments, has namespace
    > "urn:ietf:params:xml:ns:yang:ietf-voucher"; prefix vch; Different
    > module, same prefix; this contradicts a SHOULD NOT in RFC8407.

okay, so I shoudl change it to "vcr" for VouCher Request then?
I think that this will have affects on the constrained-voucher document, but
that is easily fixed.

    > Further, this I-D defines import ietf-voucher { prefix v; i.e. does not
    > use the prefix defined in RFC8366.  This contradicts a MUST in RFC8407.

okay, got it, fixed it.

    > Author: Kent Watsen Author:

Fixed.

    > Toerless Eckert I note that the e-mail addresses for the YANG module
    > are the same as those for the YANG module in RFC8366; I do not know
    > which are correct.

People moved to different companies since publication :-)

    >   contact "WG Web: <http://tools.ietf.org/wg/anima/> should be https:
    > and usually points to datatracker.ietf.org not tools

Fixed.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: tom petch <[email-masked]>
Date: Tue, 29 Oct 2019 09:44:09 +0000

seeing if I can switch from ietf to Last Call
inline

Tom Petch

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
Sent: Monday, October 28, 2019 10:06 PM

> I think that this will have affects on the constrained-voucher
document, but

I would go for 'vchr' since voucher is 'vch' in RFC8366 and 'r' can then
mean request. but then the voucher extension is 'vcj'.  So, just a
personal preference for 'vchr'; else ok for this e-mail

Tom Petch

---

From: tom petch <[email-masked]>
Date: Tue, 29 Oct 2019 11:49:39 +0000

Michael

I just saw -29 after my last message and it still needs work.

Appendix C confuses me.  The reference to it from IANA Considerations
suggests that it is Normative but there is nothing in it to say that it
is and my take is that by default it is Informational.

It contains a YANG module which
- lacks references on import statements
- lacks authors
- lacks copyright
- is not listed in IANA Considerations
- has http: not https:
- has a reference clause with a different title to that of the I-D
- mixes URI and URL
all in 35 lines :-)

The YANG module in s.3.4
- references RFC8040 which is not in the I-D References
- references
  Voucher Profile for Bootstrapping Protocols
whereas this I-D has a title of
  Bootstrapping Remote Secure Key Infrastructures (BRSKI)
- has
  // Grouping defined for future usage
whereas the grouping is used in the previous YANG statement which leaves
me puzzled
- lacks YANG reference statements for
          leaf proximity-registrar-cert {
i.e. RFC5280, X.690, RFC8446
- has [RFC8446] which looks like an XML/HTML anchor where a YANG module
must be plain text

- IANA Considerations does not register either module, 3.4 or Appendix
C, as per RFC6020 s.14

- Security Consideratrions does not include the required YANG
considerations which in turn generates further Normative References

- Appendix A
/The secification/The specification/

Tom Petch

----- Original Message -----
From: "tom petch" <[email-masked]>
To: "Michael Richardson" <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>; "Alissa Cooper" <[email-masked]>; "Last Call"
<[email-masked]>; "Dan Romascanu" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, October 29, 2019 9:44 AM

> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call