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.

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.

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
<mbj@tail-f.com>
> Cc: netconf@ietf.org
> Subject: [netconf] 答复: I-D Action:
draft-ietf-netconf-crypto-types-09.txt
>
> 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)
<frank.xialiang@huawei.com<mailto:frank.xialiang@huawei.com>>;
netconf@ietf.org<mailto: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
>

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

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