Re: [netconf] ietf crypto types - permanently hidden

tom petch <ietfc@btconnect.com> Thu, 02 May 2019 09:39 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA3120026 for <netconf@ietfa.amsl.com>; Thu, 2 May 2019 02:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level:
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 0PVwbGQk-bBe for <netconf@ietfa.amsl.com>; Thu, 2 May 2019 02:39:13 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10111.outbound.protection.outlook.com [40.107.1.111]) (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 D832212004A for <netconf@ietf.org>; Thu, 2 May 2019 02:39:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rDtRmoBG1vGuOaNxhF+YkKq0olIZHfKofjvWppzzddE=; b=WKiZ4l4i2s7j9g5zQnPlbWaJXTnOO19LCXcndzrQLbC5Ge5oR5U9hLptlUubj0wwD4ixRj1Jbre0lzPtTW4O/1hLsfyux6jtcMjRiqpVgJ0umsxyJg8powfZMbN9QneIAm5QYkD9uzpCNMAQ4AZNVAy98+LAU3tESc86+/YWV1w=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB5693.eurprd07.prod.outlook.com (20.178.120.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.6; Thu, 2 May 2019 09:39:09 +0000
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1878.004; Thu, 2 May 2019 09:39:09 +0000
From: tom petch <ietfc@btconnect.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AQHVAMrknf3fF5qMGEKvxGfF1bfg7A==
Date: Thu, 2 May 2019 09:39:09 +0000
Message-ID: <03de01d500ca$68ad9da0$4001a8c0@gateway.2wire.net>
References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <VI1PR07MB47353B20AF138B5B8B702285833A0@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> <acef56d17fc64102ae24bb8fcb8c828d@XCH-RCD-007.cisco.com> <CABCOCHS=mETbXUNm4pC45HPLtLu-r6QfX6xQAWCGxb7jfR19_w@mail.gmail.com> <20190501180553.3oidb7x275tgcdz6@anna.jacobs.jacobs-university.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0024.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::36) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dda59e16-d341-442a-3b2d-08d6cee2069d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5693;
x-ms-traffictypediagnostic: VI1PR07MB5693:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <VI1PR07MB56933C19909D643ACEDE2EE8A0340@VI1PR07MB5693.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0025434D2D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(136003)(346002)(396003)(376002)(13464003)(189003)(199004)(54094003)(2906002)(76176011)(81686011)(4720700003)(81816011)(52116002)(6486002)(84392002)(966005)(478600001)(62236002)(1556002)(44716002)(66066001)(61296003)(50226002)(44736005)(6246003)(256004)(53936002)(476003)(86152003)(9686003)(6512007)(14444005)(8936002)(6306002)(4326008)(25786009)(14496001)(446003)(3846002)(486006)(73956011)(66946007)(66476007)(66556008)(66446008)(6116002)(5660300002)(8676002)(229853002)(64756008)(186003)(26005)(14454004)(316002)(81156014)(386003)(81166006)(6506007)(102836004)(71200400001)(71190400001)(99286004)(305945005)(68736007)(86362001)(6436002)(7736002)(110136005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5693; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: OQBy4ztH80r8couRAg8GCLUs/i1F8LGBhGLlPeioeDPr4LKGEe2thOQwa3LCYJUoH4+PdwNVdM3P9W/nfADMurb5lwfvzPS8ZkFKOQ4O6D9I9ByjpPbB+gwU8vDcWjSZAb2JBOVkLmRf9gtFwPW65AiYssccyenil9KqX9vW2p2eDKcbB6tqv6KYQmjuMufqKjzYiE1cYiLn29Nhd0Z84Ll8CA6X9JvC9Og8ajFdWL/9q5PaSlfsAfp6cxbQc8SnuG6ltciiGBcqPHBXU34s+mmqjxF+P7FqflJ3GQbw3pwNl7LZR1gvxLc7x9z+JO0n1MrANNc+rErXsLQQ2SKCGbXfzltYARXX6qwlpcgpdng/+jGDeGE0Fa/pKwjDslcfiHY9naqKmgiLdKZEiwyNs/TmY0lq+MePsnkisHM48L8=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <774E1A22505CEE498C46A2DDCA9DD1BB@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dda59e16-d341-442a-3b2d-08d6cee2069d
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 09:39:09.7587 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5693
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/XxGIv9SWxy8oSHdOdzql0s4dnHc>
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2019 09:39:15 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>;
Sent: Wednesday, May 01, 2019 7:05 PM

> On Wed, May 01, 2019 at 09:19:38AM -0700, Andy Bierman wrote:
> >
> > This seems to be a good test for whether NMDA is useful as designed.
> > It seems obvious that something has to be stored in <running> and
> > then transformed as it is applied to <intended>.
> >
>
> The issue here seems to be that you create a resource that you would
> like to be partially accessible as config and partially not accessible
> at all or only as applied config in operational state. The question is
> how to model that, i.e., the binding between config part and the
> internal state part. Do we have any other similar resources or is this
> really a very special case?

I wonder if IPv6 privacy addresses are similar, generated on the device
using random or pseudo-random input and which may also use device
specific data such as MAC address; and which may derive from the
device's public key.

If the hardware is replaced, and the configuration is restored, should
the address stay the same or is it a breach of privacy to carry the
address across? I do not know but would guess the latter.

Tom Petch

> We discussed the 'create user account' case where often users ids are
> allocated as a side effect of creating an account but the allocated
> ids then becomes regular config, i.e., the config can be copied and
> restored as one would expect. This is not really the same case that we
> have with locally created keys.
>
> An alternative might be to consider a locally generated key entirely
> operational state (applied config): You invoke an RPC to create a key
> and you give it a name and then it exists as named operational state
> (applied config) until you delete that named operational state. If you
> want to configure a transport that refers to such a key, you do this
> via a name binding, pretty much in the way we apply interface
> configuration to an interface with a matching name. Perhaps this is a
> model that could work.
>
> Perhaps Martin has even better ideas.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf