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

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 03 Dec 2018 22:28:51 -0800

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:
https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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
OPTION_V4_ZEROTOUCH_REDIRECT?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: [email-masked]
Date: Fri, 7 Dec 2018 15:35:53 +0100

Hi Ben,

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

Thanks,
Ian

> On 4. Dec 2018, at 07:28, Benjamin Kaduk <[email-masked]> wrote:
> 

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

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Sat, 8 Dec 2018 02:46:11 +0000

Hi Benjamin,

Thanks for your review!  See below for responses.

It took me quite some time to compose this response; I can only imagine
how long it took you to compose your message.

For when I write "Fixed", or otherwise indicate a change has been made,
unless stated otherwise, I mean to say that the changes are in my local
copy (not yet in a published update).

Kent // author

Good catch.  The fix here is to mimic RFC7317's "authorized-key" list.
That is, convert "ssh-host-key" from a "leaf-list" to a "list"
containing the extra "algorithm" node.  This fix is here:

https://github.com/netconf-wg/zero-touch/commit/7a33c418f733aebcd95f2c91c4e9abbccfd362e4

> There's text in Section 2.1 (and, really, throughout) that indicates that
> a device being bootstrapped 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.)

Correct, "redirect information" from a trusted source should contain a
trust-anchor certificate (actually, a CMS containing a chain of certs).

Yes, the device's trust in a TLS trust anchor cert (e.g., provided via the
manufacturing process) is used to trust the EE cert for a bootstrap 
server that returns a new trust anchor cert, enabling the device to 
pin the new TA cert for subsequent EE cert validation.  

This is similar to a CA in that a chain of trusted certs is formed, but
it isn't quite like a CA cert, in that the EE cert doesn't itself sign
the new TA cert; it only signs that transport used to convey the TA cert.

Regarding the owner cert being similar, I think you mean that the 
ownership voucher [RFC 8366] is similar, which is true.  In this case,
the device's trust in a trust anchor for voucher-signing certs (e.g., 
provided via the manufacturing process) is used to trust a specific
signing cert for a voucher, which encodes a new trust anchor cert 
(the 'pinned-domain-cert'), which is, in fact, the issuing CA for
the owner certificate.

Okay, so we have these two things.  In both cases, trust anchors are 
conveyed via trusted mechanisms.  Do you want me to add a Security
Consideration saying this?  

I somehow thought this concept was fairly common, is it not done 
elsewhere?

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

I sent email to my RFC 8366 co-authors, as they were behind setting
this min nonce length.  I have yet to hear back from them, but will
let you know when I do.

> OPTION_V4_ZEROTOUCH_REDIRECT?

Yes, these statements appear to be contradictory.  I asked my co-author,
Ian Farrer, our local DHCP expert, to answer this question.  I think some
word-smithing is needed to convey that a "singleton" option may be split
into pieces.

> Should we consider recommending AuthEnvelopedData throughout instead
> of just EnvelopedData?

I don't think this is necessary as 1) the decrypted data can be tested
to be a well-formed CMS and 2) using SZTP to cause the device to act as a
decryption oracle doesn't work well, if at all, as the decrypted text
isn't subsequently made available.

> signatures (well, provided modern versions are used) that we don't
> get too much heartburn about reusing the same key directly for both
> zerotouch [artifact] decryption and TLS client certificates, but 
> it's generally the sort of thing that we frown upon.

Understood, which is why the last paragraph of Section 3.4 (Artifact
Encryption) says "This [encryption] certificate MAY be the same as 
the TLS-level client certificate the device uses when connecting to
bootstrap servers.".  The draft is going out of its way to say that
this is okay.  This is necessary, in part, because devices tend to
have only a single IDevID certificate, and hence it tends to be used
for both digitalSignature (for when used as a TLS client cert) and
keyEncipherment (for decrypting the zerotouch artifacts).  The draft
also leaves open the possibility to use distinct certificates for
each purpose.  Perhaps a Security Consideration for this would be
good?  [But given that these are distinct/separate uses, with no
leakage between (AFAICT), then maybe not needed?]

> authentication.  Section 2.5 of RFC 8040 might be enough (though it is
> of course not citing TLS 1.3).

This draft's use of TLS and HTTP authentication is exclusively for
RESTCONF (RFC 8040).   I'm generally hoping to just reference that
RFC and let it speak for itself.

Correct, RFC 8040 does not cite TLS 1.3 explicitly, though TLS 1.3 is
allowed, as Section 2.1 says:

   RESTCONF does not require a specific version of HTTP.  However, it 
   is RECOMMENDED that at least HTTP/1.1 [RFC7230] be supported by all
   implementations.

BTW, does this comment regard Section 9.6?  

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

I'm not aware of any problems here.  No RFC 8040 errata has been filed.
Is there something in particular you're thinking about?

> nit: deployment-specific (with hyphen)

Fixed (as well as the instance in Section C.2)

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

No, because these are "yang-data" structures.
https://tools.ietf.org/html/rfc8340#section-2.3.

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

The owner certificate is encoded using a CMS SignedData structure.
SignedData is defined in RFC 5652, 5.1.  The "certificates" field
is of type "CertificateSet", defined in Section 10.2.3 as a "SET OF",
which is defined in ASN.1 as an unordered collection.  So, ordering
is not possible.

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

Are you referring to the padding oracle attack?  As mentioned above, the
solution presented in this document doesn't lend the device to being a
very good decryption oracle.  I suppose the fix would be to add to this
section (or the Security Considerations section?) something like:

  This document specifies the encryption of signed objects, as opposed
  to the signing of encrypted objects, as might be expected given well-
  publicized oracle attacks (e.g., the padding oracle attack).  This
  document does not view such attacks as being feasible in the context
  of the solution because i) the decrypted text never leaves the device
  and ii) the solution does not differentiate between a "bootstrap-error"
  cause by a decryption failure versus a failure occurring when parsing
  the decrypted text.

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

Is the concern the mounting of *all* or *any* filesystems?  It seems 
that even if there were just one filesystem, it could be intentionally
malformed.  Are you hoping to see a Security Consideration for this?

> 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

First, regarding the term "zerotouch" being perhaps overly generic,
I have somewhat felt this way for a while.  One thing that could be
done fairly easily is to more the bulk of the "zerotouch" references
to "sztp", the acronym given throughout.  Admittedly, what SZTP
stands for isn't tremendously better, but I think that it is
generally better than just "zerotouch".  Thoughts?

Second, I am not a DNS expert, do you know who we can discuss
such things with?  That said, I guess our idea was to use TXT
records like RFC 1464, where the TXT value itself has the form
"<attribute name>=<attribute value>", in which case it doesn't
seem to need IANA registration?

> maybe a forward-reference is in order?

I'm unsure what the forward reference would be to.  However, I think that
we could add "serial number" to Section 5.1 (Initial State), as a new
first item in the <read-only storage> box.  Would that be better?

> of one, but sometimes this is useful information in other settings.

I also cannot think of a reason.  That the incoming CMS is encrypted has
no bearing on device's processing logic.  This is expected, given that the
device's public key is, well, public, and therefore access to it has no
special meaning.  Note that encryption here is used to ensure privacy, as
only the device can decrypt/access the data.

> former, but perhaps some editorial work is in order.)

Your intuition is correct :)   How about this:

  OLD:
    In either case, success or failure, ...

  NEW:
    Whether the processing of the onboarding information succeeds
    or fails, ...

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

There is no special handling per se but, the point that is trying 
(perhaps ineffectually) is that, if signed-data is received from a
trusted-source, validating the signature is all that matters, that
the source was trusted becomes irrelevant to being able to validate
the data.  Makes sense now?  Does it need to be reworded?

> nit: I think this is a comma splice.

Changed to a semicolon.

>   send progress reports beyond the mandatory ones specified for the

Fixed.

> information was authenticated at the CMS layer)", but I would think about

How about postpending:

  ", even though the onboarding information must have been signed and
   authenticated.  Please be aware that bootstrap servers are recommended,
   in the last paragraph of Section 9.6, to promote untrusted connections
   to trusted connections so as, in part, to be able to collect progress
   reports from devices."

Too wordy, or just right?

> any future new encodings of this data model, though.

The steps are roughly: 
  a) HTTPS GET an XML/JSON document (the get-bootstrapping-data" response).
  b) extract the CMS-based artifacts from the XML/JSON document.
  c) if encrypted, decrypt.
  d) if signed, authenticate.
  e) extract the onboarding-information (another XML/JSON doc) from the CMS artifact.
  f) process the onboarding-information XML/JSON doc

So here we're at step (f), where the text mentions the possible use of a
stream parser.  This is rather long after step (a), where TLS truncation
may occur and, presumably caught in step (b).  This is by way of saying
that I don't think this is an issue, but interested to hear your response.

FWIW, the point of this "stream-based parser" comment is to highlight
that, unlike most all the other progress-types, which seem to reflect
a serial processing of the steps, the parsing may either be a distinct
step (e.g., a DOM-based parser) or something that is splayed across all
the other steps (a stream-based parsed).  In the first case, the all
the "parsing-*" progress reports (including any parsing-error report)
are expected to be transmitted before any, e.g., boot-image-* reports
are sent; whereas, in the second case, the parsing-* reports can be
intermixed.

I don't think there is a TLS concern, but perhaps the paragraph needs
to be reworded?

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

Is this better?

   Most steps are atomic.  For example, the processing a configuration
   is specified as atomic above, and the processing of scripts are
   similarly atomic, as specified in the "ietf-zerotouch-information"
   YANG module.

> trailing numbers to provide different values for the different fields?

The issue here is that the example documents must be valid (fwiw, they
are tested each time `xml2rfc` is run).  Previous versions of this 
document included compete base64 encoding of the real objects, but 
people complained that it greatly distracted from readability.  To
address this, the WG agreed to use "base64encodedvalue==" in examples
to represent YANG "binary" data.

Is it okay to leave this as is?

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

Fixed. Now both YANG modules read:

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
    "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 
    "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document
    are to be interpreted as described in BCP 14 [RFC2119]
    [RFC8174] when, and only when, they appear in all
    capitals, as shown here.

> enough to see the outer structure at least...

See previous response regarding "base64encodedvalue==".  It's tricky
business.  That said, in a separate "expert review" response from Russ
Housley, we were thinking to add an appendix section containing all
the possible ASN.1 structures.  For instance:

  X. ASN.1 for Various Artifacts
  X.1. Zero Touch Information
  X.2. Signed Zero Touch Information
  X.3. Encrypted and Signed Zero Touch Information
  X.4. Owner Certificate
  X.5. Encrypted Owner Certificate
  X.6. Ownership Voucher
  X.7. Encrypted Ownership Voucher

Would this bridge the gap for you?

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

Yep, fixed along with the fix to the other YANG module.

> (As opposed to "bootstrap-complete", which probably is a global statement.)

Yes, just the current scope. how about the following? - or should the last
sentence be left off?

              "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
               for this bootrapping attempt.  The device may
               access this bootstrap server after rebooting
               and restarting the zerotouch bootstrapping
               process.";

>               MUST only authenticate to the last intermediate CA

This text is trying to say that the "last certificate" is the issuer of
the device's end-entity certificate.  More generally, it's trying to say
that there are no superfluous certificates in the CMS.  Perhaps:

NEW:
               The CMS MUST contain only a single chain of
               certificates.  The last certificate in the chain
               MUST be the issuer for the the device's end-entity 
               certificate.

> three would be relevant for both nodes, if I understand correctly.

True, but my general goal is to have the "reference" statements support
the "description" statements.  So, in this case, the parent node mentions
RFC 6187, hence I put the "reference" for it there.  Does it still seem
unusual to you?

> whether it's appropriate to be citing it yet.

How about tacking on this last sentence, and list ietf-ntp-using-nts-for-ntp
as an Informative reference?
 
          Implementations SHOULD NOT rely on NTP for time, as
          NTP is not a secure protocol at this time.  Note, there
          is an IETF work-in-progress to secure NTP
          <xref target="I-D.ietf-ntp-using-nts-for-ntp"/>.

> have complete overlap with whether the client considers the server to be

Hmmm, I agree with the optics.  Perhaps we could change it to "signed-data-
preferred"?  Keep in mind that signed-data isn't required, as it would be
okay for the server to return unsigned redirect information.  It's only if
the data is onboarding information that it would need to be signed.

> even though it is mentioned in Section 9.1 already.)

Good catch.  How about adding the last two lines below?
 
          Bootstrap server administrators are RECOMMENDED to follow best
          practice to protect the private key used for any online operation.
          Use of a hardware security module (HSM) is RECOMMENDED.  If an 
          HSM is not used, frequent private key refreshes are RECOMMENDED,
          assuming all bootstrapping devices have an accurate clock (see
          <xref target="clock-sens"/>).

> operator does not trust all the pre-configured authorities designated by

How about adding the last sentence below?

          Operators should be aware that this system assumes that they trust
          all the pre-configured bootstrap servers and voucher signing authorities
          designated by the manufacturers.  While operators may use points in
          the network to block access to the well-known bootstrap servers, 
          operators cannot prevent voucher signing authorities from generating
          vouchers for their devices.

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

Here I'm thinking that the bootstrap server may be hosted by a 3rd-party,
or another group within the operator's organization.  For example, the
NOC generates the artifacts, but IT admins the bootstrap server boxes.

Any need for an update to this text?

> nit: the last word is "revoked".

Fixed.

> nit: this is a comma splice

Fixed.

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

How about "encrypt the artifact using the device's public key"?

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

Replaced "ssh-rsa key" with "SSH public key"

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

Replaced "it" with "bootstrap server"

Thanks again!
Kent

---

From: Kent Watsen <[email-masked]>
Date: Mon, 10 Dec 2018 21:34:34 +0000

Hi Ben,

> this min nonce length.  I have yet to hear back from them, but will

I received the following response from one of my RFC 8366 co-authors:

  ===start====
  I think we wanted something that was big enough to have some 
  reasonable entropy.  But, we didn't want to force receivers to
  store too much.

  More than 32-bytes shouldn't be a problem for most receivers, but
  we wouldn't expect them to accommodate kilobytes.  The registrar
  may need to store an index over nonce values for some situations.
  ===stop===

Does this resolve this DISCUSS item?

Kent // coauthor

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 29 Dec 2018 13:03:54 -0600

> Does this resolve this DISCUSS item?

I agree that 32 bytes of entropy should be plenty and we don't want to ask
endpoints to store kilobytes.  My uncertainty is more at the other end,
whether 64 bytes is enough for defending against all the possible attacks
that may be in scope.  In general, it's simplest to just require a 128-bit
(or larger) nonce, but there is certainly a reasonable argument to make
that in some cases 64 bits is enough and the difference is important for
the low-end systems.

For example, if we're only concerned about a device possibly generating the
same nonce value twice, and an attacker storing+replaying the old response,
then 64 bits should be enough.  But if the attacker can (even off-path) try
to spoof response and collide the nonce value to trick the device into
accepting the spoofed reply, then 128 bits are needed, for our usual
security margins.

I don't want to insist that you include a discussion of the various attacks
and security margins in this document, which is not really the place for
it.  But it might be good to recommend at least 16 bytes of nonce (or even
make the minimum bound 16 bytes, if appropriate).

My apologies for not making the concern more clear in the original ballot
position, especially with the long delay cycle for responses.

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 29 Dec 2018 18:30:03 -0600

Hi Kent,

Now that I'm mostly back from vacation+holidays, let's get back to this...

> copy (not yet in a published update).

Understood.

> https://github.com/netconf-wg/zero-touch/commit/7a33c418f733aebcd95f2c91c4e9abbccfd362e4

Sounds good.

> I somehow thought this concept was fairly common, is it not done 

It is fairly common, but it is probably still worth describing the security
properties of the protocol exchanges, here.  (In that a compromise of the
initial interaction can result in compromise of all subsequent
interactions, just as for trust-on-first-use.)

> this min nonce length.  I have yet to hear back from them, but will

[covered in separate thread]

> word-smithing is needed to convey that a "singleton" option may be split

If memory serves, this was resolved in a different AD's ballot thread.

> isn't subsequently made available.

I'm not sure that (2) is relevant, but (1) and being a SignedData ought to
be enough.  Thanks for thinking it through with me.

> leakage between (AFAICT), then maybe not needed?]

I would suggest (recalling that this is a non-blocking comment) adding some
text that this does allow for reuse of the private key to make different
types of signatures, but there are not any known ways to cause a signature
made in one context to be (mis)interpreted as valid in the other.

> BTW, does this comment regard Section 9.6?  

Section 9.6 is about making sure the client does not send sensitive data to
an unauthenticated server, which is not limited to the data in the
certifcate; my comment here is more about the mechanics of the client
authenticating itself to a server for the server to make authorization
decisions (admittedly, I did not mention "authorization" prior to now, so
my apologies for being unclear).  Client authentication is mentioned
directly or in passing in at least sections 5.1 (which does mention Section
2.5 of RFC 8040 already) and 5.3 (ditto), as well as 9.6.

> Is there something in particular you're thinking about?

Nothing in particular, no.  

> https://tools.ietf.org/html/rfc8340#section-2.3.

Ah, thanks for the pointer -- learn something every day.

> which is defined in ASN.1 as an unordered collection.  So, ordering

Okay.

> Are you referring to the padding oracle attack?  As mentioned above, the

Right.

>   cause by a decryption failure versus a failure occurring when parsing

That works for me, thanks.  (But feel free to leave it out if you don't
think it's adding value, too.)

> malformed.  Are you hoping to see a Security Consideration for this?

The concern was any, thanks for figuring out what I meant.
Thinking about this again after the long gap, it seems a pretty generic
consideration, so it's unclear that Security Considerations text in this
document specifically would be particularly helpful.

> generally better than just "zerotouch".  Thoughts?

SZTP does seem better than just "zerotouch" to me, all things considered.

> seem to need IANA registration?

Please correct me if I'm wrong, but I think this issue was already covered
in a different AD's ballot thread.

That said, the addition of <serial number>._zerotouch.fqdn in the -26 seems
to indicate that mention of draft-ietf-dnsop-attrleaf is appropriate, if I
remember correctly how that works.

> first item in the <read-only storage> box.  Would that be better?

It looks like -26 added some text relating "serial number" and "device
identity [certificate]", so let's call this OBE.

> only the device can decrypt/access the data.

Agreed.

>     Whether the processing of the onboarding information succeeds

SGTM :)

> the data.  Makes sense now?  Does it need to be reworded?

It does make sense now, and I don't think it needs to be reworded -- thanks
for the extra explanation.  (I was mostly concerned that there was a
special case that I wasn't finding in the text, but the existing text
describes exactly what to do, so it's alll good.)

> Too wordy, or just right?

I am prone to being too wordy myself, but that seems just right to me.

> I don't think there is a TLS concern, but perhaps the paragraph needs

I think your understanding basically matches mine; I tried to include in my
remark that it would only possibly apply to the case where the predicates
for (c) and (d) are false.  I just plain don't know whether (a)/(b) will
choke if the GET response is an incomplete XML/JSON document.  If it
properly errors out, then there's no concern here, and we should just move
on.  In any case, even if there was an issue, this paragraph would not
really be the place to talk about it -- my comment is only located here
because this is where we start talking about stream-based parsers.  The
errors in question are not necessarily those generated by the stream-based
parser, but can also include those generated at earlier steps.

>    similarly atomic, as specified in the "ietf-zerotouch-information"

Yes, thanks.  (I think the -26 lost both "of"s, though?)

> Is it okay to leave this as is?

This is a non-blocking comment, so by definition my answer is "yes" :)
I mostly just wanted to point out that the examples use the same literal
string to fill in for many different data types -- I agree with not using
"real" examples since they're bulky and not readable in encoded form, but
was just wondering if we could use different short strings to represent
semantically different objects.

> Would this bridge the gap for you?

That would help a lot, thanks!

>                and restarting the zerotouch bootstrapping

Probably the last sentence is not adding anything useful.

>                MUST be the issuer for the the device's end-entity 

That looks wonderful, thanks.

> RFC 6187, hence I put the "reference" for it there.  Does it still seem

Less so; thanks for the explanation :)

>           <xref target="I-D.ietf-ntp-using-nts-for-ntp"/>.

SGTM.

> the data is onboarding information that it would need to be signed.

That works for me.  (It doesn't seem like a big deal either way, of
course.)

>           <xref target="clock-sens"/>).

SGTM.

>           vouchers for their devices.

Perfect :)

> Any need for an update to this text?

Even given the above clarification, I'm still having a hard time not
reading the current text as saying that the administrators of the bootstrap
server are making the determination that content is considered sensitive.
Maybe "even with respect to distribution to the administrators of a
bootstrap server" or "even to the point of hiding it from the
administrators of a bootstrap server"?

> How about "encrypt the artifact using the device's public key"?

Sure.

> Replaced "ssh-rsa key" with "SSH public key"

Even better

> Replaced "it" with "bootstrap server"

Sure.

Thanks!

-Benjamin