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

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Thu, 04 July 2019 09:55 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 91F161201D7 for <netconf@ietfa.amsl.com>; Thu, 4 Jul 2019 02:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AwKp9z0d-IrU for <netconf@ietfa.amsl.com>; Thu, 4 Jul 2019 02:55:56 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 B9769120176 for <netconf@ietf.org>; Thu, 4 Jul 2019 02:55:55 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 10378B8282768A977810 for <netconf@ietf.org>; Thu, 4 Jul 2019 10:55:54 +0100 (IST)
Received: from DGGEMM421-HUB.china.huawei.com ( by lhreml705-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 4 Jul 2019 10:55:53 +0100
Received: from DGGEMM511-MBX.china.huawei.com ([]) by dggemm421-hub.china.huawei.com ([]) with mapi id 14.03.0439.000; Thu, 4 Jul 2019 17:55:43 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: tom petch <ietfc@btconnect.com>, Wang Haiguang <wang.haiguang.shieldlab@huawei.com>, 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: AQHVMY5p0BmiaN/OWU21n+8cGP1fTqa6MiSQ
Date: Thu, 04 Jul 2019 09:55:44 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13E7BFE93@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> <C02846B1344F344EB4FAA6FA7AF481F13E7B45A1@dggemm511-mbx.china.huawei.com> <20303ff0c07346c7ae7cf1200502ecfe@huawei.com> <077201d5318e$5ed91620$4001a8c0@gateway.2wire.net>
In-Reply-To: <077201d5318e$5ed91620$4001a8c0@gateway.2wire.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/mDqeencjU8Spj6oh9SIckdwYet8>
Subject: [netconf] 答复: : I-D Action: draft-ietf-netconf-crypto-types-09.txt
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, 04 Jul 2019 09:56:00 -0000

Hi Tom,
Agree with your general observation.

Please see inline:

发件人: tom petch [mailto:ietfc@btconnect.com] 
发送时间: 2019年7月3日 18:59
收件人: Wang Haiguang <wang.haiguang.shieldlab@huawei.com>; Xialiang (Frank, Network Standard & Patent Dept) <frank.xialiang@huawei.com>; Kent Watsen <kent+ietf@watsen.net>; Martin Bjorklund <mbj@tail-f.com>
抄送: netconf@ietf.org
主题: Re: [netconf] : I-D Action: draft-ietf-netconf-crypto-types-09.txt

----- Original Message -----
From: "Wang Haiguang" <wang.haiguang.shieldlab@huawei.com>
Sent: Wednesday, July 03, 2019 11:17 AM

> Hi, all.
> I have some comments regarding the management of crypto algorithms
used by different protocols such as TLS, IPSec and SSL.
> At the moment, different work group maintains own definitions
regarding the crypto algorithms, including public key algorithms, key exchange algorithms, hash, mac, encryptions etc.
> Each working group defined their own identifiers for crypto
algorithms. In some group, crypto algorithms for authentication, encryption and key exchange etc. are defined separately while others may combined identifiers.
> The current method requires additional efforts in each group for
protocol development, and also in implementation and network management.
> A better way could be that the IETF security group define a unified
crypto algorithm identifiers and register them with IANA. These crypto algorithm identifiers can be shared among  different working groups in their future work.
> The current draft-ietf-crypto-types provides valuable work the
classification of crypto algorithms.
> I think we should discuss this point and make a decision whether we
should get IANA registration numbers for different crypto algorithms in the coming face-to-face meeting.

Yes:-) trouble is, WGs are independent and even if they are in the same area with the same AD, it can be a challenge to get a common approach.
(I have been trying, mostly failing, to get a coordinated approach in Routing where an interface can have different attributes0.

Here, there is also a technical challenge that the potential list of algorithms is long, different protocols have different views of what is current, what is obsolete and so on so we could and should create a list of everything we can think of and get a Security directorate view of which are acceptable, in terms of strength, for what; and, perhaps, add a tick list of which protocols use them, so that it is easy to extract all those with e.g. IPsec in the ticklist, for use by IPsec, which would be different list for those with NETCONF in the tick list.

[Frank]: Agree that ticklist is an each way for this goal, a minor problem is the basic list will be the maximum list for all the protocol and will be very large. The other similar idea in my mind is: firstly, we should have one basic crypto algorithm IANA list, which is a basis for each specific protocol's algorithm list. Secondly, each protocol (i.e., tls, ipsec, ssh ...) inherits the basic algorithm list with required modification (i.e., add new algo, obsolete old algo, ...). Lastly, any update of the basic list must reflect into each protocol's list, but each protocol's list can have its own update with no influence back to basic list. By this way, the basic list can be a minimum list, and each protocol's list only needs to focus on the left part in addition to basic list.

Then all we can do is make it easy to use, widely known about and encourage others to use - or tell us why not.

But the first step, which, after much discussion, we have yet to take, is to create a list. I prefer multiple lists, for encrypt, MAC and so on, easier to maintain.

[Frank]: agree too with this way forwarding. We have nearly finished the crypto algorithms list definition in draft-ietf-netconf-crypto-types-10. So, my question is can we publish it as the RFC before the IANA list is created?


Tom Petch

> Best regards.
> Haiguang
> From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Xialiang
(Frank, Network Standard & Patent Dept)
> Sent: Thursday, June 27, 2019 11:47 AM
> To: Kent Watsen <kent+ietf@watsen.net>; Martin Bjorklund
> Cc: netconf@ietf.org
> Subject: [netconf] 答复: I-D Action:
> 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<mailto:mbj@tail-f.com>>
> 抄送: Xialiang (Frank, Network Standard & Patent Dept)
> 主题: 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.
which includes TLS 1.2 and TLS 1.3.
> 2.
, 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://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


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