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

Kent Watsen <kwatsen@juniper.net> Thu, 24 May 2018 00:50 UTC

Return-Path: <kwatsen@juniper.net>
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 C2E8412D875 for <netconf@ietfa.amsl.com>; Wed, 23 May 2018 17:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 UK6uHFigWu0C for <netconf@ietfa.amsl.com>; Wed, 23 May 2018 17:50:46 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 7627112D943 for <netconf@ietf.org>; Wed, 23 May 2018 17:50:46 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4O0nJHq024250; Wed, 23 May 2018 17:50:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=6IG4vXrGB9AXIBHVR9tz+I/bv+/705LNo4b0a2e4FK4=; b=fOQ6W2uedvuhWCzypZshRPcWM4CGitTEAFMKJzlE9b59x+peAJeY67f4PE9Uv8oIohoY VvCYGNuBvsuZH4HhqW1/1Dj8BKuM+57tEyaWByDCrvEb7n09qF0STW2xXsm9bdy8Ahi4 0wa+ony6qW8Z26lJVhF25uLoedse3gyUzBiMT2YVzuj9m58ber7wzeg9fp/UI8ry5QnL SsDLhcItiNuIJSs2/X6pTlqk0FyaZ9SCDfFroBB2LaAWdAYrZsb1/dvqK/lrIh2AfDKS GFYnaQaI3J0Xq18hj8Pl9cfeNApX4ag/VrRcSziKQ98zXJLvhE//E4BEkDIQVwnCPO+c Qw==
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0020.outbound.protection.outlook.com [207.46.163.20]) by mx0b-00273201.pphosted.com with ESMTP id 2j5df3rjjs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 23 May 2018 17:50:45 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4165.namprd05.prod.outlook.com (52.135.200.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.5; Thu, 24 May 2018 00:50:42 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::95f0:e564:96c8:7f1c%2]) with mapi id 15.20.0797.011; Thu, 24 May 2018 00:50:42 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "Eric Voit (evoit)" <evoit@cisco.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Adoption poll for crypto-types and trust-anchors
Thread-Index: AQHT4wADJ2ALQ9zNKkqYEk+Kq3yYtKQfpfMAgASX5ZD///FoAIAB9YWggAMvS4CAAEU6sIATvX/QgACSpAA=
Date: Thu, 24 May 2018 00:50:42 +0000
Message-ID: <6EC4BBB7-F11B-492E-ACD1-3E50E38ECE3D@juniper.net>
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> <2474b9e72e734988bf5b6bb5ebd67109@XCH-RTP-013.cisco.com>
In-Reply-To: <2474b9e72e734988bf5b6bb5ebd67109@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4165; 7:ouI/U/TZsPZUeqlTZcDdQhg056UagZWIN4OHajf04aUKLdDX7rlSINZXhuGpU8XGQkMmKiMjx/v/xWtvOF4J9vfHtSvZX/ngluOULGBEhmj6qeKZ47FZapwQYJrE/It0XH7cfy4U6e1TAoNolxJbZOR4Dxung2LTC6wgQZFznQPMPE6gbYqYXe9WcC4a0L6k2LA4CjKb85qoZvEkWczD7J7v0f2nTmBJuNlOlPnn95+r5YjNKgnwCD3mqs9vrwZ6
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4165;
x-ms-traffictypediagnostic: BYAPR05MB4165:
x-microsoft-antispam-prvs: <BYAPR05MB416564A1379C558E07874BD3A56A0@BYAPR05MB4165.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(95692535739014)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4165; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4165;
x-forefront-prvs: 0682FC00E8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(376002)(396003)(39380400002)(199004)(189003)(76176011)(54896002)(99286004)(11346002)(6436002)(476003)(102836004)(486006)(2616005)(26005)(6246003)(105586002)(68736007)(8936002)(33656002)(36756003)(6512007)(229853002)(6306002)(58126008)(316002)(236005)(93886005)(186003)(6506007)(6486002)(446003)(53546011)(59450400001)(53936002)(86362001)(82746002)(5250100002)(4326008)(3846002)(97736004)(6916009)(478600001)(6116002)(25786009)(7736002)(81156014)(14454004)(83716003)(3660700001)(8676002)(106356001)(66066001)(81166006)(5660300001)(2906002)(2900100001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4165; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: PMwam648jfcJBATj+scA1LE1UVkMKtI+yGjfIvDKyZOoBnadN/N0l5osJzIcITO2gQuzvOgbh5xk8SKXkb00yM7m+KkHitTU1M0tW72hGVnoLWqqDRMVX2oAHuVCX2mjElJOn8Urv9mqzcXCpGoe7ushQp4UEmTftN0vZw6rPu8AC9JIWKeg28gyvtqN1Yks
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_6EC4BBB7F11B492EACD13E50E38ECE3Djunipernet_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: d69d0b86-5ddb-46ea-0fcb-08d5c11060b3
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: d69d0b86-5ddb-46ea-0fcb-08d5c11060b3
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2018 00:50:42.7997 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4165
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-23_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=929 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805240009
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/yPd2v8fOmArQ_-hG5LK0aALPBdI>
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: Thu, 24 May 2018 00:50:51 -0000

Makes sense.  Thanks Eric.
Nothing more below.
Kent



On 5/23/18, 8:12 AM, "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>> wrote:

From: Eric Voit, May 11, 2018 6:13 PM


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.

<Eric3>  Based on the set of discussions, I support adoption.  This is worthwhile topic for the WG.
Eric

Eric

Kent // contributor