Re: [netconf] crypto-types fallback strategy

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 18 September 2019 09:36 UTC

Return-Path: <rwilton@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 D1F9D1201E4 for <netconf@ietfa.amsl.com>; Wed, 18 Sep 2019 02:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, URIBL_BLOCKED=0.001, 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 header.b=Ci9vcZYF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Dl/hmFuA
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 2sU9ONrJaGHe for <netconf@ietfa.amsl.com>; Wed, 18 Sep 2019 02:36:08 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67F81201C6 for <netconf@ietf.org>; Wed, 18 Sep 2019 02:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15970; q=dns/txt; s=iport; t=1568799367; x=1570008967; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aVXP3tltMMzvzHgTjiqimBF+Hf4mfQR+fSVbMFPvcx8=; b=Ci9vcZYFsdLRTYRivxpLRqODUwz7J/l4fqbFdtQ+9V+apqmAm7zTdn5p cWLoLinF86I28WFLeoFBI9soahWPKQA+SG8FsCdHTH8I0f3vi6ERkYikK d9c0alGto06pbYTD5kxyUY0ybYQb8uS1UMbOObU23VxE1g6LuMpvijyWX A=;
IronPort-PHdr: =?us-ascii?q?9a23=3AAUvSahBF+koxShWJCSE4UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNuHrazA9GuxJVURu+DewNk0GUMs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAAAg+oFd/4MNJK1dCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVQEAQEBAQsBgRUvUANtViAECyoKhBiDRwOKd4JciWaJMIR?= =?us-ascii?q?dgS6BJANUCQEBAQwBAS0CAQGEPwIXgmwjNQgOAgMJAQEEAQEBAgEFBG2FLQy?= =?us-ascii?q?FSgEBAQEDEhEKEwEBNwEPAgEGAhEEAQErAgICHxEdCAIEAQ0FCBqDAYEdTQM?= =?us-ascii?q?dAQKUY5BhAoE4iGFzgTKCfQEBBYUCDQuCFwmBNAGKRYFDGIFAP4FXgkw+ghq?= =?us-ascii?q?CABQYgwkygiaPVIUnJJccQQqCIpEDhBuZII4PihaOcwIEAgQFAg4BAQWBUwE?= =?us-ascii?q?2gVhwFYMngkKDcopTc4EpjioBgSIBAQ?=
X-IronPort-AV: E=Sophos;i="5.64,520,1559520000"; d="scan'208,217";a="633049017"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Sep 2019 09:36:06 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8I9a6Gi015942 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Sep 2019 09:36:06 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 04:36:05 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 05:36:04 -0400
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 18 Sep 2019 04:36:04 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fZFKD5iq6vVuXT77S/NqvC8XmA9fxWscJNCxnmWPJnhteyd5J1oRfSgK2fhAOmvFJh604EY4a8FA69Ve4zOR6EBlXa06C8Dt394yfby9AZbvfUlINQcqIItVtaLP6m+3ZbuilBR2ZOcfyf0hTkKMISSkgWRGXAGdmULhWX4+24HLz2WfohINQCcoIcWZN52+urQJ3d6p/YnjLQ4ZIh2s0Jw9CWcEWo3YhpfP6QbW2nIvTUzRkmqMvgjzJzQEQYBT67/fOdRUJVUzKaolClwSi+piZXaofweFZDi6sYWzdKnslpopEQOwfRq1BvixXl+mI7pzEL+x4jCThUfDv1m2bg==
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=aVXP3tltMMzvzHgTjiqimBF+Hf4mfQR+fSVbMFPvcx8=; b=YFyMhxSFRFQ8kAyDkF7v/OYuoFyNadQBVSqqfBMuDmPicWxGKhNefZmT1Xbvf6zJQsloh+z3nowSHf8Q6AWJl3FaZQvd28TnyWXtzIEuROoJnirc1xpErrcpn8+fWckhl6FmrBZrE3gpQk8UfnpQOyO6rIyGsHMyOhJEF1zt86oL5JN1uPmuczSE5lIUiv+uW3kzx8RMmdCmN2cezMIzEERbgLS7i7GpFpSqn4vWe+7F68VTfBT/jN6A/TnuMXweFDZAhCV2jOZ+gjf2QkBqwlZghQ9bLq3/3CeRn+q9e+2iD7WBVigPkXZdOOaFNnSxQJkVa90K143FlwPTQQTyrA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aVXP3tltMMzvzHgTjiqimBF+Hf4mfQR+fSVbMFPvcx8=; b=Dl/hmFuAs5iShHq6Wlgb65NeNuX4rJlwDaK15NHhf07vzKCZtjUQuPV9Utr2kgv0Lia+u77ZlW/40uqK+aqRctmYIVZSCLcs/DjnwQ/kDuM9xib3N5Jp1IlhRDuYSGzKY2IQG6GB3DzVa6AGAMA795cBawGgSwBPZN85q671SjI=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3630.namprd11.prod.outlook.com (20.178.253.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.20; Wed, 18 Sep 2019 09:36:03 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 09:36:03 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "Salz, Rich" <rsalz@akamai.com>, Kent Watsen <kent+ietf@watsen.net>
CC: Russ Housley <housley@vigilsec.com>, "netconf@ietf.org" <netconf@ietf.org>, Sean Turner <sean@sn3rd.com>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Thread-Topic: [netconf] crypto-types fallback strategy
Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAIAATvkAgAABvxCAAC5vAIAAAggggAADhQCAAQHLcA==
Date: Wed, 18 Sep 2019 09:36:03 +0000
Message-ID: <MN2PR11MB4366F20EE2FD6DF04B965125B58E0@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <MN2PR11MB4366AE6CF9E03B15EBEA3A39B5B30@MN2PR11MB4366.namprd11.prod.outlook.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <MN2PR11MB4366F63419F6BD4EF106766FB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <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>
In-Reply-To: <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.61]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6590751b-f9dc-44c7-0f99-08d73c1b9fd2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3630;
x-ms-traffictypediagnostic: MN2PR11MB3630:
x-microsoft-antispam-prvs: <MN2PR11MB3630DA85607602E7BF83AB18B58E0@MN2PR11MB3630.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01644DCF4A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(376002)(396003)(366004)(199004)(189003)(7696005)(66066001)(86362001)(478600001)(54906003)(8676002)(71200400001)(71190400001)(14454004)(74316002)(316002)(7736002)(110136005)(6436002)(256004)(81156014)(229853002)(6306002)(54896002)(55016002)(52536014)(186003)(5660300002)(76176011)(66946007)(102836004)(6506007)(53546011)(446003)(476003)(11346002)(66556008)(64756008)(66446008)(66476007)(26005)(486006)(4326008)(99286004)(6246003)(9686003)(76116006)(33656002)(81166006)(25786009)(9326002)(8936002)(3846002)(6116002)(790700001)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3630; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: c/MBofD0/w0aY7gzid4jhP5RUa3WWOp1miunmA3TX+JTadzsnepguuhdwNY/0bQavglc+sex0hXwRB2IV8nZMluISxdxkVjTXLBc2yrA75pJ/baYv9VIo5QtgZWwpc4IOJsNJdI3QKcFPeSnRZ/p/W/x6j4l+yc/i/dyQQoDscA6lkaKbbsH5+DEEZJanxDx9IVEVVPQ4t21+Jh4VSqehddnLTkWxw4pUyf3RrPuYsXDvC1BsjaEG0li9lC2UBGXtCxonG0WlDK3xNxqAWDve60n14wgSukSOZRCI+cA/aXvI1kRLxIaBbjHo3mGvBVrZfbrojWsyDUBoAN8raVsVQO1J4vv4q8eSkevla2QSx0Q3dp45NYAI6EvyJkJathkQBVXKQhpVp8vWMa6rI9x44lDjJVqAgwY+EfTWtcR5lU=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366F20EE2FD6DF04B965125B58E0MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6590751b-f9dc-44c7-0f99-08d73c1b9fd2
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 09:36:03.8632 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: U17I3FRsRhjGAv2pgMqBVdLmL9EKBc6ZJ+y8i8HwwqMmxvdMrTHPZLl4myA77sAc2m96gDlMPwp+1FghG3LcwA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3630
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/y0JCcvSz4u5qydJSnjdAWON5NYM>
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 09:36:11 -0000

Hi Rich,

From: Salz, Rich <rsalz@akamai.com>
Sent: 17 September 2019 18:07
To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; Kent Watsen <kent+ietf@watsen.net>
Cc: Russ Housley <housley@vigilsec.com>om>; netconf@ietf.org; Sean Turner <sean@sn3rd.com>om>; Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Subject: Re: [netconf] crypto-types fallback strategy

I do not think using algorithms as the base classes is a good idea.  I think it is much better to have the type of key material as the base class:
                asymmetric-key (RSA, ECC, etc)
                symmetric-key (AES 3DES etc)
                byte string (maybe…)
nonce (non-reused stream of bits used in AES-GCM, EdDSA signature, EDDSA signatures, etc)
                tag (used in KDF functions, almost always a text string)

The *use* of the identities should be implied by the operation.
[RW]
OK.  So, in YANG I think the definition of a base identity is effectively defined by how it is intended to be used.  I.e. somewhere in the model there is an identity reference that indicates that it can take any identity value that is derived from that base identity.

So, from the keystore model I can see:

“keystore/asymmetric-keys/asymmetric-key/algorithm” uses any identity derived from “asymmetric-key-algorithm”
“keystore/symmetric-keys/symmetric-key/algorithm” uses any identity derived from “encryption-algorithm”

I assume that the other base identities are used in the other drafts.

I also think that the identities are identifying encryption-key-algorithms, not the keys themselves, so having algorithm in the name doesn’t seem particularly strange.


I like the idea of partitioning by “here is what you need to configure a typical HTTPS server” in one document and “here is what you need to configure a typical SSH server”
[RW]
We still need to have care here.  Presumably there will be cases where the same key algorithm is used in multiple places.  I was partly trying to tie the partitioning into modules about where the algorithms are being defined (i.e. which RFCs) rather then where they are necessarily used.


Does that answer your question?
[RW]
Yes, thank you.

Thanks,
Rob