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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 26 February 2020 12:49 UTC

Return-Path: <rwilton@cisco.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 8D5C03A09B5 for <netmod@ietfa.amsl.com>; Wed, 26 Feb 2020 04:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lsJefgTo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=I8ybBLRE
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 HqioXdDfWBQN for <netmod@ietfa.amsl.com>; Wed, 26 Feb 2020 04:49:45 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7668E3A09B4 for <netmod@ietf.org>; Wed, 26 Feb 2020 04:49:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11262; q=dns/txt; s=iport; t=1582721385; x=1583930985; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/5j9Qg0tbPLgthprAEjyhW6BOcfZ14FM/39h4gItkEo=; b=lsJefgToSpn0PdSNmSBJy0ohvtM14sJdac7Oxu0NyhS5qGB67qO3Vqen giILYcWtJQvcv9eG+z6OrqxvvhS2MQbVNL3/bqYMr+tIpwmM9DeQxCZSH 462QhI3JyxfU9YzrsvjtvGfWf6BUaIjed7yYrukUgP5nzf8whBCNQfuuv U=;
IronPort-PHdr: =?us-ascii?q?9a23=3A2YTknxV7BTQthq+Q1vlZ9ERzliLV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankgA8VGSFhj13q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwBQALaFZe/4YNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFbFggBAsqCoQKg0YDimGCX5gUgUKBEANUCQEBAQwBARg?= =?us-ascii?q?LCgIEAQGDe0UCF4FqJDgTAgMNAQEFAQEBAgEFBG2FNwyFYwEBAQEDAQEQERE?= =?us-ascii?q?MAQEsCwELBAIBBgIOAwEDAQEDAiMDAgICJQsUAQIGCAEBBAENBQgBEAmDBYJ?= =?us-ascii?q?KAy4BDpIzkGcCgTmIYnWBMoJ/AQEFgS8BAwIOQYMDGIIMCYEOKowkGoFBP4E?= =?us-ascii?q?RR4JMPoJZCwEBAQEBARiBLwEBAhiDDzKCLI1MB4MSnzUKgjyHUYxJgmeCSX2?= =?us-ascii?q?HHoROi3yNNoE6gU2HL4UwjRsCBAIEBQIOAQEFgWkigVhwFRohgmwJRxgNgRq?= =?us-ascii?q?NA4NzhRSFQXQCgSeNcwEnBIEHAYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.70,488,1574121600"; d="scan'208";a="723887885"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Feb 2020 12:49:44 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 01QCniUt024931 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2020 12:49:44 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 26 Feb 2020 06:49:43 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 26 Feb 2020 06:49:42 -0600
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 26 Feb 2020 07:49:42 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L/PEOi8/c+b8n9kSOuURtG70q18Pxq1fGoEg/Vzb8h3V8ly/y2OOCNeutGLc4bX0fFOsKOyCMZ+knn0myVNNbAc8oagfc8YZ/yHMOpr6FXptnOmqbQK0mrSO4WnE0Ng2+Nex4pGs0Rm6+z8LOCVHSi2wquPzYmU2nFuib/cFBeHmFhKFInRWeYMHqodtmfRs5LgT/SNhXByH6oo0/0WcsFiiuKODhd9siGKvI3AjcOEl7UlHcTxeu3mKGqSLIGC74jdODO2pX/OGaHQYd/WWiNjyafHQit8Nd8Xb2e/xeuIfZbOsTNFtF77JEACo/olKe+mggCi1mD+7YR/KR73FKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/5j9Qg0tbPLgthprAEjyhW6BOcfZ14FM/39h4gItkEo=; b=hEHGrL7+Q8B08woIpk4b2i55Ug8XU1C5/C47Wc0LNu+fbAGThDj7h0/q6VtB+2HV3UG2lHBDC/aG1iddvMB0zXEi0hVDFf1q8nkfXpPjZ+Ed6Hp7T7drxGCm8etNu4/JB/kvmzyIvyLTIA7TY49unzwXBtdzQBzyDc6mm70qKsdV4fjOItGG5X9jOqLvKyjZmDus0zKJzclzMkxdQXCk0QvFdZo6yWzcPKAH2olfpRQAeFkjAwjwIMG4i9M0hRoxzNzlxwLTESpFNkZlSWBxy5BAEgWrVM8pGBTdz0tK1i0/JIQe64x/POlvM/ijWSi6Zuf4j5DlxCGafjLI/NRV4Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/5j9Qg0tbPLgthprAEjyhW6BOcfZ14FM/39h4gItkEo=; b=I8ybBLRE/Oe9qFDEM+GjaEPfrUlZFUJBH09aowQd1gvbAfUMtp/ZItBOwNjgz//swYgJzRcFv1RCpm7DCve52G+orKGWt2YN1rwRi0p+KklQytmsLP3Maz7qwTN8+HTJg9NYKpPU5F4he9mFpQcmGjcItHfHsDzuQEiTN/032dk=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4518.namprd11.prod.outlook.com (2603:10b6:208:24f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Wed, 26 Feb 2020 12:49:40 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2750.021; Wed, 26 Feb 2020 12:49:40 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Qin Wu <bill.wu@huawei.com>, Warren Kumari <warren@kumari.net>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: I-D Action: draft-ietf-netmod-factory-default-13.txt
Thread-Index: AdXsoAkozsA67961Tg6jiYKM+sl4qwAArNZg
Date: Wed, 26 Feb 2020 12:49:40 +0000
Message-ID: <MN2PR11MB4366927357DB4BB34F128F7EB5EA0@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <B8F9A780D330094D99AF023C5877DABAAD4E48C5@dggeml511-mbx.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAAD4E48C5@dggeml511-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.50]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dd552395-f6a9-41f5-6c63-08d7baba587d
x-ms-traffictypediagnostic: MN2PR11MB4518:
x-microsoft-antispam-prvs: <MN2PR11MB45183632FE917A235BFA674DB5EA0@MN2PR11MB4518.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0325F6C77B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(396003)(39860400002)(136003)(376002)(199004)(189003)(26005)(66574012)(66556008)(66446008)(7696005)(66476007)(6506007)(76116006)(55016002)(53546011)(9686003)(52536014)(478600001)(66946007)(64756008)(186003)(8676002)(316002)(33656002)(81156014)(966005)(8936002)(71200400001)(2906002)(4326008)(81166006)(110136005)(86362001)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4518; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jJ50KNRqyOd0OHTkOE9kR8/sWzl6B4Ma7P+98XUnqVZUupSa8lJgMt6Si6at4w4+MIvxwTwfyeSdHfE/CUYAvV7a499SxHXVU9i/m8S8lK9FGo3RZ5I7IbtC+VaqU0JfHkppJ8RybIie4vIRNtXY5K4ofT7OuMbbKlI2pwBTaMwUTeK4PKq8LUiQAxRxKbf3dh/iW/4RbiDWDDILpayFpqcpewsobsybExIN4BAHOm9leNBFX3cWnKiYtvl901sJn9FgCrLUSry9a3wb1qWpqN7F0iAOi2eu/Ij1xQ7bGrDu/mxaZ/P4bSvCORdQVoNRzuRvoYuaq1mToQ572PeMY46zm9xFwft1iP5GZzdbFfMfVdYkWpZadwMQvELmylnna7LU4F45gHM68rEwCwlS4JibXIuPuONu6+WNEnBm6pMCpBK34uDLiR5Wf8UgiYvNqG6gry8U7Xll8/yPUXY/4TO4y+3VyNpfUnN0V/Omoxb1uKmE3K4wiqeI5XNP+lByv0t4JVNfDT4AuItwLqIQMQ==
x-ms-exchange-antispam-messagedata: ySdhztzKNU6FjqLUHjrWIfSvx4ZIvyAVU1tVvZnTSzV/k7O0+EYwlKIvODsp1yRiYgSMDyGRbRXnNUlr+0ymoy4o23Fi8vY+AL4nnN8gahEr5RKGdbfXiHkbrmPvlBhqJ8T8MeqR8fRZpQ2iKyz9Aw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dd552395-f6a9-41f5-6c63-08d7baba587d
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 12:49:40.5843 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: t01Aaku5iejsyGKNAqUKBqJ1b6ueEr5WX8Y/RhE4uu+CUc5UlPytqIZBdRbrvKxdGv49lTueN4Tl5rzuEZNq4g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4518
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hx_jlDiGjE-eb0B_zzKhRlHGxeU>
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:49:48 -0000

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 <bill.wu@huawei.com>
> Sent: 26 February 2020 12:28
> To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; netmod@ietf.org
> Subject: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt
> 
> -----邮件原件-----
> 发件人: 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-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
> > > 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