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=2680Hello, 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