Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types

tom petch <ietfc@btconnect.com> Thu, 25 April 2019 11:01 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 03F79120071 for <netconf@ietfa.amsl.com>; Thu, 25 Apr 2019 04:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Level:
X-Spam-Status: No, score=0.247 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] 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 xKd3dXhWT4rx for <netconf@ietfa.amsl.com>; Thu, 25 Apr 2019 04:01:52 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80102.outbound.protection.outlook.com [40.107.8.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FB8120021 for <netconf@ietf.org>; Thu, 25 Apr 2019 04:01:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wSUevAkgVTrxZMjLRDujwJ4FQ0MSTE45DSax1hBvBYw=; b=Gu6UcK+l39ekrSfnV4I4kfNwdZJ282wsQDsTV3rrS7aYWd6BX3EJpdPCj8DVB3f2HHZtr1aI20FNT9Y1nF8ovde/m6nxVxTrZHlZxJDRq89kM2fk5I1qpXUYHB6byb56x6Y4RpK0QNqc45lMl3mYMjysmi3ZmCvsj3DPf8aprDo=
Received: from DB7PR07MB5562.eurprd07.prod.outlook.com (20.178.46.212) by DB7PR07MB4997.eurprd07.prod.outlook.com (20.177.193.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Thu, 25 Apr 2019 11:01:49 +0000
Received: from DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::89bf:8194:3f8c:ff65]) by DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::89bf:8194:3f8c:ff65%6]) with mapi id 15.20.1835.010; Thu, 25 Apr 2019 11:01:49 +0000
From: tom petch <ietfc@btconnect.com>
To: Wang Haiguang <wang.haiguang.shieldlab@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types
Thread-Index: AQHU+1ZHgZ5Vg/wJskmQTLEgbjEyCQ==
Date: Thu, 25 Apr 2019 11:01:49 +0000
Message-ID: <01e301d4fb55$d1cc3500$4001a8c0@gateway.2wire.net>
References: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0226.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:b::22) To DB7PR07MB5562.eurprd07.prod.outlook.com (2603:10a6:10:7b::20)
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.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5994c3c1-9f07-46a7-e028-08d6c96d69c4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DB7PR07MB4997;
x-ms-traffictypediagnostic: DB7PR07MB4997:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <DB7PR07MB4997E506784A3D00B4D02CEFA03D0@DB7PR07MB4997.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0018A2705B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(39860400002)(396003)(366004)(346002)(189003)(199004)(13464003)(81156014)(81166006)(8676002)(84392002)(81686011)(61296003)(81816011)(256004)(99286004)(44736005)(86362001)(76176011)(2906002)(6486002)(71190400001)(6436002)(66476007)(97736004)(25786009)(52116002)(66556008)(64756008)(66446008)(73956011)(66946007)(110136005)(316002)(4720700003)(71200400001)(186003)(66066001)(53936002)(6116002)(68736007)(6506007)(386003)(26005)(86152003)(2501003)(44716002)(62236002)(476003)(446003)(486006)(229853002)(6246003)(3846002)(9686003)(6512007)(6306002)(966005)(14454004)(305945005)(7736002)(50226002)(478600001)(1556002)(102836004)(5660300002)(14496001)(8936002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB4997; H:DB7PR07MB5562.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: L4KhPvhz9sAC4AFqyaeZBpaeRROVB1rppWf+TJP7EhpNkGpgSlhwPBSFKH1VYfGOGcPDqj7QH1/5JswOUAGt6GTW5wZUu7x3CfSc1B72fKU7a+KfJPevBRshqjkujzHujpzTDFYjBDrgutF+fwUrliH9f1wowzzhSrPPCpJoFbxDoxyhasHAqtZgZmtnPirGPghHlrpCvzE35XK6hrCmi271QPTRHLvSrnof++z6dDdjqHcEPKkLydUgVC4VmQ39Itof4jMxNYkcoxm2o6E5m2s4wLx7z17vkhz735hHrQ00OfWkdPKe93wBcMhkBgbg5xSC7FTpF3XOojI1EONdUQ1YjTkevA9E3A3GPnm9/g4A4LEjKSzgK0TyJyJVwEChAeAafqd8hjD+YfLr7plaGGd42LGDR0mFSJ55KElqkKE=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1AA877A44D1EC142832F3868063EDEEE@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5994c3c1-9f07-46a7-e028-08d6c96d69c4
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 11:01:49.5881 (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-Transport-CrossTenantHeadersStamped: DB7PR07MB4997
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/L28PlREKEAZPF1lsc_JRAB6Py-c>
Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types
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: Thu, 25 Apr 2019 11:01:55 -0000

----- Original Message -----
From: "Wang Haiguang" <wang.haiguang.shieldlab@huawei.com>
Sent: Thursday, April 25, 2019 4:22 AM

Hello, everyone.

Recently there are some discussions in i2nsf group over the crypto
algorithm identifiers defined in the draft-ietf-cryoto-types.
Please refer to the email thread below for the discussion there:
https://mailarchive.ietf.org/arch/msg/i2nsf/XZevQcuifa_PN6OeZMLaMch3mAo

The basic concerns in the email is as follows:

1.       Crypto-types contains a generic list of crypto algorithms. Some
of them are not supported by IPSec, how should they handle this.

a.       Somebody suggest to include a subset of the supported
algorithms in their draft. I think it is a good idea.

2.       Some deprecated algorithm are needed by their draft.

a.       Some expert suggested to define those identifiers by them own
within their draft. I think this is a feasible solution.

For the above issue, I think we can add some text in
draft-ietf-crypto-types to guide users from other group how to handle
the above two issues.

Beside that,  in the future, some new algorithms might be added and some
algorithms will be deprecated, we have to figure out how to made the
algorithm list defined by crypto-types flexible.

<tp>

To state the obvious (?), the larger something is the more unstable it
is so putting in the kitchen sink - KEX, HASH, MAC... - all into one
module is going to increase the churn on that module, as opposed to
having separate (sub-?)modules for e.g. KEX, MAC. HASH.

Again, to state the obvious, if this mega-module is published as an RFC,
then it must be updated by further RFC, once agreement has been reached
on what has become obsolete, too insecure etc.

Two technological solutions come to mind; divide the module up into
smaller pieces which would require more changes in total but fewer for
any one of the subdivided modules.

And make the module(s) IANA-controlled which allows a spectrum of ways
in which updates can be performed, from FCFS to Standards Track RFC and
which allows different approaches for e.g. KEX and HASH.

Tom Petch






If you have any suggestion, please post it on the mailing list.

Let's discuss and find a feasible solution to it.

Best Regards.

Haiguang



------------------------------------------------------------------------
--------


> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>