openssh unix dev - Jan 2019 - Can we disable diffie-hellman-group14-sha1 by default?

I'm not sure if collision resistance is required for DH key
derivation, but generally, SHA-1 is on its way out. If it's possible
(if there's not a very large percentage of servers that do not support
anything newer), it should be disabled.

On Sat, 19 Jan 2019, Yegor Ievlev wrote:
> I'm not sure if collision resistance is required for DH key
> derivation, but generally, SHA-1 is on its way out. If it's possible
> (if there's not a very large percentage of servers that do not support
> anything newer), it should be disabled.
No, SHA1 is used as a PRF for key derivation so collision-resistance
is not needed.

Yes, a large number of devices only support this curve - it's the only
remaining MUST curve from the original RFCs that we enable by default.

It's the last preference on the client, and the KEX isn't subject to
MITM downgrade attacks unless the hostkey signature algorithm is broken,
so keeping it there doesn't affect the security of connections to
servers that support better KEX algorithms.

For these reasons we're keeping it. Feel free to adjust your own configs -
it's easy: "KexAlgorithms=-diffie-hellman-group14-sha1"

-d

Yegor Ievlev <koops1997 at gmail.com> writes:
> I'm not sure if collision resistance is required for DH key
> derivation, but generally, SHA-1 is on its way out. If it's possible
> (if there's not a very large percentage of servers that do not support
> anything newer), it should be disabled.
Perhaps, but doing so will be the final break in dealing with devices
that have SSH, but no path to really upgrade the implementation. Just
putting it at the end of the negotation list will do almoast as well.

Both diffie-hellman-group1-sha1 (which is defined in RFC 2412 section
E.2 as 'Well-Known Group 2: A 1024 bit prime', so the name
'group1' has
always been a bit of a misrepresentation) and
diffie-hellman-group14-sha1 were specified in RFC 4253 as a REQUIRED to
implement key exchange.

By default you may choose to not include them in your key exchange
lists, but it would perhaps be better if you just put them at the end of
the selections.

Of course, the Mandatory To Implement (MTI) algorithms for SSH are
getting a bit long in the tooth now.

  Key Exchange Methods:
    diffie-hellman-group1-sha1 REQUIRED
    diffie-hellman-group14-sha1 REQUIRED
  Public Key:
    ssh-dss REQUIRED sign - Raw DSS Key (with SHA1 hashing of the key)
  MAC Algorithm:
    hmac-sha1 REQUIRED - HMAC-SHA1 (digest length = key length = 20)  
  Cipher:
    3des-cbc REQUIRED - three-key 3DES in CBC mode
  Compression:
    none REQUIRED - no compression

I personally believe we can and should deprecate
diffie-hellman-group1-sha1, but think that diffie-hellman-group14-sha1
should just be stuck to the end of the negotation list.

Note: If the device needs to pass FIPS 140-2 certification or some kind
of Common Criterial Evalution, then there will be a requirement to NOT
have ssh-dss or diffie-hellman-group14-sha1 in the negotiations. I also
expect that 3des-cbc will be on the list of non-approved algorithms
before too long.

We have lots of choices for public key cryptography: FFC = Finite Field
Cryptography (Diffie-Hellman (DH) and Digital Signature Algorith (DSA)),
IFC = Integer Factorization Cryptography (RSA), ECC = Elliptic Curve
Cryptography (Elliptic Curve DSA (ECDSA), Elliptic Curve Diffie-Hellman
(ECDH), Edwards-Curve Digital Signature Algorithm EcDSA).

None of these are secure from Post Quantum Cryptography (PQC).

My personal preferences are, you will note that I usually DO still put
the MTI arguments at the end of my lists.

  KEX:
    diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,
    curve25519-sha256 at libssh.org,diffie-hellman-group14-sha256,
    diffie-hellman-group14-sha1

  Public key (per RFC 8332 and 8308 - with 3072-bit RSA keysize):
    rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ssh-rsa,
    ecdsa-sha2-nistp256,ssh-dss

  Ciphers:
    aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,
    aes128-gcm at openssh.com,aes256-ctr,aes256-cbc,aes128-ctr,aes128-cbc,
    3des-ctr,3des-cbc

  MAC:
    hmac-sha2-512-etm at openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-sha1

  Compression:
    none

Note: for diffie-hellman-group-exchange-sha256 a la RFC 4419/8270
provide that g is a proper generator of a q-ordered subgroup which is
not mandated by the RFCs.

Note: I tend to favor sha2-512 over sha2-256 where possible as it is
usually faster on 64-bit processors and in hardware accelarators. I
would probably use sha2-384 if it were more generally available as more
of the internal state of the internal SHA engine bits are kept secret.

	-- Mark

Also can we do anything with ssh-rsa? It uses both SHA-1 and
deprecated PKCS#1 padding. If it's used to sign certificates, there's
no additional protection of SHA-2 hashing before SHA-1 signature, it
just signs the raw certificate.

On Sat, Jan 19, 2019 at 11:32 PM Yegor Ievlev <koops1997 at gmail.com>
wrote:
>
> I'm not sure if collision resistance is required for DH key
> derivation, but generally, SHA-1 is on its way out. If it's possible
> (if there's not a very large percentage of servers that do not support
> anything newer), it should be disabled.

e.g. can we make it throw warnings etc. rsa-sha2-256 and rsa-sha2-512
are fine, they use PSS.

On Sun, Jan 20, 2019 at 1:55 AM Yegor Ievlev <koops1997 at gmail.com>
wrote:
>
> Also can we do anything with ssh-rsa? It uses both SHA-1 and
> deprecated PKCS#1 padding. If it's used to sign certificates,
there's
> no additional protection of SHA-2 hashing before SHA-1 signature, it
> just signs the raw certificate.
>
> On Sat, Jan 19, 2019 at 11:32 PM Yegor Ievlev <koops1997 at
gmail.com> wrote:
> >
> > I'm not sure if collision resistance is required for DH key
> > derivation, but generally, SHA-1 is on its way out. If it's
possible
> > (if there's not a very large percentage of servers that do not
support
> > anything newer), it should be disabled.