Re: [netconf] crypto-types fallback strategy

[Martin Bjorklund <[e-mail]>]

Schönwälder, Jürgen <[e-mail]> wrote:
> 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)

Yes.

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


While I agree that this would probably work, I'm not convinced it is
required for now, to get this document done.  I think it can be ok to
declare this as out of scope for now.

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

Yes.

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

I agree.


/martin


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