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

Qin Wu <bill.wu@huawei.com> Wed, 26 February 2020 12:28 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79E03A094A for <netmod@ietfa.amsl.com>; Wed, 26 Feb 2020 04:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw5tz_haaSeG for <netmod@ietfa.amsl.com>; Wed, 26 Feb 2020 04:28:21 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35353A0945 for <netmod@ietf.org>; Wed, 26 Feb 2020 04:28:20 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4571BAF4770A6F04B637 for <netmod@ietf.org>; Wed, 26 Feb 2020 12:28:18 +0000 (GMT)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 26 Feb 2020 12:28:17 +0000
Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.89]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0439.000; Wed, 26 Feb 2020 20:28:14 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: I-D Action: draft-ietf-netmod-factory-default-13.txt
Thread-Index: AdXsoAkozsA67961Tg6jiYKM+sl4qw==
Date: Wed, 26 Feb 2020 12:28:13 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD4E48C5@dggeml511-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.123]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SrKwjPbqpspmj5RSIjqMS8IvW6Y>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-13.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 12:28:25 -0000

-----邮件原件-----
发件人: Rob Wilton (rwilton) [mailto:rwilton@cisco.com] 
发送时间: 2020年2月26日 18:03
收件人: Qin Wu <bill.wu@huawei.com>om>; netmod@ietf.org
主题: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt

Hi Qin,

Please see inline ...

> -----Original Message-----
> From: Qin Wu <bill.wu@huawei.com>
> Sent: 26 February 2020 01:15
> To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; netmod@ietf.org
> Subject: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt
> 
> Hi, Rob:
> -----邮件原件-----
> 发件人: Rob Wilton (rwilton) [mailto:rwilton@cisco.com]
> 发送时间: 2020年2月26日 2:02
> 收件人: Qin Wu <bill.wu@huawei.com>om>; netmod@ietf.org
> 主题: 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 <netmod-bounces@ietf.org> On Behalf Of Qin Wu
> > Sent: 25 February 2020 12:39
> > To: netmod@ietf.org
> > 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:i-d-announce-bounces@ietf.org] 代表
> internet-
> > drafts@ietf.org
> > 发送时间: 2020年2月25日 20:36
> > 收件人: i-d-announce@ietf.org
> > 抄送: netmod@ietf.org
> > 主题: 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
> > I-D-Announce@ietf.org
> > 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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod