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

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-gajcowski-cnsa-ssh-profile@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-gajcowski-cnsa-ssh-profile-07

The IESG has completed a review of draft-gajcowski-cnsa-ssh-profile-07
consistent with RFC5742.

The IESG has no problem with the publication of 'Commercial National Security
Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)'
as an Informational RFC.

The IESG has concluded that this work is related to IETF work done in WG
CURDLE, but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-gajcowski-cnsa-ssh-profile/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-gajcowski-cnsa-ssh-profile/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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 than ", vs "more
likely to ").

  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.

[Ballot comment]
(Updated ballot)

==[ IESG
I have chosen this conflict review because this document is primarily profiling which collection of algorithms are permitted to be used by SSH.  It is a more restrictive set that those already allowed by the referenced RFCs.

==[ ISE/Authors

Thanks for incorporating the suggestions made in my previous ballot in -06.

[Ballot discuss]
I think we should have some discussion of whether this "related, but does
not prevent publishing" conflict-review response is the correct one.

In particular, I want to look at the use of implicit MAC algorithm when
using an AEAD encryption algorithm (AES-GCM).  While Section 5 does well and
clearly presents two options of using the RFC 5647 procedures or using the
aes256-gcm@openssh.com procedures, with the latter giving the "implicit MAC"
treatment, the portrayal in Section 4 is not quite so easy to unpack.  In
particular, it says that "Use of AES-GCM in SSH should be done as described
in RFC 5647, with the exception that AES-GCM need not be listed as the MAC
algorithm as its use is implicit (such as done in aes256-gcm@openssh.com)."
This seems to say that AES-GCM need not be listed as the MAC algorithm
generically, with its use always being implicit, in contrast to what I
believe to be the case, that it is only implicitly engaged when using
specifically the aes256-gcm@openssh.com encryption algorithm.  If this text
instead said "need not be listed as the MAC algorithm *when* its use is
implicit", that would not seem problematic to me.  (Recall that RFC 5647 has
MUST-level requirement that if AES-GCM is used as one of encryption or MAC
algorithm, it must be used for the other as well.)

[Ballot comment]
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 than ", vs "more
likely to ").

  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.

[Ballot comment]
(Updated ballot text to fix incorrect reference -- s/RFC1918/RFC2119/)

This note constitutes a ballot position on the IESG conflict review response
For draft-gajcowski-cnsa-ssh-profile-05.  RFC 5742 requires the IESG to
review documents submitted to the RFC Editor by the IRTF and ISE, and to
produce one of a fixed set of conflict-review responses.  The response I
have selected is visible in the datatracker page for this conflict review.
In this case, the response is number 2, "The IESG has concluded that this
work is related to IETF work done in WG , but this relationship does not
prevent publishing.".  However, that response is not final until approved by
the IESG as a whole, and other IESG members will likely produce ballot
comments on this conflict-review as well.  Since the primary purpose of this
IESG balloting activity is to agree on the conflict-review response, I will
include remarks in the "IESG" section below that are directed at the other
IESG members and attempt to clarify why I chose this option for the
response, as well as laying out any other potentially relevant factors that
might influence the IESG's decision (even if they do not directly support
the conclusion that I reached).  That said, the remarks in the "IESG"
section may be of interest to the authors, if they indicate changes that
could be made to the document that might result in a different
conflict-review response from the IESG.  Please note that in preparing the
IESG conflict-review response, I am tasked only with determining whether
IETF process is being followed, and am not tasked with assessing the quality
or content of the document in other ways.  However, because I had to read
the draft in question in order to decide what conflict-review response to
propose, I also include (under the "COMMENT" heading) some remarks about the
document itself; these comments are directed at the authors and ISE, but
have no formal standing. 

==[ IESG
I have chosen this conflict review because this document is primarily profiling which collection of algorithms are permitted to be used by SSH.  It is a more restrictive set that those already allowed by the referenced RFCs.

==[ COMMENTS
** This profile restricts algorithm choices in the following ways:

(a) Section 4.  “Any hash algorithm other than SHA-384 or SHA-512 MUST NOT be used.”

(b) Section 5.  “The result MUST be one of the following kex_algorithms or the connection MUST be terminated. … ecdh-sha2-nistp384 [RFC5656] diffie-hellman-group15-sha512 [RFC8268] diffie-hellman-group16-sha512 [RFC8268]”
However, Section 3.2.2. of draft-ietf-curdle-ssh-kex-sha2-20 (in the RFCed queue) says that “diffie-hellman-group14-sha256” is a “MUST” to implement.  The use of SHA256 would violate (a) and this is not one of the required kex_algorithms per the list in (b).

The text would benefit from stating that the MTI for SSH isn’t being changed (CNSA compliment SSH implementations still need to support “diffie-hellman-group14-sha256”), but that algorithm must not be used.

I would recommend adding text to Section 5 to the effect of:

OLD
The result MUST be one of the
  following kex_algorithms or the connection MUST be terminated.

NEW
While draft-ietf-curdle-ssh-kex-sha2-20 establishes general guidance on the capabilities of SSH implementations and requires support for “diffie-hellman-group14-sha256”, it MUST NOT be used.  The result MUST be one of the following kex_algorithms or the connection MUST be terminated.

** Abstract and Section 1.
  It applies to the capabilities, configuration, and
  operation of all components of US National Security Systems that
  employ IPsec. 

The IPsec reference seems like a typo – s/IPsec/SSH/.

** Section 3.
(a) “Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically-relevant quantum computer.”

(b) “NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near- term flexibility in meeting their information assurance interoperability requirements.”

(c) “The purpose behind this flexibility is to avoid vendors and customers making two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.”

The intent here isn’t clear. (a) makes a statement about PQC.  (b) speaks vaguely about near-term requirements.  (c) talks about avoiding to transitions.

Is (b) suggesting this profile is providing guidance irrespective of PQC?

Is (c) suggesting that this profile meets the need of both quantum resistance and needed evolution irrespective of PQC?

** RFC2119 key word usage:
-- Section 4.  “Therefore, the SHA-384 based kex and public key algorithms should be used; SHA-512 based algorithms may be used.”  Should RFC2119 key words be used here “SHOULD” for SHA-384 and “MAY” for SHA-512?

-- Section 4. “CNSA implementations must ensure the counter ...”.  Should s/must/MUST/?

[Ballot comment]
This note constitutes a ballot position on the IESG conflict review response
For draft-gajcowski-cnsa-ssh-profile-05.  RFC 5742 requires the IESG to
review documents submitted to the RFC Editor by the IRTF and ISE, and to
produce one of a fixed set of conflict-review responses.  The response I
have selected is visible in the datatracker page for this conflict review.
In this case, the response is number 2, "The IESG has concluded that this
work is related to IETF work done in WG , but this relationship does not
prevent publishing.".  However, that response is not final until approved by
the IESG as a whole, and other IESG members will likely produce ballot
comments on this conflict-review as well.  Since the primary purpose of this
IESG balloting activity is to agree on the conflict-review response, I will
include remarks in the "IESG" section below that are directed at the other
IESG members and attempt to clarify why I chose this option for the
response, as well as laying out any other potentially relevant factors that
might influence the IESG's decision (even if they do not directly support
the conclusion that I reached).  That said, the remarks in the "IESG"
section may be of interest to the authors, if they indicate changes that
could be made to the document that might result in a different
conflict-review response from the IESG.  Please note that in preparing the
IESG conflict-review response, I am tasked only with determining whether
IETF process is being followed, and am not tasked with assessing the quality
or content of the document in other ways.  However, because I had to read
the draft in question in order to decide what conflict-review response to
propose, I also include (under the "COMMENT" heading) some remarks about the
document itself; these comments are directed at the authors and ISE, but
have no formal standing. 

==[ IESG
I have chosen this conflict review because this document is primarily profiling which collection of algorithms are permitted to be used by SSH.  It is a more restrictive set that those already allowed by the referenced RFCs.

==[ COMMENTS
** This profile restricts algorithm choices in the following ways:

(a) Section 4.  “Any hash algorithm other than SHA-384 or SHA-512 MUST NOT be used.”

(b) Section 5.  “The result MUST be one of the following kex_algorithms or the connection MUST be terminated. … ecdh-sha2-nistp384 [RFC5656] diffie-hellman-group15-sha512 [RFC8268] diffie-hellman-group16-sha512 [RFC8268]”
However, Section 3.2.2. of draft-ietf-curdle-ssh-kex-sha2-20 (in the RFCed queue) says that “diffie-hellman-group14-sha256” is a “MUST” to implement.  The use of SHA256 would violate (a) and this is not one of the required kex_algorithms per the list in (b).

The text would benefit from stating that the MTI for SSH isn’t being changed (CNSA compliment SSH implementations still need to support “diffie-hellman-group14-sha256”), but that algorithm must not be used.

I would recommend adding text to Section 5 to the effect of:

OLD
The result MUST be one of the
  following kex_algorithms or the connection MUST be terminated.

NEW
While draft-ietf-curdle-ssh-kex-sha2-20 establishes general guidance on the capabilities of SSH implementations and requires support for “diffie-hellman-group14-sha256”, it MUST NOT be used.  The result MUST be one of the following kex_algorithms or the connection MUST be terminated.

** Abstract and Section 1.
  It applies to the capabilities, configuration, and
  operation of all components of US National Security Systems that
  employ IPsec. 

The IPsec reference seems like a typo – s/IPsec/SSH/.

** Section 3.
(a) “Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically-relevant quantum computer.”

(b) “NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near- term flexibility in meeting their information assurance interoperability requirements.”

(c) “The purpose behind this flexibility is to avoid vendors and customers making two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.”

The intent here isn’t clear. (a) makes a statement about PQC.  (b) speaks vaguely about near-term requirements.  (c) talks about avoiding to transitions.

Is (b) suggesting this profile is providing guidance irrespective of PQC?

Is (c) suggesting that this profile meets the need of both quantum resistance and needed evolution irrespective of PQC?

** RFC1918 key word usage:
-- Section 4.  “Therefore, the SHA-384 based kex and public key algorithms should be used; SHA-512 based algorithms may be used.”  Should RFC1918 key words be used here “SHOULD” for SHA-384 and “MAY” for SHA-512?

-- Section 4. “CNSA implementations must ensure the counter ...”.  Should s/must/MUST/?