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

[Kent Watsen <[e-mail]>]

Hi Paul,

Something seems wrong with the quote-levels in your response.
I added "[Paul writes]” to where I see your messages below.


> On Mar 4, 2024, at 8:10 PM, Paul Wouters <[e-mail]> wrote:
> 
> 
> On Sun, Mar 3, 2024 at 11:31 AM Kent Watsen <[e-mail] <mailto:[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] <mailto:[e-mail]>" and "[e-mail] <mailto:[e-mail]>”.
> 

[Paul writes]
> This did not make it into draft-ietf-netconf-ssh-client-server-39 ?

It will be in -40.   I was going to publish it today, but was waiting to hear back from other ADs first...


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

[Paul writes]
> 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 [sure] if the current syntax is good enough for these.

I’m sorry this is taking too long, but can you please provide a concrete example?

Is your comment related to https://datatracker.ietf.org/doc/html/rfc5647#section-5.1:

     If AES-GCM is selected as the encryption algorithm for a given
     tunnel, AES-GCM MUST also be selected as the Message Authentication
     Code (MAC) algorithm.  Conversely, if AES-GCM is selected as the MAC
     algorithm, it MUST also be selected as the encryption algorithm.

???



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


[Paul writes]
> Yes, but I don't see all the promised changes in the latest version?

They will be in -40.   I was going to publish it today, but was waiting to hear back from other ADs first.   Sort of good thing too, since now we still have open the AEAD thread...


> Paul

Kent