From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 28 01:12:41 2015 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 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 --=-D/tHOdgKvhLDcK69vyMT Content-Type: text/plain; charset="utf-8" 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. --=-D/tHOdgKvhLDcK69vyMT Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey everyone,

so, over the past several yea= rs, it looks like everyone has proverbially screwed the pooch with regard t= o plain old DSA key sizes larger than 1024 bits.

OpenSSH is now goin= g so far as to have dropped ssh-dss in its default=20 configuration, which is reasonable, given that this algorithm is now only u= seful for 1024-bit DSA.

Everyone is migrating now to ECDSA over NIST curv= es or Ed25559,=20 which is all nice and well - these appear to be strong algorithms,=20 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 senti= mentalism, 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, beca= use there are implementations out there that implement them in incompatible= ways:

- There were older versions of OpenSSL and OpenSSH that imple= mented 2048-bit modulus, but kept 160-bit subgroup. This did not effectivel= y 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 larg= er DSA keys, such as Windows CNG, support the larger DSA keys in conjunctio= n with SHA-2.

- A majority of other "ssh-dss" implementations suppor= t 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 compa= tibility reasons.

I therefore suggest a new SSH key algorithm, dsa-s= ha2-256, which cherry-picks from FIPS 186-3 the following two options:
<= br>L =3D 2048, N =3D 256
L =3D 3072, N =3D 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 t= han 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 compli= cate standardization. If a suffixed algorithm is commonly implemented, ther= e's pressure to have a version with a non-suffixed name, and now we have mu= ltiple names for the same thing.

- I don't see many ways for "dsa-sh= a2-256" to be implemented incorrectly or incompatibly by a reasonable imple= mentor. There's really only one DSA, the one specified in FIPS 186. This ha= s four variants. The suffix -sha2-256 explicitly specifies which hash funct= ion to use, and strongly suggests use of the 256-bit subgroup sizes.
Unless someone has a strong and reasonable objection, I intend to=20 implement this for Bitvise SSH Client and Server 7.xx as described above.
Comments welcome.

= --=-D/tHOdgKvhLDcK69vyMT-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 28 06:48:02 2015 Return-Path: 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 5DF1C1A88C0 for ; Wed, 28 Oct 2015 06:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 rGy1qbJYWqE6 for ; Wed, 28 Oct 2015 06:48:00 -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 CADB01A88B8 for ; Wed, 28 Oct 2015 06:48:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id C349C14A24F; Wed, 28 Oct 2015 13:47:57 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9ECC014A24E for ; Wed, 28 Oct 2015 13:47:54 +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 l1sC3nFq0J3h for ; Wed, 28 Oct 2015 13:47:54 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D62E814A239 for ; Wed, 28 Oct 2015 13:47:52 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CABDF4004F; Wed, 28 Oct 2015 14:47:48 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 55C9240011; Wed, 28 Oct 2015 14:47:47 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Wed, 28 Oct 2015 14:47:47 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm References: <1107500596-2928@skroderider.denisbider.com> Date: Wed, 28 Oct 2015 14:47:47 +0100 In-Reply-To: <1107500596-2928@skroderider.denisbider.com> (denis bider's message of "Tue, 27 Oct 2015 22:50:09 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes: > I therefore suggest a new SSH key algorithm, dsa-sha2-256, which > cherry-picks from FIPS 186-3 the following two options: > > L =3D 2048, N =3D 256 > L =3D 3072, N =3D 256 > > In other words: > - modulus size is either 2048 or 3072 > - subgroup size is 256 bits > - hash function is SHA2-256 Makes sense to me.=20 Last time I looked at doing larger DSA, I had trouble finding any test vectors. Does FIPS-186 include any now? > I choose the name "dsa-sha2-256", rather than a suffixed name > ("...@bitvise.com") for the following reasons: I don't quite agree, but I don't have any strong objection either. I think it would be nice with an (informational?) RFC spelling out those details, and providing a few test vectors. Any then a non-suffixed name is fully appropriate (and as far as I remember, the ietf requirements for a new ssh algorithm name are pretty weak). Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 28 07:06:28 2015 Return-Path: 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 3DAC01A890E for ; Wed, 28 Oct 2015 07:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 loNYUVwoIDYw for ; Wed, 28 Oct 2015 07:06:25 -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 91E031A8909 for ; Wed, 28 Oct 2015 07:06:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id E10CE14A248; Wed, 28 Oct 2015 14:06:24 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4689D14A239 for ; Wed, 28 Oct 2015 14:06:17 +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 2hBZwCIpnVzs for ; Wed, 28 Oct 2015 14:06:16 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::764]) by mail.netbsd.org (Postfix) with ESMTP id F195014A20D for ; Wed, 28 Oct 2015 14:06:15 +0000 (UTC) Received: from SN1PR0501CA0003.namprd05.prod.outlook.com (10.163.126.141) by BL2PR05MB052.namprd05.prod.outlook.com (10.255.228.156) with Microsoft SMTP Server (TLS) id 15.1.306.13; Wed, 28 Oct 2015 14:06:12 +0000 Received: from BY2FFO11FD035.protection.gbl (2a01:111:f400:7c0c::139) by SN1PR0501CA0003.outlook.office365.com (2a01:111:e400:52fe::13) with Microsoft SMTP Server (TLS) id 15.1.312.18 via Frontend Transport; Wed, 28 Oct 2015 14:06:12 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; denisbider.com; dkim=none (message not signed) header.d=none;denisbider.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BY2FFO11FD035.mail.protection.outlook.com (10.1.14.220) with Microsoft SMTP Server (TLS) id 15.1.306.13 via Frontend Transport; Wed, 28 Oct 2015 14:06:11 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 28 Oct 2015 07:06:05 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t9SE65D33390; Wed, 28 Oct 2015 07:06:05 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 7E99B1144F; Wed, 28 Oct 2015 07:06:04 -0700 (PDT) To: denis bider CC: Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm In-Reply-To: <1107500596-2928@skroderider.denisbider.com> References: <1107500596-2928@skroderider.denisbider.com> Comments: In-reply-to: denis bider message dated "Tue, 27 Oct 2015 22:50:09 -0000." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11FD035;1:bD/Aphfq7xAzvpWOI9G1bTDcMDrf+Ald4Q59kt1LRsoAr9tkU/JlfF7a/JUliMUrQw1/96S6uNtXpgHdqKQa18R0JinPpYzTYBZyxCaZE4wtaL1oU+ZTU6crE+QsZ61/z6v4zYEj4WKmuFoSc1wH7CnjC3odgE3dHEOchGMwgDNLGoX/BpQgtYppfT1Gx2rEDgo1yufiV+e/UsOjHoRdoLVtsfOEdUGvrsZsraZfyrLOYmG9gwjUedtouy2RBYgkeUPt1b13R7MdyUV1bY7WK4XWRVTst1E1Euu2B6idLBJ+RLuTziAubLKZTl3ziBUbQaRz3kkPb71KqEQwUNS9pw== X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(243025005)(189002)(5007970100001)(15975445007)(76506005)(117636001)(5001960100002)(189998001)(77096005)(2950100001)(81156007)(87936001)(53416004)(97736004)(8558605004)(5003600100002)(76176999)(50986999)(110136002)(86362001)(50226001)(19580405001)(5003940100001)(106466001)(47776003)(19580395003)(6806005)(92566002)(48376002)(105596002)(69596002)(50466002)(230783001)(11100500001)(42262002)(19623455008);DIR:OUT;SFP:1102;SCL:1;SRVR:BL2PR05MB052;H:p-emfe01b-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB052;2:c4iQM4TjgvSvKoXeOi/treC4r5fMu5PJu6eE+5yDmoetA/BjfzM16CsYSxudJAaqOBXcRs/5iV2VMvBT0f7s4M87/BncBCEp2CH8yBdq2QgmT8oP4lryxq90f1r79aep6EZbSYfmzN/EmjEYGrwExrVl270cq3URnt0s86dYxoM=;3:eaftUxEXZSZGMFNoLMRfLchJTJFAACPCR1wP9a5jN3IuyHHYobJjv5aQk3FoiiV5z6BXFrUQKwclCpbp5MNarYKAAIXMouYVl6r/MzLvkKaFbibjPRQ89Nau+JUZ5fElKLg877tkL8LGIw47d+I76e7v1Cf2cvwKNM0FKOt1OyZsaCpm7j5ajkpvZMf3barjNiGNyd61kWaQO01UYZgSLp6CivxTAm6q8EqGNcG8AVM=;25:7+v9+NNZ0tlFUojn+CeXG97avt1OqAQ7wqyEQqft/BvAgNBKt82NiH+Bj1/8PreUUHVGMooV6U58uaOPWFE7u9TXjuHRkGq7W/FPom5b7LSvR2DLmg8MQ/czzo5TY4Yeq2uCA4FkqfnUYmhn69DXufrLeYUmev39U9tkufVX7wjcJCvKmfDN8+wANrLRDeOSNXIIC2UTlRetXNoHeTMIkc3igdi/iDt7nd35xzh9YUuExPxSa/zngMH6KOsFyo5b X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB052; X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB052;20:phh55Ho5PS/dEvRUAt/7rcvh0DpDPBAtESGBKPsQGQmNTp5/o7JsD1AIJg3NAtI5al3/kQW2QRqv+4OT5HBJOOTA9Y2dixaYjeKAmhH3DIPg4VXVqxqSmHeFCxOeeYkxBJV0tIuAYN2UdFwU0GVYRle5q3rCsgt+FPqcVtL3PEMMWe6xDjGZ9xtz3+8Dn9rGpRNss2t1pvY9hYvjBri522ABNojm9ndo2ih/6jErr7xG3dTpopj1Nx3UQMqxhJ5Z9j+S22FNfr31rZnsMtHsNmOFHy4/JEi5KzSMlKvU2G1FSZWeNelJyOLaMToOUxJWSw+tZhR8nO2ZRtOusx6L9iiQEU6J1Uu1QoHpKFNqi6m6lQFM30sLk1HPa4tFHr+TBoL7uXsXHc0F+RW2tP/4NR9iIsrpY5Ima4T6wJEDiP59EFcqNMg3bVcgeHapeSCpbxhzpn8V1t73plZvVQSUt6xrdOS7EI/PSvrnpxhb7sHUIiSuja9zmXw6eNOiTtsq;4:0QDaER7uH2rqgjSmEuPfLUP2dZ15dmQynxZOqfnHnyYg+x9SgngPkIqI31zedEMBzgFp50z1/3yjBmi7Exhqu6IeUt8nIfZKd6mkpmRXS7E1UyuMMKjE8D30VWY2AXosthMLnCiTDrLXzPLH+t0c4g1ohVP7gKDYN8aBFUlG2YluwO4CJ7fCE2KvWV7d7Tl5NWjXBifslqvjE6+WAjbmfXH85iKewjTCBlNfxnRmrnzb21nBlx3VQrGnSQrzgSB0DNm/YaOLLMEvI6mAe6Z2lMVdc1FcTMrCqeJu2/RzVPhLoveDbvA1u8GdSs0FDf2itmX7tD6g/V4FKAzev5FK+QqtmsLEGJjQbB8ZTSge/PLAOeIMVYQphjxFMUWiXOFjA0tnMtWJnsl4LpB1/q0YZg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(65766998875637); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046)(102215026);SRVR:BL2PR05MB052;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB052; X-Forefront-PRVS: 0743E8D0A6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BL2PR05MB052;23:AYiyT41f5+AUOrONqEWT8xpq7H2rtYXzkFZqmqyDx+?= =?us-ascii?Q?mjjbSQbnRh9+MOHo43GITdFM7mkRlNqzeKDkKum5s7GuSs1Gu583RsRMVzaQ?= =?us-ascii?Q?zFLuJmMnxva8jpLJd82ogZHSnOkHI2bRPGD4hJBZKYuWtgOBqmKcxTa002Ub?= =?us-ascii?Q?9VLMzVVwLVpUmUt/fWM7Q2Zd+RMsWfv0Y3HKpLJbyX2B9iASZ989O9PykGK3?= =?us-ascii?Q?+U57eNUEi2Q3q/BjNyzAGlBPT3CJWZB9khvFCCFj5Wsmkp4YY5C2p3C/HXud?= =?us-ascii?Q?o2R/IDcG3KJ5XN4jbKkLX78DQjsgOkA4MmNCa3UW3JOJkrj6RpnR1XiywN0c?= =?us-ascii?Q?M6g2ASAY0RwArC2Vjslui4XEFUhnE7mrxGmxf6ygf3Ub4F2rCJRIjt58j32M?= =?us-ascii?Q?Ghshv7yZ7qnR0Zs9HMhBCu2aAjX9Ge3iuIQDEhFs8P+cNvl7WRLqnWCBYD+m?= =?us-ascii?Q?pw7FSOi3bmIou5HT5bWreB+ou3Z7bf1s32wjK1RY40GeDGoGrJ9tM9VLs6oy?= =?us-ascii?Q?qkvISymj1wVRBvwAID+LIODjnKJNKiyXr6aEUMEbUdBSeB8WrrrH12Qi5Yu6?= =?us-ascii?Q?8zp7O/myFawlNS0cPVD4HLJzc6Djo3lCO20JJQpRQUMf+0IBsDAtYGEyRVsM?= =?us-ascii?Q?p9TEtc+qczEc/FotrUaKQQ7mTSztSLJy/sH+F7Nh2gc1qKCEWxRDaYQaTww4?= =?us-ascii?Q?6cnuWyLlqTK1VVncOhr87xiB2/A+PwCDdSjWz+fs6qEkhwMuGG45IuY1quoD?= =?us-ascii?Q?HTMbIZqePErKQCgYE8RliQtnzZ3xo78jd1FnyCo3gUd6Q305LU5JPQSomPwx?= =?us-ascii?Q?n3tCULkz4IuUL5To42GSZsyFSPgNnsph6xGS3NwqkgL4CbktJhhDAgnjXEf/?= =?us-ascii?Q?JZHVyCbNXjh89zWSxeL6xxumSCbvpJEDc64dzhvNOR+jgSXiUQKj7LHjxC2A?= =?us-ascii?Q?3xfAyVFqgk5PrEMyUgRODJDR1CMnoU75KtdwETK8w+yNuLSS6UiKTm1m2x/o?= =?us-ascii?Q?hAW8U6luX45MhxjSHec9RTUsLtpbo+06FMFLhVG4sSacsjMs/CiZrUXqzoJP?= =?us-ascii?Q?TEHTmQsRtLLm55vfl9RbzDV+yd?= X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB052;5:1t/A7tYWv/OKt5kNtbz2wQJ7NnBKMzkWaciwCvfET+kWzNU28Kfq98oHM/jIR0WnOd+gIa2FQsQV3NQKNWzAct81u5rFWGdI/UUgx+Pb9XToLm0i+YufuwDLmimRi/+trsn3SyfRWn2avWr2e0WwBA==;24:BPXwQ7FrZAhf5X/hwuVI5t8sUN16l5rhjll6KpyqqJVryIBAyKQZHwKHUzNIgsq2Hb152y2wO6R2GYqiFmyzATX/mFwCUuzRc9hLlcJ2FjI=;20:pd9gtkE++cFgjm89N1Hl6+u7dJFe1vALnB+VbUPsVUIWeVw8RMGkKY8mB7RstyKDiYFajP1drIVJ/tboykJSlQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2015 14:06:11.9206 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB052 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi denis, denis bider writes: > 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. If you are going to go there, you will want to write another RFC and probably use FIPS 186-4 Section 4 "The Digital Signature Algorithm (DSA)" as the normative reference. > - 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. You have already been through co-authoring RFC 6668, so writing another RFC for dsa-sha2-256 should not be that hard of a thing for you to do. Information on test vectors for DSA may be found here: http://csrc.nist.gov/groups/STM/cavp/documents/dss2/dsa2vs.pdf The test vectors for DSA2 are here http://csrc.nist.gov/groups/STM/cavp/documents/dss/186-3dsatestvectors.zip (Yes, they are still the same as FIPS 186-3.) -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 28 08:09:51 2015 Return-Path: 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 4A9B71A89EB for ; Wed, 28 Oct 2015 08:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Qa1ehz3ad9Vc for ; Wed, 28 Oct 2015 08:09:49 -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 87BA71A89C6 for ; Wed, 28 Oct 2015 08:09:49 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2D7BD14A257; Wed, 28 Oct 2015 15:09:47 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 60FCF14A242 for ; Wed, 28 Oct 2015 15:09:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 M3aZWBgrqig0 for ; Wed, 28 Oct 2015 15:09:40 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 36C3D14A235 for ; Wed, 28 Oct 2015 15:09:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BFF25BE25; Wed, 28 Oct 2015 13:52:34 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhna64Po3hhc; Wed, 28 Oct 2015 13:52:34 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 956B4BE58; Wed, 28 Oct 2015 13:52:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446040354; bh=X4rVf5RlEJi0i4XWumqEvtKdm3bK7U5oMptaeFK1mbc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lMgnpoSELjasUL0E5mHXTY7k6LjqSv4uIXDCzaFguuRFo/aw4BIEO6LeL9FVMk+/g 8wroXWBIYoL2tyesjRwCZPRoArvlkcoeZLdd+h6z5NnYxkporzrZc3yPNHaBp2MS7/ IYXewqA4Js0avB6NMocPg6kj0tU8XwWdRyk+EE9A= Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm To: denis bider , ietf-ssh@netbsd.org References: <1107500596-2928@skroderider.denisbider.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5630D321.2000301@cs.tcd.ie> Date: Wed, 28 Oct 2015 13:52:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1107500596-2928@skroderider.denisbider.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list If proceeding with this, it'd be good to pass it by the CFRG [1] list for comment. For example, in discussion of signature schemes based on new curves, CFRG recently preferred deterministic signatures, I'm not sure whether this proposal is the same i that respect or not. Cheers, S. [1] https://irtf.org/cfrg On 27/10/15 22:50, denis bider wrote: > 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. > > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 28 21:02:25 2015 Return-Path: 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 84B111B6469 for ; Wed, 28 Oct 2015 21:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 Bc0Opg8klcU1 for ; Wed, 28 Oct 2015 21:02:23 -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 D72B41B6468 for ; Wed, 28 Oct 2015 21:02:23 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 95A5014A27D; Thu, 29 Oct 2015 04:02:21 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8DB4514A27A for ; Thu, 29 Oct 2015 04:02:19 +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 U_MeDZ22cMcP for ; Thu, 29 Oct 2015 04:02:19 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D159C14A266 for ; Thu, 29 Oct 2015 04:02:18 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 8371640016; Thu, 29 Oct 2015 05:01:30 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 4856F4000E; Thu, 29 Oct 2015 05:01:29 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 29 Oct 2015 05:01:29 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Stephen Farrell Cc: denis bider , ietf-ssh@netbsd.org Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm References: <1107500596-2928@skroderider.denisbider.com> <5630D321.2000301@cs.tcd.ie> Date: Thu, 29 Oct 2015 05:01:28 +0100 In-Reply-To: <5630D321.2000301@cs.tcd.ie> (Stephen Farrell's message of "Wed, 28 Oct 2015 13:52:33 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Stephen Farrell writes: > For example, in discussion of signature schemes based on > new curves, CFRG recently preferred deterministic signatures, A standard (including test vectors) on how to do deterministic DSA would be nice. But independent of the ssh protocol. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 28 23:47:01 2015 Return-Path: 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 B70E31A88D3 for ; Wed, 28 Oct 2015 23:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yuJCTi9z6--9 for ; Wed, 28 Oct 2015 23:47:00 -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 C45221A88D2 for ; Wed, 28 Oct 2015 23:47:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 712BE14A27A; Thu, 29 Oct 2015 06:46:59 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 1580114A266; Thu, 29 Oct 2015 06:46:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B581F14A28D for ; Wed, 28 Oct 2015 20:38:50 +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 w5uLcHUor6hv for ; Wed, 28 Oct 2015 20:38:50 +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 4389A14A26E for ; Wed, 28 Oct 2015 20:38:50 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Wed, 28 Oct 2015 20:38:43 +0000 Date: Wed, 28 Oct 2015 20:38:43 +0000 Subject: Re: 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: <1187939657-352@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: jon@siliconcircus.com, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, mdb@juniper.net Content-Type: multipart/alternative; boundary="=-JXdachghc5Y+TiYJmmi7" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-JXdachghc5Y+TiYJmmi7 Content-Type: text/plain; charset="utf-8" Thanks to everyone for your feedback! I will draft an RFC proposal for dsa-sha2-256, using FIPS 186-4 as reference. It is in fact my past experience with the IETF process that I find discouraging. :) However, I agree it's the right next step. I'll post when I have a draft ready. denis --=-JXdachghc5Y+TiYJmmi7 Content-Type: text/html; charset="utf-8" Thanks to everyone for your feedback!

I will draft an RFC proposal for dsa-sha2-256, using FIPS 186-4 as reference.

It is in fact my past experience with the IETF process that I find discouraging. :)

However, I agree it's the right next step. I'll post when I have a draft ready.

denis

--=-JXdachghc5Y+TiYJmmi7-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 28 23:50:07 2015 Return-Path: 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 7F6FF1A891B for ; Wed, 28 Oct 2015 23:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uCJHcPDgt9lz for ; Wed, 28 Oct 2015 23:50:06 -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 F0D051A891F for ; Wed, 28 Oct 2015 23:50:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 8717C14A32F; Thu, 29 Oct 2015 06:50:05 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 257D114A32D; Thu, 29 Oct 2015 06:50:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6F25114A2CB for ; Thu, 29 Oct 2015 00:35:29 +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 A1u1cfR6T7pH for ; Thu, 29 Oct 2015 00:35:28 +0000 (UTC) Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 7CE7114A2C3 for ; Thu, 29 Oct 2015 00:35:27 +0000 (UTC) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp01.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[128.2.193.239]"; client-ip=128.2.193.239 Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id t9SLVv7l023450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 28 Oct 2015 17:31:58 -0400 (EDT) Message-ID: <1446067917.23356.67.camel@MINBAR.FAC.CS.CMU.EDU> Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm From: Jeffrey Hutzelman To: denis bider Cc: jhutz@cmu.edu, ietf-ssh@NetBSD.org Date: Wed, 28 Oct 2015 17:31:57 -0400 In-Reply-To: <1107500596-2928@skroderider.denisbider.com> References: <1107500596-2928@skroderider.denisbider.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 2015-10-27 at 22:50 +0000, denis bider wrote: > I choose the name "dsa-sha2-256", rather than a suffixed name > ("...@bitvise.com") for the following reasons: Please don't do that, unless you are going to write and publish an IETF consensus RFC and register the name properly. Just making up names leads to collisions and resulting interop problems, which is a very real possibility if someone else is thinking the same as you but isn't active on this list. Also, with no registration, someone seeing this and wanting to interoperate has no idea where to look for a specification. > - Suffixed names are overly long and clumsy. If I were to choose a > suffixed name instead, I would go with just "...@bv". Please don't do that either. Besides being non-compliant, it again leaves anyone wanting to interoperate with no idea how to find a spec. > - 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. Yes, that's an issue, if the thing actually gets standardized. The right answer is to keep using the original name, rather than inventing a new one, unless the algorithm has actually changed during the standardization process. > - 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. Well, someone could decide to implement only one of the two modulus sizes available with 256-bit subgroups. Or, they could decide that all four options are permissible, as long as the hash is SHA-256. I think it would be desirable to publish an RFC to nail these sorts of things down. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 28 23:52:45 2015 Return-Path: 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 EE8F91A892A for ; Wed, 28 Oct 2015 23:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UhJWHRSBCNV6 for ; Wed, 28 Oct 2015 23:52:44 -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 1BD3E1A8925 for ; Wed, 28 Oct 2015 23:52:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 648AD14A10F; Thu, 29 Oct 2015 06:52:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0C1B814A0D8; Thu, 29 Oct 2015 06:52:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E639514A2B9 for ; Thu, 29 Oct 2015 00:25:40 +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 6rvGU5_ojhi3 for ; Thu, 29 Oct 2015 00:25:40 +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 13E6C14A1E5 for ; Thu, 29 Oct 2015 00:25:40 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@NetBSD.org; Thu, 29 Oct 2015 00:25:37 +0000 Date: Thu, 29 Oct 2015 00:25:37 +0000 Subject: Re: 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: <1201220755-2044@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@NetBSD.org Cc: nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, mdb@juniper.net, jon@siliconcircus.com, jhutz@cmu.edu Content-Type: multipart/alternative; boundary="=-1M2lNzsRwe/dfLmw2fBa" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-1M2lNzsRwe/dfLmw2fBa Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have whipped up a draft here: http://www.denisbider.com/draft-dsa-sha2-256.txt At this point, I'm most uncertain about whether we should allow the followi= ng option also: =C2=A0=C2=A0 L =3D 2048, N =3D 224 Arguments for: - No apparent interoperability reason to exclude it. - Perhaps there are DSA implementations that don't easily support setting s= ubgroup size, and can only easily generate the N=3D224 option? Does anyone = know of one? Arguments against: - Slightly weaker than N =3D 256 Any comments? Thoughts? =C2=A0 ----- Original Message ----- From: Jeffrey Hutzelman Sent: Wednesday, Oct= ober 28, 2015 15:31 To: denis bider Cc: jhutz@cmu.edu ; ietf-ssh@NetBSD.or= g Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key al= gorithm =C2=A0 On Tue, 2015-10-27 at 22:50 +0000, denis bider wrote: > I ch= oose the name "dsa-sha2-256", rather than a suffixed name > ("...@bitvise.c= om") for the following reasons: =C2=A0 Please don't do that, unless you are= going to write and publish an IETF consensus RFC and register the name pr= operly.=C2=A0 Just making up names leads to collisions and resulting intero= p problems, which is a very real possibility if someone else is thinking t= he same as you but isn't active on this list. =C2=A0 Also, with no registr= ation, someone seeing this and wanting to interoperate has no idea where to= look for a specification. =C2=A0 =C2=A0 > - Suffixed names are overly long= and clumsy. If I were to choose a > suffixed name instead, I would go wit= h just "...@bv". =C2=A0 Please don't do that either.=C2=A0 Besides being no= n-compliant, it again leaves anyone wanting to interoperate with no idea ho= w to find a spec. =C2=A0 =C2=A0 =C2=A0 > - Suffixed names complicate stand= ardization. If a suffixed algorithm is > commonly implemented, there's pre= ssure to have a version with a > non-suffixed name, and now we have multipl= e names for the same thing. =C2=A0 Yes, that's an issue, if the thing actu= ally gets standardized.=C2=A0 The right answer is to keep using the origina= l name, rather than inventing a new one, unless the algorithm has actually= changed during the standardization process. =C2=A0 =C2=A0 =C2=A0 > - I don= 't see many ways for "dsa-sha2-256" to be implemented > incorrectly or inco= mpatibly by a reasonable implementor. There's really > only one DSA, the o= ne specified in FIPS 186. This has four variants. > The suffix -sha2-256 e= xplicitly specifies which hash function to use, > and strongly suggests us= e of the 256-bit subgroup sizes. =C2=A0 Well, someone could decide to imple= ment only one of the two modulus sizes available with 256-bit subgroups.=C2= =A0 Or, they could decide that all four options are permissible, as long a= s the hash is SHA-256.=C2=A0 I think it would be desirable to publish an R= FC to nail these sorts of things down. =C2=A0 -- Jeff = --=-1M2lNzsRwe/dfLmw2fBa Content-Type: text/html; charset="utf-8"
I have whipped up a draft here:

http://www.denisbider.com/draft-dsa-sha2-256.txt

At this point, I'm most uncertain about whether we should allow the following option also:

   L = 2048, N = 224

Arguments for:

- No apparent interoperability reason to exclude it.
- Perhaps there are DSA implementations that don't easily support setting subgroup size, and can only easily generate the N=224 option? Does anyone know of one?

Arguments against:

- Slightly weaker than N = 256

Any comments? Thoughts?

 
----- Original Message -----
From: Jeffrey Hutzelman
Sent: Wednesday, October 28, 2015 15:31
To: denis bider
Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm
 
On Tue, 2015-10-27 at 22:50 +0000, denis bider wrote:
> I choose the name "dsa-sha2-256", rather than a suffixed name
> ("...@bitvise.com") for the following reasons:
 
Please don't do that, unless you are going to write and publish an IETF
consensus RFC and register the name properly.  Just making up names
leads to collisions and resulting interop problems, which is a very real
possibility if someone else is thinking the same as you but isn't active
on this list.
 
Also, with no registration, someone seeing this and wanting to
interoperate has no idea where to look for a specification.
 
 
> - Suffixed names are overly long and clumsy. If I were to choose a
> suffixed name instead, I would go with just "...@bv".
 
Please don't do that either.  Besides being non-compliant, it again
leaves anyone wanting to interoperate with no idea how to find a spec.
 
 
 
> - 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.
 
Yes, that's an issue, if the thing actually gets standardized.  The
right answer is to keep using the original name, rather than inventing a
new one, unless the algorithm has actually changed during the
standardization process.
 
 
 
> - 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.
 
Well, someone could decide to implement only one of the two modulus
sizes available with 256-bit subgroups.  Or, they could decide that all
four options are permissible, as long as the hash is SHA-256.  I think
it would be desirable to publish an RFC to nail these sorts of things
down.
 
-- Jeff

--=-1M2lNzsRwe/dfLmw2fBa-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Oct 28 23:52:56 2015 Return-Path: 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 D5EC11A892E for ; Wed, 28 Oct 2015 23:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 1478gSEVL0gh for ; Wed, 28 Oct 2015 23:52:54 -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 CC0C71A8925 for ; Wed, 28 Oct 2015 23:52:54 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5746914A331; Thu, 29 Oct 2015 06:52:54 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id DD69C14A330; Thu, 29 Oct 2015 06:52:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 07FE514A21A for ; Wed, 28 Oct 2015 10:10:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=siliconcircus_com.20150623.gappssmtp.com 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 8WQANSsFcJ7E for ; Wed, 28 Oct 2015 10:10:29 +0000 (UTC) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B1AB014A213 for ; Wed, 28 Oct 2015 10:10:29 +0000 (UTC) Received: by ykdr3 with SMTP id r3so2344392ykd.1 for ; Wed, 28 Oct 2015 03:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siliconcircus_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i4dxEeCHphbPlTrR64KqZRdPVDBgcqkruP1ofuWFjvM=; b=Tk5eNts/jsShKB22qjL9abx25C1AexDEDZhnXC+Gw7iyukYHTtE3I7QBF81BBxAx1a goMDjg1BXmqeTI8HNmiHuDVdPtNewTrncHlJj4sySIyLsJKS2Lz5j77rLn7PojM74CLE qge6Vv+XKkseQI6xFXh9z1nTzGIUxR+hA5LtFIq/PCiH2tK5Sjfj5O60qhT9xibEINHQ GtjtoSNqFtvdvRLJ9WzHgwkMN3trPIC9GJEgkGu6IR5YLMuaEPtRJagPeVk/MdTfPhFr HUDFPuPSWgXGyvApYra5zs5OJclzeBe/zn/QT8MRF9biQKJ+l+CwC+fL09MRHQHxNEL1 mupQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i4dxEeCHphbPlTrR64KqZRdPVDBgcqkruP1ofuWFjvM=; b=fi3H3qFfhxyUw7/7UNtLBdveDTJD1h3LPR9l9J72+QdZKSW9qQ6q8pULsHXX6QMiF8 gNtVVZQrkLn0drjq/XXjEbXprRV+B6hpX6d1O98WAruM5OYzFKInRbH4T/7os4B3z7kX mvZHRFigQ5pP2dBsQLV3wB2pmwHz63FIkhrCKQ5fuDDAAH59BrgZYVM3xhcJ5u6xfBVe rFgDL5j8l5wRgT6i4YwlR5t0iMEajPDOmHTDD1T6/bFCHNV57FJMnG4aC45n+qJPRsTK YjQDwMhcKVcvg8oNCyY4zs7vm6/DQY+uQAKYCATDSBtE0EWe9j23OvGNdaKU6CdiJFJN KSCQ== X-Gm-Message-State: ALoCoQlF5Eixt7iAOlKGlzXkie2QnEnSVAD7PYSw6lMlvDFpeACI4wEVbtAVxpyNr1fkBpCZBydX MIME-Version: 1.0 X-Received: by 10.13.207.134 with SMTP id r128mr33645639ywd.170.1446027028470; Wed, 28 Oct 2015 03:10:28 -0700 (PDT) Received: by 10.37.119.205 with HTTP; Wed, 28 Oct 2015 03:10:28 -0700 (PDT) In-Reply-To: <1107500596-2928@skroderider.denisbider.com> References: <1107500596-2928@skroderider.denisbider.com> Date: Wed, 28 Oct 2015 11:10:28 +0100 Message-ID: Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm From: Jon Bright To: denis bider Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary=001a114e4dd05e57980523276758 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --001a114e4dd05e57980523276758 Content-Type: text/plain; charset=UTF-8 The algorithm/idea itself sounds reasonable, but why not write this up as a short RFC and get IANA to actually assign the name? On 27 October 2015 at 23:50, denis bider wrote: > 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. > > --001a114e4dd05e57980523276758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The algorithm/idea itself sounds reasonable, but why not w= rite this up as a short RFC and get IANA to actually assign the name?
=

On 27 October 201= 5 at 23:50, denis bider <ietf-ssh3@denisbider.com> wr= ote:
Hey everyone,

so, over t= he 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=20 configuration, which is reasonable, given that this algorithm is now only u= seful for 1024-bit DSA.

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

Still, I think it&#= 39;s a pity for larger DSA keys to never have had a chance; but more than s= entimentalism, I think we're losing out on heterogeneity and backup opt= ions in case something, anything, turns out to be wrong in Elliptic Curve t= erritory.

Now, if we want to agree on some way to implement large DS= A keys, the "ssh-dss" algorithm name is tainted for use with larg= er key sizes, because there are implementations out there that implement th= em 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-b= it 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 imple= mentations of larger DSA keys, such as Windows CNG, support the larger DSA = keys in conjunction with SHA-2.

- A majority of other "ssh-dss&= quot; 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 sugges= t a new SSH key algorithm, dsa-sha2-256, which cherry-picks from FIPS 186-3= the following two options:

L =3D 2048, N =3D 256
L =3D 3072, N = =3D 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 ("...@<= a href=3D"http://bitvise.com" target=3D"_blank">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 suffixe= d 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 thin= g.

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

Unless some= one has a strong and reasonable objection, I intend to=20 implement this for Bitvise SSH Client and Server 7.xx as described above.
Comments welcome.


--001a114e4dd05e57980523276758-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Oct 29 23:53:42 2015 Return-Path: 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 336151B37E2 for ; Thu, 29 Oct 2015 23:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Pwk_g4S4yrrS for ; Thu, 29 Oct 2015 23:53: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 B71BA1B37E1 for ; Thu, 29 Oct 2015 23:53:40 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4C1F114A2CF; Fri, 30 Oct 2015 06:53:37 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9966614A2C6 for ; Fri, 30 Oct 2015 06:53:33 +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 p9ZJeyVk0i4A for ; Fri, 30 Oct 2015 06:53:33 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::706]) by mail.netbsd.org (Postfix) with ESMTP id 6F8FB14A2C0 for ; Fri, 30 Oct 2015 06:53:31 +0000 (UTC) Received: from BLUPR05CA0043.namprd05.prod.outlook.com (10.141.20.13) by BY1PR0501MB1383.namprd05.prod.outlook.com (10.160.107.141) with Microsoft SMTP Server (TLS) id 15.1.312.18; Fri, 30 Oct 2015 06:53:28 +0000 Received: from BL2FFO11FD055.protection.gbl (2a01:111:f400:7c09::103) by BLUPR05CA0043.outlook.office365.com (2a01:111:e400:855::13) with Microsoft SMTP Server (TLS) id 15.1.312.18 via Frontend Transport; Fri, 30 Oct 2015 06:53:28 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; denisbider.com; dkim=none (message not signed) header.d=none;denisbider.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD055.mail.protection.outlook.com (10.173.161.183) with Microsoft SMTP Server (TLS) id 15.1.318.9 via Frontend Transport; Fri, 30 Oct 2015 06:53:26 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 29 Oct 2015 23:53:25 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t9U6rMD60096; Thu, 29 Oct 2015 23:53:22 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 33E551148B; Thu, 29 Oct 2015 23:53:22 -0700 (PDT) To: denis bider CC: , , , , Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm In-Reply-To: <1297540000-2044@skroderider.denisbider.com> References: <1297540000-2044@skroderider.denisbider.com> Comments: In-reply-to: denis bider message dated "Fri, 30 Oct 2015 03:03:55 -0000." From: "Mark D. Baushke" Date: Thu, 29 Oct 2015 23:53:22 -0700 Message-ID: <51845.1446188002@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD055;1:iIFhrY4/FrOzbVL0NpRJXzQh5pAl+rpeGT3SBeShqTEjaFGdMZd1CCix6t9fbn16iolULMAo5ENVIf8lbIK7FdVRm56BuLsYw7gjc1Q5gOdbaTqEaTxw6nrSNHZo76tPb8y4x9Y23UBREGNFf8yHNTlv7BNDAw0sfXe8lKD4II+O9W56Y4+/wrtDTnWil9P7TWB3uWWsAeF1JC/6+rxGE8EcKqFGkgOp6n8eKRFaIfPnHQGGYoA7soPtJLNdE1nSkkF+NklJ0arLKrvYJT3gcGjyN1g/nEPqX0jxBjbOe9Kp3+cM78cwXO0wP4cnqQtsDN9MGGTn9R/5U9BYmt5IBoABohsGSv29yKCIUY2sHsY= X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(189002)(47776003)(5003940100001)(50466002)(87936001)(92566002)(117636001)(48376002)(76506005)(81156007)(76176999)(54356999)(50986999)(11100500001)(97736004)(6806005)(77096005)(2950100001)(86362001)(15975445007)(106466001)(53416004)(5007970100001)(230783001)(69596002)(110136002)(5003600100002)(105596002)(5001960100002)(19580395003)(189998001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR0501MB1383;H:p-emfe01b-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1383;2:aLlKJQ69woxxxGReXdV/n/vG65kqvMa6gYI+HP5xWLaNVmbdiMH9m/F26XCiOVwiF3yd6d0leIkRqziquvjVyHpGhdfa1V9CO/dMDqjWASjDQAbizSo0GbMsoDBFWy5t4/2b2zno6rTw1kk2vhtWwS9bGO2hPKWOMYJmFZwXErc=;3:A2rpv8FYCpBEMTyqmAIKtOl7Ri6kU1zNfIX6KKdQMylQc2nIrjt0nRHwucUndGvbQJIUaQw+a1+tUA4usqqM3KOYh2Ae8qu232GcL5at8WSw/727YP3JGdACUqoHTuJ2aqalUig62PREFs+3zd4NAJzciysYT9pbrwNvaDFU/DgwxLPKbx94wme2YDXSwumtUzTshx+P9n30uK03QKI20RHNittxAIa9upgS3QLN6dM=;25:aFz7EV5Pd5oDzcNHvfOFbZXMkHI39xzK/cOEtJ9vC74OxXY0HlwlgklfbUBAKECDYAaumv6yqUmM3A9Q9MRBsdltf+21jLcf9AI0TuSEAZx1XhzyEoiaZT88C+PCrdoVJaekfF0FfQtSxiigaguG6qDSP1WWnMYUGl/bnhH3VF57I/8WUuuN61EKP6HmX9fgVN24UwBbWZkyb8SH4z1aGWGL1IztfYKfxJ5gxg+XWKzcJ352SOyqh0JMkxJsyNrwMCg9zugsD+1wrUHmSdZWAA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1383; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1383;20:4ZTD8r9l2rTMCpBGpY76fW0hphPXKjg4B1KpJ/z5M44TB+B2F94J5wU4f2LcnrJ79YZaJpY3bVaJSUvIpo8KMMS1ohjzo2Z9Owy9PXCOuR32Z/o2WE7bRbfF/T2RZqQ1Rcd4RU7d5vKEqJajLvCXV3ZJpcs/AU8B/XwjQcY7xwg0lmeN5tZ6o9s79TEc+78bRV4gwr159PF7f+bCSoFm+U9MornoHR6SHWgwCVEHCmi6Hv1tgwt49afQsR0313+tTiBjzDt6dlKMxPfJovLHLFKSZINZzK3BTEgx7+zbmc+4shxHHyFvX6GKJvLzNXflN2amOShvUclgJ3bKnCa3IaXNnwPmIV6a5DvLbGwv3PnvIPlac8mWDKgyw3CeudMZrX/1/gA3kFL4rZHWXKHRfaBmVnCGm3f52B/+jDX0VzfjZti/UryNIkltw8Vfj4FNahC/+wcYybNwvz1qtW71h3h5fuNbwOSX1b3eJI2kA5PNQNTdaz0/Wq+pCExyX48s;4:ykcl680hgg8BS9od7MvmOd2krRUW8/Sxuoqdlk2WC8Lf8RMbs6H1ieoI1l96Z4CqRfwhuT1GTU+yptzFEHhI4t3oSY13DY/dnamnFUpCEX6XuCzbp3iQVidIMUDePSW96IrQ/rXrPR/pz7aHXi8p3X0QfUkqbME0jdctBf+PMH03x1lqDscHZy/gaiegb5GgBaSczW6TRdEYm58xYwyymMcLWgdNBcB+dqsHJTjRRPHpAjRr7wzvolKcCtfXhF8mNZ88DoT/FCmwcgwr7pz68UR17tK074mK6y/T1VwW9ab071YkjrTCCUF0fpMK9Pq0ZW6OeCEDiVXGNQOzD2V+E1f9xAMFISKIZJ2hbBBfiFPNwBm3GeYfBywq1jDZ1CiZc1K8MCMLJlezXkKTJuiwwQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001)(102215026);SRVR:BY1PR0501MB1383;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1383; X-Forefront-PRVS: 07459438AA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY1PR0501MB1383;23:5pPKPyCYfQUih+srF0A52epLTE0tK+zCJfdYUXx?= =?us-ascii?Q?bTxAgO5jLh6CMFRObkabgGM0q9ZE5cYEqBdgEteHqaLTyFbZwYGp8eLfq+hF?= =?us-ascii?Q?/XyaWTQ6iCxH2pGWt9XTWUzrgl3FRItt+RIkTHlvoeTRsIDrdlYqn4UF4lYz?= =?us-ascii?Q?o8Jv7O6D+h1eNZ9ZNbQjjapqoYPxbVCtpfThXfxtqtyD2BhMScqmD97Px+0Z?= =?us-ascii?Q?NSzmbz4dUo8rUpu4KTDkQZlY/QxEMvfgPLqveitcONxET+BrpByj70CsWWLl?= =?us-ascii?Q?sGDw8YJmwqEWrSN/3Rk4N7XczB70sKSdL3q0P+e5c8x/8AW63xsZEnbhxcr6?= =?us-ascii?Q?jV6F3E749U7KmbM4NYcfxCAUdYn0I2FV8jl3dORcmpd/nZk2euChyag6iQ0I?= =?us-ascii?Q?acNeidgedH2uGCbGe7mj2lgh4mKLiJV7M+M08uPh8EdXkBPKtaVi/vtj/u2T?= =?us-ascii?Q?x4okafZUjGCGTnla/MCceJnvjZDSDt7E4sJpYdnD4CqzuiT4JKCYVI/JYqqr?= =?us-ascii?Q?HFT2ewLPXT2jIQB+sPVsB7PNjnUVK1Jd++NxHJIL/qmZ3Jz9h7T9effPJ/8i?= =?us-ascii?Q?zf+Mpw87g0Q3fy6x2a4WRI1CBjpaYd8CyT8LaLmZ4WLiZSv+RcsQ2s1rARSQ?= =?us-ascii?Q?ITOBBuBbwfUjATGtGxtMVBFk1wqxM4FxbLO0himlGFwAc4+gZRwEDsfsh6Fx?= =?us-ascii?Q?+fBHWoB4cE47z5ZgQ8JLIvUqh+X0cSuUdbT1pwW7bve0+jQdUBL8K+9jaXck?= =?us-ascii?Q?7JWPWXUJrDKee/hQqq26+FrvIaF+XXzYW7ZGVB4zDWFDaKMw5pHZMSu3tEDM?= =?us-ascii?Q?Y6mAGNVfR+UejCLTKbTajlqYw92i/2iuN5QnBi6/fKGP5SMkoU3ao5YzKZt+?= =?us-ascii?Q?tY9GfU+clqaag5gA07F90lfWfwgWhoXg71WYSb+zr2n1KBOmgtWcLO686s3h?= =?us-ascii?Q?BzuQ9uQ3cdIORXM6+oMgFZ5HzXI/o1gzzLKGENItoAA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1383;5:7cxB++J0QaF4rOQjrT/1NwCdGF43bX0nI31Ph0DblkWzcsRRoLlkiyRxiQdVk7pgN8hgl2Cl538IgfRss/UzK/dKw1rG7ZwindBwZ9JTs1avk5h8ysYFGv0MNGB5Vu6qap+wSMstN+0rXUGUfZQJLA==;24:cpe5gLXgHLcJGQOGAJ3GvkJtZl2+fK6fdoy2wrz639ZNvMnUDqWQFZ8eoS6iXRFTJUtXDeNPoLyQELfvMD+2n74AA5++sCqczBy6/My6owk=;20:FlwK8ernahRaqHACU8K9exAHRx4g4e6ERTOYszOPrUvoGJuo7n24SsDdStKhCmmoDf/6QokzMmbQ6jDRWqhJoA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2015 06:53:26.5560 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1383 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi denis, Should this Draft RFC also be the one that moves the "ssh-dss" public key algorithm from a "REQUIRED" and "MUST" implement algorithm to an "OPTIONAL" and "SHOULD NOT" implement algorithm? As things stand right now with RFC4253, the only REQUIRED algorithm is "ssh-dss" and I do not believe that it is a good idea to leave it in that state. Or, is this better left to another RFC? Perhaps moving the Ed25519 algorithm created by https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 into a MUST algorithm while deprecating "ssh-dss" for SSH? Curious, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Oct 30 01:10:22 2015 Return-Path: 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 AFD441A1C00 for ; Fri, 30 Oct 2015 01:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4TAFmR8uWaf4 for ; Fri, 30 Oct 2015 01:10:17 -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 9D3481B3881 for ; Fri, 30 Oct 2015 01:10:17 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B2B6C14A235; Fri, 30 Oct 2015 08:10:14 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 550DB14A22C; Fri, 30 Oct 2015 08:10:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6260D14A245 for ; Thu, 29 Oct 2015 15:25:57 +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 PMsN69tkbhRw for ; Thu, 29 Oct 2015 15:25:56 +0000 (UTC) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id BE50114A23A for ; Thu, 29 Oct 2015 15:25:54 +0000 (UTC) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp03.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[192.168.1.235]"; client-ip=184.195.119.228 Received: from [192.168.1.235] (184-195-119-228.pools.spcsdns.net [184.195.119.228] (may be forged)) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id t9TDYTOm019239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 29 Oct 2015 09:34:32 -0400 (EDT) Message-ID: <1446125668.10319.22.camel@destiny.pc.cs.cmu.edu> Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm From: Jeffrey Hutzelman To: denis bider Cc: jhutz@cmu.edu, ietf-ssh@NetBSD.org, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, mdb@juniper.net, jon@siliconcircus.com Date: Thu, 29 Oct 2015 09:34:28 -0400 In-Reply-To: <1201220755-2044@skroderider.denisbider.com> References: <1201220755-2044@skroderider.denisbider.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, 2015-10-29 at 00:25 +0000, denis bider wrote: > I have whipped up a draft here: > > http://www.denisbider.com/draft-dsa-sha2-256.txt Not too bad. A few comments, all minor: - The use of SHA-256 is a departure from the original ssh-dss algorithm, which specifies SHA-1. Even though it's fairly obvious from the algorithm name, I think that should be mentioned in the abstract and introduction. It might be appropriate to work it into the title, too, since that's all that appears in the RFC index, but IMHO that's less important. - The reference to FIPS-186-3 in the introduction seems superfluous. - NIST SP 800-131A doesn't "suggest" or "consider" that 1024-bit DSA and SHA-1 are disallowed after 2013. It disallows them for government use(*). I suggest an edit something like this... OLD: The National Institute of Standards and Technology (NIST) Special Publication 800-131A [800-131A] suggests that DSA keys shorter than 2048 bits, and with subgroup sizes under 224 bits, are considered to have an encryption strength of less than 112 bits, and are disallowed after 2013. DSA key sizes of 2048 bits or more, and with subgroup sizes of 224 bits or more, are considered acceptable. NEW: National Institute of Standards and Technology (NIST) Special Publication 800-131A [800-131A] suggests that DSA keys shorter than 2048 bits, and with subgroup sizes under 224 bits, are considered to have an encryption strength of less than 112 bits. It disallows use of such keys for U.S. Government use after 2013. DSA key sizes of 2048 bits or more, and with subgroup sizes of 224 bits or more, are considered acceptable. Similarly for the next paragraph. > At this point, I'm most uncertain about whether we should allow the following option also: > > L = 2048, N = 224 > > Arguments for: > > - No apparent interoperability reason to exclude it. > - Perhaps there are DSA implementations that don't easily support > setting subgroup size, and can only easily generate the N=224 option? > Does anyone know of one? > > Arguments against: > > - Slightly weaker than N = 256 > > Any comments? Thoughts? If you don't include it, then either implementors will support it anyway, or users will be confused when their keys don't work. I assume that with N=224, you'd want to actually use SHA-224. For that matter, what about _larger_ key sizes? What's to say that NIST won't publish FIPS-186-5 with an (L=4096, N=512) option. You'd want to use SHA-512 with that, but wouldn't it be better not to constrain this to the key sizes that are available today? I'd suggest allowing arbitrary key sizes with L >= 2048 and N >= 224, with the hash to be the largest of SHA-{224,256,384,512} that produces a digest not larger than N bits. -- Jeff (*) Or rather, it disallows use of all digital signature algorithms with strength less than 112 bits. While specific parameters are mentioned for RSA and DSA, formally the strengths are defined in SP 800-57. Hpwever, I think we can ignore the latter detail for our purpose. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Oct 30 01:11:27 2015 Return-Path: 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 2F8551A9235 for ; Fri, 30 Oct 2015 01:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RtrSudKgpEP8 for ; Fri, 30 Oct 2015 01:11:24 -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 137431B2D21 for ; Fri, 30 Oct 2015 01:11:23 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2CB9814A2E5; Fri, 30 Oct 2015 08:11:22 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C4C1D14A2E3; Fri, 30 Oct 2015 08:11:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2F96F14A27A for ; Fri, 30 Oct 2015 03:03:58 +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 L40gbXDAnolD for ; Fri, 30 Oct 2015 03:03:56 +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 5343F14A285 for ; Fri, 30 Oct 2015 03:03:56 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@NetBSD.org; Fri, 30 Oct 2015 03:03:55 +0000 Date: Fri, 30 Oct 2015 03:03:55 +0000 Subject: Re: 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: <1297540000-2044@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@NetBSD.org Cc: jhutz@cmu.edu, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, mdb@juniper.net, jon@siliconcircus.com Content-Type: multipart/alternative; boundary="=-8DsCxxIHHNmwtjz7k3Qy" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-8DsCxxIHHNmwtjz7k3Qy Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Jeffrey, thank you for your comments. :-) I have updated the draft based on this feedback. Same URL - new version: http://www.denisbider.com/draft-dsa-sha2-256.txt > Even though it's fairly obvious from the algorithm name, > I think that should be mentioned in the abstract and > introduction.=C2=A0 It might be appropriate to work it into > the title, too Done so. > The reference to FIPS-186-3 in the introduction seems > superfluous. Removed. > NIST SP 800-131A doesn't "suggest" or "consider" that > 1024-bit DSA and SHA-1 are disallowed after 2013. > It disallows them for government use(*). Updated. > If you don't include it, then either implementors will > support it anyway, or users will be confused when their > keys don't work. I've done some testing, and found that Windows CNG cannot import an L=3D204= 8, N=3D224 private key generated with Crypto++. In the interest of interoperability, I think it's better to prohibit this o= ption. I have added language to this effect. > I assume that with N=3D224, you'd want to actually use SHA-224. It may be interesting to note that Windows built-in crypto - a major, FIPS-= certified platform - does not support SHA-224 at all. With DSA, or standalo= ne. > For that matter, what about _larger_ key sizes? > What's to say that NIST won't publish FIPS-186-5 > with an (L=3D4096, N=3D512) option. =C2=A0 Allowing for such keys to be used with the same algorithm name would break = interoperability with applications unaware of such a new standard. I have added a section further emphasizing that any departure from the spec= ified options and key sizes requires a different algorithm name. denis ----- Original Message ----- From: Jeffrey Hutzelman=20 Sent: Thursday, October 29, 2015 07:34 To: denis bider=20 Cc: jhutz@cmu.edu ; ietf-ssh@NetBSD.org ; nisse@lysator.liu.se ; stephen.fa= rrell@cs.tcd.ie ; mdb@juniper.net ; jon@siliconcircus.com=20 Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algori= thm On Thu, 2015-10-29 at 00:25 +0000, denis bider wrote: > I have whipped up a draft here: >=20 > http://www.denisbider.com/draft-dsa-sha2-256.txt Not too bad.=C2=A0 A few comments, all minor: - The use of SHA-256 is a departure from the original ssh-dss algorithm, which =C2=A0 specifies SHA-1.=C2=A0 Even though it's fairly obvious from the algo= rithm name, I =C2=A0 think that should be mentioned in the abstract and introduction.=C2= =A0 It might be =C2=A0 appropriate to work it into the title, too, since that's all that appears in =C2=A0 the RFC index, but IMHO that's less important. - The reference to FIPS-186-3 in the introduction seems superfluous. - NIST SP 800-131A doesn't "suggest" or "consider" that 1024-bit DSA and SHA-1 =C2=A0 are disallowed after 2013.=C2=A0 It disallows them for government us= e(*). =C2=A0 I suggest an edit something like this... OLD: =C2=A0=C2=A0 The National Institute of Standards and Technology (NIST) Spec= ial =C2=A0=C2=A0 Publication 800-131A [800-131A] suggests that DSA keys shorter= than =C2=A0=C2=A0 2048 bits, and with subgroup sizes under 224 bits, are conside= red =C2=A0=C2=A0 to have an encryption strength of less than 112 bits, and are =C2=A0=C2=A0 disallowed after 2013. DSA key sizes of 2048 bits or more, and= with =C2=A0=C2=A0 subgroup sizes of 224 bits or more, are considered acceptable. NEW: =C2=A0=C2=A0 National Institute of Standards and Technology (NIST) Special =C2=A0=C2=A0 Publication 800-131A [800-131A] suggests that DSA keys shorter= than =C2=A0=C2=A0 2048 bits, and with subgroup sizes under 224 bits, are conside= red =C2=A0=C2=A0 to have an encryption strength of less than 112 bits.=C2=A0 It= disallows =C2=A0=C2=A0 use of such keys for U.S. Government use after 2013. DSA key s= izes =C2=A0=C2=A0 of 2048 bits or more, and with subgroup sizes of 224 bits or m= ore, =C2=A0=C2=A0 are considered acceptable. Similarly for the next paragraph. > At this point, I'm most uncertain about whether we should allow the follo= wing option also: >=20 >=C2=A0=C2=A0=C2=A0 L =3D 2048, N =3D 224 >=20 > Arguments for: >=20 > - No apparent interoperability reason to exclude it. > - Perhaps there are DSA implementations that don't easily support > setting subgroup size, and can only easily generate the N=3D224 option? > Does anyone know of one? >=20 > Arguments against: >=20 > - Slightly weaker than N =3D 256 >=20 > Any comments? Thoughts? If you don't include it, then either implementors will support it anyway, or users will be confused when their keys don't work.=C2=A0 I assum= e that with N=3D224, you'd want to actually use SHA-224. For that matter, what about _larger_ key sizes?=C2=A0 What's to say that NI= ST won't publish FIPS-186-5 with an (L=3D4096, N=3D512) option.=C2=A0 You'd wa= nt to use SHA-512 with that, but wouldn't it be better not to constrain this to the key sizes that are available today? I'd suggest allowing arbitrary key sizes with L >=3D 2048 and N >=3D 224, with the hash to be the largest of SHA-{224,256,384,512} that produces a digest not larger than N bits. -- Jeff (*)=C2=A0 Or rather, it disallows use of all digital signature algorithms with strength less than 112 bits.=C2=A0 While specific parameters are mentioned for RSA and DSA, formally the strengths are defined in SP 800-57.=C2=A0 Hpwever, I think we can ignore the latter detail for our purpose. = --=-8DsCxxIHHNmwtjz7k3Qy Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Jeffrey,

thank you for your comments. := -)

I have updated the draft based on this feedback. Same URL - new v= ersion:

http://www.denisbider.com/draft-dsa-sha2-256.txt


= > Even though it's fairly obvious from the algorithm name,
> I thi= nk that should be mentioned in the abstract and
> introduction. = It might be appropriate to work it into
> the title, too

Done= so.


> The reference to FIPS-186-3 in the introduction seems<= br>> superfluous.

Removed.


> NIST SP 800-131A doesn= 't "suggest" or "consider" that
> 1024-bit DSA and SHA-1 are disallow= ed after 2013.
> It disallows them for government use(*).

Upda= ted.


> If you don't include it, then either implementors will=
> support it anyway, or users will be confused when their
> ke= ys don't work.

I've done some testing, and found that Windows CNG ca= nnot import an L=3D2048, N=3D224 private key generated with Crypto++.
In the interest of interoperability, I think it's better to prohibit this= option. I have added language to this effect.


> I assume tha= t with N=3D224, you'd want to actually use SHA-224.

It may be intere= sting to note that Windows built-in crypto - a major, FIPS-certified platfo= rm - does not support SHA-224 at all. With DSA, or standalone.


&= gt; For that matter, what about _larger_ key sizes?
> What's to say t= hat NIST won't publish FIPS-186-5
> with an (L=3D4096, N=3D512) optio= n.  

Allowing for such keys to be used with the same algorithm = name would break interoperability with applications unaware of such a new s= tandard.

I have added a section further emphasizing that any departu= re from the specified options and key sizes requires a different algorithm = name.

denis


----- Original Message -----
From: Jeffrey= Hutzelman
Sent: Thursday, October 29, 2015 07:34
To: denis bider Cc: jhutz@cmu.edu ; ietf-ssh@NetBSD.org ; nisse@lysator.liu.se ; stephen.= farrell@cs.tcd.ie ; mdb@juniper.net ; jon@siliconcircus.com
Subject: Re= : Proposal and intent to implement "dsa-sha2-256" SSH key algorithm

= On Thu, 2015-10-29 at 00:25 +0000, denis bider wrote:
> I have whippe= d up a draft here:
>
> http://www.denisbider.com/draft-dsa-sha= 2-256.txt

Not too bad.  A few comments, all minor:

- The= use of SHA-256 is a departure from the original ssh-dss algorithm,
whic= h
  specifies SHA-1.  Even though it's fairly obvious from the= algorithm
name, I
  think that should be mentioned in the abstr= act and introduction.  It
might be
  appropriate to work it= into the title, too, since that's all that
appears in
  the RFC= index, but IMHO that's less important.

- The reference to FIPS-186-= 3 in the introduction seems superfluous.

- NIST SP 800-131A doesn't = "suggest" or "consider" that 1024-bit DSA and
SHA-1
  are disall= owed after 2013.  It disallows them for government use(*).
  I= suggest an edit something like this...

OLD:
   The Nat= ional Institute of Standards and Technology (NIST) Special
   = Publication 800-131A [800-131A] suggests that DSA keys shorter than
&nbs= p;  2048 bits, and with subgroup sizes under 224 bits, are considered<= br>   to have an encryption strength of less than 112 bits, and a= re
   disallowed after 2013. DSA key sizes of 2048 bits or mor= e, and with
   subgroup sizes of 224 bits or more, are conside= red acceptable.

NEW:
   National Institute of Standards= and Technology (NIST) Special
   Publication 800-131A [800-13= 1A] suggests that DSA keys shorter than
   2048 bits, and with= subgroup sizes under 224 bits, are considered
   to have an e= ncryption strength of less than 112 bits.  It disallows
  = ; use of such keys for U.S. Government use after 2013. DSA key sizes
&nb= sp;  of 2048 bits or more, and with subgroup sizes of 224 bits or more= ,
   are considered acceptable.

Similarly for the next = paragraph.



> At this point, I'm most uncertain about whet= her we should allow the following option also:
>
>  =   L =3D 2048, N =3D 224
>
> Arguments for:
>
&g= t; - No apparent interoperability reason to exclude it.
> - Perhaps t= here are DSA implementations that don't easily support
> setting subg= roup size, and can only easily generate the N=3D224 option?
> Does an= yone know of one?
>
> Arguments against:
>
> - Sl= ightly weaker than N =3D 256
>
> Any comments? Thoughts?
If you don't include it, then either implementors will support it
anyw= ay, or users will be confused when their keys don't work.  I assumethat with N=3D224,
you'd want to actually use SHA-224.

For that = matter, what about _larger_ key sizes?  What's to say that NIST
won= 't publish FIPS-186-5 with an (L=3D4096, N=3D512) option.  You'd want = to
use SHA-512 with that, but wouldn't it be better not to constrain thi= s
to the key sizes that are available today?

I'd suggest allowing= arbitrary key sizes with L >=3D 2048 and N >=3D 224,
with the has= h to be the largest of SHA-{224,256,384,512} that produces a
digest not = larger than N bits.

-- Jeff


(*)  Or rather, it disal= lows use of all digital signature algorithms
with strength less than 112= bits.  While specific parameters are
mentioned for RSA and DSA, fo= rmally the strengths are defined in SP
800-57.  Hpwever, I think we= can ignore the latter detail for our
purpose.

= --=-8DsCxxIHHNmwtjz7k3Qy-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Oct 30 14:36:39 2015 Return-Path: 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 149721B3C24 for ; Fri, 30 Oct 2015 14:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 zK6a_fzzcd1B for ; Fri, 30 Oct 2015 14:36:37 -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 D92651A9123 for ; Fri, 30 Oct 2015 14:36:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2C75A14A35B; Fri, 30 Oct 2015 21:36:37 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AC4DB14A354 for ; Fri, 30 Oct 2015 21:36:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 NNs_vcfpAzey for ; Fri, 30 Oct 2015 21:36:34 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id CE96514A34D for ; Fri, 30 Oct 2015 21:36:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 852E9BE5D; Fri, 30 Oct 2015 21:36:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Be5f0V4GKIld; Fri, 30 Oct 2015 21:36:27 +0000 (GMT) Received: from [133.93.100.27] (unknown [133.93.100.27]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E5A6CBE4D; Fri, 30 Oct 2015 21:36:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446240987; bh=d6KZvJBydzTG03FrKEx4rjkeXLzWEZyCTXSbvwOfpDE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=eotZJIjHNiH1hAISUMvl+6rlCBWd7kEm9dvUDLGN4uj18IBYA/oMfuX+wn+EQfEDQ lRfmTFNoQmmQcJujIRSljd9NslijDMcf4NOTpzVNHBaYgos3B9Ubd4gs7ewEG77BLZ Zd7HjRl00o1TFMkhyKGNQGuA6wr8Uuo6gUDDfSjI= Subject: Re: SSH key algorithm updates To: Jeffrey Hutzelman , "Mark D. Baushke" References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> Cc: denis bider , ietf-ssh@NetBSD.org, nisse@lysator.liu.se, jon@siliconcircus.com From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5633E2D5.1020207@cs.tcd.ie> Date: Fri, 30 Oct 2015 21:36:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 30/10/15 18:12, Jeffrey Hutzelman wrote: > Agreed. In fact, we probably should undertake a general updating of > recommended and required crypto algorithms across the protocol. If there's general support for this, then I'd be happy to try shift any annoying IETF bureaucracy out of the way. That could mean forming a short-lived wg or me AD sponsoring a single document if that's all that's needed. I'm happy to help with either approach. Cheers, S. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Oct 30 16:07:56 2015 Return-Path: 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 9EED71B32BF for ; Fri, 30 Oct 2015 16:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 UssYZlq-zn7p for ; Fri, 30 Oct 2015 16:07:55 -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 E76181B32D4 for ; Fri, 30 Oct 2015 16:07:52 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 506E014A369; Fri, 30 Oct 2015 23:07:52 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BDD2714A364 for ; Fri, 30 Oct 2015 23:07:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 StJZ07XF0ESW for ; Fri, 30 Oct 2015 23:07:47 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id BC3B414A362 for ; Fri, 30 Oct 2015 23:07:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 40D3CBE73; Fri, 30 Oct 2015 21:49:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBxBHVVfIE9t; Fri, 30 Oct 2015 21:49:25 +0000 (GMT) Received: from [133.93.100.27] (unknown [133.93.100.27]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7443FBE64; Fri, 30 Oct 2015 21:49:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446241765; bh=F2dTsTrQl0dUIrrj78iEtSx8wpA9BOwSYe/DQngFpUk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=xB50gIoQxOVlf1VRy78oS989IOihQoulYcSFwFg/f4orjgekuoT/SZnu+QR6DIvy6 io6X5nJem7Apyw4JWD7ApqKptrwxQ67anZ6kjYHo2YktvoY6UFO+BmwWAGookhf2/0 YiNqpvtwwbRxcdOcfGd5w07QQpFxnUHoVnjNaUbk= Subject: Re: SSH key algorithm updates To: Jeffrey Hutzelman References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> <5633E2D5.1020207@cs.tcd.ie> <1446241420.32676.14.camel@destiny.pc.cs.cmu.edu> Cc: "Mark D. Baushke" , denis bider , ietf-ssh@NetBSD.org, nisse@lysator.liu.se, jon@siliconcircus.com From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5633E5E0.8000503@cs.tcd.ie> Date: Fri, 30 Oct 2015 21:49:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1446241420.32676.14.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 30/10/15 21:43, Jeffrey Hutzelman wrote: > On Fri, 2015-10-30 at 21:36 +0000, Stephen Farrell wrote: >> >> On 30/10/15 18:12, Jeffrey Hutzelman wrote: >>> Agreed. In fact, we probably should undertake a general updating of >>> recommended and required crypto algorithms across the protocol. >> >> If there's general support for this, then I'd be happy to >> try shift any annoying IETF bureaucracy out of the way. That >> could mean forming a short-lived wg or me AD sponsoring a >> single document if that's all that's needed. I'm happy to >> help with either approach. > > > I imagine that we could do it with an AD-sponsored document and an > extended IETF last call. No need to spin up a WG, I hope. Yeah, if it's just algo updates, that seems right. I guess we should see if folks have another list of things they'd like to do though - if there were then that might justify a wg, but if not, then AD sponsored is much quicker/simpler. > > I admit I haven't been paying attention; what's the plan for SHA3? Not sure there's a general plan. There does seem to be a general disinterest;-) > Should we be thinking about a set of documents to define SHA3-based key > exchange, public key, and MAC algorithms for SSH? Personally, I'm not that keen on defining stuff that might not get widespread use, but that kind of opinion seems to vary from protocol to protocol, and from one set of folks to another. So I'm not sure what folks here think. Deprecating old stuff to the extent we can OTOH, I'm quite keen on that:-) Cheers, S. S. > > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 31 08:51:11 2015 Return-Path: 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 C39661A1BB5 for ; Sat, 31 Oct 2015 08:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WCRklW5JwhPI for ; Sat, 31 Oct 2015 08:51:10 -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 6B59B1A1B71 for ; Sat, 31 Oct 2015 08:51:10 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id BD53D14A204; Sat, 31 Oct 2015 15:51:07 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 605A714A201; Sat, 31 Oct 2015 15:51:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0EA6F14A285 for ; Fri, 30 Oct 2015 18:06:12 +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 uEvtD7qXajEh for ; Fri, 30 Oct 2015 18:06:11 +0000 (UTC) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3CEAC14A253 for ; Fri, 30 Oct 2015 18:06:09 +0000 (UTC) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp03.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[192.168.202.98]"; client-ip=74.109.252.206 Received: from [192.168.202.98] (pool-74-109-252-206.pitbpa.fios.verizon.net [74.109.252.206]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id t9UI5r4k004511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2015 14:05:54 -0400 (EDT) Message-ID: <1446228353.10319.92.camel@destiny.pc.cs.cmu.edu> Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm From: Jeffrey Hutzelman To: denis bider Cc: jhutz@cmu.edu, ietf-ssh@NetBSD.org, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, mdb@juniper.net, jon@siliconcircus.com Date: Fri, 30 Oct 2015 14:05:53 -0400 In-Reply-To: <1297540000-2044@skroderider.denisbider.com> References: <1297540000-2044@skroderider.denisbider.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, 2015-10-30 at 03:03 +0000, denis bider wrote: > Hey Jeffrey, > > thank you for your comments. :-) > > I have updated the draft based on this feedback. Same URL - new version: > > http://www.denisbider.com/draft-dsa-sha2-256.txt Those updates all look good. > > If you don't include it, then either implementors will > > support it anyway, or users will be confused when their > > keys don't work. > > I've done some testing, and found that Windows CNG cannot import an > L=2048, N=224 private key generated with Crypto++. > > In the interest of interoperability, I think it's better to prohibit > this option. I have added language to this effect. > > I assume that with N=224, you'd want to actually use SHA-224. > > It may be interesting to note that Windows built-in crypto - a major, > FIPS-certified platform - does not support SHA-224 at all. With DSA, or > standalone. > > For that matter, what about _larger_ key sizes? > > What's to say that NIST won't publish FIPS-186-5 > > with an (L=4096, N=512) option. > > Allowing for such keys to be used with the same algorithm name would > break interoperability with applications unaware of such a new > standard. I don't understand. The issue with ssh-dss was that we _didn't_ allow for larger key sizes. Well, that and the fact that we specified SHA1, which doesn't provide sufficient security to keep up with larger key sizes(*). So why would it be bad to support larger key sizes with an existing hash that is already big enough? (*) In fact, now that I think about it, we probably should have defined an rsa-sha256 public key algorithm. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 31 08:51:56 2015 Return-Path: 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 1DB871A2119 for ; Sat, 31 Oct 2015 08:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0ID5fo-CS0Z2 for ; Sat, 31 Oct 2015 08:51:55 -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 0E86F1A1F73 for ; Sat, 31 Oct 2015 08:51:55 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id AA76714A20A; Sat, 31 Oct 2015 15:51:54 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 4BF3214A208; Sat, 31 Oct 2015 15:51:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 76AE314A324 for ; Fri, 30 Oct 2015 18:12:40 +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 Ty-IEerfAJ8L for ; Fri, 30 Oct 2015 18:12:39 +0000 (UTC) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id AFA3714A2C0 for ; Fri, 30 Oct 2015 18:12:39 +0000 (UTC) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp03.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[192.168.202.98]"; client-ip=74.109.252.206 Received: from [192.168.202.98] (pool-74-109-252-206.pitbpa.fios.verizon.net [74.109.252.206]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id t9UICRgx004798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2015 14:12:28 -0400 (EDT) Message-ID: <1446228747.32676.0.camel@destiny.pc.cs.cmu.edu> Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm From: Jeffrey Hutzelman To: "Mark D. Baushke" Cc: jhutz@cmu.edu, denis bider , ietf-ssh@NetBSD.org, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com Date: Fri, 30 Oct 2015 14:12:27 -0400 In-Reply-To: <51845.1446188002@eng-mail01.juniper.net> References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, 2015-10-29 at 23:53 -0700, Mark D. Baushke wrote: > Hi denis, > > Should this Draft RFC also be the one that moves the "ssh-dss" public > key algorithm from a "REQUIRED" and "MUST" implement algorithm to > an "OPTIONAL" and "SHOULD NOT" implement algorithm? > > As things stand right now with RFC4253, the only REQUIRED algorithm is > "ssh-dss" and I do not believe that it is a good idea to leave it in > that state. > > Or, is this better left to another RFC? Perhaps moving the Ed25519 > algorithm created by > > https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 > > into a MUST algorithm while deprecating "ssh-dss" for SSH? A good question. I feel like we should be discussing such changes, since the current situation is rather silly. However, it probably belongs in a separate document, if only because reaching consensus on the choice of algorithms may take some time. More on this in another post. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 31 08:55:10 2015 Return-Path: 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 08DE21A6FC8 for ; Sat, 31 Oct 2015 08:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nescs3UzrsMZ for ; Sat, 31 Oct 2015 08:55:07 -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 9C2E41A6FC7 for ; Sat, 31 Oct 2015 08:55:07 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id F37CE14A1A9; Sat, 31 Oct 2015 15:55:06 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9011214A195; Sat, 31 Oct 2015 15:55:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A47B314A324 for ; Fri, 30 Oct 2015 18:12:47 +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 clYmvXykJ8EQ for ; Fri, 30 Oct 2015 18:12:46 +0000 (UTC) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0FA6514A2C0 for ; Fri, 30 Oct 2015 18:12:45 +0000 (UTC) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp03.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[192.168.202.98]"; client-ip=74.109.252.206 Received: from [192.168.202.98] (pool-74-109-252-206.pitbpa.fios.verizon.net [74.109.252.206]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id t9UICXB5004805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2015 14:12:34 -0400 (EDT) Message-ID: <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> Subject: SSH key algorithm updates From: Jeffrey Hutzelman To: "Mark D. Baushke" Cc: jhutz@cmu.edu, denis bider , ietf-ssh@NetBSD.org, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, jon@siliconcircus.com Date: Fri, 30 Oct 2015 14:12:33 -0400 In-Reply-To: <51845.1446188002@eng-mail01.juniper.net> References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> Content-Type: multipart/mixed; boundary="=-lQlvaSQBHXH6+1UIszbV" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-lQlvaSQBHXH6+1UIszbV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2015-10-29 at 23:53 -0700, Mark D. Baushke wrote: > Hi denis, > > Should this Draft RFC also be the one that moves the "ssh-dss" public > key algorithm from a "REQUIRED" and "MUST" implement algorithm to > an "OPTIONAL" and "SHOULD NOT" implement algorithm? > > As things stand right now with RFC4253, the only REQUIRED algorithm is > "ssh-dss" and I do not believe that it is a good idea to leave it in > that state. Agreed. In fact, we probably should undertake a general updating of recommended and required crypto algorithms across the protocol. A number of new algorithms have been defined over time, but none of them is REQUIRED and none of the old ones have been downgraded. My suggestion would be to publish a document which updates RFC4253 with a new set of requirements and recommendations for algorithms. It should include tables listing key exchange, encryption, MAC, and public key algorithms, showing the current state (REQUIRED, RECOMMENDED, OPTIONAL, NOT RECOMMENDED) of each algorithm. I've included below a table showing the current state of all registered algorithms, as far as I've been able to determine, along with some proposals for changes. To summarize the changes, I propose: For public key algorithms: - Downgrade ssh-dss, pgp-sign-dss, and x509v3-ssh-dss to NOT RECOMMENDED. - Upgrade ssh-rsa to REQUIRED - Upgrade ecdsa-sha2-* to RECOMMENDED - Add dsa-sha2-256 as RECOMMENDED Since ssh-rsa has always been RECOMMENDED and is very widely deployed, it not only is a good candidate for upgrade to REQUIRED, but also justifies downgrading ssh-dss directly from REQUIRED to NOT RECOMMENDED. If we're going to downgrade DSS, we should do it across the board. Perhaps Denis wants to add pgp-sign-dsa-sha2-256 and/or x509v3-dsa-sha2-256 to his document. Both larger-key DSA and ECDSA are viable algorithms, and there is some benefit to having multiple algorithms which are widely implemented, since public keys tend to have long lifetimes and be difficult to upgrade if there is a crisis. Thus, I think it's reasonable to list both of these as RECOMMENDED and would probably not object to listing one of them as REQUIRED (in addition to ssh-rsa). For MAC algorithms: - Upgrade hmac-sha2-256 to REQUIRED - Consider upgrading hmac-sha2-512 to RECOMMENDED - Downgrade hmac-md5 and hmac-md5-96 to NOT RECOMMENDED - Downgrade hmac-sha1-96 to NOT RECOMMENDED - Consider downgrading hmac-sha1 to RECOMMENDED HMAC-SHA1 is not (yet) considered insecure, it has been SSHv2's only required algorithm since RFC 425x were published, and it is probably the most widely deployed. So, we should not downgrade it below RECOMMENDED. However, I think a case can be made for hmac-sha2-256 replacing it as the REQUIRED algorithm, if we think that has gained enough traction. For encryption algorithms: - Upgrade aes128-ctr to REQUIRED - Consider downgrading 3des-cbc to RECOMMENDED - Downgrade all other *-cbc algorithms to NOT RECOMMENDED - Do we want to say anything about IDEA, CAST, or RC4? Downgrading the CBC modes should be obvious. Similarly, it should be clear that we should upgrade one of the AES counter variants to take its place. I chose aes128-ctr because RFC4253 listed aes128-cbc as RECOMMENDED while leaving the other sizes OPTIONAL. I suspect this was done because at the time, some folks did not want to ship AES256 due to export restrictions and/or lack of utility. Today, we may want to reconsider this position and REQUIRE aes256-ctr instead of aes128-ctr. Unfortunately, I don't have a good idea how widely implemented these are. We may wish to consider leaving 3des-cbc at SHOULD, with a recommendation that it be disabled by default, especially in servers. If implementors all remove this, then users may be stuck unable to access embedded and other old devices which cannot be upgraded. This has been a serious problem for people trying to access web-based management interfaces of older devices, as browsers and TLS stacks have done things like removing support for smaller DH groups and objecting to certificates with smaller key sizes. Finally, for key exchange algorithms: - Upgrade diffie-hellman-group-exchange-sha256 to REQUIRED - Upgrade ecdh-sha2-* to RECOMMENDED - Consider downgrading diffie-hellman-group14-sha1 to RECOMMENDED - Downgrade other diffie-hellman-*-sha1 to NOT RECOMMENDED - Downgrade rsa1024-sha1 to NOT RECOMMENDED Again, eliminating the SHA1-based DH algorithms in favor of GEX SHA256 should be obvious, but there is the question of interoperability with existing deployments. Thus, we may want to consider leaving group1 or group14 at SHOULD, with a recommendation that it be disabled by default in servers. If we're going to de-recommend SHA1 (outside of HMAC), we should do so across the board. Unfortunately, sha256-based versions of the GSSAPI key exchanges have not yet been defined or implemented. Since no replacement is available, deprecating them is premature. It would probably be good to update RFC4462, but even after an update is published, it will probably be a while before the new version is widely implemented enough to downgrade the old. Analogous to the public key algorithms, ECDH is a viable algorithm, so IMHO it makes sense to upgrade to RECOMMENDED. > Or, is this better left to another RFC? Perhaps moving the Ed25519 > algorithm created by > > https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 > > into a MUST algorithm while deprecating "ssh-dss" for SSH? That's an unfinished, -00 version internet draft from CFRG. It's probably too soon to use it as the basis for an SSH public key algorithm at all, let alone make such an algorithm mandatory to implement. Once the document is ready, we can start with OPTIONAL, and consider upgrading when the algorithm has proven itself and is reasonably widely implemented in SSH. -- Jeff --=-lQlvaSQBHXH6+1UIszbV Content-Disposition: attachment; filename="ssh-algos.txt" Content-Type: text/plain; name="ssh-algos.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit Type Current Proposed RFC Name ==== ========== ========== ==== ======================================== kex MUST SHOULD NOT 4253 diffie-hellman-group1-sha1 kex MUST SHOULD? 4253 diffie-hellman-group14-sha1 kex MAY SHOULD NOT 4419 diffie-hellman-group-exchange-sha1 kex MAY MUST 4419 diffie-hellman-group-exchange-sha256 kex MAY SHOULD NOT 4432 rsa1024-sha1 kex MAY 4432 rsa2048-sha256 kex MAY 4462 gss-group1-sha1-* kex MAY 4462 gss-group14-sha1-* kex MAY 4462 gss-gex-sha1-* kex MAY(+) SHOULD 5656 ecdh-sha2-* kex MAY 5656 ecmqv-sha2-* Type Current Proposed RFC Name ==== ========== ========== ==== ======================================== enc MUST SHOULD? 4253 3des-cbc enc MAY SHOULD NOT 4253 blowfish-cbc enc MAY SHOULD NOT 4253 twofish256-cbc enc MAY SHOULD NOT 4253 twofish-cbc enc MAY SHOULD NOT 4253 twofish192-cbc enc MAY SHOULD NOT 4253 twofish128-cbc enc MAY SHOULD NOT 4253 aes256-cbc enc MAY SHOULD NOT 4253 aes192-cbc enc SHOULD SHOULD NOT 4253 aes128-cbc enc MAY SHOULD NOT 4253 serpent256-cbc enc MAY SHOULD NOT 4253 serpent192-cbc enc MAY SHOULD NOT 4253 serpent128-cbc enc MAY SHOULD NOT 4253 arcfour enc MAY SHOULD NOT 4253 idea-cbc enc MAY SHOULD NOT 4253 cast128-cbc enc SHOULD NOT 4253 none enc ??? ---- des-cbc enc SHOULD MUST? 4344 aes128-ctr enc SHOULD 4344 aes192-ctr enc SHOULD 4344 aes256-ctr enc SHOULD 4344 3des-ctr enc MAY 4344 blowfish-ctr enc MAY 4344 twofish128-ctr enc MAY 4344 twofish192-ctr enc MAY 4344 twofish256-ctr enc MAY 4344 serpent128-ctr enc MAY 4344 serpent192-ctr enc MAY 4344 serpent256-ctr enc MAY ??? 4344 idea-ctr enc MAY ??? 4344 cast128-ctr enc MAY ??? 4345 arcfour128 enc MAY ??? 4345 arcfour256 enc MAY 5647 AEAD_AES_128_GCM enc MAY 5647 AEAD_AES_256_GCM Type Current Proposed RFC Name ==== ========== ========== ==== ======================================== mac MUST SHOULD? 4253 hmac-sha1 mac SHOULD SHOULD NOT 4253 hmac-sha1-96 mac MAY SHOULD NOT 4253 hmac-md5 mac MAY SHOULD NOT 4253 hmac-md5-96 mac SHOULD NOT 4253 none mac MAY 5647 AEAD_AES_128_GCM mac MAY 5647 AEAD_AES_256_GCM mac SHOULD MUST 6668 hmac-sha2-256 mac MAY SHOULD? 6668 hmac-sha2-512 Type Current Proposed RFC Name ==== ========== ========== ==== ======================================== pk MUST SHOULD NOT 4253 ssh-dss pk SHOULD MUST 4253 ssh-rsa pk MAY 4253 pgp-sign-rsa pk MAY SHOULD NOT 4253 pgp-sign-dss pk ??? ???? spki-sign-rsa pk ??? ???? spki-sign-dss pk MAY 4462 null pk MAY(+) SHOULD 5656 ecdsa-sha2-* pk MAY SHOULD NOT 6187 x509v3-ssh-dss pk MAY 6187 x509v3-ssh-rsa pk MAY 6187 x509v3-rsa2048-sha256 pk MAY 6187 x509v3-ecdsa-sha2-* (+) "SSH ECC implementations" (i.e., those that implement RFC5656) are required to implement the ecdsa-sha2-* public key algorithms and the ecdh-sha2-* kex algorithms, but not the ecmqv-sha2-* kex algorithm. Furthermore, only certain curves are required. --=-lQlvaSQBHXH6+1UIszbV-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 31 08:56:13 2015 Return-Path: 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 A81B81A6FCC for ; Sat, 31 Oct 2015 08:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 htcKFahAwOru for ; Sat, 31 Oct 2015 08:56:12 -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 3173E1A6FCA for ; Sat, 31 Oct 2015 08:56:12 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id C2E1A14A211; Sat, 31 Oct 2015 15:56:06 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 626B614A210; Sat, 31 Oct 2015 15:56:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A060614A364 for ; Fri, 30 Oct 2015 23:07:41 +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 mveiualW-ANR for ; Fri, 30 Oct 2015 23:07:41 +0000 (UTC) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2D24C14A362 for ; Fri, 30 Oct 2015 23:07:39 +0000 (UTC) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp02.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[192.168.202.98]"; client-ip=74.109.252.206 Received: from [192.168.202.98] (pool-74-109-252-206.pitbpa.fios.verizon.net [74.109.252.206]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id t9ULhe47002157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2015 17:43:41 -0400 (EDT) Message-ID: <1446241420.32676.14.camel@destiny.pc.cs.cmu.edu> Subject: Re: SSH key algorithm updates From: Jeffrey Hutzelman To: Stephen Farrell Cc: jhutz@cmu.edu, "Mark D. Baushke" , denis bider , ietf-ssh@NetBSD.org, nisse@lysator.liu.se, jon@siliconcircus.com Date: Fri, 30 Oct 2015 17:43:40 -0400 In-Reply-To: <5633E2D5.1020207@cs.tcd.ie> References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> <5633E2D5.1020207@cs.tcd.ie> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, 2015-10-30 at 21:36 +0000, Stephen Farrell wrote: > > On 30/10/15 18:12, Jeffrey Hutzelman wrote: > > Agreed. In fact, we probably should undertake a general updating of > > recommended and required crypto algorithms across the protocol. > > If there's general support for this, then I'd be happy to > try shift any annoying IETF bureaucracy out of the way. That > could mean forming a short-lived wg or me AD sponsoring a > single document if that's all that's needed. I'm happy to > help with either approach. I imagine that we could do it with an AD-sponsored document and an extended IETF last call. No need to spin up a WG, I hope. I admit I haven't been paying attention; what's the plan for SHA3? Should we be thinking about a set of documents to define SHA3-based key exchange, public key, and MAC algorithms for SSH? From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 31 08:56:41 2015 Return-Path: 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 5324B1A6FCD for ; Sat, 31 Oct 2015 08:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 fgjM7uKoJBam for ; Sat, 31 Oct 2015 08:56:39 -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 C11281A6FCA for ; Sat, 31 Oct 2015 08:56:39 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 44AC514A213; Sat, 31 Oct 2015 15:56:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C8CDB14A212; Sat, 31 Oct 2015 15:56:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2146D14A1CA for ; Sat, 31 Oct 2015 10:33:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=dunlop-lello_uk.20150623.gappssmtp.com 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 iieiYHjUkbMb for ; Sat, 31 Oct 2015 10:33:07 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id CDD0714A1C4 for ; Sat, 31 Oct 2015 10:33:04 +0000 (UTC) Received: by lbbes7 with SMTP id es7so62383468lbb.2 for ; Sat, 31 Oct 2015 03:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunlop-lello_uk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nPq0Qtnh5oyJVitszRMvwoXx2SuohS9mGGiEIk4/pj0=; b=OMnuTCRU0HxLFiT2A4xjMVV+oV3Ngbe2ScJLD+9i4u7r6APBEwJRyGk+WIloEMOa6a 8ewkKos3vuQX0NBpPEvmwL2uHZ4649NOVLCYeR8VblS3lvVg57fdkopnFcsqL3GFNRn6 inePIVr3WiUGfQbH6qgvYFvrpatCy+8xdZ89e2dAKX9MhFA9pF6HZllGRgarUGBNGScT ng041zJd9quRCF++ijTa9p1j6luUqOEC2FmbBZWtbEUxC5Xl9FZK2X4jkAabq70RoYIQ nUc/DtJGc4IzS+EOHcVfmqX+Zyp+alZlzSuBdnG3XkdgTktMyBNgKH2gQ8eAdgRpaHTO geTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nPq0Qtnh5oyJVitszRMvwoXx2SuohS9mGGiEIk4/pj0=; b=M8nhJpgoqTS9hH2+H+yELROjAjcH+HKyKrr184xFXpC4/yR1JVSF6Hp6+Q30DAB6Io mB5MzKtRIwq4MQqD+BKpY+X+0UtmdPMtOx36hGd8VbGuiYpi2h7R7adomkfkybqKNLFb xrp25yew1fSTZ8A+c2u5iGvcpkivMt51vtcWrtfIRnzs+KWkI7xTHoY2GsRDNVwy9QfL AEYYjj1eB/UbZPoem4JWjLBmGaNb8xhPi8FV2+05bRZpOUuBIdXu/WA+zxx+uE3a+S2b nGrFTjHaKcIYT/ZkAvXOiKd/VHefK3rbw9Iygc/C8yAvtcITLAQx6ACKDBwCRFCv2gle dkPQ== X-Gm-Message-State: ALoCoQm/uTBoN3tyZ0PNe0bkvmc2+AoHFQLTSECTp1nA7SMjWmjA9tMYOERePF9HFiQxSIG7zaUV MIME-Version: 1.0 X-Received: by 10.112.137.34 with SMTP id qf2mr177820lbb.35.1446287582748; Sat, 31 Oct 2015 03:33:02 -0700 (PDT) Received: by 10.25.197.198 with HTTP; Sat, 31 Oct 2015 03:33:02 -0700 (PDT) In-Reply-To: <5633E5E0.8000503@cs.tcd.ie> References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> <5633E2D5.1020207@cs.tcd.ie> <1446241420.32676.14.camel@destiny.pc.cs.cmu.edu> <5633E5E0.8000503@cs.tcd.ie> Date: Sat, 31 Oct 2015 10:33:02 +0000 Message-ID: Subject: Re: SSH key algorithm updates From: Phil Lello To: Stephen Farrell Cc: Jeffrey Hutzelman , "Mark D. Baushke" , denis bider , ietf-ssh@netbsd.org, nisse@lysator.liu.se, jon@siliconcircus.com Content-Type: multipart/alternative; boundary=089e01182b469d0219052364114e Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --089e01182b469d0219052364114e Content-Type: text/plain; charset=UTF-8 At the risk of thread-jacking a little, I was working a few months ago on adding SASL support to the SSH protocol; this work is currently parked, but if I can find time to work on this again, would this be a good juncture to get that on the standards track? I'm assuming the audience for adding a new auth mechanism is the same one involved in deprecation. Best wishes, Phil Lello On Fri, Oct 30, 2015 at 9:49 PM, Stephen Farrell wrote: > > > On 30/10/15 21:43, Jeffrey Hutzelman wrote: > > On Fri, 2015-10-30 at 21:36 +0000, Stephen Farrell wrote: > >> > >> On 30/10/15 18:12, Jeffrey Hutzelman wrote: > >>> Agreed. In fact, we probably should undertake a general updating of > >>> recommended and required crypto algorithms across the protocol. > >> > >> If there's general support for this, then I'd be happy to > >> try shift any annoying IETF bureaucracy out of the way. That > >> could mean forming a short-lived wg or me AD sponsoring a > >> single document if that's all that's needed. I'm happy to > >> help with either approach. > > > > > > I imagine that we could do it with an AD-sponsored document and an > > extended IETF last call. No need to spin up a WG, I hope. > > Yeah, if it's just algo updates, that seems right. I guess we > should see if folks have another list of things they'd like to > do though - if there were then that might justify a wg, but if > not, then AD sponsored is much quicker/simpler. > > > > > I admit I haven't been paying attention; what's the plan for SHA3? > > Not sure there's a general plan. There does seem to be a general > disinterest;-) > > > Should we be thinking about a set of documents to define SHA3-based key > > exchange, public key, and MAC algorithms for SSH? > > Personally, I'm not that keen on defining stuff that might not > get widespread use, but that kind of opinion seems to vary from > protocol to protocol, and from one set of folks to another. So > I'm not sure what folks here think. > > Deprecating old stuff to the extent we can OTOH, I'm quite keen > on that:-) > > Cheers, > S. > > > S. > > > > > > --089e01182b469d0219052364114e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At the risk of thread-jacking a little, I was working= a few months ago on adding SASL support to the SSH protocol; this work is = currently parked, but if I can find time to work on this again, would this = be a good juncture to get that on the standards track? I'm assuming the= audience for adding a new auth mechanism is the same one involved in depre= cation.

Best wishes,

Phil Lello

On Fri, Oct 30, 2015= at 9:49 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 30/10/15 21:43, Jeffrey Hutzelman wrote:
> On Fri, 2015-10-30 at 21:36 +0000, Stephen Farrell wr= ote:
>>
>> On 30/10/15 18:12, Jeffrey Hutzelman wrote:
>>> Agreed.=C2=A0 In fact, we probably should undertake a general = updating of
>>> recommended and required crypto algorithms across the protocol= .
>>
>> If there's general support for this, then I'd be happy to<= br> >> try shift any annoying IETF bureaucracy out of the way. That
>> could mean forming a short-lived wg or me AD sponsoring a
>> single document if that's all that's needed. I'm happy= to
>> help with either approach.
>
>
> I imagine that we could do it with an AD-sponsored document and= an
> extended IETF last call.=C2=A0 No need to spin up a WG, I hope.

Yeah, if it's just algo updates, that seems right. I guess we
should see if folks have another list of things they'd like to
do though - if there were then that might justify a wg, but if
not, then AD sponsored is much quicker/simpler.

>
> I admit I haven't been paying attention; what's the plan for S= HA3?

Not sure there's a general plan. There does seem to be a general
disinterest;-)

> Should we be thinking about a set of documents to define SHA3-based ke= y
> exchange, public key, and MAC algorithms for SSH?

Personally, I'm not that keen on defining stuff that might not
get widespread use, but that kind of opinion seems to vary from
protocol to protocol, and from one set of folks to another. So
I'm not sure what folks here think.

Deprecating old stuff to the extent we can OTOH, I'm quite keen
on that:-)

Cheers,
S.


S.

>
>

--089e01182b469d0219052364114e-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 31 08:57:37 2015 Return-Path: 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 64A091A6FD0 for ; Sat, 31 Oct 2015 08:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 onfQIF1ci5-E for ; Sat, 31 Oct 2015 08:57:34 -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 67D521A6FFE for ; Sat, 31 Oct 2015 08:57:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 041FE14A215; Sat, 31 Oct 2015 15:57:31 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9CE6514A214; Sat, 31 Oct 2015 15:57:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BD4FF14A104 for ; Sat, 31 Oct 2015 05:32:55 +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 XP55r_mnagA1 for ; Sat, 31 Oct 2015 05:32:54 +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 C876014A0E0 for ; Sat, 31 Oct 2015 05:32:54 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@NetBSD.org; Sat, 31 Oct 2015 05:32:52 +0000 Date: Sat, 31 Oct 2015 05:32:52 +0000 Subject: RE: SSH key algorithm updates / 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: <1392146370-2044@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: ietf-ssh@NetBSD.org Cc: jhutz@cmu.edu, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, mdb@juniper.net, jon@siliconcircus.com Content-Type: multipart/alternative; boundary="=-yi0QP59hsYaskk9Fccq9" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-yi0QP59hsYaskk9Fccq9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mark D. Baushke: > Should this Draft RFC also be the one that moves the "ssh-dss" > public key algorithm from a "REQUIRED" and "MUST" implement > algorithm to an "OPTIONAL" and "SHOULD NOT" implement algorithm? I very much agree this should be done. However, it seems to me a separate p= urpose which may require a different type of consensus. It seems we could very much use Stephen's (offered) help with this. > Perhaps moving the Ed25519 algorithm FIPS does not approve of it, so there's a huge swath of products aimed for= government that can't use the supposed "required" method. It's also not easily available everywhere. Crypto++ doesn't have it. Window= s CNG doesn't have it. There's DJB's original code, which is native code, a= nd is not the most user friendly. I think RSA might fit the "required" role better. It's old, solid, universa= lly available, and acceptable to everyone. All it needs is an update to use= SHA-2 as the hash. Jeffrey Hutzelman: > I don't understand. The issue with ssh-dss was that we _didn't_ > allow for larger key sizes.=20 The issue is that there was no standard for larger key sizes at the time "s= sh-dss" was defined. Consequently, few implementations existed that could h= andle them. None existed that were completely general. If we "allow for" larger key sizes, then ALL implementations must be able t= o straightforwardly and correctly support them in advance. If they do not -= and they will not, because they don't perceive the need at this time - the= n this creates future compatibility problems. For example, if I use Windows CNG to implement this algorithm, I can only i= mplement 2048-bit and 3072-bit key sizes. I can't provide an implementation= compliant with a requirement to support larger keys. Any future users that= might use larger sizes will run into compatibility issues with software I = create now. This software may very well be still in use in 2020, even 2025.= We still hear from users running 9 year old versions of our software. User= s running 5 year old versions are common (perhaps even a majority). >=C2=A0 In fact, now that I think about it, we probably should have > defined an rsa-sha256 public key algorithm. There's no time like today. We can define "rsa-sha2-256" right now. Since RSA keys aren't themselves hash-dependent, we could grandfather in ex= isting RSA keys, and keep "ssh-rsa" in the public key format. This retains = existing host key fingerprints, and allows the same keys to be used for bot= h "ssh-rsa" and "rsa-sha2-256". This vastly simplifies migration. We change= the signature specification to use the new name, and to use SHA-2 256. I believe this would further provide a credible signature algorithm that we= could suggest "recommended" or "required". It seems to me that none of the= other candidates are good matches: - without deterministic signatures, DSA has its weakness to anything but pe= rfect RNG - EdDSA is not FIPS acceptable - ECDSA over NIST curves is not acceptable to others - The existing "ssh-rsa" uses SHA-1 However, if we define "rsa-sha2-256", however, we could mandate it as at "r= ecommended" (or even "required"). > - Upgrade ssh-rsa to REQUIRED Not sure about that. It uses SHA-1. We should probably define "rsa-sha2-256= ". = --=-yi0QP59hsYaskk9Fccq9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mark D. Baushke:

> Should this Draft RFC= also be the one that moves the "ssh-dss"
> public key algorithm from= a "REQUIRED" and "MUST" implement
> algorithm to an "OPTIONAL" and "= SHOULD NOT" implement algorithm?

I very much agree this should be do= ne. However, it seems to me a separate purpose which may require a differen= t type of consensus.

It seems we could very much use Stephen's (offe= red) help with this.


> Perhaps moving the Ed25519 algorithm
FIPS does not approve of it, so there's a huge swath of=20 products aimed for government that can't use the supposed "required"=20 method.

It's also not easily available everywhere. Crypto++ doesn't = have it. Windows CNG doesn't have it. There's DJB's original code, which is= native code, and is not the most user friendly.

I think RSA might f= it the "required" role better. It's old, solid, universally available, and = acceptable to everyone. All it needs is an update to use SHA-2 as the hash.=


Jeffrey Hutzelman:

> I don't understand. The issue wi= th ssh-dss was that we _didn't_
> allow for larger key sizes.
The issue is that there was no standard for larger key sizes at the time "= ssh-dss" was defined. Consequently, few implementations existed that could = handle them. None existed that were completely general.

If we "allow= for" larger key sizes, then ALL implementations must be able to straightfo= rwardly and correctly support them in advance. If they do not - and they wi= ll not, because they don't perceive the need at this time - then this creat= es future compatibility problems.

For example, if I use Windows CNG = to implement this algorithm, I can only implement 2048-bit and 3072-bit key= sizes. I can't provide an implementation compliant with a requirement to s= upport larger keys. Any future users that might use larger sizes will run i= nto compatibility issues with software I create now. This software may very= well be still in use in 2020, even 2025. We still hear from users running = 9 year old versions of our software. Users running 5 year old versions are = common (perhaps even a majority).


>  In fact, now that I= think about it, we probably should have
> defined an rsa-sha256 publ= ic key algorithm.

There's no time like today. We can define "rsa-sha= 2-256" right now.

Since RSA keys aren't themselves hash-dependent, w= e could grandfather in existing RSA keys, and keep "ssh-rsa" in the public = key format. This retains existing host key fingerprints, and allows the sam= e keys to be used for both "ssh-rsa" and "rsa-sha2-256". This vastly simpli= fies migration. We change the signature specification to use the new name, = and to use SHA-2 256.

I believe this would further provide a credibl= e signature algorithm that we could suggest "recommended" or "required". It= seems to me that none of the other candidates are good matches:

- w= ithout deterministic signatures, DSA has its weakness to anything but perfe= ct RNG
- EdDSA is not FIPS acceptable
- ECDSA over NIST curves is not= acceptable to others
- The existing "ssh-rsa" uses SHA-1

However= , if we define "rsa-sha2-256", however, we could mandate it as at "recommen= ded" (or even "required").


> - Upgrade ssh-rsa to REQUIRED
Not sure about that. It uses SHA-1. We should probably define "rsa-sha= 2-256".

= --=-yi0QP59hsYaskk9Fccq9-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 31 08:58:12 2015 Return-Path: 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 D7C971A003A for ; Sat, 31 Oct 2015 08:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 loWzvSSohquc for ; Sat, 31 Oct 2015 08:58:06 -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 2F0AC1A6FD0 for ; Sat, 31 Oct 2015 08:58:06 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id C283C14A219; Sat, 31 Oct 2015 15:58:05 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 687E414A218; Sat, 31 Oct 2015 15:58:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A058E14A2FB for ; Sat, 31 Oct 2015 07:20:47 +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 Wd3J-1tK8Ey2 for ; Sat, 31 Oct 2015 07:20:46 +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 9E1B014A2E5 for ; Sat, 31 Oct 2015 07:20:46 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@NetBSD.org; Sat, 31 Oct 2015 07:20:45 +0000 Date: Sat, 31 Oct 2015 07:20:45 +0000 Subject: Re: SSH key algorithm updates / 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: <1399504453-896@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1392146370-2044@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: ietf-ssh@NetBSD.org Cc: jhutz@cmu.edu, nisse@lysator.liu.se, stephen.farrell@cs.tcd.ie, mdb@juniper.net, jon@siliconcircus.com Content-Type: multipart/alternative; boundary="=-/07Dj/GNS+CKcgNGpoAL" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-/07Dj/GNS+CKcgNGpoAL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have uploaded a new draft here: http://www.denisbider.com/draft-rsa-dsa-sha2-256.txt This now specifies both "rsa-sha2-256" and "dsa-sha2-256". denis bider , 10/31/2015 5:17 AM: Mark D. Baushke: > Should this Draft RFC also be the one that moves the "ssh-dss" > public key algorithm from a "REQUIRED" and "MUST" implement > algorithm to an "OPTIONAL" and "SHOULD NOT" implement algorithm? I very much agree this should be done. However, it seems to me a separate p= urpose which may require a different type of consensus. It seems we could very much use Stephen's (offered) help with this. > Perhaps moving the Ed25519 algorithm FIPS does not approve of it, so there's a huge swath of products aimed for= government that can't use the supposed "required" method. It's also not easily available everywhere. Crypto++ doesn't have it. Window= s CNG doesn't have it. There's DJB's original code, which is native code, a= nd is not the most user friendly. I think RSA might fit the "required" role better. It's old, solid, universa= lly available, and acceptable to everyone. All it needs is an update to use= SHA-2 as the hash. Jeffrey Hutzelman: > I don't understand. The issue with ssh-dss was that we _didn't_ > allow for larger key sizes.=20 The issue is that there was no standard for larger key sizes at the time "s= sh-dss" was defined. Consequently, few implementations existed that could h= andle them. None existed that were completely general. If we "allow for" larger key sizes, then ALL implementations must be able t= o straightforwardly and correctly support them in advance. If they do not -= and they will not, because they don't perceive the need at this time - the= n this creates future compatibility problems. For example, if I use Windows CNG to implement this algorithm, I can only i= mplement 2048-bit and 3072-bit key sizes. I can't provide an implementation= compliant with a requirement to support larger keys. Any future users that= might use larger sizes will run into compatibility issues with software I = create now. This software may very well be still in use in 2020, even 2025.= We still hear from users running 9 year old versions of our software. User= s running 5 year old versions are common (perhaps even a majority). >=C2=A0 In fact, now that I think about it, we probably should have > defined an rsa-sha256 public key algorithm. There's no time like today. We can define "rsa-sha2-256" right now. Since RSA keys aren't themselves hash-dependent, we could grandfather in ex= isting RSA keys, and keep "ssh-rsa" in the public key format. This retains = existing host key fingerprints, and allows the same keys to be used for bot= h "ssh-rsa" and "rsa-sha2-256". This vastly simplifies migration. We change= the signature specification to use the new name, and to use SHA-2 256. I believe this would further provide a credible signature algorithm that we= could suggest "recommended" or "required". It seems to me that none of the= other candidates are good matches: - without deterministic signatures, DSA has its weakness to anything but pe= rfect RNG - EdDSA is not FIPS acceptable - ECDSA over NIST curves is not acceptable to others - The existing "ssh-rsa" uses SHA-1 However, if we define "rsa-sha2-256", however, we could mandate it as at "r= ecommended" (or even "required"). > - Upgrade ssh-rsa to REQUIRED Not sure about that. It uses SHA-1. We should probably define "rsa-sha2-256= ". = --=-/07Dj/GNS+CKcgNGpoAL Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have uploaded a new draft here:

http://ww= w.denisbider.com/draft-rsa-dsa-sha2-256.txt

This now specifies both = "rsa-sha2-256" and "dsa-sha2-256".


denis bider <ietf-ssh3@denisbider.com> , 10/31/2015= 5:17 AM:
Mark D. Baushke:

> Sho= uld this Draft RFC also be the one that moves the "ssh-dss"
> public = key algorithm from a "REQUIRED" and "MUST" implement
> algorithm to a= n "OPTIONAL" and "SHOULD NOT" implement algorithm?

I very much agree= this should be done. However, it seems to me a separate purpose which may = require a different type of consensus.

It seems we could very much u= se Stephen's (offered) help with this.


> Perhaps moving the E= d25519 algorithm

FIPS does not approve of it, so there's a huge swat= h of=20 products aimed for government that can't use the supposed "required"=20 method.

It's also not easily available everywhere. Crypto++ doesn't = have it. Windows CNG doesn't have it. There's DJB's original code, which is= native code, and is not the most user friendly.

I think RSA might f= it the "required" role better. It's old, solid, universally available, and = acceptable to everyone. All it needs is an update to use SHA-2 as the hash.=


Jeffrey Hutzelman:

> I don't understand. The issue wi= th ssh-dss was that we _didn't_
> allow for larger key sizes.
The issue is that there was no standard for larger key sizes at the time "= ssh-dss" was defined. Consequently, few implementations existed that could = handle them. None existed that were completely general.

If we "allow= for" larger key sizes, then ALL implementations must be able to straightfo= rwardly and correctly support them in advance. If they do not - and they wi= ll not, because they don't perceive the need at this time - then this creat= es future compatibility problems.

For example, if I use Windows CNG = to implement this algorithm, I can only implement 2048-bit and 3072-bit key= sizes. I can't provide an implementation compliant with a requirement to s= upport larger keys. Any future users that might use larger sizes will run i= nto compatibility issues with software I create now. This software may very= well be still in use in 2020, even 2025. We still hear from users running = 9 year old versions of our software. Users running 5 year old versions are = common (perhaps even a majority).


>  In fact, now that I= think about it, we probably should have
> defined an rsa-sha256 publ= ic key algorithm.

There's no time like today. We can define "rsa-sha= 2-256" right now.

Since RSA keys aren't themselves hash-dependent, w= e could grandfather in existing RSA keys, and keep "ssh-rsa" in the public = key format. This retains existing host key fingerprints, and allows the sam= e keys to be used for both "ssh-rsa" and "rsa-sha2-256". This vastly simpli= fies migration. We change the signature specification to use the new name, = and to use SHA-2 256.

I believe this would further provide a credibl= e signature algorithm that we could suggest "recommended" or "required". It= seems to me that none of the other candidates are good matches:

- w= ithout deterministic signatures, DSA has its weakness to anything but perfe= ct RNG
- EdDSA is not FIPS acceptable
- ECDSA over NIST curves is not= acceptable to others
- The existing "ssh-rsa" uses SHA-1

However= , if we define "rsa-sha2-256", however, we could mandate it as at "recommen= ded" (or even "required").


> - Upgrade ssh-rsa to REQUIRED
Not sure about that. It uses SHA-1. We should probably define "rsa-sha= 2-256".

= --=-/07Dj/GNS+CKcgNGpoAL-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 31 09:52:56 2015 Return-Path: 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 4F09A1B2B5B for ; Sat, 31 Oct 2015 09:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 IEjSLGwh9LUx for ; Sat, 31 Oct 2015 09:52:55 -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 062FF1B2B5A for ; Sat, 31 Oct 2015 09:52:55 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 74D1314A1E5; Sat, 31 Oct 2015 16:52:51 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DB91414A1DF for ; Sat, 31 Oct 2015 16:52:44 +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 gLWOX70AQLy6 for ; Sat, 31 Oct 2015 16:52:44 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) by mail.netbsd.org (Postfix) with ESMTP id 8EE5714A1DB for ; Sat, 31 Oct 2015 16:52:42 +0000 (UTC) Received: from BLUPR05CA0076.namprd05.prod.outlook.com (10.141.20.46) by DM2PR0501MB1389.namprd05.prod.outlook.com (10.161.224.11) with Microsoft SMTP Server (TLS) id 15.1.312.18; Sat, 31 Oct 2015 16:52:40 +0000 Received: from BN1AFFO11FD022.protection.gbl (2a01:111:f400:7c10::154) by BLUPR05CA0076.outlook.office365.com (2a01:111:e400:855::46) with Microsoft SMTP Server (TLS) id 15.1.312.18 via Frontend Transport; Sat, 31 Oct 2015 16:52:39 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; denisbider.com; dkim=none (message not signed) header.d=none;denisbider.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1AFFO11FD022.mail.protection.outlook.com (10.58.52.82) with Microsoft SMTP Server (TLS) id 15.1.318.9 via Frontend Transport; Sat, 31 Oct 2015 16:52:39 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 31 Oct 2015 09:52:38 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t9VGqaD82005; Sat, 31 Oct 2015 09:52:36 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 2D0EB1141B; Sat, 31 Oct 2015 09:52:36 -0700 (PDT) To: Jeffrey Hutzelman CC: denis bider , , , , Subject: Re: SSH key algorithm updates In-Reply-To: <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net> <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> Comments: In-reply-to: Jeffrey Hutzelman message dated "Fri, 30 Oct 2015 14:12:33 -0400." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1AFFO11FD022;1:i4P4cCqy163R+ChNB2Tpr/e1TCAl5ZjhydGxlwpcMGFFCQsmiXYsB7IP7ZosRFRZGQf/SMqfBKlHD8QztL1cM4l9YpMU8uJrG0Avj/MvcFotdUqDdz/qUAAC4vpuq8kr0nwo1bIQTKdkDRDhO+m0So3qYkYTwwSNLcEMXZgj08cwvE1oAbTEwU0iYiG7JfHMuhevq4+4fhSXijic8z8pIw2oxOHEVKylagK3NZrdluyZ8HOn0rKmI098hviqEnvwADPkvCw2WXchm2jHtwGqcvRkDqxOkXYLLyUTcjvPT620dWPYskzsQomIKb8pLWF3om1FYO1mymTfVIvz+0puWaEaWxcSBjqNkDLkgeryx7Mm/NzufFV7RCwPLo7ZZhpnNzGMTHh1noHrolWpTPbK8w== X-Forefront-Antispam-Report: CIP:66.129.239.17;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(189002)(199003)(11100500001)(77096005)(69596002)(2950100001)(5007970100001)(106466001)(48376002)(97736004)(19580405001)(15975445007)(5003940100001)(50226001)(6806005)(81156007)(76176999)(19580395003)(50986999)(5001960100002)(92566002)(87936001)(5003600100002)(76506005)(2171001)(86362001)(53416004)(47776003)(117636001)(189998001)(105596002)(110136002)(50466002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0501MB1389;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1389;2:mLxrHXVLs/EJepdnMhdaoxV7OD3sxdY4oN/iOogfnNr9ug/T7jPw7ryuZTp497rIWcxkwhllGVtGYHU1e3z9Rt8lqUauxrkWRWPCyIngDbbK6ME2grgH1M84N+YRWiWnbblJYCA5J8xwdPpMB4kW7y1I7A4WDNmLXsfq9XFghDU=;3:D+slv0MNRXJ4iYT2s9WqiXUNb5t2Sd6I1X/MlKnGvSbvbuc9PZTFk8KIUrg29B2c3A/oQO26BnHjcakTunc1FHKTuykWzFinB1NCzNElB9BCTNTYO2uWHO7Uh4zxweZwuV2iOHZUuwU0OgA1Ig3yaYSV8Mp0nN9URmY3nLbDqCxGQuFMy85lnDK4B0Jx8U/Ko6ZEx6aXQCFR8y9HCOpl/tdtPcF+Rbr9O8lB5OUfVwg=;25:ybmeUL81uCXLS71olMNJcwyBLwD4O6X0K/bw4OZjZr0gCUSchiuJXvZwp16sSb50Q3RHsYGF8AsKTlZgMcjh2FPAnkscyx+OJH3189Ya3H1Dq7WvxdKsKiqFE9Cc6IVG+w2NaKix9ykQN2qHcM1BXHEOGQWlT4MUDOfLRryOKH7+JJkmGu/saqJI6tTPxD7ZBNGFaJvZsqomyNqSgdOMWWvFvb61mq9fXdQvJ61m2mlMnzpGvIZAz0zw7m5ahGhTBkk/xeT7mJmyXcFMlv9CyQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1389; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1389;20:Q+vFT02uIBwUh5oMynXEcSIrl8AkzOzLF4JUbC70IU694bwVn5qtxSMaZuVec0wsQZmk+iTiJyCnVIy7qmnUVpjaaI1aiyy/QsG9uzXr/T18gsQM2b4m2AVD5QbFld56s2E4g0/SOhn+mbNdxBFxqWYKsW/oQX4Mkxcr0BBOP0yy7Aqvgd6sPX6inM7v69h+tDL5nXqzvsT6Q1WJ2E+p3XyBl3RGvnmaEF3OTn3H2Quf+LeeRgQvu0qT3LwMINWqdpAUH+JdNDUgfSmRtq9bsb/cQ5O3kMsV2tdYz4o4CrKW6kd2PM+EankaYCEBsjfJSYjAGCizgj3g6qeYVnt5i4eZHzYQkVF5RbA+ea1pB74lK2EV2qVoHm9n/ZQGgStw3cTS9HXubfI5t8DU2AYE4sAnmS0HOfg0fJh/kojTr+ing/8JLeK6OX3LESGAO4lUkUxZlrRbF9d09zQ/fkXPpFvfpkni/w4Xgeecm4llgtVh3WPeh9ppKrog6YHlje0B;4:G55Xd/TnaeK8LOnwLfKvDaKA9F+9IRnF9fp+rMdd6eFjnIt64bhIaItIT520y+1gEzb9zBmeGCQ1D8bBEDwtigC73HKJ/+CCqC6pqyFSZZdtVPpj3mYOPE34ULGutG93g8Ps1RuE0xqR6rZMFRqqNB57xzWAKeBdcx4uv5Elnv8g9bZGwtbc1UGXQWeGXyc/sRQoAYsIpTLUDAtdkPIfLWMR+X/ovEbMk6IYAQyLzSfHARlAN7fy3oWJTE8Bgs2WIQZQcCJLyNcT9PcTWgFV0q13J3hNDiwPPoaoCR5nHQ9GiHaqwgvBsCQ0Bd1Kw1v49PmLhitLfZSB3GxmzpsmSfWp6EwAq0rG9JY8WPMC+kX3GIFoIRwLOdGlmH/aeZey X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046);SRVR:DM2PR0501MB1389;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1389; X-Forefront-PRVS: 07467C4D33 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM2PR0501MB1389;23:ySr9/3fAocHieJJNP5uIyEiMW5IwX48EQZda2oy?= =?us-ascii?Q?R1+0aQYUfuxJqRrGxffIYqw7Z+u2YtpbE2KXVKMwAlO+hrpx4eUhiJwA26OH?= =?us-ascii?Q?jE22+kS7K+WmerrGzRF0qFlPHVFb/aB86KLgn9FiSzPNkeoWYMxYl4c/xmdu?= =?us-ascii?Q?Y+achh3bkrC0KDw8GqSFuoO7UUVQuSZfxtXB/xBBYcJj3lwKmwpaBA1xdBS1?= =?us-ascii?Q?98K4E+UFDofjxXoBeFLX4SbhNNvEVXZQtbC5wh71S4GAVj/+F7tpj0F0tkaT?= =?us-ascii?Q?6uDMHfHXLycEm2lAJu22wTQbD+TkcmL0fXQzwb81dRXIOwK8MU2HA59fKzWf?= =?us-ascii?Q?LDKxdNqE2rIiL8HySa8kFcoxtJDp1V1HYBeA+h8mIZhtsDZGbxYoR74ueweE?= =?us-ascii?Q?ODpVkl0oElX5rBHTIPhytS/wgytJI7j0qf3eretigxk5QPyCR773+Atbxp2H?= =?us-ascii?Q?1CEdNLsgkbneuLvpg/9WRspAN6rJ1hS6FQXgGYHfvZbsdDVQevDGDWwX8Em8?= =?us-ascii?Q?Uw38EXFsYpox6Vsd/GPI0fBJKY4HlyUA7Ird7IJ70iih8aUGnIlqdzTB8DW9?= =?us-ascii?Q?OQRtcLdDO1HoCbcJ7VwJog3TwXAJUnmPVKXpIw8X0ya3vS+tHkOop2xw1Ugq?= =?us-ascii?Q?VLYjhwpHhDXOwqTl0FXca1f5dxCQ7x0g8C/n16oOTYoXxzm/cX+9i4tuC7nv?= =?us-ascii?Q?y9onAAASQlwhXns62TjT18BG4ar1I7iJuf7cL1jK3VLk46rQm18B16eR+SE3?= =?us-ascii?Q?FKusFM7g7KUXd11EnBdhPE+ecwEuXEy7SnnkSL6ixhjISejAkI40F8feNxJa?= =?us-ascii?Q?VyqkFbuHnkZ+dZk870+rzwseGNq1F0ksXDrIEBk0f0CNlgBYTksOua7TJsKq?= =?us-ascii?Q?yky3SJbQKbh/M+1iBaFdiPFXveGYQvEnsmsbDsHFzxs+cviYW98SI5mIv7Iy?= =?us-ascii?Q?Hs0Z61g0edV2MnRqQErdoJDpwMcz2mZECMN27k4Jzoi08u2DhtywoMD4PPqp?= =?us-ascii?Q?j6ws=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1389;5:pSJ/V2lVvxbyq3/Y9DVmErq9vOTWZt3Ay9MnSUYiT1m6GmhS3zea05Yj5Uh0NKgUPDNfi/K+ZEbpnzQxT/QGzNR+vNsDxvZQmRhd7j7xRNYIaGL8ZW1/O84ym9cLRY3crzHWK4O61/QaxfSRkSCThg==;24:Wo/7yyNSRE7bwOoHc+EDd/obxpXlSeERaDMl5ZX9qqaVAk/ejj2zGMC6QxygOyQdoOzNXJGZgVhx/hEBLLjN9gEaBR++3BOXMf9H8q+r2rs=;20:JPkpdMZANC6+4s42xOBy5zS56KDrNrNaOPcIE2M4Ia0phgFAmgjbuOLI+agOaXInMnge2bE8wjCsJwRVhqg+xA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2015 16:52:39.0292 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.17];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1389 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Jeff, > > Or, is this better left to another RFC? Perhaps moving the Ed25519 > > algorithm created by > > > > https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 > > > > into a MUST algorithm while deprecating "ssh-dss" for SSH? > > That's an unfinished, -00 version internet draft from CFRG. It's > probably too soon to use it as the basis for an SSH public key algorithm > at all, let alone make such an algorithm mandatory to implement. Once > the document is ready, we can start with OPTIONAL, and consider > upgrading when the algorithm has proven itself and is reasonably widely > implemented in SSH. Hmmm.... OpenSSH has implemented an ssh-ed25519 and B. Harris has written: https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02 I am not sure how closely the IRTF Ed25519 an ssh-ed25519 implementations match, but I suspect it may be relevant to discuss both drafts and the SSH protocol sooner rather than later. Regading your table: > enc MAY ??? 4345 arcfour128 > enc MAY ??? 4345 arcfour256 To the best of my understanding, these use CBC and I suggest enc MAY SHOULD NOT 4345 arcfour128 enc MAY SHOULD NOT 4345 arcfour256 Regarding additional ciphers while the door is open. How about RFC7539 ChaCha and Poly1305? OpenSSH has implemented chacha20-poly1305@openssh.com The way that RFC5647 was written seems to not have been widely adopted although OpenSSH did implement aes128-gcm@openssh.com and aes256-gcm@openssh.com which are very similar. It might be nice to actually come up with a 'standards' track document dealing with AEAD ciphers and SSH and see if there is a better way to negotiate it within the existing framework of SSH's separation of MAC and Cipher. For example, maybe MAC=AEAD and Cipher=aes-gcm,chacha20-poly1305 would make more sense in the negotiation? It would be useful to see what other protocols various SSH implementers have been adding and see if there is a desire to move any of them into a recommended or optional standard. There is also the possibility of a encrypt-then-mac kinds of MAC choices to try to avoid attacks against block ciphers which are either mac-then-encrypt or AEAD. fwiw: I would have no problem with an ssh-rsa-sha2 pk. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Oct 31 19:34:10 2015 Return-Path: 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 08F541B52CA for ; Sat, 31 Oct 2015 19:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 3WEEAeaYB-n4 for ; Sat, 31 Oct 2015 19:34:08 -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 A73621B52C7 for ; Sat, 31 Oct 2015 19:34:08 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 7675414A1EE; Sun, 1 Nov 2015 02:34:05 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7D9EB14A1E3 for ; Sun, 1 Nov 2015 02:34:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 rCN4-EXCkP0p for ; Sun, 1 Nov 2015 02:34:01 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 4397E14A1D1 for ; Sun, 1 Nov 2015 02:34:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446345241; x=1477881241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BLBo4eOr0JusqEhLh62yV5MOrlkQw2FzhOyqJ9jvPYs=; b=EP+uzN48kgg/cotezf9+zhrFxAlZXEs3pxsBZ8+s2ZER1Q+mR7ix9I76 RwkgW9JUtlQvezuDD2mlnlQ4aY/ozVezNfK3hvN09gWyrBFGvg+7aAW3g NL/jSqegrH+TgfsiRti3owbbFRIw7xtiL/xIGk7BTOpthlos/5hrPs8R8 aYx9ouKK2PyMxNmVbD1WawMCdZFvFR6fH/xFx5dkYIzuQa4IfKujnMAvx qrt5sH4lywJHvSoPbYJhVEZSFpVliK6u5rANti7eoHdcHZ+Ur2QljMW+u MtCzdJsOiO6TDF8ebTkKubDoWxotvosYQyNPbv5PtDHFuHO6ZK04M5Vnz Q==; X-IronPort-AV: E=Sophos;i="5.20,226,1444647600"; d="scan'208";a="51745667" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 01 Nov 2015 14:02:18 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 1 Nov 2015 14:02:17 +1300 From: Peter Gutmann To: Jeffrey Hutzelman , "Mark D. Baushke" CC: denis bider , "ietf-ssh@NetBSD.org" , "nisse@lysator.liu.se" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: RE: SSH key algorithm updates Thread-Topic: SSH key algorithm updates Thread-Index: AQHRE/SHmOIgZ5z99Em1AFq8dDsFj56GWcO7 Date: Sun, 1 Nov 2015 01:02:16 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B4BC9F@uxcn10-5.UoA.auckland.ac.nz> References: <1297540000-2044@skroderider.denisbider.com> <51845.1446188002@eng-mail01.juniper.net>,<1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1446228753.32676.1.camel@destiny.pc.cs.cmu.edu> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman writes:=0A= =0A= >- Add dsa-sha2-256 as RECOMMENDED=0A= =0A= I'm strongly opposed to keeping DSA, for the reasons given earlier. It's d= ead=0A= everywhere except SSH, it'd be nice to get rid of this one holdout as well.= =0A= =0A= >Perhaps Denis wants to add pgp-sign-dsa-sha2-256 and/or x509v3-dsa-sha2-25= 6=0A= >to his document.=0A= =0A= Since neither the PGP nor the X.509 formats as used in SSH were ever define= d,=0A= I'd just remove them. Short of reverse-engineering someone else's=0A= implementation to see what they do, I can't see how you'd create an=0A= interoperable implementation of either of these.=0A= =0A= Peter.=