Re: [netconf] crypto-types fallback strategy

Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de> Wed, 18 September 2019 17:41 UTC

Return-Path: <J.Schoenwaelder@jacobs-university.de>
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 8388D120B0A for <netconf@ietfa.amsl.com>; Wed, 18 Sep 2019 10:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 13iK75dlKCN6 for <netconf@ietfa.amsl.com>; Wed, 18 Sep 2019 10:41:14 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130048.outbound.protection.outlook.com [40.107.13.48]) (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 54B74120AE1 for <netconf@ietf.org>; Wed, 18 Sep 2019 10:41:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SpCp/0RNESK1eWOKVyaRtXNOXFjq6t7EPl2b4tMf/ag29WV5rlR5Oq65iM97ouOftPT3d1+vftp7qyeKS5RcPvAiUAo0VIzAuPRlgtaBLKfjfseNY30R0HkGDLIGqU+sTk4+aB/9XlzAW2NmoDA/isYtxoRqXmhPGt2dK3bUiebPmh+DMqUD9USgp05ldSinlSVHt3SnDkWorQwTAarSYhhgn6OAiBpSMuzuO/a+TRcyQjUcCW/89juLdmLPOUkENgrAGtvQzCmsALZvL9cJYoJqQEW82qpsoOzO7ILyceNOarRihp0jNJ+uJG9TghGnlPgJWd5Rig/DuaZOrcv4Sw==
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=fq1PsYxYP/ehdmXf0gmiCKm5KfJe/oHuZobb0q0q8os=; b=jcpsk3BbkfjtNXELShtB0+vPuP0x6oj5gmAPxKJ0yb3Om1YZyIUq1tWPj6FndUMz4BJmP2BNPDvzAuODrWMYSKkBd5O79dLkRjpeeNKV8Hky/2VNB5iGCgU/Lg5KLFO/yTwT//e0bLcqKKhh9v+2ZV/qINMC+cacdi4Zr+HdZ8hiQ9UcIcA4CUg/jW6/ewsikakQ1p/yf6yFHqmt1sQ2ZM4Fn8czAmNMo/i9JEIkZqvQ9BgVHDt8PI4sajx3aPRuyKguMJ0z8Re7wE9P7KU0hmboDsywk52vjkI5W64w1CI+NP1QdnVYAMjrz3hcNKP2l49J3WwdDUA7Bif2XbGQOQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fq1PsYxYP/ehdmXf0gmiCKm5KfJe/oHuZobb0q0q8os=; b=dR1iey4xpJbOMlyI6W8BQ0H8smI8bVIz2K1cXyYm7X0mL4tHq+Tec20Do1AuPbvuVhKrr0ROLTcKsLfGiImGsDyDjUriihDT6MoKmze+vViwNoznniZ+4QC2SWS3D3k3tCWTpwFZLsc0dQB/09/+ss6Q0xXQ3A0wJO6yl0DxFqo=
Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0285.EURP190.PROD.OUTLOOK.COM (10.165.197.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.15; Wed, 18 Sep 2019 17:41:09 +0000
Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e%2]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 17:41:09 +0000
From: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Thread-Topic: [netconf] crypto-types fallback strategy
Thread-Index: AQHVbjbxVhFlbERW30moo9Q8WhnpJqcxoiSAgAAJ6YCAAAgFgA==
Date: Wed, 18 Sep 2019 17:41:08 +0000
Message-ID: <20190918174107.lqipsd2qal5x7eom@anna.jacobs.jacobs-university.de>
References: <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <MN2PR11MB4366B5C09B4348FDAE33E2BCB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <MN2PR11MB4366F20EE2FD6DF04B965125B58E0@MN2PR11MB4366.namprd11.prod.outlook.com> <EBE4757D-E99E-41EB-A52B-A25F023BF4BC@akamai.com> <MN2PR11MB4366E4ECE10DFB018941BA5FB58E0@MN2PR11MB4366.namprd11.prod.outlook.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <MN2PR11MB436617082A8308A7A8928DDFB58E0@MN2PR11MB4366.namprd11.prod.outlook.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com>
In-Reply-To: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com>
Reply-To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: PR0P264CA0155.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1b::23) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:638:709:5::7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 853527d9-163b-4042-b745-08d73c5f63aa
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1P190MB0285;
x-ms-traffictypediagnostic: VI1P190MB0285:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <VI1P190MB0285EE5CF00AE7A3725D40BFDE8E0@VI1P190MB0285.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01644DCF4A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(39850400004)(346002)(376002)(396003)(199004)(189003)(25786009)(478600001)(8676002)(6246003)(2906002)(99286004)(14454004)(6506007)(786003)(46003)(316002)(8936002)(486006)(7736002)(256004)(14444005)(305945005)(54906003)(476003)(71200400001)(81166006)(81156014)(71190400001)(11346002)(6116002)(446003)(6436002)(86362001)(186003)(6306002)(1076003)(386003)(5660300002)(43066004)(102836004)(3450700001)(45776006)(6512007)(229853002)(52116002)(6486002)(66946007)(66446008)(76176011)(66556008)(4326008)(66476007)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0285; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 1g4LQYGKaFc3jQGy0L3RWJpyYq46WrUFcwq22bJN7jXbyTbV5GQAIKOGTJP3n2sk9e33rirzjazDQ35MLKn6eVEwUJMYvJA+ivJYd2k6k42/Rdle8bkmM8bZAjJIpvY3/HH1fK+Fx3Rbe5vJv4wrtI7DHZPmfP9VzHK/Ud+nxrawirt1bZTx5/o7WtW9bb4HsmzY1yl0SX3vUPnUadQl+hfx4YpNGTzCcuwv3SehkH071bIh1gdfQus5jT3fqCo9eMwNrkYqI7XjRaKUFjgV96rXF8KjvJAQzsfvUSLgEuxGCEzo8ElpWf3sk8d6zUcegPhsl47hS9r74Hie+sn6LvMGbpumImavlYhA9LLZx+Dt4WR6tNuGBFfwzRfHfCqPRSvzNDLfbKBrK+vl97B/y68Qx3iPzUYlnhpF4WFwXgc=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <BB2B69A46A423B4FA89F90AEAA2135C6@EURP190.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 853527d9-163b-4042-b745-08d73c5f63aa
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 17:41:08.9127 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dbbZ2iasPBm5rtaP7eKxWOiYGJFhqD11xin1yhC9xbMVzqfSW469xpEReLNkVjvPoU61uo5ZbNH3UCWIoSx/iqZhoaXy6oXWHTa1uS0d8BA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0285
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/FRcJfGabnierDJdHB2RrfHCMJdM>
Subject: Re: [netconf] crypto-types fallback strategy
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: Wed, 18 Sep 2019 17:41:16 -0000

On Wed, Sep 18, 2019 at 05:12:25PM +0000, Kent Watsen wrote:
> > 
> > I would check what is commonly used in existing configuration
> > interfaces. We are not inventing the wheel here. And whatever we
> > define better is usable with existing implementations and tools.
> 
> These are the native types used by OpenSSL and OpenSSH, what more verification do we need?   
> 
> Possibly we could discuss supporting PEM, in addition to DER, but I'd image that, if PEM is supported at all, the presentation layer (Web UI, CLI) would convert it to/from PEM as needed (i.e., the underlying model only needs to support DER).
>

On my Linux system, certs tend to be stoed in pem format, so I am
biased. It seems some other applications like web browsers and server
also tend to use pem format. But I am happy to be corrected since my
experience with cert usage is limited.

Yes, the application or presentation could convert between formats and
solve all problems. One of the failures of SNMP was that SNMP required
an application or presentation layer to be usable while CLIs did not
require other tools. The idea that there is always software between
the NC/RC server and whoever has to solve an automation problem has
somehow failed in the past. I believe data models should be written to
enable automation without requiring lots of additional tooling. And
yes, there is a need to find a balance.
 
> > The SSH implementations that I use have the binary key data rendered
> > in ASCII. In fact, the whole key record is rendered in ASCII. I
> > strongly suggest to use formats that are well established.
> 
> This is the "key-data" leaf from RFC 7317.  Are you saying that it should've been different?
> 
> Regardless, should this be a presentation layer issue?

See above, if we start to require a presentation layer, we may repeat
a failure. It might be useful to check who has implemented that part
of RFC 7317 and how happy operators were with the format. I personally
would not immediately know how to convert my openssh key in a binary
format such that that I can use the YANG model. We should try to
maximize usability and stay away from the idea that a presentation
layer will be available to make things usable for people that have to
script customized automation solutions.

/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/>