Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-keystore and draft-ietf-netconf-zerotouch

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 4 Aug 2017 13:24:12 -0700

The same is true for these two drafts also. With no explicit support, we are declaring the WGLC unsuccessful. 

Once the authors have posted updated drafts, we will resume the LC.

Thanks.

> On Jul 26, 2017, at 9:26 AM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> The same message applies to these documents in WG LC. Even though the LC has timed out, we are extending this by one week to get your vote in.
> 
> We saw support for these documents in the WG meeting, but we need that support expressed on the mailing list. Note, that Kent has already indicated that he will resolve the issue of whether to keep identifiers in the keystore draft as part of the LC.
> 
> Authors please indicate whether you are aware of any IPRs.
> 
>> On Jun 29, 2017, at 6:08 PM, Mehmet Ersue <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Dear NETCONF WG,
>>  
>> we hereby issue a WG Last Call for 2 weeks for the drafts below: 
>>  
>> https://tools.ietf.org/html/draft-ietf-netconf-keystore-02 <https://tools.ietf.org/html/draft-ietf-netconf-keystore-02>
>> https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-14 <https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-14>
>>  
>> Please review and send your comments to the NETCONF WG mailing list by July 13, 2017 EOB PT. 
>> Please be aware that the Keystore and Zerotouch drafts are planned to publish as standard track documents.
>>  
>> We would like to ask WG members to state explicitly that you have read/reviewed and whether you support the publication of the drafts.
>> Please indicate also if you plan to implement or have already implementation experience with these drafts.
>>  
>> Authors: 
>> Please indicate with an email on the maillist explicitly whether you are aware or you are not aware of any IPRs related to the drafts.
>>  
>> PS: Next in the row are the 4 client-server drafts going to WGLC on July 10th.
>>  
>> Thank you,
>> Mehmet and Mahesh
>>  
>> _______________________________________________
>> Netconf mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
> 
> 
> 

Mahesh Jethanandani (as co-chair)
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Wed, 16 Aug 2017 00:17:49 +0000

Hi Robert,

I've decided to defer addressing some of your concerns until after posting
an update, so the changes are easier to understand.    I'll post the update
later tonight.   More responses below.

K.

On 7/20/17, 4:45 AM, "Robert Wilton" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

On 19/07/2017 20:07, Kent Watsen wrote:

Hi Rob,

Thanks for the review.  Please see my comments below.

Kent

--

Hi,

I've read through the zerotouch draft, but found it much more hard going

that the keystore draft, but then it relates to stuff that I'm not

particularly familiar with!

I would say that this draft it a long way out of my domain of expertise,

so I'm not sure that I'm really qualified to judge whether this draft is

ready for publication.  In particular, I think that a through founding

in the security aspects are probably key to knowing whether this draft

is right.

So, my comments are more to do with the structure/readability of the

document rather that whether the proposed technological solution is

right.  Hopefully they are still of use.

Main comments:

1) I found that the draft is long, with quite lengthy descriptions in

the early part of the document, which often seemed to overlap in the

concepts that they are describing.  E.g. whether some data is trusted or

untrusted, and how that trust can be established could possibly be dealt

with early in the document, and then just referenced later.

I.e. data is untrusted unless it has been received over a secure

connection to a trusted server, or is appropriately signed.

Then in section 2.1, the 3 paragraphs on trust could be simplified to:

Redirect data may be trusted or untrusted.  If trusted, then it can be

used to establish a secure connection to a trusted server by including

the bootstrap server's trust anchor certificate.  If untrusted, then the

device MUST discard any included trust anchor certificates.  The text

about a provision connection could be left to a reference to section 7.5.

Likewise, in section 2.2, the paragraph starting "Bootstrap information

is trusted if ..." could be deleted.

<KENT> okay, point taken, I'll see how this can be simplified.

2) Section 4. Artifact Groupings:

2i) I think that the second paragraph of 4.1, starting "unsigned

information is useful ..." is probably superfluous and could be deleted.

<KENT> or perhaps stated differently?  I'm trying to provide the use

case.  Similar paragraphs are in 4.2 and 4.3 as well...
My thought was to try and make the normative part of the document (i.e. to actually implement zerotouch) shorter and more concise.

If trusted vs untrusted and signed/unsigned data is covered once near the top of the document then it may not be necessary to comment about signed vs unsigned, and trusted vs untrusted in the subsequent sections.

<KENT> I deferring making this change now.

2ii) I wonder if sections 4.2 Signed Information (without Revocations)

and 4.3 Signed Information (with Revocations) could be coalesced

together.  I.e. covering signed information, and then a subsection of

revocations?

<KENT> Perhaps, but then wouldn't that make the three variations less

obvious?  Currently, each variation has its own section, which I think

helps them to stand out...
Yes, perhaps.

But possibly you could see this as really just 2 options, one of which has 2 sub options:

1) Unsigned data
2) Signed data.  If signed, then revocation certificates may or may not be provided.

<KENT> I've dramatically shortened this section, we'll see how you like it when I
post the update…

3) Section 5: Sources of Bootstrapping Data

I also think that these sections could also possible be made more concise:

3i) Some of the text on "Removable Storage" seems unnecessary given that

it is out of scope for this draft.

<KENT> what do you think is out of scope?
Sorry, I mean that the text is perhaps not normative.

E.g. picking up this comment "

The format of the removable storage device's filesystem and the

   naming of the files are outside the scope of this document.

"

I wonder if this section could be summarized as:

"Removal storage can be a source of untrusted bootstrap artifacts.  The specific details of how those artifacts are encoded is outside the scope of this draft."

Perhaps that text is a bit too short, but given it is implementation specific I'm not sure how much needs to be stated.

<KENT> Yes, way too short.  Actually, I like it the way it is, even after re-reading it.
Looking at removable storage in particular, since you called it out, that last paragraph
has been built up over time - mostly by comments from Juergen.   Maybe you should
think about it again after seeing the update with all the other changes…

3ii) As per previous comments the comments about trust could potentially

be curtailed if it previously been covered in a generic way.

<KENT> right, I'll look to tighten this up

4) Section 6. Workflow

4 i) Would it make sense to put the Workflow text as an appendix? It

seems to be giving examples of how it could be implemented.

<KENT> certainly could, as it's not meant to be normative.  That

said, I think Andy said that he really appreciated that section

being there...
OK.  My goal is just to try and get the normative text to be shorter.

<KENT> I've moved this section to the Appendix.

4 ii) The diagram on page 23, point 2 seems incomplete: "for each source

supported, check"

<KENT> If we use another line, we could have a more complete sentence.

E.g. for each source supported, check if bootstrapping data is available.

But then again, that's pretty much what #2 under the diagram says.  Is

this what you want?
I don't mind.  It just seemed that the current description ended mid flow.

<KENT> I'll consider this item closed.

Minor comments:

1) In the terminology section, it might be useful to add definitions for

"fingerprint" and "webhook".  Perhaps also "trusted", "untrusted",

"trusted device".

<KENT> is "fingerprint" not commonly known?
I don't know, within security circles I would assume yes, outside of that I'm not sure.  I do know that my children leave lots of fingerprints on our windows ;-)

<KENT> I'm going to assume that readers of this draft know what a fingerprint is.  Also, where used, the draft seems to provide enough context to provide a definition in situ.

2) section 7.6, force the reinstallation of its boot image.

Is this forcing re-installation of the original boot image, or an

updated one, or does it not matter?

<KENT> it's the boot-image specified by the bootstrapping process.

Reading this section, the intent seems clear, but I wrote it.  Can

you re-read this section and see if you still feel the same way?
It's still not entirely clear to me, but if I was interpreting this text I my best guess would match your description above.

<KENT> okay, I replaced "its boot image" with "the boot image".  Hopefully this
resolves your issue.

---

From: Robert Wilton <[email-masked]>
Date: Wed, 16 Aug 2017 11:56:33 +0100

Hi Kent,

The draft updates looks good, some further comments inline ...

On 16/08/2017 01:17, Kent Watsen wrote:
> My thought was to try and make the normative part of the document 
> (i.e. to actually implement zerotouch) shorter and more concise.
>
> If trusted vs untrusted and signed/unsigned data is covered once near 
> the top of the document then it may not be necessary to comment about 
> signed vs unsigned, and trusted vs untrusted in the subsequent sections.
>
OK.

> <KENT> I've dramatically shortened this section, we'll see how you 
Yes, I think that the shorter section is much better.

> "Removal storage can be a source of untrusted bootstrap artifacts.  
> The specific details of how those artifacts are encoded is outside the 
> scope of this draft."
>
> Perhaps that text is a bit too short, but given it is implementation 
> specific I'm not sure how much needs to be stated.
>

The new chapter 4 still seems quite long to me, but it is probably OK, 
and I don't think that I can offer any pragmatic alternative.

Thanks.

> <KENT> I'll consider this item closed.
OK.

> I don't know, within security circles I would assume yes, outside of 
> that I'm not sure.  I do know that my children leave lots of 
> fingerprints on our windows ;-)
>
> <KENT> I'm going to assume that readers of this draft know what a 
> fingerprint is.  Also, where used, the draft seems to provide enough 
> context to provide a definition in situ.
>
OK.

> It's still not entirely clear to me, but if I was interpreting this 
> text I my best guess would match your description above.
>
Not sure.

In the algorithm, it is still a bit ambiguous to me as to what happens 
when a failure happens, e.g. the downloaded image doesn't match the 
fingerprint.  Does it keep trying to download the image?

E.g. sometimes with a BIOS there is a known good BIOS baked into NVRAM 
so that if even if you bork updating the BIOS you can go back to a 
previous version that should hopefully allow you to recover without 
bricking the device.

Perhaps the device should have a choice as to which boot image is 
reverts to?

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Fri, 18 Aug 2017 15:14:01 +0000

Hi Robert,

Trimming down to the only remaining open discussion point:

<KENT> okay, I replaced "its boot image" with "the boot image".  Hopefully this
resolves your issue.
Not sure.  In the algorithm, it is still a bit ambiguous to me as to what happens when a failure happens, e.g. the downloaded image doesn't match the fingerprint.  Does it keep trying to download the image?

<KENT> that's a 'sha256' issue, for which Section 5.6 says that the device would effectively stop trying to consume bootstrapping information from this bootstrap server, which case it would continue with the next bootstrap server (if any) or source of bootstrapping information.  Yes, it may fall into an infinite loop but, hopefully, the device is able to post a progress-update to the bootstrap server, so there is a log that it's in trouble.

E.g. sometimes with a BIOS there is a known good BIOS baked into NVRAM so that if even if you bork updating the BIOS you can go back to a previous version that should hopefully allow you to recover without bricking the device.  Perhaps the device should have a choice as to which boot image is reverts to?

<KENT> Okay, thanks for the example.  Examining the current text, it says " the device MUST reset itself *in such a way* that forces a reinstallation of the boot image".  So, the reset could be, revert to previous image or an image from NVRAM or just set a flag that is examined the next go around.  Do you want me to add a sentence that says that so it's more explicit?

K.