IETF conflict review for draft-gajcowski-cnsa-ssh-profile
conflict-review-gajcowski-cnsa-ssh-profile-00

The updates in the -07 of the draft have eliminated the concerns I had
about whether this is the correct conflict-review response.

My previous comments (on the draft) are retained below, which were, IIRC,
made against the -05 of the draft and are likely stale.

The following comments are on the draft itself, not the conflict-review
response.

Section 4

   Several RFCs have documented how each of the CNSA components are to
   be integrated into Secure Shell (SSH):

This threw me for a bit, as I was expecting a "CNSA component" to be a
tangible module or something; would it be easier to just refer to "how each
of the CNSA algorithms are used in Secure Shell (SSH)"?

   While the approved CNSA hash function for all purposes is SHA-384, as
   defined in [FIPS180], commercial products are more likely to
   incorporate the SHA-512 (sha2-512) based kex algorithms and public
   key algorithms defined in [RFC8268] and [RFC8332].  Therefore, the
   SHA-384 based kex and public key algorithms should be used; SHA-512
   based algorithms may be used.  Any hash algorithm other than SHA-384
   or SHA-512 MUST NOT be used.

I would consider mentioning where the SHA-384-based methods are defined, to
provide a more clear comparison ("more likely to <A> than <B>", vs "more
likely to <A>").

   Use of AES GCM shall meet the requirements set forth in SP 800-38D
   with the additional requirements that all 16 octets of the
   authentication tag MUST be used as the SSH data integrity value and

I see that this is an additional requirement compared to SP 800-38D, but it
is not a new requirement compared to RFC 5647, which clearly states that
"[a]ll implementations of AES-GCM secure shell MUST use the full 16-octet
Authentication Tag".  So perhaps the "MUST" could be lowercase and a
reference to RFC 5647 being what imposes this requirement could be added.

Section 5

   This section specifies the use of CNSA components in the Secure Shell
   algorithm negotiation, key agreement, server authentication, and user
   authentication.

[same comment about "component"]

Section 10

   The security considerations of [RFC4251], [RFC4252], [RFC4253],
   [RFC5647], and [RFC5656] apply.

Why list 5647 and 5656 but not 8268 or 8332?

NITS

Section 5

   One of the following sets MUST be used for the encryption_algorithms
   and mac_algorithms name-lists.  Either set MAY be used for each
   direction (i.e. client_to_server, server_to_client) but the result
   must be the same (i.e. use of AEAD_AES_256_GCM).  This option MUST be
   used.

I suggest rephrasing around "this option MUST be used"; the current
statement is pretty unclear about what exactly is required.  Both
encryption_algorithm and mac_algorithm name-lists appear to be required
parts of the SSH_MSG_KEXINIT packet, so I don't think the statement would
make sense as a requirement to send something in either/both fields.

Section 7.2

   authenticate using passwords.  Other methods of authentication MUST
   not be used, including "none".

This would probably read better with the BCP 14 "MUST NOT" keyword.

   When authenticating with public key, the following public key
   algorithms MUST be used:

Probably "one of the following" is better; IIUC it's hard to use both
simultaneously.