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

[Kent Watsen <[e-mail]>]

Hi Ben,

Thanks for your review!
See below for responses.

Kent // coauthor


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Adam's and Alexey's DISCUSS points.

I've responded to them both separately.


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

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.
>
>  - 6th paragraph: The first sentence is even more convoluted.

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



> §5.6, 10th paragraph: I'm not sure how to interpret "MUST try". That doesn't
> 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"
> the same things as "roll back"?

Yes, replaced (in my local copy).



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

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