[netconf] Paul Wouters' Discuss on draft-ietf-netconf-ssh-client-server-38: (with DISCUSS and COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-netconf-ssh-client-server-38: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the document. I have a few DISCUSS items that hopefully are pretty
minor to resolve.

1) client options?

The ssh client allows to set the source IP. Should that not be exposed here to
support picking the right source IP on multihomed nodes? Similarly, this does
not seem to support ports != 22 ? And seeing people are starting to experiment
with ssh over QUIC or HTTP/3, perhaps a protocol should be added as well? Is
compression an option that should be exposed here?

2) server options

I think the idle timeout might be a useful server option to expose here? It
seems the best place for it instead of placing it in another ssh server module
to include ?

3) algorithms, names and IANA entries

        2.2. Example Usage

This uses older ctr/cbc algorrithms, why not use more modern examples?
I'd recommend removing the cbc examples and including the well known AEAD
ones instead? (see also the catch below)

Note openssh uses names like  [e-mail],
[e-mail],[e-mail] while the IANA registry uses
names like AEAD_AES_128_GCM and AEAD_AES_256_GCM. How does this relates to
names in the document, which uses "aead-aes-256-gcm" which is not an IANA
value, but presumably points to AEAD_AES_256_GCM and [e-mail] ? I
think some guidance or explanation about the valid value names here compared to
IANA and OpenSSH would be useful. I believe the "@" ones are non-IETF namespaces

I would also include at least one "@" encryption name to ensure people know
those are valid syntax as well. I do not know if AEAD_AES_256_GCM is the
same as [e-mail]

What should the <mac> field list for AEAD algorithms? Just be empty? Or
a special "none" value? Or should the field be entirely omitted? Is there
guidance needed here? (Sorry I am not a yang doctor)

The value diffie-hellman-group-exchange-sha256 is a valid IANA registry
name but points to a MAY entry. I would pick a MUST or SHOULD entry for
examples, in this case diffie-hellman-group14-sha256. Similar, the
example gss-group1-sha1-curve25519-sha256 is actually a SHOULD NOT
implement entry. Similar the mac aead-aes-256-gcm really has an IANA
entry of AEAD_AES_256_GCM.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

C1) hashed-password ?

The example "$0$secret" uses the most unsafe option as example. "secret"
is not a hash. It is cleartext baesd on RFC 7317 "crypt-hash". Maybe give
an example with an actual hashed password as well? Maybe change "secret"
to "cleartext-password" ?

Since RFC 7317 only defines crypt-hash 0,1,5 and 6 there is some
ambiguity here for hashed passwords based on other algorithms. My
crypt(5) man page also supports script, yescript, bcrypt, NT. But not
argon. But I guess this is an issue for RFC 7317, and not this document.