Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT) Fri, 07 December 2018 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48510128CF2; Fri, 7 Dec 2018 06:36:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mX0eDbsA-fz0; Fri, 7 Dec 2018 06:36:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F17D1252B7; Fri, 7 Dec 2018 06:36:03 -0800 (PST)
Received: from [] ([]) by (mrgmx101 []) with ESMTPSA (Nemesis) id 0LcWSI-1hDifd38uE-00jrjs; Fri, 07 Dec 2018 15:35:55 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
In-Reply-To: <>
Date: Fri, 7 Dec 2018 15:35:53 +0100
Cc: The IESG <>,,, Bert Wijnen <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3445.101.1)
X-Provags-ID: V03:K1:jYMPq4ObG/0FqjOBvBYXUxPVB3MK3mtxtaM5rqfw8mNfr3wRVn3 qTeebSBmbFL8XaIlku6oqZsl1kMnbZ50WZuoXQtlXpntCUZ6mI0fpA+zYb51e+MW7fFyiyE sfEGKupvobEwxe7SVVMVh+bYQedMAxG8UPlFw5GJJwWo2Y5EuwBcn8zBfC6eJeMo/vgJpEO 3umQSN4Ss+D+9N8JMorfQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:QDdQNOlj9iI=:nHxAvaW9VWaoMoEXKy3jcu 474TUI/WjWgoCMvJ/nnVaoC8GGkJ22N9D9IxyG+lpUd4mGdM3ShZz2xondGZh6HyM4eXnNXTX esS8QuyYObh9atXvjGAcIWlAfUBuPu2qyWWFq6AAjjFicpNgjvcyRObRP+DDAzJMo8+PMl+y3 C2pcDyv46Pip+EOVt9hj5G0qTY65GJF87z+Z//SmxR8TOlpxRn47tyycUTqvBLeB4YjZNlM3t AljXPkwwRpRPGCvMgkvi6erYdw28MjqTZs5oVmcdMJGuNQsfPY3ADwljCB13H4oRUZlm8bXmD 7OYHH/H/wVKHQSXGvLfhU+0O2wb3uouY4IvHPUynfligqpladJOJUzcLZ+SlDqqZiBzhWSXyX mIOwB7ON/vvjHSakGU67F2nWBFMgPaS9el7Mbfwujh6yErHsUlZBxCL/XbY76HruzD6iS2w5b Ls+VGLAe68a7WzihUK/2KXl2yThHKVGXgQU6fQLIPVYLv+0C9cJXWMDxFBs9Z4ONhMktSt54q lKnr07tvf0Z3t1lo17BrVBU1uBuIho4adXWAJ63Pb4U8l794tfD7N06enBixP2QHH0Lyx4E3i EfyWBNGARxtCl8n5PRKmyDSwb+It7yR19QzNgcPlrPzYD3rerCPw4lp/X//FHhS4jXBDT+nuw vp4pqv9REinzAOkYE07TnEsU0t8NlkhWyTeUwM5pl5q1YETgx5Kbr9E15keIWf7FFUaKzx9K0 KHrHQ6IheQdYnIsGUzn9EecvsmlI8Jx9stvwOMa4OIT2X6IT5cgpHQH1rvy96ogtNun44sDSq yhntpgjPMC4VZtKZfoFMXzfQRkpkyE6qzzFgT+c8ktqToVc9Hkomt+1KpaTPMQ7EBzAUQlmXo dBGfGf9xs/uUWMTCkRgMnZYB5k2OyVWXL1h8nhddmejLyRJ17jsPCeifbEl+ki
Archived-At: <>
Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Dec 2018 14:36:07 -0000

Hi Ben,

Thanks for the comments. Please see below, specifically regarding your
point on the DHCP section (8.1).


> On 4. Dec 2018, at 07:28, Benjamin Kaduk <> wrote:
> 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
> 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;
>             description
>               "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
>                            identifier
>                  byte[n]   key/certificate data.";
>             reference
>               "RFC 4253: The Secure Shell (SSH) Transport Layer
>                          Protocol";
> 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.
> and
>   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
>   option.
> in conflict about sending more than one instance of

[if - Yes, the current text is not consistent between client and server. I propose
replacing the server paragraph with the following:

          The server’s DHCP message MUST contain only a single instance of the
          OPTION_V4_ZEROTOUCH_REDIRECT’s 'bootstrap-server-list’
          field. However, the list of URIs in this field may exceed the maximum
          allowed length of a single DHCPv4 option (per [RFC3396]).

          If the length of 'bootstrap-server-list’ is small enough to fit into
          a single instance of OPTION_V4_ZEROTOUCH_REDIRECT,  the server MUST NOT
          send more than one instance of this option.

          If the length of the 'bootstrap-server-list’ field is too large to
          fit into a single option, then OPTION_V4_ZEROTOUCH_REDIRECT MUST be
          split into multiple instances of the option according to the process
          described in [RFC3396].

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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
> draft-moonesamy-dnsop-special-use-label-registry?
> 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
>   server.
> 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" {
>               description
>                 "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
> trusted.
> 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
>                                                         This
>   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".
> _______________________________________________
> Netconf mailing list