Re: [netconf] ssh/tls key generation support

[tom petch <[e-mail]>]

From: netconf <[e-mail]> on behalf of Dhruv Dhody <[e-mail]>
Sent: 22 March 2022 07:30

Hi WG,

I agree!

And as an author of the PCEP YANG model which is dependent on draft-ietf-netconf-tls-client-server<https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/>; we would really like to see it published SOON!

Dhruv

You could oppose the adoption of the NETCONF I-D that are currently up for adoption on the grounds that the WG has a backlog that is too big and has been there for too many years and should not be taking on more work until some of that backlog has passed IESG Review!

I have known ADs do just that in the past.

You also might find some allies in the Babel WG.

Tom Petch

Thanks!
Dhruv

On Tue, Mar 22, 2022 at 12:26 PM Jürgen Schönwälder <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

Kent asked for feedback concerning key generation support. My view is
the following:

- As long as you can trust your device to generate good keys, it is
  good idea to generate keys on the device so that keys are never sent
  around and they may be kept in protected storage.

- As stated by others during the WG meeting, the proposal in
  draft-ietf-netconf-ssh-client-server-27.txt should be more explicit
  that it is about generating key pairs and in particular hostkey
  pairs.

- Generating server key pairs is just a step of a more complex
  process. In SSH, clients traditionally built trust into hostkeys
  using an ad-hoc process, in TLS this is traditionally done using
  certificates. Hence, at least for TLS, we get into the territory of
  generating certificates, either creating self-signed certs, hooking
  into an automated certification system like lets encrypt, or
  handling a full blown cert process (generating csrs etc).

- If we got the YANG modules right, then it should be possible to add
  support for server key generation without changes to the existing
  definitions (i.e., we can do this later if we decide to do so, there
  is not reason why this needs to be done now).

- The SSH and TLS documents started as WG documents in July 2016, we
  are getting close to 6 years in the WG and it is somewhat unclear
  what the uptake of these documents will be. If we get into
  certificate territory, I fear we add at least another year of delay.

My take is that we should leave key generation for future work and
instead try to deliver what we have. Note that the documents highly
interrelated and they have overall grown to a significant size (even
if we leave out the IANA algorithm registry modules, this is
substantial).

  | Pages | Lines | Draft                                            |
  |-------+-------+--------------------------------------------------|
  |    63 |  3528 | draft-ietf-netconf-crypto-types-22.txt           |
  |    51 |  2856 | draft-ietf-netconf-keystore-24.txt               |
  |    31 |  1736 | draft-ietf-netconf-http-client-server-09.txt     |
  |    60 |  3360 | draft-ietf-netconf-netconf-client-server-25.txt  |
  |    56 |  3136 | draft-ietf-netconf-restconf-client-server-25.txt |
  |   137 |  7672 | draft-ietf-netconf-ssh-client-server-27.txt      |
  |    34 |  1904 | draft-ietf-netconf-tcp-client-server-12.txt      |
  |   146 |  8176 | draft-ietf-netconf-tls-client-server-27.txt      |
  |    39 |  2184 | draft-ietf-netconf-trust-anchors-17.txt          |

/js

--
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>

_______________________________________________
netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf