Subject: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-zerotouch-25: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 05 Dec 2018 21:31:33 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-netconf-zerotouch-25: No Objection

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/

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

I support Adam's and Alexey's DISCUSS points.

§1.2: I have a bit of discomfort in how the manufacturer/owner business model
is encoded into this. In particular, is there any possibility of anonymous
owners? How about secondary markets (i.e. transfer of a device between owners)
without mediation by the manufacturer.)? But I see this is actually mentioned
in the security considerations, so I don't really expect a change.

§3.1, 4th paragraph: The first sentence is convoluted; please consider breaking
it into multiple simpler sentences.

- 6th paragraph: The first sentence is even more convoluted.

§5.6, 10th paragraph: I'm not sure how to interpret "MUST try". That doesn't
seem verifiable. -- first bullet under "implementation notes": is "roll out of"
the same things as "roll back"?

§9.8:
- 4th paragraph: Can the "best practices" be cited or described? Otherwise, the
normative "RECOMMENDED" seems pretty vague. (Or are the next few sentences
intended to define those practices?

-5th paragraph: Paragraph is hard to parse.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 11 Dec 2018 01:26:33 +0000

Hi Ben,

Thanks for your review!
See below for responses.

Kent // coauthor

I've responded to them both separately.

> in the security considerations, so I don't really expect a change.

First, I don't believe the draft ever says that there is such an integration.
The draft does say that devices must be manufactured with some default trust
anchors, but the trust anchors could be delegated to 3rd-parties.  Similarly,
the draft never states how the, e.g, 3rd parties come to be know *who* is the
rightful owner of a device.  

That said, I believe the document does imply this as a possibility, as it is
by far the easiest to implement, at least initially, for the manufacturer to
themselves stand-up an instance of a trusted bootstrap server and/or a trusted
ownership-voucher issuing service and, of course, integrate both these into
some backend sales channel database.  

Regarding transfer of ownership, the manufacturer may implement some mechanism
outside the scope of this document to facilitate a transfer.  Perhaps it could
be mediated by a sales representative in the field, or perhaps via some action
performed by the previous owner, or perhaps (assuming the manufacturer keys 
"ownership" off support contracts) by the previous owner first cancelling 
their support contract followed by the successor owner initiating a new 
support contract.

Regarding anonymity, it is unnecessary for the manufacturer, or trusted
delegates, to know the actual identity of the rightful owner; they only
need to ensure that the rightful owner can claim ownership unambiguously.
Thinking out loud here, perhaps, at the time of sale, the owner is 
provided a some random credentials that they can use when interacting
with the manufacturer or its delegates - presumably, only the purchaser
(and manufacturer or delegate) would know the credentials for the device.

Of course, a lot of this has to do with the class of device (enterprise
versus consumer) and how paranoid the security dial is set.  The draft
defines just the bits-on-the-wire part of the solution, leaving it to
the vendors to determine what backend parts makes sense for their markets.

> §3.1, 4th paragraph: The first sentence is convoluted; please consider
> breaking it into multiple simpler sentences.
>

Okay, I broke the sentence up a bit (in my local copy).  I also did the
same to the similar sentences in §3.3.

> seem verifiable. 

I'm open to wording suggestions, but what is trying to be conveyed is more
than a SHOULD, and yet not quite a MUST, in the sense that if, for any reason,
the device is unable to deliver the progress report (e.g., remote server down),
it is okay for the device to proceed.  I don't know, maybe "SHOULD" conveys
this just right, thoughts?

> -- first bullet under "implementation notes": is "roll out of"

Yes, replaced (in my local copy).

> intended to define those practices?

I'm unaware of any great references.  RFC 5280, §8, 5th paragraph touches on 
it, but not to any great affect.  I added a "For example," (in my local copy) 
to clarify that the following sentences provide some suggestions.

> -5th paragraph: Paragraph is hard to parse.

Agreed. Simplified.

Thanks again!
Kent