Re: [netconf] crypto-types fallback strategy

[Kent Watsen <[e-mail]>]

> On Sep 27, 2019, at 1:46 PM, Schönwälder, Jürgen <[e-mail]> wrote:
> 
> On Fri, Sep 27, 2019 at 03:53:51PM +0000, Rob Wilton (rwilton) wrote:
>> I basically agree with what Martin is saying.
> 
> So do I.

Hmmm...


>> Either one YANG module containing all of the crypto identities, or a few YANG modules as previously suggested.
> 
> 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).

One issue not addressed is defining the identities for the algorithms used to encrypt other keys in the keystore.   At least, neither SSH or TLS are involved.  However, both the keystore and TLS use "ASN.1" and so, somehow, the keystore may be encrypting with "TLS" (really ASN.1) keys already... (requires more analysis)


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


Rich, does any of this line of thinking address your concern?  - or maybe you liked more my previous idea of using IANA registries?

Kent // contributor