Re: [netconf] [Taps] crypto-types fallback strategy

tom petch <daedulus@btconnect.com> Fri, 27 September 2019 11:00 UTC

Return-Path: <daedulus@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 5410F12083D; Fri, 27 Sep 2019 04:00:40 -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 CO2AtZB2qRTO; Fri, 27 Sep 2019 04:00:37 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20106.outbound.protection.outlook.com [40.107.2.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E68A120848; Fri, 27 Sep 2019 04:00:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eOxaUSoBMQvOQtvc/WV24NPW/v2I/ywTjEYGWj5UpZ1UeJWw6BETOnso22oR/WWQ9IJgVSTsbbKBaOSjYriXIgY8kGTaXxNiHooLidTl5suNMtrSfHbGLDZfYOLOGrxkLHLi0ynxhxiaGFrdOtav7jDh5KPBkxh4Ro/kFXOGcqznu+LAA17oWbm4FdGuu+urOduoX3MTgzSNWL8b5lZ6sRAHH2B6j6tvKZkDFKdQSypo84xdeWRzIUmVMyk0TS99/sDRklL3X8z39yxR6HUlQGGV0gFx1WYKCMgZhmLvAwAQW9VQvPShrOVLdP5EnyyHUndDKVoMZO0rG9wBemvRoA==
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=8RWZEdGRp66ZrTnvGCG/m9ZFoFbzBQIIJoHBvB5gRKM=; b=i0lqAQgYPpVcdWyy/0eWW0f1MhfRcKtbYF/Zt8Z8srX66aaZTk3XVyUAxFr3G9G+3rfmzuKiqDSNVSqF/cgeOnNS44E6PqklGc08joEsNgGhaY+9oOtmTCEFphqqPQ+Vln57HEfJ9syb6ngJALJUw/4kcth1tWGYmfY4QvO1+KhsUGbS457MDvuLbsS+2mqDXuBFAPGZIfTTKARgQI08wj5atzlpjgFcywBVkD+0VrVpIZ7guiHgFQPf9rELwH2xUeDD+IlbgmxnZzgLYZ9JhG1/qvm2kWdtJwA7CBb2DCTm17uy5nydcOZm/jUPOxOOdwcG1bn7peTVHXXqfxQFAw==
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=8RWZEdGRp66ZrTnvGCG/m9ZFoFbzBQIIJoHBvB5gRKM=; b=PsDbAldC6opyszVDG79vhR9sMEsRa6Z1s01Xe/98iEw3UBwU1fxu53pZRYatU68SoYnDjVtl2zwcqifeLECdXnyb6dHQStCT80g+hWq0akGcP5WHlRPUjXy69mwo7JV1UcsNcbJNuZMt70AeWenFViUB/DD6Ew7XIjr6lMwYxoE=
Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB5362.eurprd07.prod.outlook.com (20.178.23.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.13; Fri, 27 Sep 2019 11:00:32 +0000
Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3%3]) with mapi id 15.20.2305.017; Fri, 27 Sep 2019 11:00:32 +0000
From: tom petch <daedulus@btconnect.com>
To: "Holland, Jake" <jholland@akamai.com>, "Salz, Rich" <rsalz@akamai.com>
CC: "netconf@ietf.org" <netconf@ietf.org>, "taps@ietf.org" <taps@ietf.org>
Thread-Topic: [Taps] [netconf] crypto-types fallback strategy
Thread-Index: AQHVdSLIiIMcLXKzwkKSh5zqgsfzeQ==
Date: Fri, 27 Sep 2019 11:00:32 +0000
Message-ID: <01e501d57522$842edfe0$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> <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> <AFB2FE43-947F-428B-8087-A8BB22445E2D@akamai.com> <3F71FEE6-3679-4482-B210-6585A15E0BA7@akamai.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0102.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::18) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@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: f7ecedee-b479-48c5-fe58-08d74339ea75
x-ms-traffictypediagnostic: AM0PR07MB5362:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <AM0PR07MB5362FD9BFF24308F9797467CC6810@AM0PR07MB5362.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0173C6D4D5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(366004)(396003)(136003)(199004)(189003)(51444003)(13464003)(64756008)(3846002)(6486002)(966005)(61296003)(6436002)(186003)(44736005)(14454004)(110136005)(81166006)(81156014)(229853002)(476003)(50226002)(316002)(54906003)(4326008)(14496001)(2906002)(305945005)(486006)(446003)(8676002)(14444005)(256004)(76176011)(99286004)(81686011)(53546011)(6506007)(386003)(25786009)(62236002)(26005)(44716002)(66574012)(8936002)(66556008)(6116002)(86362001)(478600001)(7736002)(81816011)(102836004)(6306002)(52116002)(5660300002)(6512007)(9686003)(66476007)(66446008)(71200400001)(66066001)(1556002)(66946007)(71190400001)(4720700003)(6246003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB5362; H:AM0PR07MB5716.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: RIQAeWOuDL492lh3WYxjGVMx/7Q/GQvCVWTQpCgbm5PTxHoyKv55qXRRv+Khl2DtZr+rSY8mX47di34bMmlskrYOwuiW1Q67XP3e0gGmeOh4aDOTTff4/PPSpeXtPvkQGp8JRwb+dCj975f5qWJxVTDkeADjLXe/ggULyfIAZkljkUsWR5+PI0Tyrj94YNKb4f5VRK3NKR9FpW6K3RprQgpogv/+AJDzmIX5mw91UO4YpsnQ2Da9PzCbVF6GrDDYOwJWfC9j3OWgB1fkBNy0OJnAOQBN2i9G+vOvjata59rtuEENzOMONRmHLK7c3hQ5U/zQnb9jA9CWK220ifDP/vTw+atvY0wvIwCQRpCDqHYO/Se/m4iWMGFq7sliIMJtUYF++bNrGo20NULaRr7rM+4qRFGQvOhC/2w2cVTfEAJmlJHE8Vu3QROU5qbx2c9f3uJdCdvY4A7fUn+NeV1Oxw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <EF2EF3608949D442BA9F151950F0E1C0@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f7ecedee-b479-48c5-fe58-08d74339ea75
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 11:00:32.4361 (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: vmgJbR6KL9f3UTqsHn615Vmwh1yQv+PQVqn7NYrTZCSx2gh61u3G11edD1FO8bgN1os/8xYqRITDWXFm2GWWjQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5362
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/vQ8j2d8SixtzYW348y5ywnlj4_Q>
Subject: Re: [netconf] [Taps] 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: Fri, 27 Sep 2019 11:00:48 -0000

----- Original Message -----
From: "Holland, Jake" <jholland@akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: <netconf@ietf.org>; <taps@ietf.org>
Sent: Tuesday, September 24, 2019 9:38 PM

> (+taps)
> Hi,
>
> Thanks for taking a look at that model, Tom.  I'll give just a
> little background:
>
> The current taps-api structure was driven basically by an attempt to
> support the examples given in the taps-interface draft, for instance
> in section 5.3.1:
> https://tools.ietf.org/html/draft-ietf-taps-interface-04#section-5.3.1
>
> I didn't do much (or any? don't recall...) of a search for crypto
> models before throwing together the early ietf-taps-api.yang drafts,
> including the security config stuff.  I mostly worked off the API
> examples, with intent to look for a more serious answer later as
> we try to integrate the secure connection support into a reference
> implementation or 2.
>
> What's there now hasn't been through any kind of security review, and
> I'd characterize it as a placeholder, at the moment.  (The taps use of
> yang is still relatively immature.)
>
> I'd be very grateful for a grouping or object of some kind that I
> could pull in by import from another module, and would support
> using it in taps-api-yang if we can use it to do what we need (which
> is to configure connection endpoints to allow secured connections,
> for either client or server endpoints).  I think that would make for
> a very helpful improvement.
>
> Part of the point of using yang in taps was to be able to better
exploit
> yang work from other wgs, and this would be an excellent opportunity
to
> put that into practice, I think.  So I would be very delighted to
import
> a model that does this right.

Jake,

Yes!  Part of the remit of the NETCONF and NETMOD WG  is to produce YANG
modules for general use by other WG and
draft-ietf-netconf-crypto-types
is part of that.  The NETCONF *client-server* modules would be another
example

Crypto has different object classes - hash, MAC, KEX, encrypt,
signature - with plenty of options for most of these.  YANG lacks a
subset feature for saying this is the MTI subset and here are others for
you to consider; unless you divide the space up with base YANG modules
and augmentations thereto, an option which has been discussed on the
NETCONF list and not found favour.

And then you have SSH and TLS which take radically different approaches,
with TLS having ciphersuites and TLS itself changing what it uses with a
change of version.

So is a list of everything possible, in a tree or mesh structure of YANG
identity going to be useful to other WG?

Your I-D caught my eye and seemed to be a different approach based on
this is what most implementations of TLS 1.2 will need, and limiting it
to that; a different approach to
draft-ietf-netconf-crypto-types
which made me wonder if the latter would be of any use to you; and if
not, if anything would.

Tom Petch

> Best,
> Jake
>
> On 2019-09-24, 13:02, "Salz, Rich" <rsalz@akamai.com> wrote:
>
> Jake,
>
> As the author of the draft referenced below, do you care to comment?
>
> The crypto-types document in the netconf WG is undergoing some pretty
drastic surgery.
>
>
> On 9/24/19, 4:50 AM, "tom petch" <ietfc@btconnect.com> wrote:
>
>     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 mailing list
>     netconf@ietf.org
>     https://www.ietf.org/mailman/listinfo/netconf
>
>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>