Re: [Curdle] Can you do a review of draft-gajcowski-cnsa-ssh-profile

["[e-mail]" <[e-mail]>]

Thanks, Mark! We will look at these and respond shortly.

Mike Jenkins
________________________________
From: mbaushke ietf <[e-mail]>
Sent: Sunday, August 15, 2021 12:06 PM
To: [e-mail] <[e-mail]>; Nicholas Gajcowski (GOV) <[e-mail]>; Michael Jenkins (GOV) <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Benjamin Kaduk <[e-mail]>
Subject: Re: Can you do a review of draft-gajcowski-cnsa-ssh-profile

Hi Adrian, Nicholas, & Michael,

I regret it has taken me longer to organize my thoughts on the draft-gajcowski-cnsa-ssh-profile than I thought it would take.

The comments I sent to Adrian were rushed, but I tried to take more time with the notes that follow. At the end of this message is my original quick replay.

This is a review of

  https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-gajcowski-cnsa-ssh-profile%2F02%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927305090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=jrxga%2Fh31jOyfz8OUwr0H4EN45kWLSC5yH7dXIXPjFg%3D&amp;reserved=0

In the Abstract and Section 1, "IPsec" is preferred over "IPSec"
anywhere it appears:

  See RFC 4301 Section 1.1,

  |   The spelling "IPsec" is preferred and used throughout this and all
  |   related IPsec standards.  All other capitalizations of IPsec (e.g.,
  |   IPSEC, IPSec, ipsec) are deprecated.  However, any capitalization of
  |   the sequence of letters "IPsec" should be understood to refer to the
  |   IPsec protocols.

Please use IPsec throughout your draft to be consistent with other IETF RFCs.

[SP80059] should probably use the URL:
"https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.6028%2FNIST.SP.800-59&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3CFnncHbi28CPwEzWJHsR1rYCeICV3oQUp3jta4HtYU%3D&amp;reserved=0"
given all of the movement of documents at the NIST site in recent
years.

Section 3
  "meeting their IA interoperability requirements"

This is the first use of the Inter-Agency (IA) acronym. Please spell
it out on first use... assuming that I have the acronym correct in
the first place.

Section 4

If you expect to use rsa-sha2-512 as a public key algorithm, then it
is necessary to add two methods to the key exchange algorithms. These
two methods are: "ext-info-c" and "ext-info-s", defined in [RFC8308].
They provide a mechanism to support other Secure Shell negotiations
including "server-sig-algs" which allows the public-key-algorithms to
restrict the ssh-rsa to not be negotiated and instead allow only
rsa-sha2-512. See also the requirement given in section 6.1 of your
draft for why it is important to reduce the list of the
"server-sig-algs" to just the two of interest in this RFC. Some
implementations always add ext-info-c to the server configuration and
ext-info-s to the client configuration, so they are implicit. The
"server-sig-algs" may be defined by another configuration option name
such as the PubkeyAcceptedKeyTypes directive used by OpenSSH.

Also, please note that RFC5647 is not the only way to negotiate the
use of AES 256-bit GCM mode. It turns out that the RFC5647 was not
well written and was not generally adopted by most open source
editions of SSH. Instead, [e-mail] uses the same wire
protocol, but negotiates to IGNORE the value of the MAC algorithm list
and implicitly select the matching MAC algorithm when the AEAD GCM
algorithm is selected.

There is presently no explicit RFC with [e-mail] or
[e-mail] names, but there are multiple implementations
in the field that use the @openssh.com name-space for this option
negotiation.

The issue here is if this RFC should be taken as being 'prescriptive'
or 'descriptive' to get the profile that is desired with the available
implementations. In my opinion, a 'prescriptive' profile is not
desirable as it will not allow the use of experimental PQC algorithms
to be used in the profile even if that is highly desirable for testing
and deployment purposes. So, it MAY be desirable to avoid being too
restrictive in disallowing something like a a publickey algorithm
option such as one of

  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]

as was mentioned in
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.gov%2FCSRC%2Fmedia%2FPresentations%2Fprototyping-post-quantum-and-hybrid-key-exchange%2Fimages-media%2Fstebila-session-1-paper-pqc2019.pdf&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=KfItbLgYgOK7yN0HliYTMCiUt4AzRPhe4EOdhUw7gTw%3D&amp;reserved=0

If this informational RFC is made prescriptive, then it is possible
that certification efforts for vendors trying to provide for
experimental algorithms would fail to be certified. This is
undesirable behavior in my opinion. In general, the use of MUST NOT in
your RFC seems overly harsh. I would think that SHOULD NOT is strong
enough. Use of profiles that are not approved by NIST may cause harm
to interoperability of SSH implementations within the public sector
government.

Section 4.1

As yet, SHA-3 and its related XOF functions are not present in SSH.
However, this section prohibits experimentation with them while using
this profile. I do not necessarily think this is a wise choice. It
seems to me that it would be better to specify a minimum security
strength needed and provide a list of algorithms which meet that
criteria.

Section 4.2

Query: Why only 3072 and 4096 bits for an RSA key? You are suggesting
that an RSA public key modules of 3078 bits is not acceptable. Why
does this restriction exist? Yes, there are a large number of primes
that will work, but why limit them to two explicit sizes instead of a
range? I think this may need some justification. As long as sizes are
documented and strong enough, I do not understand the blind reasoning
of two fixed sizes of moduli length.

I believe the NSA may be overly restrictive in suggesting that only
X.509v3 certificates are acceptable. There are alternatives in the
field which are well deployed which avoid the ASN.1 encoding debacle
that has caused so many implementation problems since X.509 was first
deployed in the OSI protocol stack in 1988 and later pushed into the
TCP/IP universe with X.509v3 arriving in 1996.

An alternative is documented as OpenSSH Certificates which was
documented in 2010-03-08 with release OpenSSH 5.4. See
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fssh-comparison.quendi.de%2Fcomparison%2Fhostkey.html&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=tLybJbVhnZvL%2BZyR9XLfDYy%2BDJtx3bXfWYfjdNy0qn8%3D&amp;reserved=0
for a table on the support of the *[e-mail]
and the URL:
  https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcvsweb.openbsd.org%2Fsrc%2Fusr.bin%2Fssh%2FPROTOCOL.certkeys%3Fannotate%3DHEAD&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZREnU3PGT5Snt3eb9SS1HZDbmRzoCidsmYQFDwEmHU0%3D&amp;reserved=0
for some documentation.

I therefore suggest the sentence

    "Certificates MUST be X.509v3 certificates and their use MUST
    comply with [RFC8603]."

be removed. However, you could say that should X.509v3 certificates be
used, they MUST comply with RFC8603.

In the past twenty years, there have been MANY problems with
non-inter-operable X509v3 certificates on the Internet. Including
misuse of critical sections and improper OIDs being used as well as
the use of UNICODE to generate dangerous false identities that seem to
look good to a human, but are forgeries.

Of course, this is a larger issue, but forced compliance to X509v3 and
use of CRLs and OCSP as well as Cross Certificates (aka chain or
bridge certificates) and multi-host certificates can make it
non-trivial for some devices to properly make use of X509v3
certificates.

Section 6.1 and 6.2

Is it really desirable to mix ECC and FFC DH exchanges and public
signature algorithms? I do not see any real harm in it, but it seems
to be counter intuitive to the push I have seen elsewhere for use of
ECDH with ECDSA and FFC DH with RSA in the past. I mostly curious
here, there is no problem with these sections allowing that
flexibility. I am just somewhat bewildered by prescriptive use of
algorithms in other places in the document where this one actually
allows flexibility for the deployment.

Section 7.

I am again puzzled by a prescriptive fixed 3072 bit and 4096 bit RSA
modulus sizes with nothing in between them. If this is a testing
consideration, you might want to mention that those are the only two
sizes that the ACVP system permits for formal certification under FIPS
140-3 and/or NIAP Protection Profiles. Assuming this is the reason for
the restriction.

Section 9

There seems to be some confusion in Rekeying. There are two separate
encryption streams client-to-server and server-to-client. They are
typically rekeyed separately based on time and/or traffic volume. I do
not recall seeing any implementation where the same key is being used
in both directions. It would seem wise to be explicit that this
section is overwriting is updating guidance of RFC4253 section 9
to disallow the reselection of Ciphers against the "It is permissible to
change some or all of the algorithms during the re-exchange."
original text. A possible rewrite might be:

    [RFC4253] section 9 alllows either the server or the client to
    send initiate a "key re-exchange by sending an SSH_MSG_KEXINIT
    packet". However, that section also specifies "It is permissible
    to change some or all of the algorithms during the re-exchange."
    this sentence being updated. The cipher suite being employed MUST
    NOT be changed when a rekey occurs.

Section 10

In my opnion, it is highly desirable to note that in a PQC world, the
smaller key sizes used by ECC algorithms will require less Qubits
(quantum bit) to be deployed to break the connection than if FFC
algorithms are employed. I have not read any recent papers comparing
IFC (RSA algorithm) factorization Qubit requirements. If this is going
to be a useful RFC, a pointer to such literature may help make the
CSNA users more comfortable when actually configuring their SSH
clients and servers.

Just suggesting that the security consideration of the other SSH RFCs
is sufficient undermines the purpose and justification of this draft.
This section should tell the reader what vulnerability of security for
the SSH protocol exists without the mitigation of the profile being
recommended in this draft.

Section 12.1

The URL: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cnss.gov%2FCNSS%2FIssuances%2FPolicies.htm&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZHTdHKEcLvuXmW9CWXhoXk4ctwF%2BfqDUBcsGGWPLxRY%3D&amp;reserved=0 is
embarrassing as my browser reports 'NET::ERR_CERT_INVALID'

  |  Subject: https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iad.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=lrAbhO4Cqu57a0iy9YNIxDPpBu5jDPvTfkY%2B08SYZj0%3D&amp;reserved=0
  |
  |  Issuer: DOD SW CA-54
  |
  |  Expires on: Jan 31, 2022
  |
  |  Current date: Aug 7, 2021
  |
  |  PEM encoded chain:
  |  -----BEGIN CERTIFICATE-----
  |  MIIEwDCCA6igAwIBAgICf38wDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCVVMx
  |  GDAWBgNVBAoMD1UuUy4gR292ZXJubWVudDEMMAoGA1UECwwDRG9EMQwwCgYDVQQL
  |  DANQS0kxFTATBgNVBAMMDERPRCBTVyBDQS01NDAeFw0xOTAxMzExOTM1NDRaFw0y
  |  MjAxMzExOTM1NDRaMGsxCzAJBgNVBAYTAlVTMRgwFgYDVQQKDA9VLlMuIEdvdmVy
  |  bm1lbnQxDDAKBgNVBAsMA0RvRDEMMAoGA1UECwwDUEtJMRAwDgYDVQQLDAdOU0Ev
  |  Q1NTMRQwEgYDVQQDDAt3d3cuaWFkLmdvdjCCASIwDQYJKoZIhvcNAQEBBQADggEP
  |  ADCCAQoCggEBAJapnWkho9HhQA11ySYQppvELs8eGWEnMwdQQXk5ik9647QPQFfd
  |  NtPlSbJvZwuxKreWr8AARKe7bzTRSuuOK8wfhTuc8Z65jbwK0/SvyUWwViHyMF4O
  |  ASo4q66dLmWbO7tvgmb1pR0RTWt94sBldsW0klknTiM2Fal1bJrCdVlG8JzQ0Lx6
  |  MeUJHouRYln3bmgetnmUupGG7scV3N8fzDf39B/XPnLX+kgjn366xIjSoTCKhPO+
  |  g3vxh0/0+5c1lRgveN9smfytLYVhBRMwEiEYEO8+EaI9CyUbFZ4/rj9z55zeFMOf
  |  S1eKu6sOnTDxZFtlUBIQC03/pfyCF6mVjbcCAwEAAaOCAX0wggF5MB8GA1UdIwQY
  |  MBaAFLC3KL8sBImKdCavqhOMAhBVgXmxMB0GA1UdDgQWBBSBBFCzdIbRPI+nM3oi
  |  ePipyDap/DBlBggrBgEFBQcBAQRZMFcwMwYIKwYBBQUHMAKGJ2h0dHA6Ly9jcmwu
  |  ZGlzYS5taWwvc2lnbi9ET0RTV0NBXzU0LmNlcjAgBggrBgEFBQcwAYYUaHR0cDov
  |  L29jc3AuZGlzYS5taWwwDgYDVR0PAQH/BAQDAgWgMDcGA1UdHwQwMC4wLKAqoCiG
  |  Jmh0dHA6Ly9jcmwuZGlzYS5taWwvY3JsL0RPRFNXQ0FfNTQuY3JsMEYGA1UdEQQ/
  |  MD2CC3d3dy5pYWQuZ292ghJuY21kLXVmeDA1LmlhZC5nb3aCDHd3dy5jbnNzLmdv
  |  doIMd3d3Lmlvc3MuZ292MBYGA1UdIAQPMA0wCwYJYIZIAWUCAQsnMCcGA1UdJQQg
  |  MB4GCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUIAgIwDQYJKoZIhvcNAQELBQAD
  |  ggEBABzu5Naz3ndMZFkR9aA35AlyXT8R/zW4I7YyNONr6cybciSjPuQjmFfdbvDd
  |  l9t/Hv8FhXCF4KhxFoMADAyZcLjARKF26elYizcGKr9nc6hmgiUJpwqp/B8+Rlfn
  |  TG7s1UWlXrdSn/LxCZdNk/zJl3X5CoXAimFq3EL5+ziZvFtDtiGI8538PTBQ/Tra
  |  6ZHr7qUG5T9hCNrajwULckBxD4Nuh+F4wP6AWu96BFlQuMasYksvm4y8oiPXnUhM
  |  gDG0z5umBR15mdZ7CSUPlG2lETB2w6LjPIN84hp73LP30L/St1dZlX+1ZWfEBvPW
  |  Hij1G3wQ+dsAJkApXaxWJX1WLGA=
  |  -----END CERTIFICATE-----

I respectfully suggest that a published document with a revision be
produced that has a valid DOI URL that is not subject to change from
https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iad.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=lrAbhO4Cqu57a0iy9YNIxDPpBu5jDPvTfkY%2B08SYZj0%3D&amp;reserved=0 to https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9y%2Fb1xNndoOfnQhZQlxrwnZk3jp8m55khzfy2g0KyYU%3D&amp;reserved=0 or other issues moving forward.
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cnss.gov%2FCNSS%2FIssuances%2FPolicies.htm&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZHTdHKEcLvuXmW9CWXhoXk4ctwF%2BfqDUBcsGGWPLxRY%3D&amp;reserved=0

    $ wget --no-check-certificate https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cnss.gov%2FCNSS%2FIssuances%2FPolicies.htm&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZHTdHKEcLvuXmW9CWXhoXk4ctwF%2BfqDUBcsGGWPLxRY%3D&amp;reserved=0
    --2021-08-09 13:04:49--  https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cnss.gov%2FCNSS%2FIssuances%2FPolicies.htm&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZHTdHKEcLvuXmW9CWXhoXk4ctwF%2BfqDUBcsGGWPLxRY%3D&amp;reserved=0
    Resolving https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9y%2Fb1xNndoOfnQhZQlxrwnZk3jp8m55khzfy2g0KyYU%3D&amp;reserved=0 (https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9y%2Fb1xNndoOfnQhZQlxrwnZk3jp8m55khzfy2g0KyYU%3D&amp;reserved=0)... 8.44.96.42
    Connecting to https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9y%2Fb1xNndoOfnQhZQlxrwnZk3jp8m55khzfy2g0KyYU%3D&amp;reserved=0 (https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927315045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9y%2Fb1xNndoOfnQhZQlxrwnZk3jp8m55khzfy2g0KyYU%3D&amp;reserved=0)|8.44.96.42|:443... connected.
    WARNING: cannot verify https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=YVOtWMrw2ixFPfZhQdQ0uqDNyd%2B3VxGMEy8NTF51PFw%3D&amp;reserved=0's certificate, issued by ‘CN=DOD SW CA-54,OU=PKI,OU=DoD,O=U.S. Government,C=US’:
      Unable to locally verify the issuer's authority.
    HTTP request sent, awaiting response... 302 Found
    Location: /my.policy [following]
    --2021-08-09 13:04:50--  https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cnss.gov%2Fmy.policy&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=JrCcO44aV00X6faaLf52WvF%2BCkXT2Yn65awG0p5ahAk%3D&amp;reserved=0
    Connecting to https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=YVOtWMrw2ixFPfZhQdQ0uqDNyd%2B3VxGMEy8NTF51PFw%3D&amp;reserved=0 (https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=YVOtWMrw2ixFPfZhQdQ0uqDNyd%2B3VxGMEy8NTF51PFw%3D&amp;reserved=0)|8.44.96.42|:443... connected.
    WARNING: cannot verify https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=YVOtWMrw2ixFPfZhQdQ0uqDNyd%2B3VxGMEy8NTF51PFw%3D&amp;reserved=0's certificate, issued by ‘CN=DOD SW CA-54,OU=PKI,OU=DoD,O=U.S. Government,C=US’:
      Unable to locally verify the issuer's authority.
    HTTP request sent, awaiting response... 302 Found
    Location: /CNSS/Issuances/Policies.htm [following]
    --2021-08-09 13:04:50--  https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cnss.gov%2FCNSS%2FIssuances%2FPolicies.htm&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ulpiF045GhD%2BNLYbN1VMYRQecRGqxDbOywpYssk5JuQ%3D&amp;reserved=0
    Connecting to https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=YVOtWMrw2ixFPfZhQdQ0uqDNyd%2B3VxGMEy8NTF51PFw%3D&amp;reserved=0 (https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=YVOtWMrw2ixFPfZhQdQ0uqDNyd%2B3VxGMEy8NTF51PFw%3D&amp;reserved=0)|8.44.96.42|:443... connected.
    WARNING: cannot verify https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnss.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=YVOtWMrw2ixFPfZhQdQ0uqDNyd%2B3VxGMEy8NTF51PFw%3D&amp;reserved=0's certificate, issued by ‘CN=DOD SW CA-54,OU=PKI,OU=DoD,O=U.S. Government,C=US’:
      Unable to locally verify the issuer's authority.
    HTTP request sent, awaiting response... 404 Not Found
    2021-08-09 13:04:50 ERROR 404: Not Found.
    $

Note: I tried to visit the link with a number of browsers and failed
each time.

URL for FIPS180 should be https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.6028%2FNIST.FIPS.180-4&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=Inz%2FLxlD02lBF7Yfp%2BTwzQF5AHcwJyWKpfnfN%2BaLXlc%3D&amp;reserved=0
rather than https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.gov%2Fpublications%2Fdetail%2Ffips%2F180%2F4%2Ffinal&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=%2FBPmELhr1nmBPhJKn8W2ST0ozyBPYrSy5gtyLTuz%2Bx4%3D&amp;reserved=0
OR, should use the DOI entry in the citation.

Section 12.2

I would also suggest that

 https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvlpubs.nist.gov%2Fnistpubs%2FSpecialPublications%2FNIST.SP.800-56Ar3.pdf&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=YhLgMOX8atYmRC9S%2FcyPHDsGBQkrOayfSqCVHXm3FWs%3D&amp;reserved=0

become a DOI URL https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.6028%2FNIST.SP.800-56Ar3&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=0uAdEUqJKmLTOm2%2BbZztkdhPyw%2FnoUZg2%2BB%2Bxw%2Bhz0s%3D&amp;reserved=0
or that the reference include the DOI information.

With similar DOI URLs used for the csrc.nist.gov and https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nist.gov%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=wpYBSyKkhos%2BJ%2FKBEqwIz4QYs2SakRkLzly%2Bm777eRE%3D&amp;reserved=0
URLs. They have changed locations a number of times over the last
20+ years and the DOI URLs are intended to be able to be updated to
point to a good archival location for the documents.

It is not yet clear to me if GSSAPI capabilities are allowed in the
CSNA framework. Trusting a Key Distribution Center (KDC) for servers
to be used to introduce other servers needs to be addressed in this
document somewhere as there is a large installed base of Microsoft
servers and many educational institutions that use Kerberos throughout
their institutions.

I would also suggest that one or two examples of configurations for
client and server of popular SSH configurations may be desirable. This
would let you show how to inter-operate with more than one release of
popularly available implementations. This would allow you to show that
interoperability testing has actually occurred with one or more
implementations of the SSH client/server protocol with your suggested
profile.

Quick and dirty partial example... only you really know what you think
is correct...

  * OpenSSH sshd_config (server configuration file, but most of these
    will also be present in the ssh_config file).

    KexAlgorithms ecdh-sha2-nistp384
    KexAlgorithms +diffie-hellman-group15-sha512
    KexAlgorithms +diffie-hellman-group16-sha512

    PubkeyAcceptedKeyTypes [e-mail]
    PubkeyAcceptedKeyTypes [e-mail]
    PubkeyAcceptedKeyTypes +ecdsa-sha2-nistp384,rsa-sha2-512

    HostKeyAlgorithms [e-mail]
    HostKeyAlgorithms [e-mail]
    HostKeyAlgorithms +ecdsa-sha2-nistp384,rsa-sha2-512

    Ciphers [e-mail]

    # Will not be used given [e-mail] is implicitly used
    MACs hmac-sha2-512

    HostbasedAcceptedAlgorithms [e-mail]
    HostbasedAcceptedAlgorithms [e-mail]
    HostbasedAcceptedAlgorithms +ecdsa-sha2-nistp384,rsa-sha2-512

    HostbasedAuthentication no
    HostbasedUsesNameFromPacketOnly no

    # HostCertificate filename-for-the-certificate
    # TrustedUserCAKeys filename-for-public-trusted-certificate-authorities
    HostKey /etc/ssh/ssh_host_ecdsa_key,/etc/ssh/ssh_host_rsa_key
    CASignatureAlgorithms ecdsa-sha2-nistp384,rsa-sha2-512

    # GSSAPIAuthentication yes
    GSSAPICleanupCredentials yes
    GSSAPIStrictAcceptorCheck yes

    # Use of a HostKeyAgent such as a process running on an HSM may be
    # desirable but is outside of the scope of this RFC.
    # HostKeyAgent

This ends my comments on the draft.

If you have any questions on my points, please let me know.

        Be safe, stay healthy,
        -- Mark
        [e-mail]

PS: I believe that most of the material in my original note may already have been covered, but I leave it in place as the draft-gajcowski authors were not part of the original distribution and I am not sure if they were given a copy of the message or not.

> On Jul 28, 2021, at 8:32 AM, mbaushke ietf <[e-mail]> wrote:
>
> Hi Adrian,
>
>> On Jul 27, 2021, at 3:11 PM, RFC ISE (Adrian Farrel) <[e-mail]> wrote:
>>
>> Hi Mark, I trust you are well and life is treating you fairly.
>
> I am presently on holiday, but will be back to my normal grind the middle of next week at which time I can take a more detailed look for a real review of the draft.
>
> This message was written in haste. I hope I have written it with proper references to other RFCs and URLs.
> Please pardon any typos and ask questions if my content is unclear.
>
>>
>> Nicholas Gajcowski and Mike Jenkins have submitted
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-gajcowski-cnsa-ssh-profile%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=oPXZ5ZclfSUXjBdiU3jnf30Edu23dIgvR7zHe%2Ffm%2BnA%3D&amp;reserved=0 to me
>> requesting publication as an Independent Submission Informational RFC.
>
> Okay.
>
> Taking a quick read, it does have a few problems with the majority of the SSH implementations.
>
> * The algorithm agreement of the informational RFC 5647 missed the point that AEAD algorithms already bring the MAC algorithm with them when the encryption algorithm is specified. Requiring that they both match when they are independently negotiated was a mistake. Many negotiation implementations are using "[e-mail]" to negotiate the wire protocol used in RFC 5647, but the language in the draft does not allow for this wiggle room which means that very few implementations of SSH would interoperate with this draft. At this time, I believe RFC 5647 is only implemented by two SSH variations while [e-mail] is implemented by eleven variations which includes the two that do implement RFC 5647.
>
> Notes on the [e-mail] encryption method may be found in
>
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcvsweb.openbsd.org%2Fcgi-bin%2Fcvsweb%2Fsrc%2Fusr.bin%2Fssh%2FPROTOCOL%3Frev%3D1.41%26content-type%3Dtext%2Fx-cvsweb-markup&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=yFeqTRbm6oTuCdbCpnrGL6spBiyHlc7OyLf9OQyyHLk%3D&amp;reserved=0
>
> * There is an issue in the use of X.509v3 certificates. A few of the primary implementations of SSH avoid these ASN.1 field of problems if at all possible. The largest fielded implementation is OpenSSH which provides a certificate format that is simpler and less prone to implementation errors. The format of the certificate may be found here:
>
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcvsweb.openbsd.org%2Fcgi-bin%2Fcvsweb%2Fsrc%2Fusr.bin%2Fssh%2FPROTOCOL.certkeys%3Frev%3D1.19%26content-type%3Dtext%2Fx-cvsweb-markup&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927325004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=phGk6S1lObL9o%2BVAdJeY40keAwmMFHKemHBmQ43RHX0%3D&amp;reserved=0
>
> * Section 5 seems unclear on how negotiation is performed in SSH. In this case, they need to explicitly mention the use of RFC 8308 to "add ext-info-s" and "ext-info-c" or they will not be able to support the rsa-sha2-512 algorithm they list. In addition, as suggested previously, they really should allow [e-mail] if they want RFC 5647 to be used for encryption. I think only the commercial implementations of SSH have tried to bend over sideways to implement RFC5656.
>
> Someone should look at https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fssh-comparison.quendi.de%2F&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927334958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=kyiBtTiCeoNWsWK4VOeooEMKJbqVqqaByPgNcoQU38c%3D&amp;reserved=0 to see what CNSA restrictions will actually work.
>
> Although there are very few implementations available, it seems like they should also allow the GSSAPI algorithms which match to be used, but perhaps they no longer trust a Kerberos Key Distribution Center.
>
> I also admit some surprise that EdDSA is not on the approved list, given that the Draft FIPS 186-5 has it listed (ssh-ed25519 may be too small for CSNA, but ssh-ed448 might be good enough). RFC 8709 is not mentioned at all.
>
> Also worth noting is that use of ECDSA and ECDH are theoretically easier to break than RSA using Quantum Cryptography because the number of Q-bits needed for the job are smaller. I can worry more about that when real Q-bits are shown to factor more than just 21 as the largest number I could find.
>
> * Section 12.1 - the CNSA URL does not work without setting off security problems. They really need to get their documents somewhere that are more controlled. Perhaps use a DOI.com URL?
>
>>
>> This document is one of a series of documents that describe "profiles" of
>> IETF security tools approved for use by the US Government. The aim is to
>> advise implementers what they need to do to enter the US Government
>> market, but also to help best practices. The intention is to never dilute
>> IETF security, but to sometimes make some strengthening by upgrading the
>> RFC 2119 language.
>>
>> The document has been through a round of editing as I discussed several
>> points with the authors, and now I'm looking for a few brief reviews.
>
> If it a brief review you need, then the above may be a good enough start.
>
>>
>> Mike suggested you as a possible reviewer. Are you able to have a look at
>> it, and tell me (briefly) what you think of it, please?
>
> Yes. This message is the brief review.
>
>>
>> - Would publication be a good/bad idea?
>
> As it is right now, it will mean that FIPS 140-3 conformant implementations will not be able to work.
>
>> - Does it violate any security issues?
>
> Only the original sin that RFC 5656 never went through review by any of the SSH implementers.
>
>> - Is it clear enough to be published?
>
> Not yet. I think that they need to actually provide better guidance about how to avoid non-interoperability.
>
>>
>> If you are also willing and have the time/energy, would you be prepared
>> do a more detailed review as well, with two parts:
>>
>> a) Comments for the Authors
>>  Reasons for rejection or suggestions for improvements.
>>  These will be returned to authors (or you may wish to have
>>  email discussions directly with authors).  These may be
>>  be published in an 'ISE write-up' if this draft
>>  is sent to the IESG for a Conflict Review (RFC 5742).
>
> Yes, I can do this. I have written a great deal on how governments should configure and implement SSH.
>
> I was a part of the CCUF that provided an SSH package for use in Common Criterial Protection Profiles which was used by NIAP to generate the Functional Package for SSH.
>
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.niap-ccevs.org%2FProfile%2FInfo.cfm%3FPPID%3D459%26id%3D459&amp;data=04%7C01%7Cmjjenki%40cyber.nsa.gov%7C539e1456134f43f03eeb08d96006b165%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637646404927334958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=LDB5sfWWVThCxvqEmWsN1AadLYSTKKQg9CpNAG%2Bnag4%3D&amp;reserved=0
>
> As written, the current draft will make that NIAP functional Package harder to handle.
>
>>
>> b) Comments for the Independent Submissions Editor
>>  These are advice to the ISE, and will not be published.
>>
>> If you can do the review, two to three weeks would be a good time frame.
>> If not, could you suggest other possible reviewers, please?
>
> If there is need, I can provide a suggested list of other possible reviewers for this document.
>
>>
>> Thanks,
>> Adrian
>> --
>> Adrian Farrel (ISE),
>> [e-mail]
>>
>
> Thank you for the opportunity to help the ISE.
>
> You may feel free to send a copy of this message to the authors of the draft if you think it would be useful.
>
>        Be safe, stay healthy,
>        -- Mark
>        [e-mail]
>