Re: [netconf] crypto-types fallback strategy

tom petch <ietfc@btconnect.com> Tue, 24 September 2019 08:50 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 BD63C120120 for <netconf@ietfa.amsl.com>; Tue, 24 Sep 2019 01:50:11 -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 DlP8aJbcb6vN for <netconf@ietfa.amsl.com>; Tue, 24 Sep 2019 01:50:09 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130123.outbound.protection.outlook.com [40.107.13.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606121201A3 for <netconf@ietf.org>; Tue, 24 Sep 2019 01:50:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O2kQh9D8JdW6Ij4V7RFsejgR69ProuVZxfUUHEueQaZLVqT+56Q4ByyhH73z9tPPnliHgiuCZzuhlV9A2Rie540sSu11t07+UJg/L7/HtU+43+Swavk+fToBVcdkSvIvRwmFowO5OzovmahccGttP44hLtLa9KQEFWVGRsbTWmBeu7EdocerQMc7xFNzzumAAk+mDXImnamVoRtHM9VQ9a8vfr69i8y1K20XTs0ipzI7Mc32UeqVfCLSFoI4LGHLECu+2k0wyDSH0Yy7a2Wvso+2svfQuDpqmLED08RY0sdvKePPOAQySxPtoHWNRF+OnCLgmUY7OVXrRD1wXfhLoQ==
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=ZxN1gNdmoJzWL8VYkf0PNb54AhAg4plTK57sdmmJKeY=; b=kxi3HKicbEvgq3Hh2cOdVlse/4bMEacBn2U3tBO+szbjVxdRfuD/dAs39lFuG/XuV7ZzAsRGmGZ5wVM3OjcFbgknEvYAeI/mIrb50QPK8qYnKOeXvRfV0vwUBExWLO3WCv5+ODzpSxPOuaqrRkEk/FcSkM8r7Lf415vh4IGKJKvQKn0h3dI8W2EkeX9sOlcY1qxBm5tp8DZ9NgNFcv7fnFjSzbay5oFRDSligye5M6SM9hjZUsnpg0fhpxafVrQeNVjiq8JNmlWXmJJ6tst/bTWuTHoCxxZwwxUWmkTcTjyfZY4JQjlChBN3xn/0MX2p58LzwvhEJR5fS/wb7iYkTw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZxN1gNdmoJzWL8VYkf0PNb54AhAg4plTK57sdmmJKeY=; b=IEMUUaVBfnhVy6f5xI76AwixmUvtG/VVQ00MtBOPVYHSA5NHUzBuwYYZyPeHBc3qJzntiDPBwkYrfZZskTdou+1ghk83LLC3VEdjcvvIrt/BfNXK0rU8AgEnTWbFA2dFc/OZ95sTtsd/zsNERD2Xv8vAWQfc0GRVgI+pvKyMvVQ=
Received: from AM6PR07MB5944.eurprd07.prod.outlook.com (20.178.91.205) by AM6PR07MB5076.eurprd07.prod.outlook.com (20.177.119.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.13; Tue, 24 Sep 2019 08:50:06 +0000
Received: from AM6PR07MB5944.eurprd07.prod.outlook.com ([fe80::c01e:2ff4:7649:142]) by AM6PR07MB5944.eurprd07.prod.outlook.com ([fe80::c01e:2ff4:7649:142%7]) with mapi id 15.20.2284.023; Tue, 24 Sep 2019 08:50:06 +0000
From: tom petch <ietfc@btconnect.com>
To: =?iso-8859-1?Q?J=FCrgen?= <J.Schoenwaelder@jacobs-university.de>, "Rob Wilton (rwilton)" <rwilton@cisco.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] crypto-types fallback strategy
Thread-Index: AQHVcrUQ0Ns6WykVUk6hpO31wncbaw==
Date: Tue, 24 Sep 2019 08:50:06 +0000
Message-ID: <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net>
References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <MN2PR11MB43669B3A47A39FD93B47292FB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <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>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0201.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::21) To AM6PR07MB5944.eurprd07.prod.outlook.com (2603:10a6:20b:90::13)
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.211.103]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 590f797e-3f99-4a37-ab25-08d740cc32a8
x-ms-traffictypediagnostic: AM6PR07MB5076:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <AM6PR07MB5076FB1A35867B2F219A1D46A0840@AM6PR07MB5076.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0170DAF08C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(346002)(366004)(396003)(376002)(199004)(189003)(51444003)(13464003)(6116002)(62236002)(478600001)(44716002)(486006)(1556002)(9686003)(6306002)(316002)(186003)(66066001)(386003)(6506007)(76176011)(81816011)(81686011)(52116002)(66446008)(8676002)(81156014)(5660300002)(229853002)(99286004)(71190400001)(71200400001)(6512007)(110136005)(4720700003)(64756008)(6486002)(6436002)(446003)(61296003)(14496001)(305945005)(25786009)(8936002)(476003)(66556008)(66946007)(7736002)(66476007)(81166006)(44736005)(102836004)(966005)(14454004)(256004)(14444005)(66574012)(6246003)(50226002)(3846002)(26005)(86362001)(2906002)(4326008)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5076; H:AM6PR07MB5944.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Z+K8bBeim0OFGcJX7W6CseOyzTfQEHFpUFIo3hwnQTdXOaYVgHEvcqM1GvjPmA7Je2CB90FoKtQGHAGyA4naQIXGi1BfvfUpLarrhLqbyv9ld798kCcV6XYtv/sQfJydL5oUdkJ52RgQretyg7/n68lYokSsCk9luDmsVVDfg+DLMmRe4va0yxrufCnRcLu1BRmWHvR15saMykQOr52I4shE/wb0xmfud7wZdkTyPjNTwPqGiS1c8BPjQAlc2S4SU0OzGyY/h2sGz5azCnz0u1fvlfO4fXtPdWd3PK4WtLgHC9kmB0OOOXVTVEs6k9opau9E34tH4E4xNnsjnItKD09tr43FuS5iIFZbkGlqvOy9dZasauztuhAGjcVKWegNqUBrOOn8YKfoJ5K0JkzieTL8XREjCrZHtoSNTs9OOUgtIS0pfShGwaY8dn5RO22OKa2xv6GHwhzB1B+oGFnAAQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <D7C069C52F0AEE439C60C55D6589C898@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 590f797e-3f99-4a37-ab25-08d740cc32a8
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 08:50:06.5584 (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-CrossTenant-userprincipalname: aSWLgRxHWS78N5Tk88ee9FW4jWCLWWFIHw2PKMhzgAWmZeEFBquE5Y+uBrDM0dxDqiWEFRA4yelfebZ/GJKXCg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5076
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/lcfroX0f5bRF4d8QLbpqVVCHeJk>
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: Tue, 24 Sep 2019 08:50:12 -0000

Going back a bit, since this is a more generic comment, I get a
different, simpler perspective in
draft-jholland-taps-api-yang
which has me wondering just how complicated this needs to be for it to
be useful in other WGs.

The I-D defines
  identity security-algorithm {description "Base identity for security
algorithms."
  identity cipher-suite { base security-algorithm;description "Base
identity for security cipher suites.";
  identity signature-algorithm {base security-algorithm;
description "Base identity for security signature algorithms.";
  identity ed25519 {base signature-algorithm;
  identity TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 {
    base cipher-suite;

and

  grouping security-credentials {
    leaf identity { type string;
    leaf trust-ca { type string;
    leaf algorithm { type identityref {base security-algorithm;
    leaf pre-shared-key { type string;
    leaf private-key { type string;
    leaf private-key-callback-handle {type string;
    leaf public-key {type string;

(No SSH but that does not surprise me:-)

Again a more general comment, the IETF often starts simple and adds lots
later, which sometimes goes wrong because no allowance was made for
slotting in extras, but an approach which, I think, more often leads to
successful adoption.

Thus will TAPS consider using
draft-ietf-netconf-crypto-types
or will they RYO?

Tom Petch

----- Original Message -----
From: <Schönwälder>; "Jürgen" <J.Schoenwaelder@jacobs-university.de>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: "Russ Housley" <housley@vigilsec.com>; <netconf@ietf.org>; "Sean
Turner" <sean@sn3rd.com>; "Rifaat Shekh-Yusef" <rifaat.ietf@gmail.com>
Sent: Wednesday, September 18, 2019 5:36 PM

> On Wed, Sep 18, 2019 at 03:37:14PM +0000, Rob Wilton (rwilton) wrote:
> > >From the gist of the discussion, the punch list appears to be:
> >
> > - revert back to using identities, as they were in the -08 revision.
> > - only define base identities for what's needed immediately for TLS
and SSH and keystore key-encryption.
> > - define these base identities in distinct YANG modules
> > - have each identity's description statement indicate what the
binary key data is encoded.
> > [RW]
> > I think that this matches my view, except for "define these base
identities in distinct YANG modules".  I don't feel particularly
strongly about this, but I was thinking that the base identities would
still be defined in crypto-types.yang, which might help keep the import
references simple.
>
> I tend to agree that sometimes less modules is more. For me, the
> problem is likely more that I am not entirely sure what the proper
> base types would be, which may depend on what exactly they are used
> for. I guess I wait until I see the description text...
>
> > A bit separate from the above, but still in mind:
> >
> >   - specify that all TLS public-keys are a DER-encoded
SubjectPublicKeyInfo structure
> >   - specify that all SSH public-keys are a "ssh-public-key-type"
type (see below)
> >   - specify that all encrypted symmetric keys are a DER-encoded
OneSymmetricKey structure
> >   - specify that all encrypted asymmetric keys are a DER-encoded
OneAsymmetricKey structure
>
> 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.
>
> > The "ssh-public-key" type would be defined as:
> >
> >      typedef ssh-public-key-type {
> >          type binary;
> >          mandatory true;
> >          description
> >            "The binary public key data for this SSH key, as
> >             specified by RFC 4253, Section 6.6, i.e.:
> >
> >               string    certificate or public key format
> >                         identifier
> >               byte[n]   key/certificate data.";
> >          reference
> >            "RFC 4253: The Secure Shell (SSH) Transport
> >                       Layer Protocol";
> >           }
>
> 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.
>
> /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