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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Qin,

Thanks for your work and timely updates on this document.

Warren, I think that we are good to go for IETF LC with the -14 version.

Thanks,
Rob


> -----Original Message-----
> From: Qin Wu <[e-mail]>
> Sent: 26 February 2020 12:28
> To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
> Subject: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt
> 
> -----邮件原件-----
> 发件人: Rob Wilton (rwilton) [mailto:[e-mail]]
> 发送时间: 2020年2月26日 18:03
> 收件人: Qin Wu <[e-mail]>; [e-mail]
> 主题: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt
> 
> Hi Qin,
> 
> Please see inline ...
> 
> > -----Original Message-----
> > From: Qin Wu <[e-mail]>
> > Sent: 26 February 2020 01:15
> > To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
> > Subject: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt
> >
> > Hi, Rob:
> > -----邮件原件-----
> > 发件人: Rob Wilton (rwilton) [mailto:[e-mail]]
> > 发送时间: 2020年2月26日 2:02
> > 收件人: Qin Wu <[e-mail]>; [e-mail]
> > 主题: 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?
> [RW]
> Apologies, I had read the diff the wrong way round.  Your instruction here
> is fine, and no further change is required.
> [Qin]: Good.
> 
> >
> > 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.
> >
> 
> 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?
> 
> [Qin]: Thanks for your clarification, the text you suggest seems
> reasonable to me now, thanks.
> Thanks,
> Rob
> 
> 
> > Thanks,
> > Rob
> >
> >
> > > -----Original Message-----
> > > From: netmod <[e-mail]> On Behalf Of Qin Wu
> > > Sent: 25 February 2020 12:39
> > > To: [e-mail]
> > > 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:[e-mail]] 代表
> > internet-
> > > [e-mail]
> > > 发送时间: 2020年2月25日 20:36
> > > 收件人: [e-mail]
> > > 抄送: [e-mail]
> > > 主题: 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-defa
> > > ul
> > > 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
> > > [e-mail]
> > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod