Subject: New version of rsa-sha2-512 draft posted: no more DSA

From: denis bider <[email-masked]>
Date: Thu, 5 Nov 2015 09:13:25 +0000

I have posted a new version of the draft: see details below.

As per multiple requests (Hanno Boeck, Peter Gutmann, Damien Miller), I have removed DSA.

I have taken into account Damien's suggestion for rsa-sha2-512, and observed that there appears to be no reason to have rsa-sha2-256, if we have rsa-sha2-512. As far as I can tell, SHA-2 512 should be reasonably available everywhere that SHA-2 256 is available. It is slower on 32-bit platforms, but the performance impact of hashing is negligible compared to the signing operation. It produces a larger digest than SHA-2 256, but this digest easily fits into all reasonable RSA key sizes.

Therefore, this new version of the draft removes both rsa-sha2-256 and dsa-sha2-256, and replaces them with only rsa-sha2-512.

In addition, this version adds a mechanism which the server can use to notify the client of signature algorithms supported, so that the client does not have to guess with authentication requests. Clients will still need to implement guessing due to servers that might not support this, but if the server cares to send this info, this can speed up authentication by one or more round trips.

Unfortunately, since:

- SSH does not have a proper extension negotiation; and since

- clients of at least one ubiquitous implementation will disconnect if any new fields are added to SSH_MSG_SERVICE_REQUEST, SSH_MSG_SERVICE_ACCEPT, or SSH_MSG_USERAUTH_FAILURE;

there seems to be little choice but to send this information in a specially crafted SSH_MSG_IGNORE message. Let us congratulate ourselves on that success. ;)

Let's think things through better with the next protocol.

----- Original Message -----

A new version of I-D, draft-rsa-dsa-sha2-256-01.txt
has been successfully submitted by Denis Bider and posted to the
IETF repository.

Name: draft-rsa-dsa-sha2-256
Revision: 01
Title: Use of RSA Keys with SHA-2 512 in Secure Shell (SSH)
Document date: 2015-11-05
Group: Individual Submission
Pages: 6
URL:            https://www.ietf.org/internet-drafts/draft-rsa-dsa-sha2-256-01.txt
Status:         https://datatracker.ietf.org/doc/draft-rsa-dsa-sha2-256/
Htmlized:       https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-rsa-dsa-sha2-256-01

Abstract:
  This memo defines an algorithm name, public key format, and signature
  format for use of RSA keys with SHA-2 512 for server and client
  authentication in SSH connections. A new mechanism is also defined
  for servers to inform clients of supported signature algorithms during
  client authentication.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 6 Nov 2015 08:57:50 +0000

denis bider <[email-masked]> writes:

>I have taken into account Damien's suggestion for rsa-sha2-512, and observed
>that there appears to be no reason to have rsa-sha2-256, if we have rsa-
>sha2-512. As far as I can tell, SHA-2 512 should be reasonably available
>everywhere that SHA-2 256 is available.

Uhh, that's more or less the opposite of the actual situation: SHA2-256 is
fast becoming the universal replacement for SHA-1, while SHA2-512 is the "oh,
there's another one alongside -256?" alternative.  For example Mozilla just
posted the following discussion item:

  In item #8 of the Maintenance Policy recommend that CAs avoid SHA-512 and
  P-521, especially in their CA certificates. This is to ensure
  interoperability, as SHA-512 and (especially) P-521 are less well-supported
  than the other algorithms.

So it should be MUST -256, MAY -512, at most.

(I can't see any good reason to have -512, it has little support, it's a pain
to do on 32-bit CPUs, it's slow, and it offers little to no practical security
advantage over -256).

Peter.

---

From: [email-masked] (Niels Möller)
Date: Sun, 08 Nov 2015 19:18:58 +0100

> to do on 32-bit CPUs, it's slow, and it offers little to no practical security

My experience is that sha512 actually seems to be a bit faster than
sha256 on 64-bit hardware.

That said, I do agree rsa-sha256 might be a better choice for a new
required or strongly recommended signature algorithm.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: Damien Miller <[email-masked]>
Date: Mon, 9 Nov 2015 09:05:26 +1100 (AEDT)

>   than the other algorithms.

I don't think the glacial* crypto adoption pace of CAs is relevant to 
the choices we make for SSH. Moreover, any SSH implementation that
supports ed25519 in the future will need SHA512 for it's inner hash,
so it's not like it will be extra code to carry around.

-d

* actually unfair to glaciers

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 8 Nov 2015 23:31:48 +0000

Damien Miller <[email-masked]> writes:

>I don't think the glacial* crypto adoption pace of CAs is relevant to the
>choices we make for SSH.

The OP wasn't commenting on use by CAs, it was commenting on use by clients.
In other words it was saying that CAs should hold back on -512 otherwise
clients won't be able to verify the certs they issue.

>Moreover, any SSH implementation that supports ed25519 in the future will
>need SHA512 for it's inner hash, so it's not like it will be extra code to
>carry around.

This assumes that your implementation carries an entire crypto library around
with it.  Many don't, but use the host's crypto.  If the host doesn't support
algorithm X, then you're out of luck.

Peter.

---

From: Damien Miller <[email-masked]>
Date: Mon, 9 Nov 2015 10:49:21 +1100 (AEDT)

> algorithm X, then you're out of luck.

What I'm saying is that any implementation that does ed25519 keys will
also need to support SHA512. So SHA512 seems like a good choice if you
care about minimising the amount of code that you want to carry around.

ed25519 looks like it will be an excellent choice for embedded devices,
and Peter Schwabe has a couple of MCU ports (inc. 8 bit AVR) already.

-d