Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-13.txt

From: Qin Wu <[email-masked]>
Date: Wed, 26 Feb 2020 01:14:36 +0000

Hi, Rob:
-----邮件原件-----
发件人: Rob Wilton (rwilton) [mailto:[email-masked]] 
发送时间: 2020年2月26日 2:02
收件人: Qin Wu <[email-masked]>; [email-masked]
主题: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt

Hi Qin,

I think that you may have accidentally removed the RFC editor instructions in the YANG module that presumably we want to still keep?

	 	// RFC Ed.: update the date below with the date of RFC publication	
 	      // and remove this note.	
 	      // RFC Ed.: replace XXXX with actual RFC number and remove this	
 	      // note.
[Qin]: My understanding is RFC Note is used to send a note to RFC Editor, after RFC Editor take action, the RFC Editor note should go away and will not stay in the YANG module any more.
What do you suggest? Don't include "and remove this note" in the RFC Editor note?

For the update to the security section, my concern wasn't so much about no longer being able to access a private key, but more that a client cannot rely on any private data being unrecoverable after the factory-reset RPC.  i.e. they can't just use the factory-reset RPC and then sell the device on ebay, with the assumption that all private data has been properly cleansed.

OLD:

 	   The non-volatile storage is expected to be wiped clean and reset back	
 	   to the factory default state, but there is no guarantee that the data	
 	   is wiped according to any particular data cleansing standard, and the	
 	   owner of the device MUST NOT rely on any temporary data (e.g.,	
 	   including private keys) for recovery after the factory-reset RPC has	
 	   been invoked.

NEW:

 	   The non-volatile storage is expected to be wiped clean and reset back	
 	   to the factory default state, but there is no guarantee that the data	
 	   is wiped according to any particular data cleansing standard, and the	
 	   owner of the device MUST NOT rely on any sensitive data (e.g.,	
 	   private keys) being forensically unrecoverable from the device's
          non-volatile storage after a factory-reset RPC has been invoked.

[Qin]: I am not lawyer, when you use the word "forensically". But the "factory-reset" RPC operation has been restricted by
using the "default-deny-all" access control defined in RFC8341. I am not sure any end user can take advantage of 
factory-reset RPC as the client. Let me know if my understanding is correct.

Thanks,
Rob

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Qin Wu
> Sent: 25 February 2020 12:39
> To: [email-masked]
> Subject: Re: [netmod] I-D Action: 
> draft-ietf-netmod-factory-default-13.txt
> 
> v-13 is posted, the diff is:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-13
> Thanks Rob for valuable review.
> 
> -Qin
> -----邮件原件-----
> 发件人: I-D-Announce [mailto:[email-masked]] 代表 internet- 
> [email-masked]
> 发送时间: 2020年2月25日 20:36
> 收件人: [email-masked]
> 抄送: [email-masked]
> 主题: I-D Action: draft-ietf-netmod-factory-default-13.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Network Modeling WG of the IETF.
> 
>         Title           : A YANG Data Model for Factory Default Settings
>         Authors         : Qin Wu
>                           Balazs Lengyel
>                           Ye Niu
> 	Filename        : draft-ietf-netmod-factory-default-13.txt
> 	Pages           : 12
> 	Date            : 2020-02-25
> 
> Abstract:
>    This document defines a YANG data model to allow clients to reset a
>    server back to its factory default condition.  It also defines a
>    "factory-default" datastore to allow clients to read the factory
>    default configuration for the device.
> 
>    The YANG data model in this document conforms to the Network
>    Management Datastore Architecture (NMDA) defined in RFC 8342.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-factory-default-13
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-defaul
> t-13
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-13
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 26 Feb 2020 10:02:59 +0000

Hi Qin,

Please see inline ...

> From: Qin Wu <[email-masked]>
> Sent: 26 February 2020 01:15
> To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
> Subject: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt
> 
> Hi, Rob:
> -----邮件原件-----
> I think that you may have accidentally removed the RFC editor instructions
> in the YANG module that presumably we want to still keep?
> 
> [Qin]: My understanding is RFC Note is used to send a note to RFC Editor,
> after RFC Editor take action, the RFC Editor note should go away and will
> not stay in the YANG module any more.
[RW] 
Apologies, I had read the diff the wrong way round.  Your instruction here is fine, and no further change is required.

> 
> For the update to the security section, my concern wasn't so much about no
> longer being able to access a private key, but more that a client cannot
> rely on any private data being unrecoverable after the factory-reset RPC.
> i.e. they can't just use the factory-reset RPC and then sell the device on
> ebay, with the assumption that all private data has been properly
> cleansed.
> 
> OLD:
> 
> 
> [Qin]: I am not lawyer, when you use the word "forensically". But the
> "factory-reset" RPC operation has been restricted by using the "default-
> deny-all" access control defined in RFC8341. I am not sure any end user
> can take advantage of factory-reset RPC as the client. Let me know if my
> understanding is correct.
> 

Your current text says, "users need to be aware that private keys might not be recoverable after a factory-reset RPC".  But this isn't a security consideration, this is just an inconvenience, and I believe the text is section 2 is sufficient.

My concern is entirely the other way around, i.e. "users need to be aware that private information might still be recoverable after a factory-reset RPC", because a factory-reset RPC does not guarantee that it won't be.  Section 2 recommends that security sensitive data be overwritten with 0's, but this is only a SHOULD, and writing 0's doesn't meet the standard industry requirements of ensuring that the data won't be subsequently recoverable.

When electronic equipment reaches the end of its useful life then normally the company will ensure that all private data is destroyed from any media before it can be resold.  E.g. in the US this might be done to the DoD 5220.22 standard.

I don't want clients using the factory-reset RPC to think that it is sufficient for them to avoid properly wiping any non-volatile storage.

Does that help clarify the security concern that I'm asking you to please address?

Thanks,
Rob