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/>