Re: [netconf] crypto-types fallback strategy

[Schönwälder, Jürgen <[e-mail]>]

On Tue, Oct 01, 2019 at 12:38:08AM +0000, Kent Watsen wrote:
> > 
> > It may make sense to split by security protocol.
> 
> That would go some towards addressing Rich's concern.  Presumably we would have one module each for SSH  and TLS algorithms.  That said, to Rich's concern, there is a constant churn with them.  This churn concerns two activities:  the removal and addition of algorithms.  Both occur at protocol-version boundaries and, perhaps, other times as well.  This suggests to me that we could further refine the identities by protocol version, something like this:
> 
> In ietf-crypto-types:
> 
>     identity base-alg {}
>     identity tls-alg { base "base-alg" }
>     identity ssh-alg { base "base-alg" }
> 
> In ietf-tls-1.1-types:
> 
>     identity tls-1.1-alg { base "ct:tls-alg" }
>     <a bunch of tls-1.1 identities here>
> 
> In ietf-tls-1.2-types:
> 
>     identity tls-1.2-alg { base "ct:tls-alg" }
>     <a bunch of tls-1.2 identities here>
> 
> etc.
> 
> Updates only to the specific module would be needed.   The updates would only need to support new algorithms (not to remove support for legacy algorithms), as a different mechanism can be used for a server to advertise which algorithms it actually supports (on a more granular level).

I do not know whether this helps solving a problem or creates other
problems as side effects. I think we have

a) a set of named algorithms that is changing over time
b) a set of algorithms that are "blessed" for use a certain protocol
   version (and the set may change over time)
c) a set of algorithms supported by a protocol implementation (may change
   with over time as well, i.e., with firmware updates)
d) a set of algorithms configured to be used by a protocol implementation
   (this is really what we want to get at)

Perhaps it is best to use identities for a) and to expose the other
sets via data leafs. I am not even sure exposing b) is required since
b) is input to the protocol implementer and a client can (only)
configure what is implemented anyway. I think c) could be exposed as
config false data and d) is then config true data.

> >> If advertising the specific identities is important, then a per identity if-feature could be used, although I'm not entirely sure that one feature per identity is really a great option either, but I think that this would be better than one per module.
> > 
> > Why not instead have a config false list of algorithms supported? Once
> > we have solved this problem generically, this list may get deprecated.
> 
> I like this idea, but it means that ietf-crypto-types, where this config false list would be defined, presumably, would then have protocol accessible nodes and, to the point, may be odd for a "types" module to define.   Thoughts?  - a "config false" list okay?
>

Such a config false list should go where the protocol specifics are
defined. And it likely has to be protocol version specific for
implementations that do support multiple versions of a security
protocol.

I am generally not a fan of overloading names (or concepts in
general). A YANG identity simply gives a name to something and a
module simply puts a collection of named definitions into a common
namespace. We should stay away from associating additional semantics
with how an identity is named or how a module is named. If additional
information is needed, model that additional information as data.
 
/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>