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

[Paul Wouters <[e-mail]>]

On Sun, Mar 3, 2024 at 11:31 AM Kent Watsen <[e-mail]> wrote:

[cut all the agreements and non-issues]

I’m confused, where are these ‘@‘ variations defined?   They are not
defined in the Encryption Algorithm Name registry here:
https://www.iana.org/assignments/ssh-parameters/ssh-parameters-17.csv

So I believe the SSH protocol uses "namespaces" for some algorithms. If
there is no "@" symbol it means the IETF / IANA
namespace. But OpenSSH has its own namespace with its own entries. That's
why I thought it might be useful to add these
to ensure people are aware that this is valid syntax as well.


Oh, this?  https://www.rfc-editor.org/rfc/rfc4250.html#section-4.6.1

Now I understand...

I understand now what you mean about the local names having the ‘@‘
character.

I fixed the YANG by creating new typedefs enabling the various algorithm
values to either be from the IANA-defined registry or be a local name
(containing the ‘@‘ character.

I updated both examples in Section 2.2 to include the local names "
[e-mail]" and "[e-mail]”.

This did not make it into draft-ietf-netconf-ssh-client-server-39 ?

Eg AES-CBC-SHA2, the "SHA2" part is the integrity aka mac.

For AEAD algorithms such as AES-GCM and CHACHA-POLY, the integrity/mac part
is integral to the encryption algorithm, so it has no separate "mac".
So my question was, when using an AEAD, what is expected for the <mac>
field? Should it be empty? Should it be absent? Should it contain a value
"none"?
So I was wondering if guidance should be given here about what is
valid/allowed and what is not.


Okay but, unless I’m mistaken, the guidance is clear (though possibly
wrong).  The YANG says that the value must be one of the values from the
underlying IANA registry (or a local name containing ‘@‘).  For reference,
the “supported-algorithms” node lists all of the algs the SSH-server
supports.

To this end, you are right that IANA's AEAD alg names do not encode a MAC
algorithm (e.g., SHA2).  Using your language, the "<mac> field" could be
said to be “empty" or “absent”.   I don’t see how this is handled in
practice.  I checked RFC 5647 to no avail.

I think that the allowed values are well-defined.  How the AEAD algs set a
MAC to use seems to be outside the scope of this document.  Agreed?

The MAC is internal to the AEAD. What this means though is that an
encryption method that is an AEAD MUST NOT also specify a mac. And if you
specify an AEAD and non-AEAD encryption algorithm, only the non-AEAD needs
the mac entry. I am not entirely if the current syntax is good enough
for these.


It is but the text "secret" is not a TYPE but a VALUE. Eg you are using a
secret of "secret". I wasn't sure if that was very clear. That also does
not make it
entirely clear of the secret is cleartext or some other format (without
reading 7317). If you used "ExampleSecret", that would be more clear.


Changed examples to use the value "example-secret” instead.

That also did not make it into -39 ?

I'll wait with updating my ballot until we understood each other regarding
the "@" namespace and <mac> topics.

Have I provided sufficient response above?

Yes, but I don't see all the promised changes in the latest version?

Paul