Subject: [Gen-art] 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: 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: 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