[Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 04 December 2018 06:28 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86ACD127B4C; Mon, 3 Dec 2018 22:28:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-netconf-zerotouch@ietf.org, Mahesh Jethanandani <mjethanandani@gmail.com>, Bert Wijnen <bwijnen@bwijnen.net>, Bert Wijnen <bwietf@bwijnen.net>, netconf-chairs@ietf.org, mjethanandani@gmail.com, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154390493154.31734.13025584839857369253.idtracker@ietfa.amsl.com>
Date: Mon, 03 Dec 2018 22:28:51 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/a0vUuE6UmDS4Wxv16cNPbCxG7X0>
Subject: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2018 06:28:52 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netconf-zerotouch-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


First off, thanks for this clear and considered document and design; it
really lays out the scenario of applicability and the functionality quite
well.  I just have a couple lingering places that we might want to nail
down a little bit tighter...

(1) SSH key formats

The module in Section 7.3 says:

           leaf-list ssh-host-key {
             type binary;
               "The binary public key data for this SSH key, as
                specified by RFC 4253, Section 6.6, i.e.:

                  string    certificate or public key format
                  byte[n]   key/certificate data.";
               "RFC 4253: The Secure Shell (SSH) Transport Layer

but RFC 4523 Section 6.6 says:

   The key type MUST always be explicitly known (from algorithm
   negotiation or some other source).  It is not normally included in
   the key blob.

   Certificates and public keys are encoded as follows:

      string    certificate or public key format identifier
      byte[n]   key/certificate data

How is the key type known for the SZTP usage?

(2) Privilege escalation by design

There's text in Section 2.1 (and, really, throughout) that indicates that a
device being boostrap should allow a trusted bootstrap server to behave as
(i.e., supply) a trust anchor for verifying a different service.  In some
sense this is elevating an EE cert to a CA cert, and I had hoped to see
some discussion of this escalation in the security considerations.  (Same
for the owner cert, though there's a stronger argument that the owner
should be considered fully privileged here.)

(3) Nonce length

Section 7.3 describes the nonce leaf:

         leaf nonce {
           type binary {
             length "8..32";

There is probably some discussion to be had about the minimum nonce length
(not necessarily in the document itself).  Do you have a pointer handy to
previous disucsions or do we need to have it now?
(I do see that this is just following RFC 8366, so hopefully this is an
easy question.)

(4) OPTION_V4_ZEROTOUCH_REDIRECT repeated instances

(In Section 8.1.)

I think I may just be misunderstanding things here, but aren't

   As the list of URIs may exceed the maximum allowed length of a single
   DHCPv4 option (255 octets), the client MUST implement [RFC3396],
   allowing the URI list to be split across a number of
   OPTION_V4_ZEROTOUCH_REDIRECT option instances.


   The DHCPv4 server MAY include a single instance of Option
   OPTION_V4_ZEROTOUCH_REDIRECT in DHCP messages it sends.  Servers MUST
   NOT send more than one instance of the OPTION_V4_ZEROTOUCH_REDIRECT

in conflict about sending more than one instance of


Should we consider recommending AuthEnvelopedData throughout instead of
just EnvelopedData?

TLS and CMS are probably good enough about adding context in their
signatures (well, provided modern versions are used) that we don't get too
much heartburn about reusing the same key directly for both zerotouch
decryption and TLS client certificates, but it's generally the sort of
thing that we frown upon.

I a little bit wonder if we want references for TLS and/or HTTP client
authentication.  Section 2.5 of RFC 8040 might be enough (though it is of
course not citing TLS 1.3).

(Are there generic RESTCONF internationalization considerations?  I see
8040 say "just use UTF-8", but is more needed?)

Section 1.2

   Network Management System (NMS):  The acronym "NMS" is used
       throughout this document to refer to the deployment specific

nit: deployment-specific (with hyphen)

Section 2.1

Does RFC 8340 require a "ro" (or similar) to appear in the tree diagram?
(Both here and in §2.2.)

Section 3.2

Do we want to impose any ordering requirements on the certificate chain
(e.g., owner cert must come first, each cert SHOULD certify the one
immediately prior to it, etc.)?

Section 3.4

Thank you for including the motivating text about sign-then-encrypt.  I do
wonder if it's worth saying anything about why the well-publicised security
risks of mac-then-encrypt do not apply.  (The authors of
draft-campbell-sip-messaging-smime probably already have some text that
could be used, but it doesn't seem to be in the public view yet.)

Section 4.1

Mounting all filesystems found on removable devices can be a security risk,
with intentionally malformed filesystem images causing system compromise in
some cases.

Section 4.2

I agree with Adam about registering "zerotouch" (and the name is perhaps
overly generic?).

I'm also not sure I properly understand the "zt-info"/zt-* TXT records'
usage; would they need to be registered akin to

Section 5.3

This is the first time we talk about "serial number" as device identity;
maybe a forward-reference is in order?

Does the device have any reason to track whether the incoming artifact is
encrypted (whether at the CMS layer or the transport layer)?  I can't think
of one, but sometimes this is useful information in other settings.

   If the zero touch information artifact contains onboarding
   information, and trust-state is FALSE, the device MUST exit the
   recursive algorithm (as this is not allowed, see the figure above),
   returning to the bootstrapping sequence described in Section 5.2.
   Otherwise, the device MUST attempt to process the onboarding
   information as described in Section 5.6.  In either case, success or
   failure, the device MUST exit the recursive algorithm, returning to
   the bootstrapping sequence described in Section 5.2, the only
   difference being in how it responds to the "Able to bootstrap from
   any source?" conditional described in the figure in the section.

Does this "either case" refer to just the processing of onboarding
information, or the exit vs. attempt to process cases?  (I assume the
former, but perhaps some editorial work is in order.)

   If the zero touch information artifact is signed, and the device is
   able to validate the signed data using the algorithm described in
   Section 5.4, then the device MUST set trust-state to TRUE; otherwise,
   if the device is unable to validate the signed data, the device MUST
   set trust-state to FALSE.  Note, this is worded to cover the special
   case when signed data is returned even from a trusted bootstrap

Having read Section 5.4, I'm still unsure where the special handling for
this special case is described.

Section 5.5

   Processing redirect information is straightforward, the device
   sequentially steps through the list of provided bootstrap servers
   until it can find one it can bootstrap from.

nit: I think this is a comma splice.

Section 5.6

                                                Regardless the
   reporting-level indicated by the bootstrap server, the device MAY
   send progress reports beyond the mandatory ones specified for the
   given reporting level.

nit: "Regardless of"

   When the onboarding information is obtained from an untrusted
   bootstrap server, the device MUST NOT send any progress reports to
   the bootstrap server.

I'm not sure if I would want a parenthetical "(that is, the onboarding
information was authenticated at the CMS layer)", but I would think about
adding one.

   The device MUST parse the provided onboarding information document,
   to extract values used in subsequent steps.  Whether using a stream-
   based parser or not, if there is an error when parsing the onboarding

This line makes me consider the scenario where a stream-based parser is
used with a trusted bootstrap server and no CMS-layer signature.  At the
TLS layer, a truncation attack by the network is possible, and if
truncation is not detectable at the application layer, the device could end
up misconfigured with neither party aware (unless there's an additional
response or something that I'm forgetting about).  I think that for the XML
and JSON formats we know and love, truncation would make for a malformed
stream due to the outermost scope container, but please correct me if I'm
wrong.  There are probably some security considerations to mention w.r.t.
any future new encodings of this data model, though.

      *  Most steps are atomic.  For instance, when a commit fails, it
         is expected to have no impact on the configuration.  Similarly,
         if the error occurs when executing a script, the script will
         gracefully exit.

As a reader it's hard to tell if this is giving guidance to script authors
or consumers.

Section 6.2

"base64encodedvalue==" is pretty cute, though maybe we could add some
trailing numbers to provide different values for the different fields?

Section 6.3

The YANG module boilerplate is still on the RFC 2119 version of BCP 14 (not
RFC 8174).

Section 7.2

If we're going to say "and receives signed data in the response", maybe we
could actually give an example that shows the (base64'd) CMS structure that
corresponds to the signature?  Not necessarily the whole payload, but
enough to see the outer structure at least...

Section 7.3

The YANG module boilerplate is still on the RFC 2119 version of BCP 14 (not
RFC 8174).

             enum "boot-image-installed-rebooting" {
                 "Indicates that the device successfully installed
                  a new boot image and is about to reboot.  After
                  sending this progress type, the device is not
                  expected to access the bootstrap server again.";

Is this just scoped to the current connection/session?
(As opposed to "bootstrap-complete", which probably is a global statement.)

   container trust-anchor-certs {
               The CMS MUST contain only a single chain of
               certificates.  The device's end-entity certificate
               MUST only authenticate to last intermediate CA
               certificate listed in the chain.

I'm not sure whether "authenticate to" means that the CA cert directly
certifies or is the trust anchor.  Could we maybe use language like
"directly certifies the [next|previous]" certificate?

Also, the split of references of RFC 6187 for trust-anchor-certs but RFCs
5280 and 5652 for trust-anchor-cert seems unusual, since potentially all
three would be relevant for both nodes, if I understand correctly.

Section 9.1

At this point draft-ietf-ntp-using-nts-for-ntp exists, though I don't know
whether it's appropriate to be citing it yet.

Section 9.6

There is perhaps some room for discussion of the consequences of the device
telling the bootstrapping server whether the device thinks the connection
is trusted, in that it gives an attacker information about the target.
(Granted, it does not seem like much information, but it might be cleaner
to define the semantics of the node as being whether the client would like
the server to sign its responses at the application layer, which need not
have complete overlap with whether the client considers the server to be

Section 9.8

Does recommending frequent private key refreshes actually help in
environments where revocation is unusable (i.e., by virtue of not having
reliable time)?  (If not, perhaps that caveat should be more explicit here,
even though it is mentioned in Section 9.1 already.)

Section 9.10

I would suggest also mentioning the (lack of) mitigations possible if the
operator does not trust all the pre-configured authorities designated by
the manufacturers.

Section 9.11

      revealing (e.g., network topology, firewall policies, etc.).  It
      is RECOMMENDED that operators encrypt the bootstrapping data when
      its contents are considered sensitive, even to the administrators
      of a bootstrap server.

I don't understand what is meant by "even to the administrators of a
bootstrap server"?

Section 9.12

nit: the last word is "revoked".

Section 9.13

   Implementations should be aware that signed bootstrapping data only
   protects the data from modification, the contents are still visible
   to others.  [...]

nit: this is a comma splice

   information should be considered sensitive and precautions should be
   taken to protect it (e.g., encrypt artifact with device public key).

nit: I think it's more conventional to "encrypt to" a public key than
"encrypt with" one.

Section C.3

We could perhaps recommend ecdsa-sha2-* keys instead of ssh-rsa keys.

   4.  Otherwise, if redirect information is found, the device iterates
       through the list of specified bootstrap servers, checking to see
       if it has bootstrapping data for the device.  [...]

The "it" is perhaps ambiguous; I would suggest "each server in turn".