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: Jürgen <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
- [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Per Hedeland
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Per Hedeland
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy tom petch
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- [netconf] FW: crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Holland, Jake
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] [Taps] crypto-types fallback strate… tom petch
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy tom petch
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy tom petch
- Re: [netconf] crypto-types fallback strategy Wang Haiguang
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund