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

From: Kent Watsen <[email-masked]>
Date: Sat, 5 Jan 2019 03:05:35 +0000

Hi Benjamin,

Below are several links to individual GitHub commits, but here's the link
to the complete/rendered draft:

	https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-27

Cheers,
Kent

>> > ----------------------------------------------------------------------
>> > 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?
>> 
>> 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
>
> Sounds good.

Excellent - this item is closed.

>> > (2) Privilege escalation by design
>> >
>> > 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?
>
> 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.)

Please let me know if this update addresses the concern:
https://github.com/netconf-wg/zero-touch/commit/a5086b299f60c00afcaddc0ddf0a0e9d3431c04e

>> > (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.)
>> 
>> 
>> 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.
>
> [covered in separate thread]

[Bringing back into this thread]

I emailed the RFC 8366 authors (CC you) regarding your concern with the
minimum-allowed nonce length.

As for this draft, I feel that the easiest solution is to change the YANG
as follows:

       leaf nonce {
         type binary {
-          length "8..32";
+          length "16..32";
         }

It is within the range allowed by RFC 8366 (i.e., no compatibility violation)
while eliminated the low-end that you objected to.  I can't imagine there
being an issue in asking a low-end device (even a measly IoT thing) to generate
an extra 8 bytes of random data.

I've made this change in my local copy.

>> > (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?
>> 
>> 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.
>
> If memory serves, this was resolved in a different AD's ballot thread.

I think you mean this commit by my co-author Ian to address a comment from Suresh: https://github.com/netconf-wg/zero-touch/commit/1c846ca3bc6ce8ffe1813a0c864dc3aebaf3af65.

In either case, we believe the issue is resolved in the current (posted) text.
Here is the direct link: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-26#section-8.

Can this DISCUSS item be closed now?

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

Great - this item is closed.

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

I have added a new Security Considerations section to highlight this reuse: https://github.com/netconf-wg/zero-touch/commit/62076e8421fd286a74519b60e8346dbf78d3c4f2

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

As you say, authentication is mentioned in several places already 
and, if I understand you correctly, this text is sufficient.

While the word "authorization" does not appear in this document, 
Section 9.13 discusses "access", which relates to statements in 
RFC 8040, such as:

   The RESTCONF server MUST authenticate client access to any protected
   resource.

   The server MUST NOT allow any RESTCONF operation for any resources
   that the client is not authorized to access.

To provide a more complete picture, the bootstrap server exposes just
two RPCs.  Each RPC *requires* an authenticated client-credential to
function.  That is, "get-bootstrapping-data" can only return the 
bootstrapping data for the authenticated client credential; there is
no other parameter passed for the server to determine which data to 
return. Likewise, "report-progress" can only report progress for the
authenticated client credential; there is no other parameter passed
for the server to determine for which client is reporting the data.

This COMMENT began by asking if we might want references for TLS 
and/or HTTP client authentication, and now maybe authorization.
Given the above discussion, what is your recommendation?

>> > (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?
>
> Nothing in particular, no.  

Okay, this item seems to be closed then.

>> > 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)
>> 
>> 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.
>
> Ah, thanks for the pointer -- learn something every day.

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

>> > 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
>
> Right.
>
>> 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.
>
> That works for me, thanks.  (But feel free to leave it out if you don't
> think it's adding value, too.)

I added a slightly reduced version of the above text (taking out clause "ii"):
https://github.com/netconf-wg/zero-touch/commit/388d0355b3c7c6ce4aa48028a4ef89dc64147304.

Still good?

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

Okay, let's close this one with no update.

>> > 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?
>> 
>> 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?
>
> SZTP does seem better than just "zerotouch" to me, all things considered.

Okay, I did the following:

  When referring to the draft/solution:
    Zero Touch --> SZTP

  When referring to the bootstrapping artifact:
    zero touch information --> conveyed information
    zerotouch-information  --> conveyed-information

  For the CMS content types:
    id-ct-zerotouchInformationXML  --> id-ct-sztpConveyedInfoXML
    id-ct-zerotouchInformationJSON --> id-ct-sztpConveyedInfoJSON

  For the YANG modules:
    ietf-zerotouch-information.yang      --> ietf-sztp-conveyed-info.yang
    ietf-zerotouch-bootstrap-server.yang --> ietf-sztp-bootstrap-server.yang

  For the DNS/service name:
    _zerotouch --> _sztp

A big change, though I scripted most of it. Here's the diff:
https://github.com/netconf-wg/zero-touch/commit/394b863d1850019fd451554a9f86c3c10d280d08

>> 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?
>
> Please correct me if I'm wrong, but I think this issue was
> already covered in a different AD's ballot thread.

Correct, Section 4.2 was updated (posted in -26) per Alexey's DISCUSS.
Per your original comment (and his, and Adam's), Section 10.6 now
requests IANA to register the service name "sztp" (was "zerotouch"). 

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

I've just now read draft-ietf-dnsop-attrleaf.  I see the applicability,
but I don't understand your proposal.  Looking at DataTracker, I see
that it is already in RFC Ed Queue, so I think you're suggesting me
treat it as a fait accompli, and add an IANA Consideration section
to register "_sztp", yes?  Assuming that is the case, then what should
be done with the service name registration in Section 10.6, added per
comments from Alexey and Adam?

>> > Section 5.3
>> >
>> > This is the first time we talk about "serial number" as device identity;
>> > 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?
>
> It looks like -26 added some text relating "serial number" and "device
> identity [certificate]", so let's call this OBE.

Sounds good, thanks.

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

Excellent (closed)

>> >   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.)
>> 
>> 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, ...
>
> SGTM :)

Edit made in -27.

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

Okay, item closed with no update made.

>> > 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.
>> 
>> Changed to a semicolon.

>> > 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"
>> 
>> Fixed in -26.

>> >   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.
>> 
>> 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?
>
> I am prone to being too wordy myself, but that seems just right to me.

Okay, I added a slightly modified version of the above to -27.

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

Okay, if we step back from the stream-parsing angle, and instead just focus
on the TLS truncation concern, my first thought is that said error will be
detected in (a) and (b) will not be entered.  In case (b) is entered, then
it seems that (b) would detect a malformed response from the server, as it
would normally need to do.

>> >      *  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.
>> 
>> 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.
>
> Yes, thanks.  (I think the -26 lost both "of"s, though?)

Edit made to -27, including the missing "of"s.

>> > Section 6.2
>> >
>> > "base64encodedvalue==" is pretty cute, though maybe we could add some
>> > 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?
>
> 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.

Okay, let's close this with no update.  That said, you may be pleased (or
irked) to see that the nonce min-length change forced one example to have
to change to "<nonce>extralongbase64encodedvalue=</nonce>" in order to pass
build-time validation tests ;)

>> > Section 6.3
>> >
>> > The YANG module boilerplate is still on the RFC 2119 version of BCP 14
>> > (not RFC 8174).
>> 
>> Fixed in -26. 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.
 
Note, a separate WG comment prompted an additional update here.
Now "[RFC2119][RFC8174]" is "(RFC 2119, RFC 8174)", since YANG
modules aren't themselves drafts with a references secton and
such.

>> > 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...
>> 
>> 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?
>
> That would help a lot, thanks!

Is it okay for me to back out of this one?  I had thought previously
that Russ would provide the ASN.1, but he said he didn't have time and,
well, I'd rather not venture into this if it can be avoided...

>> > Section 7.3
>> >
>> > The YANG module boilerplate is still on the RFC 2119 version of
>> > BCP 14 (not RFC 8174).
>> 
>> Yep, fixed in -26 along with the fix to the other YANG module.

>> >             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.)
>> 
>> 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.";
>
> Probably the last sentence is not adding anything useful.

Last sentence removed (and spelling mistake fixed) in -27.

>> >   container trust-anchor-certs {
>> >   [...]
>> >               The CMS MUST contain only a single chain of
>> >               certificates.  The device's end-entity certificate
>> >               MUST only authenticate to the 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?
>> 
>> 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.
>
> That looks wonderful, thanks.

Change made (along with fixing "the the") in -27.

>> > 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.
>> 
>> 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?
>
> Less so; thanks for the explanation :)

Okay, let's close this with no update made.

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

Okay, and for posterity sake, the change was made in -26.

>> > 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.
>> 
>> 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.
>
> That works for me.  (It doesn't seem like a big deal either way, of
> course.)

Change made in -27.

>> > 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.)
>> 
>> 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"/>).
>
> SGTM.

Okay, and for posterity sake, this update was in -26.

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

Ex excellent and, again, for posterity sake, this update was in -26.

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

Okay, slightly modified text to your 2nd suggestion in -27.

>> > Section 9.12
>> >
>> > nit: the last word is "revoked".
>> 
>> Fixed in -26.

>> > 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
>> 
>> Fixed in -26.

>> >                                                         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.
>> 
>> How about "encrypt the artifact using the device's public key"?
>
> Sure.

Excellent, and this update was in -26.

>> > Section C.3
>> >
>> > We could perhaps recommend ecdsa-sha2-* keys instead of ssh-rsa keys.
>> 
>> Replaced "ssh-rsa key" with "SSH public key"
>
> Even better

Excellent and, again, this update was in -26.

>> >   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".
>> 
>> Replaced "it" with "bootstrap server"
>
> Sure.

Also was in -26.

Thanks again!
Kent

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 5 Jan 2019 23:02:55 -0600

Hi Kent,

(Also a heads-up for Adam and Alexey, mentioned below regarding
dnsop-attrleaf registry actions)

> 	https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-27

You probably already saw the mail, but these changes did address my Discuss
points, so I've cleared in the datatracker.  Thank you for the really good
discussions we've been having; I'll try to finish things up below.

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

Perfect, thanks!

> I've made this change in my local copy.

Sounds good.  This is certainly the easiest way forward, and if there are
no objections there's not much reason to not just go with it.  I may have
some generic desire in the abstract to fully understand whether it's
needed, but I am pretty sure I can suppress that desire if needed :)

> Can this DISCUSS item be closed now?

It already was; I had updated my ballot position in the datatracker for the
-26 (but did not have it send mail)

> I have added a new Security Considerations section to highlight this reuse: https://github.com/netconf-wg/zero-touch/commit/62076e8421fd286a74519b60e8346dbf78d3c4f2

Thanks; it does a great job laying out the situation.

> Given the above discussion, what is your recommendation?

I think that the document will be good with no additional change for this
matter; the contents of RFC 8040 and the way we use RESTCONF makes things
clear enough.

> https://github.com/netconf-wg/zero-touch/commit/388d0355b3c7c6ce4aa48028a4ef89dc64147304.

Yes.

Okay.

> https://github.com/netconf-wg/zero-touch/commit/394b863d1850019fd451554a9f86c3c10d280d08

Thank you for your willingness to make these disruptive changes "for the
good of the team"; I know it's pretty thankless work.

>From memory, yes.

> comments from Alexey and Adam?

I think we'll need to get some further input from Alexey and/or Adam, but
my understanding is that we would need both registrations -- the service
name registration covers our _sztp._tcp.fqdn SRV records, but we are also
using <serial number>._sztp._tcp.fqdn TXT records, and so (IIUC) we'd need
to add a reference to this document for the TXT _tcp entry that RFC 6763
(DNS-SD) is currently the reference for.

> would normally need to do.

Okay, defense in depth is a good thing.  It sounds like we don't need to
say anything about this in the document, IIUC.

> build-time validation tests ;)

Cool, I wish my CI was that good :)

> well, I'd rather not venture into this if it can be avoided...

It will be okay if nothing happens on this front.  (You've already put in a
huge amount of effort anyway!)

Huge thanks for all your work on this -- hopefully the end is in sight!

-Benjamin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 7 Jan 2019 20:58:55 +0000

[adding Dave, author of the draft-ietf-dnsop-attrleaf]

Hi Ben,

  I have trimmed the below response down to just the remaining open items.

Hi Dave,

  Could you please search for "draft-ietf-dnsop-attrleaf" in this thread,
  which regards this Section 4.2 of the zerotouch draft [1], and provide
  your opinion?  In particular, since _sztp is under _tcp, does that mean
  that it is not a globally scoped entry?
 
  [1] https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-27#section-4.2),

Thanks,
Kent

>> I've made this change in -27.
>

Okay, let's just go with it.  You may want to engage Michael Richardson, from
that fork in this thread, to consider if there is a true need.

> matter; the contents of RFC 8040 and the way we use RESTCONF makes things

Excellent.  This item is closed.

>> https://github.com/netconf-wg/zero-touch/commit/388d0355b3c7c6ce4aa48028a4ef89dc64147304.

Zipping along (item closed)

> good of the team"; I know it's pretty thankless work.

Your welcome, and thanks for the acknowledgement.  (item closed)

> (DNS-SD) is currently the reference for.

This item remains open.  Hopefully Dave can provide guidance.

> say anything about this in the document, IIUC.

Thanks for letting this slide.  (item closed)

> Cool, I wish my CI was that good :)

Really, it's the only way to go.  The time spent setting it up is easily
recovered in the course of the project.  I wish all draft authors extra
time in their lives to do more rewarding stuff than chase down issues
that otherwise would've been easily caught.

> It will be okay if nothing happens on this front.  (You've already put
> in a huge amount of effort anyway!)

Okay (item closed).

> Huge thanks for all your work on this -- hopefully the end is in sight!

You bet, it was my pleasure.  I hope to thank you in person sometime.

Cheers,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 Jan 2019 20:06:07 +0000

Gentle reminder to Dave, Alexey, and Adam wrt draft-ietf-dnsop-attrleaf.

Note: I further trimmed the thread down to just this one remaining IESG COMMENT.

Kent

-----Original Message-----
From: Kent Watsen <[email-masked]>
Date: Monday, January 7, 2019 at 4:13 PM
To: Benjamin Kaduk <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, NETCONF Working Group <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Monday, January 7, 2019 at 4:13 PM

Hi Ben,

Hi Dave,

  [1] https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-27#section-4.2

Thanks,
Kent

Cheers,
Kent

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Jan 2019 12:54:24 -0800

> Gentle reminder to Dave, Alexey, and Adam wrt draft-ietf-dnsop-attrleaf.

While I see that the original note includes an address for attrleaf, I 
can't find a copy of the message in my own archive.  So it's good you 
sent the reminder.

> Date: Monday, January 7, 2019 at 4:13 PM
...
>    [1] https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-27#section-4.2

I believe your analysis is correct.

In the names your draft uses, _tcp is the global scoped name, relevant 
to attrleaf, while _sztp is subordinate and therefore not relevant to 
attrleaf.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Jan 2019 15:06:22 -0600

On Wed, Jan 09, 2019 at 12:54:24PM -0800, Dave Crocker wrote:
> ....

That's true for both
SRV in _sztp._tcp.example.com.
and
TXT in <serial number>._sztp._tcp.example.com.
but it's not clear to me that the "existing" TXT _tcp registration is
appropriate for our usage here.

-Ben

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 Jan 2019 21:12:06 +0000

Hi Dave,

Thanks for your prompt reply and, yeah, sometimes the IETF-aliases are wonky.

Your response makes sense to me, but it immediately conjured the question of *why* is _sztp under _tcp, for this case?  This question isn't specifically to you, though your input would be appereciated.

To clarify, the draft uses DNS in two ways:

1) the first is for traditional SRV records, for which being under _tcp makes sense.

2) the second is for TXT records that, of and in themselves, are not describing a TCP service, so much as providing bootstrapping data, that may or may not cause the device to initiate a subsequent connection (TCP or otherwise).   For this case, we also have the _sztp record under _tcp, but *should* it be under the TLD instead?

Does anyone else have an option?  If none, than we'll assume the current is good enough.

Thanks,
Kent

-----Original Message-----
From: Dave Crocker <[email-masked]>
Date: Wednesday, January 9, 2019 at 3:54 PM
To: Kent Watsen <[email-masked]>, Adam Roach <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, NETCONF Working Group <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

...
>    [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Dzerotouch-2D27-23section-2D4.2&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=ClpsoYlkzVsJPxG2UmqaoE9oty_meAJY0WsZ6iMoXug&s=sSjLzUmLXf7IqaubCPlMV1hgf7AyKEh9Afqc6M51Ks0&e=

d/

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 Jan 2019 21:13:13 +0000

Hi Ben,

I think we said the same thing.
Who can we ask?

Kent

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Date: Wednesday, January 9, 2019 at 4:06 PM
To: Dave Crocker <[email-masked]>
Cc: Kent Watsen <[email-masked]>, Adam Roach <[email-masked]>, Alexey Melnikov <[email-masked]>, NETCONF Working Group <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Wednesday, January 9, 2019 at 4:06 PM

On Wed, Jan 09, 2019 at 12:54:24PM -0800, Dave Crocker wrote:
> >    [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Dzerotouch-2D27-23section-2D4.2&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=lR4QeoNbY2lcou5sU88p1brc5TNL1TXt9wqxe8WeZ7w&s=1ipD0lOjua2BnhH3LtNxo52s0zlx9XmYz9G352RpyGQ&e=
> 
> 

That's true for both

-Ben

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Jan 2019 13:48:18 -0800

> appropriate for our usage here.

I'm pretty sure it is.

 > TXT        | _tcp                | [RFC6763]

The existing entry for TXT/_tcp in the attrleaf registry reserves the 
global use of _tcp and assigned responsibility for it to RFC 6763.

Worrying about reservation of the /global/ scoped names is the limit to 
the scope of attrleaf.

It intentionally punts on any concern for /subordinate/ underscored 
names, which become the responsibility of the specification to which the 
reserved globally-scoped RR/name combination has been assigned.

d/

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Jan 2019 16:00:07 -0600

Right.

But RFC 6763 is DNS Service Discovery, whose TXT records have a particular
structure, defined in its (subsections of) Section 6.  That is not what's
going on here.

So what should the attrleaf registry say about TXT _tcp that would actually
be relevant for our usage?

-Benjamin

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Jan 2019 14:19:49 -0800

> be relevant for our usage?

I'll admit to winging it, as I type this, so I won't be surprised if I'm 
seriously misunderstanding, but...

I think what you are saying is that your planned use conflicts with the 
usage defined in the existing TXT use under 6763.

Unless I'm misreading that doc, it doesn't provide for subordinate 
underscored naming.  Right?

So that means your spec has created a conflict.

I suspect it stems from the fact that you also use SRV, which has 
standardized use of _tcp and you are merely trying to stay with that 
framework.

I think the solution is that you should not stay with that framework, 
for the TXT record and therefore should use some new, global underscored 
name and register in the attrleaf registry.  (Remember, I said I was 
winging it....)

d/

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Jan 2019 15:06:22 -0600

That's true for both

-Ben

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Jan 2019 17:13:03 -0800

> appropriate for our usage here.

Your use of SRV looks entirely kosher.

So as I guess in the previous note, I suggest you use a new, globally 
scoped underscored name, and register it in the attrleaf registry.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Jan 2019 09:26:22 -0800

> Thanks for your prompt reply and, yeah, sometimes the IETF-aliases are wonky.

Seems to have mostly worked for/with me in the past.  I hadn't heard 
that it is inconsistent.  Hmmm...  Might be worth getting ietf sysadmin 
involved to look at logs.

> Your response makes sense to me, but it immediately conjured the question of *why* is _sztp under _tcp, for this case?  This question isn't specifically to you, though your input would be apperecia…

Having no history of the group's activity, and merely looking at the 
relevant draft spec text, I'd assume it merely seemed natural, given 
that (entirely appropriate) use of _tcp for the corresponding SRV record 
-- on its own it certainly looks natural to me, especially given the 
long history of no registration discipline for use of TXT RRsets.

> 1) the first is for traditional SRV records, for which being under _tcp makes sense.

+1
> 2) the second is for TXT records that, of and in themselves, are not describing a TCP service, so much as providing bootstrapping data, that may or may not cause the device to initiate a subsequent…

Absent deep involvement in the work of the spec, and just basing my view 
on the small bits of the spec I've read, I'd suggest dropping use of 
_tcp for the TXT and just using _sztp as a globally-scoped attrleaf node 
name, registering it in the new attrleaf registry.

d/

---

From: Adam Roach <[email-masked]>
Date: Thu, 10 Jan 2019 12:22:03 -0600

On 1/10/19 11:26 AM, Dave Crocker wrote:
>> 2) the second is for TXT records that, of and in themselves, are not 
>> describing a TCP service, so much as providing bootstrapping data, 
>> that may or may not cause the device to initiate a subsequent 
>> connection (TCP or otherwise). For this case, we also have the _sztp 
>> record under _tcp, but *should* it be under the TLD instead?
>
> Absent deep involvement in the work of the spec, and just basing my 
> view on the small bits of the spec I've read, I'd suggest dropping use 
> of _tcp for the TXT and just using _sztp as a globally-scoped attrleaf 
> node name, registering it in the new attrleaf registry. 

I don't think this is right. Draft-ietf-netconf-zerotouch is explicitly 
using DNS-SD procedures [1]. In turn, DNS-SD absolutely mandates the 
presence of both SRV and TXT records with the same name [2]. So the 
names need to match.

Dave's assertion that the use of _sztp._tcp... is not under the purview 
of draft-ietf-dnsop-attrleaf is correct [3]. The assumption in attrleaf 
is that whatever document ends up registering a global underscored name 
will provide guidance for those name elements that precede (are lower 
down in the tree than) the global underscored name.

In the case of DNS-SD, both the SRV and TXT _tcp global leaf namespace 
is clearly spelled out to be governed by 
<http://www.iana.org/assignments/port-numbers> [4][5][6][7].

In short, unless we're making radical changes to zerotouch so that it no 
longer uses RFC 6763, there is no valid path forward other than 
registering a corresponding service in the IANA table cited above (such 
as "sztp").

/a

____
[1] draft-ietf-netconf-zerotouch §4.2.1: "Devices claiming to support 
DNS as a source of bootstrapping data MUST first query for 
device-specific DNS records using DNS-SD [RFC6763]"

[2] RFC 6763 §6: "Every DNS-SD service MUST have a TXT record in 
addition to its SRV record, with the same name"

[3] draft-ietf-dnsop-attrleaf §2: "Only global underscored names are 
registered in the IANA Underscore Global table."

[4] draft-ietf-dnsop-attrleaf §4.3 defers authority for SRV/_tcp to RFC 
2782 and authority for TXT/_tcp to RFC 6763.

[5] RFC 6763 §7: "The first label of the pair is an underscore character 
followed by the Service Name [RFC6335]."

[6] RFC 6335 §10, which is too long too reasonably quote here.

[7] RFC2782 §"The format of the SRV RR"; see definition of "Service", 
with STD 2/RFC 1700 -> RFC 3232 -> iana.org

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Jan 2019 12:34:44 -0600

> presence of both SRV and TXT records with the same name [2]. So the 

Whoops, that's totally an error on my part.  If we're explicitly doing
DNS-SD, then there's "nothing to see here".

Sorry for missing that.

-Benjamin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Jan 2019 20:09:08 +0000

> DNS-SD, then there's "nothing to see here".

No, wait, I think that the draft's stating that it uses DNS-SD procedures
may be in error.  It might be more correct to say that it uses DNS in the
following two separate/distinct ways (in order of device-processing):

   1) A lookup for device-specific data (for the TXT RRs)

      Currently is this:<serial-number>._sztp._tcp.example.com
      But maybe should be: <serial-number>._sztp.example.com ???

      Returns TXT records (no SRV records) supplying bootstrapping
      data.

      Only if this lookup fails (not in addition to), then the 
      device moves to (2), in conflict with RFC 6763 §6.3 says:

        "DNS-SD uses DNS TXT records to store arbitrary key/value pairs
         conveying *additional* information about the named service."
        (emphasis mine)

   2) A traditional SRV lookup (per RFC 2782, not DNS-SD, right?)

      Example: _szpt._tcp.example.com

      Returns SRV records (no TXT or PTR records) supplying 
      traditional service info (address, port, priority, weight).

      FWIW, technically, SZTP defines an application-level protocol
      on top of RESTCONF, which is on top of HTTPS, but I don't
      think anyone is suggesting this:

          _sztp._restconf._http._tls._tcp.example.com   ;)

More reasons why it may be a more correct to say DNS-SD is NOT used:

  1) This draft doesn't use any PTR records, since PTR records 
     are more oriented for human-in-the-loop.  Instead, the draft 
     effectively hardcodes the PTR response to be the device's
     serial number.

     FWIW, this within itself is likely not that big of a deal, since 
     RFC 6763 allows that zero PTR are returned.

  2) The draft's definition of some of the contents of the TXT records
     overalps with SRV information, in conflict with RFC 6763:

     RFC 6763 §6.3 says:

      "The target host name and TCP (or UDP) port number of the service
       are given in the SRV record.  This information -- target host 
       name and port number -- MUST NOT be duplicated using key/value
       attributes in the TXT record."

     But this isn't the case in this draft.  If a device gets a device-
     specific response (i.e., TXT RRs from <sn>._sztp[._tcp].example.com)
     then it is NOT supposed to query for the device-independent SRV
     records.

Note that the WG didn't know about draft-ietf-dnsop-attrleaf until just
now in the IESG review.  We were shoe-horning in DNS-SD as it the closest
fit.  But now that draft-ietf-dnsop-attrleaf is brought to our attention,
perhaps it makes more sense to define a top-level "_sztp" attribute for
the device-specific bootstrapping data?

>> registering a corresponding service in the IANA table cited above (such 

Right, maybe this draft shouldn't say it's using RFC 6763?
That said, happy to keep it as is as well, if that's okay...

Thanks,
Kent

---

From: Adam Roach <[email-masked]>
Date: Thu, 10 Jan 2019 16:00:07 -0600

>        Returns TXT records (no SRV records) supplying bootstrapping

Aha! Okay, I had missed this in my read of the zeroconf document. I 
think I just saw "DNS-SD" and made certain assumptions. If this is the 
procedure you've specced out, then you can't use a TXT record with the 
_tcp global underscored name (since its use has to be consistent with 
the procedures spelled out in RFC 6763). The use of 
<serial-number>._zrtp.example.com would be fine, and would call for a 
registration in the attrleaf registry.

>        traditional service info (address, port, priority, weight).

Kind of? The issue here is that 2782 uses normal DNS lookup procedures, 
while zerotouch uses mDNS lookup procedures (if I've read things 
correctly). Doing mDNS with SRV records using _tcp but *not* using 
DNS-SD ends up stepping on DNS-SD's toes, at least a little bit. I 
suppose as long as "szpt" is registered in the service table (which is 
required for 2782 use), there's no practical risk of collisions.

>            _sztp._restconf._http._tls._tcp.example.com   ;)

I hate to admit that there's (kind of) precedent there, but it's *bad* 
precedent resulting from a misreading of 2782, and not something I'd 
encourage. :)

<snip>

> the device-specific bootstrapping data?

FWIW, before attrleaf, the accepted approach was to land-grab a label 
and naïvely hope that no one ever tried to grab the same label twice. In 
any case, even with attrleaf (and based on your clarifications above), I 
think the <serial-number>._sztp.example.com formulation for TXT is 
correct. With attrleaf, it's even more clearly so.

All of that said, you'll need to put additional language in here about 
using SRV with mDNS, but *NOT* using DNS-SD procedures. I'd advise 
copying and modifying appropriate passages from DNS-SD as the basis for 
such language. Also, please be certain to be very clear about the 
relationship between this mechanism and DNS-SD.

/a

---

From: Kent Watsen <[email-masked]>
Date: Fri, 11 Jan 2019 23:10:48 +0000

Hi Adam, Benjamin, and Dave,

  I just posted -28 to address this last COMMENT.
  Please review to see how it can be improved.

  The draft no longer says it uses DNS-SD and it
  now registers "_sztp" in DNS Underscore Global
  Scoped Entry Registry.
  
  Here's a direct link to updated/new sections:
   - https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-28#section-4.2
   - https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-28#section-10.7

Adam,

  I added text about this draft not using DNS-SD.

  Also, after reviewing RFC6763, copied over the 
  recommendation that mDNS SRV responses also 
  include address (A and AAAA) records.  This was
  the only thing I can find of merit after searching
  for both the strings "multicast" and "mdns".  Was
  there something else you had in mind?

Thanks,
Kent

-----Original Message-----
From: Adam Roach <[email-masked]>
Date: Thursday, January 10, 2019 at 5:00 PM
To: Kent Watsen <[email-masked]>, Benjamin Kaduk <[email-masked]>
Cc: Dave Crocker <[email-masked]>, Alexey Melnikov <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, NETCONF Working Group <[email-masked]>
Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

<snip>

/a

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Jan 2019 18:54:06 -0600

>    - https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-28#section-10.7

Thanks, this seems to be a fine resolution of the issues.
While looking at the diff, I managed to confuse myself as to where it is
specified how the device serial number is encoded in the identity
certificate (so that we are confident that that encoding is usable as a
DNS label).  Am I correct in assuming that that's in 802.1AR?  (Also, the
URL in the -28 gave me a 404, and I ended up at
https://standards.ieee.org/standard/802_1AR-2018.html by searching.)

-Benjamin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Jan 2019 20:43:28 +0000

Hi Ben,

> Thanks, this seems to be a fine resolution of the issues.

Great!

> https://standards.ieee.org/standard/802_1AR-2018.html by searching.)

Yes, that is the correct URL.  I've fixed it in my local copy.  The 802.1AR spec is behind a paywall, but it says this about the serial number:

  An IDevID certificate subject field be non-null and should
  include a   unique device serial number encoded as the 
  serialNumber attribute(RFC 5280 X520SerialNumber).

From RFC 5280:

   X520SerialNumber ::=    PrintableString (SIZE (1..ub-serial-number))

   ub-serial-number INTEGER ::= 64

   The character string type PrintableString supports a very basic Latin
   character set: the lowercase letters 'a' through 'z', uppercase
   letters 'A' through 'Z', the digits '0' through '9', eleven special
   characters ' = ( ) + , - . / : ? and space.

Any comments/concerns about this?

PS: I'll defer publishing the update until sure nothing more is coming.  

PPS: Looking at Datatracker, all items are cleared and the summary now says "Has enough positions to pass".  Out of curiosity, how does the document progress to the next state - is it the Responsible AD pushing a button of some sort?

Kent

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 14 Jan 2019 16:11:56 -0600

> Any comments/concerns about this?

Sigh.  There could be some excitement here (but might not be), but I think
I'm going to have to defer to some people with more DNS (and X.500)
expertise.  There's several potential (but not certain) issues here,
including at least:

(1) ub-serial-number is 64, and the maximum length of a DNS label is 64
octets, so we have no room for escaping or encoding at the margins.

(2) RFC 1034 suggests that DNS domain name comparisons should be performed
in a case-insensitive manner (for alphabetic ASCII a-z/A-Z), but that
labels themselves can contain arbitrary octets.  There is some placation
here in that X.520 appears to define the Serial Number attribute should use
a caseIgnoreMatch equality matching rule, so maybe this is a non-issue.

(3) Those extra characters (other than '-') are not allowed in DNS host
names.  AIUI, that technically shouldn't be a problem for this usage, but
I'm not 100% confident, and maybe some implementations are wrong.

(4) Using '.' in a label is pretty rare and require escaping for textual
presentation (but this is not inherently a fatal flaw and would not hit the
64-character limit on label length).

But on the whole, the question I want to ask myself here is along the lines
of "how likely is there to be implementation incompatibility in this
space?".  If serial numbers in practice are not using the full flexibility,
this could still be a non-issue.

> PPS: Looking at Datatracker, all items are cleared and the summary now says "Has enough positions to pass".  Out of curiosity, how does the document progress to the next state - is it the Responsib…

The next step is the responsible AD informing the Secretariat that the
document is approved.

-Benjamin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 15 Jan 2019 22:43:59 +0000

Hi Benjamin,

>> Yes, that is the correct URL.  I've fixed it in my local copy.  
>> The 802.1AR spec is behind a paywall, but it says this about the serial number:
>> 

Be aware that the draft must, in general, say something about the serial
number for each source of bootstrapping information (and note that the
draft leaves open the possibility that more "sources" may be defined in
the future):

  Removable Storage:
    - okay, well, the draft punts on providing an actual file-naming
      convention but, in theory, there could be a directory per 
      serial-number.  E.g., /<serial-number>/<artifact-file>.

  DNS:
    - TXT in <serial-number>._sztp.local.   (multicast)
    - TXT in <serial-number>._sztp.<domain>.  (unicast)

  DHCP:
    - the draft punts here as well. DHCP is the only source of
      bootstrapping information defined by the document that
      doesn't support device-specific response (bootp payloads
      are *way* too small!)

  SZTP Bootstrap Server:
    - device MUST identify/authenticate itself using its serial-number.
    - device SHOULD use a client-certificate (DevID RECOMMENDED)
    - device MAY use an HTTP authentication scheme but, if it does so,
      it MUST identify itself using its serial-number.

Lastly, for any source, if "signed data" is returned, the ownership
voucher [RFC 8366] defines a "serial-number" leaf that MUST be
populated with the serial number value.

In general, it is felt that, if a device vendor's serial-numbers
contain characters that are not supported by some protocol or format,
then that is their problem to solve.  That said, most protocol/formats
will define some escaping mechanism and, if not, the vendor can create
some mapping.

As for serial-number lengths exceeding some limit, then it may mean
that the device vendor either can't use that bootstrapping strategy,
or, again, they come up with a mapping of some sort (e.g., a hash).
But I doubt serial numbers ever get so long, as they are many times
typed or spoken, and users would revolt if they were too long ;)

My hope is that we can ignore this concern altogether, or maybe just
have a Security Considerations section that essentially captures the
above.  Thoughts?

Kent

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Jan 2019 17:00:50 -0600

The changes regarding DNS handling appear to be fine to me. Thanks for 
being so patient as we worked through the proper course of action here.

/a

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 15 Jan 2019 17:31:26 -0600

> have a Security Considerations section that essentially captures the

I'm inclined to believe that we can just ignore this concern for now, based
on the above discussion and having thought about the issues a bit more.

(I also see that Ignas has already pushed the "approve" button, so the
publication process is underway.)

Thanks again for all your work getting this one over the finish line.

-Benjamin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 16 Jan 2019 01:10:20 +0000

Okay, I just posted the update with the 802.1AR URL fixed.

And, as they say in BB&Fs, that's all folks!   :)

Kent

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Date: Tuesday, January 15, 2019 at 6:31 PM
To: Kent Watsen <[email-masked]>
Cc: Adam Roach <[email-masked]>, Dave Crocker <[email-masked]>, Alexey Melnikov <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, NETCONF Working Group <[email-masked]>
Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

-Benjamin