Proposal and intent to implement "dsa-sha2-256" SSH key algorithm

denis bider <ietf-ssh3@denisbider.com> Wed, 28 October 2015 08:12 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DB91AC3F1 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Wed, 28 Oct 2015 01:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.791
X-Spam-Level:
X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FE_uQLzhwUsV for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Wed, 28 Oct 2015 01:12:40 -0700 (PDT)
Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731CA1A026E for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Wed, 28 Oct 2015 01:12:25 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id 262D014A1A7; Wed, 28 Oct 2015 08:12:22 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: by mail.netbsd.org (Postfix, from userid 1347) id BDDFF14A176; Wed, 28 Oct 2015 08:12:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5060814A28C for <ietf-ssh@netbsd.org>; Tue, 27 Oct 2015 23:51:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at NetBSD.org
Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id nOII3mmPD9zT for <ietf-ssh@netbsd.org>; Tue, 27 Oct 2015 23:51:15 +0000 (UTC)
Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 7368614A1E5 for <ietf-ssh@netbsd.org>; Tue, 27 Oct 2015 23:51:15 +0000 (UTC)
X-Footer: ZGVuaXNiaWRlci5jb20=
Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Tue, 27 Oct 2015 22:50:09 +0000
Date: Tue, 27 Oct 2015 22:50:09 +0000
Subject: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm
X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Message-ID: <1107500596-2928@skroderider.denisbider.com>
X-Priority: 3
Importance: Normal
MIME-Version: 1.0
From: denis bider <ietf-ssh3@denisbider.com>
To: ietf-ssh@netbsd.org
Content-Type: multipart/alternative; boundary="=-D/tHOdgKvhLDcK69vyMT"
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

Hey everyone,

so, over the past several years, it looks like everyone has proverbially screwed the pooch with regard to plain old DSA key sizes larger than 1024 bits.

OpenSSH is now going so far as to have dropped ssh-dss in its default  configuration, which is reasonable, given that this algorithm is now only useful  for 1024-bit DSA.

Everyone is migrating now to ECDSA over NIST curves or Ed25559,  which is all nice and well - these appear to be strong algorithms,  according to information available at this time.

Still, I think it's a pity for larger DSA keys to never have had a chance; but more than sentimentalism, I think we're losing out on heterogeneity and backup options in case something, anything, turns out to be wrong in Elliptic Curve territory.

Now, if we want to agree on some way to implement large DSA keys, the "ssh-dss" algorithm name is tainted for use with larger key sizes, because there are implementations out there that implement them in incompatible ways:

- There were older versions of OpenSSL and OpenSSH that implemented 2048-bit modulus, but kept 160-bit subgroup. This did not effectively increase the security of the scheme, compared to 1024-bit modulus.

- Our (Bitvise) implementation predates FIPS 186-3 by a year. It supports a larger modulus, and appropriately larger subgroups, BUT continues to use SHA-1 as the hash function. After FIPS 186-3, other implementations of larger DSA keys, such as Windows CNG, support the larger DSA keys in conjunction with SHA-2.

- A majority of other "ssh-dss" implementations support only 1024-bit key sizes, and can't verify signatures with larger DSA keys under that scheme.

Larger DSA keys need a new scheme name for compatibility reasons.

I therefore suggest a new SSH key algorithm, dsa-sha2-256, which cherry-picks from FIPS 186-3 the following two options:

L = 2048, N = 256
L = 3072, N = 256

In other words:
- modulus size is either 2048 or 3072
- subgroup size is 256 bits
- hash function is SHA2-256

I choose the name "dsa-sha2-256", rather than a suffixed name ("...@bitvise.com") for the following reasons:

- Suffixed names are overly long and clumsy. If I were to choose a suffixed name instead, I would go with just "...@bv".

- Suffixed names complicate standardization. If a suffixed algorithm is commonly implemented, there's pressure to have a version with a non-suffixed name, and now we have multiple names for the same thing.

- I don't see many ways for "dsa-sha2-256" to be implemented incorrectly or incompatibly by a reasonable implementor. There's really only one DSA, the one specified in FIPS 186. This has four variants. The suffix -sha2-256 explicitly specifies which hash function to use, and strongly suggests use of the 256-bit subgroup sizes.

Unless someone has a strong and reasonable objection, I intend to  implement this for Bitvise SSH Client and Server 7.xx as described above.

Comments welcome.