Subject: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types

From: Wang Haiguang <[email-masked]>
Date: Thu, 25 Apr 2019 03:22:46 +0000

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.

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.

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.

If you have any suggestion, please post it on the mailing list.

Let's discuss and find a feasible solution to it.

Best Regards.

Haiguang

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Apr 2019 08:42:01 +0200

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

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

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

---

From: tom petch <[email-masked]>
Date: Thu, 25 Apr 2019 11:01:49 +0000

----- Original Message -----
From: "Wang Haiguang" <[email-masked]>
Sent: Thursday, April 25, 2019 4:22 AM

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

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.

a.       Some expert suggested to define those identifiers by them own
within their draft. I think this is a feasible solution.

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.

<tp>

To state the obvious (?), the larger something is the more unstable it
is so putting in the kitchen sink - KEX, HASH, MAC... - all into one
module is going to increase the churn on that module, as opposed to
having separate (sub-?)modules for e.g. KEX, MAC. HASH.

Again, to state the obvious, if this mega-module is published as an RFC,
then it must be updated by further RFC, once agreement has been reached
on what has become obsolete, too insecure etc.

Two technological solutions come to mind; divide the module up into
smaller pieces which would require more changes in total but fewer for
any one of the subdivided modules.

And make the module(s) IANA-controlled which allows a spectrum of ways
in which updates can be performed, from FCFS to Standards Track RFC and
which allows different approaches for e.g. KEX and HASH.

Tom Petch

Best Regards.

Haiguang

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

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 25 Apr 2019 16:15:11 +0000

> a YANG next issue for this, but we should.

Just submitted https://github.com/netmod-wg/yang-next/issues/80 <https://github.com/netmod-wg/yang-next/issues/80>.

Perhaps YANG Library be used for this?

> ietf-crypto-types" is not going to work for long.

Agreed.  It would seem that crypto-types should define the universe of all known algorithms, even it deprecated or obsoleted, and let the solution to Issue #80 enable implementations identify the subset they support.

> when algorithms are considered to be not secure enough anymore.

Yes, the identity takes "status" as a substatement, so this can be done.   

This discussion makes me wonder if the module should be called iana-crytpo-types and have IANA maintain the module.

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Apr 2019 18:51:16 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> Just submitted https://github.com/netmod-wg/yang-next/issues/80
> <https://github.com/netmod-wg/yang-next/issues/80>.
> 

This requirement is already captured in #40.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 25 Apr 2019 17:51:39 +0000

> On Apr 25, 2019, at 12:51 PM, Martin Bjorklund <[email-masked]> wrote:
> 
>> Perhaps YANG Library can be used for this?
> 

The issues are related, but seem like two sides of a coin:

   #40 regards deviating away what is not supported
   #80 regards expressing what is supported

Of course, what is supported could be form of implementing the module and then deviating away what's not used, but is it ideal?   

For instance, a server may implement different modules that use different sets of identities (e.g., because they use different libraries in the backend), such that what is not supported in one module (and hence the deviated away) is supported in the other (and hence shouldn't be deviated away).

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Apr 2019 20:50:39 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> Of course, what is supported could be form of implementing the module
> and then deviating away what's not used, but is it ideal?

Right, this is part of #40.  IMO #40 states the *problem* but not the
solution.  It is unfortunate that the title indicates a solution, but
that is the case for many of our other issues as well.

/martin

> 
> For instance, a server may implement different modules that use
> different sets of identities (e.g., because they use different
> libraries in the backend), such that what is not supported in one
> module (and hence the deviated away) is supported in the other (and
> hence shouldn't be deviated away).
> 
> 
> Kent // contributor
> 
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 25 Apr 2019 21:21:43 +0000

> that is the case for many of our other issues as well.

The titles can and should be updated to reflect the true problem.
Could you update #40 and close #80 with label "Duplicate"?

In the meanwhile, what's the stop-gap solution?   - crypto-types
shouldn't be blocked on YANG Next...

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Apr 2019 23:45:16 +0200

> shouldn't be blocked on YANG Next...

What we have been doing so far is publishing identities / enumerations
without having a common way for implementations to declare the subset
they do support. This seems reasonable since once we add a common
mechanism to report the subset actually implemented, we do not have to
go back and revise the definitions of identities and enumerations.

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 26 Apr 2019 14:25:46 +0000

> On Apr 25, 2019, at 5:45 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Sounds right, with the clarification that crypto-types should have identities for all (within reason) known algorithms, even if deprecated or obsolete, and that for those algorithms that are deprecated or obsolete, the identity's "status" statement should be set to "deprecated" or "obsolete" accordingly.

Haiguang, can you please point the i2nsf group to this thread?

Thanks,
Kent

---

From: Wang Haiguang <[email-masked]>
Date: Sun, 28 Apr 2019 08:31:16 +0000

Hi, Kent and all

Sorry for the late reply due to time differences.

I will post the link to i2nsf tonight and let them aware the discussion in netconf.

Best regards.

Haiguang

________________________________
From: Kent Watsen [[email-masked]]
Sent: Friday, 26 April, 2019 10:25:46 PM
To: Juergen Schoenwaelder
Cc: Martin Bjorklund; Wang Haiguang; [email-masked]
Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types

On Apr 25, 2019, at 5:45 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Kent