Re: [netconf] crypto-types fallback strategy

[Kent Watsen <[e-mail]>]

> 
> I think there are
> 
> a) cryptographic algorithms (the primitives)
> b) operating modes for symmetric algorithms etc.
> c) combinations of a) and b) used by certain security protocols or
>   sub-protocols (keyex vs data transfer)
> d) key formats that are used together to combinations from b)
> 
> and we seem to sometimes confuse these things. If this is a proposal
> for a), then fine. But these registries do not help much with b)-d),
> 
> I believe b) and d) tend to be security protocol specific (and may
> even be security protocol version specific).
> 
> Looking at things from a management perspective, I assume the
> relevance for configuration is d) to a).
> 
> Hence, I believe it makes sense to create a module with definitions
> specifically needed for SSH and a module with definitions specifically
> needed for TLS. (The SNMP model in RFCC 7407 has a several choices to
> deal with different security "algorithms". This does not really matter
> except that we also back then went for a security protocol specific
> solution.)


An attempt to do this already exists.  Please look at:

  - https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-14#section-5.3 <https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-14#section-5.3>
  - https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-14#section-5.3 <https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-14#section-5.3>

As well as the tables in Section 5 in both drafts.

Admittedly, my co-authors decided to put this effort on hold while crypto-types issue is resolved, as the WG's focus is on the first three drafts of the client/server suite of drafts.   But the point is that the plan is to address the protocol-specific issue within these drafts.

Kent