openssh unix dev - Apr 2017 - Allow SHA1 deprecation for rsa-sha

Hi,

Following the fix [1] being released on 7.5, now SHA2 RSA signature
methods work properly.

On the other hand it is still not possible to disable SHA1 RSA alone
(as an example, as SHA2-256 or SHA2-512 could also potentially be not
desirable), where it is considered insecure or undesirable.

I am proposing to add a mechanism, and happy to submit a patch, to
enable selection of the Hashes allowed for RSA. If all or any of SHA1,
SHA2-256, and SHA2-512.

The straighforward solution would be just to adapt all options that
currently accept "ssh-rsa" to mean that they accept
(SHA1,SHA2-256,SHA2-512), and to use rsa-sha2-256 and rsa-sha2-512 to
mean just the specific hash formats.

So ssh-rsa would mean the same as now, and in the future deprecation
for sha1 could be enforced by replacing the config with
"rsa-sha2-256,rsa-sha2-512".

Unfortunately this doesn't cover the possibility the user wants to
disable instead sha2 and only allow sha1.

For that case I propose to extend keytypes at sshkey.c, with an
additional "rsa-sha1" algorithm.

This means that ssh-rsa would be the "legacy" configuration, with the
same meaning as "rsa-sha1, rsa-sha2-256, rsa-sha2-512".

I would appreciate comments if this is seen fit.

Also, since I am lacking on understanding the ssh protocol, I question
if this sha2 extensions also apply "ssh-rsa-cert-v01 at openssh.com".

Thanks,
Nuno

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2680

On 04/04/2017 04:18 PM, Nuno Gon?alves wrote:
> Hi,
>
> Following the fix [1] being released on 7.5, now SHA2 RSA signature
> methods work properly.
>
> On the other hand it is still not possible to disable SHA1 RSA alone
> (as an example, as SHA2-256 or SHA2-512 could also potentially be not
> desirable), where it is considered insecure or undesirable.
>
> I am proposing to add a mechanism, and happy to submit a patch, to
> enable selection of the Hashes allowed for RSA. If all or any of SHA1,
> SHA2-256, and SHA2-512.
>
> The straighforward solution would be just to adapt all options that
> currently accept "ssh-rsa" to mean that they accept
> (SHA1,SHA2-256,SHA2-512), and to use rsa-sha2-256 and rsa-sha2-512 to
> mean just the specific hash formats.
>
> So ssh-rsa would mean the same as now, and in the future deprecation
> for sha1 could be enforced by replacing the config with
> "rsa-sha2-256,rsa-sha2-512".
>
> Unfortunately this doesn't cover the possibility the user wants to
> disable instead sha2 and only allow sha1.
>
> For that case I propose to extend keytypes at sshkey.c, with an
> additional "rsa-sha1" algorithm.
>
> This means that ssh-rsa would be the "legacy" configuration, with
the
> same meaning as "rsa-sha1, rsa-sha2-256, rsa-sha2-512".
>
> I would appreciate comments if this is seen fit.
>
> Also, since I am lacking on understanding the ssh protocol, I question
> if this sha2 extensions also apply "ssh-rsa-cert-v01 at
openssh.com".
>
> Thanks,
> Nuno
>
> [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2680
Hello,

Disabling SHA-1 for signatures sounds like a good idea these days (and 
was the main reason why the extension created if I read it right [1]).
This leaves me confused if the use case without SHA1 was missed from the 
draft or it was left as an implementation detail, that was not 
implemented in OpenSSH.

Your proposal sounds reasonable, though not sure if this should all go 
into this single configuration option, or we should use different 
talking about the hash algorithms such as PubkeySignatureHash, since the 
existing list of algorithms (PubkeyAcceptedKeyTypes) is long enough already.

To my understanding, this update should not be needed for the 
certificates, since they are just an addition to public keys and do not 
change how the private key operations are performed (and secured).

[1] https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-03

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

On Wed, Apr 5, 2017 at 10:21 AM, Jakub Jelen <jjelen at redhat.com>
wrote:
> Your proposal sounds reasonable, though not sure if this should all go into
> this single configuration option, or we should use different talking about
> the hash algorithms such as PubkeySignatureHash, since the existing list of
> algorithms (PubkeyAcceptedKeyTypes) is long enough already.
Actually I tried exactly as you suggested 1 month ago [1], but I'm not
sure if that is the best way forward now after comments from Douglas,
and so I was proposing to just extend the same option.

Anyway I'll wait for comments  for 1 week and then eventually provide
patchs for both options as they are quite trivial in any case.

Thanks,
Nuno

[1]
https://github.com/nunojpg/openssh-portable/commit/1739aceb34c0eb4a9b363ff2515925e093d7ddcc

On Wed, 5 Apr 2017, Jakub Jelen wrote:
> Disabling SHA-1 for signatures sounds like a good idea these days (and was
the
> main reason why the extension created if I read it right [1]).
> This leaves me confused if the use case without SHA1 was missed from the
draft
> or it was left as an implementation detail, that was not implemented in
> OpenSSH.
The reasons we didn't implement disabling RSA/SHA1 were basically:

1) The protocol extension used to negotiate the RSA/SHA2 methods is still
   an early draft and is subject to change
2) Hardly any other implementations support the necessary extension.
3) Support for RSA/SHA2 signatures is still incomplete, e.g. they aren't
   usable with PKCS#11 tokens yet.

IMO users who want a stronger signature hash algorithm should use ed25519
or one of the ECDSA methods for the time being. All of these use SHA2 hashes.

-d