Subject: Re: [Netconf] WGLC on zerotouch draft

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 Nov 2017 14:55:46 +0100 (CET)

Hi,

I have reviewed version -19, and checked that my previous comments are
addressed.  Here are my comments on this version:

o  Section 2.2

  Tree diagram is out of date.

o  Section 5.1, item 1

  Add reference to the new module ietf-zerotouch-device, maybe tweak
  the text?

o  Section 6.2

  The example has:

         "ietf-device:zerotouch" : {
           "enabled" : false
         }

  This should be:

         "ietf-zerotouch-device:zerotouch" : {
           "enabled" : false
         }

o  ietf-zerotouch-bootstrap-server.yang

  In the description for "script", you mention 'script-warning' and
  'script-error'.  But they are called 'pre-script-warning',
  'post-script-warning', etc.

  [I made this comment earlier, to which you replied "Will fix", so I
  assume you simply forgot this one.]

o  ietf-zerotouch-bootstrap-server.yang

  The description of the "script" typedef says:

       No attempt is made to standardize the contents, running context,
       or programming language of the script.
       [...]
       The script returns exit status code '0' on success and non-zero
       on error, with accompanying stderr/stdout for logging purposes.

     I think the last quoted sentence contradicts the first - it does in
     fact make assumptions about the running context of the script.

     I suggest the latter sentence is removed, and the rest of the test
     adjusted.  Don't talk about exit codes, but instead talk about
     "success" or "error" etc.

  [I made this comment earlier, to which you replied "Will do", so I
  assume you simply forgot this one.]

o  ietf-zerotouch-bootstrap-server.yang

                enum "ssh-dss" {
                  description
                    "ssh-dss";

  Did you get a warning for a missing description ;-)

o  ietf-zerotouch-information.yang

  I still think that when rc:yang-data is used, it needs to have a
  single container.

  You can easily fix this by defining two separate structures,
  "redirect-information" and "onboarding-information", then define a
  "zerotouch-information" artifact as being one of these two
  structures.

o  ietf-zerotouch-device.yang

    leaf devid-certificate

  Should it be called idevid-certificate?

o  ietf-zerotouch-device.yang

    container bootstrap-servers {
        config false;
        ...
        "Default list of bootstrap servers this device is
         configured to reach out to when bootstrapping.";

  I had to think hard about this one.  I *think* that the idea is that
  this list contains the factory-installed list of bootstrap servers
  defined in section 5.1, bullet 3?

  Maybe rephrase, w/o using the words "default list" and "configured".

o  ietf-zerotouch-device.yang

    leaf bootstrap-server-ta-certificates {

  What does "ta" stand for?

Editorial nit
-------------

o  use "" instead of '' consistently  (except in YANG strings)
  (you fixed some, and then added some new usages of '' :)

/martin

Mahesh Jethanandani <[email-masked]> wrote:
> The zerotouch draft has had a couple of calls for consideration of LC,
> and has over that period cumulatively picked up votes of support. The
> last attempt resulted in a few more issues being raised by Martin,
> which Kent has addressed. That leaves the question of the definition
> of “hash-algorithm” as a base identity in the module and the
> ‘yang-data’ extension statement as it applies to a draft's use of
> 'choice' statement. Since there is no crypto module with
> “hash-algorithm" identities, Kent is leaving the definition in this
> draft. When and if, such a model/identity is defined, we will
> deprecate the definition in this draft. For ‘yang-data’ extension
> statement, we will go with Martin’s suggestion to add this in the
> yang-data-augmentation draft. Please note that that draft is an
> individual draft, but since it is a technical detail, whose solution
> has generally been agreed upon, we feel it should not hold up the LC.
> 
> Since we are dealing with an updated draft, a new LC has to be
> issued. We will count the previous votes of support for this draft in
> addition to any new ones to move the draft forward. This e-mail starts
> that LC and will last 2 weeks. Please indicate support for the draft
> by responding to the e-mails, and if you have objections, indicate
> why. For those that provided feedback before, please ensure your
> comments have been addressed by this version of the draft.
> 
> Thanks. 
> 
> Mahesh Jethanandani (as co-chair)
> [email-masked]
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Thu, 2 Nov 2017 22:18:45 +0000

Hi All,

One of our development teams just received a request from an operator that isn't using a private PKI, and therefore are using a public CA (e.g., GoDaddy).  So, for them, the certificate chain might look like:

   GoDaddy CA
     ^
     |
    Org CA
     ^
     |
    ZTP CA
     ^
     |
  Bootstrap server's TLS cert

Just putting the "Org CA" as the pinned domain cert doesn't work with some common open source utilities, because they don't support what OpenSSL calls "partial chain" verification.  And, of course, putting "GoDaddy CA" as the pinned domain cert would be overly permissive.  What's needed is a way for them to specify the partial chain leading up to and including the root certificate.  So, for instance, in this case, they'd like the redirect server to return the chain:

  GoDaddy CA
     ^
     |
   Org CA

and the bootstrap server's TLS handshake to return:

   ZTP CA
     ^
     |
  Bootstrap server's TLS cert

which provides the TLS client everything it needs to verify the chain.
From a tree-diagram perspective, the change looks like this:

OLD

   +--:(redirect-information)
      +---- redirect-information
         +---- bootstrap-server* [address]
            +---- address         inet:host
            +---- port?           inet:port-number
            +---- trust-anchor?   binary   <-- a single X.509 certificates

NEW

   +--:(redirect-information)
      +---- redirect-information
         +---- bootstrap-server* [address]
            +---- address         inet:host
            +---- port?           inet:port-number
            +---- trust-anchor?   pkcs7  <-- a chain of X.509 certificate

Here's what the diff looks like:

           leaf trust-anchor {
-            type binary;
+            type pkcs7;
             description
-              "An X.509 v3 certificate structure as specified by RFC
-               5280, Section 4, encoded using ASN.1 distinguished
-               encoding rules (DER), as specified in ITU-T X.690.  A
-               certificate that the device can use as the trust anchor
-               to authenticate the bootstrap server the device is
-               being redirected to.  If not specified, the device may
-               establish a provisional connection to the bootstrap
-               server, as described in RFC XXXX.";
+              "This PKCS#7 structure MUST contain the pinned domain
+               certificate and all intermediate certificates leading
+               up to the root certificate, and the root certificate
+               itself.  In cases where the pinned domain certificate
+               is a root certificate, only one X.509 certificate is
+               present.  Additionally, if needed by the device, this
+               structure MAY also contain suitably fresh CRL and/or
+               OCSP Responses with which to verify the revocation
+               status of the certificates.
+      
+               X.509 certificates and CRLs are described in RFC 5280.
+               OCSP Responses are described in RFC 6960.";

We can discuss more in Singapore.

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Sat, 11 Nov 2017 14:49:41 +0000

Hi Martin,

> addressed.  Here are my comments on this version:

Thanks for the follow-up.

>  Tree diagram is out of date.

Fixed.

>  Add reference to the new module ietf-zerotouch-device, maybe tweak

I put the reference to the module up a level (Section 5) as the module
applies to more than just item 1.  Regarding tweaking the text, do you
have a suggestion?

>         "ietf-zerotouch-device:zerotouch" : {

Fixed.  Tool-support for validating yang-data would be helpful.

>  assume you simply forgot this one.]

okay, really fixed this time.

>  assume you simply forgot this one.]

I did edit it before (see the 17 -> 18 diff, but my edit was not what
you had suggested before.  Rather than not talk about exit codes and
what not (which I think is important to fix), I modified the first
sentence to clarify "other than that it can emit an exit status code
and stderr/sdtout".

>  Did you get a warning for a missing description ;-)

Yes, several revisions back, but I take it that you're actually dinging
me for not have a more useful description?  (I just made the descriptions
a little more useful).

>  "zerotouch-information" artifact as being one of these two

Wait, I thought we had an agreement that this draft would switch to
use the new yang-data extension being defined in NETMOD that would
allow for this use of a 'choice' statement.  I will switch to this
yang-data definition now, okay?

>  Should it be called idevid-certificate?

Yes.  That said, an IDevID cert *is* a DevID cert, but that's
not important here.

> Maybe rephrase, w/o using the words "default list" and "configured".

Done.

>  What does "ta" stand for?

"ta" stands for "trust anchor", but I went ahead and s/ta/pinned/ to
make it more consistent with the node the leafref points to.

> Editorial nit

Okay, but what "YANG strings" get the single quotes?

> /martin

Kent // contributor

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=FCQO2THqpwxTGOLcS8CA7NY-PmQidV2Fpe5x_tgOqDg&s=D37jntlIvLFP2McTM-nVEXtCClbeZsIsaTBxNcgy9nQ&e=

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=FCQO2THqpwxTGOLcS8CA7NY-PmQidV2Fpe5x_tgOqDg&s=D37jntlIvLFP2McTM-nVEXtCClbeZsIsaTBxNcgy9nQ&e=

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 13 Nov 2017 15:57:41 +0100 (CET)

Hi,

> applies to more than just item 1.  Regarding tweaking the text, do you

The text has guidelines for how a vendor should define a
"enable zerotouch" variable.  Maybe replace the text with a reference
to the standard module instead.

> sentence to clarify "other than that it can emit an exit status code

But why even talk about exit codes?  The important thing to note is
ensure that the script can either succeed or fail.  For some
background, see https://en.wikipedia.org/wiki/Exit_status.

Also, there's no reason to talk about "stdout/stderr"; just use
"output", esp. since you never refer to just "stderr" or "stdout", but
always as "stderr/stdout".

> me for not have a more useful description?

Yes ;-)

> (I just made the descriptions
> a little more useful).

Good!

> yang-data definition now, okay?

Ok!

> Yes.  That said, an IDevID cert *is* a DevID cert, but that's

Ok.

> Okay, but what "YANG strings" get the single quotes?

Any term in a double quoted string, e.g. 'message' in:

    "Indicates that the device obtained warning messages
     when it committed the initial configuration.  The
     'message' field below SHOULD indicate any warning
     messages that were generated.";

/martin