Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 25 April 2019 06:42 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
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 0484D1200EA for <netconf@ietfa.amsl.com>; Wed, 24 Apr 2019 23:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 ZqDfYHDkPHtA for <netconf@ietfa.amsl.com>; Wed, 24 Apr 2019 23:42:06 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D78C120133 for <netconf@ietf.org>; Wed, 24 Apr 2019 23:42:05 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3FE83DAC; Thu, 25 Apr 2019 08:42:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 7UbaEr3BPMsq; Thu, 25 Apr 2019 08:42:04 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 Apr 2019 08:42:04 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 207F1200D5; Thu, 25 Apr 2019 08:42:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id DkUyGYf0qLow; Thu, 25 Apr 2019 08:42:03 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A2950200D3; Thu, 25 Apr 2019 08:42:03 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Thu, 25 Apr 2019 08:42:03 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 7C01F300894B8A; Thu, 25 Apr 2019 08:42:02 +0200 (CEST)
Date: Thu, 25 Apr 2019 08:42:01 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Wang Haiguang <wang.haiguang.shieldlab@huawei.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20190425064201.lfuwspbkkwatbg6h@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Wang Haiguang <wang.haiguang.shieldlab@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/y9jq3aPn7Hpzq0DSqyiHOoHt-nw>
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 06:42:10 -0000
On Thu, Apr 25, 2019 at 03:22:46AM +0000, Wang Haiguang wrote: > 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. > I am not sure what "include a subset of the supported algorithms in their draft" means. Please explain. This issue touches on an open issue that we never managed to solve: Given an arbitrarily extensible set of identifiers, how does an implementation announce the subset actually supported? And related to that, can a YANG module define a subset that is expected to be supported (i.e., a conformance requirement)? I am not sure we have a YANG next issue for this, but we should. > 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. > This sounds a bit like hiding deprecated crypto somehow under the carpet. What if multiple technologies need the same deprecated crypto algorithm? They create multiple identifiers for the same thing or they get interesting module dependencies? Crypto algorithms come and go and ietf-crypto-types will sooner or later have identities that will need to be deprecated because the crypt algorithm is not considered secure enough anymore. So in the long term, hiding deprecated crypto algorithms in some corners "under the carpet" will not work. My point is that "we only have good crypto algorithms defined in ietf-crypto-types" is not going to work for long. > 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. The obvious way of dealing with this is to deprecate the identities when algorithms are considered to be not secure enough anymore. /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/>
- Re: [netconf] The maintenance of the algorithm id… tom petch
- [netconf] The maintenance of the algorithm identi… Wang Haiguang
- Re: [netconf] The maintenance of the algorithm id… Juergen Schoenwaelder
- Re: [netconf] The maintenance of the algorithm id… Kent Watsen
- Re: [netconf] The maintenance of the algorithm id… Martin Bjorklund
- Re: [netconf] The maintenance of the algorithm id… Kent Watsen
- Re: [netconf] The maintenance of the algorithm id… Martin Bjorklund
- Re: [netconf] The maintenance of the algorithm id… Kent Watsen
- Re: [netconf] The maintenance of the algorithm id… Juergen Schoenwaelder
- Re: [netconf] The maintenance of the algorithm id… Kent Watsen
- Re: [netconf] The maintenance of the algorithm id… Wang Haiguang