Re: [Netconf] Adoption poll for crypto-types and trust-anchors

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 11 May 2018 22:12 UTC

Return-Path: <evoit@cisco.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 2AB0A127863 for <netconf@ietfa.amsl.com>; Fri, 11 May 2018 15:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
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 b56E9PPtcZwd for <netconf@ietfa.amsl.com>; Fri, 11 May 2018 15:12:56 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B26126DEE for <netconf@ietf.org>; Fri, 11 May 2018 15:12:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15062; q=dns/txt; s=iport; t=1526076776; x=1527286376; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zuqz23edX2xiFxsPzuyZCH8AhtbbcszHhztJfxxprdo=; b=Z2reufhx4TgQBCIghyjo97cYy9Q1QvDAFp3HAXFfthYZO3iFnCJ0F6NY aw1EUG571tSfS5VtiedObKeP2C1G0FdebW3b1IAVsHh0A+cTo/lxTu2RZ WwfkgTclzGvweJi0wDYHvkz3qq2r1jXivqD39GZLeJglth514Qv11eGIB E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CWAQD3FPZa/51dJa1bGQEBAQEBAQEBAQEBAQcBAQEBAYJNdmF7MoNoiASMcIF5gQ+OPYR4gXgLhGwCGoJvITQYAQIBAQEBAQECbCiFKAEBAQEDIwpMEAIBCA4HLQICAjAlAgQODYMdgRtkq1SCHB+IKIInhwKBI4FUP4NsLoRdJIJyglQCmDIJAo5HjHOCK44LAhETAYEkARw4gVJwFYJ/kE2Qc4EYAQE
X-IronPort-AV: E=Sophos;i="5.49,390,1520899200"; d="scan'208,217";a="397160941"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2018 22:12:55 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w4BMCtNo020154 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 May 2018 22:12:55 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 11 May 2018 17:12:54 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Fri, 11 May 2018 17:12:54 -0500
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kwatsen@juniper.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Adoption poll for crypto-types and trust-anchors
Thread-Index: AQHT4wADJ2ALQ9zNKkqYEk+Kq3yYtKQfpfMAgASX5ZD///FoAIAB9YWggAMvS4CAAEU6sA==
Date: Fri, 11 May 2018 22:12:54 +0000
Message-ID: <fec307a188914e2eab1e6dace8559a97@XCH-ALN-013.cisco.com>
References: <30074620-B60A-420D-8805-80C9EF1E1BDC@juniper.net> <D8937259-459A-4D8C-84B7-D75EE559A9BA@juniper.net> <AM5PR0701MB23377923E96B8A0121B8D00A839B0@AM5PR0701MB2337.eurprd07.prod.outlook.com> <69CC8DB5-95C5-413A-965D-A624EE05DC9D@juniper.net> <fe1783af8fc743c1845f91b253ed4cd9@XCH-RTP-013.cisco.com> <C59CC8EF-DD5C-49FF-9275-E8AA1E2A3DBF@juniper.net>
In-Reply-To: <C59CC8EF-DD5C-49FF-9275-E8AA1E2A3DBF@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_fec307a188914e2eab1e6dace8559a97XCHALN013ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/XuZPkBb0LMFVgn1qk6V-tE0TSJ0>
Subject: Re: [Netconf] Adoption poll for crypto-types and trust-anchors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing 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: Fri, 11 May 2018 22:12:58 -0000

From: Kent Watsen, May 10, 2018 6:31 PM

Kent writes, in response to Balazs:
You're right about that, if added later, it may not be widely implemented.  Back to the technical discussion, some important points have been raised.  Perhaps it is better after all to keep ietf-keystore, the -03 version, before the private key was converted to being a grouping.  Right now, the adoption poll is showing weak support, and this seems to be the core issue.  Hearing from others on this point would be very helpful!

<Eric> I do like providing grouping which allow key-pairs to be defined and used in various models.

<Kent> It's possible to both have groupings (for those that want them) and to use those groupings in a keystore data model.  The only question then would be if the ietf-[ssh/tls]-[client/server] modules use one, or the other, or both?  [I think the idea of bringing back the keystore module would be then to just use it in our modules]

<Eric2> I don’t have a very strong opinion on this.  I see this more of a preference question of how much modularity do we want.  My assumption is that in the security space, solid modular identities & group definitions might play a role similar to that of RFC 6021 for common YANG types.

<Eric> One question on this, leaf public-key in draft-kwatsen-netconf-crypto-types-00 has a must constraint for a private key, which is fine for the purpose of this grouping.  But do you see a case where other YANG modules might want to pick up using the schema definition of public key and the various key algorithm identities defined?  Maybe for someone who just wants to store decryption keys?  If yes, perhaps an extra grouping definition?

<Kent> Potentially.  If I understand you correctly, the public-key-only grouping wouldn't be used in any current modules (e.g., in the keystore module), but merely be available for anyone who might want just a public-key in the future?

<Eric2>  Yes.  As your module is being designed for such reuse already, it would seem a natural extension at low cost.

Eric

Kent // contributor