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

[Warren Kumari <[e-mail]>]

On Wed, Feb 26, 2020 at 7:49 AM Rob Wilton (rwilton) <[e-mail]> wrote:
>
> 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.


Whoops, I had missed this; luckily Rob is on the ball and reminded me
/ pointed this out.

I have just requested IETF LC.

W

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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf