[netconf] 答复: I-D Action: draft-ietf-netconf-crypto-types-09.txt

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Thu, 27 June 2019 03:46 UTC

Return-Path: <frank.xialiang@huawei.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 BB35412006B for <netconf@ietfa.amsl.com>; Wed, 26 Jun 2019 20:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 LXY3rAbqerqm for <netconf@ietfa.amsl.com>; Wed, 26 Jun 2019 20:46:48 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00586120041 for <netconf@ietf.org>; Wed, 26 Jun 2019 20:46:48 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 38A167726DF1E2B36C3A for <netconf@ietf.org>; Thu, 27 Jun 2019 04:46:46 +0100 (IST)
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 04:46:45 +0100
Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.140]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 11:46:41 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: Kent Watsen <kent+ietf@watsen.net>, Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt
Thread-Index: AQHVK3Hpee/jJ7WI6Eal2Mc7/Yk+cKasUBKAgAHLEwCAALBK4A==
Date: Thu, 27 Jun 2019 03:46:41 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13E7B45A1@dggemm511-mbx.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F13E7B118B@dggemm511-mbx.china.huawei.com> <20190625.084508.905200182299290020.mbj@tail-f.com> <0100016b8f701d10-02dff612-5c5f-4ed3-938d-8b9f25679996-000000@email.amazonses.com> <20190625.224243.332607515244909664.mbj@tail-f.com> <0100016b9640a87c-b6e29e8c-0db0-4f15-bb58-887fc48c81d0-000000@email.amazonses.com>
In-Reply-To: <0100016b9640a87c-b6e29e8c-0db0-4f15-bb58-887fc48c81d0-000000@email.amazonses.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.159.76]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13E7B45A1dggemm511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/l9QWZ7dlIflzAU67LpnzXG5BhvQ>
Subject: [netconf] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt?= =?gb2312?b?bmV0Y29uZi1jcnlwdG8tdHlwZXMtMDkudHh0?=
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, 27 Jun 2019 03:46:51 -0000

Hi Martin, Kent and all,
Thanks for so productive discussion and clarification for our current problems and possible solution. And sorry for late response since I am out of office yesterday.

Let me give more information for better understanding the difficulties we are facing, and hopeful a direction worth for going to.

Please see inline:


发件人: Kent Watsen [mailto:kent+ietf@watsen.net]
发送时间: 2019年6月27日 8:06
收件人: Martin Bjorklund <mbj@tail-f.com>;
抄送: Xialiang (Frank, Network Standard & Patent Dept) <frank.xialiang@huawei.com>;; netconf@ietf.org
主题: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

Hi Martin,


4) to enable the SSH and TLS models to use types defined in their
protocol specs, mapping tables were added to those drafts to map the
protocol-specific types to the generic crypto-types type.

So perhaps this is not the best solution?  The big set of types (in
crypto-types) will change over time, and the subsets used in various
applications will also change over time.  The best solution for such
sets in the IETF seems to be IANA registries, with corresponding
IANA-maintained YANG modules.

I'm hoping someone, perhaps my co-authors, can suggest a path forward.

[Frank]: We mainly reference to these 3 IANA registries for define our crypto types in draft:

1.       https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml: which includes TLS 1.2 and TLS 1.3.

2.       https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml, https://tools.ietf.org/html/rfc8221-- crypto algorithms guidance for ESP and AH, https://tools.ietf.org/html/rfc8247-- crypto algorithms guidance for IKEv2: the 2 drafts are the latest recommendations for crypto algos of IPsec, so we mainly reference the definition in them;

3.       https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml, https://tools.ietf.org/html/rfc4253 -- main SSH Spec, https://tools.ietf.org/html/rfc8332 -- new RSA with SHA256 and SHA512 for its authentication function: also, the 2 drafts are the main resource we have referenced.

So, the above reference are all current input for the crypto type definition in the crypto types draft. Now, the 2 main difficulties for us are:

1.       For the above 3 protocols and their respective and different crypto algorithm definition in each IANA registries, should we align our yang model to all of them, or only one of them? If the former, we must deal with the problem that same crypto algo has different IANA number in different IANA registries?

2.       Considering TLS 1.2, which uses a combined way to represent different types of crypto into one IANA number (e.g., TLS_DHE_RSA_WITH_AES_128_GCM_SHA256). That is against our crypto type definition principle (IPsec and SSH are all aligned): atomic, which means we are currently define 7 categories of crypto type: Hash Algorithms, Asymmetric Key Algorithms, MAC Algorithms, Encryption Algorithms, Encryption and MAC Algorithms, Signature Algorithms and Key Exchange Algorithms. So, how should we map our crypto type definition back to TLS 1.2 IANA numbers?

After clarifying our problems, I want to ask if we can solve them by this way: we yang guys define a crypto type yang IANA registries, which can keep on being aligned with all the related protocols’ IANA registries, but have its own IANA number for each crypto algorithms. So, our draft just need to follow this IANA registries.


8) our efforts to normalize this may be futile, and yet we want to
support keystore.

Perhaps we can take a step back and define just the types we need
right now for keystore, in order to finish these drafts.  Then we (or
some other WG) can immediately start to work on an update to
crypto-types that would define more types for other purposes as well.

Maybe, depending on how that turns out, it may be trivial to extend the approach to cover everything.

[Frank]: based on my clarification above, even we have TLS and SSH now, we still have to deal with the aforementioned 2 difficulties. If so, why not do it right at start time?


B.R.
Frank

Kent // contributor