From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Feb 1 22:48:04 2016 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 100761A885C for ; Mon, 1 Feb 2016 22:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] 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 pMSfjG04BucG for ; Mon, 1 Feb 2016 22:48:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 6B8801A8865 for ; Mon, 1 Feb 2016 22:48:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5F07185EE7; Tue, 2 Feb 2016 06:48:01 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 154CA85EE5; Tue, 2 Feb 2016 06:48:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 100DC85E7B for ; Mon, 1 Feb 2016 21:55:49 +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 sU9e3SuksDEU for ; Mon, 1 Feb 2016 21:55:48 +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 AFD8B85E5D for ; Mon, 1 Feb 2016 21:55:45 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F2C7240006; Mon, 1 Feb 2016 22:55:42 +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 0240C40005; Mon, 1 Feb 2016 22:55:40 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 01 Feb 2016 22:55:40 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Stephen Farrell , ietf-ssh@NetBSD.org, Watson Ladd , Daniel Migault , Curdle Chairs , mdb@juniper.net Subject: AEAD in ssh References: <1361670077-596@skroderider.denisbider.com> Date: Mon, 01 Feb 2016 22:55:40 +0100 In-Reply-To: <1361670077-596@skroderider.denisbider.com> (denis bider's message of "Fri, 29 Jan 2016 22:44:35 +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: > With regard to AEAD: > > I think we should just make the following simple and clear statement: > > MAC algorithms are secondary to encryption algorithms, and are > evaluated only if the encryption algorithm is not AEAD. If an AEAD > encryption algorithm is negotiated, the outcome of MAC negotiation is > irrelevant and must be ignored. If no mutual MAC algorithms are > available, this causes key exchange to fail if, and only if, the > negotiated encryption algorithm is not AEAD. That's only one part of it. I think the following points need clear specification: 1. How to negotiate use of AEAD.=20 The above would work, I think.=20 Or one could specify a "n/a" mac name, which is a bit like "none", except that negotiation fails if it's the output of the mac negotiation and the negotiated cipher isn't an aead mechanism. Maybe unnecessary, but it could also serve the second purpose as signalling support for aead, in case the negotiation rules need tweaking (see also next point). If defined, it should be mandatory (i.e., if the agreed cipher is aead, but "n/a" mac isn't offered, connection should fail). 2. How it interacts with first_kex_packet_follows.=20 Roughly, if everything is "guessed" correctly except the mac algorithm (e.g, if the mac name-list is empty so mac negotiation fails), and the agreed cipher is aead, the guess ought to nevertheless be considered successful. The details must be made crystal clear.=20 (And I'm open to tweaking the rules in other ways too, if new rules are reliably signalled via some extension or by the "n/a" atom; it's unclear to me if the first_kex_packet_follows logic really needs to depend on anything else but the agreed key exchange mechanism and maybe host_key_algorithm (I think I can argue that it's independent of host_key_algorithm: Every reasonable keyexchange algorithm needs input from the client, and the key exchange signature must depend on that data. Hence the first kex packet should be independent of the signature)). 3. If and how to encrypt the length field.=20 My strong opinion is that it ought to be encrypted. A spec for AEAD in ssh should either specify fully how to do that, or give clear guidelines in case some details must be left to the specification of each AEAD mechanism. Roughly, one should use an independent cipher instance (distinct key or disjoint nonce sequence or distinct ctr value) to encrypt the length in a ctr-like mode. 4. What the "block size" used for padding purposes (RFC 4253, Sec. 6, "Binary Packet Protocol") should be.=20 AEAD in the abstract doesn't expose any block size, so I'd be inclined to say that we should always use 8, the ssh minimum. One could tie it to the underlying block cipher if there is one, but it makes little sense to me, given that it's the length *including* the length field which must be a multiple of the "block size". And with AEAD, the length field has to be separately encrypted, so by the current rules, we're always going to be unaligned anyway. 5. Precisely which bytes go into the AEAD nonce, data, and plaintext, when processing each packet. Perhaps we should first take a step back and look at the binary packet format: uint32 packet_length byte padding_length byte[n1] payload; n1 =3D packet_length - padding_length - 1 byte[n2] random padding; n2 =3D padding_length byte[m] mac (Message Authentication Code - MAC); m =3D mac_length For AEAD, maybe it's better to think about it as applying the padding to the *plaintext*. Then the plaintext input to the AEAD algorithm would be byte padding_length byte[n1] payload; n1 =3D packet_length - padding_length - 1 byte[n2] random padding; n2 =3D padding_length These n1+n2+1 =3D packet_length bytes of cleartext are transformed using AEAD into packet_length+m bytes of ciphertext including an authentication data. For simplicity, drop all requirements on the padding length except keeping the lower bound n2 >=3D 4. The packet length field is encrypted separately producing 4 bytes of encrypted length preceding the AEAD ciphertext on the wire. It can also be included in the associated data, before or after encryption; I'm not sure if there's any real benefit in doing that, but it might make it a little more robust. The existing RFC 5647 on aes-gcm is unclear on (1) and (2) (and apparently not implemented that way in openssh). I disagree with its choice for (3), this has been argued on the secsh list recently, I'll not repeat it here.=20 I think it gets (5) right (without deep thinking about it. I note that it departs from RFC 4253 by not including an explicit sequence number in the authenticated data). For (4), it specifies that AEAD plaintext *excluding* the length field must be a multiple of 16. Which makes some sense, but (i) departs from the original rules, and (ii) is of little benefit, since gcm doesn't require the input to be an integral number of AES blocks. Openssh's chacha-poly1305 is also pretty important. I don't have their details in front of me, but at least the length *is* encrypted, using an independent chacha instance. And it doesn't agree with the (later) definition of chacha-poly1305 in RFC 7539. In short, to write a good specification will require some non-trivial amount of work. And I think it's pretty important work. Do you agree? Are there any objections to the above direction? (I already know some dislike encrypted lengths). What are the chances to reach rough consensus? 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 Mon Feb 1 23:21:37 2016 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 903D91A88D7 for ; Mon, 1 Feb 2016 23:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] 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 SqCS7fG_XKk4 for ; Mon, 1 Feb 2016 23:21:37 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 E80671A884B for ; Mon, 1 Feb 2016 23:21:36 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A40B885E8D; Tue, 2 Feb 2016 07:21:34 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 509DE85E81 for ; Tue, 2 Feb 2016 07:21:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id LsZ0HpNS17Oj for ; Tue, 2 Feb 2016 07:21:31 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:747]) by mail.netbsd.org (Postfix) with ESMTP id 2CBFA85DFE for ; Tue, 2 Feb 2016 07:21:27 +0000 (UTC) Received: from DM2PR0501CA0014.namprd05.prod.outlook.com (10.162.29.152) by BY1PR0501MB1382.namprd05.prod.outlook.com (10.160.107.140) with Microsoft SMTP Server (TLS) id 15.1.396.15; Tue, 2 Feb 2016 07:21:24 +0000 Received: from BN1AFFO11FD020.protection.gbl (2a01:111:f400:7c10::169) by DM2PR0501CA0014.outlook.office365.com (2a01:111:e400:5148::24) with Microsoft SMTP Server (TLS) id 15.1.396.15 via Frontend Transport; Tue, 2 Feb 2016 07:21:23 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.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-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD020.mail.protection.outlook.com (10.58.52.80) with Microsoft SMTP Server (TLS) id 15.1.409.7 via Frontend Transport; Tue, 2 Feb 2016 07:21:23 +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; Mon, 1 Feb 2016 23:20:59 -0800 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 u127KvD88823; Mon, 1 Feb 2016 23:20:57 -0800 (PST) (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 2599211446; Mon, 1 Feb 2016 23:20:57 -0800 (PST) To: Niels =?utf-8?Q?M=C3=B6ller?= CC: denis bider , Stephen Farrell , , Watson Ladd , Daniel Migault , Curdle Chairs Subject: Re: AEAD in ssh In-Reply-To: References: <1361670077-596@skroderider.denisbider.com> Comments: In-reply-to: Niels =?utf-8?Q?M=C3=B6ller?= message dated "Mon, 01 Feb 2016 22:55:40 +0100." From: "Mark D. Baushke" Date: Mon, 1 Feb 2016 23:20:57 -0800 Message-ID: <62946.1454397657@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1AFFO11FD020;1:spHX7i9b9qLRG929P4rypF5psOzhI9sfn3ttQxczmGtektB/qSVaF5wj5nexzX9r8qrdEJdUAhLXEHgrbgz9K6GO/bHP9fLJ76k+ie1RzzchFg0gUnk7ocSgKXvmaDgG2OWQI9jDKww8dvQXx9cZkE0BSBtXP/fWQs6KxQAfmeebwmMJxesAXn61eUsczANyCsuCkccKR20AX3Udk4WYxdYtYI236P4zxLo1tTlf/QrRxWi2mhIbpqrfVXLlK5EAT+R43aFaJlzv6Wvn7p07SMv/qRlZ7yceJtT3Eyu7cUO8qA/mIah6n4YgsC4Kqhfk/AMBTbZoLv54Nfh5x4Fuf4WPQTOAbFzV9oMGog/Ikx1igVVRIV4G5BXXxzED/Zsi5i6cgIo0awmOuac9n/qY/rllObrh2FWgkIMfMZpkFIzcZ8QwGj/9pl3rf/nyOesT X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(189002)(5001960100002)(189998001)(50466002)(6806005)(54356999)(76176999)(1220700001)(1096002)(105596002)(86362001)(4326007)(50986999)(110136002)(3470700001)(106466001)(47776003)(586003)(2810700001)(3480700001)(117636001)(53416004)(76506005)(87936001)(5003940100001)(2906002)(11100500001)(48376002)(77096005)(92566002)(5003600100002)(2950100001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR0501MB1382;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1382;2:BdbGud63yEVXvA94wOChhb3TtirynCq+Vp9Ye76y18nhPniq6h+ukOp7r2hQitlC/BuoE36p++Iltonx1MC2l3ydBtIeaA6QF6dBTKpY1YAWRMneBAs06sUngb0ETACL+XGcB1d+wAXx1iJpOTLtZQ==;3:sKOnIDXTEeUhtIeJhBN4ZZ4VCEbM03w8pDRilGm4R0zkTk2KJGYIOa8gJxjVRp5ZL2ZrGWiupW9jdP3T4K/9q4VcTuDYgyCEIFVU4HABlG6Omr9YZiVv1LYbYIJTFUIbuhliO07xCmM7DcPEyuVwpNbv5WTMq6aDqjDC0L6i3X48agGQYYYh+TrBjQliZFueINFjytmcGjSjYjOndwFJc2BYqPjwQ9rxn2m6k85sqKg=;25:tRslGsQ6fQ9k61Uj4zP9VJxugO0bthKu1PciDvj1Zvksq5jnjAu5WqmpctCvQLKuSaOD/2pwogKGgacZhAjBv01KScqioGEMHY/khp4+HBV+9a4vMaMUvJMg5vDxnwE19bdU1/rgBaxLEghtSkO6kjjuW87+v8kx0uDODgru1G3SXOvv4JNJNFtRiZ5wLiPA0UA2ooKU5dzLyEmq/9JIlxzMl3f9y9bsuVYo69OT64i1O0XF2OLWJfcptCgZhNGm X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382; X-MS-Office365-Filtering-Correlation-Id: 130ef2ff-5109-4508-10ba-08d32ba174d1 X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1382;20:3M/M7mn+/N3IBUIoXGfexk6gHNBXVbV3cAMRfHnGzsrPWwTsPtsHd/Sb28CI/ZKSjNAboM1lJZoeQLOutuiWCIy2Xb0i7OrxK0b+MhLfDp7uF5QbE1kbVSB8Ek4+22XDR3bg0WaNQt+UD+JvqQtoXZP7CPMuczR1JKm+h5+f36FGuUBy2r9DSltyOVvUr6FeJO7hgEDRc9vzS8fgw4lIfmovXY4mnXnBSRAN/58EsWLuoKVncf+UdIYnVrbwk91s4Abd4rw6qlfN6BuIO0Q03inqNpaut2pKRzGQdMtUNN2+3PKTIGl/ExlRVHx/rvdFYeWvHfNOvkknmvjLDpGTf7rfVIdiAWuMOGkbvDh40ivtydaIucDLpD/fQWpuKYf+gjZRpCb62TQcgVsVwhwe0dm9Bvry7tfVQsAUu+ZpQhm9hQtaC9GRqytO62S9mAvHCba0N6SuMX4Mu++Odvuk9RTTmcz88Tn6rM3NOuGBUl+9zzfz1WCprNp89UwWtiqG X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13024025)(13017025)(13015025)(13023025)(5005006)(13018025)(8121501046)(3002001)(10201501046);SRVR:BY1PR0501MB1382;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1382;4:jrVaWji0plywoSLD827res1AQ+5ofMIyy+ij2SIYiIUFDJZRK/NdSq9HP6tMmVQRgrVIi87reQ6pv2sg1dHQJyHZfIf0aB80SFq+gvkgFfk6AcpIHCFsEG/XdkfVPQ9DgicJWbrem/UK8cyPa9M7KNL2DGYkUuNfHfFpzDp22b7296QEM2MxhIHbZTTRvIYnfgJo7Hxhk/2R0wxXwLIgDc1Xgldi28xieg5LRnMUvAxSQFo0T22452HrjonmACZ1kcNMDzGXiqTe8WS/YncxXcErnhH/vaqb4DGsu9B6J9+lLPVcyhVOjG87Oe6Rumjd2dhYpNd+9kAHW8NHQnyYriQV/C8B+YqVecHzccmT4cfqFzY4NS0rE8/+H3tG3GrlQLT3HZgUB9U2X/biL/aCCoC4GXkjFBwmyWzjowqJBW2mgiwfS90T7eXk6ikucQ3Mu8g6TtxenOxMoX8NR/RSEw== X-Forefront-PRVS: 084080FC15 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY1PR0501MB1382;23:nR+2bu4AOjGzsioyhjvbblw1o11a/ggckrSiyAX?= =?us-ascii?Q?Xjye610fwWB5bjULUEH9I5X8dEX2crUZsFBo7FMAKbmZXXs31BXvox33/6nb?= =?us-ascii?Q?oGfzJqr81eyNW4HJlSdpFYck5VmnhyKCJXVoAxAICRURTl7QxgIEGlqoUzo0?= =?us-ascii?Q?0nQz7dLsXVO93wsnH6TcyGlIZnIuPMhjxYSGlL/kGcUvjgWS10dSpXQxwVUM?= =?us-ascii?Q?a99VKFVmX4SH9qPz+AQC1mzd5JM8zVV/qcxd9aRQAeMBEIMrSdy+pBwGh/ov?= =?us-ascii?Q?13CQsLU2uMvkUMGx86t4tFkFcKkZC5cMSsZs5hwuH17ZX3227a7GJvD81dhK?= =?us-ascii?Q?U7POiZvNwE1qjAbUYPwVtdURibhwcLrnvy5V0n4VbctVrXQ9YscQdfHzc0fY?= =?us-ascii?Q?qu8XfeJak69aFmc+AgoCt+YSiD7dCxAswb6dwriCddsutoiMW1l0Y6455THo?= =?us-ascii?Q?bO0fzQ+gD4qC3uX6zzL9uP3Bn1kh0Gv/2eQ3sO0KWKAhr0FP84mdipecCHdj?= =?us-ascii?Q?wdb/5dUWk/0pLOZaqY6nLqwWuXJqJGclkwFxxaYPXpwmhyFvM6kmk+GBDBus?= =?us-ascii?Q?sH1H2Je26L5K20i5P5LpeNlKsX098BzIvneCbt7K7oDnpsZwCT87uWXMPHvj?= =?us-ascii?Q?jRP9wiQBvl1U8MNEvIaFP2m1MYpPqyWj8DG5tjhJlVxZMmRLNjBke9kaFnDA?= =?us-ascii?Q?/K3TJ/QvGiH9qD/BTajQGNkhe5C6DY4JFDRBKnfGa4qI88LfY7DuaXtaM/dt?= =?us-ascii?Q?Y7niyezyTVroTtKhSZztnztLbO1M84ueNA/Xskyz+J6gQw57X2Yi59c+nfXl?= =?us-ascii?Q?+rzDFCdNmucO/aYFiLFF9WRx2zoEs1S87QjCPBsIetfGuYX7KSeFmd1Qwevu?= =?us-ascii?Q?t5yCb/tOFk4Gemxu6+GJ0dgxgkHSSxpznEl0sEJc0hxvcUKhEQ4cxXoKKG18?= =?us-ascii?Q?BgJn2PegiiZOfAl2IfI1/M/WWL1gQ+yLqpYaAtORLfg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1382;5:6Pta7Wg+O2c+7dC0LXDyuuW9e7052m54Bz4l/EuQwNYFNkmads8DRouCJ+7FApp5PH+GUSxksXlDfeG56a7+2CB3vcGe58GvWLWNuhb8MfIsFqGBupUHB2xvN9V9XqbibHYxkWjww0mxbmPl8racEw==;24:4bKM7sYxqa7KQnswOs4Kb/BWjbCzZSxjoSDLesr242vZEXOLJWK5GRliszg5MYF0NGfpkxsSjcLfS/n/KDOqJw46dCWReilt4m52O2r914g= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2016 07:21:23.5371 (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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1382 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Niels & denis, > 1. How to negotiate use of AEAD. Rather than "n/a" as the atom, why not "AEAD" or "aead" so we are clear about the intent? That said, I am fine with ignoring the Mac if the 'Cipher' is an AEAD like the OpenSSH folks do if that is helpful. Technically, aren't both AES-GCM and ChaCha20-Poly1305 considered to be Authenticated Encryption with Associated Data (AEAD) rather than being either a Mac or a Cipher directly? > 3. If and how to encrypt the length field. +1 on encrypting the length field. fwiw: I agree on the overall direction you have written. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 2 22:16:39 2016 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 165041A21C0 for ; Tue, 2 Feb 2016 22:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] 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 BA1f6PEaH6lf for ; Tue, 2 Feb 2016 22:16:37 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 9C4251A1E0E for ; Tue, 2 Feb 2016 22:16:37 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5C46785F8A; Wed, 3 Feb 2016 06:16:37 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 183BA85ED4; Wed, 3 Feb 2016 06:16:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7474885F82 for ; Wed, 3 Feb 2016 00:30:13 +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 Qf9Qg_8XwQaq for ; Wed, 3 Feb 2016 00:30:13 +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 F2F2084D04 for ; Wed, 3 Feb 2016 00:30:12 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Wed, 3 Feb 2016 00:30:10 +0000 Date: Wed, 3 Feb 2016 00:30:10 +0000 Subject: Re: AEAD in ssh X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1716151008-2716@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?NielsM=C3=B6ller?= , "Mark D. Baushke" Cc: Stephen Farrell , ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-Fps+BiSOzwpT/qZ2D6zj" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-Fps+BiSOzwpT/qZ2D6zj Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with Niels and Mark. I have recently implemented AES-GCM, and I find the choice of unencrypted l= ength fields dubious. It negates any means of obfuscating the lengths of so= me packets using SSH_MSG_IGNORE.=20 The alternative - to encrypt packet lengths using a parallel construction -= seems much preferable. ----- Original Message ----- From: Mark D. Baushke=20 Sent: Tuesday, February 2, 2016 01:20 To: NielsM=C3=B6ller=20 Cc: denis bider ; Stephen Farrell ; ietf-ssh@NetBSD.org ; Watson Ladd ; Dan= iel Migault ; Curdle Chairs=20 Subject: Re: AEAD in ssh=20 Hi Niels & denis, > 1. How to negotiate use of AEAD.=20 Rather than "n/a" as the atom, why not "AEAD" or "aead" so we are clear about the intent? That said, I am fine with ignoring the Mac if the 'Cipher' is an AEAD like the OpenSSH folks do if that is helpful. Technically, aren't both AES-GCM and ChaCha20-Poly1305 considered to be Authenticated Encryption with Associated Data (AEAD) rather than being either a Mac or a Cipher directly? > 3. If and how to encrypt the length field.=20 +1 on encrypting the length field. fwiw: I agree on the overall direction you have written. -- Mark = --=-Fps+BiSOzwpT/qZ2D6zj Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with Niels and Mark.

I have recentl= y implemented AES-GCM, and I find the choice of unencrypted length fields d= ubious. It negates any means of obfuscating the lengths of some packets usi= ng SSH_MSG_IGNORE.

The alternative - to encrypt packet lengths usin= g a parallel construction - seems much preferable.


----- Origina= l Message -----
From: Mark D. Baushke
Sent: Tuesday, February 2, 201= 6 01:20
To: NielsM=C3=B6ller
Cc: denis bider ; Stephen Farrell ; iet= f-ssh@NetBSD.org ; Watson Ladd ; Daniel Migault ; Curdle Chairs
Subject= : Re: AEAD in ssh

Hi Niels & denis,

> 1. How to negot= iate use of AEAD.

Rather than "n/a" as the atom, why not "AEAD" or = "aead" so we are clear
about the intent? That said, I am fine with ignor= ing the Mac if the
'Cipher' is an AEAD like the OpenSSH folks do if that= is helpful.

Technically, aren't both AES-GCM and ChaCha20-Poly1305 = considered to be
Authenticated Encryption with Associated Data (AEAD) ra= ther than being
either a Mac or a Cipher directly?

> 3. If and= how to encrypt the length field.

+1 on encrypting the length field= .

fwiw: I agree on the overall direction you have written.

--= Mark

= --=-Fps+BiSOzwpT/qZ2D6zj-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 2 22:20:54 2016 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 6DC7A1A6EE0 for ; Tue, 2 Feb 2016 22:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] 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 MiFEADmH22t8 for ; Tue, 2 Feb 2016 22:20:53 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 508C81A6EDB for ; Tue, 2 Feb 2016 22:20:53 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 59FEA85F8D; Wed, 3 Feb 2016 06:20: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 714EA85F8B for ; Wed, 3 Feb 2016 06:20:50 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id R_5cjBjjoH2y for ; Wed, 3 Feb 2016 06:20:49 +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 62F4885F82 for ; Wed, 3 Feb 2016 06:20:45 +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=1454480450; x=1486016450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jKaWh0H672A3xmdQMTr3K8TpBFwdboIkSMvMvKf29m0=; b=vvWRfG/gu3NSTjEACWO9jMxlerGZC/HiCSOhII6zgLuN3b7fSCI7pfzP H47a49bluV9thu50Pmt5LQcKHzVcAvXSiOMFOUJuFDMVkDXeEjAOGqQgS SyWA2DaGCKTU363OkgxOf9knwDmVc5tKoUbsZMYN6IHWRBGEg+LBoxda0 2ru3WcYd6vikK4UMMwtOrY6sVrzfti1t2g35e8sE9bn9QLHcMtCUlPlhz KNsmgOiOyCp1WS3ofwrQieZkD13bEPnawQkbFY/0pDmLJJ3XzWfCmDUI9 4rff6jxrgGyd4A+p0x2JInuxOzlfnpG+6Dnp35z2FbhWubOfv6Tf7OpqN w==; X-IronPort-AV: E=Sophos;i="5.22,388,1449486000"; d="scan'208";a="65960112" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Feb 2016 19:20:44 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Wed, 3 Feb 2016 19:20:43 +1300 From: Peter Gutmann To: denis bider , =?iso-8859-1?Q?NielsM=F6ller?= , "Mark D. Baushke" CC: Stephen Farrell , "ietf-ssh@NetBSD.org" Subject: RE: AEAD in ssh Thread-Topic: AEAD in ssh Thread-Index: AQHRXhoJELa8nioDCUCatba065Wr958Z2YzN Date: Wed, 3 Feb 2016 06:20:43 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BE1D90@uxcn10-5.UoA.auckland.ac.nz> References: <1716151008-2716@skroderider.denisbider.com> In-Reply-To: <1716151008-2716@skroderider.denisbider.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >I have recently implemented AES-GCM, and I find the choice of unencrypted= =0A= >length fields dubious. It negates any means of obfuscating the lengths of = some=0A= >packets using SSH_MSG_IGNORE.=0A= >=0A= >The alternative - to encrypt packet lengths using a parallel construction = -=0A= >seems much preferable.=0A= =0A= See "Peek-a-Book, I Still See You: Why Efficient Traffic Analysis=0A= Countermeasures Fail" by Dyer, Coult, Ristenpart and Shrimpton. The=0A= conclusion from the research: It's completely pointless, none of their atta= cks=0A= even bother looking at the length field, so encrypting it is entirely=0A= irrelevant.=0A= =0A= Or, more importantly, it offers negative utility in that it makes processin= g=0A= much harder and has led to exploitable vulnerabilities in the past.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 2 22:40:11 2016 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 6B3BD1A6F3C for ; Tue, 2 Feb 2016 22:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 Y9Wq96lalSQ3 for ; Tue, 2 Feb 2016 22:40:10 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 6A8C11A6F38 for ; Tue, 2 Feb 2016 22:40:10 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2552F85F94; Wed, 3 Feb 2016 06:40:09 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4D95985ED4 for ; Wed, 3 Feb 2016 06:40:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 2UzpA4GO2D0y for ; Wed, 3 Feb 2016 06:40:05 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::795]) by mail.netbsd.org (Postfix) with ESMTP id C11D784CF5 for ; Wed, 3 Feb 2016 06:40:00 +0000 (UTC) Received: from DM2PR0501CA0040.namprd05.prod.outlook.com (10.162.29.178) by DM2PR0501MB1390.namprd05.prod.outlook.com (10.161.224.12) with Microsoft SMTP Server (TLS) id 15.1.396.15; Wed, 3 Feb 2016 06:39:58 +0000 Received: from BL2FFO11OLC010.protection.gbl (2a01:111:f400:7c09::171) by DM2PR0501CA0040.outlook.office365.com (2a01:111:e400:5148::50) with Microsoft SMTP Server (TLS) id 15.1.396.15 via Frontend Transport; Wed, 3 Feb 2016 06:39:59 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; 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-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11OLC010.mail.protection.outlook.com (10.173.160.154) with Microsoft SMTP Server (TLS) id 15.1.409.7 via Frontend Transport; Wed, 3 Feb 2016 06:39:57 +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; Tue, 2 Feb 2016 22:39:55 -0800 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 u136dtD21537; Tue, 2 Feb 2016 22:39:55 -0800 (PST) (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 145B611446; Tue, 2 Feb 2016 22:39:51 -0800 (PST) To: Peter Gutmann CC: denis bider , =?iso-8859-1?Q?NielsM=F6ller?= , Stephen Farrell , "ietf-ssh@NetBSD.org" Subject: Re: AEAD in ssh In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BE1D90@uxcn10-5.UoA.auckland.ac.nz> References: <1716151008-2716@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4BE1D90@uxcn10-5.UoA.auckland.ac.nz> Comments: In-reply-to: Peter Gutmann message dated "Wed, 03 Feb 2016 06:20:43 +0000." From: "Mark D. Baushke" Date: Tue, 2 Feb 2016 22:39:50 -0800 Message-ID: <32597.1454481590@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11OLC010;1:VY/0aMWNu5Jnh/nXcCB3RX2bx6VZzlzN+WB7R76pt/G+We6EAlBQwNygZHlr7yx+NumpHybEygekfiobDghzMSs1toN/vBqSZOUy3Rm/kLysXAorKMfG9wRnHJ57UHQ/xbV5kvMIhprrqKXv4lbwy8OSH+sjLY1VOYn3Z/o+Iz+m91nJV7olbZmMAePQpbBwtEFO0EaIpbE6ppH70C6GY9Ev8WbtsMG7qcYbwaUk6MSGFocFjE6QtQDEtEKX5rtHuLudNfbfACwD2A6q5GeYsNMXcivFioP1IHHAwX1JoN++aTQYPN0Kj4hOkIOyeux/d6BjPHr/KS9dbe64Z2o+ft7OKeYQhM+2FT+LXL8OiTBi3MXOaeqP9MyOHusSt2GST4vSjb/iVNgt/6pROLBBkSGM3nJqQML1iPq7kKkIyPbXZ+gR6qDXM4U6WyMRxieh X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(24454002)(51914003)(189002)(5003940100001)(50466002)(4326007)(105596002)(2950100001)(3480700001)(5003600100002)(5001960100002)(87936001)(92566002)(106466001)(11100500001)(110136002)(77096005)(2810700001)(189998001)(117636001)(48376002)(1096002)(2906002)(6806005)(50986999)(76176999)(54356999)(586003)(1220700001)(76506005)(53416004)(47776003)(86362001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0501MB1390;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1390;2:G6kxm87Gl/5YdtZL+fm/uHujNT0xma5l2xzvr6isxteI8yRKnGjh9PVpzSatviAFwPMCEPFZGL7Lbz9C3O63Ss6MioaNM1IPuyzgco/l3hdh3XbRXkm7h3vf+/v3KUDYKqdFsb+AThIaswxPga5NlA==;3:b0BEtDoTHQfg4sKEbgdYXI70VDuQ3mA+lYZP4M03WXfBjD6ltdEzDXBhgDw5rRYD1iv8xT8ZUJ8Keni049XGP3G/FX6+UeY1b7g4bHrz3EagOry0XgpG9TP1Fi+I07KCEItSXa73tNnE12IroSM0m+a83D0Al86vLRcSBC7Lx9cE6grfezTd+0Pn+XbhqByZCFCP8aqYIYouXvaKNUcFt5JLjBE0NcZdME9zhCAJy1c=;25:A0rJM98fTjDEHkpy3MKztrjajl9M0vr+ZiWZxDY+Y67n8UHP+3k/yAvjfE3Rrn2r+oZwzphi7cyaSasbFncGkv4GxZx1dpLF1yj4VtsJ3QZ0DziOcuCJhczCe/Y+MpGxxgcKOBePDfmZN83/HtBlDJZ1bFOsjbitAs5iIoTIAFnleWL7suAY73AYUWM+p4rOD0dyVb84HRX4s4FkiUCNEV7nAx7X02FCIEukOn6CFsVtH/HzLoojzgWBvDs34LNM X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1390; X-MS-Office365-Filtering-Correlation-Id: 6141f048-5c58-4509-0080-08d32c64d527 X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1390;20:hbxjLNV0GhxsGgtncCeRRvMpfxAif9Tl9/g/mW/YqQ4zs28Z5YpyCKDJjwSxWP66LUJBghpVGuhWke5EpsvjxpPMSg0BK3hDt+YeT2+Vuyzw37F7NJ6ibl0iFX01tK0rek0xsWCqPumL/jn0nPUcgJoyVbEeA1WtXmfxn2q4X42Z9dgzrAuDu1r9SWZmCQ2ioxixFvK5/MvkxWI2WCJfXIcq9cctwqGOUd7vCdYpIS2ZDUi6Tzaqy7MURkT0IsJxEnC9H1jz6ssgILgK07CDcjbZ5EbU5dHQxZMni2ye2p3u+EBa/BU6INcq/ytCDfyp2c0jPpEDFQxmkx52JzspC/i3g8P6a65CiAGKksLjY5UkdVlauoYqD/1DERJzAEhnrpfa+SjUcLRli6YYAzczGVG7JgqS9gIcllqANWOtZFZYSL1VTh0hbaRe82g3SfzUpTq83LMGFn880gfFj4jrLLF7vQXFqSKdt5++EqNRxLecApZKX7I5sG5oY+g6wm40 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13015025)(13018025)(13017025)(8121501046)(13024025)(13023025)(5005006)(10201501046)(3002001);SRVR:DM2PR0501MB1390;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1390; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1390;4:vYkMjMXZ9zFvt6tqK5Cf0hiZPrc+9J1zF24AUeFkW2ugyCF9IY/VUsrxGvj5w62I3QJsCjr0FSTTP/kEQ/Qj42o1boDwSR7c63k9iaY6D0pKYfw0yvDAPk6Z/FE7TxnF1OSdIJO+o76urocMkCAPF6HXYkl88QE17fOgnjx+kiPLUb6kxQCRop5fB7H9bXpzldLNYf5TCaUWCq1PAfO7Y4spwU3Xo72GIjcI+Y1D3rkSdAqOLcZ7YHCHfQsnrN/jo6GJKXcOXS74HosQJmVymXEZz5Ufo/6o0Vh9kipRbkgYid8217yh/eWWVqRDPU4L80MWJTpK1hchtTdOMZhDFa0IjJPCb756zNrne+T5Y4gEYk7o6bi3g2tf+wfULqLcIRTOlduShE/yvtmBoeCgdJecJbkTcwoR+MVTdFokDuu6PtdyMjZqbceN3eKM+SvVinCsl6fuCq0tTiJLuFB+9A== X-Forefront-PRVS: 08417837C5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM2PR0501MB1390;23:h6dbM5gdZrFRb4DayfXB/j6TEwdLnfbV+weMB5Y?= =?us-ascii?Q?irTGKC/Fdy97NGmZeNx4L0kcRNBMxsFzEGYTQjQgBVY7QGd0k6XLkZkvHBBh?= =?us-ascii?Q?QAzm3VkksgqE3wvHmWae+HH5JwyL1tUy0qhz61aqPyycIfUc+74wVpzFbdNr?= =?us-ascii?Q?HYPSQhBRcFVbDIRKfHTIEtm8116izUYyvYbmyHF0NcuGRxf3g7TjoPfG5ZkS?= =?us-ascii?Q?xafANaP40kWbsKYbXs+Dv3b2TFAyOwmfd2zctekc3RlJSI4wrXdquLQBRNXY?= =?us-ascii?Q?s6rd49LrfxK8QzPYiWPhswQkP1FuC6APWEHzQecAzAG8ovsWBetlSAUUQqK+?= =?us-ascii?Q?6aj5a8WBSHPUyLywK4F/3kJ1LS/BRhetA1lsbg81BDcGwvlYFmR3p8APVE3j?= =?us-ascii?Q?felLLbIqZ93c4sLd2iVcQUhEq4dcssbT49aWO65Xb7+ai4rYX00RQVZTuOSx?= =?us-ascii?Q?j/x/agq5yHkD7M4Y1jScW+ZTuUKypaxqYAnJZfQhnK1uRi9PiOPrSvhjCz0h?= =?us-ascii?Q?pxYDTcdTEPBv18+zRpUVWofajvT9vjC77oSuNzxbJ1kSgu0HEB6xfvCg1MjH?= =?us-ascii?Q?KtXWIxma+stOa6urAxOPRnbRqyYLcroAzCFq/Oxp3afRZonGbA+Tsi+eO8tB?= =?us-ascii?Q?vU3D9QYq+AhpD21z3oMTmM/h4GdLXYawxl7u2R8HvZoOY+nSxxIY8pzDrmt8?= =?us-ascii?Q?OPWYh65Tk0aHcutn17PrUTZmoVS9t8goTfWpZr1ZSvkq2bYSTcH/9FIywroQ?= =?us-ascii?Q?/k7gGjyNSFLhKUNeG/bG/ldddfIj7fHffjrQH1Cc5WrqLHOyQXH4ghPXO8NY?= =?us-ascii?Q?we1ZbfT/ZkjeCM0xqjR6FctT1XURwpNPvQj80lfyMmzQdyrcWH9+61iW/R+a?= =?us-ascii?Q?WzirJk6jCHyKepBOagPXRPr45cyxDBdoMhUha7NlqZBDVoE8AIUnbCTBbprO?= =?us-ascii?Q?CVskS7ebMY1Iq9OBgMfUbVvNXYN9RQUNfcxvZidmMPnHaDZNjfDjfzZXhgGp?= =?us-ascii?Q?Mgvc=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1390;5:1+jTXii28w3NfNw4G+90dILHRUrhRKez0026dzxOU6LZDgb/82WobWvRs4HjcgtPwfYzdQEf4TW6q73tbH0mQYtQa02bpVPF9u8rBCNR5dJjTqExfFIuLbJCWrPMwCDq8pn7jrS+NoDQL2RmVnXJpA==;24:MBfPI8Y7X77QYSkb8E8sQfmcr48NZqmfAuFbnPifOY8MK7hETgUwsBvAMZ28VVxdn2GqNjhvugPNfLh6fXDzMVXT1UQkOXm0SuzsNByNPXw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2016 06:39:57.0238 (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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1390 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Peter, Peter wrote: > See "Peek-a-Book, I Still See You: Why Efficient Traffic Analysis > Countermeasures Fail" by Dyer, Coult, Ristenpart and Shrimpton. The > conclusion from the research: It's completely pointless, none of their > attacks even bother looking at the length field, so encrypting it is > entirely irrelevant. Many thanks for the pointer to the document. At only fifteen pages, it packs in a lot of useful information on Traffic Analysis (TA) countermeasures for web sites into a single paper. > Or, more importantly, it offers negative utility in that it makes > processing much harder and has led to exploitable vulnerabilities in > the past. I do understand that processing is much harder and that exploitable vunlerabilities are an issue. I am not sure that the TA for web page traffic directly maps to the SSH TA threats. That said, the paper does raise questions about how to effeciently use such counermeasures and requires a bit more thinking on my part. Thanks! -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 2 23:02:12 2016 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 9A3961A8759 for ; Tue, 2 Feb 2016 23:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.001] 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 cDvRYKYQ4Xmq for ; Tue, 2 Feb 2016 23:02:10 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 C1C501A872D for ; Tue, 2 Feb 2016 23:02:10 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id ACFC485F8A; Wed, 3 Feb 2016 07:02:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 66A7585ED4 for ; Wed, 3 Feb 2016 07:02:05 +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 zRdXPRkyS0So for ; Wed, 3 Feb 2016 07:02:04 +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 F02A984CEB for ; Wed, 3 Feb 2016 07:02:03 +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=1454482924; x=1486018924; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=imErJuPwH5KqpnhHDu7t6SN65q7elC68E1k7VFJ/nk4=; b=FRnWvs7dp8XXMJ0xBWS4NQZ8N7SdLl0WfXcWxc2MUhy5zXLE2jDI10cS oJ3qK432eSjaItPectKNhoojzbmgbur434FhgrCxmKAr9U0d7cdjeq77+ 3qnalwhDUhNw8IqcMMOz4urONRyz7m8Q6Af/r4OlKTvwGR1VugQbEP3nh aYbzUEEmL1/cS2r5kWBx3GkFqpCl3DgGnlhjGxn1O2eP8u/3nC8e3CKSx mBrwcnepRrpHwBLVdnWOzmkvFH9kELbLWi1j8W9pC8iKTU8v8X7CmyVOu QMRuJq4kHQUsRIXAt99MWrQZWP7byuuzsvNIDIi9mTehPffVmHc5MQ/eR w==; X-IronPort-AV: E=Sophos;i="5.22,388,1449486000"; d="scan'208";a="65962582" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Feb 2016 20:02:02 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Wed, 3 Feb 2016 20:02:02 +1300 From: Peter Gutmann To: "Mark D. Baushke" CC: denis bider , =?iso-8859-1?Q?NielsM=F6ller?= , Stephen Farrell , "ietf-ssh@NetBSD.org" Subject: RE: AEAD in ssh Thread-Topic: AEAD in ssh Thread-Index: AQHRXk22MV7ZCroVCEeHe3ab08uhCp8Z5IFk Date: Wed, 3 Feb 2016 07:02:01 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BE1DEB@uxcn10-5.UoA.auckland.ac.nz> References: <1716151008-2716@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4BE1D90@uxcn10-5.UoA.auckland.ac.nz>,<32597.1454481590@eng-mail01.juniper.net> In-Reply-To: <32597.1454481590@eng-mail01.juniper.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list mdb@juniper.net writes:=0A= =0A= >That said, the paper does raise questions about how to effeciently use suc= h=0A= >counermeasures and requires a bit more thinking on my part.=0A= =0A= It was a real eye-opener, it points out that the simplistic mechanism built= =0A= into both TLS and SSH for (attempting to) defeat traffic analysis pretty mu= ch=0A= doesn't work. There's been a bit of earlier work in this area (the work on= =0A= Bayesian classifiers, notably used by the Tor folks) but this is a 2nd-gen= =0A= study that looks at how to defeat countermeasures that that initial 1st-gen= =0A= work inspired.=0A= =0A= I agree that there may be issues of applicability to SSH, but a bigger=0A= question is the usual WYTM (what's your threat model), you need to figure o= ut=0A= what you're trying to defend against in order to evaluate your defences. I= t'd=0A= be nice to have some rigorous model like the random oracle model or standar= d=0A= model in crypto. The pad-the-packets approach doesn't really have any thre= at=0A= model except that it seems like a good thing to do, what they've pointed ou= t=0A= is that it's ineffective against traffic classifiers. Hopefully there'll b= e=0A= more work on this in the future (although the previous papers were from 5-1= 0=0A= years ago)...=0A= =0A= The tl;dr version, from a comment in my code:=0A= =0A= Padding in order to defeat traffic analysis is extremely problematic. Th= e=0A= simplistic approach of adding random padding provides little more than wa= rm=0A= fuzzies since it falls almost trivially to statistical classifiers like= =0A= Bayesian or support vector machines. In fact almost any attempt to defea= t=0A= traffic analysis with low overhead, including random padding, linear padd= ing=0A= (padding to the nearest 128 bytes), exponential padding (padding to the= =0A= nearest power of two), mice/elephant padding (padding short packets to 12= 8=0A= bytes and long ones to the MTU), straight padding to the MTU, and padding= by=0A= a random multiple of 8 or 16 bytes, doesn't work (see "Peek-a-Book, I Sti= ll=0A= See You: Why Efficient Traffic Analysis Countermeasures Fail" by Dyer,=0A= Coult, Ristenpart and Shrimpton).=0A= =0A= It's only when quite complex traffic morphing, sending fixed-length packe= ts=0A= at fixed intervals and the like, is applied and reaches an overhead of 40= 0%=0A= that things start getting tricky for an attacker, or at least an attacker= =0A= using a straightforward Bayesian or SVM classifier.=0A= =0A= This doesn't leave much choice in the way of padding, since no matter wha= t=0A= we do it won't be terribly effective. The best option is to choose the= =0A= variant with the lowest overhead and use that, since it has at least a sm= all=0A= amount of effect. This is linear padding, but we pad to 64 bytes instead= of=0A= 128 because we're typically used in embedded environments which both use= =0A= shorter messages and often have bandwidth constraints.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Feb 3 18:59:32 2016 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 AD27F1B38D0 for ; Wed, 3 Feb 2016 18:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] 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 5vWMBIsABY-t for ; Wed, 3 Feb 2016 18:59:30 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 802D61B38D2 for ; Wed, 3 Feb 2016 18:59:30 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3F81985E91; Thu, 4 Feb 2016 02:59:29 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EF52885F13 for ; Thu, 4 Feb 2016 02:59:22 +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 mSj63RufG6hW for ; Thu, 4 Feb 2016 02:59:22 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id A418D85DFD for ; Thu, 4 Feb 2016 02:59:19 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u141oAcB037829; Thu, 4 Feb 2016 11:50:10 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u141oAVg008955 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Feb 2016 11:50:10 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id u141o7aB025659; Thu, 4 Feb 2016 11:50:08 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 69EADA4F31; Thu, 4 Feb 2016 12:50:07 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 64FCDA4F30; Thu, 4 Feb 2016 12:50:07 +1100 (AEDT) Date: Thu, 4 Feb 2016 12:50:07 +1100 (AEDT) From: Damien Miller To: =?ISO-8859-15?Q?Niels_M=F6ller?= cc: denis bider , Stephen Farrell , ietf-ssh@NetBSD.org, Watson Ladd , Daniel Migault , Curdle Chairs , mdb@juniper.net Subject: Re: AEAD in ssh In-Reply-To: Message-ID: References: <1361670077-596@skroderider.denisbider.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="19207093747712-155405129-1454550607=:7655" X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1454550612 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --19207093747712-155405129-1454550607=:7655 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Mon, 1 Feb 2016, Niels Möller wrote: > denis bider writes: > > > With regard to AEAD: > > > > I think we should just make the following simple and clear statement: > > > > MAC algorithms are secondary to encryption algorithms, and are > > evaluated only if the encryption algorithm is not AEAD. If an AEAD > > encryption algorithm is negotiated, the outcome of MAC negotiation is > > irrelevant and must be ignored. If no mutual MAC algorithms are > > available, this causes key exchange to fail if, and only if, the > > negotiated encryption algorithm is not AEAD. > > That's only one part of it. I think the following points need clear > specification: > > 1. How to negotiate use of AEAD. > > The above would work, I think. > > Or one could specify a "n/a" mac name, which is a bit like "none", > except that negotiation fails if it's the output of the mac > negotiation and the negotiated cipher isn't an aead mechanism. Maybe > unnecessary, but it could also serve the second purpose as signalling > support for aead, in case the negotiation rules need tweaking (see > also next point). If defined, it should be mandatory (i.e., if the > agreed cipher is aead, but "n/a" mac isn't offered, connection should > fail). I prefer Denis' forumation (which matches what we in OpenSSH for AEAD) ciphers, it's simpler, harder to get wrong and less likely to fail at runtime through user misconfiguration. The only cost is that the KEX code needs to be able to easily tell whether an algorithm is an AEAD before it starts working on the MAC. The change to OpenSSH's KEX code to support AEAD ciphers was trivial: https://anongit.mindrot.org/openssh.git/diff/kex.c?id=1d75abfe > 2. How it interacts with first_kex_packet_follows. > > Roughly, if everything is "guessed" correctly except the mac > algorithm (e.g, if the mac name-list is empty so mac negotiation > fails), and the agreed cipher is aead, the guess ought to > nevertheless be considered successful. The details must be made > crystal clear. > > (And I'm open to tweaking the rules in other ways too, if new rules are > reliably signalled via some extension or by the "n/a" atom; it's > unclear to me if the first_kex_packet_follows logic really needs to > depend on anything else but the agreed key exchange mechanism and > maybe host_key_algorithm (I think I can argue that it's independent > of host_key_algorithm: Every reasonable keyexchange algorithm needs > input from the client, and the key exchange signature must depend on > that data. Hence the first kex packet should be independent of the > signature)). I don't think the first_kex_packet_follows rules need adjustment if mac negotiation is simply ignored for ciphers that are AEAD. > 3. If and how to encrypt the length field. > > My strong opinion is that it ought to be encrypted. A spec for AEAD > in ssh should either specify fully how to do that, or give clear > guidelines in case some details must be left to the specification of > each AEAD mechanism. Roughly, one should use an independent cipher > instance (distinct key or disjoint nonce sequence or distinct ctr > value) to encrypt the length in a ctr-like mode. IMO this is completely up to the AEAD itself. OpenSSH supports an AEAD that does (chacha20/poly1305) and AES-GCM that doesn't. I'm not convinced that encrypting packet lengths wouldn't contribute to an effective traffic analysis mitigation scheme -- the "peek-a-boo" paper clearly shows they are not sufficient, but that's not the same as saying that it isn't necessary, or can't help. OTOH I'll freely admit that the point is moot in the absense of a threat model and until implementations actually implement serious traffic analysis mitigations. I don't accept Peter's argument that encrypting length fields is a net negative for security. An independently keyed cipher for length encryption is never going to act as an oracle in the same way as the CBC+bad MAC order mess was. > 4. What the "block size" used for padding purposes (RFC 4253, Sec. 6, > "Binary Packet Protocol") should be. > > AEAD in the abstract doesn't expose any block size, so I'd be > inclined to say that we should always use 8, the ssh minimum. One > could tie it to the underlying block cipher if there is one, but it > makes little sense to me, given that it's the length *including* the > length field which must be a multiple of the "block size". And with > AEAD, the length field has to be separately encrypted, so by the > current rules, we're always going to be unaligned anyway. I don't think it makes sense to try to define this for AEAD modes in abstract, it's a concrete property of the individual algorithms. > The existing RFC 5647 on aes-gcm is unclear on (1) and (2) (and > apparently not implemented that way in openssh). RFC5647 is quite clear on negotiation, but it doesn't follow either scheme mentioned above (with are both IMO much more reasonable), instead it requires (section 5.1) that "AEAD_AES_*_GCM" be selected for both cipher and MAC. I think this offers even more opportunities for runtime failure and misconfiguration. > In short, to write a good specification will require some non-trivial > amount of work. And I think it's pretty important work. Do you agree? > Are there any objections to the above direction? (I already know some > dislike encrypted lengths). What are the chances to reach rough > consensus? IMO the best approach to the problem is to define the right way to negotiate AEAD algorithms in KEX, but specify the AEADs individually. If I had a time machine then I'd go back to 2000, buy a bunch of stocks and then argue that SSH2 should only negotiate complete AEADs rather than separate ciphers and MACs. I'd almost certainly be dismissed as a crank, but at least I'd be rich when I got back. -d --19207093747712-155405129-1454550607=:7655-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Feb 3 21:56:45 2016 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 EDF151A9097 for ; Wed, 3 Feb 2016 21:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.001] 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 9JUZIDAKI5Lk for ; Wed, 3 Feb 2016 21:56:43 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 10AEF1A909C for ; Wed, 3 Feb 2016 21:56:43 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0165485EDD; Thu, 4 Feb 2016 05:56:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id ADDF185E93; Thu, 4 Feb 2016 05:56:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 26B3285EFC for ; Wed, 3 Feb 2016 22:45:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id bOGVsqYTi6vH for ; Wed, 3 Feb 2016 22:45:24 +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 5117D85EE5 for ; Wed, 3 Feb 2016 22:45:24 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Wed, 3 Feb 2016 22:45:15 +0000 Date: Wed, 3 Feb 2016 22:45:15 +0000 Subject: Re: AEAD in ssh X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1796103752-3592@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann , "Mark D. Baushke" Cc: =?UTF-8?q?NielsM=C3=B6ller?= , Stephen Farrell , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-MVnyME286Ko4LaOnqXLs" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-MVnyME286Ko4LaOnqXLs Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, but this is all related to low-overhead padding. The problem with unen= crypted lengths is that they make high-overhead padding more difficult or p= ossibly impossible, also. Suppose you have a user typing at a terminal. The user types "Q", you have = to send SSH_MSG_CHANNEL_DATA containing "Q". You cannot pad that packet mor= e than 255 bytes, so it's going to be small. If your defense against traffic analysis is that you're stuffing the connec= tion with a max bandwidth of SSH_MSG_IGNORE messages, unencrypted lengths p= revent you from effectively hiding whether the traffic is file transfer, or= terminal. If the traffic is file transfer, you have to send large SSH_MSG_= IGNORE messages, or else the real data packets are going to stick out like = a sore thumb. If the traffic is terminal, you have to send small SSH_MSG_IG= NORE messages, or else the real typing is going to stick out. Sure, low-overhead padding doesn't do much. But unencrypted lengths defeat = the effectiveness of higher-overhead padding, also. I haven't actually implemented high-overhead padding, but it's something I'= ve been considering. Trying to combine that with unencrypted lengths in AEA= D would be shooting myself in the foot. ----- Original Message ----- From: Peter Gutmann=20 Sent: Wednesday, February 3, 2016 01:02 To: Mark D. Baushke=20 Cc: denis bider ; NielsM=C3=B6ller ; Stephen Farrell ; ietf-ssh@NetBSD.org=20 Subject: RE: AEAD in ssh=20 mdb@juniper.net writes: >That said, the paper does raise questions about how to effeciently use suc= h >counermeasures and requires a bit more thinking on my part. It was a real eye-opener, it points out that the simplistic mechanism built into both TLS and SSH for (attempting to) defeat traffic analysis pretty mu= ch doesn't work.=C2=A0 There's been a bit of earlier work in this area (the wo= rk on Bayesian classifiers, notably used by the Tor folks) but this is a 2nd-gen study that looks at how to defeat countermeasures that that initial 1st-gen work inspired. I agree that there may be issues of applicability to SSH, but a bigger question is the usual WYTM (what's your threat model), you need to figure o= ut what you're trying to defend against in order to evaluate your defences.=C2= =A0 It'd be nice to have some rigorous model like the random oracle model or standar= d model in crypto.=C2=A0 The pad-the-packets approach doesn't really have any= threat model except that it seems like a good thing to do, what they've pointed ou= t is that it's ineffective against traffic classifiers.=C2=A0 Hopefully there= 'll be more work on this in the future (although the previous papers were from 5-1= 0 years ago)... The tl;dr version, from a comment in my code: =C2=A0 Padding in order to defeat traffic analysis is extremely problematic= .=C2=A0 The =C2=A0 simplistic approach of adding random padding provides little more th= an warm =C2=A0 fuzzies since it falls almost trivially to statistical classifiers l= ike =C2=A0 Bayesian or support vector machines.=C2=A0 In fact almost any attemp= t to defeat =C2=A0 traffic analysis with low overhead, including random padding, linear= padding =C2=A0 (padding to the nearest 128 bytes), exponential padding (padding to = the =C2=A0 nearest power of two), mice/elephant padding (padding short packets = to 128 =C2=A0 bytes and long ones to the MTU), straight padding to the MTU, and pa= dding by =C2=A0 a random multiple of 8 or 16 bytes, doesn't work (see "Peek-a-Book, = I Still =C2=A0 See You: Why Efficient Traffic Analysis Countermeasures Fail" by Dye= r, =C2=A0 Coult, Ristenpart and Shrimpton). =C2=A0 It's only when quite complex traffic morphing, sending fixed-length = packets =C2=A0 at fixed intervals and the like, is applied and reaches an overhead = of 400% =C2=A0 that things start getting tricky for an attacker, or at least an att= acker =C2=A0 using a straightforward Bayesian or SVM classifier. =C2=A0 This doesn't leave much choice in the way of padding, since no matte= r what =C2=A0 we do it won't be terribly effective.=C2=A0 The best option is to ch= oose the =C2=A0 variant with the lowest overhead and use that, since it has at least= a small =C2=A0 amount of effect.=C2=A0 This is linear padding, but we pad to 64 byt= es instead of =C2=A0 128 because we're typically used in embedded environments which both= use =C2=A0 shorter messages and often have bandwidth constraints. Peter. = --=-MVnyME286Ko4LaOnqXLs Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, but this is all related to low-overhead paddi= ng. The problem with unencrypted lengths is that they make high-overhead pa= dding more difficult or possibly impossible, also.

Suppose you have = a user typing at a terminal. The user types "Q", you have to send SSH_MSG_C= HANNEL_DATA containing "Q". You cannot pad that packet more than 255 bytes,= so it's going to be small.

If your defense against traffic analysis= is that you're stuffing the connection with a max bandwidth of SSH_MSG_IGN= ORE messages, unencrypted lengths prevent you from effectively hiding wheth= er the traffic is file transfer, or terminal. If the traffic is file transf= er, you have to send large SSH_MSG_IGNORE messages, or else the real data p= ackets are going to stick out like a sore thumb. If the traffic is terminal= , you have to send small SSH_MSG_IGNORE messages, or else the real typing i= s going to stick out.

Sure, low-overhead padding doesn't do much. Bu= t unencrypted lengths defeat the effectiveness of higher-overhead padding, = also.

I haven't actually implemented high-overhead padding, but it's= something I've been considering. Trying to combine that with unencrypted l= engths in AEAD would be shooting myself in the foot.


----- Origi= nal Message -----
From: Peter Gutmann
Sent: Wednesday, February 3, 2= 016 01:02
To: Mark D. Baushke
Cc: denis bider ; NielsM=C3=B6ller ; S= tephen Farrell ; ietf-ssh@NetBSD.org
Subject: RE: AEAD in ssh

m= db@juniper.net <mdb@juniper.net> writes:

>That said, the pa= per does raise questions about how to effeciently use such
>counermea= sures and requires a bit more thinking on my part.

It was a real eye= -opener, it points out that the simplistic mechanism built
into both TLS= and SSH for (attempting to) defeat traffic analysis pretty much
doesn't= work.  There's been a bit of earlier work in this area (the work onBayesian classifiers, notably used by the Tor folks) but this is a 2nd-ge= n
study that looks at how to defeat countermeasures that that initial 1s= t-gen
work inspired.

I agree that there may be issues of applicab= ility to SSH, but a bigger
question is the usual WYTM (what's your threa= t model), you need to figure out
what you're trying to defend against in= order to evaluate your defences.  It'd
be nice to have some rigoro= us model like the random oracle model or standard
model in crypto. = The pad-the-packets approach doesn't really have any threat
model excep= t that it seems like a good thing to do, what they've pointed out
is tha= t it's ineffective against traffic classifiers.  Hopefully there'll be=
more work on this in the future (although the previous papers were from= 5-10
years ago)...

The tl;dr version, from a comment in my code:=

  Padding in order to defeat traffic analysis is extremely pro= blematic.  The
  simplistic approach of adding random padding = provides little more than warm
  fuzzies since it falls almost triv= ially to statistical classifiers like
  Bayesian or support vector = machines.  In fact almost any attempt to defeat
  traffic anal= ysis with low overhead, including random padding, linear padding
  = (padding to the nearest 128 bytes), exponential padding (padding to the
=   nearest power of two), mice/elephant padding (padding short packets = to 128
  bytes and long ones to the MTU), straight padding to the M= TU, and padding by
  a random multiple of 8 or 16 bytes, doesn't wo= rk (see "Peek-a-Book, I Still
  See You: Why Efficient Traffic Anal= ysis Countermeasures Fail" by Dyer,
  Coult, Ristenpart and Shrimpt= on).

  It's only when quite complex traffic morphing, sending f= ixed-length packets
  at fixed intervals and the like, is applied a= nd reaches an overhead of 400%
  that things start getting tricky f= or an attacker, or at least an attacker
  using a straightforward B= ayesian or SVM classifier.

  This doesn't leave much choice in = the way of padding, since no matter what
  we do it won't be terrib= ly effective.  The best option is to choose the
  variant with= the lowest overhead and use that, since it has at least a small
  = amount of effect.  This is linear padding, but we pad to 64 bytes inst= ead of
  128 because we're typically used in embedded environments = which both use
  shorter messages and often have bandwidth constrai= nts.

Peter.
= --=-MVnyME286Ko4LaOnqXLs-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Feb 4 22:18:23 2016 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 9326C1B363F for ; Thu, 4 Feb 2016 22:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] 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 NQOI86K_Uatx for ; Thu, 4 Feb 2016 22:18:20 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 CCBE81B363D for ; Thu, 4 Feb 2016 22:18:20 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4325D85E6F; Fri, 5 Feb 2016 06:18:19 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id EBF3B85E61; Fri, 5 Feb 2016 06:18:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9525A85F2E for ; Thu, 4 Feb 2016 07:19: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 kp1leU71HgW3 for ; Thu, 4 Feb 2016 07:19: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 7FF6A85EE0 for ; Thu, 4 Feb 2016 07:19:56 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Thu, 4 Feb 2016 07:19:55 +0000 Date: Thu, 4 Feb 2016 07:19:55 +0000 Subject: Re: AEAD in ssh X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1827107952-1416@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Damien Miller , =?UTF-8?q?Niels_M=C3=B6ller?= Cc: Stephen Farrell , ietf-ssh@NetBSD.org, Watson Ladd , Daniel Migault , mdb@juniper.net Content-Type: multipart/alternative; boundary="=-g7MLYsZiPwzH7Hz9PhkG" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-g7MLYsZiPwzH7Hz9PhkG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree on all below points. And yes: > and then argue that SSH2 should only negotiate > complete AEADs rather than separate ciphers and MACs.=20 Very much this. ----- Original Message ----- From: Damien Miller=20 Sent: Wednesday, February 3, 2016 19:50 To: Niels M=C3=B6ller=20 Cc: denis bider ; Stephen Farrell ; ietf-ssh@NetBSD.org ; Watson Ladd ; Dan= iel Migault ; Curdle Chairs ; mdb@juniper.net=20 Subject: Re: AEAD in ssh On Mon, 1 Feb 2016, Niels M=C3=B6ller wrote: > denis bider writes: >=20 > > With regard to AEAD: > > > > I think we should just make the following simple and clear statement: > > > > MAC algorithms are secondary to encryption algorithms, and are > > evaluated only if the encryption algorithm is not AEAD. If an AEAD > > encryption algorithm is negotiated, the outcome of MAC negotiation is > > irrelevant and must be ignored. If no mutual MAC algorithms are > > available, this causes key exchange to fail if, and only if, the > > negotiated encryption algorithm is not AEAD. >=20 > That's only one part of it. I think the following points need clear > specification: >=20 > 1. How to negotiate use of AEAD.=20 >=20 >=C2=A0=C2=A0=C2=A0 The above would work, I think.=20 >=20 >=C2=A0=C2=A0=C2=A0 Or one could specify a "n/a" mac name, which is a bit l= ike "none", >=C2=A0=C2=A0=C2=A0 except that negotiation fails if it's the output of the= mac >=C2=A0=C2=A0=C2=A0 negotiation and the negotiated cipher isn't an aead mec= hanism. Maybe >=C2=A0=C2=A0=C2=A0 unnecessary, but it could also serve the second purpose= as signalling >=C2=A0=C2=A0=C2=A0 support for aead, in case the negotiation rules need tw= eaking (see >=C2=A0=C2=A0=C2=A0 also next point). If defined, it should be mandatory (i= .e., if the >=C2=A0=C2=A0=C2=A0 agreed cipher is aead, but "n/a" mac isn't offered, con= nection should >=C2=A0=C2=A0=C2=A0 fail). I prefer Denis' forumation (which matches what we in OpenSSH for AEAD) ciphers, it's simpler, harder to get wrong and less likely to fail at runtime through user misconfiguration. The only cost is that the KEX code needs to be able to easily tell whether an algorithm is an AEAD before it starts working on the MAC. The change to OpenSSH's KEX code to support AEAD ciphers was trivial: https://anongit.mindrot.org/openssh.git/diff/kex.c?id=3D1d75ab= fe > 2. How it interacts with first_kex_packet_follows.=20 >=20 >=C2=A0=C2=A0=C2=A0 Roughly, if everything is "guessed" correctly except th= e mac >=C2=A0=C2=A0=C2=A0 algorithm (e.g, if the mac name-list is empty so mac ne= gotiation >=C2=A0=C2=A0=C2=A0 fails), and the agreed cipher is aead, the guess ought = to >=C2=A0=C2=A0=C2=A0 nevertheless be considered successful. The details must= be made >=C2=A0=C2=A0=C2=A0 crystal clear.=20 >=20 >=C2=A0=C2=A0=C2=A0 (And I'm open to tweaking the rules in other ways too, = if new rules are >=C2=A0=C2=A0=C2=A0 reliably signalled via some extension or by the "n/a" a= tom; it's >=C2=A0=C2=A0=C2=A0 unclear to me if the first_kex_packet_follows logic rea= lly needs to >=C2=A0=C2=A0=C2=A0 depend on anything else but the agreed key exchange mec= hanism and >=C2=A0=C2=A0=C2=A0 maybe host_key_algorithm (I think I can argue that it's= independent >=C2=A0=C2=A0=C2=A0 of host_key_algorithm: Every reasonable keyexchange alg= orithm needs >=C2=A0=C2=A0=C2=A0 input from the client, and the key exchange signature m= ust depend on >=C2=A0=C2=A0=C2=A0 that data. Hence the first kex packet should be indepen= dent of the >=C2=A0=C2=A0=C2=A0 signature)). I don't think the first_kex_packet_follows rules need adjustment if mac negotiation is simply ignored for ciphers that are AEAD. > 3. If and how to encrypt the length field.=20 >=20 >=C2=A0=C2=A0=C2=A0 My strong opinion is that it ought to be encrypted. A s= pec for AEAD >=C2=A0=C2=A0=C2=A0 in ssh should either specify fully how to do that, or g= ive clear >=C2=A0=C2=A0=C2=A0 guidelines in case some details must be left to the spe= cification of >=C2=A0=C2=A0=C2=A0 each AEAD mechanism. Roughly, one should use an indepen= dent cipher >=C2=A0=C2=A0=C2=A0 instance (distinct key or disjoint nonce sequence or di= stinct ctr >=C2=A0=C2=A0=C2=A0 value) to encrypt the length in a ctr-like mode. IMO this is completely up to the AEAD itself. OpenSSH supports an AEAD that does (chacha20/poly1305) and AES-GCM that doesn't. I'm not convinced that encrypting packet lengths wouldn't contribute to an effective traffic analysis mitigation scheme -- the "peek-a-boo" paper clearly shows they are not sufficient, but that's not the same as saying that it isn't necessary, or can't help. OTOH I'll freely admit that the point is moot in the absense of a threat model and until implementations actually implement serious traffic analysis mitigations. I don't accept Peter's argument that encrypting length fields is a net negative for security. An independently keyed cipher for length encryption is never going to act as an oracle in the same way as the CBC+bad MAC order mess was. > 4. What the "block size" used for padding purposes (RFC 4253, Sec. 6, >=C2=A0=C2=A0=C2=A0 "Binary Packet Protocol") should be.=20 >=20 >=C2=A0=C2=A0=C2=A0 AEAD in the abstract doesn't expose any block size, so = I'd be >=C2=A0=C2=A0=C2=A0 inclined to say that we should always use 8, the ssh mi= nimum. One >=C2=A0=C2=A0=C2=A0 could tie it to the underlying block cipher if there is= one, but it >=C2=A0=C2=A0=C2=A0 makes little sense to me, given that it's the length *i= ncluding* the >=C2=A0=C2=A0=C2=A0 length field which must be a multiple of the "block siz= e". And with >=C2=A0=C2=A0=C2=A0 AEAD, the length field has to be separately encrypted, = so by the >=C2=A0=C2=A0=C2=A0 current rules, we're always going to be unaligned anywa= y. I don't think it makes sense to try to define this for AEAD modes in abstract, it's a concrete property of the individual algorithms. > The existing RFC 5647 on aes-gcm is unclear on (1) and (2) (and > apparently not implemented that way in openssh). RFC5647 is quite clear on negotiation, but it doesn't follow either scheme mentioned above (with are both IMO much more reasonable), instead it requires (section 5.1) that "AEAD_AES_*_GCM" be selected for both cipher and MAC. I think this offers even more opportunities for runtime failure and misconfiguration. > In short, to write a good specification will require some non-trivial > amount of work. And I think it's pretty important work. Do you agree? > Are there any objections to the above direction? (I already know some > dislike encrypted lengths). What are the chances to reach rough > consensus? IMO the best approach to the problem is to define the right way to negotiate AEAD algorithms in KEX, but specify the AEADs individually. If I had a time machine then I'd go back to 2000, buy a bunch of stocks and then argue that SSH2 should only negotiate complete AEADs rather than separate ciphers and MACs. I'd almost certainly be dismissed as a crank, but at least I'd be rich when I got back. -d = --=-g7MLYsZiPwzH7Hz9PhkG Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree on all below points.

And yes:
> and then argue that SSH2 should only negotiate
> complete AEAD= s rather than separate ciphers and MACs.

Very much this.

----- Original Message -----
From: Damien Miller
Sent: Wednesday, F= ebruary 3, 2016 19:50
To: Niels M=C3=B6ller
Cc: denis bider ; Stephe= n Farrell ; ietf-ssh@NetBSD.org ; Watson Ladd ; Daniel Migault ; Curdle Cha= irs ; mdb@juniper.net
Subject: Re: AEAD in ssh

On Mon, 1 Feb 201= 6, Niels M=C3=B6ller wrote:

> denis bider <ietf-ssh3@denisbide= r.com> writes:
>
> > With regard to AEAD:
> >> > I think we should just make the following simple and clear stat= ement:
> >
> > MAC algorithms are secondary to encryption= algorithms, and are
> > evaluated only if the encryption algorith= m is not AEAD. If an AEAD
> > encryption algorithm is negotiated, = the outcome of MAC negotiation is
> > irrelevant and must be ignor= ed. If no mutual MAC algorithms are
> > available, this causes key= exchange to fail if, and only if, the
> > negotiated encryption a= lgorithm is not AEAD.
>
> That's only one part of it. I think = the following points need clear
> specification:
>
> 1. = How to negotiate use of AEAD.
>
>    The above= would work, I think.
>
>    Or one could spec= ify a "n/a" mac name, which is a bit like "none",
>   = except that negotiation fails if it's the output of the mac
> &= nbsp;  negotiation and the negotiated cipher isn't an aead mechanism. = Maybe
>    unnecessary, but it could also serve the se= cond purpose as signalling
>    support for aead, in c= ase the negotiation rules need tweaking (see
>    also= next point). If defined, it should be mandatory (i.e., if the
> = ;   agreed cipher is aead, but "n/a" mac isn't offered, connectio= n should
>    fail).

I prefer Denis' forumation= (which matches what we in OpenSSH for AEAD)
ciphers, it's simpler, hard= er to get wrong and less likely to fail at
runtime through user misconfi= guration.

The only cost is that the KEX code needs to be able to eas= ily
tell whether an algorithm is an AEAD before it starts working on
= the MAC. The change to OpenSSH's KEX code to support AEAD ciphers
was tr= ivial: https://anongit.mindrot.org/openssh.git/diff/kex.c?id=3D1d75abfe
=
> 2. How it interacts with first_kex_packet_follows.
>
&g= t;    Roughly, if everything is "guessed" correctly except t= he mac
>    algorithm (e.g, if the mac name-list is em= pty so mac negotiation
>    fails), and the agreed cip= her is aead, the guess ought to
>    nevertheless be c= onsidered successful. The details must be made
>    cr= ystal clear.
>
>    (And I'm open to tweaking = the rules in other ways too, if new rules are
>    rel= iably signalled via some extension or by the "n/a" atom; it's
> =    unclear to me if the first_kex_packet_follows logic really nee= ds to
>    depend on anything else but the agreed key = exchange mechanism and
>    maybe host_key_algorithm (= I think I can argue that it's independent
>    of host= _key_algorithm: Every reasonable keyexchange algorithm needs
> &= nbsp;  input from the client, and the key exchange signature must depe= nd on
>    that data. Hence the first kex packet shoul= d be independent of the
>    signature)).

I don= 't think the first_kex_packet_follows rules need adjustment if
mac negot= iation is simply ignored for ciphers that are AEAD.

> 3. If and h= ow to encrypt the length field.
>
>    My stro= ng opinion is that it ought to be encrypted. A spec for AEAD
> &= nbsp;  in ssh should either specify fully how to do that, or give clea= r
>    guidelines in case some details must be left to= the specification of
>    each AEAD mechanism. Roughl= y, one should use an independent cipher
>    instance = (distinct key or disjoint nonce sequence or distinct ctr
>  = ;  value) to encrypt the length in a ctr-like mode.

IMO this is= completely up to the AEAD itself. OpenSSH supports an AEAD that
does (c= hacha20/poly1305) and AES-GCM that doesn't. I'm not convinced that
encry= pting packet lengths wouldn't contribute to an effective traffic
analysi= s mitigation scheme -- the "peek-a-boo" paper clearly shows they
are not= sufficient, but that's not the same as saying that it isn't
necessary, = or can't help.

OTOH I'll freely admit that the point is moot in the = absense of a
threat model and until implementations actually implement s= erious
traffic analysis mitigations.

I don't accept Peter's argum= ent that encrypting length fields
is a net negative for security. An ind= ependently keyed cipher for
length encryption is never going to act as a= n oracle in the same
way as the CBC+bad MAC order mess was.

> = 4. What the "block size" used for padding purposes (RFC 4253, Sec. 6,
&g= t;    "Binary Packet Protocol") should be.
>
>=     AEAD in the abstract doesn't expose any block size, so I= 'd be
>    inclined to say that we should always use 8= , the ssh minimum. One
>    could tie it to the underl= ying block cipher if there is one, but it
>    makes l= ittle sense to me, given that it's the length *including* the
> =    length field which must be a multiple of the "block size". And= with
>    AEAD, the length field has to be separately= encrypted, so by the
>    current rules, we're always= going to be unaligned anyway.

I don't think it makes sense to try t= o define this for AEAD modes in
abstract, it's a concrete property of th= e individual algorithms.

> The existing RFC 5647 on aes-gcm is un= clear on (1) and (2) (and
> apparently not implemented that way in op= enssh).

RFC5647 is quite clear on negotiation, but it doesn't follow= either
scheme mentioned above (with are both IMO much more reasonable),=
instead it requires (section 5.1) that "AEAD_AES_*_GCM" be selected
= for both cipher and MAC. I think this offers even more opportunities
for= runtime failure and misconfiguration.

> In short, to write a goo= d specification will require some non-trivial
> amount of work. And I= think it's pretty important work. Do you agree?
> Are there any obje= ctions to the above direction? (I already know some
> dislike encrypt= ed lengths). What are the chances to reach rough
> consensus?

= IMO the best approach to the problem is to define the right way to
negot= iate AEAD algorithms in KEX, but specify the AEADs individually.

If = I had a time machine then I'd go back to 2000, buy a bunch of
stocks and= then argue that SSH2 should only negotiate complete AEADs
rather than s= eparate ciphers and MACs. I'd almost certainly be
dismissed as a crank, = but at least I'd be rich when I got back.

-d

= --=-g7MLYsZiPwzH7Hz9PhkG-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Feb 4 22:18:47 2016 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 D92A71B363E for ; Thu, 4 Feb 2016 22:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] 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 TY7m0A_Q-ykF for ; Thu, 4 Feb 2016 22:18:46 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 9DE861B363D for ; Thu, 4 Feb 2016 22:18:46 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 63D8285E7C; Fri, 5 Feb 2016 06:18:46 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 17B6985E61; Fri, 5 Feb 2016 06:18:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B72ED85F27 for ; Thu, 4 Feb 2016 09:54:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id j0NxCFEORTlG for ; Thu, 4 Feb 2016 09:54:04 +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 8AC2285DFE for ; Thu, 4 Feb 2016 09:54:02 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 151D74001F; Thu, 4 Feb 2016 10:54:00 +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 D643F4001E; Thu, 4 Feb 2016 10:53:57 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 04 Feb 2016 10:53:57 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Damien Miller Cc: denis bider , Stephen Farrell , ietf-ssh@NetBSD.org, Watson Ladd , Daniel Migault , Curdle Chairs , mdb@juniper.net Subject: Re: AEAD in ssh References: <1361670077-596@skroderider.denisbider.com> Date: Thu, 04 Feb 2016 10:53:57 +0100 In-Reply-To: (Damien Miller's message of "Thu, 4 Feb 2016 12:50:07 +1100 (AEDT)") 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 Damien Miller writes: >> 2. How it interacts with first_kex_packet_follows.=20 > > I don't think the first_kex_packet_follows rules need adjustment if > mac negotiation is simply ignored for ciphers that are AEAD. I think it just needs to be a little clearer. You mean that "ignored" implies "considered a successful guess for purposes of the first_kex_packet_follows logic", right? >> 3. If and how to encrypt the length field.=20 > IMO this is completely up to the AEAD itself. Since there isn't a single obvious way to do length encryption, I think an ssh-aead is a good place to document some reasonable way to do it. Possibly as a SHOULD (i.e., the spec for each particular AEAD should stick to this particular way unless there's a good reason not to), but not a MUST. >> 4. What the "block size" used for padding purposes (RFC 4253, Sec. 6, >> "Binary Packet Protocol") should be.=20 > I don't think it makes sense to try to define this for AEAD modes in > abstract, it's a concrete property of the individual algorithms. An AEAD algorithm as defined in RFC 5116 has no block size. Do you see any advantage in making sure that the message size aligns with any block cipher underlying any aead algorithm? If the alternative is to either stick with 8 and the original size alignment rules, or to drop the requirement that sizes align with any block size? If we want to leave open for using an algorithm-specific block size, I guess we have to do it like aes-gcm (RFC5647) and align things so that the size of the aead plaintext input matches that block size, not counting the length field like for non-aead ciphers. Right? I think it is quite important to specify this in a uniform way for aead algorithms. It should be easy to plug in any AEAD adhering to the interface specified in RFC5116, without having to write new code to ensure correct ssh packet sizes. (Which is why I'd also like to specify some general and reasonable way to do length encryption). > IMO the best approach to the problem is to define the right way to > negotiate AEAD algorithms in KEX, but specify the AEADs individually. In principle, I agree. But I think it will make better progress to have at least one aead in the spec, both to help iron out the details, and to get some concrete and good aead standardized faster (I don't quite like gcm). =20 > If I had a time machine then I'd go back to 2000, buy a bunch of > stocks and then argue that SSH2 should only negotiate complete AEADs > rather than separate ciphers and MACs. I don't think the ssh protocol design was controversial at all back then. E.g, Schneier's Applied Cryptography, the bible at the time, recommended doing the MAC on the plain text rather than the cipher text. IIRC. 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 Thu Feb 4 22:19:00 2016 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 ADCA51B363E for ; Thu, 4 Feb 2016 22:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] 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 c7pyFUuipidt for ; Thu, 4 Feb 2016 22:19:00 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 9C0641B363F for ; Thu, 4 Feb 2016 22:18:58 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 39C0485E7E; Fri, 5 Feb 2016 06:18:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id E39D985E61; Fri, 5 Feb 2016 06:18:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BB65785FC6 for ; Thu, 4 Feb 2016 12:09:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id oheSRK7IT8QX for ; Thu, 4 Feb 2016 12:09:10 +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 D3A2E85DFD for ; Thu, 4 Feb 2016 12:09:08 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 057364001E; Thu, 4 Feb 2016 13:09:07 +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 6F1E94000D; Thu, 4 Feb 2016 13:09:05 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 04 Feb 2016 13:09:05 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: denis bider , Stephen Farrell , , Watson Ladd , Daniel Migault , Curdle Chairs Subject: Re: AEAD in ssh References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> Date: Thu, 04 Feb 2016 13:09:05 +0100 In-Reply-To: <62946.1454397657@eng-mail01.juniper.net> (Mark D. Baushke's message of "Mon, 1 Feb 2016 23:20:57 -0800") 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 "Mark D. Baushke" writes: > Rather than "n/a" as the atom, why not "AEAD" or "aead" so we are clear > about the intent? That said, I am fine with ignoring the Mac if the > 'Cipher' is an AEAD like the OpenSSH folks do if that is helpful. Should we allow advertising an empty mac list when all advertised ciphers are aead? RFC4253, Sec 7.1., is quite clear that "Each name-list MUST contain at least one algorithm name.". Is it ok to depart from that? Otherwise we need some placeholder, be that "n/a" or "aead". (Or perhaps we could use "none" in the particular case that *all* ciphers are aead, but I kind-of dislike ever adding "none" to these lists, it's about as appropriate in this case as using "hmac-md5", which would actually work just as well). Rereading 4253, it also seems I misremembered the current spec of first_kex_packet follows. It says o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm), or o if any of the other algorithms cannot be agreed upon (the procedure is defined below in Section 7.1). so maybe no tweaks needed there for aead. If the dependence on host key algorithm is confusing or improper, that's an independent issue, unrelated to aead. I'm also happy to say that I've gotten some time to work on a draft. Hopefully I have something within a few days. 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 Feb 10 00:22:45 2016 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 6100E1A00DB for ; Wed, 10 Feb 2016 00:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001] 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 BeQXUuKONHed for ; Wed, 10 Feb 2016 00:22:43 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 694E61A00B4 for ; Wed, 10 Feb 2016 00:22:43 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C5B4985EDD; Wed, 10 Feb 2016 08:22:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2142D85E6C for ; Wed, 10 Feb 2016 08:22:39 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id d07P3Uwg-414 for ; Wed, 10 Feb 2016 08:22:38 +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 E44E485E57 for ; Wed, 10 Feb 2016 08:22:35 +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=1455092559; x=1486628559; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=zmvq+CEgbHy7V3kIyGGPyosnMMZyadaCkBUikdz3gRA=; b=k9aiO70EjHongrcPnJsg6aTM7dHTh98tZPE41KhJUwf0sCKykkaemsIa 7TCtg8aqT1DsrMnM9fx44mWsvZqBARf0pSuz+u1EpQ2+4y6o/7zsqF4UP ZnozcX0qVdBTNgcYiHE+GVC8+Z56mIT6/wjSJK+VUuJAeXUVXo1irrXZV v4afthRd/wQ3bhVfH+vlSWw9yXf/3a83cc65w/Sacj+C0kzp/xYX5RBVq xoBZuMazyAW8l5HPyKyjMMnLB6Bx7s+yJ3VV/9da2C4/DYEE+DPzy6R4g sOjkfKd9bIZX0ZQhSkbfUPaDfyCGdcwfrZB0YDkjwM1vHbJ+H+SvGOMK9 A==; X-IronPort-AV: E=Sophos;i="5.22,425,1449486000"; d="scan'208";a="67118252" 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/AES256-SHA; 10 Feb 2016 21:22:33 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Wed, 10 Feb 2016 21:22:32 +1300 From: Peter Gutmann To: "ietf-ssh@NetBSD.org" Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Thread-Topic: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Thread-Index: AdFj3DBkMdJDQld0Qaiw70eVAW98zw== Date: Wed, 10 Feb 2016 08:22:32 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BEC444@uxcn10-5.UoA.auckland.ac.nz> 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 Damien Miller writes:=0A= =0A= >So my recommendation would be:=0A= >=0A= >diffie-hellman-group1-sha1 NOT RECOMMENDED=0A= >diffie-hellman-group14-sha256 RECOMMENDED=0A= >diffie-hellman-group16-sha512 RECOMMENDED=0A= >diffie-hellman-group18-sha512 OPTIONAL=0A= >=0A= >(but 16+256 & 18+512 would be fine too)=0A= =0A= >From an embedded perspective (which is what triggered this late reply) I'd= =0A= prefer the -256's over the -512's, the less extra huge hash functions I hav= e=0A= to include code for the better. I'd also like to see SHA-1 just die, there= 's=0A= no reason to specify it in a new spec published in 2016. Having said that = I=0A= realise that there are other profiles that still specify SHA-1, but then I'= d=0A= like to at least see the wording given as "SHOULD NOT" rather than "NOT=0A= RECOMMENDED". The latter is for restaurants, not security-critical=0A= infrastructure components.=0A= =0A= In fact same with RECOMMENDED and OPTIONAL, what's wrong with SHOULD and MA= Y?=0A= Those are more widely-used in standards. In particular I'd like to be able= to=0A= point to SHA-1 as SHOULD NOT (which is pretty unambiguous) rather than NOT= =0A= RECOMMENDED, which seems to say that people can keep on using it for as lon= g=0A= as they like.=0A= =0A= It'd also be good to include a note, where the groups are defined not down = in=0A= the security considerations, saying that the SHA-1 option is provided for= =0A= backwards compatibility, shouldn't be used in new designs, and should be=0A= phased out of existing ones as quickly as possible because it's not secure.= =0A= The danger here is is illustrated by the TLS 1.2 RFC:=0A= =0A= Support for the SSLv2 backward-compatible hello is now a MAY, not a SHOUL= D,=0A= with sending it a SHOULD NOT. Support will probably become a SHOULD NOT = in=0A= the future.=0A= =0A= That's for a protocol that was known to be insecure thirteen years earlier.= =0A= In fact all previous versions of TLS said:=0A= =0A= Warning: The ability to send Version 2.0 client hello messages will be=0A= phased out with all due haste. Implementors should make every=0A= effort to move forward as quickly as possible. Version 3.0=0A= provides better mechanisms for moving to newer versions.=0A= =0A= Thats from TLS 1.1 in 2006, so they'd spent more than a decade phasing it o= ut=0A= with all due haste.=0A= =0A= The point is that without text in the spec that implementers can point to= =0A= saying "if you're still using SHA-1, your product is broken" then it's goin= g=0A= to hang around forever, as the TLS experience has shown.=0A= =0A= Still, as long as the draft doesn't decide to reintroduce support for MD5,= =0A= like TLS 1.2 did...=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Feb 10 09:24:50 2016 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 560851B2D70 for ; Wed, 10 Feb 2016 09:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 FuYdIdaBZIOO for ; Wed, 10 Feb 2016 09:24:48 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 5050E1B2D6D for ; Wed, 10 Feb 2016 09:24:48 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E8BBC85F0D; Wed, 10 Feb 2016 17:24:46 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5ACDA85EBA for ; Wed, 10 Feb 2016 17:24:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id VkJG6OCporeC for ; Wed, 10 Feb 2016 17:24:39 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::789]) by mail.netbsd.org (Postfix) with ESMTP id 1C6AA84CF5 for ; Wed, 10 Feb 2016 17:24:34 +0000 (UTC) Received: from SN1PR05CA0027.namprd05.prod.outlook.com (10.163.68.165) by BN1PR05MB060.namprd05.prod.outlook.com (10.255.202.153) with Microsoft SMTP Server (TLS) id 15.1.403.16; Wed, 10 Feb 2016 17:24:32 +0000 Received: from BY2FFO11FD037.protection.gbl (2a01:111:f400:7c0c::104) by SN1PR05CA0027.outlook.office365.com (2a01:111:e400:5197::37) with Microsoft SMTP Server (TLS) id 15.1.403.16 via Frontend Transport; Wed, 10 Feb 2016 17:24:32 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; cs.auckland.ac.nz; dkim=none (message not signed) header.d=none;cs.auckland.ac.nz; 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-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11FD037.mail.protection.outlook.com (10.1.14.222) with Microsoft SMTP Server (TLS) id 15.1.409.7 via Frontend Transport; Wed, 10 Feb 2016 17:24:31 +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; Wed, 10 Feb 2016 09:24:29 -0800 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 u1AHOQD24444; Wed, 10 Feb 2016 09:24:27 -0800 (PST) (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 3FBC111454; Wed, 10 Feb 2016 09:24:26 -0800 (PST) To: Peter Gutmann CC: "ietf-ssh@NetBSD.org" Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BEC444@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4BEC444@uxcn10-5.UoA.auckland.ac.nz> Comments: In-reply-to: Peter Gutmann message dated "Wed, 10 Feb 2016 08:22:32 +0000." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; 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;BY2FFO11FD037;1:pmNkj9liZVgPGfz+3++1sQrNAR3TktzUhsJ76GuB2tgaIZYKZHkoTROY8y8TxLzPSiN2dnosjrYOkFBHRZFr3N1nrWFsDK5HiOrXAXZCMH6AQ70J7nQoClCOVAK1yjhHGZWVnFfjURveYmizVAQswxK7lLwQ7FO6fFZYExD1B4hBNVu7zGn63zSjhYv1e89+Z+ra7hO98qisAp8subhY2S6XMZVf1CX5cxWBAzQXFIpfVl/gwxCtT61KvGBucH8E0F1EwTtPQjeZp0MZTR7BUPE5eeg8WSIqX+wBRHebDCCwssv4Mg57d5mXAo7xzlkbufRREGFM5CNbwd1kSHshfr92BorsJF8FzRF336yxpOd6RVH5JhlvFO6qSeLHYAf6TcXB8lP/lpyr0IwgaBJ0VQ== X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(164054003)(189002)(5003600100002)(6806005)(4326007)(110136002)(586003)(11100500001)(53416004)(2906002)(19580405001)(50226001)(1096002)(47776003)(86362001)(5001960100002)(76506005)(106466001)(50986999)(1220700001)(117636001)(76176999)(2950100001)(87936001)(50466002)(230783001)(5003940100001)(48376002)(189998001)(92566002)(15975445007)(105596002)(77096005)(2810700001)(19580395003)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR05MB060;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB060;2:P2+y+T+4LRvQpkQBjAGkPqMgiJMVv0OW92atCowP+XNxyTKuY15cfu5WeoMiLNaNLf0JTvzgjp0V1cm0CRQ7RLLBGvpCOgor1gz3vR3I1iMran36WJo6AV2h98g4ArovgcYx84LloSym9QPTVH/pIg==;3:4m7P4aeuo7tWVJ3hNtPbJnDsjlxyW1k3P1HXMM4gopoG95Akz7LZnkd06FdLmaBiv9Bt4qu54VdaLSKKgc1wruRVxLk/Ap4shtAhFp2LKcvHhIcaQ1jrH8ywqUUnE4EUFxNHd7JKE01RUkl0JqAMIAGvEzNa7RyAk+EKKLrgmAIQYiqnVThai+w349VjPkzbAkUEvWka9ElFumMJZVOPw4pZmd34o1b8fMbRL6nfsyU=;25:fZQSRqAg1VFYWmvBaDmFs3LZgUoGoS3V5e453bEExCevta+WIPuJW8AxVRPpgJalH1ImsRFadZgM7+ozSFC3v+eZlfGyklYFeYiK4z7BPQfvTh0s9ttJ9VfR6rgd6cdm5UvAb5otT3oWhXl4J4PO04PJ8SCawf1qzKoKu6A1FmIGHN+L1u+JZFjoCJE/NtWGT3+H6Bc6doi+QULQMd5veuAmIgNTOzNjtlKZQvezL1gD1pKf+BGae04sA1fOxrf5sS3+3tqIqju605JpnfTTucjo7T0v10FfLjy4OaUB5R5S6iKqDZpx908KvR012pRd X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB060; X-MS-Office365-Filtering-Correlation-Id: 6058f879-f49f-4f48-cd20-08d3323f098f X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB060;20:odOrZqhr92CCjncRo0EkyR9v3A+zqI4moUTUKgej4/0bGWlYGBijTh5izzq9TLqNaianW1stVxreGMOO7NIN2H/GuxYw2UZkR5wr+OQ/g03xJJI/nNypBIDdzSxKp3fm6s1yzIB4Un6E70NlGD6Ak6k/uJgRwwKyWToa2Ee85hVCNnhDb83y3QDxU+uY/hX0pi9LtOZ+cdBuc2Ch0zc2lsEwQAeZlZo6BAWES3ZAo68jCcP/+xgRHjtvokovJ5yBibo2uQtp2yX+kYWPAdSjHPBILCI5m3wUiJjwoDI2D9tuleRZ/tLvb72sl4zyGVbLOQgRPwLDh3LnWg2+v8O8ysBIa3Of56BoKefSGSMmmIEn1r0l2VgTgjDabtWIOsQ7p3PT5WkU03kgKhMsMatdHMYsKeQb/jJW1sbC+a39N8w+8oI4j6vxI2yjo/4CFHQwNBj0zVG3VsnBNzYJ3U5U/kguHhTHzB1sZ1ErDiFbuJz5rgobjHhurCV9fVFX6Akl X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13017025)(13024025)(5005006)(8121501046)(13018025)(13023025)(13015025)(10201501046)(3002001);SRVR:BN1PR05MB060;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB060; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB060;4:3dI9ayEskbQFw6HYjUA6oOyOLPcS4C3ib7WDrcugb6mK5iX26FPDAnHUeFnvWc3Xai81wzr++++FukM1DhVgu8DjM0dMoM2XruXW0A+RztG5n5/1e55QcAddleYZwBPM6ZO30TyAb7FwKgfarlikbWc082QJiIWQrOwsYX4uLAJAGGuecxpEb9Nug25WSscGuKFp0pO7tV7iuw2Svdi6Wz9rQsUzgcJbls8izlD7lasFPwe5fNMNJ3t5ml50C4+mJnVbm8p4mWl7jkEp7BgXCCaD3ve+f7p/JRe917JOf0cjTiCmuq7iT30lID429YLYnduLwUeX4/9voFQRVXfBiRg2GEdhl79nPkpOa96yi5oAG9K9pNk1q5o8uDK/i0ziYsc1zuzo30w2jS6LZ78eJ9ghY/Dg2AJ294aKOgASzVQ/ujhWg5U1cLDrSFvtidV9YAoMdydxXtYMnNXdGh5rsg== X-Forefront-PRVS: 0848C1A6AA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN1PR05MB060;23:ldmqdXhRPD80VW6//Uw4e92g7oiocN5orqPl00Whmk?= =?us-ascii?Q?ctS5r53AFCIDRYi/vklBLBRDNeRB68CFK9yZbC8DrCFmE9XHOIo9nJ+gcJs2?= =?us-ascii?Q?ORKsg6AKJOQZI+zENL0wdqstMyydMBky5GuEmuz4NvqU+87V3RijhZ4dvrjl?= =?us-ascii?Q?dgJief7afej3XIiVf857pYswSiZCWXTnyeQQr0mohcsYwySzS4ivtnQyXSDS?= =?us-ascii?Q?P6rgVO2Ofnae+EOPtlmXGNYvwB3bl615aYRE6AXDUqYEftcfo6QQpRZys0L4?= =?us-ascii?Q?gOPu6O3y7JfRuAAOD1DzBOjm7yZQ6KBq0iIlF+hhLMDseO0Dt+OXcskjJa0y?= =?us-ascii?Q?3KN8fkbcfELQlO+9oReP+ENIpdHZxWWe4PBCMLYz5sjio4vY1RJHuRjsbFS2?= =?us-ascii?Q?uFIZrRE2xAjCp6cr2AITbo9pOevyOg31d5lHB3/188cyiy/ASIAbEZokVdz1?= =?us-ascii?Q?DwLDKFRKYqo0XQyl/rT+bR5U6kKBy8Fb4s7j2gMwvtlYxEhpFboxchA8eZIW?= =?us-ascii?Q?oVA1Fr5J6CoWoDv4T058hUliiA3HP7pwswwb5kYfpB3vxoHVKc54+gOyHowx?= =?us-ascii?Q?i4iR/NYrzp2+dnbRy7CXbhZBm+L3rXpqFmXKWY2Qt8uCHzavhZ4qMEz/yqVs?= =?us-ascii?Q?i9qWuI1hgDIv22+ej3Gz6OZOqfkUJRbdNwguCGsLIxPFlWq6bNXFs5A56vWT?= =?us-ascii?Q?ju/IQQAm26fECSzoAUPw/LtUnVe1gKtiKzX2YWu50gfNGJZ/qZjJV2pJz7uc?= =?us-ascii?Q?h20bOYwfInwlZT7XTU8ASyovcWIGnYgMEom0Ckli1Jwjnlu5QR4lxoKDNh4F?= =?us-ascii?Q?hJuTdVM+o0AqTrHG0PohyL6MSb20PyzJ8ERPrSlX8OVSQDNrWCkNJL6rvhlJ?= =?us-ascii?Q?y++NBpASB7+SsDWh21RpkO03lgkfygVoMygEogQcr4cbUmCnGsDLyFfECKOi?= =?us-ascii?Q?u+/c3JeDVmo/64lgZfA0oJgV8WIYsYYf7RY7ajOhxmPcai0dBnZy61vpaZZV?= =?us-ascii?Q?h4cX/FVsdEYtNYcA6fm/SvpFNLMPGl/QRxV6VL7NJS+XPfUY8+4VqL8S9OFz?= =?us-ascii?Q?7EZi0=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB060;5:Gp0uQKsQrAFBXmMa44kr71rBtjP5/JhJesFTDwCMQRy3b8UROLGJYRd4r/5+ykZN5rTaidrH3NQ2+WVx0MRqd2PUooBgpD5Dwr2tSD6tbLjWjDWHG2raeoea83NRkan8HFj9K3d+5Sa0R8d9hW9u7g==;24:lzEV2UZkTVbKFKnroqr1d6wNbQ2rB+K4Tn4Sf/Lukzx206tYAtHgjutddB65O0lnOSpAJc2fXKfkbv6VyiOOLSxWexKcs+1U0zTLXdMPFWw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2016 17:24:31.1779 (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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB060 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > Damien Miller writes: > > >So my recommendation would be: > > > >diffie-hellman-group1-sha1 NOT RECOMMENDED > >diffie-hellman-group14-sha256 RECOMMENDED > >diffie-hellman-group16-sha512 RECOMMENDED > >diffie-hellman-group18-sha512 OPTIONAL > > > >(but 16+256 & 18+512 would be fine too) > > From an embedded perspective (which is what triggered this late reply) I'd > prefer the -256's over the -512's, the less extra huge hash functions I have > to include code for the better. I'd also like to see SHA-1 just die, there's > no reason to specify it in a new spec published in 2016. Having said that I > realise that there are other profiles that still specify SHA-1, but then I'd > like to at least see the wording given as "SHOULD NOT" rather than "NOT > RECOMMENDED". The latter is for restaurants, not security-critical > infrastructure components. RFC2119 says that "SHOULD NOT" and "NOT RECOMMENDED" have the same meaning. To make it stronger would mean moving to "MUST NOT" instead. Today diffie-hellman-group1-sha1 is "REQUIRED" so I only moved to "NOT RECOMMENDED/SHOULD NOT" are you suggesting a need to move to "MUST NOT" here? Today diffie-hellman-group14-sha1 is "REQUIRED" and is not mentioned. Do you believe that we should change that one to "OPTIONAL/MAY" and select a new "REQUIRED" key exchange to avoid SHA-1? If so, which one should now be "REQUIRED" ? > In fact same with RECOMMENDED and OPTIONAL, what's wrong with SHOULD > and MAY? Nothing is wrong with SHOULD or MAY. Per RFC2119: * "RECOMMENDED" and "SHOULD" are equivalent * "OPTIONAL" and "MAY" are equivalent * "MUST" and "REQUIRED" are equivalent > Those are more widely-used in standards. I have seen the terms used interchangeably per RFC2119. > In particular I'd like to be able to point to SHA-1 as SHOULD NOT > (which is pretty unambiguous) rather than NOT RECOMMENDED, which seems > to say that people can keep on using it for as long as they like. The terms are supposed to be understood in the context of RFC2119. Are you speaking of the use of SHA-1 in key exchange only? There is diffie-hellman-group-exchange-sha1 in RFC4419 which also uses SHA-1. I presume it is currently an OPTIONAL key exchange. Should we be moving it to a MUST NOT now too? I have no strong preference for which of the equivalent terms are used if it helps make the point better. Does it really make the point better? > It'd also be good to include a note, where the groups are defined not > down in the security considerations, saying that the SHA-1 option is > provided for backwards compatibility, shouldn't be used in new > designs, and should be phased out of existing ones as quickly as > possible because it's not secure. The concern for SHA-1 is specified in the Overview nd Rationale as well as in the Security Considerations section. Where do you feel it should be noted in addition to those two locations? > The danger here is is illustrated by the TLS 1.2 RFC: ...elided... Yes, I think we are currently trying to do the right thing with the Secure Shell requirements. I suspect we really do need to have at least one REQUIRED key exchange mechanism that is common before and after these drafts are published. Otherwise, we probably need to bump to SSHv3 if we are going to get rid of all of the MUST NOT algorithms. Are there any additional thoughts for this draft? Is it desirable to list out all of the Key Exchange Method names in the https://www.ietf.org/assignments/ssh-parameters/ssh-parameters.xml table and their new state? Key Exchange Method Names Method Name Reference Note diffie-hellman-group-exchange-sha1 RFC4419 MUST NOT diffie-hellman-group-exchange-sha256 RFC4419 MAY diffie-hellman-group1-sha1 RFC4253 MUST NOT diffie-hellman-group14-sha1 RFC4253 MAY ecdh-sha2-nistp256 RFC5656 MUST ecdh-sha2-nistp384 RFC5656 MUST ecdh-sha2-nistp521 RFC5656 MUST ecdh-sha2-* RFC5656 Other curves are possible? ecmqv-sha2 RFC5656 MAY gss-gex-sha1-* RFC4462 MUST NOT gss-group1-sha1-* RFC4462 MUST NOT gss-group14-sha1-* RFC4462 MUST NOT gss-* RFC4462 MAY rsa1024-sha1 RFC4432 MUST NOT rsa2048-sha256 RFC4432 MAY diffie-hellman-group14-sha256 This Draft MAY diffie-hellman-group15-sha256 This Draft MUST diffie-hellman-group16-sha512 This Draft SHOULD diffie-hellman-group17-sha512 This Draft MAY diffie-hellman-group18-sha512 This Draft MAY Above I have moved all of the *sha1* exchange methods to MUST NOT with the exception of diffie-hellman-group14-sha1. Should that one also be moved to MUST NOT too? If we want to fix RFC4419 to pass q in addition to g,p so that we are able to use Lim/Lee primes for q and allow for run-time checking of a g being a generator of the q-ordered subgroup, does that need to be rolled into this draft too? What do we want to call this option for negotiation? Additional comments solicited on these topics. Thanks, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Feb 11 23:50:05 2016 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 33EAC1B413E for ; Thu, 11 Feb 2016 23:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 Ja__P-RM7RV3 for ; Thu, 11 Feb 2016 23:50:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 6C1B81B413F for ; Thu, 11 Feb 2016 23:50:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 375A485EE1; Fri, 12 Feb 2016 07:49:59 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B69B385E70 for ; Fri, 12 Feb 2016 07:49:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 2F0af_LhCMnJ for ; Fri, 12 Feb 2016 07:49:55 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::735]) by mail.netbsd.org (Postfix) with ESMTP id 1FCD485DFE for ; Fri, 12 Feb 2016 07:49:51 +0000 (UTC) Received: from BLUPR05CA0043.namprd05.prod.outlook.com (10.141.20.13) by BN1PR05MB057.namprd05.prod.outlook.com (10.255.202.139) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 12 Feb 2016 07:49:48 +0000 Received: from BL2FFO11FD018.protection.gbl (2a01:111:f400:7c09::111) by BLUPR05CA0043.outlook.office365.com (2a01:111:e400:855::13) with Microsoft SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Fri, 12 Feb 2016 07:49:49 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; cs.auckland.ac.nz; dkim=none (message not signed) header.d=none;cs.auckland.ac.nz; 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-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11FD018.mail.protection.outlook.com (10.173.161.36) with Microsoft SMTP Server (TLS) id 15.1.415.6 via Frontend Transport; Fri, 12 Feb 2016 07:49:48 +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; Thu, 11 Feb 2016 23:49:44 -0800 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 u1C7nhD92674; Thu, 11 Feb 2016 23:49:43 -0800 (PST) (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 380E911821; Thu, 11 Feb 2016 23:49:42 -0800 (PST) To: denis bider CC: Peter Gutmann , Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) In-Reply-To: <99035674-2196@skroderider.denisbider.com> References: <99035674-2196@skroderider.denisbider.com> Comments: In-reply-to: denis bider message dated "Fri, 12 Feb 2016 07:22:53 +0000." From: "Mark D. Baushke" Date: Thu, 11 Feb 2016 23:49:42 -0800 Message-ID: <24239.1455263382@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD018;1:WEncRB6xIILofmURDslEz2upeYvohsoDYp6DHO7EG69Z7mO2/XR40NnGYoOlv3lASkWR1zxfoYM2Mrl8q6gLswbQz+JWMh+C6qnz4jZPOZjfTH01/q+R1V0so8mLC0P/LO5/n6k0PJNvEzqe2asLrQd5QJvN0ivBEDbPV24va32G355jhVcyXlX17b2mybRIePZ4QXZ7hRhxOx8QOBBB6zoUyughEeXRjAYJtWXx73yWAjW1ItAn+KWVPXR94I4hawTbGN63cuyMJ57ucmnSizd1KAt6JSimMgaWz23uDYQCmy0Pbwr59JxQUk1xdquDWnlGmw9Q2YYD9X69IxWcwwLytyAzv2ExFJoKFAMjVUZqYd1DjMwtp3gM1avGVy8J5Ub4+/ibptEfQ8g1aNh4vR77ajGdB19NhiFLeNogUnU= X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(189002)(51744003)(87936001)(77096005)(15975445007)(5003600100002)(189998001)(53416004)(86362001)(47776003)(2950100001)(110136002)(5001960100002)(117636001)(586003)(1096002)(5003940100001)(1220700001)(4326007)(2906002)(2810700001)(19580395003)(50466002)(48376002)(230783001)(92566002)(6806005)(54356999)(76176999)(105596002)(106466001)(76506005)(50986999)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR05MB057;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB057;2:ymL//J/AHOM2CdAdo6ZSVRHt/lRktJp2IIiY6h0qJE0ZSJwb1MQhLj6d1fVjC1qrTFAtxi9JBoruLVz30UkGoHxJ/jRdsBLl2zVPK8ZEdeXXXKOfvwrUgEN8bbQwWFMnCPm1hmRovoBMx6lKepRMJA==;3:5Qeyurqk30TiV0dnJmO4o6OrieOvZEOAAhhuTir28IiKwo1AFHbia6d5Z9QD66TY3XfuTroTzF0maJ6AO898GU8RZ3UvGwhkqK7R1IPWiJzkAiNnSXj4nQI2/8LDgCabWNbT3qNkhAO2aW6e7Is2a3S9iif4cLxxc1me3Bp8SO2jolZFgGtActawFIHH1cKKBNUl2p+1czvvh7ZVnK6AfyBDxDAP0rg3Bc3p3pOQagc=;25:yhQ+N5VR8/PzzzvW5dJaVtdarikN12BfjXoyxD53Q22z1P0mr5ry7SVP6hQ1BR6lK5M5uILLzqfl3QcChgy3YDQ/NnUE6QdI2sJdF8eNyRgOvgdEZE6fPSkkUe/ZzMpFGWouNs/CnOP28G2mgACrMV4kawHCNZD8qI8dvL1vMA3rwfeXv6hPEk2faiJzzkkrCf2yrRDiX7N44rWev2jiBfMkGOt6ve3IImpVhwHzH8h3awe73s98ErkMgLSQOUdr8IPijH4Q0OZUoIeFxckOUJ9taP1mYkOAWGR8YKhWjB/DYRIr5LTd8VUWXDRW0DLl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB057; X-MS-Office365-Filtering-Correlation-Id: 971a5dfd-5f8c-4c14-63c3-08d3338114e7 X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB057;20:r6rDjdrc3FvZGOWabD96C+IXzKcmp/R0f/PpdmGxXiI7DEuBKH0xS5UhSmYRZUtkJYCS3BpHV7/LJYIQOhSBBrtIZErR5owZHrsZH7prj3+2tXUs0kmVyiftMZUWppkjqGqQD5dPzbJV1sMEr2wX3M51fCQerwUekfW2y6hcx2NhF2l1wa5LUuzkcJh3bIbYqR+ey++y5nSIy0Lxy06IZpPBvMBVE0nFM+uchQXP9ZLhQ5ZZ4We6T/FY+zPLwmPD756O+YKLHr7O1YSw3Mm0WRyMa5UH8vXZfjW0q2IXqYGTF8CFQzVaSgNRaQ9BEDDEPMIj6/XDl+BwFDMgsHQ9wu7if/QitXSbyPvmFj7X28hhU42wZz2RPYNUTD02yhBx1A+wk4WWda7uNrwyi2Ffmh2f9S8eTtsXZrquHXGigIDoSi0SFIqwT4Sfhj+Nhepsdcq1siqh0cjO0bqmb9XZ7qLk/F6poQqPiew+wot2TFJsPcePaDnRQuSbNAc/1pqR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13017025)(13018025)(8121501046)(5005006)(13023025)(13015025)(13024025)(10201501046)(3002001);SRVR:BN1PR05MB057;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB057; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB057;4:cJ8/Dvx1RaVHyS6XF579hxknRyAkKaHTQ/gFQCEi/clJEpPKrhgD2PWvKbn9POPME6oXsgH9ugA3Y8JSMm3SzLQelP1Lj00RdGGPRIW0BybsJySC1a7isKkJwsck8wNq7kqwF4RzIVaM98NQDNNEww0pKvjy/Y7kHMjulU61iBWgkCM72Eos+88f8l+85OepCt75jKM+jypN5RLVqI03XTfPcPliapmktfgjY/R0aVyQaDYyP+jwPOk56Uge9XqmB7RtyV8CKmEJL6l6poNHDS/xeb/Cq6KUfluRIAwTZTba1dLym4/+RdLv00PDXoeMV2d/A8S0uSTm8KAyNQfKStUAlOaCWiLb9e0ku7ToaTpMBYZENX20RniLhT0pa924QPNFLvBnzVV/Cxo+d1OlxZLivO7wb+t2d5mfI0VWNKsLcD0DBBnnFVHo2phCEEuJSzj69zguA9YQZpokKhiCew== X-Forefront-PRVS: 0850800A29 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN1PR05MB057;23:r4HLImRJcwhCP1iJFLKDo6d6AB+Z82wx/bwGnLLg74?= =?us-ascii?Q?cZaEtTFLT0k9DaC7UVunbCkhSJhz5PT/Q3zhgr90TFVYelBPaphtKUF1y1yC?= =?us-ascii?Q?AkTyx7jj0pdC0b9zNLhmUDxhmGcMb8JbT1+12GPzTffzUmRD/CaCVg4nWAUa?= =?us-ascii?Q?9KFemJPh1Evq9Xxu0TZq7afq58o1aR8GDX6RX0nxjFkOJVCqHmJQOU8TV+k5?= =?us-ascii?Q?RZPyEOJpr9j/Bx/jgNHEYxifcqs++rsq5dyqEdc8MuJ2KIqh9aGx9/PKBIOz?= =?us-ascii?Q?C+ddg5Ee3RjAJe0ZqwcsESSPMLzbzhVH6xNCRfmHeb7j0DCy6JgPF/FSkfhr?= =?us-ascii?Q?n5Rfrdqxm7FGYdStxBSTEGdl3ibBSCEu8zhTvZyBRBUlqWywGmJBQWquHpfC?= =?us-ascii?Q?hLvm9R+GkNaASHin0mfw2eVzPfo2QOZlBM/GihpLXF8Q3PfbiIwpJo9fezP1?= =?us-ascii?Q?cbPdJaWmyqPQSMRK4dFR5ohD2nQCvHCs9rJ6pZqCD6s4e4ZwUUxEPzR0HtPk?= =?us-ascii?Q?Hp7VpikjgDybUCnqAJQ+7D+wKtfpgWMCha3W1rx7BiadOLlDKyW5ghc0PCc8?= =?us-ascii?Q?oXiWi6vzLLm34G5J9UiyZgREh9MDchJUcUfwJqk7ieWH30ixsgEUPEjKEHKd?= =?us-ascii?Q?6/qE1tcJIUsd0PpMADApmCf6QpWW2WCsLUhw8QtqhA+8ezLNFXNq0WFP5Udn?= =?us-ascii?Q?/adXxOlSgAqDZ147I4vyIKRviQZENgzvlJKpuczaZah1UsXZpKgj1pzim3vr?= =?us-ascii?Q?rkZHE/HaCbpR66NJmsg0NeKdmKiB0NQRf5DnygmkSyi1nekPp0mng6qwvXu3?= =?us-ascii?Q?0O3kKU5En7TrzNVctmFlI8DuAW4NdZZXd+6+W9d8vMud17FDwLfkodDzSEUB?= =?us-ascii?Q?2OXBen6mrQ3D/m/PXEDf2B0HqNATHKWzgCfD6CsPOJVYqChjXUc9uSKvy4g4?= =?us-ascii?Q?58Dlsj/mF7zoJI4JP3vs6LvrtaxOOx5fLP2Nb3beBfMf4h4uexOpn9y4xdl0?= =?us-ascii?Q?g=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB057;5:MI7vMdxx0Hya3DjEI2H31p/7EiRQureFQfn2sI/8kYrmpVrRKqgxh3rNi9HHNOU9iaZge2WhpDX0DPwZQwIz6HY5ZbrIYEu/8Kf5cLWi6siRbXw7ai4XCX3vBOZ1m6XrdggOAV3d0CkVxiijCcbzCQ==;24:/7CZSxp9RaggsDQVnPUVL0v/h8+FiAdHqneAXhsgQ8CnpAN39ilNWfI5Xs5D5gCi1l5GEql6IiZClCS99WJmpqE6d0x1fkK+p8GA0t7pZqM= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2016 07:49:48.0134 (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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB057 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi denis, Two questions: a) Should the draft list all of the Key Exchange Method Names in the https://www.ietf.org/assignments/ssh-parameters/ssh-parameters.xml table? If so, does the following capture the desired state? Key Exchange Method Name Reference Note diffie-hellman-group-exchange-sha1 RFC4419 NOT RECOMMENDED diffie-hellman-group-exchange-sha256 RFC4419 OPTIONAL diffie-hellman-group1-sha1 RFC4253 NOT RECOMMENDED diffie-hellman-group14-sha1 RFC4253 OPTIONAL ecdh-sha2-nistp256 RFC5656 REQUIRED ecdh-sha2-nistp384 RFC5656 REQUIRED ecdh-sha2-nistp521 RFC5656 REQUIRED ecdh-sha2-* RFC5656 OPTIONAL ecmqv-sha2 RFC5656 OPTIONAL gss-gex-sha1-* RFC4462 NOT RECOMMENDED gss-group1-sha1-* RFC4462 NOT RECOMMENDED gss-group14-sha1-* RFC4462 NOT RECOMMENDED gss-* RFC4462 OPTIONAL rsa1024-sha1 RFC4432 NOT RECOMMENDED rsa2048-sha256 RFC4432 OPTIONAL diffie-hellman-group14-sha256 This Draft OPTIONAL diffie-hellman-group15-sha256 This Draft REQUIRED diffie-hellman-group16-sha512 This Draft RECOMMENDED diffie-hellman-group17-sha512 This Draft OPTIONAL diffie-hellman-group18-sha512 This Draft OPTIONAL Note: I do not know of any rsa2048-sha256 implementations from RFC4432, I suspect at least someone is using it or it would not be in RFC4432, who is using it? A similar question for gss-* and RFC4462 comes to mind as well. b) Is it desirable to specify all of group 14, 15, 16, 17, and 18 as to the hashing algorithm to be used NOW? Or, is it better to drop 15 and 17 for now? If so, is it desirable for group14-sha256 to be REQUIRED, RECOMMENDED, or OPTIONAL ? diffie-hellman-group14-sha256 This Draft RECOMMENDED diffie-hellman-group16-sha512 This Draft RECOMMENDED diffie-hellman-group18-sha512 This Draft OPTIONAL Thank you for your consideration. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Feb 12 05:43:26 2016 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 D4A1F1A00EF for ; Fri, 12 Feb 2016 05:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001] 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 TOAy9qC08pHE for ; Fri, 12 Feb 2016 05:43:24 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 4B8BC1A00D5 for ; Fri, 12 Feb 2016 05:42:40 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0771785F24; Fri, 12 Feb 2016 13:42:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9308284CFD for ; Fri, 12 Feb 2016 13:42:35 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id FfaqMuQ5CN-m for ; Fri, 12 Feb 2016 13:42:34 +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 2AA2D84CE9 for ; Fri, 12 Feb 2016 13:42:29 +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=1455284554; x=1486820554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KEaXPKwAWsBXLUbc/7U9G7c+em1UGJdXQdXxE/JX/ng=; b=WPAAAo/G3q5yQ49iTI/p/zEm5mcHSsw3t8kkKefihAVkIc3/qakVfLPp h5ClWo0P9MtsNM0ZiWFV/iKZDK16jWjsEAkhA2XwH/qheUaSudZOPI+0K jVYtXHoOMdVqfyAPtZTLKjLW7Sycf69fN/AdXWIhkzMUv6Rr0/Tm77edR sOepszRkyO8k9qt6hynO5Pkzj78REF5F/bt8YHMh2ts5VrQwMrrlfXLiq fqiH5I2sMrW2710nZJTaaeuoZ18nNBjzKfG3fatGQvCP/EX18ZKTqjSMC OEfZIp8BpmntT3xNy8lPVf8IBVRmj3ZcGv2wboTzG8fBRKb69L0OrLfIw w==; X-IronPort-AV: E=Sophos;i="5.22,436,1449486000"; d="scan'208";a="67626512" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Feb 2016 02:42:23 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Sat, 13 Feb 2016 02:42:22 +1300 From: Peter Gutmann To: "Mark D. Baushke" CC: "ietf-ssh@NetBSD.org" Subject: RE: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Thread-Topic: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Thread-Index: AQHRZCfqehwX1UzzoUCPK38cAZMnbp8obYI2 Date: Fri, 12 Feb 2016 13:42:22 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BEE4EB@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4BEC444@uxcn10-5.UoA.auckland.ac.nz>,<86698.1455125066@eng-mail01.juniper.net> In-Reply-To: <86698.1455125066@eng-mail01.juniper.net> 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 mdb@juniper.net writes:=0A= =0A= >RFC2119 says that "SHOULD NOT" and "NOT RECOMMENDED" have the same meaning= .=0A= =0A= This assumes that whoever's reading that knows that 2119 exists, and bother= s=0A= reading it. If you're dealing with an industry standards group doing worki= ng=0A= on, say, PLCs for infrastructure control whose primary goal is to find reas= ons=0A= to avoid changing what they've got now (not that I have any experience with= =0A= those or anything...) then they're going to look at "NOT RECOMMENDED" and= =0A= decide that it's OK to keep using SHA-1 for the next ten years (literally,= =0A= that's the time frames they think in).=0A= =0A= >To make it stronger would mean moving to "MUST NOT" instead.=0A= =0A= No, just use the SHOULD NOT wording option rather than NOT RECOMMENDED. Sa= me=0A= for the others, SHOULD rather than RECOMMENDED.=0A= =0A= >The terms are supposed to be understood in the context of RFC2119.=0A= =0A= See above. People working on things like SCADA neither know about RFC 2119= ,=0A= nor care about it if it's pointed out to them. They'll look at the spec at= =0A= hand, take the simplest option in there, and go with that. "SHA-1 isn't=0A= necessarily recommended but we have legacy considerations so we'll keep usi= ng=0A= it forever. We can consider the other recommendations in the next=0A= standardisation round in 2025 if required".=0A= =0A= >I have no strong preference for which of the equivalent terms are used if = it=0A= >helps make the point better. Does it really make the point better?=0A= =0A= Yes, definitely. SHOULD NOT is pretty explicit while NOT RECOMMENDED is,= =0A= well, something you see in restaurant reviews.=0A= =0A= >The concern for SHA-1 is specified in the Overview nd Rationale as well as= in=0A= >the Security Considerations section. =0A= =0A= The Overview portion, which is the one that'll get read, mentions "security= =0A= concerns with SHA-1", which really doesn't tell you much, almost everything= =0A= has security concerns to some degree. So I'd be good to have the note with= =0A= the text I proposed saying something like "the SHA-1 option is provided for= =0A= backwards compatibility, shouldn't be used in new designs, and should be=0A= phased out of existing ones as quickly as possible because it's not secure"= =0A= somewhere close to the SHOULD NOT -sha1.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Feb 12 05:52:40 2016 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 34AAF1A00F9 for ; Fri, 12 Feb 2016 05:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 av5WWGPnoric for ; Fri, 12 Feb 2016 05:52:39 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 427101A00E8 for ; Fri, 12 Feb 2016 05:52:39 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 1B8DB85F05; Fri, 12 Feb 2016 13:52:38 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C2CA084CFD for ; Fri, 12 Feb 2016 13:52:36 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id VU1G0jjQxU8s for ; Fri, 12 Feb 2016 13:52:36 +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 DE3E784CE9 for ; Fri, 12 Feb 2016 13:52:34 +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=1455285155; x=1486821155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lAaZP7Rl+Kg5hKDdb9+SQjm2BDeH36jWCvjo1CJgA2c=; b=u5f5fajYjzl1+Y3vcPz6HQfAqJqbFS8ncKOI3be5TOAU/i6T/ObYM7Pp 2icxSHNsdP7Xa4la9DyLjVvt+HgUNaxIcAA3kZE3unLhvwokjPzhAfsiR WIaZGGy37zW2Th936kpbvHxLnyo1zcjYw0zI7jtWSOytRbhMkH3HPHvzp EZYeX9y1P6ecDlpTYVrOmVcIxR9uTxbuwYfTe7dxfyiP1+KqDHgtWF5QU QM0/DN+cRN/jEEKJTOAe72KvmpxjOfvHAx49y3Km9VbHMoN1+Ut6oKj1a +XHSqnmlskTK4Wc63KSES6A9DSrahqCguj9NTnlMYcFDYRWhjCh3YoNnj w==; X-IronPort-AV: E=Sophos;i="5.22,436,1449486000"; d="scan'208";a="67627233" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Feb 2016 02:52:33 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Sat, 13 Feb 2016 02:52:33 +1300 From: Peter Gutmann To: denis bider , "Mark D. Baushke" CC: "ietf-ssh@NetBSD.org" Subject: RE: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Thread-Topic: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Thread-Index: AQHRZWYvMdJDQld0Qaiw70eVAW98z58obk+4 Date: Fri, 12 Feb 2016 13:52:32 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BEE53B@uxcn10-5.UoA.auckland.ac.nz> References: <99035674-2196@skroderider.denisbider.com> In-Reply-To: <99035674-2196@skroderider.denisbider.com> 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 denis bider writes:=0A= =0A= >If we settle on SHA-256, we run the risk of having to introduce SHA-512=0A= >versions a year or two later.=0A= =0A= Why would we need to do that?=0A= =0A= Peter.=0A= =0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Feb 12 09:48:42 2016 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 6199A1A8733 for ; Fri, 12 Feb 2016 09:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 ZNoMykd-mh7D for ; Fri, 12 Feb 2016 09:48:41 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 37E241A8731 for ; Fri, 12 Feb 2016 09:48:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 10B3685E82; Fri, 12 Feb 2016 17:48:40 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E3A5684CFB for ; Fri, 12 Feb 2016 17:48:37 +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 2TdtMMpqH6zk for ; Fri, 12 Feb 2016 17:48:37 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::795]) by mail.netbsd.org (Postfix) with ESMTP id 8225384CE9 for ; Fri, 12 Feb 2016 17:48:33 +0000 (UTC) Received: from BY1PR0501CA0034.namprd05.prod.outlook.com (10.162.139.44) by BLUPR05MB055.namprd05.prod.outlook.com (10.255.210.150) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 12 Feb 2016 17:48:31 +0000 Received: from BN1BFFO11FD018.protection.gbl (2a01:111:f400:7c10::1:152) by BY1PR0501CA0034.outlook.office365.com (2a01:111:e400:4821::44) with Microsoft SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Fri, 12 Feb 2016 17:48:31 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; cs.auckland.ac.nz; dkim=none (message not signed) header.d=none;cs.auckland.ac.nz; 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-emfe01a-sac.jnpr.net (66.129.239.18) by BN1BFFO11FD018.mail.protection.outlook.com (10.58.144.81) with Microsoft SMTP Server (TLS) id 15.1.415.6 via Frontend Transport; Fri, 12 Feb 2016 17:48:28 +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; Fri, 12 Feb 2016 09:48:11 -0800 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 u1CHmAD99573; Fri, 12 Feb 2016 09:48:10 -0800 (PST) (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 B1E89114A5; Fri, 12 Feb 2016 09:48:09 -0800 (PST) To: denis bider CC: Peter Gutmann , Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) In-Reply-To: <114857654-3608@skroderider.denisbider.com> References: <114857654-3608@skroderider.denisbider.com> Comments: In-reply-to: denis bider message dated "Fri, 12 Feb 2016 11:52:46 +0000." From: "Mark D. Baushke" Date: Fri, 12 Feb 2016 09:48:09 -0800 Message-ID: <89441.1455299289@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD018;1:rA6QWyppfsV/pGnI4EC2R3cIt92l+6DTxvDqTYfk3jHb8oRFZkhHMp80DM3qQlMRxNe0+OKlfgi/HY+u5EYbCbzGC8vh7UjMQq79cuHVJFPH4vx5hsr4VzEfbQOn7ntwVbIfrjdO1fews0ybhMCXBagbzk8O33zqwxMUydElNEWdTUUeEWjI0ePF/9sO3/Z33y9uvLTfFdYAcaR8Bpp8S1fPzgl/nn54AV3sqcpNV4CegjSTrWnsSc2TUkKf5lslgwteF2JFLaIkdGmlS9eoKkABC48UVmHEgNqGfZi0jgbEWmeMY4bcQPt+QJFQsQuiwqG6SXscp4groiSq9Fm+CHrQ++Ko3ici0P4E2zxYlZ15RqGJEtGIIV+mjT6O0T0FFCv9yVMDlYDDTMri4l5bRL4DaLPuzE6fKYBGHzakV8M= X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(189002)(586003)(77096005)(54356999)(4326007)(15975445007)(230783001)(1220700001)(1096002)(189998001)(110136002)(76176999)(2950100001)(11100500001)(5001960100002)(6806005)(117636001)(2906002)(53416004)(106466001)(50986999)(19580395003)(2810700001)(5003600100002)(105596002)(86362001)(48376002)(87936001)(47776003)(76506005)(5003940100001)(50466002)(92566002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR05MB055;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB055;2:tNRd11m5u2H/lXg4ReCJAqJevdbbNGgXM9xRS8tSao8nSaOSNB72RLYKBTFB+JHmvUMiE0KYCEp+J7xbtQO3Tk/2w9/b19biJ9oUtO2/Y5+3Uvw1EF1WzuDv0zsiln63CA4z31Zfk6S8ITiaimlfmw==;3:eF/YPLRp20Gj8ST2cVjLx0y9fdBbSOZzsGWtLqWnNUg1oeWJLXEKiYkeFwSXtFXtLNJh6xZjSd/hbAMN5enavEnh+c0TBzLOLHkNHcDlSxYNTUNHr+hYt9kapAwv1gc80k91hSGCujgqFo6qzCxsCXyXithoTxk7uBApMxRkUpDN7bq80jCe7gp4hGoEFQJ6DhaTs6PI8sFrmtC5PE+YDfxCA4PS46uJAVwTSSF/jUU=;25:1EHHuJrjQxZTQkQIPR+ahUMR9z+35gw2q6iNOJfvsn0H18Taj8M1D4i4SYsk42j7/Dbtet87B48GuD6BhiOkOpZBRboAiXfcqUQ/MmsH3RXtjEmtBlAuxHmBfNlqnkMziMF1P53NIvmwYrO5i8Opz4x4NFjjsq2QNYTDHbrQygGnPW1ZtrzmOnvpgHOZh2t6Y6ESOWftPyJHKVrAPXx/s+mvHt9ShWw4dYj6WVsBCL+s+3IeOuUD86IrKgfpDkUpGLhcrSNlujGHjM+vT+gTPWMSFkvz2MjrO9ArGcXvUwAVKw1bXUjBqYuXbK+1hJuz X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB055; X-MS-Office365-Filtering-Correlation-Id: 0382c29f-68a6-46c5-060d-08d333d4b753 X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB055;20:kCLbjUybXyK7W2fWHM6MwDdpGk3iQZhYp/9dJdNNX/IgTZlDT3oOaCmu2RFdA1m4zmSL5sRTgJ1DVe3aypq0dtKvpbtbaHy34DermgKDl4UoimZ87T3E2kfH2j1Echx+mA/976AKh5oeSfjR1YVqmgzbsLYwAlLhesbFoSDOpnMzsd+CTGlwJcmBG34JdXTLCfvxlKafIs0/F6VD3cTHpZCdOgiNwllTX8TVZs4plGF9qQ0st9KqSD3KigTWVZotCQlfDTKShSGFJLnHAiKom1J6yL36iElhlaFoDHdm7blE0sKLt8h2zbrLbbXNzit6OHOFDlYGYMYKx3uygW8Iy2FMhHTg0TqXtypYPiwtp1H7zRnQ0j55XDrP7JfmSnN3XB6XK4GViAqJa9l4KuDW94MVFnwq5ZHccv2tvlqAUHhEFYlUFIxWyp6RMJLOCLAaFlB7ueS2zTVXTuDdbkkNcd0ecYbNHLBcslJZeVnM1O3jlooDFLb9CecRX/DOLYvf X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(13018025)(13017025)(13015025)(13023025)(13024025)(8121501046)(3002001)(10201501046);SRVR:BLUPR05MB055;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB055; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB055;4:8X9dXlSABzCuKE4gJDjeF16UYZCKLQ6HHues0xG1OzQuzfQQSgEyFOupKQhdTGOGGhIiKrrvj8LgoSljICN73efbuG36BrJuc1Oa6inGJM4sDHeuyScFixuoBi6iRfaWZjgg6kJkKgVIaZOZIPdsRgPHnweHQ26tULpqC8d97kVuLX29ptRxjM4eKVZbcTGrPzgnRtDooV2iDve45jb8yv3tmHJzSg4uIdjcvy6f8wsPs03a3fXhN094lu8Lr7MH5CHIJQoB2AbIgihP/fBd49rxltRaiFojIht9VSqKJegr9j5b7o7aUYBCHEKDJD/sqmsQ/U3KhdNekLcbSm2HNjhbPRoov2rECVULO28N9luKmoRqE0Jl0vmsaPC7xmdsFHhGx+09PHYpm/f/vElXnWWzn2/ZjKnPpDvAjvP9JZpTiy1kWwtA4ESEL3GICG8IxC7d/IvHnL9/2ly8oGJd3A== X-Forefront-PRVS: 0850800A29 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BLUPR05MB055;23:mnTdVfoAgY/eWakHaZvFL18+oi0VNd/kMhGYoSLTq1?= =?us-ascii?Q?LQs/keiK3gZ4zQNx1P9B1tr7svzNYtKa1ILxDq74PiE8T/47Q+vDkioG4ohG?= =?us-ascii?Q?2I6JBadpRl1iFC74p7cHzNjc5V/Rwg7PVdY/hLPHq6cw6pNnjKFEwvYf8llH?= =?us-ascii?Q?X4PqbH3/WVqdNC4xFSus3EuSxOcWr1dyLgtfJOXNEnVh10Fe9bS5thyDFYz7?= =?us-ascii?Q?v+j7qughOx8Jto/R2GhbFPOj7eC+EqPWUAaV2va4u7d2/RQUQOaYwA+x99j6?= =?us-ascii?Q?oac9Ru2r9ijTkxD5SYWlfqb/TupYTReUGUI1rcEyXx8QUsiox7M8QyxEsqx3?= =?us-ascii?Q?YALE1MKH7ZwD80b0gQnuX/M4DCDxjrjH5lblM33wwN/z2zbjaa0hkKcmY65y?= =?us-ascii?Q?h4zVzDTZD4NUd7K5hfcqtEinafWchK2wF8toCmF+eCDgOqT/LwzX+9yPe233?= =?us-ascii?Q?7I4PBEkm2i2lNDMNl5DbAKDiQA83m48QY4kWszBwdm40cstiB17htV+UP+1A?= =?us-ascii?Q?mzdZ77seD4BbHknFBmmT8oNiOAY02hh58zMp4T6CR1li5/vJPsrOh7EjsfjJ?= =?us-ascii?Q?4qNaP9mEEBLlG9hmzcJdOKfmiYZv94sfDnfmHdAJHXBKPtFTVeBUwzB4NQ/A?= =?us-ascii?Q?1lzdOplnDigddVBAMW1cP1ZNt/G7b3GQ3qwBqLXIyPZ1Yz1pyd+sZqZIWYLG?= =?us-ascii?Q?GHRRegN4TL2sXcuYDkftAfLSeYJwztAIaf9WOZFxg67mmC0zKwsp/2lTq9Em?= =?us-ascii?Q?kcF5creZPoLqbgt/du3KYbRH4FQENNyvO0S9Dpk//nhktTgDEYk6Q4BE/yjg?= =?us-ascii?Q?4aGc8yvXB++hDpz08bSlomXq5TJotMzPpiuMsepMRMP4Em3feaKJr5jJ+adG?= =?us-ascii?Q?EQTIslkVdgoAbaJ9lB65iUNuSAHYVn80VshcOw0TRg/JTmZYozVJbsTSXg1G?= =?us-ascii?Q?LRo7nFY19PCaLwY06D0SPAMb4O8IJAbN1jxCIvCG8IcTz9l029qU1wbSGoqx?= =?us-ascii?Q?M=3D?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB055;5:IvIdHr1M/tJNvcne1u8A85wEVAg3mAwZ6l1oHsrwISmxEC0N6ec0jth1OdtXzRNBx/6PXKcF84wEUBkhEAXyocctsmWfNF94LNH11t8l++4CMRVWI//Wq1ojrC4sPKM49yJdR2AIU3uJENG5WsPENA==;24:QmvgR1BBfJ7alcDs2PeUTg0j8s4Bc0agJJHdmBVOyub8LVD1dRNNakc484afzc3HcmkQnpBmE4U3tyK/GxebOIWtiT0KbS8ZPkJBerBfypg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2016 17:48:28.7538 (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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB055 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi denis, You have made some good points. I have updated my draft to -02 and it is in the process of being uploaded to the ietf servers. For now, you can see the latest edition here: https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/ I think I have the normative vs informative references in their proper locations, please let me know of any nits that still need to be addressed. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Feb 13 07:44:31 2016 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 5B5811A0196 for ; Sat, 13 Feb 2016 07:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.094 X-Spam-Level: * X-Spam-Status: No, score=1.094 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 rNBX8yKpMqo4 for ; Sat, 13 Feb 2016 07:44:29 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 227301A0194 for ; Sat, 13 Feb 2016 07:44:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4059185E13; Sat, 13 Feb 2016 15:44:28 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 22B1B85DFE for ; Sat, 13 Feb 2016 15:44:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id DoHRshfBLRs7 for ; Sat, 13 Feb 2016 15:44:24 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.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 49FEC84C6C for ; Sat, 13 Feb 2016 15:44:22 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7AA9B4000B; Sat, 13 Feb 2016 16:44:19 +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 8115E40004; Sat, 13 Feb 2016 16:44:17 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Sat, 13 Feb 2016 16:44:17 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: denis bider , Peter Gutmann , Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) References: <99035674-2196@skroderider.denisbider.com> <24239.1455263382@eng-mail01.juniper.net> Date: Sat, 13 Feb 2016 16:44:17 +0100 In-Reply-To: <24239.1455263382@eng-mail01.juniper.net> (Mark D. Baushke's message of "Thu, 11 Feb 2016 23:49:42 -0800") 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 "Mark D. Baushke" writes: > a) Should the draft list all of the Key Exchange Method Names=20 > in the https://www.ietf.org/assignments/ssh-parameters/ssh-parameter= s.xml > table? I think that would be helpful. > If so, does the following capture the desired state? For discussion, it would also be helpful with another column with the previous status of the method. > Key Exchange Method Name Reference Note > diffie-hellman-group14-sha1 RFC4253 OPTIONAL > ecdh-sha2-nistp256 RFC5656 REQUIRED > ecdh-sha2-nistp384 RFC5656 REQUIRED > ecdh-sha2-nistp521 RFC5656 REQUIRED > diffie-hellman-group15-sha256 This Draft REQUIRED I don't think it makes sense with multiple REQUIRED algorithms. (Side note: The exact meaning of REQUIRED is somewhat unclear in the presence of local configuration. I think it means that an implementation MUST implement it and it MUST be enabled in the default configuration. If an algorithm is implemented but disabled in almost every actual configuration, then REQUIRED won't be of any help for interoperability). To me, the point of having a REQUIED algorithm is to make it possible to do a minimalistic implementation cutting off everything optional, and still be able to interoperate. And implementing three different EC curves well is not very minimal. It also seems unfortunate to degrade diffie-hellman-group14-sha1 directly from REQUIRED to OPTIONAL. It would be a nicer rollover to move it to RECOMMENDED (or RECOMMENDED until some specified date, if that's possible). And then elevate *one* other algorithm to REQUIRED, where I think my preference would be for a non-ec dh method, since (1) it's simpler, and (2) I think it's desirable over the coming years to move away from the old curves to "safe curves". If it really is necessary for security, deprecating diffie-hellman-group14-sha1 asap is the right thing to do. But first, I'd like to know if sha1 is believed vulnerable in the setting where it is used, mainly for key expansion. Attacks are a lot easier with input under the attackers control, but I'm not sure that happens when sha1 is used in the key exchange. E.g., I'd be surprised if there are any real issues with using sha1 to expand a *secret* diffie-hellman master key into several subkeys. > b) Is it desirable to specify all of group 14, 15, 16, 17, and 18 as > to the hashing algorithm to be used NOW? Or, is it better to drop > 15 and 17 for now? If so, is it desirable for group14-sha256 to be > REQUIRED, RECOMMENDED, or OPTIONAL ? We probably don't need all of them. I think what's most important is to have sha256 together with one or two groups with estimated security corresponding to some 250-300 bits. 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 Sat Feb 13 14:27:01 2016 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 2D5881A8881 for ; Sat, 13 Feb 2016 14:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 7HgKqEwV4dkF for ; Sat, 13 Feb 2016 14:26:59 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 D5F5A1A887D for ; Sat, 13 Feb 2016 14:26:59 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 58C4985E77; Sat, 13 Feb 2016 22:26:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 44AC885E60 for ; Sat, 13 Feb 2016 22:26:56 +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 tB8Y7u0Nd8Eq for ; Sat, 13 Feb 2016 22:26:55 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::753]) by mail.netbsd.org (Postfix) with ESMTP id 8B24B84CED for ; Sat, 13 Feb 2016 22:26:51 +0000 (UTC) Received: from BY2PR05CA048.namprd05.prod.outlook.com (10.141.250.38) by BY2PR05MB061.namprd05.prod.outlook.com (10.242.34.141) with Microsoft SMTP Server (TLS) id 15.1.403.16; Sat, 13 Feb 2016 22:26:49 +0000 Received: from BL2FFO11FD046.protection.gbl (2a01:111:f400:7c09::170) by BY2PR05CA048.outlook.office365.com (2a01:111:e400:2c5f::38) with Microsoft SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Sat, 13 Feb 2016 22:26:49 +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-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11FD046.mail.protection.outlook.com (10.173.161.208) with Microsoft SMTP Server (TLS) id 15.1.415.6 via Frontend Transport; Sat, 13 Feb 2016 22:26:48 +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, 13 Feb 2016 14:26:47 -0800 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 u1DMQjD53955; Sat, 13 Feb 2016 14:26:46 -0800 (PST) (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 56EC0114C5; Sat, 13 Feb 2016 14:26:44 -0800 (PST) To: denis bider , =?UTF-8?q?Niels_M=C3=B6ller?= CC: Peter Gutmann , Simon Josefsson , Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) In-Reply-To: <223360780-3264@skroderider.denisbider.com> References: <223360780-3264@skroderider.denisbider.com> Comments: In-reply-to: denis bider message dated "Sat, 13 Feb 2016 17:59:24 +0000." From: "Mark D. Baushke" Date: Sat, 13 Feb 2016 14:26:44 -0800 Message-ID: <86136.1455402404@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD046;1:n+C4/r5arsqNoYaqrDeMRiuWs5U80FIRCYogx9+1RPBl8VCtQeyjEmoeYij95uSTDZc5V/QPetVrPD1gZfSWghv6R3iOYbSbAf6FvWGG299tMZXkXA6q+oHKUHY4Ox7abQxctVHxma5gZbt96sQP0fK4jkUpNai5Lh7cBzClTrhfjbfjg5JtFB6iJ2YseN9G4v9vM8D5RM1uEeJEqZqXLLHb+9D25r050VSYGfB8QzStd/ZpnB2oFTDcARRU3AiP+rOJ3cAQzTv99FWGmf44y+4qMV9BIB5XMNRqSDuiPzIXoZRn9ABqKPk1XzL+3kINxPA0YCZraRkm2ryuROEp2iHRBnnqo8IpX4LGClMJphNbj1TiyvnV3e769mEzcUHlJR4Md2aprPhFbzr7LL6JTQ== X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(189002)(50986999)(47776003)(1096002)(1220700001)(5001770100001)(76176999)(54356999)(2906002)(50466002)(4326007)(189998001)(19580395003)(5001960100002)(5003600100002)(2810700001)(586003)(92566002)(76506005)(53416004)(2950100001)(117636001)(86362001)(87936001)(230783001)(5003940100001)(6806005)(11100500001)(48376002)(105596002)(77096005)(15975445007)(106466001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR05MB061;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB061;2:+05C7b056ARa9opEmsce3VullzTPjOEFLZMM7E+mmugWSPT2TeJJCvdgPRhQcqcPZ0qlqUW0c360YEVm8y7zGUVdNeHV9bRQGTDsIqnHJQ6rNNdiYzloI8jSZQQhqooYDrP+ErxdnBGPn2NO5M+Hfg==;3:vTsYBpeeGUQUotqHVTLFMzgtPlcFHknGDUXWOYFWEjsCXWntU9hOE0QToeBVVD2/EID/8w18vvSYftuLUy8FoMh0eJl0dSwxbCdMXY1KFXbpbjbE7VUtU7fcOTmFNytAzfrjl7WAZgDmgcdlO1VOWQ3du4gSPUmcyL6mpo5DxsRruaAe/gwMG+LAf1Wt3AQ74E4Wc5WKdP1gSvRMg9HbFdRLgRgIONewFWUma96nqPo=;25:2MasyLsL/5YGGfeCu7U5dV+TjtBV2Rs+BW+ZBU9xCJPsjKC4G/xlFAeTAeCUljOkxUakwQAU+YT/K11gE2VkELVDCwvKjeNIRXghdxUUdNiZpK8T2qpSOSMYO+3NEILAh1yKpM3dJo5ZTw8zMitKyVsWglY2OkcnUT46M364LyclmgJH5jTwaOxeI28yFDgwQ9Q+YVbSLS3ABFKolFGuXT79UqQ+vfvKQKrJVWKggeYSBUXRY/w6KZ9e2ekO4k0KYbFBdG6M8wm0I2izRduMiBpVo2iyACwfvwR5g9V/2VB64qZgTNzQMvjiG4D/HohC X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB061; X-MS-Office365-Filtering-Correlation-Id: 1fbb32c2-3b11-474d-9e44-08d334c4c378 X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB061;20:91H/7y8dTIp2JggiAKoAwpHnOFPV9+Zzm+Ju8pKoxGmIrYPI6B2sBpEyqXy2hRyVAWyWiypx33Up5bEocbPWrNrt/nCuEbfekRS8JrMbUGhOTWjQn77JJjGUdrgc5GKBtpIW0jZC1nLviFtc+UGmpE29EAJlKsKdyYw/gtmoe66ZSginoJNLGS08qcdab6PpvGoamjwaAcpCyzYYL8OmkHiTsm7aF/f+phmQGRx300WENa2Uz8HU7ZoBRLlXcHSohlDqGDlyUIJDwpW4sbOyJHmZCF0PWWfLCdjjSKvTYtDBk4fU5SK4Z48AXtPex9VZMYsWVkra2eTkrTel9ABPzIFiAyJdOZScMbsJl8N+sqMScwlP3TaFJl2XRwwPpXRwdJHItP2yWTPAxnxwBnrDQgOSxhENum/r26ma7UpFZLgz9r42pwofBY+9TBtScJdX7lh/uAituwGafsN/CWPqL6Aus9k75JbrwU4KcE/RKPl6suJNzKwkYSbPNUlGj/DL X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13023025)(5005006)(13018025)(13017025)(13024025)(13015025)(8121501046)(10201501046)(3002001);SRVR:BY2PR05MB061;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB061; X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB061;4:1ZJEQDTcnk4PF3bd22jqb7FwzOGixBr7ErE+niMZ+yD1iOG58JmSlnKk0rjHRAZBH42lspa5IuXR0w7VQOJWwZnEMU0faWuzhmaHmsyW+9RF/kJ0VookvgNEEn8tDfLe9wSVxBXSRrz66VbltsiEP8B3tAiuPNxuB6I3ZSxTy4Mq0TbdvDansjoh1yoc1DXQk+osJpKkExqFwOsQP/Yh0rxquMtBjL//5mK/P29jAH/arQCQ56fFuUDRAVYpvPXtEFBAGPCDspuYlAEuqHF07eDj0RWKOzPV68aec3QIWri8bAg2DmOBrk/az/qIvl8ioTs7r6fjUVlgMmDfnJ12siG9ijJPntd/iOmN/2jMG/LZfJQR2hZ8CgYFhmA/fu9mCm/C120hLgbo76hcwMF4YxUmAbZYLDAV/3n1m7FRy2KRg6/MUKXRRVSlKFw9bq3JatN48Qo49UxFtZVkokX8jQ== X-Forefront-PRVS: 08512C5403 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY2PR05MB061;23:JSY87UHCLcTjE09ZYNLwFFSyHDqox+HsgbCVvvv863?= =?us-ascii?Q?o8r3Y2gtnysa6YNEuntKmjIEtLnbexW1BCiR4AHy1V/IcQhqvbVhbm6FH+Z9?= =?us-ascii?Q?3yLnYFZXJIZ7jqK9ImuGgUEW7nHjkFaNQNWCoy+AvNFxpHCY2ZbQ3HOexm0a?= =?us-ascii?Q?3cFhDhBJAdpPqJSvb6PAK9cw1sA7bnYGkRRlxQwFoaOqdFxkx/vLwY6BCP8D?= =?us-ascii?Q?Qo69vmy3XlNnn+rUX5vGCCPf/B4qQV9kmIqsMFN2o8hSlZswYKKxXwoQb+PV?= =?us-ascii?Q?OqBW42G9t8VUI4IkFGtRAxY8/hK2FINR95d9O1CWymMQO/X2EErOu4CIkY/F?= =?us-ascii?Q?d0RL7GWoWzl3GcQU0RM496GgVgkCNbFpsHJdlcJOpFuwczmsiHogpJPO0OsR?= =?us-ascii?Q?HpY2DFhA17uW9dUdVa5li6tsvAcQO+IXjBNGYN0h8WJ239ZIobX95ehoHd/P?= =?us-ascii?Q?nkDp3X+BdiaD3i/m5YOQ2DIodXWnRvTORwkq3BG2RC4Ckofeky4em1s8r55M?= =?us-ascii?Q?tH4PzyRInf1DhGjwKgBOicT65fTD0euG6bi5iGAtuHn/3CW9CkBV1prTNSX2?= =?us-ascii?Q?Q53AdO6xRXH0xH9EmeyNsSdCDfsMPP39UIBwRoOl+gulCI5u0ZRzTIoz3UBJ?= =?us-ascii?Q?ShSC06+LXwykjY/LBKaUKmXGaM286/MMToiiYgeWBNMwrLhtCBq4/wGq1Lnn?= =?us-ascii?Q?daBj5tckau4bcTfFedVS5LC7Lu6159HDObi9hJWAec28UrwFHd7D3NLe1Ke/?= =?us-ascii?Q?/aykeU+szK5GN2sFk9pYPPNy4o5cUrbtvrFCeAdYaFQOxuWzpkBpRzKaWdAA?= =?us-ascii?Q?RBJWEJwVrV7GM0n/YIGvoR24z5eolwqVqvJkWPjVo3jf6+TRHsNW+pZu5FCy?= =?us-ascii?Q?4jTpklJvdkVQqKLbpd6S/qLAhWZovtTvUsqE43byeqXolMrfV2cnJQVuFWXT?= =?us-ascii?Q?+Y/eb79o3/baaic3dOEVTXj1jOfB/gHw8Cal80/HAuwc8RibDxScZApeyNBX?= =?us-ascii?Q?N7BTYldoF0h/PwrzDKbZfX?= X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB061;5:jjyO1JNijG6lWn+bMa6hRAcIYU+T/KvEP20rIy7QMVY7KnmHkqrh0IBMHBOEZ7HO+leMzZtFG/CTtgNSJZfFZRdzTG7I/kVpQDcqZUAjfJERaeXCpA4vMBS49rgeC77O62QJVXCtjSIqEuuIyKxKdA==;24:781zVc/hMQot2On/QURRXrO5tTdTpzX5709VDptcaxzfF63DtZssVt1JB612yLJcMwicj6wyL5fPqtGc8LS8VAlXP9HlgGVd2VyvLtHUtiA= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2016 22:26:48.3324 (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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB061 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi denis & Niels, You have both made good points. I have adopted the updated text from denis and tried provide a meaning for the Note column. I have also added a pointer to the Simon's ssh-curves draft and included both of the currently published curve names in the table in this draft. https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/ Please let me know of additional comments. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 14 00:09:31 2016 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 10E421B3A84 for ; Sun, 14 Feb 2016 00:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.795 X-Spam-Level: X-Spam-Status: No, score=0.795 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 aonm1oNhOBvC for ; Sun, 14 Feb 2016 00:09:27 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 8C6FE1B3A7F for ; Sun, 14 Feb 2016 00:09:27 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 56ACB85E91; Sun, 14 Feb 2016 08:09:26 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 102DA85E1A; Sun, 14 Feb 2016 08:09:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 79A6785E70 for ; Fri, 12 Feb 2016 07:22: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 KxKOjT1MyWer for ; Fri, 12 Feb 2016 07:22: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 5DD5B85DFE for ; Fri, 12 Feb 2016 07:22:54 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Fri, 12 Feb 2016 07:22:53 +0000 Date: Fri, 12 Feb 2016 07:22:53 +0000 Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <99035674-2196@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann , "Mark D. Baushke" Cc: ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-OS4l+tW8wBeDI+FLqY3b" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-OS4l+tW8wBeDI+FLqY3b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey everyone, I think the draft as-is is more reasonable than the ideas being discussed n= ow. "NOT RECOMMENDED", being equal in meaning to "SHOULD NOT", seems to me the = correct choice for outdated methods, such as "diffie-hellman-group1-sha1". = Moving to "MUST NOT" is untenable, and would divorce the spec from reality.= These algorithms need to continue to be available in some pockets of deplo= yment, where the only viable alternatives might be no connectivity, or fall= ing back to plaintext FTP. It seems to me that Peter might have misinterpreted the draft as newly spec= ifying "diffie-hellman-group1-sha1", instead of its actual purpose, which i= s to demote this. In order to demote a previously defined key exchange meth= od, the draft has to mention it. The draft does not suggest adding any new SHA-1 based key exchange methods,= so I don't think there's much to be discussed about SHA-1 here. I would prefer to see SHA-512, rather than SHA-256, for group16 and group18= . If we settle on SHA-256, we run the risk of having to introduce SHA-512 v= ersions a year or two later. It seems more likely than not that embedded en= vironments will come under pressure to add SHA-512, anyway. denis ----- Original Message ----- From: Mark D. Baushke=20 Sent: Wednesday, February 10, 2016 11:24 To: Peter Gutmann=20 Cc: ietf-ssh@NetBSD.org=20 Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)= =20 Peter Gutmann writes: > Damien Miller writes: >=20 > >So my recommendation would be: > > > >diffie-hellman-group1-sha1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOT= RECOMMENDED > >diffie-hellman-group14-sha256=C2=A0=C2=A0=C2=A0=C2=A0 RECOMMENDED > >diffie-hellman-group16-sha512=C2=A0=C2=A0=C2=A0=C2=A0 RECOMMENDED > >diffie-hellman-group18-sha512=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL > > > >(but 16+256 & 18+512 would be fine too) >=20 > From an embedded perspective (which is what triggered this late reply) I'= d > prefer the -256's over the -512's, the less extra huge hash functions I h= ave > to include code for the better.=C2=A0 I'd also like to see SHA-1 just die= , there's > no reason to specify it in a new spec published in 2016.=C2=A0 Having sai= d that I > realise that there are other profiles that still specify SHA-1, but then = I'd > like to at least see the wording given as "SHOULD NOT" rather than "NOT > RECOMMENDED".=C2=A0 The latter is for restaurants, not security-critical > infrastructure components. RFC2119 says that "SHOULD NOT" and "NOT RECOMMENDED" have the same meaning. To make it stronger would mean moving to "MUST NOT" instead. Today diffie-hellman-group1-sha1 is "REQUIRED" so I only moved to "NOT RECOMMENDED/SHOULD NOT" are you suggesting a need to move to "MUST NOT" here? Today diffie-hellman-group14-sha1 is "REQUIRED" and is not mentioned. Do you believe that we should change that one to "OPTIONAL/MAY" and select a new "REQUIRED" key exchange to avoid SHA-1? If so, which one should now be "REQUIRED" ? > In fact same with RECOMMENDED and OPTIONAL, what's wrong with SHOULD > and MAY?=20 Nothing is wrong with SHOULD or MAY. Per RFC2119: =C2=A0=C2=A0 * "RECOMMENDED" and "SHOULD" are equivalent =C2=A0=C2=A0 * "OPTIONAL" and "MAY" are equivalent =C2=A0=C2=A0 * "MUST" and "REQUIRED" are equivalent > Those are more widely-used in standards. I have seen the terms used interchangeably per RFC2119. > In particular I'd like to be able to point to SHA-1 as SHOULD NOT > (which is pretty unambiguous) rather than NOT RECOMMENDED, which seems > to say that people can keep on using it for as long as they like. The terms are supposed to be understood in the context of RFC2119. Are you speaking of the use of SHA-1 in key exchange only? There is diffie-hellman-group-exchange-sha1 in RFC4419 which also uses SHA-1. I presume it is currently an OPTIONAL key exchange. Should we be moving it to a MUST NOT now too? I have no strong preference for which of the equivalent terms are used if it helps make the point better. Does it really make the point better? > It'd also be good to include a note, where the groups are defined not > down in the security considerations, saying that the SHA-1 option is > provided for backwards compatibility, shouldn't be used in new > designs, and should be phased out of existing ones as quickly as > possible because it's not secure. The concern for SHA-1 is specified in the Overview nd Rationale as well as in the Security Considerations section. Where do you feel it should be noted in addition to those two locations? > The danger here is is illustrated by the TLS 1.2 RFC: ...elided... Yes, I think we are currently trying to do the right thing with the Secure Shell requirements. I suspect we really do need to have at least one REQUIRED key exchange mechanism that is common before and after these drafts are published. Otherwise, we probably need to bump to SSHv3 if we are going to get rid of all of the MUST NOT algorithms. Are there any additional thoughts for this draft? Is it desirable to list out all of the Key Exchange Method names in the https://www.ietf.org/assignments/ssh-parameters/ssh-parameters.xml table and their new state? Key Exchange Method Names Method Name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Reference=C2=A0=C2=A0=C2=A0=C2=A0 Note diffie-hellman-group-exchange-sha1=C2=A0=C2=A0=C2=A0 RFC4419=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 MUST NOT diffie-hellman-group-exchange-sha256=C2=A0 RFC4419=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 MAY diffie-hellman-group1-sha1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 RFC4253=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST NOT diffie-hellman-group14-sha1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 RFC4253=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MAY ecdh-sha2-nistp256=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC5656=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST ecdh-sha2-nistp384=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC5656=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST ecdh-sha2-nistp521=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC5656=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST ecdh-sha2-*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 RFC5656=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Other curves= are possible? ecmqv-sha2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 RFC5656=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MAY gss-gex-sha1-*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 RFC4462=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST NOT gss-group1-sha1-*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC4462=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST NOT gss-group14-sha1-*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC4462=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST NOT gss-*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC4462=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 MAY rsa1024-sha1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 RFC4432=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST NOT rsa2048-sha256=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 RFC4432=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MAY diffie-hellman-group14-sha256=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 This Draft=C2=A0=C2=A0=C2=A0 MAY diffie-hellman-group15-sha256=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 This Draft=C2=A0=C2=A0=C2=A0 MUST diffie-hellman-group16-sha512=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 This Draft=C2=A0=C2=A0=C2=A0 SHOULD diffie-hellman-group17-sha512=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 This Draft=C2=A0=C2=A0=C2=A0 MAY diffie-hellman-group18-sha512=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 This Draft=C2=A0=C2=A0=C2=A0 MAY Above I have moved all of the *sha1* exchange methods to MUST NOT with the exception of diffie-hellman-group14-sha1. Should that one also be moved to MUST NOT too? If we want to fix RFC4419 to pass q in addition to g,p so that we are able to use Lim/Lee primes for q and allow for run-time checking of a g being a generator of the q-ordered subgroup, does that need to be rolled into this draft too? What do we want to call this option for negotiation? Additional comments solicited on these topics. Thanks, -- Mark = --=-OS4l+tW8wBeDI+FLqY3b Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey everyone,

I think the draft as-is is mo= re reasonable than the ideas being discussed now.

"NOT RECOMMENDED",= being equal in meaning to "SHOULD NOT", seems to me the correct choice for= outdated methods, such as "diffie-hellman-group1-sha1". Moving to "MUST NO= T" is untenable, and would divorce the spec from reality. These algorithms = need to continue to be available in some pockets of deployment, where the o= nly viable alternatives might be no connectivity, or falling back to plaint= ext FTP.

It seems to me that Peter might have misinterpreted the dra= ft as newly specifying "diffie-hellman-group1-sha1", instead of its actual = purpose, which is to demote this. In order to demote a previously defined k= ey exchange method, the draft has to mention it.

The draft does not = suggest adding any new SHA-1 based key exchange methods, so I don't think t= here's much to be discussed about SHA-1 here.

I would prefer to see = SHA-512, rather than SHA-256, for group16 and group18. If we settle on SHA-= 256, we run the risk of having to introduce SHA-512 versions a year or two = later. It seems more likely than not that embedded environments will come u= nder pressure to add SHA-512, anyway.

denis


----- Origina= l Message -----
From: Mark D. Baushke
Sent: Wednesday, February 10, = 2016 11:24
To: Peter Gutmann
Cc: ietf-ssh@NetBSD.org
Subject: Re= : draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

Pe= ter Gutmann <pgut001@cs.auckland.ac.nz> writes:

> Damien Mi= ller <djm@mindrot.org> writes:
>
> >So my recommendat= ion would be:
> >
> >diffie-hellman-group1-sha1 &nbs= p;      NOT RECOMMENDED
> >diffie-hellman= -group14-sha256     RECOMMENDED
> >diffie-hell= man-group16-sha512     RECOMMENDED
> >diffie-h= ellman-group18-sha512     OPTIONAL
> >
>= >(but 16+256 & 18+512 would be fine too)
>
> From an e= mbedded perspective (which is what triggered this late reply) I'd
> p= refer the -256's over the -512's, the less extra huge hash functions I have=
> to include code for the better.  I'd also like to see SHA-1 j= ust die, there's
> no reason to specify it in a new spec published in= 2016.  Having said that I
> realise that there are other profil= es that still specify SHA-1, but then I'd
> like to at least see the = wording given as "SHOULD NOT" rather than "NOT
> RECOMMENDED".  = The latter is for restaurants, not security-critical
> infrastructure= components.

RFC2119 says that "SHOULD NOT" and "NOT RECOMMENDED" ha= ve the same meaning.

To make it stronger would mean moving to "MUST = NOT" instead.

Today diffie-hellman-group1-sha1 is "REQUIRED" so I on= ly moved to
"NOT RECOMMENDED/SHOULD NOT" are you suggesting a need to mo= ve to
"MUST NOT" here?

Today diffie-hellman-group14-sha1 is "REQU= IRED" and is not mentioned. Do
you believe that we should change that on= e to "OPTIONAL/MAY" and select
a new "REQUIRED" key exchange to avoid SH= A-1? If so, which one should
now be "REQUIRED" ?

> In fact sam= e with RECOMMENDED and OPTIONAL, what's wrong with SHOULD
> and MAY? =

Nothing is wrong with SHOULD or MAY. Per RFC2119:

 &nbs= p; * "RECOMMENDED" and "SHOULD" are equivalent

   * "OPTIO= NAL" and "MAY" are equivalent

   * "MUST" and "REQUIRED" a= re equivalent

> Those are more widely-used in standards.

I= have seen the terms used interchangeably per RFC2119.

> In parti= cular I'd like to be able to point to SHA-1 as SHOULD NOT
> (which is= pretty unambiguous) rather than NOT RECOMMENDED, which seems
> to sa= y that people can keep on using it for as long as they like.

The ter= ms are supposed to be understood in the context of RFC2119.

Are you = speaking of the use of SHA-1 in key exchange only?

There is diffie-h= ellman-group-exchange-sha1 in RFC4419 which also uses
SHA-1. I presume i= t is currently an OPTIONAL key exchange. Should we
be moving it to a MUS= T NOT now too?

I have no strong preference for which of the equivale= nt terms are used
if it helps make the point better. Does it really make= the point better?

> It'd also be good to include a note, where t= he groups are defined not
> down in the security considerations, sayi= ng that the SHA-1 option is
> provided for backwards compatibility, s= houldn't be used in new
> designs, and should be phased out of existi= ng ones as quickly as
> possible because it's not secure.

The = concern for SHA-1 is specified in the Overview nd Rationale
as well as i= n the Security Considerations section. Where do you
feel it should be no= ted in addition to those two locations?

> The danger here is is i= llustrated by the TLS 1.2 RFC:
...elided...

Yes, I think we are c= urrently trying to do the right thing with the
Secure Shell requirements= .

I suspect we really do need to have at least one REQUIRED key exch= ange
mechanism that is common before and after these drafts are publishe= d.
Otherwise, we probably need to bump to SSHv3 if we are going to getrid of all of the MUST NOT algorithms.

Are there any additional th= oughts for this draft?

Is it desirable to list out all of the Key Ex= change Method names in the
https://www.ietf.org/assignments/ssh-paramete= rs/ssh-parameters.xml table
and their new state?


Key Exchange= Method Names

Method Name       &= nbsp;           &nbs= p;       Reference     No= te
diffie-hellman-group-exchange-sha1    RFC4419 &nb= sp;     MUST NOT
diffie-hellman-group-exchange-sha25= 6  RFC4419       MAY
diffie-hellman-g= roup1-sha1           = ; RFC4253       MUST NOT
diffie-hellman-gr= oup14-sha1           RFC4= 253       MAY
ecdh-sha2-nistp256 &nbs= p;            &= nbsp;     RFC5656       M= UST
ecdh-sha2-nistp384        &n= bsp;           RFC5656&nb= sp;      MUST
ecdh-sha2-nistp521  &nb= sp;            =      RFC5656       MUSTecdh-sha2-*          &n= bsp;            = ;    RFC5656       Other curve= s are possible?
ecmqv-sha2       &nbs= p;            &= nbsp;       RFC5656    &n= bsp;  MAY
gss-gex-sha1-*       &= nbsp;           &nbs= p;    RFC4462       MUST NOTgss-group1-sha1-*         &n= bsp;           RFC4462&nb= sp;      MUST NOT
gss-group14-sha1-*  = ;            &n= bsp;     RFC4462       MU= ST NOT
gss-*          =             &nb= sp;          RFC4462 &nbs= p;     MAY
rsa1024-sha1     = ;            &n= bsp;        RFC4432   &nb= sp;   MUST NOT
rsa2048-sha256     &nb= sp;            =       RFC4432       = MAY
diffie-hellman-group14-sha256      &nb= sp;  This Draft    MAY
diffie-hellman-group15-sha256=          This Draft  &nbs= p; MUST
diffie-hellman-group16-sha512      = ;   This Draft    SHOULD
diffie-hellman-group17= -sha512         This Draft &nb= sp;  MAY
diffie-hellman-group18-sha512     = ;    This Draft    MAY

Above I have mo= ved all of the *sha1* exchange methods to MUST NOT
with the exception of= diffie-hellman-group14-sha1. Should that one
also be moved to MUST NOT = too?

If we want to fix RFC4419 to pass q in addition to g,p so that = we are
able to use Lim/Lee primes for q and allow for run-time checking = of a g
being a generator of the q-ordered subgroup, does that need to be= rolled
into this draft too? What do we want to call this option for neg= otiation?

Additional comments solicited on these topics.

Than= ks,
-- Mark

= --=-OS4l+tW8wBeDI+FLqY3b-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 14 00:09:42 2016 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 963441B3A86 for ; Sun, 14 Feb 2016 00:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] 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 hn7m5759wPu4 for ; Sun, 14 Feb 2016 00:09:35 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 386831B3A7F for ; Sun, 14 Feb 2016 00:09:35 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0233E85EA8; Sun, 14 Feb 2016 08:09:35 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B1D0A85E1A; Sun, 14 Feb 2016 08:09:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A891D85E70 for ; Fri, 12 Feb 2016 11:52:48 +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 KRJoe3bCEL3Q for ; Fri, 12 Feb 2016 11:52:47 +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 C3A2384CFD for ; Fri, 12 Feb 2016 11:52:47 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for mdb@juniper.net; Fri, 12 Feb 2016 11:52:46 +0000 Date: Fri, 12 Feb 2016 11:52:46 +0000 Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <114857654-3608@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: "Mark D. Baushke" , Peter Gutmann Cc: ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-K6dV3/A7wbvdaFV/tfoE" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-K6dV3/A7wbvdaFV/tfoE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5IE1hcmsgLQ0KDQpJIGNhbid0IHNheSB3aGV0aGVyIHRoZSBkcmFmdCAic2hvdWxkIiBsaXN0 IGFsbCB0aGUga2V5IGV4Y2hhbmdlIG1ldGhvZCBuYW1lcy4gVGhpcyBtaWdodCBpbXBvc2UgcHJv Y2VkdXJhbCBjb21wbGljYXRpb25zIG9uIHRoZSBkcmFmdCdzIGFjY2VwdGFuY2UgdGhhdCBJJ20g bm90IGF3YXJlIG9mLiBIb3dldmVyLCBpZiB3ZSBhcmUgaW4gYSBwb3NpdGlvbiB0byB1cGRhdGUg dGhlIGZ1bGwgdGFibGUgb2Yga2V5IGV4Y2hhbmdlIG1ldGhvZHMsIGl0IHdvdWxkIHNlZW0gYSB1 c2VmdWwgc2VydmljZSB0byBkbyBzby4NCg0KSWYgd2UgYXJlIGluIHRoaXMgcG9zaXRpb24sIGl0 IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGJlbG93IHRhYmxlIGRvZXMgbW9zdGx5IGNhcHR1cmUgdGhl IGRlc2lyZWQgc3RhdGUuIENvbW1lbnRzOg0KDQotIElmICJkaWZmaWUtaGVsbG1hbi1ncm91cDE0 LXNoYTEiIGlzIE9QVElPTkFMOyB0aGVuIGl0IHNlZW1zIGluY29uc2lzdGVudCB0aGF0ICJnc3Mt Z3JvdXAxNC1zaGExLSoiIGlzIE5PVCBSRUNPTU1FTkRFRC4gQm90aCB1c2UgZ3JvdXAxNCB3aXRo IFNIQS0xLiBJIHdvdWxkIHNwZWNpZnkgZ3NzLWdyb3VwMTQtc2hhMS0qIGFzIE9QVElPTkFMLCBn aXZlbiB0aGF0IHRoZXJlJ3MgY3VycmVudGx5IG5vIHJlcGxhY2VtZW50Lg0KDQotIEdpdmVuIHJl Y2VudCBOU0EvTklTVCBndWlkZWxpbmVzLCAiZWNkaC1zaGEyLW5pc3RwMjU2IiBzaG91bGQgYmUg ZGVtb3RlZCBmcm9tIFJFUVVJUkVEIHRvIGVpdGhlciBPUFRJT05BTCwgb3IgUkVDT01NRU5ERUQu DQoNCi0gR2l2ZW4gdGhlc2Ugc2FtZSBndWlkZWxpbmVzLCBJJ2QgcHJlZmVyIHRvIHVzZSBTSEEt NTEyIHdpdGggZ3JvdXAxNS4NCg0KV2l0aCByZWdhcmQgdG8gcnNhMTAyNC1zaGExIGFuZCByc2Ey MDQ4LXNoYTI1NiBrZXkgZXhjaGFuZ2UgbWV0aG9kcyAoIFJGQyA0NDMyKSAtIGFjY29yZGluZyB0 byB0aGlzIGNvbXBhcmlzb24sIHRoZXNlIGFyZSBpbXBsZW1lbnRlZCBieSBhdCBsZWFzdCBQdVRU WSBhbmQgdlNTSDoNCg0KaHR0cDovL3NzaC1jb21wYXJpc29uLnF1ZW5kaS5kZS9jb21wYXJpc29u Lmh0bWwNCg0KV2l0aCByZWdhcmQgdG8gZ3NzLSogbWV0aG9kcyBmcm9tIFJGQyA0NDMyIC0gb3Vy IHNvZnR3YXJlIGltcGxlbWVudHMgdGhpcywgYm90aCBjbGllbnQgc2lkZSBhbmQgc2VydmVyIHNp ZGUuIEFjY29yZGluZyB0byB0aGUgYWJvdmUgY29tcGFyaXNvbiwgUGFyYW1pa28gYW5kIFNlY3Vy ZUNSVCBhbHNvIGhhdmUgdGhpcy4NCg0KVGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBvdXIgU1NIIFNl cnZlciBlbmFibGVzIGdzcy1nZXgtc2hhMS0qIGFuZCBnc3MtZ3JvdXAxNC1zaGExLSogYnkgZGVm YXVsdC4gVGhlIFNTSCBDbGllbnQgZG9lcyBub3QsIGJ1dCB0aGV5IGNhbiBiZSBlbmFibGVkIGFj Y2Vzc2libHkgb24gdGhlIExvZ2luIHRhYiAoYnkgY2hlY2tpbmcgIlNTUEkvS2VyYmVyb3MgNSBr ZXkgZXhjaGFuZ2UiKS4NCg0KQXMgZmFyIGFzIGFjdHVhbCB1c2FnZSAtIHdlIGhhZCBhIHJlY2Vu dCByZXBvcnQgaW52b2x2aW5nIGdzcy1nZXgtc2hhMS0qIHdpdGggb3VyIGNsaWVudCBhbmQgYW5v dGhlciBzZXJ2ZXIsIHNvIGl0IGRvZXMgc2VlbSB0byBiZSB1c2VmdWwgb2NjYXNpb25hbGx5Lg0K DQpJIGFtIGluIGZhdm9yIG9mIGluY2x1ZGluZyBncm91cHMgMTUgYW5kIDE3OyBlc3BlY2lhbGx5 IGdyb3VwIDE1Lg0KDQpGb3IgZ3JvdXAxNC1zaGEyNTYsIEkgdGhpbmsgUkVRVUlSRUQgYW5kIFJF Q09NTUVOREVEIG1heSBiZSBwb29yIGNob2ljZXMgYmVjYXVzZSBvZiBpdHMgbG93LWlzaCBjcnlw dG9ncmFwaGljIHN0cmVuZ3RoLCBiYXNlZCBvbiBjdXJyZW50IHVuZGVyc3RhbmRpbmcuIEkgdGhp bmsgT1BUSU9OQUwgaXMgYSBnb29kIGNob2ljZSBoZXJlLg0KDQpJIGFncmVlIHdpdGggZ3JvdXAx NSBiZWluZyBlaXRoZXIgUkVDT01NRU5ERUQgb3IgUkVRVUlSRUQgLSBwcmVmZXJhYmx5IHdpdGgg U0hBLTUxMiAtIHNvIHRoYXQgd2UgbWlnaHQgaGF2ZSBhIHN0cm9uZywgd2lkZWx5IGltcGxlbWVu dGVkIGtleSBleGNoYW5nZSBtZXRob2QgdGhhdCBmaXRzIHRoZSBsYXRlc3QgTlNBL05JU1QgcmVj b21tZW5kYXRpb25zLCBhbmQgaXMgbm90IEVDLWJhc2VkIChqdXN0IGluIGNhc2UpLg0KDQpkZW5p cw0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IE1hcmsgRC4gQmF1c2hr ZQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAxMiwgMjAxNiAwMTo0OQ0KVG86IGRlbmlzIGJpZGVy DQpDYzogUGV0ZXIgR3V0bWFubiA7IGlldGYtc3NoQE5ldEJTRC5vcmcNClN1YmplY3Q6IFJlOiBk cmFmdC1iYXVzaGtlLXNzaC1kaC1ncm91cC1zaGEyLTAxICh3YXMgUmU6IERIIGdyb3VwIGV4Y2hh bmdlKQ0KDQpIaSBkZW5pcywNCg0KVHdvIHF1ZXN0aW9uczoNCg0KwqAgYSkgU2hvdWxkIHRoZSBk cmFmdCBsaXN0IGFsbCBvZiB0aGUgS2V5IEV4Y2hhbmdlIE1ldGhvZCBOYW1lcw0KwqDCoMKgwqAg aW4gdGhlIGh0dHBzOi8vd3d3LmlldGYub3JnL2Fzc2lnbm1lbnRzL3NzaC1wYXJhbWV0ZXJzL3Nz aC1wYXJhbWV0ZXJzLnhtbA0KwqDCoMKgwqAgdGFibGU/DQoNCsKgwqDCoMKgIElmIHNvLCBkb2Vz IHRoZSBmb2xsb3dpbmcgY2FwdHVyZSB0aGUgZGVzaXJlZCBzdGF0ZT8NCsKgDQpLZXkgRXhjaGFu Z2UgTWV0aG9kIE5hbWXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBSZWZlcmVuY2XCoMKgwqDC oCBOb3RlDQpkaWZmaWUtaGVsbG1hbi1ncm91cC1leGNoYW5nZS1zaGExwqDCoMKgIFJGQzQ0MTnC oMKgwqDCoMKgwqAgTk9UIFJFQ09NTUVOREVEDQpkaWZmaWUtaGVsbG1hbi1ncm91cC1leGNoYW5n ZS1zaGEyNTbCoCBSRkM0NDE5wqDCoMKgwqDCoMKgIE9QVElPTkFMDQpkaWZmaWUtaGVsbG1hbi1n cm91cDEtc2hhMcKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgUkZDNDI1M8KgwqDCoMKgwqDCoCBOT1Qg UkVDT01NRU5ERUQNCmRpZmZpZS1oZWxsbWFuLWdyb3VwMTQtc2hhMcKgwqDCoMKgwqDCoMKgwqDC oMKgIFJGQzQyNTPCoMKgwqDCoMKgwqAgT1BUSU9OQUwNCmVjZGgtc2hhMi1uaXN0cDI1NsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJGQzU2NTbCoMKgwqDCoMKgwqAgUkVR VUlSRUQNCmVjZGgtc2hhMi1uaXN0cDM4NMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIFJGQzU2NTbCoMKgwqDCoMKgwqAgUkVRVUlSRUQNCmVjZGgtc2hhMi1uaXN0cDUyMcKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJGQzU2NTbCoMKgwqDCoMKgwqAg UkVRVUlSRUQNCmVjZGgtc2hhMi0qwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBSRkM1NjU2wqDCoMKgwqDCoMKgIE9QVElPTkFMDQplY21xdi1zaGEy wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJG QzU2NTbCoMKgwqDCoMKgwqAgT1BUSU9OQUwNCmdzcy1nZXgtc2hhMS0qwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBSRkM0NDYywqDCoMKgwqDCoMKgIE5PVCBS RUNPTU1FTkRFRA0KZ3NzLWdyb3VwMS1zaGExLSrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIFJGQzQ0NjLCoMKgwqDCoMKgwqAgTk9UIFJFQ09NTUVOREVEDQpnc3MtZ3Jv dXAxNC1zaGExLSrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBSRkM0NDYy wqDCoMKgwqDCoMKgIE5PVCBSRUNPTU1FTkRFRA0KZ3NzLSrCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJGQzQ0NjLCoMKgwqDC oMKgwqAgT1BUSU9OQUwNCnJzYTEwMjQtc2hhMcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJGQzQ0MzLCoMKgwqDCoMKgwqAgTk9UIFJFQ09NTUVOREVE DQpyc2EyMDQ4LXNoYTI1NsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgUkZDNDQzMsKgwqDCoMKgwqDCoCBPUFRJT05BTA0KZGlmZmllLWhlbGxtYW4tZ3JvdXAx NC1zaGEyNTbCoMKgwqDCoMKgwqDCoMKgIFRoaXMgRHJhZnTCoMKgwqAgT1BUSU9OQUwNCmRpZmZp ZS1oZWxsbWFuLWdyb3VwMTUtc2hhMjU2wqDCoMKgwqDCoMKgwqDCoCBUaGlzIERyYWZ0wqDCoMKg IFJFUVVJUkVEDQpkaWZmaWUtaGVsbG1hbi1ncm91cDE2LXNoYTUxMsKgwqDCoMKgwqDCoMKgwqAg VGhpcyBEcmFmdMKgwqDCoCBSRUNPTU1FTkRFRA0KZGlmZmllLWhlbGxtYW4tZ3JvdXAxNy1zaGE1 MTLCoMKgwqDCoMKgwqDCoMKgIFRoaXMgRHJhZnTCoMKgwqAgT1BUSU9OQUwNCmRpZmZpZS1oZWxs bWFuLWdyb3VwMTgtc2hhNTEywqDCoMKgwqDCoMKgwqDCoCBUaGlzIERyYWZ0wqDCoMKgIE9QVElP TkFMDQoNCk5vdGU6IEkgZG8gbm90IGtub3cgb2YgYW55IHJzYTIwNDgtc2hhMjU2IGltcGxlbWVu dGF0aW9ucyBmcm9tIFJGQzQ0MzIsDQpJIHN1c3BlY3QgYXQgbGVhc3Qgc29tZW9uZSBpcyB1c2lu ZyBpdCBvciBpdCB3b3VsZCBub3QgYmUgaW4gUkZDNDQzMiwNCndobyBpcyB1c2luZyBpdD8gQSBz aW1pbGFyIHF1ZXN0aW9uIGZvciBnc3MtKiBhbmQgUkZDNDQ2MiBjb21lcyB0byBtaW5kDQphcyB3 ZWxsLg0KDQrCoCBiKSBJcyBpdCBkZXNpcmFibGUgdG8gc3BlY2lmeSBhbGwgb2YgZ3JvdXAgMTQs IDE1LCAxNiwgMTcsIGFuZCAxOCBhcw0KwqDCoMKgwqAgdG8gdGhlIGhhc2hpbmcgYWxnb3JpdGht IHRvIGJlIHVzZWQgTk9XPyBPciwgaXMgaXQgYmV0dGVyIHRvIGRyb3ANCsKgwqDCoMKgIDE1IGFu ZCAxNyBmb3Igbm93PyBJZiBzbywgaXMgaXQgZGVzaXJhYmxlIGZvciBncm91cDE0LXNoYTI1NiB0 byBiZQ0KwqDCoMKgwqAgUkVRVUlSRUQsIFJFQ09NTUVOREVELCBvciBPUFRJT05BTCA/DQoNCmRp ZmZpZS1oZWxsbWFuLWdyb3VwMTQtc2hhMjU2wqDCoMKgwqDCoMKgwqDCoCBUaGlzIERyYWZ0wqDC oMKgIFJFQ09NTUVOREVEDQpkaWZmaWUtaGVsbG1hbi1ncm91cDE2LXNoYTUxMsKgwqDCoMKgwqDC oMKgwqAgVGhpcyBEcmFmdMKgwqDCoCBSRUNPTU1FTkRFRA0KZGlmZmllLWhlbGxtYW4tZ3JvdXAx OC1zaGE1MTLCoMKgwqDCoMKgwqDCoMKgIFRoaXMgRHJhZnTCoMKgwqAgT1BUSU9OQUwNCg0KVGhh bmsgeW91IGZvciB5b3VyIGNvbnNpZGVyYXRpb24uDQoNCi0tIE1hcmsNCg0K --=-K6dV3/A7wbvdaFV/tfoE Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Mark -

I can't say whether the draft "s= hould" list all the key exchange method names. This might impose procedural= complications on the draft's acceptance that I'm not aware of. However, if= we are in a position to update the full table of key exchange methods, it = would seem a useful service to do so.

If we are in this position, it= seems to me that the below table does mostly capture the desired state. Co= mments:

- If "diffie-hellman-group14-sha1" is OPTIONAL; then it seem= s inconsistent that "gss-group14-sha1-*" is NOT RECOMMENDED. Both use group= 14 with SHA-1. I would specify gss-group14-sha1-* as OPTIONAL, given that t= here's currently no replacement.

- Given recent NSA/NIST guidelines,= "ecdh-sha2-nistp256" should be demoted from REQUIRED to either OPTIONAL, o= r RECOMMENDED.

- Given these same guidelines, I'd prefer to use SHA-= 512 with group15.

With regard to rsa1024-sha1 and rsa2048-sha256 key= exchange methods ( RFC 4432) - according to this comparison, these are imp= lemented by at least PuTTY and vSSH:

http://ssh-comparison.quendi.de= /comparison.html

With regard to gss-* methods from RFC 4432 - our so= ftware implements this, both client side and server side. According to the = above comparison, Paramiko and SecureCRT also have this.

The current= version of our SSH Server enables gss-gex-sha1-* and gss-group14-sha1-* by= default. The SSH Client does not, but they can be enabled accessibly on th= e Login tab (by checking "SSPI/Kerberos 5 key exchange").

As far as = actual usage - we had a recent report involving gss-gex-sha1-* with our cli= ent and another server, so it does seem to be useful occasionally.

I= am in favor of including groups 15 and 17; especially group 15.

For= group14-sha256, I think REQUIRED and RECOMMENDED may be poor choices becau= se of its low-ish cryptographic strength, based on current understanding. I= think OPTIONAL is a good choice here.

I agree with group15 being ei= ther RECOMMENDED or REQUIRED - preferably with SHA-512 - so that we might h= ave a strong, widely implemented key exchange method that fits the latest N= SA/NIST recommendations, and is not EC-based (just in case).

denis

----- Original Message -----
From: Mark D. Baushke
Sent: Fr= iday, February 12, 2016 01:49
To: denis bider
Cc: Peter Gutmann ; iet= f-ssh@NetBSD.org
Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re= : DH group exchange)

Hi denis,

Two questions:

  a= ) Should the draft list all of the Key Exchange Method Names
  = ;   in the https://www.ietf.org/assignments/ssh-parameters/ssh-pa= rameters.xml
     table?

   &n= bsp; If so, does the following capture the desired state?
 
Key = Exchange Method Name         &= nbsp;    Reference     Note
diffie-he= llman-group-exchange-sha1    RFC4419    =    NOT RECOMMENDED
diffie-hellman-group-exchange-sha256  = RFC4419       OPTIONAL
diffie-hellman-grou= p1-sha1            R= FC4253       NOT RECOMMENDED
diffie-hellma= n-group14-sha1           = RFC4253       OPTIONAL
ecdh-sha2-nistp256&= nbsp;           &nbs= p;       RFC5656     = ;  REQUIRED
ecdh-sha2-nistp384      &= nbsp;           &nbs= p; RFC5656       REQUIRED
ecdh-sha2-nistp5= 21            &= nbsp;       RFC5656    &n= bsp;  REQUIRED
ecdh-sha2-*       = ;            &n= bsp;       RFC5656    &nb= sp;  OPTIONAL
ecmqv-sha2       &= nbsp;           &nbs= p;        RFC5656    = ;   OPTIONAL
gss-gex-sha1-*      = ;            &n= bsp;     RFC4462       NO= T RECOMMENDED
gss-group1-sha1-*       = ;            &n= bsp; RFC4462       NOT RECOMMENDED
gss-gro= up14-sha1-*          &nbs= p;         RFC4462   = ;    NOT RECOMMENDED
gss-*     &= nbsp;           &nbs= p;            &= nbsp;  RFC4462       OPTIONAL
rsa1024= -sha1           &nbs= p;            &= nbsp; RFC4432       NOT RECOMMENDED
rsa204= 8-sha256           &= nbsp;            RFC= 4432       OPTIONAL
diffie-hellman-group14= -sha256         This Draft &nb= sp;  OPTIONAL
diffie-hellman-group15-sha256    =      This Draft    REQUIRED
diffie-he= llman-group16-sha512         This D= raft    RECOMMENDED
diffie-hellman-group17-sha512 &n= bsp;       This Draft    OPTIO= NAL
diffie-hellman-group18-sha512      &nb= sp;  This Draft    OPTIONAL

Note: I do not know = of any rsa2048-sha256 implementations from RFC4432,
I suspect at least s= omeone is using it or it would not be in RFC4432,
who is using it? A sim= ilar question for gss-* and RFC4462 comes to mind
as well.

 = b) Is it desirable to specify all of group 14, 15, 16, 17, and 18 as
&n= bsp;    to the hashing algorithm to be used NOW? Or, is it b= etter to drop
     15 and 17 for now? If so, is it d= esirable for group14-sha256 to be
     REQUIRED, REC= OMMENDED, or OPTIONAL ?

diffie-hellman-group14-sha256  &nb= sp;      This Draft    RECOMMENDED<= br>diffie-hellman-group16-sha512       &= nbsp; This Draft    RECOMMENDED
diffie-hellman-group18-sh= a512         This Draft  =   OPTIONAL

Thank you for your consideration.

-- Mark
=
= --=-K6dV3/A7wbvdaFV/tfoE-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 14 00:09:58 2016 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 377D01B3A84 for ; Sun, 14 Feb 2016 00:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 XAcm6vSHDWWZ for ; Sun, 14 Feb 2016 00:09:56 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 9ABE11B3A7F for ; Sun, 14 Feb 2016 00:09:45 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3DD4085EB4; Sun, 14 Feb 2016 08:09:45 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id EF80A85E1A; Sun, 14 Feb 2016 08:09:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 99FE085F24 for ; Fri, 12 Feb 2016 16:11:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id IMHOOBpJJSwd for ; Fri, 12 Feb 2016 16:11: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 2044584CF0 for ; Fri, 12 Feb 2016 16:11:46 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Fri, 12 Feb 2016 16:11:44 +0000 Date: Fri, 12 Feb 2016 16:11:44 +0000 Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <130305716-2760@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann , "Mark D. Baushke" Cc: ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-5Q2tKXOtnavHJ0uGbVYE" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-5Q2tKXOtnavHJ0uGbVYE Content-Type: text/plain; charset="utf-8" Because we have customers opposite of what you describe. Some of ours are large institutions that come to us with a list of algorithms they deem acceptable, and it's stricter than what we implement. Some are government organizations that have to follow what NIST says. If NSA announces yesterday that the minimum secure is now SHA-384, it's not unlikely that within a few years, we'll have people coming to us, asking how to disable lesser algorithms. With regard to NOT RECOMMENDED, that sounds to me equally as heavy as SHOULD NOT. I can't fathom that people would read "NOT RECOMMENDED", and interpret as if it said "sure, what the heck". It seems to me a stern disrecommendation. That being said, SHOULD NOT is also in RFC 2119, and is a synonym. If you think "SHOULD NOT be used" would work better, I'm not opposed. ----- Original Message ----- From: Peter Gutmann Sent: Friday, February 12, 2016 07:52 To: denis bider ; Mark D. Baushke Cc: ietf-ssh@NetBSD.org Subject: RE: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) denis bider writes: >If we settle on SHA-256, we run the risk of having to introduce SHA-512 >versions a year or two later. Why would we need to do that? Peter. --=-5Q2tKXOtnavHJ0uGbVYE Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Because we have customers opposite of what you des= cribe. Some of ours are large institutions that come to us with a list of a= lgorithms they deem acceptable, and it's stricter than what we implement. S= ome are government organizations that have to follow what NIST says. If NSA= announces yesterday that the minimum secure is now SHA-384, it's not unlik= ely that within a few years, we'll have people coming to us, asking how to = disable lesser algorithms.

With regard to NOT RECOMMENDED, that soun= ds to me equally as heavy as SHOULD NOT. I can't fathom that people would r= ead "NOT RECOMMENDED", and interpret as if it said "sure, what the heck". I= t seems to me a stern disrecommendation.

That being said, SHOULD NOT= is also in RFC 2119, and is a synonym. If you think "SHOULD NOT be used" w= ould work better, I'm not opposed.


----- Original Message -----<= br>From: Peter Gutmann
Sent: Friday, February 12, 2016 07:52
To: deni= s bider ; Mark D. Baushke
Cc: ietf-ssh@NetBSD.org
Subject: RE: draft-= baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

denis bider= <ietf-ssh3@denisbider.com> writes:

>If we settle on SHA-25= 6, we run the risk of having to introduce SHA-512
>versions a year or= two later.

Why would we need to do that?

Peter.

= --=-5Q2tKXOtnavHJ0uGbVYE-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 14 00:10:02 2016 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 43C151B3A7F for ; Sun, 14 Feb 2016 00:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] 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 jeMFUeL85Ooj for ; Sun, 14 Feb 2016 00:09:57 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 158641B3A8C for ; Sun, 14 Feb 2016 00:09:55 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D687085EB5; Sun, 14 Feb 2016 08:09:54 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9110C85E1A; Sun, 14 Feb 2016 08:09:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2B07C85E1A for ; Sat, 13 Feb 2016 17:49: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 Pj6YOr_RIHHW for ; Sat, 13 Feb 2016 17:49:11 +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 7552084CF5 for ; Sat, 13 Feb 2016 17:49:11 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for mdb@juniper.net; Sat, 13 Feb 2016 17:49:04 +0000 Date: Sat, 13 Feb 2016 17:49:04 +0000 Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <219217362-2196@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: "Mark D. Baushke" Cc: Peter Gutmann , =?UTF-8?q?Niels_M=C3=B6ller?= , Simon Josefsson , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-fi+9+xlVPEyZTKk620KH" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-fi+9+xlVPEyZTKk620KH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Comments: - If we're being comprehensive, we should include a position with regard to= Curve25519 and Curve448: https://tools.ietf.org/html/draft-josefsson-ssh-curves-03 I suggest we take the following positions: curve25519-sha256=C2=A0=C2=A0=C2=A0 SHOULD curve448-sha256=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD, or MAY? That being said: - Given the recent NSA recommendations, it seems to me it would be prudent = to update the Curve25519/Curve448 draft, and to replace the SHA-256 algorit= hm with SHA-512 for Curve448. This would create the method "curve448-sha512= " instead of "curve448-sha256". Simon, what do you think? Could your draft be updated to do that? It seems to me that this would meet the NSA's long-term guidelines, whereas= curve448-sha256 doesn't. - As Niels points out - now that the modifiers are SHOULD / MAY / ..., we o= ught to specify the verb this refers to. I would be more comfortable assumi= ng that our target audience are developers, and that these modifiers refer = to "implement". I'm less comfortable reaching out to end users, dispensing = advice about deployed configurations - but I'm not firmly against it. - If we're going to have text saying SHA-1 is begrudgingly acceptable for b= ackwards compatibility, we can't simultaneously say that it is "NOT SECURE"= in all caps. Conversely - if we do say it is "NOT SECURE", we can't have a= graceful transition away from SHA-1. We must in that case pursue an aggres= sive transition, including condemnation of existing products that use it. It seems to me we don't have reason enough to be that aggressive. If someon= e asks why SHA-1 is not currently secure for key exchange, we can't point t= o a document saying "here's how to break diffie-hellman-group14-sha1". What= we have is concerns that such attacks might exist in the future, given wea= knesses known today. Bottom line - I think the following is fine: "The SHA-1 [algorithm] SHOULD NOT be used. If it is used, it should only be= provided for backwards compatibility[,] should not be used in new designs[= ,] and should be phased out of existing key exchanges as quickly as possibl= e" But it's not currently accurate to say: "... because it is NOT SECURE." It may instead be accurate to say: "... because of its known weaknesses." - Niels has suggested that it's onerous to have so many "MUST" curves. We'v= e already reduced the number of MUST curves from three (in RFC 5656) to two= (in this draft). I'm not sure that either nistp384 or nistp521 are suitabl= e candidates for demotion. However, if we make changes here, it seems we sh= ould keep nistp384 as MUST, and demote nistp521 to SHOULD. This is due to t= hat nistp384 meets current longest-term guidelines; whereas nistp521 seems = to be overkill, and slower. =C2=A0 ----- Original Message ----- From: Mark D. Baushke Sent: Friday, February 12, 2016 11:48 To: denis bider Cc: Peter Gutmann ; ietf-ssh@NetBSD.org Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Hi denis, You have made some good points. I have updated my draft to -02 and it is in the process of being uploaded to the ietf servers. For now, you can see the latest edition here: =C2=A0 https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/ I think I have the normative vs informative references in their proper locations, please let me know of any nits that still need to be addressed. -- Mark = --=-fi+9+xlVPEyZTKk620KH Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Comments:


- If we're being comprehensiv= e, we should include a position with regard to Curve25519 and Curve448:
=
https://tools.ietf.org/html/draft-josefsson-ssh-curves-03

I sugg= est we take the following positions:

curve25519-sha256  &n= bsp; SHOULD
curve448-sha256      SHOULD, or MAY= ?

That being said:


- Given the recent NSA recommendations= , it seems to me it would be prudent to update the Curve25519/Curve448 draf= t, and to replace the SHA-256 algorithm with SHA-512 for Curve448. This wou= ld create the method "curve448-sha512" instead of "curve448-sha256".
Simon, what do you think? Could your draft be updated to do that?

I= t seems to me that this would meet the NSA's long-term guidelines, whereas = curve448-sha256 doesn't.


- As Niels points out - now that the mo= difiers are SHOULD / MAY / ..., we ought to specify the verb this refers to= . I would be more comfortable assuming that our target audience are develop= ers, and that these modifiers refer to "implement". I'm less comfortable re= aching out to end users, dispensing advice about deployed configurations - = but I'm not firmly against it.


- If we're going to have text say= ing SHA-1 is begrudgingly acceptable for backwards compatibility, we can't = simultaneously say that it is "NOT SECURE" in all caps. Conversely - if we = do say it is "NOT SECURE", we can't have a graceful transition away from SH= A-1. We must in that case pursue an aggressive transition, including condem= nation of existing products that use it.

It seems to me we don't hav= e reason enough to be that aggressive. If someone asks why SHA-1 is not cur= rently secure for key exchange, we can't point to a document saying "here's= how to break diffie-hellman-group14-sha1". What we have is concerns that s= uch attacks might exist in the future, given weaknesses known today.
Bottom line - I think the following is fine:

"The SHA-1 [algorithm]= SHOULD NOT be used. If it is used, it should only be provided for backward= s compatibility[,] should not be used in new designs[,] and should be phase= d out of existing key exchanges as quickly as possible"

But it's not= currently accurate to say:

"... because it is NOT SECURE."

I= t may instead be accurate to say:

"... because of its known weakness= es."


- Niels has suggested that it's onerous to have so many "MU= ST" curves. We've already reduced the number of MUST curves from three (in = RFC 5656) to two (in this draft). I'm not sure that either nistp384 or nist= p521 are suitable candidates for demotion. However, if we make changes here= , it seems we should keep nistp384 as MUST, and demote nistp521 to SHOULD. = This is due to that nistp384 meets current longest-term guidelines; whereas= nistp521 seems to be overkill, and slower.

 

----- Orig= inal Message -----
From: Mark D. Baushke
Sent: Friday, February 12, 2= 016 11:48
To: denis bider
Cc: Peter Gutmann ; ietf-ssh@NetBSD.org
= Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)=

Hi denis,

You have made some good points. I have updated my = draft to -02 and it is
in the process of being uploaded to the ietf serv= ers.

For now, you can see the latest edition here:

  htt= ps://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/

I thi= nk I have the normative vs informative references in their proper
locati= ons, please let me know of any nits that still need to be
addressed.
=
-- Mark

= --=-fi+9+xlVPEyZTKk620KH-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 14 00:21:14 2016 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 1A3DF1B3A57 for ; Sun, 14 Feb 2016 00:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.007 X-Spam-Level: X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 4MGa85D8couG for ; Sun, 14 Feb 2016 00:21:11 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 2B3F51B3A9E for ; Sun, 14 Feb 2016 00:21:11 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 02E8C85EC5; Sun, 14 Feb 2016 08:21:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2208185E1A for ; Sun, 14 Feb 2016 08:21: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=auckland.ac.nz Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id Z_J2knEjPj4b for ; Sun, 14 Feb 2016 08:21:07 +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 147D384CFB for ; Sun, 14 Feb 2016 08:21:03 +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=1455438067; x=1486974067; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+oPziw4fmpLZbgENa5vfDJJaPONYwNWNqEIcWU+QotI=; b=NKQ9mkuKZ7UhslbR1dNJGeZDB+uJpN95AAF2UOMjJb93/p0OSkrfBmI3 UUvnYO847RLIvl+kFh6XcuLXeltwHYPr3ayu+D8qYlt9innDMAHpchZbk cTq66RF7bgkThlm0qJYPHX06cvhJpNND8EpRy/LEu5gsMMbSgu7rk8svW o1GwoBSTr5qNEc90vrvd1On/z11SqznkuLEiL4oyA2COZPE2Wx/d/ljuw XDzCrRjQzeuiLIDZ3LSWU3+RRKSzVi1DemRqsaDGhpUF8arbreSu6I2Kf inr9ApzVgpG+LvrywBVgdJgDko1XutKCg1jBkuRUkTGUG1uK8m1t3bcnL Q==; X-IronPort-AV: E=Sophos;i="5.22,444,1449486000"; d="scan'208";a="67804334" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Feb 2016 21:21:01 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Sun, 14 Feb 2016 21:21:01 +1300 From: Peter Gutmann To: denis bider , "Mark D. Baushke" CC: "ietf-ssh@NetBSD.org" Subject: RE: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Thread-Topic: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Thread-Index: AQHRZbAQMdJDQld0Qaiw70eVAW98z58rNXuu Date: Sun, 14 Feb 2016 08:21:01 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BF131D@uxcn10-5.UoA.auckland.ac.nz> References: <130305716-2760@skroderider.denisbider.com> In-Reply-To: <130305716-2760@skroderider.denisbider.com> 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 denis bider writes:=0A= =0A= >With regard to NOT RECOMMENDED, that sounds to me equally as heavy as SHOU= LD=0A= >NOT. I can't fathom that people would read "NOT RECOMMENDED", and interpre= t=0A= >as if it said "sure, what the heck". It seems to me a stern disrecommendat= ion.=0A= =0A= These are people looking for any reason they can to not do anything (they'r= e=0A= still AFAIK using MD5 and DES in places because the spec doesn't say you=0A= can't). The stronger the wording, the easier it will be to persuade them t= hat=0A= they need to do something.=0A= =0A= >That being said, SHOULD NOT is also in RFC 2119, and is a synonym. If you= =0A= >think "SHOULD NOT be used" would work better, I'm not opposed.=0A= =0A= I think it would help.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 14 00:23:04 2016 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 6210C1B3AA4 for ; Sun, 14 Feb 2016 00:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 X2lqIvz6E0Gn for ; Sun, 14 Feb 2016 00:23:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 114011B3AA5 for ; Sun, 14 Feb 2016 00:23:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B28E485EB7; Sun, 14 Feb 2016 08:10:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 6BCAC85E1A; Sun, 14 Feb 2016 08:10:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6629C85E1A for ; Sat, 13 Feb 2016 17:59:30 +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 mHqpDP8ebGsf for ; Sat, 13 Feb 2016 17:59:29 +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 9A65084CF5 for ; Sat, 13 Feb 2016 17:59:29 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh3@denisbider.com; Sat, 13 Feb 2016 17:59:24 +0000 Date: Sat, 13 Feb 2016 17:59:24 +0000 Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <223360780-3264@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <219217362-2196@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: denis bider , "Mark D. Baushke" Cc: Peter Gutmann , =?UTF-8?q?Niels_M=C3=B6ller?= , Simon Josefsson , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-yMpIY/yhVRjZptkCFmku" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-yMpIY/yhVRjZptkCFmku Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On further consideration, it seems to me that: - to be consistent, "curve25519-sha256" should actually be in status MAY - "curve448-sha512" is the strongest key exchange method we can offer right= now, and is probably preferable to nistp384. I would make this one a "MUST= " if it wasn't for (1) the long-term problem of FIPS certification, and (2)= the short-term problem of no one implementing it right now. Therefore, I suggest the following: curve25519-sha256=C2=A0=C2=A0=C2=A0 MAY curve448-sha512=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD Assuming Simon agrees to alter his spec, and specify curve448-sha512. denis bider , 2/13/2016 4:44 PM: Comments: - If we're being comprehensive, we should include a position with regard to= Curve25519 and Curve448: https://tools.ietf.org/html/draft-josefsson-ssh-curves-03 I suggest we take the following positions: curve25519-sha256=C2=A0=C2=A0=C2=A0 SHOULD curve448-sha256=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD, or MAY? That being said: - Given the recent NSA recommendations, it seems to me it would be prudent = to update the Curve25519/Curve448 draft, and to replace the SHA-256 algorit= hm with SHA-512 for Curve448. This would create the method "curve448-sha512= " instead of "curve448-sha256". Simon, what do you think? Could your draft be updated to do that? It seems to me that this would meet the NSA's long-term guidelines, whereas= curve448-sha256 doesn't. - As Niels points out - now that the modifiers are SHOULD / MAY / ..., we o= ught to specify the verb this refers to. I would be more comfortable assumi= ng that our target audience are developers, and that these modifiers refer = to "implement". I'm less comfortable reaching out to end users, dispensing = advice about deployed configurations - but I'm not firmly against it. - If we're going to have text saying SHA-1 is begrudgingly acceptable for b= ackwards compatibility, we can't simultaneously say that it is "NOT SECURE"= in all caps. Conversely - if we do say it is "NOT SECURE", we can't have a= graceful transition away from SHA-1. We must in that case pursue an aggres= sive transition, including condemnation of existing products that use it. It seems to me we don't have reason enough to be that aggressive. If someon= e asks why SHA-1 is not currently secure for key exchange, we can't point t= o a document saying "here's how to break diffie-hellman-group14-sha1". What= we have is concerns that such attacks might exist in the future, given wea= knesses known today. Bottom line - I think the following is fine: "The SHA-1 [algorithm] SHOULD NOT be used. If it is used, it should only be= provided for backwards compatibility[,] should not be used in new designs[= ,] and should be phased out of existing key exchanges as quickly as possibl= e" But it's not currently accurate to say: "... because it is NOT SECURE." It may instead be accurate to say: "... because of its known weaknesses." - Niels has suggested that it's onerous to have so many "MUST" curves. We'v= e already reduced the number of MUST curves from three (in RFC 5656) to two= (in this draft). I'm not sure that either nistp384 or nistp521 are suitabl= e candidates for demotion. However, if we make changes here, it seems we sh= ould keep nistp384 as MUST, and demote nistp521 to SHOULD. This is due to t= hat nistp384 meets current longest-term guidelines; whereas nistp521 seems = to be overkill, and slower. =C2=A0 ----- Original Message ----- From: Mark D. Baushke Sent: Friday, February 12, 2016 11:48 To: denis bider Cc: Peter Gutmann ; ietf-ssh@NetBSD.org Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Hi denis, You have made some good points. I have updated my draft to -02 and it is in the process of being uploaded to the ietf servers. For now, you can see the latest edition here: =C2=A0 https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/ I think I have the normative vs informative references in their proper locations, please let me know of any nits that still need to be addressed. -- Mark = --=-yMpIY/yhVRjZptkCFmku Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable On further consideration, it seems to me that:
=
- to be consistent, "curve25519-sha256" should actually be in status MA= Y

- "curve448-sha512" is the strongest key exchange method we can of= fer right now, and is probably preferable to nistp384. I would make this on= e a "MUST" if it wasn't for (1) the long-term problem of FIPS certification= , and (2) the short-term problem of no one implementing it right now.
Therefore, I suggest the following:

curve25519-sha256  &= nbsp; MAY
curve448-sha512      SHOULD

As= suming Simon agrees to alter his spec, and specify curve448-sha512.

=
denis bider <ietf-ssh3@denisbider.com= > , 2/13/2016 4:44 PM:
Co= mments:


- If we're being comprehensive, we should include a posi= tion with regard to Curve25519 and Curve448:

https://tools.iet= f.org/html/draft-josefsson-ssh-curves-03

I suggest we take the f= ollowing positions:

curve25519-sha256    SHOULD
cu= rve448-sha256      SHOULD, or MAY?

That bei= ng said:


- Given the recent NSA recommendations, it seems to me = it would be prudent to update the Curve25519/Curve448 draft, and to replace= the SHA-256 algorithm with SHA-512 for Curve448. This would create the met= hod "curve448-sha512" instead of "curve448-sha256".

Simon, what do y= ou think? Could your draft be updated to do that?

It seems to me tha= t this would meet the NSA's long-term guidelines, whereas curve448-sha256 d= oesn't.


- As Niels points out - now that the modifiers are SHOUL= D / MAY / ..., we ought to specify the verb this refers to. I would be more= comfortable assuming that our target audience are developers, and that the= se modifiers refer to "implement". I'm less comfortable reaching out to end= users, dispensing advice about deployed configurations - but I'm not firml= y against it.


- If we're going to have text saying SHA-1 is begr= udgingly acceptable for backwards compatibility, we can't simultaneously sa= y that it is "NOT SECURE" in all caps. Conversely - if we do say it is "NOT= SECURE", we can't have a graceful transition away from SHA-1. We must in t= hat case pursue an aggressive transition, including condemnation of existin= g products that use it.

It seems to me we don't have reason enough t= o be that aggressive. If someone asks why SHA-1 is not currently secure for= key exchange, we can't point to a document saying "here's how to break dif= fie-hellman-group14-sha1". What we have is concerns that such attacks might= exist in the future, given weaknesses known today.

Bottom line - I = think the following is fine:

"The SHA-1 [algorithm] SHOULD NOT be us= ed. If it is used, it should only be provided for backwards compatibility[,= ] should not be used in new designs[,] and should be phased out of existing= key exchanges as quickly as possible"

But it's not currently accura= te to say:

"... because it is NOT SECURE."

It may instead be = accurate to say:

"... because of its known weaknesses."


-= Niels has suggested that it's onerous to have so many "MUST" curves. We've= already reduced the number of MUST curves from three (in RFC 5656) to two = (in this draft). I'm not sure that either nistp384 or nistp521 are suitable= candidates for demotion. However, if we make changes here, it seems we sho= uld keep nistp384 as MUST, and demote nistp521 to SHOULD. This is due to th= at nistp384 meets current longest-term guidelines; whereas nistp521 seems t= o be overkill, and slower.

 

----- Original Message ----= -
From: Mark D. Baushke
Sent: Friday, February 12, 2016 11:48
To: = denis bider
Cc: Peter Gutmann ; ietf-ssh@NetBSD.org
Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exch= ange)

Hi denis,

You have made some good points. I have update= d my draft to -02 and it is
in the process of being uploaded to the ietf= servers.

For now, you can see the latest edition here:

 = ; https://datatracker.ietf.org/doc/draft-baushke-ssh-= dh-group-sha2/

I think I have the normative vs informative refer= ences in their proper
locations, please let me know of any nits that sti= ll need to be
addressed.

-- Mark

= = --=-yMpIY/yhVRjZptkCFmku-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 14 00:36:09 2016 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 07F101B3ACA for ; Sun, 14 Feb 2016 00:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 o4nAVti5c5L9 for ; Sun, 14 Feb 2016 00:36:07 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 B1A1D1B2E43 for ; Sun, 14 Feb 2016 00:36:07 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 943CC85EC3; Sun, 14 Feb 2016 08:36:06 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CEC8B85E1A for ; Sun, 14 Feb 2016 08:36:03 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 5bFcQ1xoLVeF for ; Sun, 14 Feb 2016 08:36:03 +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 CC42084CFB for ; Sun, 14 Feb 2016 08:36:02 +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=1455438963; x=1486974963; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h5th8CRzVIvYgxjnMGmCfkRYjOno8QreAWROw38kBqw=; b=3vEIFvpkTwNVkWKrJo60Eq8oTqhi0lRVA4ZOG50DlaEpBBMGDZA1FqLy BNLV9B9iQc7KFxNXw0DoBKzTpkoCF4mJxEP6wPokZ317oUNHI4GJLSiYv MQ3fDfV+Tf3mGNbhx7S5+92WAhF7CUUtV0BlmXlctg2PwfD8RygiVAqso zRo45UIV4Ea/c9bWR+um7Ro1tFOgPJYp+1usS0R+8c84W8KHeiF2E+0JJ YQXtA5U+fYfgOd0JVmSQ5lTeOzQjWTrGoZVNbhO6BzLtsP8csOnJOTYXI 9ErsBZOIEfn90LPKG/ZSH9e9eFEXM2aHtIlUZntZdPbFbPhErIPhTVZvR Q==; X-IronPort-AV: E=Sophos;i="5.22,444,1449486000"; d="scan'208";a="67804946" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe4.UoA.auckland.ac.nz) ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Feb 2016 21:36:01 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Sun, 14 Feb 2016 21:36:00 +1300 From: Peter Gutmann To: denis bider , "Mark D. Baushke" CC: =?iso-8859-1?Q?Niels_M=F6ller?= , Simon Josefsson , "ietf-ssh@netbsd.org" Subject: RE: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Thread-Topic: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) Thread-Index: AQHRZobUMdJDQld0Qaiw70eVAW98z58rOBFi Date: Sun, 14 Feb 2016 08:36:00 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BF1342@uxcn10-5.UoA.auckland.ac.nz> References: <219217362-2196@skroderider.denisbider.com> In-Reply-To: <219217362-2196@skroderider.denisbider.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >It seems to me we don't have reason enough to be that aggressive. If someo= ne=0A= >asks why SHA-1 is not currently secure for key exchange, we can't point to= a=0A= >document saying "here's how to break diffie-hellman-group14-sha1". =0A= =0A= We can however point to mass-market, mainstream products, and mainstream=0A= industry groups (e.g. the CAB Forum), that have banned SHA-1 outright:=0A= =0A= Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certifica= tes=0A= or Subordinate CA certificates using the SHA-1 hash algorithm.=0A= =0A= Go to a site using SHA-1 right now with Chrome or Firefox and you'll get an= =0A= indicator that the connection is untrusted, i.e. it'll be treated worse tha= n=0A= if it wasn't encrypted at all (which is pretty stoopid, but that's a differ= ent=0A= issue). MSIE will also start doing this in a couple of months, if they don= 't=0A= move the date up yet again.=0A= =0A= For crypto as most people experience it, use of SHA-1 will be flagged as=0A= insecure, or (for CA use) banned outright. So we have a pretty good preced= ent=0A= for warning about SHA-1:=0A= =0A= In line with widespread industry practice that deprecates SHA-1 as insecu= re=0A= from January 2016, the SHA-1 [algorithm] SHOULD NOT be used. If it is use= d,=0A= it should only be provided for backwards compatibility[,] should not be u= sed=0A= in new designs[,] and should be phased out of existing key exchanges as= =0A= quickly as possible. Since SHA-1 is being actively phased out, anyone=0A= continuing to use it should expect increasing problems in its use, for=0A= example public CAs will no longer issue certificates using SHA-1.=0A= =0A= I think that's a fair warning to people of what's in store for SHA-1, so no= -=0A= one can say they weren't warned.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 14 23:51:18 2016 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 234C41A88C5 for ; Sun, 14 Feb 2016 23:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.007 X-Spam-Level: X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 V8qRGtvr4pDv for ; Sun, 14 Feb 2016 23:51:16 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 8B55C1A87AA for ; Sun, 14 Feb 2016 23:51:16 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id ECE3385EE8; Mon, 15 Feb 2016 07:51:14 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 97A3C85EE4 for ; Mon, 15 Feb 2016 07:51: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 0IJ4odWI5pMM for ; Mon, 15 Feb 2016 07:51:12 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 7BB8984C6C for ; Mon, 15 Feb 2016 07:51:08 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u1F7osMJ023729; Mon, 15 Feb 2016 17:50:54 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u1F7os1i057097 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Feb 2016 17:50:54 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id u1F7ortj002233; Mon, 15 Feb 2016 17:50:53 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 690ECA4F34; Mon, 15 Feb 2016 18:50:53 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 6401CA4F33; Mon, 15 Feb 2016 18:50:53 +1100 (AEDT) Date: Mon, 15 Feb 2016 18:50:53 +1100 (AEDT) From: Damien Miller To: "Mark D. Baushke" cc: denis bider , Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) In-Reply-To: <24239.1455263382@eng-mail01.juniper.net> Message-ID: References: <99035674-2196@skroderider.denisbider.com> <24239.1455263382@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1455522655 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, 11 Feb 2016, Mark D. Baushke wrote: > Hi denis, > > Two questions: > > a) Should the draft list all of the Key Exchange Method Names > in the https://www.ietf.org/assignments/ssh-parameters/ssh-parameters.xml > table? > > If so, does the following capture the desired state? > > Key Exchange Method Name Reference Note > diffie-hellman-group-exchange-sha1 RFC4419 NOT RECOMMENDED > diffie-hellman-group-exchange-sha256 RFC4419 OPTIONAL > diffie-hellman-group1-sha1 RFC4253 NOT RECOMMENDED > diffie-hellman-group14-sha1 RFC4253 OPTIONAL > ecdh-sha2-nistp256 RFC5656 REQUIRED > ecdh-sha2-nistp384 RFC5656 REQUIRED > ecdh-sha2-nistp521 RFC5656 REQUIRED > ecdh-sha2-* RFC5656 OPTIONAL > ecmqv-sha2 RFC5656 OPTIONAL > gss-gex-sha1-* RFC4462 NOT RECOMMENDED > gss-group1-sha1-* RFC4462 NOT RECOMMENDED > gss-group14-sha1-* RFC4462 NOT RECOMMENDED > gss-* RFC4462 OPTIONAL > rsa1024-sha1 RFC4432 NOT RECOMMENDED > rsa2048-sha256 RFC4432 OPTIONAL > diffie-hellman-group14-sha256 This Draft OPTIONAL > diffie-hellman-group15-sha256 This Draft REQUIRED > diffie-hellman-group16-sha512 This Draft RECOMMENDED > diffie-hellman-group17-sha512 This Draft OPTIONAL > diffie-hellman-group18-sha512 This Draft OPTIONAL list looks ok to me > b) Is it desirable to specify all of group 14, 15, 16, 17, and 18 as > to the hashing algorithm to be used NOW? Or, is it better to drop > 15 and 17 for now? If so, is it desirable for group14-sha256 to be > REQUIRED, RECOMMENDED, or OPTIONAL ? +1 to dropping the odd-numbered groups and onlist listing group14/16/18 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Feb 15 00:01:40 2016 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 6E4E01A8781 for ; Mon, 15 Feb 2016 00:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 XWCarntVkIom for ; Mon, 15 Feb 2016 00:01:39 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 EE09C1A6F51 for ; Mon, 15 Feb 2016 00:01:38 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E6BAB85EE9; Mon, 15 Feb 2016 08:01: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 F3A5185EE4 for ; Mon, 15 Feb 2016 08:01:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id DVUMIlLJf_x2 for ; Mon, 15 Feb 2016 08:01:35 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id 1AEAC84CBD for ; Mon, 15 Feb 2016 08:01:34 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u1F80w9V029600; Mon, 15 Feb 2016 18:00:58 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u1F80wxE059268 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Feb 2016 18:00:58 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id u1F80sLd017000; Mon, 15 Feb 2016 18:00:55 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id DA812A4F35; Mon, 15 Feb 2016 19:00:54 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id D9CC9A4F34; Mon, 15 Feb 2016 19:00:54 +1100 (AEDT) Date: Mon, 15 Feb 2016 19:00:54 +1100 (AEDT) From: Damien Miller To: "Mark D. Baushke" cc: denis bider , =?ISO-8859-15?Q?Niels_M=F6ller?= , Peter Gutmann , Simon Josefsson , ietf-ssh@netbsd.org Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) In-Reply-To: <86136.1455402404@eng-mail01.juniper.net> Message-ID: References: <223360780-3264@skroderider.denisbider.com> <86136.1455402404@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1455523260 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sat, 13 Feb 2016, Mark D. Baushke wrote: > Hi denis & Niels, > > You have both made good points. I have adopted the updated text from > denis and tried provide a meaning for the Note column. I have also added > a pointer to the Simon's ssh-curves draft and included both of the > currently published curve names in the table in this draft. > > https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/ > > Please let me know of additional comments. IMO curve25519-sha256 should be a MUST, if not immediately then soon. It's already supported under the curve25519-sha256@libssh.org alias by a few implementations. This paragraph: > The group15, group16, group17, and group18 names are the same as > those specified in [RFC3526] as 3072-bit MODP Group 14, 4096-bit MODP > Group 15, 6144-bit MODP Group 17, and 8192-bit MODP Group 18. is incorrect: group 14 is 2048 bits, not 3072. Group 15 is 3072 bits, not 4096. Group 16's length is not described (4096 bits). 17 and 18 are correct. I think the table of "Group modulus security strength estimates" should have a reference - are these from NIST SP800-57? -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Feb 15 01:11:16 2016 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 DB5921A891A for ; Mon, 15 Feb 2016 01:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 RIW48llhfgLe for ; Mon, 15 Feb 2016 01:11:15 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 899B01A6F38 for ; Mon, 15 Feb 2016 01:11:15 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 48E5285EF2; Mon, 15 Feb 2016 09:11:14 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 008DD85E70 for ; Mon, 15 Feb 2016 09:11: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 R6Y47LFWyefG for ; Mon, 15 Feb 2016 09:11:11 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id DE15284C6C for ; Mon, 15 Feb 2016 09:11:10 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u1F9AOXK029053; Mon, 15 Feb 2016 19:10:25 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u1F9AOJr014157 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Feb 2016 19:10:24 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id u1F9ANFL017083; Mon, 15 Feb 2016 19:10:23 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 641D6A4F35; Mon, 15 Feb 2016 20:10:23 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 635B9A4F34; Mon, 15 Feb 2016 20:10:23 +1100 (AEDT) Date: Mon, 15 Feb 2016 20:10:23 +1100 (AEDT) From: Damien Miller To: denis bider cc: "Mark D. Baushke" , =?ISO-8859-15?Q?Niels_M=F6ller?= , Peter Gutmann , Simon Josefsson , ietf-ssh@netbsd.org Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) In-Reply-To: <362309857-1692@skroderider.denisbider.com> Message-ID: References: <362309857-1692@skroderider.denisbider.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1455527427 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Mon, 15 Feb 2016, denis bider wrote: > Being widely implemented is not sufficient for MUST. No, but it is necessary. > curve25519-sha256 has > the unfortunate distinction of being widely deployed right after widespread > recognition of the need for safe curves, but just before the upping of NSA > recommendations. It's a bit weird to see recognition of safe curves accepted in the same sentence that advice from the NSA is uncritically accepted. Much of the justification from the so-called safe curves is because most people don't trust the NSA to set crypto standards any more. > I intend to implement curve25519-sha256 in Bitvise SSH Server and Client > when not used under FIPS. However, it cannot be available in FIPS mode, > because its crypto is not covered by FIPS 140-2. FIPS has lagged and will always lag current good practice (in which year did it deprecate single-DES?). IMO FIPS compatibility is not a justification to deny inclusion of an algorithm in the MUST set (though it might be a justification for including an algorithm). > I agree that safe curves are most likely superior to the ecdh-nistp > curves, and provide greater safety of implementation. However, it puts > the spec in conflict with reality if we specify a MUST algorithm that > can't be used by a significant proportion of users. MUST specifies what implementations have to support, not what users can/can't use. nistp384/521 is already there for the subset of users who are shackled to NIST-specified algorithms, but there is a very substantial user population who want an alternative and curve25519-sha256 has already proved itself a fine fit. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Feb 15 01:36:56 2016 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 D4EC31A6FD7 for ; Mon, 15 Feb 2016 01:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 Nb0Y3JvZPCZR for ; Mon, 15 Feb 2016 01:36:54 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 5F1CA1A0197 for ; Mon, 15 Feb 2016 01:36:54 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2E60C85EFC; Mon, 15 Feb 2016 09:36:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D0CD585EFA for ; Mon, 15 Feb 2016 09:36:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id R_vFVEhLTXMm for ; Mon, 15 Feb 2016 09:36:40 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::759]) by mail.netbsd.org (Postfix) with ESMTP id 0C84285EF6 for ; Mon, 15 Feb 2016 09:36:36 +0000 (UTC) Received: from DM2PR0501CA0029.namprd05.prod.outlook.com (10.162.29.167) by BY2PR05MB112.namprd05.prod.outlook.com (10.242.38.27) with Microsoft SMTP Server (TLS) id 15.1.403.16; Mon, 15 Feb 2016 09:36:33 +0000 Received: from BL2FFO11FD050.protection.gbl (2a01:111:f400:7c09::154) by DM2PR0501CA0029.outlook.office365.com (2a01:111:e400:5148::39) with Microsoft SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Mon, 15 Feb 2016 09:36:33 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; josefsson.org; dkim=none (message not signed) header.d=none;josefsson.org; 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-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11FD050.mail.protection.outlook.com (10.173.161.212) with Microsoft SMTP Server (TLS) id 15.1.415.6 via Frontend Transport; Mon, 15 Feb 2016 09:36:32 +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; Mon, 15 Feb 2016 01:36:17 -0800 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 u1F9aGD63631; Mon, 15 Feb 2016 01:36:16 -0800 (PST) (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 8AAF81144F; Mon, 15 Feb 2016 01:36:15 -0800 (PST) To: Damien Miller CC: denis bider , =?ISO-8859-15?Q?Niels_M=F6ller?= , Peter Gutmann , "Simon Josefsson" , Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) In-Reply-To: References: <223360780-3264@skroderider.denisbider.com> <86136.1455402404@eng-mail01.juniper.net> Comments: In-reply-to: Damien Miller message dated "Mon, 15 Feb 2016 19:00:54 +1100." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; 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;BL2FFO11FD050;1:f7M4DIrC63b5kfVgLjOpYdEDmb+8QoJiLl8KBi6mso2zBtXMpDkM5GbVB/VXQU4IAdJohwWIegI5tUaYLUL+6rvqmFQmeWpPznYRBstMigXr7zWfdAcp36Fo16UH9C0psxJERx3x+PSd+kIufh8FRV2F5GRYiLUy9amtVgGpl4lxIbx3a9zp3AmWBrkuKPNV31iw3CpebrGOawlBO/oD/WkF4M8drPYKXZ3MRgrDCTLKyVv2FaPl+w2BbEOMG887/ntQMUlPR1tP9d6w4ngXwppIa0kGOu/hVEPGxaF/ZmkyRthZ3FnzXNX8abAqk2V1K/aiAOZonCPfsITFFz09tyaiGPdaBTjk0UBjJby8ZzeLDv5bnIjiroxJHdt97G4RYC6aQlzvgrwrvjRloMmPYDpCHnUSA89m7lqSz69SKK0= X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(24454002)(199003)(189002)(2906002)(4326007)(47776003)(2950100001)(86362001)(586003)(117636001)(50226001)(230783001)(189998001)(53416004)(1096002)(1220700001)(2810700001)(50466002)(6806005)(76506005)(15975445007)(105596002)(11100500001)(77096005)(92566002)(19580395003)(5001960100002)(5003940100001)(110136002)(87936001)(5003600100002)(106466001)(50986999)(19580405001)(48376002)(76176999)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR05MB112;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB112;2:XtKyElF4HvBp1qUK6ey8NYLA43GDE4YF78ohNwhNv474FkmtKEiBIFcvB7YwTnYlaIMHdbKqjKs9qWFDG9D92qbwFjSnKzvR2Gk4TLU8ovpTVu1ukdNeDWXsDlHUr+dGmxSzu8nVdKGy1zRgsSdLRA==;3:oLwrKH85uCsDKMhE6ZTkoZAkTgY4owFL6pYOKut0ZP+PvkEzRvDXo6XrpPh+UTCJ473q8rl9z8FBNG6xuAJLEU8cIGzWT6m2t44b9ihMgplqpEpWV7GvcmMZP++SfH3dKIqhMmAnhFBCD9NFV9KHRw4C25BQybQ7ueK3L2lAP9GU2/5GlhF5bOifTN+e7dEwCfWHiwjUrlO+KCCMy9DRww7BBhBgRhyCEQGSP+jyWgE=;25:ijHAbylCpAxILnfwYATdabIlMHahNqLBJKpKyJr2P87g/y/mrN/R7PIJnn79lSfHIiUsHORDsSxPAQXnXfvsWBGkKhyDT1h1vEs35K3k1W6tqYQNF/mP0bldM/phM0EqjwQe0PEoRvccfWOSlCWu3r94MWLfNTQ4ZPoT8uutwSHy+rq1A/aTb8Es7PzoQ2Tod18YnJJ5MzQJKATpF5VUgxIy5j+3dmT6tik0vpVdgdp3TgGOZf94SrZT9+St3NgLvax8vtWdQqbhRCuPd+JAw9gSzs2UM8GtFLb/cAClJixxr/bQrC1/u2CbI8rCj8vP X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB112; X-MS-Office365-Filtering-Correlation-Id: 1dac64ff-4ed4-4ee9-29ae-08d335eb7d93 X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB112;20:vx8XHDlMJI8t7737j6UM7ErYATd0IEOrebKe/e6H803l2ZRNAMOKpmQSodVZQPxvpwi8+sZazCxPWA2Ly9wseksSF6of7vMPJgoiqc42/eX45VDNOrKZEZ4ZRe6VFjncDRnPi3T5/0BZ0HR58Gi2MoKTXkZ4GCDC5cuZL7njR2Krgng3AumVdG09XJEhtgLZ2WnF5M3m+T4qqyNwbRooBgNhZ+rXpIjePLJAhS3hPDJzy+D68jIVCvIvh36ledhzb4jCqZlg5wovMCFCXPXfqAWLNZvp/qnDy9aiS8is4aqI41SwwtXa7al5GDzE1v2A9XMJveO7SBo/7qSnRQem3nlYrbZ0SlCrW61U3ZBOCKnbYq9jwBOFC6VVm/gNjCI5ATz3vtLQeYZf+c+GbzzfF+0LmeyKj6yIofTOzSxhDmf2p7quwJ69BLov6LW4qIVWNkuXvoVo4T34ZLaRooVEuiV2Qdm7M1CZoEjiStT8sRIKmoB0tryMQjnRC3yKA89V X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(13018025)(13017025)(13015025)(13023025)(13024025)(8121501046)(3002001)(10201501046);SRVR:BY2PR05MB112;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB112; X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB112;4:ySAeeJ8hxKFHqeNB30kLGqZh/pYn/oX9TkmxcBd7Pbsw7QVauh1b/yAacZMw28IGFrN/sE78qhYAHJYvRqa5QTgqVtH5xFLy7yKMKKtJYMYbeOUJTVfqCQemR3al9wz5uXK4fubqGyyTDyF2UVKBSCDXyvGAhMZTA1n7ForMD9UHolA3eoSNlgKf04NMUCBRK6Ih/UkuZG3Mj1g9Xx5NyGAl1GDHhgNdVzDPRqeqRoTIh9koyr+c7311G3bt3FfY88RFkt81NkmXhj3fuDMY+/z+yWaPIuA/RvN4Jbnt2M439goS1aTZyveb//t/ae8GAUgUPL+J28vyL0kQbUpYhnwxRMXeJUGX/Y3Hv+JEN6yh2i4n+/kRUrY+mIxfPh3hZ6X+DnAwCAPJ6K1K9AhNn7D+ViEKL4fkZ42Uw/Ql/s7vBzQfewz+KFdHUsTFyQa7m/CxQzny2QXLOjD8cqa0uw== X-Forefront-PRVS: 08534B37A7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY2PR05MB112;23:Zukq6OQgYNBVwh1QWrBzgCk6MOwWONEl3nJNMpKuCf?= =?us-ascii?Q?Vk/xSnw1z1qL1cKOotxXXaeKLYN1DfFpby/7RiY3qRqQJlRXLlXx0PXoGAga?= =?us-ascii?Q?40ea+OM/Sy5ZIE+KhO+KJmogns//kdsSjo7lbsdJWAPekM4ZNo200BRHnWoI?= =?us-ascii?Q?YApsBFEft42nK5usSEOqG4+bk1iid2HCWfwNIebdkSruS68oeIz+Nbumf7xQ?= =?us-ascii?Q?de/SBNEKP+KZAQJ5R6fz7Zh0GCun4SMCeFF/axgHL8j8b7HDrMnIRq3cOWhY?= =?us-ascii?Q?a6ssC5Qw2pRxXAGHyuIfRMj0F4HbszvoTk0IVIqAncc/leeneDN2FYIqdhrD?= =?us-ascii?Q?jH+ouOyP119+3oGAPrXYs0Zul7tLg7WDbt8zVvFkjFoq8IdjTEa5+XnGxuYe?= =?us-ascii?Q?ls+NAZTlg/PkPv8TV5l7LF/ZJUCUHyxJRDYM3RFe7Vj6U7g+ykc+mzoSwGwr?= =?us-ascii?Q?MDaJDzEf9P4Oq1x5DPYdel/rFsCmgFtLFIG8uCOns36Q590ABTUl+oiqGSF+?= =?us-ascii?Q?F7RpwBZ0QONVbBcIy5BaRxI9Rkv7s7u2yCrKxaIfHMWlwJjv9P7ZQC6FeRa/?= =?us-ascii?Q?18yJGhCByy7jg62CcG1JNm4nbRBrzqBrKKskO3vMCozmSn2uXKL+XJ4yscdb?= =?us-ascii?Q?bKhR1H6bGIp846gHOLJ7bxUFXI05XP9kR/NLssvDNU1B+OMSvrv8lFBaY10z?= =?us-ascii?Q?eJyfMYt9hUDQski4Lz0BNhSlRbUWwWMUEUVuN0oRt+R8CUJEXqZu0Wf9oet4?= =?us-ascii?Q?y5SNQGkFY6cFAZcjl/HR2SeBGgP79k7iBjJyU/77CsLVsE/A9eTukdJrcN7Z?= =?us-ascii?Q?AWiDcWlz6dZBvsK6nE8N9titE7AsM+fGlRDGVHeeP4+wJokaLcoapEFQvsLV?= =?us-ascii?Q?N4SHTcrpdVz01P7elhALFGV79fHjKKJnOiSWHFzRDmd7izbLB8u6O+haOH3Q?= =?us-ascii?Q?m1skpuHoqmIO4P+Tpfprx/gn5//FuHao4K5bOw+YDXQNvavfNmJnAYVkiFtW?= =?us-ascii?Q?xJOc90YbsohyT5iJNlyse9wxN2hX1Ih2gfeDBz96x24YwTDpcyu6alj+qdHI?= =?us-ascii?Q?mhreY=3D?= X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB112;5:Nv5LygOkIYV5ebDKibDukGioejzGFrLCb0VxkIiyEaAV1wSzOw+BvRamLA8uI6aJAbAthYKYvuG1sf75+4eLVJSA1XlYcXnHklBP8IwKbmAZa2Bw144jkIICUYHjPTjo81TK5DZrbfpRGj9ZirpvoQ==;24:BLADrShKcj0XjZ6/kIeu76xi2PHESQTVY3LDEMJQktE0cVEmlmWHEoxlgp03T+illzkFvv3u6+eyJc1Kr06R5jCvCLnQaR1pgqzULS1WuiU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2016 09:36:32.6167 (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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB112 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes: > On Sat, 13 Feb 2016, Mark D. Baushke wrote: > > > https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/ > > IMO curve25519-sha256 should be a MUST, if not immediately then soon. > It's already supported under the curve25519-sha256@libssh.org alias by > a few implementations. Good point. I have moved curve25519-sha256 to MUST. > This paragraph: > > > The group15, group16, group17, and group18 names are the same as > > those specified in [RFC3526] as 3072-bit MODP Group 14, 4096-bit MODP > > Group 15, 6144-bit MODP Group 17, and 8192-bit MODP Group 18. > > is incorrect: group 14 is 2048 bits, not 3072. Group 15 is 3072 bits, > not 4096. Group 16's length is not described (4096 bits). 17 and 18 are > correct. Thank you for reporting this. I have updated the text in my copy and removed group15 and group17 from the list. I have submitted the new edition to https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/ it should propagate shortly. > I think the table of "Group modulus security strength estimates" should > have a reference - are these from NIST SP800-57? Actually, I do mention that I got the information from RFC3526, but I will make that more explicit and also point to RFC3766 for making the security strength calculation in person. Thank you, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Feb 15 07:41:02 2016 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 6EF761B2D45 for ; Mon, 15 Feb 2016 07:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 rTv_H5yiOHly for ; Mon, 15 Feb 2016 07:41:00 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 773E51A1A10 for ; Mon, 15 Feb 2016 07:41:00 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5EEDE84D04; Mon, 15 Feb 2016 15:40:59 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 36D7284D04 for ; Mon, 15 Feb 2016 15:40:56 +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 fYvVXDFYyrk3 for ; Mon, 15 Feb 2016 15:40:55 +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 39F5385F09 for ; Mon, 15 Feb 2016 15:40:54 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 22C434000B; Mon, 15 Feb 2016 16:40:51 +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 EC7254000A; Mon, 15 Feb 2016 16:40:48 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 15 Feb 2016 16:40:48 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: denis bider , Peter Gutmann , Simon Josefsson , Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) References: <223360780-3264@skroderider.denisbider.com> <86136.1455402404@eng-mail01.juniper.net> Date: Mon, 15 Feb 2016 16:40:48 +0100 In-Reply-To: <86136.1455402404@eng-mail01.juniper.net> (Mark D. Baushke's message of "Sat, 13 Feb 2016 14:26:44 -0800") 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 "Mark D. Baushke" writes: > You have both made good points. I have adopted the updated text from > denis and tried provide a meaning for the Note column. I have also added > a pointer to the Simon's ssh-curves draft and included both of the > currently published curve names in the table in this draft. Thanks. > https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/ I'm looking at the -04 version where curve25519 is upgraded to MUST. I think it looks quite good. If at all possible, I think it would be desirable to 1. Limit the number of REQUIRED/MUST key exchange algorithms to one (1). I think curve25519 (if people agree it's mature enough) or group16 are reasonable choices. I.e., demote ecdh-sha2-nistp384 to SHOULD or MAY. 2. Make it possible for a conforming implementation to support only one of sha256 and sha512. If we make anything using sha512 REQUIRED, I think we should avoid to make sha256 REQUIRED too. And vice versa. I don't think I follow the argument in favor of sha512, but using sha512 for all REQUIRED methods is nevertheless better than a mix. According to the table, group 16 has an estimated security strength of 240 bits. As argued before, I don't think birthday-paradox is relevant as the hash function is used. Hence, if sha256 is used together with group16, sha256 seems good enough for the foreseeable future, and in addition, unlikely to be the weakest link. Finally, about the motivation in Sec 1, "[MFQ-U-OO-815099-15] suggesting that the use of ECDH using the nistp256 curve and SHA-2 based hashes less than SHA2-384 are no longer sufficient for transport of Top Secret information." On one hand, I don't think government requirements are that relevant for selecting the REQUIRED algorithm(s). It's motivated to have at least one SHOULD algorithm approved for US government use. But any organization handling "Top Secret information" is free to configure its ssh software any way it pleases, including disabling use of some REQUIRED algorithms. And "if you don't implement this algorithm, you may not interoperate with certain US government computer systems" is the kind of warning that I think is perfectly appropriate if an implementation decides to omit support for some algorithm with status SHOULD. But on the other hand, if you interpret the NSA statement as saying "we know a *lot* more about breaking sha256 than you do", than that could be a very good reason to avoid sha256. I can't say how credible that interpretation is. > Please let me know of additional comments. In short, no strong objections, but I'd prefer if the selection of REQUIRED algorithm(s) were even more restrictive. 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 Mon Feb 15 09:14:13 2016 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 A114B1A9027 for ; Mon, 15 Feb 2016 09:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 5X-CTwYSVSVX for ; Mon, 15 Feb 2016 09:14:12 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 012161A9026 for ; Mon, 15 Feb 2016 09:14:11 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0E09285F7F; Mon, 15 Feb 2016 17:14:11 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D15A585F7E for ; Mon, 15 Feb 2016 17:14:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id tjjpVaWOnMjz for ; Mon, 15 Feb 2016 17:14:06 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::771]) by mail.netbsd.org (Postfix) with ESMTP id ECE5885F6E for ; Mon, 15 Feb 2016 17:14:00 +0000 (UTC) Received: from BY1PR0501CA0040.namprd05.prod.outlook.com (10.162.139.50) by DM2PR05MB557.namprd05.prod.outlook.com (10.141.158.140) with Microsoft SMTP Server (TLS) id 15.1.396.15; Mon, 15 Feb 2016 17:13:58 +0000 Received: from BN1AFFO11FD029.protection.gbl (2a01:111:f400:7c10::186) by BY1PR0501CA0040.outlook.office365.com (2a01:111:e400:4821::50) with Microsoft SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Mon, 15 Feb 2016 17:13:58 +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-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD029.mail.protection.outlook.com (10.58.52.184) with Microsoft SMTP Server (TLS) id 15.1.415.6 via Frontend Transport; Mon, 15 Feb 2016 17:13:57 +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; Mon, 15 Feb 2016 09:13:54 -0800 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 u1FHDqD28368; Mon, 15 Feb 2016 09:13:53 -0800 (PST) (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 21E131144E; Mon, 15 Feb 2016 09:13:52 -0800 (PST) To: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6ller=3F=3D?= CC: denis bider , Peter Gutmann , Simon Josefsson , Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) In-Reply-To: References: <223360780-3264@skroderider.denisbider.com> <86136.1455402404@eng-mail01.juniper.net> Comments: In-reply-to: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6lle?= =?us-ascii?Q?r=3F=3D?= message dated "Mon, 15 Feb 2016 16:40:48 +0100." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Feb 2016 09:13:52 -0800 Message-ID: <27854.1455556432@eng-mail01.juniper.net> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1AFFO11FD029;1:AlDntMekFHVmiA4lM4xgmuPnBxU8FIC2uu0hw7RI8Frmw2MNbmEkMJ28atcENWD7CqjmYQTd3c5g+a5NTiQC3rl+5oByGdx6CkJO7jI/D/cyHE3zFVc8fG5d2Q6xwF80DIfeE/BE7uIyGRCBjrrBrGJ3sVZeVhXdaMZ7jm4/f8GvGX9K5+IJKzEaHnfXSKMF9oEW/2z+zJe6Eqzpx7dF92+LhZzfWXRJqglcaqJbYUc8mWheBYWnradwIerOTZcA+x0wsQbBOJdOpSbHAKcyI3Kc94RcvTWj6hjRuW+qOy/+wc6HhQlfcQ+cd5PToC8pcRku08ukVujgaXNfMcnwu8+PQ5/5BT5pjzpEe4jUnuUeJ4tnymFc4W/17bGGHBS5Zv4FRZMO+cCD3uVUhWPW2L1qx6cU5NQJW4GdAslS2js= X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(189002)(199003)(53416004)(92566002)(105596002)(117636001)(230783001)(110136002)(5001960100002)(50986999)(6806005)(106466001)(1096002)(1220700001)(76176999)(23676002)(586003)(189998001)(87936001)(76506005)(4326007)(2810700001)(50466002)(19580405001)(19580395003)(5003600100002)(11100500001)(54356999)(77096005)(86362001)(2906002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR05MB557;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;DM2PR05MB557;2:n46CxFf2bUEcJJhTNc1GKNKM1EvpJG5XyuITzKMt4bHk0C765E4ch/I4qXF+48saa1CUKuP6K1qEruzYOVYmVtRItlW3C5slV5rpOXJshpMW+macPieIjRLtQQX6gebu42Zha1jh4W8g6WNym5ItXQ==;3:mE6IFu9VcZ4LBfnq/uqWWSobYhETJmwnEyauMNDeSWYREBj9eymtfUwRvmDcugnSoCaCd+04/j4r6hRD9sDNNsO+ijj1XPcreOJ1Gz4knjkBYLCMMAjF0mD6WMgsode6KohHKe7Wszy6BtIbSUbrjGeLv7Jt0vWPwYJVACv05B1EFJoNPMbPbClWuuxtk+akNpka4l2KwMpnFXlLt1oguOLf5vWfiTTmKj0r+8sCnhM=;25:vA0w502nrYby44pHRxxhJ6h/5ILBrrTNFnvPN6y99tqFUyI2PN7ft8oToeRV8VxyMwwAT9hsSARik9+i7BAg9UkunTV3yqWtcnAm+7ZpPvbF7YgGgenJOmYcYBqywvzoEVa4nv/bIOKfRuD0g4f05QEvRW/2Z+RzKUUJrdoZMaTBuENVkCLPZLd9G+1yKFW4lKeFoNjIGGtVf8iuyMskiIgBfOjEInCACZsJBR9HOPwmj+rgHlWbK0PuTv5ITZCpPBFzKVd1ULUuB9RbXOOUaLaQe7zJ6F5qw9TKBQXhqr7iFRPJ5DCZxIF2sz5cAGN3 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB557; X-MS-Office365-Filtering-Correlation-Id: 42358ba5-bde3-460e-22aa-08d3362b63db X-Microsoft-Exchange-Diagnostics: 1;DM2PR05MB557;20:M9SthlbO90oENo0t/lohjvQ6e0+6Scp+9kYOwZ3yBqPeAjCSU3wszuRhcUfCC32suJGRPzN8ptUWX9X7e26lxr07nBbhn56WP5MdMpWIfy9+nSpfLHWzbwhjocsskCw6sUV/ZFA3i4eSzBUBrj0e2PY0D7U+efsT4J5nbPE5w83g20C7goe75WTKqFkTVLusF23QU85n1SdxlukNRX2zXLETIxaRPR8k5BRjPMpcvrkVCVbWIS1moV+9XXNyqEehVctPw09e7T8E3odUaE2Cb1AwvoHYrwHZEMB+OF2iFHE+Cm2TkXx7ant6/9WqnrPrINP+06zNfs0Cpku9mNwvJ6fi1pTp7cOHEMOjeK/g28+oCY2fD1pAhqT3FAeUYNs6m0v/utIs5eQjdd7dUdhW38/rPRaKCaaUe16Zm7qJHWnA4FEGl4C/HfFDqPTZO40XZ5x06f2lE7x563an0M8nArnYYJO7Lqrzh3X4b2CtvBkS9sDKIVEf2GbPFE9oOMNZ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13015025)(13018025)(13024025)(13023025)(13017025)(8121501046)(5005006)(3002001)(10201501046);SRVR:DM2PR05MB557;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB557; X-Microsoft-Exchange-Diagnostics: 1;DM2PR05MB557;4:nTVNu7E7f8R+g/ORfSVdFxIfhZlQGAktrTJebwrbjD+vKZYueL7eYW86W/n6f77OI/REgw9OlEheJQ8UMEndL7h1pK44J3I+ksxTnQbHCWXkMBR1oiRQ6ch7t+0OzQCQDmHExK1PwGICN+dQwtaGrvhM4Va/hXwY0toXDEihvx0zHupOM5AJuJy7ntsasDjaMPGyP2lVLOMIOgPN4svbkbHi9UxRZA+iQodB4zGggbYdUgdNiG0TvoxKAKcE0Ss09DsjNkNgEXL1R1DFP1WgTslSOCf0OmJuWXQ4lcNQl00OR92fcbuBQ6C6URsTxwYmdFSGvZbsBZ+RNZasToYiLypws9bqUnTpRiOmqlxev++9h5ERbt+FW5Z/6KsQ8E97Zdk/Z80/G18fpijTC7p8B6q9xUuya9KN6IH5+JO5jxKDNKs5nq8mfUPGbKQ6jJvqX2/MhrgTOujJjqnDtlEjog== X-Forefront-PRVS: 08534B37A7 X-Microsoft-Exchange-Diagnostics: 1;DM2PR05MB557;23:WOqM+YDiIttyb2ylfPpUdWurppDQJ+SKw4tf2G3zU7xCbhXkr4FoPGymsKaZS1NzyrOXYhezBjA1TNiWgT6khM62Pt0+ezAyp2i5Z8D3m1XL/+UISofp9kmqL089Cbkerv2h1YbmfQ90pMuxLTcHACG8FiEwZIR5Y3QF1/9LYgAA9pu72lgFKHE5LN0oU9cgQ0rNU6axmaN5R/ngatFH6A2Tygzz7u4jOhkPequBdxkFXsFXem+y/lwy3+CrZq+P4K9eMNX9DLZ8vO+06GL55DNuIKCQIT037eHB7SOl4YQzraPrUdr3yfKqPWS4jUxwrjxKFO6IpMenm+ym8LypN/4IxYrNpLPMkuN0zVlJQg1pBBfuQPAIvH8rhNd4fMSAjJ0/0NEBZz/ewRg0DpwnluBTYF+WzX0mUvzyGOrWyQYvAlCsvN1foDU2RCWga6nvr/idyFxapjlOlXr0qYA9qbmy9x07iC0qEE8RrhybPqMX5hAAT2xBGGrX7oq8LZRzVO3LsTpUYrhLdPWRAQewnIEuApPBAqKCRAvqUKwD5W757Tw93gi1rBNC+QMu22dNAnwPjOaqe2AAp1nvs7x48F4XciWCOHz5DukOYP0BolCIZG0XXOCEc08N4W3lxGl2V5F9SNiBPdbFzjgrEfJSWXOp8IMpYoQhrX4W+3ugedjoDqhscQO+jgsgAGm9eZkVfrNEWn5syayhmzHvO7q/TFWbeVMOzW+btnSNwen+e3LJ3H/Smx3ZDTw9sNwRczCVZQBn3W1dJdMcWuOjsVbo1nGbVbaBQcNNUwA78/NEUPeRbsMKXvMRS96gO0jeWWQez0DxC9OS18u98rHS1xf/DwNYEE3LaOPp8c+ZE+Dv17SQUw8i6MefyHniqlESvm4HJCao9Pyo99Aa5CkfUM0/fTi9aV9IN4B6Di6wlEJi6uQ= X-Microsoft-Exchange-Diagnostics: 1;DM2PR05MB557;5:oauitMQ1daxROPIq8Lzq25jadrLKQjaJhF65dQHgPCRgMN8MGaMhF6LhxqD5RKmzBVsOxyAN3qdukhtX8F5bi3cQxYLogRqqnC43O2eXOPF0SrniXwWhXq2IixVF91Xv5QWYzBugoZeru0okkUCiVw==;24:NSS1kd399xVtDG751aHNR+B7zVhXNRapSEb2GuO3ny0IUZQ9Nu1J+2CqohSTvKgXqmSthThNGWemty7MMOPtaZphRlBnCVimstAgwmMdHBA= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2016 17:13:57.2583 (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-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB557 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Ni Niels, Niels M=C3=B6ller writes: > If at all possible, I think it would be desirable to >=20 > 1. Limit the number of REQUIRED/MUST key exchange algorithms to one (1). > I think curve25519 (if people agree it's mature enough) or group16 > are reasonable choices. I.e., demote ecdh-sha2-nistp384 to SHOULD or > MAY. I am willing to consider a move of ecdh-sha2-nistp384 to SHOULD. This would mean only one Elliptic Curve (curve25519-sha256) is a MUST. For ecdh-sha2-nistp384, the downside of this is that OpenSSL library has no tuning or constant-time multiplication optimizations for the NIST-P384 curve. It is not clear to me if anyone is going to try to improve this situation. So, this means that ecdh-sha2-nistp384 may be open to side-channel attacks right now for those using the OpenSSL implementation. If it were defined, I might be interested in moving to curve448-sha512 as the single MUST algorithm, with the understanding that a lot of the other algorithms that are listed will continue to live for a time anyway. That said, is it desirable to also make one of the MODP Diffie-Hellman groups also be a MUST?=20 Perhaps the selection of diffie-hellman-group18-sha512 which has a security strength estimate of ~190 bits as compared to curve448 which has a security strength estimate of ~224 bits of security (per RFC7748). > 2. Make it possible for a conforming implementation to support only one > of sha256 and sha512. If we make anything using sha512 REQUIRED, I > think we should avoid to make sha256 REQUIRED too. And vice versa. >=20 > I don't think I follow the argument in favor of sha512, but using > sha512 for all REQUIRED methods is nevertheless better than a mix. I am not sure I follow this line of reasoning. I have seen most libraries that implement one of the SHA2 family of functions tends to have an implementation for all members of the family. > According to the table, group 16 has an estimated security strength > of 240 bits. As argued before, I don't think birthday-paradox is > relevant as the hash function is used. Hence, if sha256 is used > together with group16, sha256 seems good enough for the foreseeable > future, and in addition, unlikely to be the weakest link. Sure, I tend to think that the weakest element will be the source of entropy in the system.=20 This does not mean that I understand all of the attacks against hashing. (For example, I still do not understand why BLAKE2 did not win the SHA3 competition. Although, I do admit that I find the SHA3 XOF functions to be fascinating.) The key here is the phrase 'foreseeable future' and for that I want to be a bit more forward-looking and would very much like to see SHA2-512 if there is a negative bias in other publications for SHA2-256 still being used as a cryptographic primitive. Many processor families even have some chips with hardware acceleration for SHA2-256 (e.g., Arm, Intel, Octeon). > > Please let me know of additional comments. >=20 > In short, no strong objections, but I'd prefer if the selection of > REQUIRED algorithm(s) were even more restrictive. Okay, I can understand this. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Feb 15 10:52:06 2016 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 3F3591A9030 for ; Mon, 15 Feb 2016 10:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 o56IaITv7UIG for ; Mon, 15 Feb 2016 10:52:04 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 BC1131A8AD3 for ; Mon, 15 Feb 2016 10:52:04 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id BF7A485F94; Mon, 15 Feb 2016 18:52:03 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5F14385E3C for ; Mon, 15 Feb 2016 18:52:01 +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 9jdQoBDkqF8w for ; Mon, 15 Feb 2016 18:52:00 +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 7466784CFD for ; Mon, 15 Feb 2016 18:51:59 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C4DFC40059; Mon, 15 Feb 2016 19:51:57 +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 288D640056; Mon, 15 Feb 2016 19:51:55 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 15 Feb 2016 19:51:55 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: denis bider , Peter Gutmann , Simon Josefsson , Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) References: <223360780-3264@skroderider.denisbider.com> <86136.1455402404@eng-mail01.juniper.net> <27854.1455556432@eng-mail01.juniper.net> Date: Mon, 15 Feb 2016 19:51:55 +0100 In-Reply-To: <27854.1455556432@eng-mail01.juniper.net> (Mark D. Baushke's message of "Mon, 15 Feb 2016 09:13:52 -0800") 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 "Mark D. Baushke" writes: > That said, is it desirable to also make one of the MODP Diffie-Hellman > groups also be a MUST?=20 Not sure. But *if* we decide on two REQUIRED curves, I think it makes sense to let one of them be a modp curve. >> 2. Make it possible for a conforming implementation to support only one >> of sha256 and sha512. > I am not sure I follow this line of reasoning. I have seen most > libraries that implement one of the SHA2 family of functions tends to > have an implementation for all members of the family. The concern is more about binary size than source code. If you want a compliant ssh implementation inside your toaster or sensor node, with only a poor microcontroller inside. Then everything you can cut away helps. If we don't care about formal compliance for such devices, this argument becomes weaker. > The key here is the phrase 'foreseeable future' and for that I want to > be a bit more forward-looking and would very much like to see SHA2-512 > if there is a negative bias in other publications for SHA2-256 still > being used as a cryptographic primitive. My understanding is that a secure hash algorithm with 256 bits output is a very strong primitive. If there's a problem with sha256, it isn't the too short digest size (might be in other applications, where the attacker can win by finding arbitrary collisions, with "only" 128 bit difficulty), but structural problems which allows the attacker to take short cuts. And the likelyhood of that is hard to put a number on. I'm not strongly opposed to sha512. If we go for it, I think it's preferable to not have any sha256 with status MUST. And as someone else mentioned, if we believe eddsa25519 is going to be widely used, then it's an advantage to use sha512 in the key exchange too, to be able to cut away sha256 in the constrained implementation. 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 Tue Feb 16 22:46:32 2016 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 80E351A8956 for ; Tue, 16 Feb 2016 22:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.006 X-Spam-Level: X-Spam-Status: No, score=-0.006 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] 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 1Kyw9hGon6eW for ; Tue, 16 Feb 2016 22:46:30 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 494801A8930 for ; Tue, 16 Feb 2016 22:46:30 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 31C1C86128; Wed, 17 Feb 2016 06:46:28 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id E0F898611B; Wed, 17 Feb 2016 06:46:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 540DC85E70 for ; Mon, 15 Feb 2016 08:46:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id Vxq2D4BjvVut for ; Mon, 15 Feb 2016 08:46:28 +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 A0D1A84CEF for ; Mon, 15 Feb 2016 08:46:28 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Mon, 15 Feb 2016 08:45:59 +0000 Date: Mon, 15 Feb 2016 08:45:59 +0000 Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <362309857-1692@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Damien Miller , "Mark D. Baushke" Cc: =?UTF-8?q?Niels_M=C3=B6ller?= , Peter Gutmann , Simon Josefsson , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-j86lKKJr7gX/lm5DuGn6" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-j86lKKJr7gX/lm5DuGn6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Being widely implemented is not sufficient for MUST. curve25519-sha256 has = the unfortunate distinction of being widely deployed right after widespread= recognition of the need for safe curves, but just before the upping of NSA= recommendations. I intend to implement curve25519-sha256 in Bitvise SSH Server and Client wh= en not used under FIPS. However, it cannot be available in FIPS mode, becau= se its crypto is not covered by FIPS 140-2. Then in addition, the use of a 255-bit curve, and SHA-256 as hash function,= falls short of recent NSA recommendations for uniform standards of protect= ion of classified material up to top secret. curve448-sha512, if it were defined, would still not be usable under FIPS. = However, it would at least the security recommendations: elliptic curve lar= ger than 384 bits, with hash function SHA-384 or larger. On the other hand = - if curve448-sha512 is not defined, then curve448-sha256 does not meet the= se standards either. For these reasons, I would suggest curve448-sha512, if it were defined, as = SHOULD; and curve25519-sha256 as MAY. I agree that safe curves are most likely superior to the ecdh-nistp curves,= and provide greater safety of implementation. However, it puts the spec in= conflict with reality if we specify a MUST algorithm that can't be used by= a significant proportion of users. ----- Original Message ----- From: Damien Miller=20 Sent: Monday, February 15, 2016 02:00 To: Mark D. Baushke=20 Cc: denis bider ; Niels M=C3=B6ller ; Peter Gutmann ; Simon Josefsson ; iet= f-ssh@netbsd.org=20 Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) On Sat, 13 Feb 2016, Mark D. Baushke wrote: > Hi denis & Niels, >=20 > You have both made good points. I have adopted the updated text from > denis and tried provide a meaning for the Note column. I have also added > a pointer to the Simon's ssh-curves draft and included both of the > currently published curve names in the table in this draft. >=20 > https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/ >=20 > Please let me know of additional comments. IMO curve25519-sha256 should be a MUST, if not immediately then soon. It's already supported under the curve25519-sha256@libssh.org alias by a few implementations. This paragraph: >=C2=A0 The group15, group16, group17, and group18 names are the same as >=C2=A0 those specified in [RFC3526] as 3072-bit MODP Group 14, 4096-bit MO= DP >=C2=A0 Group 15, 6144-bit MODP Group 17, and 8192-bit MODP Group 18. is incorrect: group 14 is 2048 bits, not 3072. Group 15 is 3072 bits, not 4096. Group 16's length is not described (4096 bits). 17 and 18 are correct. I think the table of "Group modulus security strength estimates" should have a reference - are these from NIST SP800-57? -d = --=-j86lKKJr7gX/lm5DuGn6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Being widely implemented is not sufficient for MUS= T. curve25519-sha256 has the unfortunate distinction of being widely deploy= ed right after widespread recognition of the need for safe curves, but just= before the upping of NSA recommendations.

I intend to implement cur= ve25519-sha256 in Bitvise SSH Server and Client when not used under FIPS. H= owever, it cannot be available in FIPS mode, because its crypto is not cove= red by FIPS 140-2.

Then in addition, the use of a 255-bit curve, and= SHA-256 as hash function, falls short of recent NSA recommendations for un= iform standards of protection of classified material up to top secret.
<= br>curve448-sha512, if it were defined, would still not be usable under FIP= S. However, it would at least the security recommendations: elliptic curve = larger than 384 bits, with hash function SHA-384 or larger. On the other ha= nd - if curve448-sha512 is not defined, then curve448-sha256 does not meet = these standards either.

For these reasons, I would suggest curve448-= sha512, if it were defined, as SHOULD; and curve25519-sha256 as MAY.
I agree that safe curves are most likely superior to the ecdh-nistp curves= , and provide greater safety of implementation. However, it puts the spec i= n conflict with reality if we specify a MUST algorithm that can't be used b= y a significant proportion of users.


----- Original Message ----= -
From: Damien Miller
Sent: Monday, February 15, 2016 02:00
To: M= ark D. Baushke
Cc: denis bider ; Niels M=C3=B6ller ; Peter Gutmann ; Si= mon Josefsson ; ietf-ssh@netbsd.org
Subject: Re: draft-baushke-ssh-dh-g= roup-sha2-01 (was Re: DH group exchange)

On Sat, 13 Feb 2016, Mark D= . Baushke wrote:

> Hi denis & Niels,
>
> You hav= e both made good points. I have adopted the updated text from
> denis= and tried provide a meaning for the Note column. I have also added
>= a pointer to the Simon's ssh-curves draft and included both of the
>= currently published curve names in the table in this draft.
>
&g= t; https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/
>= ;
> Please let me know of additional comments.

IMO curve25519= -sha256 should be a MUST, if not immediately then soon.
It's already sup= ported under the curve25519-sha256@libssh.org alias by
a few implementat= ions.

This paragraph:

>  The group15, group16, group1= 7, and group18 names are the same as
>  those specified in [RFC3= 526] as 3072-bit MODP Group 14, 4096-bit MODP
>  Group 15, 6144-= bit MODP Group 17, and 8192-bit MODP Group 18.

is incorrect: group 1= 4 is 2048 bits, not 3072. Group 15 is 3072 bits,
not 4096. Group 16's le= ngth is not described (4096 bits). 17 and 18 are
correct.

I think= the table of "Group modulus security strength estimates" should
have a = reference - are these from NIST SP800-57?

-d

= --=-j86lKKJr7gX/lm5DuGn6-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 16 22:46:40 2016 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 A58901A90DF for ; Tue, 16 Feb 2016 22:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] 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 l24l3N7MFX2r for ; Tue, 16 Feb 2016 22:46:35 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 1B0AF1A8A46 for ; Tue, 16 Feb 2016 22:46:35 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6C6EE86125; Wed, 17 Feb 2016 06:46:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 237E68611B; Wed, 17 Feb 2016 06:46:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F1AA785E70 for ; Mon, 15 Feb 2016 08:52:18 +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 WBOOzudzThQo for ; Mon, 15 Feb 2016 08:52:18 +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 38BD984CEF for ; Mon, 15 Feb 2016 08:52:18 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Mon, 15 Feb 2016 08:51:51 +0000 Date: Mon, 15 Feb 2016 08:51:51 +0000 Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <363412612-2856@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: MIME-Version: 1.0 From: denis bider To: Damien Miller Cc: "Mark D. Baushke" , Peter Gutmann , =?UTF-8?q?Niels_M=C3=B6ller?= , Simon Josefsson , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-boo+B22wOMxQ3ISsFfhm" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-boo+B22wOMxQ3ISsFfhm Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It looks like we were writing at about the same time. :-) Yes, I agree with the below. With regard to speed - in implementations available to me (Windows CNG and = Crypto++), nistp384 appears to be faster than nistp521. I can't testify to = how optimized they are. Damien Miller , 2/15/2016 8:33 AM: On Sat, 13 Feb 2016, denis bider wrote:=20 =20 > Comments:=20 > =20 > - If we're being comprehensive, we should include a position with regard = to=20 > Curve25519 and Curve448:=20 > =20 > https://tools.ietf.org/html/draft-josefsson-ssh-curves-03=20 > =20 > I suggest we take the following positions:=20 > =20 > curve25519-sha256=C2=A0=C2=A0=C2=A0 SHOULD=20 > curve448-sha256=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD, or MAY?=20 > =20 > That being said:=20 > =20 > - Given the recent NSA recommendations, it seems to me it would be pruden= t=20 > to update the Curve25519/Curve448 draft, and to replace the SHA-256=20 > algorithm with SHA-512 for Curve448. This would create the method=20 > "curve448-sha512" instead of "curve448-sha256".=20 > =20 > Simon, what do you think? Could your draft be updated to do that?=20 > =20 > It seems to me that this would meet the NSA's long-term guidelines, where= as=20 > curve448-sha256 doesn't.=20 =20 I agree that curve448-sha512 is preferable to curve448-sha256, but=20 not for this reason. The NSA's guidance is IMO confused, betting that=20 quantum computers hit some goldilocks zone of "big/fast enough to break=20 DLP for ~256 bit EC groups" but "too small/slow for 384 bit groups"=20 because they've been caught flatfooted by QC developments and don't have=20 real QC-resistant replacements ready yet (not that anyone would trust them=20 if they came from the NSA anwyay).=20 =20 IMO a better justification is: curve448 is a backup against as-yet-unknown=20 attacks on curve25519. Since we're not likely to need it, we might as well=20 pair it with SHA512 as a backup against as-yet-unknown attacks on SHA256.=20 =20 Implementors who support ssh-ed25519 will need to carry SHA512 code around=20 anyway, so the incremental code cost is trivial. The speed cost of a SHA512= =20 hash instead of a SHA256 hash is minuscule.=20 =20 > - If we're going to have text saying SHA-1 is begrudgingly acceptable for= =20 > backwards compatibility, we can't simultaneously say that it is "NOT SECU= RE"=20 > in all caps. Conversely - if we do say it is "NOT SECURE", we can't have = a=20 > graceful transition away from SHA-1. We must in that case pursue an=20 > aggressive transition, including condemnation of existing products that u= se=20 > it.=20 =20 I agree: saying SHA1 is "NOT SECURE" here is overdoing it a little. The=20 justification for abandoning SHA-1 on signatures is that these have a=20 relatively long lifetime during which they can be attacked - O(year).=20 Key exchange hashes have a much smaller temporal window for attack -=20 only as long as an implementation is willing to accept a client that=20 doesn't reply before NEWKEYS - O(minutes).=20 =20 > - Niels has suggested that it's onerous to have so many "MUST" curves. We= 've=20 > already reduced the number of MUST curves from three (in RFC 5656) to two= =20 > (in this draft). I'm not sure that either nistp384 or nistp521 are suitab= le=20 > candidates for demotion. However, if we make changes here, it seems we=20 > should keep nistp384 as MUST, and demote nistp521 to SHOULD. This is due = to=20 > that nistp384 meets current longest-term guidelines; whereas nistp521 see= ms=20 > to be overkill, and slower.=20 =20 AFAIK nistp521 is quite a bit faster than nistp384 in practice (OpenSSL)=20 because it's been optimised. ~nobody uses nistp384, so it hasn't.=20 =20 $ openssl speed ecdh=20 [...]=20 Doing 256 bit =C2=A0ecdh's for 10s: 45769 256-bit ECDH ops in 9.98s=20 Doing 384 bit =C2=A0ecdh's for 10s: 10505 384-bit ECDH ops in 9.98s=20 Doing 521 bit =C2=A0ecdh's for 10s: 13095 521-bit ECDH ops in 9.98=20 =20 -d= --=-boo+B22wOMxQ3ISsFfhm Content-Type: text/html; charset="utf-8" It looks like we were writing at about the same time. :-)

Yes, I agree with the below.

With regard to speed - in implementations available to me (Windows CNG and Crypto++), nistp384 appears to be faster than nistp521. I can't testify to how optimized they are.


Damien Miller <djm@mindrot.org> , 2/15/2016 8:33 AM:
On Sat, 13 Feb 2016, denis bider wrote:

> Comments:
>
> - If we're being comprehensive, we should include a position with regard to
> Curve25519 and Curve448:
>
> https://tools.ietf.org/html/draft-josefsson-ssh-curves-03
>
> I suggest we take the following positions:
>
> curve25519-sha256    SHOULD
> curve448-sha256      SHOULD, or MAY?
>
> That being said:
>
> - Given the recent NSA recommendations, it seems to me it would be prudent
> to update the Curve25519/Curve448 draft, and to replace the SHA-256
> algorithm with SHA-512 for Curve448. This would create the method
> "curve448-sha512" instead of "curve448-sha256".
>
> Simon, what do you think? Could your draft be updated to do that?
>
> It seems to me that this would meet the NSA's long-term guidelines, whereas
> curve448-sha256 doesn't.

I agree that curve448-sha512 is preferable to curve448-sha256, but
not for this reason. The NSA's guidance is IMO confused, betting that
quantum computers hit some goldilocks zone of "big/fast enough to break
DLP for ~256 bit EC groups" but "too small/slow for 384 bit groups"
because they've been caught flatfooted by QC developments and don't have
real QC-resistant replacements ready yet (not that anyone would trust them
if they came from the NSA anwyay).

IMO a better justification is: curve448 is a backup against as-yet-unknown
attacks on curve25519. Since we're not likely to need it, we might as well
pair it with SHA512 as a backup against as-yet-unknown attacks on SHA256.

Implementors who support ssh-ed25519 will need to carry SHA512 code around
anyway, so the incremental code cost is trivial. The speed cost of a SHA512
hash instead of a SHA256 hash is minuscule.

> - If we're going to have text saying SHA-1 is begrudgingly acceptable for
> backwards compatibility, we can't simultaneously say that it is "NOT SECURE"
> in all caps. Conversely - if we do say it is "NOT SECURE", we can't have a
> graceful transition away from SHA-1. We must in that case pursue an
> aggressive transition, including condemnation of existing products that use
> it.

I agree: saying SHA1 is "NOT SECURE" here is overdoing it a little. The
justification for abandoning SHA-1 on signatures is that these have a
relatively long lifetime during which they can be attacked - O(year).
Key exchange hashes have a much smaller temporal window for attack -
only as long as an implementation is willing to accept a client that
doesn't reply before NEWKEYS - O(minutes).

> - Niels has suggested that it's onerous to have so many "MUST" curves. We've
> already reduced the number of MUST curves from three (in RFC 5656) to two
> (in this draft). I'm not sure that either nistp384 or nistp521 are suitable
> candidates for demotion. However, if we make changes here, it seems we
> should keep nistp384 as MUST, and demote nistp521 to SHOULD. This is due to
> that nistp384 meets current longest-term guidelines; whereas nistp521 seems
> to be overkill, and slower.

AFAIK nistp521 is quite a bit faster than nistp384 in practice (OpenSSL)
because it's been optimised. ~nobody uses nistp384, so it hasn't.

$ openssl speed ecdh
[...]
Doing 256 bit  ecdh's for 10s: 45769 256-bit ECDH ops in 9.98s
Doing 384 bit  ecdh's for 10s: 10505 384-bit ECDH ops in 9.98s
Doing 521 bit  ecdh's for 10s: 13095 521-bit ECDH ops in 9.98

-d
--=-boo+B22wOMxQ3ISsFfhm-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 16 22:46:46 2016 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 6C07A1ACCE3 for ; Tue, 16 Feb 2016 22:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 XAiPKgWEGhkD for ; Tue, 16 Feb 2016 22:46:41 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 278391A8A46 for ; Tue, 16 Feb 2016 22:46:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5DB8C86129; Wed, 17 Feb 2016 06:46:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0C26B8611B; Wed, 17 Feb 2016 06:46:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1CC2D85E70 for ; Mon, 15 Feb 2016 09:13:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id x-qdB9Rs6TWd for ; Mon, 15 Feb 2016 09:13:47 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id 2BAE284C6C for ; Mon, 15 Feb 2016 09:13:46 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u1F8Xgl8004335; Mon, 15 Feb 2016 18:33:42 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u1F8Xgrq003274 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Feb 2016 18:33:42 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id u1F8XeB4006068; Mon, 15 Feb 2016 18:33:41 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id A3A4AA4F34; Mon, 15 Feb 2016 19:33:40 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 9EF42A4F33; Mon, 15 Feb 2016 19:33:40 +1100 (AEDT) Date: Mon, 15 Feb 2016 19:33:40 +1100 (AEDT) From: Damien Miller To: denis bider cc: "Mark D. Baushke" , Peter Gutmann , =?ISO-8859-15?Q?Niels_M=F6ller?= , Simon Josefsson , ietf-ssh@netbsd.org Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) In-Reply-To: <219217362-2196@skroderider.denisbider.com> Message-ID: References: <219217362-2196@skroderider.denisbider.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="0-721202717-1455525220=:4613" X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1455525223 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-721202717-1455525220=:4613 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Sat, 13 Feb 2016, denis bider wrote: > Comments: > > - If we're being comprehensive, we should include a position with regard to > Curve25519 and Curve448: > > https://tools.ietf.org/html/draft-josefsson-ssh-curves-03 > > I suggest we take the following positions: > > curve25519-sha256    SHOULD > curve448-sha256      SHOULD, or MAY? > > That being said: > > - Given the recent NSA recommendations, it seems to me it would be prudent > to update the Curve25519/Curve448 draft, and to replace the SHA-256 > algorithm with SHA-512 for Curve448. This would create the method > "curve448-sha512" instead of "curve448-sha256". > > Simon, what do you think? Could your draft be updated to do that? > > It seems to me that this would meet the NSA's long-term guidelines, whereas > curve448-sha256 doesn't. I agree that curve448-sha512 is preferable to curve448-sha256, but not for this reason. The NSA's guidance is IMO confused, betting that quantum computers hit some goldilocks zone of "big/fast enough to break DLP for ~256 bit EC groups" but "too small/slow for 384 bit groups" because they've been caught flatfooted by QC developments and don't have real QC-resistant replacements ready yet (not that anyone would trust them if they came from the NSA anwyay). IMO a better justification is: curve448 is a backup against as-yet-unknown attacks on curve25519. Since we're not likely to need it, we might as well pair it with SHA512 as a backup against as-yet-unknown attacks on SHA256. Implementors who support ssh-ed25519 will need to carry SHA512 code around anyway, so the incremental code cost is trivial. The speed cost of a SHA512 hash instead of a SHA256 hash is minuscule. > - If we're going to have text saying SHA-1 is begrudgingly acceptable for > backwards compatibility, we can't simultaneously say that it is "NOT SECURE" > in all caps. Conversely - if we do say it is "NOT SECURE", we can't have a > graceful transition away from SHA-1. We must in that case pursue an > aggressive transition, including condemnation of existing products that use > it. I agree: saying SHA1 is "NOT SECURE" here is overdoing it a little. The justification for abandoning SHA-1 on signatures is that these have a relatively long lifetime during which they can be attacked - O(year). Key exchange hashes have a much smaller temporal window for attack - only as long as an implementation is willing to accept a client that doesn't reply before NEWKEYS - O(minutes). > - Niels has suggested that it's onerous to have so many "MUST" curves. We've > already reduced the number of MUST curves from three (in RFC 5656) to two > (in this draft). I'm not sure that either nistp384 or nistp521 are suitable > candidates for demotion. However, if we make changes here, it seems we > should keep nistp384 as MUST, and demote nistp521 to SHOULD. This is due to > that nistp384 meets current longest-term guidelines; whereas nistp521 seems > to be overkill, and slower. AFAIK nistp521 is quite a bit faster than nistp384 in practice (OpenSSL) because it's been optimised. ~nobody uses nistp384, so it hasn't. $ openssl speed ecdh [...] Doing 256 bit ecdh's for 10s: 45769 256-bit ECDH ops in 9.98s Doing 384 bit ecdh's for 10s: 10505 384-bit ECDH ops in 9.98s Doing 521 bit ecdh's for 10s: 13095 521-bit ECDH ops in 9.98 -d --0-721202717-1455525220=:4613-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 16 22:46:49 2016 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 659ED1ACE9B for ; Tue, 16 Feb 2016 22:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 NE7nvCSl2nfK for ; Tue, 16 Feb 2016 22:46:47 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 2D6371ACDDC for ; Tue, 16 Feb 2016 22:46:47 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0CB068612E; Wed, 17 Feb 2016 06:46:45 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id BB9218611B; Wed, 17 Feb 2016 06:46:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3A5DF8607F for ; Tue, 16 Feb 2016 14:22:30 +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 pSl66RX1sMFZ for ; Tue, 16 Feb 2016 14:22:29 +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 89AFE84CFD for ; Tue, 16 Feb 2016 14:22:29 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Tue, 16 Feb 2016 14:21:55 +0000 Date: Tue, 16 Feb 2016 14:21:55 +0000 Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <469639668-388@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Damien Miller Cc: "Mark D. Baushke" , =?UTF-8?q?Niels_M=C3=B6ller?= , Peter Gutmann , Simon Josefsson , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-UgHCdmr4Nw4NuYd9tFUq" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-UgHCdmr4Nw4NuYd9tFUq Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > same sentence that advice from the NSA is uncritically accepted It's not uncritical acceptance. It's recognition that: - The guidelines are not so unreasonable as to be dismissed out of hand. - Reasonable or not, a large proportion of implementations are going to hav= e to follow them. As long as the guidelines are not unreasonable, implementations that don't = have to follow them are going to want to be compatible with those that do. If the purpose of having "MUST" algorithms is to minimize implementation co= mplexity for widespread interoperability, we ought to "MUST" the most inter= operable algorithms. I'm really not in a position where this is a problem for me, though. I can = implement all the algorithms. The type of person who would ultimately care = is someone who has to implement both ecdh-nistp384, and curve25519-sha256, = on a resource-constrained device, to be compatible with the requirements of= different types of end users. But perhaps this is simply an unavoidable feature of the cryptographic land= scape, that we cannot really avoid at the moment. (And will not be able to,= unless the US government starts to stand up for some kind of civilized pri= nciples, and somehow starts being trustworthy. :-/ ) ----- Original Message ----- From: Damien Miller Sent: Monday, February 15, 2016 03:10 To: denis bider Cc: Mark D. Baushke ; Niels M=C3=B6ller ; Peter Gutmann ; Simon Josefsson ;= ietf-ssh@netbsd.org Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) On Mon, 15 Feb 2016, denis bider wrote: > Being widely implemented is not sufficient for MUST. No, but it is necessary. > curve25519-sha256 has > the unfortunate distinction of being widely deployed right after widespre= ad > recognition of the need for safe curves, but just before the upping of NS= A > recommendations. It's a bit weird to see recognition of safe curves accepted in the same sentence that advice from the NSA is uncritically accepted. Much of the justification from the so-called safe curves is because most people don't trust the NSA to set crypto standards any more. > I intend to implement curve25519-sha256 in Bitvise SSH Server and Client > when not used under FIPS. However, it cannot be available in FIPS mode, > because its crypto is not covered by FIPS 140-2. FIPS has lagged and will always lag current good practice (in which year did it deprecate single-DES?). IMO FIPS compatibility is not a justification to deny inclusion of an algorithm in the MUST set (though it might be a justification for including an algorithm). > I agree that safe curves are most likely superior to the ecdh-nistp > curves, and provide greater safety of implementation. However, it puts > the spec in conflict with reality if we specify a MUST algorithm that > can't be used by a significant proportion of users. MUST specifies what implementations have to support, not what users can/can't use. nistp384/521 is already there for the subset of users who are shackled to NIST-specified algorithms, but there is a very substantial user population who want an alternative and curve25519-sha256 has already proved itself a fine fit. -d = --=-UgHCdmr4Nw4NuYd9tFUq Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > same sentence that advice from the NSA is unc= ritically accepted

It's not uncritical acceptance. It's recognition = that:

- The guidelines are not so unreasonable as to be dismissed ou= t of hand.

- Reasonable or not, a large proportion of implementation= s are going to have to follow them.

As long as the guidelines are no= t unreasonable, implementations that don't have to follow them are going to= want to be compatible with those that do.

If the purpose of having = "MUST" algorithms is to minimize implementation complexity for widespread i= nteroperability, we ought to "MUST" the most interoperable algorithms.
<= br>I'm really not in a position where this is a problem for me, though. I c= an implement all the algorithms. The type of person who would ultimately ca= re is someone who has to implement both ecdh-nistp384, and curve25519-sha25= 6, on a resource-constrained device, to be compatible with the requirements= of different types of end users.

But perhaps this is simply an unav= oidable feature of the cryptographic landscape, that we cannot really avoid= at the moment. (And will not be able to, unless the US government starts t= o stand up for some kind of civilized principles, and somehow starts being = trustworthy. :-/ )


----- Original Message -----
From: Damien = Miller
Sent: Monday, February 15, 2016 03:10
To: denis bider
Cc: M= ark D. Baushke ; Niels M=C3=B6ller ; Peter Gutmann ; Simon Josefsson ; ietf= -ssh@netbsd.org
Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re:= DH group exchange)

On Mon, 15 Feb 2016, denis bider wrote:

&= gt; Being widely implemented is not sufficient for MUST.

No, but it = is necessary.

> curve25519-sha256 has
> the unfortunate dis= tinction of being widely deployed right after widespread
> recognitio= n of the need for safe curves, but just before the upping of NSA
> re= commendations.

It's a bit weird to see recognition of safe curves ac= cepted in the same
sentence that advice from the NSA is uncritically acc= epted. Much of the
justification from the so-called safe curves is becau= se most people don't
trust the NSA to set crypto standards any more.
=
> I intend to implement curve25519-sha256 in Bitvise SSH Server and = Client
> when not used under FIPS. However, it cannot be available in= FIPS mode,
> because its crypto is not covered by FIPS 140-2.
FIPS has lagged and will always lag current good practice (in which
yea= r did it deprecate single-DES?). IMO FIPS compatibility is not a
justifi= cation to deny inclusion of an algorithm in the MUST set (though
it migh= t be a justification for including an algorithm).

> I agree that = safe curves are most likely superior to the ecdh-nistp
> curves, and = provide greater safety of implementation. However, it puts
> the spec= in conflict with reality if we specify a MUST algorithm that
> can't= be used by a significant proportion of users.

MUST specifies what i= mplementations have to support, not what users
can/can't use. nistp384/5= 21 is already there for the subset of users
who are shackled to NIST-spe= cified algorithms, but there is a very
substantial user population who w= ant an alternative and
curve25519-sha256 has already proved itself a fin= e fit.

-d

= --=-UgHCdmr4Nw4NuYd9tFUq-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Feb 20 00:22:08 2016 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 2C4A51A0015 for ; Sat, 20 Feb 2016 00:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] 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 tTxF9-A9LkAu for ; Sat, 20 Feb 2016 00:22:06 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 43AC61A0126 for ; Sat, 20 Feb 2016 00:22:06 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C52DF86347; Sat, 20 Feb 2016 08:22:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 6255F86346; Sat, 20 Feb 2016 08:22:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 26E7385EA9 for ; Sat, 20 Feb 2016 03:28:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id CfO9awTUNLCy for ; Sat, 20 Feb 2016 03:28:32 +0000 (UTC) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0AE0185E9D for ; Sat, 20 Feb 2016 03:28:31 +0000 (UTC) X-AuditID: c618062d-f79dd6d000003091-fb-56c7c0c94428 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 22.6D.12433.9C0C7C65; Sat, 20 Feb 2016 02:26:33 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Fri, 19 Feb 2016 20:43:23 -0500 From: Daniel Migault To: "curdle@ietf.org" CC: "curdle-chairs@ietf.org" , "ietf-ssh@NetBSD.org" Subject: aes-gcm@openssh next step Thread-Topic: aes-gcm@openssh next step Thread-Index: AdFrfobJ1lSZhwDgQH+51/NprQVP+Q== Date: Sat, 20 Feb 2016 01:43:22 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C1121E5F6E@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/related; boundary="_005_2DD56D786E600F45AC6BDE7DA4E8A8C1121E5F6Eeusaamb107erics_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUyuXRPoO7JA8fDDHYf1LKY2bOB2WLrwlnM Fh/uPWZzYPZYsuQnk8fChz2MAUxRXDYpqTmZZalF+nYJXBm/J2UXPPrLWHGp9wRzA+ObT4xd jJwcEgImEtu3TGWDsMUkLtxbD2RzcQgJHGGUeNI9hRHCWc4oMeXobHaQKjYBI4m2Q/1gtoiA usSJQztYuxg5OJgFUiQ2Xk8CCQsLKEu8vXwOqkRD4t+cy2wQtp7EpvstTCDlLAKqEuveF4KE eQV8JZ73LmMFsRmBbvh+ag0TiM0sIC5x68l8JojbRCQeXjwNdaeoxMvH/1ghbCWJj7/ns0PU dzNKrG7LgZgpKHFy5hOWCYzCs5CMmoWkbBaSMoh4vsTyT8eZIWwdiQW7P7FB2NoSyxa+Zoax zxx4zIQpriOx+dJOqDmKEm2ds4FquIDspYwSrR8OMMEUtbU1M8IUTel+yA4TX9o2DWgZB1i8 604ZRO8yRok9C3ayQsR1JHYsDkXWuoBRaBUjR2lxQU5uupHBJkZg2jgmwaa7g/H+dM9DjAIc jEo8vAZpx8OEWBPLiitzDzGqALU+2rD6AqMUS15+XqqSCC/HQqA0b0piZVVqUX58UWlOavEh RmkOFiVx3qUO68OEBNITS1KzU1MLUotgskwcnFINjB36B5S+30qbnvbEVIxV4pasCEtJ5p6a sI9BLIsrdy5aEn1czyloGX/mKc8f745N+NWoZCxx15ll69W4fc3bJm7NfWF+6Ob/jpttL97y rU0XkT4p+u/h1olNxxkX1rzjULv4+O1Tl+/3rrit6pW8uqjA8JLO3sfPekpCn6iJPbr7+KB/ 6ItEXyklluKMREMt5qLiRAB++YcWIwMAAA== Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --_005_2DD56D786E600F45AC6BDE7DA4E8A8C1121E5F6Eeusaamb107erics_ Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C1121E5F6Eeusaamb107erics_" --_000_2DD56D786E600F45AC6BDE7DA4E8A8C1121E5F6Eeusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A few discussion have been raised around ea-gcm@openssh, suggesting some ad= ditional work should be done. We would like to understand if there is a con= sensus on what should be achieved. BR, Daniel [Ericsson] DANIEL MIGAULT Researcher Research Ericsson 8500 Boulevard Decarie H4P 2N2 Montreal, Canada Phone +1 514 345 7900 46628 Mobile +1 514 452 2160 daniel.migault@ericsson.com www.ericsson.com [http://www.ericsson.com/current_campaign] Legal entity: Ericsson Canada Inc., registered office in Montreal. This Com= munication is Confidential. We only send and receive email on the basis of = the terms set out at www.ericsson.com/email_disclaimer --_000_2DD56D786E600F45AC6BDE7DA4E8A8C1121E5F6Eeusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A few discussion have been raised around ea-gcm@open= ssh, suggesting some additional work should be done. We would like to under= stand if there is a consensus on what should be achieved.

 

BR,

Daniel

 

 

=

DANIEL MIGAULT
Researcher
Research


Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
daniel.migault@ericsson.com
www.ericsson.com



3D"http://www.ericsson.com/current_campaign"

 

Legal entity: Ericsson Canad= a Inc., registered office in Montreal. This Communication is Confidential. = We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C1121E5F6Eeusaamb107erics_-- --_005_2DD56D786E600F45AC6BDE7DA4E8A8C1121E5F6Eeusaamb107erics_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2367; creation-date="Sat, 20 Feb 2016 01:43:21 GMT"; modification-date="Sat, 20 Feb 2016 01:43:21 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhRAA8APcAAAIVTgAWUwAWVAQWTwUWUAcXUQkYUgAbUwAbVAoZUwAcVQEdVgMeVwQeWAYf WQAhWQAiWgggWgAjWwAjXAAkXQAlXgEmXwInYAAoYAQnYQApYQAqYQArYgArYwAsZAAuZg0sYA4t YRAtYREuYgQyZAUyZRMvYwczZhQwZAk0ZxYxZQs1aA42ahE3axI4bBQ5bQY9cBU6bgk+cRc7bxg8 cBo9cRo/bRw/bh1Abx5BcB9CcSFDciJEcyNFdCRGdSVHdiZHdylJeStLeyxMfC1NfS5Ofi9Pfy5Q ejBQgC9RezBSfDhQfDFTfTJUfjNUfzRVgDVWgTZXgjdYgzlZhDpahTtbhjxchz1diD5eiT9fikVe hUZfhkFhjEdgh0hhiEljiUtki0xljE1mjU5njk9oj1BpkFFqkVJrklNsk1VulVZvlk9xl1dwl1hx mF1xlFdzlFh0lV9zlll1lmB0l1p2l2F1mGJ2mV56m2V5nF97nGB8nWF9nmJ+n2N/oGSAoWWBomaC o2eDpGyDoG6CpmiEpW2EoW6Fom+Go3aFo3CHpHGIpXKJpnOKp3SMqHWNqXePrHiQrXmRrnqSr3uT sHyUsX6Ws3+XtISYr4easoibs4mctIqdtYueto2guI6huY+iupCjvJKlvZOmvpSnwJmou5WpwZqp vJuqvZyrvp2sv56twJ+uwaCvwqGww6KxxaOyxqS0x6W1yKa2yai4y6m5zKu6zay7zq28z7C8yq69 0bG9y6++0rK+zLO/zbTAzrXBz7bC0LjD0bnE0rrG07vH1bzI1r3J177K2L/L2cDM2sHN28PP3cfP 18TQ3sjQ2MbS4MrS28fT4cvT3MzV3c3W3s7X38/Y4NDZ4dLa4tPb5NTc5dXd5tbe59fg6Nni6trj 69vk7N/k5t3l7uDl6OHm6eLn6uPo6+Tp7OXq7ebs7uft7+nu8Orv8uvw8+zx9O3y9e7z9u/19/D2 +PL3+fP4+/T5/PX6/fb7/vn7+Pz6/vr8+ff9//v9+vn+//z/+/7//CH+EUNyZWF0ZWQgd2l0aCBH SU1QACwAAAAARAA8AAAI/gD/CRxIsKDBgwgN8tOnb1/ChxAjSjR4792vMyAaBLllb6LHjxDtvau2 SMYBCRYsSHAwSx/IlyD5ufMWCkqDBihTppQghB3MnxDhgbPVhsNJnUhTHigHtCnBeuCMKcpRAGfS qxLMOW1qTpmmKQ+OXr16oIu7rS/fPSOlhsQBB2OxPmiAwxg/tB6xtfLTo4HYuDolHOBQZI4xvBPf XYpiNCfgnQ0e5FDDyRniifUuSbD6OKWDAyPAVArW7rJHcSMcAxYcwUkjW99Mf9xnrMDjzQVw8JGF jR5BcrFMKZP90BmBuBEKcCCTSprPgfhs6VFCw8UOQfCIH0SX4wFSwQ2Y/lxqppWgNEdOaHCQwB7l Jd/aCe7D1fhBgheBjJWDL5AdqCo1iMBeUhLIoE58Bd3TjB9VuCELOfEUpEsaNJCgEmAFMIVgQfPA I49LA1mDSA4krNeZBBycs+FD7ISCxAgcdIbUAXRkt2JB9ghjhoUyJuWAEN7cONA+2zByg2o9pkSE J+/849CN6tDhAJKdZcCBDH5UIyRB8exxQJIpgeACGLR0tCVB3nh3ogQeuLBEJuQQdI+ZQvIzjG1x sZeBC0EEMtxA/LCjVyjGPHejNF8SyF4KQLARC53/vIONLGp8UMABB7wxjpDvQCHWSh70EEYnQQ5k Tze9HLLDAZxZMIAi/vPcyE8yRGxw0g1bOIJMQeQIcwkVglEpwQjobIlNJHksQstZA7mDzCdosFDA lBhqeCZB/FBTyh1A3EQlgSykc+1A5LQSyBMctHrbAZLwJ2Q9vjSiRQsOUHuiAwWQ8EexW5pjSRg7 WKDuaic5QckvTW5JDRMj2HuiXzQAYss29Vz7DhYD53nABmawgg2z41rTgIybHZDEJtio8+S4//Aj TKIasyAIM+tUzHJB3IyMFU5j0MKOuzcT9M4aMKv04ybl2HNX0AmZ4wVOErTQxzT5MD3RPWsFI4/V XHft9ddghy322GSX7dEywQijtjDBxDlN2mofwy87vhyjokDY0GLK/iq9lOPQpHsHc6A+zrRSCivI xPqPOr2ggoovB0aaTDDBiPvP29XwM0YOO8hQgwwvrPKPHTjkUEMNQZiRzD/HvOBELf+0s8kUKTwg QQqb/GPKFCVE1kMw9GxSRGNRxKYMG0dKcMMbu2KTBQ41bFIxHTfwYY8QDYiQRRVURGHLP1oc0AIX UWz2xD++DMACK/9cwgEBOdThhxOVYEMvEIoYQscww3DgQBSM4MMdypEOKEwpDnBYyRTQQY0c+GUH 0vhHFQ4ghnoYwQFGqAc60GGOefDDCwcAAzbScYSU/OMXBXCBLKghgwJQIRjskNQ5VpEBC/xBIOpg hycEMAJR/OMe/kzJBAcisAh1nCMRBxCBJrbhgwgIZhL/6IIDyGDBCMhAE5SQhCa48Q8QXoF/MpAA E05YgBe04hVfCkVBlIGSHNhhFaVhBQEyIIRA3EIgX9iABO7mDfaYoRs94MALOHADcnxhihZ0TNRg 5wUHiEAGNLAAEbpBxhekAhQDeEEuCqIPQfglaleYRjrQgKkNvKAN9mCCBFjwJHfAoAFYwEYg8xAF AnwCChGgohGixgc7zAEQ0+jiA1RghBiNQEUoNGMqBAACWRjkHccgxAxs54Z/rMMWcuhdA4YBhZSY yR0ecAAXACmBVFRCAjt4gQR0+YAx3uMeDtkHCKngDVGs5xJk/lRh/xrABkMRxB7heIEDoECQVdCA AKawAwgcsMl/7GIwg+jGDspJjiRIIAPrTKQLAKEHPcBBGF08QBbaUQ8VWAAI+WyFPNxgGydcYhWH +MQ3xtAJW1BCJWrABhlKYYs0cGAAtaBGCSQAg1UYVAIzkAY2JjqKf0ACBBLIZT2w1x4JFIAT/8gC Aaqwjn+kQQIbUEYw1Ce6bogBJ1ZyAB6SwYG2YvQG1ODFANq6gQR8IU6mWE9bh3WKfzijO2osRxFu UsFWcKITiO3EJYLJikasIlbSmMQkhvENRmRCS/+wxzAKcQYy+MEY6thEHMighkyo6BuRaMMY4rAK kHXDEWY4FUMkKPkPc3giEtEQyC4o4YhX3CMgAAA7 --_005_2DD56D786E600F45AC6BDE7DA4E8A8C1121E5F6Eeusaamb107erics_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=15442; creation-date="Sat, 20 Feb 2016 01:43:22 GMT"; modification-date="Sat, 20 Feb 2016 01:43:22 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh9AFQAPcAAFpEOQcGBnKJroVVTrmHkrm5uWpqanx8fJOpx6x7iSUnNtHR0WJKQGhCOjY3 R42MjWhSR8XFxhUaKenp6RYpSbjE17uftwJutjQkG0JCQlQ9MpdmZkRFVKZzeKa0ykI8SjpBWGQ6 MntWVhoiNp2dnQaMy83Y5jlGZGRdaSQiI0tXdSohG3ZMRXeEmnZUTFhYWFVadlhWaERKYpWkvEUn GUs1KARUjVhnhmdyihoRDEgyJCk3VWd5ljsxKzIpJSsySDY8USojIRMREUg5MqSioTJYjG1YT0Qt ISIdGlE5LLK5xoqVqZqeqxwaHCMZExaBu93d3TItKzIyMlhheay60WRjemRrhHWn04djZVCQyUZ0 riwqLaurq6OquAZGeUtTbCIrQiNEdoCVtoZcX0UwJHF5izsqIbbL5hgVE1RFRxc1YnBHPWuZySEi LTw7PpJgXVw6LC1CaExihiuW0ICIlvX19UIzK1AzIyU9ZLS/0wB6wiocFHhrabuTn09IVTMzPWx+ pEVag0hnl9bV1U43KzR5sJl1ejNJclEzKlOEuzAtNBITHXZhWQ0LCjpSfL/K2ZuIiYZ0d9bX2x8e Il50mgoLDx4UDqimpY1nbz40L6OmrXF9lnhicDctKCwtOzUdFM24vODf4J1rcK+xuLqvr9FkgFNr kIGMohwYFjw0PCclLZOSk4224S0nJaeuwS8lIFROYg0PG+Tk5lg2LSAWEF00I+Ln78Guukae0Ccd GHJthkNObxcVG5Kfsjpkn8bS4m5KUIJvbuvt8Obp7jYZDg8OD+Dk69fa4PHu7WsmLmQ/MdvZ1x4w UtrX1kIqLlo3J/n5+tPV1y8mLCYmJzU2OBcXGK+pp08fJFU3J0QSGFRQUiMNBz0lHEpNXkk+PTgO Ej4hE////9XV09PT0zg3NgBfo7++wKCWlRFjn5qXoTEwQ9TT0tXT1e/x93JydaulrczKypCVn08t KabA3ClOgpE4PjxObVo/MjAKDIODv09uoSUXFw0fOuvl54WewQAAACH/C1hNUCBEYXRhWE1QPD94 cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1w bWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS42 LWMxMTEgNzkuMTU4MzI1LCAyMDE1LzA5LzEwLTAxOjEwOjIwICAgICAgICAiPiA8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAv MS4wLyIgeG1wTU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOmE4YWU0MjY1LWM5MGItNDZm My1hZDI4LWZiODE4YmVhZjcyYiIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpDRTIzRDZGQkM5 MTAxMUU1OTE3MjhDMzMzNUIzQjc2OCIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpDRTIzRDZG QUM5MTAxMUU1OTE3MjhDMzMzNUIzQjc2OCIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3No b3AgQ0MgMjAxNSAoTWFjaW50b3NoKSI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5j ZUlEPSJ4bXAuaWlkOmRhNGU4MzA5LWEzZjAtNDJmNi1hYjc0LTFjMzZlOTA0ZGZmMiIgc3RSZWY6 ZG9jdW1lbnRJRD0iYWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmI3YmMxNTRhLWIyMmUtMTE3OC1iMGJi LWM0ZTZkNzM2YmVmZiIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0 YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk4+Lh4N/e 3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+urayrqqmop6al pKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNycXBvbm1s a2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5ODc2NTQz MjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEAACH5BAAA AAAALAAAAAD0AVAAAAj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDMODPCPY4CPID82CtCo pMlGxVIKWckSjcuXqGI6QYXECZKbuZDkoiUkh8+fQIP6tESUKC0nR53sWbp0xacVKzBgeEULlQYN hO5gw/YshLKvXxuIbbBmjVhlIeA82ypPBw1u3MBhAEeDxp0jOu5wy3Hy0xEaSZQR0kG4cGEyZHQg Xrz4iOPHRzRKnky5suXLmDNrxugxZMiRJ0umVMkyh5CXaGKqtmlTJ85cqEwLnQ20KK3bTnIzbfpU qtROSABgzat1FpwQIcSWXc4CmFg4s2YhOgJ3rtRP4MwQv3PXUskcxO48/6NxBM5gw+gRK2aM+Eh7 x2Y2y59Pv779+/gZeuzomSTJ0MWgRNpKqLmkGipONNGaayvkAptstNFmCS0T3kbLHkox5VRUUq1Q gwgreAMAGdyQdwciximjHAtrsOCCCCww0MA9sxAyix3O5OgYXHXlRZwOtJTkBHezUHdPDTogiSR6 hrHXHhmQ5SfllFRWaeWVnfXnH4CjsdRTgQcmuKBruaxQExoRSmiUhbrttqFvGBxxDwZDaOADBp9g wM0RKN6zBjAsuPjiGCKIAAwwDKQBTBppzKgBIpAiohV33B0R5DbccHePDkdoUMOnSRa2ZJPrsRfl laimquqqrOrXEX+egf/GZTFenobagU3QdBNOSJgJlRMQRmhJbWvilqGGvcFJhh1DAGCGnhiY4Qwi 99wDjAsvFjoGJphwwkmhInBCKDBmwQGdudhQyl2QToBDjDwMEIIIIZ/WC2qo6RHm5GOt9uvvvwDT l2Ws/4k2Gq0t2ZragUjoumuZUKWwAipozkaUxRUae+weK3CcJ5xm2JEEA0O4N4sGDQDQAAPXikDo GFhwi8UYY3DC7bgNhBDdLPdAly5Xd1iyDXbgyANAEvYmnaSSTJbKmGMBRy311FQ/NPBnlZx0sJe3 qpbrrmD3KjFUSAT707Booz1Uxrm12dQeGHAo1bNkDMEAAPegTNahzbn/6DK3mMzssiGGYAGjWTpH h+JWWqVrSbt0yfNoDYTQm3S9+KbnJJRVd+755/9eDVJoAiLMNUwMh43E2BIHYWbFteWg9uwZ47Zb U3HDCW3IDPTulXIvHrqGCzAHLgIEwHCrLSYiiDWLPEfII8+kQOtJAzHEgIONDvN+arnlSjftNOeg l2/++feJvqVJW59uIMNNqA6V60HU7wTsadN+sW1HJbXxUx8DmRnM0DsAMEBFZAnXGJwzPBEwAkZi +RagtgUMnckjLjTIy8/gsL2/EGMbNMDGESpHr8pdDlRLGpW+2IO+FrrwhRpR3/oMNiACuaQaXmtC /MAmsdbVr35IGJbs/4a4v6LMzkL+cxPcdBetAZpBAwyoVs7I4q1DwUEZLXIBouBwD7GEoFHAeB4Z PrEPuzROKxy8gw4+SBfyYIOE4AOfvQijwhUuBoZ4zKMeFyLDRmSNhqZTGBpwGBMdhi0FYvthEF4R hAfJzoiQjCQS23a7N/nmWU7UADDugQg7ROeL3viAM8SzN7MkAREhIOM+eDEJXuwjCDnwi3i2spU0 6gAfdAEHOHSQBDiWUI5KY1qTELPHYhoTj33UWpdOVw1CosKQN5nE6laQAh+2ohWMnNgjI8nNYlFy NxhYIsi44UQ7QIABd9jDPnKxD1oUgyh8UpFZGoAIMszCGXCRhjTYmf8neSDCXM9YC7q210ZwHKGX vjQhME84TGIe86EQBd1HYBWSP5YukKghZPx2uKseKhKb15wYGrpJUjZ9k2Nwk1u0mjhAMvQOG5/4 yT728QliHAEbV2wAWuBwInm8BS7OiN4svnJFZZiLi+k6gi7pQogkODWhvzyhMO1Ihoha9aoBU5+s /Ng+AlVjkBo1pDSr6dFpXPOsrZiYbUgKSZNiCFkqXakTB6gBCCjjLuCoKTE+QQN5POM4aTEXpBSH IsAi8CzK6FkaaeAugzq1lwhNKOXqBcx8VRWrmM1sqtRn0YNhFKw4NOQOEUnWH6LVB2lFxVopdJtu IjEpStQdJudqhhr/QECnarnLEWapFq+oRaAIPOxYlgOWe6RLB9qryx0eG1lfUk6hJZzjMDVL3eri R6skyVpXT/PVZj7zmUiQ5lirWT+0tsIH6A2Cal+LRG6aVCkZcgoTZzvAI5iBDBBggU6N6hWimmun AIUDWVoUqAIHqizFPa48dKoB5kIWqs4NX3qsS+EKa4az7FumDZsZWmiOl7zTMOtZt5De+7G3vW11 69ugIlvaPoYBLliOjMHyjFoE9L/JWcMADDyAHbNoDQm+AyEAcLIGM7epD4awCTFXRx1Y+MlQzohW /QhIrnG4GjoU6+pKG+IR+yAKUfBBEJDApv6x14jvPRZUAihXJ9rX/z33cMGPW0RnINu4FngWcFlc 1OMeGxjIZjGqGglhZAc/tnLNlSz4MqevKDv60RGZsnY1zF0cYnmjY91yCoLQCrNuoRUkBnMUgjCT oyCoba9Fc//c1rH5utg9ZCDEgXnMIqPWQhk1fkYDWCCCPvvaz8uZEQd5mYQGF/rIT30qVCWcmMRA +tnQPojo/BiArFWC0t1tZpY3Gl4um3UaPgi1qMfsv7blxsytZRur2UxO2jLGDjqAMQt+PYCiIjgE Na6FCDaAiTe8YQP+foOfa62MXuogb1fRAByMfGxDJ3nJmENPtCc+cS3JatKmQ4MQrvzMLIdX00H4 9qejsAVRR6EVDf8zt8qRYiFvuo1jKnXxYuzwKQD4OuBjuLWv13CHuoTAEAnogNA7sAGAA1vYiBhZ tZaO8IQnvNgNVzbE8YUkilv90aKrRLWrvJJFbJzDWRbvJMiagi5fs+QmPzlsVr7ylpfbTS12ImLs sKznJsEFAS860ZUxgH8bnQXKwHMHEkCAwged6AIP1IxOyYBzAuDxeGO60ydvaBJeLlRXz3yFOfKq /lj7oszUtse7TdYufxrtYJbCyWvihFy0nu3nZi1S2tTqmNf3vvCmOSGGUGwG9H0DohC6KP49+D4k YAMsADgLOlD4PhRe+AKP8eIREQQHGKF3BYT8PSLP9KZD/dAQt5f/5sdv3az/59oargYvwB728I4d xJ5GfRSkoHof3CQ3rs8/29Osobjftwd1Rzm8dxUAwAj/FnwdQDj/RgB90AEDsAYbIHQJQHh94HwE 0AHDNwZytnhkkAMZUAZGsAbYJyOQ93jd13RPJ3XQVQPk14KaNW3W1j4aB1rb5n7vt2mmtwVoR3/0 l1Y14SCtB4RAaG5vpyEccif11QnLogPMsntQdxUQgAV6J3x9N3hAlwCiAHzM13wEEHTDNwBaNCPU Fwsc4A58AAFoOILZhzdsWC0agIJXoYIl5IJ0GFHmZxLoF0hXdmlNMAl9SHZlF3+ixoM9oHpmEoQO kohDiGrm1n9S//EKLBUyATgEhEaAkGeAWkh0MTYAG2AIWTgGPbYBE8iAXYiBiccCRHYEucBKbqAN jICGaTiCJbh9kfeGcFhsCIVQdbiLD3U1WheDtIIwXndlHjcJxlh6IXZ6JceDUkAO5BAFZqKI0rgH i9g2uWCEUQGJc9UDdtCNNcB7daIBkNc7UUh8ojAGa4Bn6vg7LRKBhXeBnygCMTYLOvAJQmAJQrAF 1AAB2AKL5ySLJWiC4uiGKdhgTUUIvJiQeTRlJZGHpkOMOuSHN1hNObiD9OeMbtADjaQT0iiNr6cb 1wgxjxiJZACANDcE4SiOj4d9EMAIYwB859giPVYPbwCKB7ZvzP93eBswBs3BSdwQJCgxDVuQBozQ j/6IfQYUkNu3lHBobISmkFAJQ1lXCQ6ZcewXkTcYYkLpaVGgCPPHg+TgBlLwChyZiA0yja7XetQI c1MhFT5gBp1gBiZ5kilZguTYksHwksxzKA0wAGOQAJhQQQ1QQQwQgV4ocM4xCzRACzmwDxo3CVGg AYzACEZgBC5wlEh5NwH5eG/4dE6XBFEZmuZzhw2pYet3lcaYlRXZlTxIDc5IDj3QCmYJMWXSkfl3 jSzWlk4EgNzYhAMoIit5l0bwAEsAMzTjAiFwDcp5Dd+AD9+QDdcgD8AwBgh4jqh4T3vQCLKDBk3A C1uQCZM5AJX/eZmwqIabaYLCMXnh2C8ZYADTcD7uqRkvkAGtEp8J0Z7vmR8vkJ8PYZ+RlgEZUFHV BowIo3EQ2QQGoA2qmYw66JVgGZbkIAVp5SANAhUVWpvTaKGvAIlv2QlHYABG4I0oqQHAGZx3yQgz sASwQDw0YyjJ8KIwihzTWXSiMHyJeQR7sA2iYQna4A4Z4AOTOZmVaZmYiZSbuX2Tl3AVcQBQgBDT MAHhEKVSGg4R8AJTeqVU+g/TQAJ1IKUTQAIHEQFYOqUvcAATgBBcUAAC8aRX+qUE8QJ1sAD8ORAZ MAH0iRAGsABe+gAEYQBdOqVQcAAEQQJjGg4vUBBcEKV8KhBi/1qohloQdXqnfnqlEbCoA9GoV1oH BgEF4VAHh1oQW/qn4eCmBxGpAvEA4cAFB8Gk/0Cojgqm/5ABmEqqCpGne0oQXKCqCLEFXPCndcAF W/ARWeOqgLoKXyd6iRoOq4CM0zAKo1ByitCarhmWY+kOohqlofAAtEkEhWoA0RKXPUAKUUoC35hw AFAABWBAI2gEfGAO7XAKyVqooLAB/dAHMGMIyDCmEVASncClXkoKWFCUQ+oCRlCe/1hAmhmQ4tiZ V1ERhIqn4VAAJDCxFOueFEsCenqxBvAPC1AHJGAABnAABRAOsNqnFxsOC3CxWxoOCLEACyAQBhCx FzuyLysQhP/6qwYRsxt7EKi6AAcQsiOrpjZLshebsQOxAF96sRM7pxlAshGgqTB7silLsXP6Dzo7 tErLqXI6ECirtCRgqacaDmYaAQbRsR8LtCR7EFfLsV0qqAXxsBlwsROQtBNLn3A6AQ8AskGrED37 syIbsUdbswYxDVDgsSDLpaEQrNWGtBRLBCQwsiRAjNoQDkQAD3VAkVopDuKwBQ5Kf9PqBhHaCtxK BKRLuutAuRYqDhNQuqzrDR3aCUYQDpdguSMKnMuwDCvJrg+gCUpgAuHQArpAAkRgDaSADMhwC6CQ vAQgCuEACpiwAecQDvBACtZgDaRLAnzwEeNQB0RwAGXwAOb/EA7LQALBILADW7CxiLDnKRzsqwEO y7JqGw47qxAPSxAHIL+QyhBpO6jwW7Y1u7YDEbOLSqiEOr8wi785u78DgapuW7/8e6cuyxBcOg1N C7ZcW7Lxu7MOHMB1QLYCocAJEcGoeqcCcb8GHKsQu7Mu+7RVu8ECEcEEMQ0dXBBWisF9CsL/wMAv LLgFgbRbACtbMAELUG0BMA4L4FlCQKjUsH46RAR10IrKqpVCKQ6DMH/RepEYmZGiGw4WaqHcqg1Q obkVmo2vsJs9cAl1wAAoQLIqKRy3awTuEA+j4AEVQAWu4LstEAMpIASNwA23SzM1+W/Q4LxYEL2Q cA/yEFMj/0ES9+sOEhALI6AOf0AHHsAKVEC+AkuwEIC+B3s3nqywnAkA75vCEty/QzsROOzCgXvA J/wPUODBD4u0cwrABAEFPDwQBaCrqjwN+wvDCjEBQuvLBIHDBbG2qpzDj/oPxAyp4cCnMozBx0zK HCunM8y//vu2dVC1rZrNB2HLB5HLO5zBnfcRMesOJLEA45CHK+EO4eAOYAfMxrgO0RCIQjkI0bCM rZnF5LDFXfwKIYK6KyDGULGhr4BecsmNwmAOvNcMy+AN4uiKoRAKveABCOAKvZAHvdC7vzsFf5AK 0hAA69AMIuBvNNq8AgcJ0AAJzvAJ26CjiwAEMqAJ4bAIsf9QCRJQCdUwBVSQBQggBlSgBOcQDAVL sOSZvp+8vqJMEdFMywjhwiMsEalsygQBw0w9zaecATgbwAgcw828EMfcy7dsEPf7qU9dEMus1Ros 1QPhsR9swwbRq7h8pgscDiS8EGsbwffrtqfcw7cMBULLzHo9ELxswdf81nI9MBPABX7ksu1zv36g bfeLAmO3CuGgDQwaDeJwxQ/qBpydCfy8Av4c2pQ7FesgDizGoR3KjajKBw5NqJFgALvrCsJgC0rg AVTQCzPQ03nwCxvNARKgCqpgxBjgAjTaAc1LKJAQDpEADtuQA5MgA44QBztA2RzwD5AsASPwBQKg BR5ACR7/cAZn8Aia8AB8gL5FrYYJu5mjfBBW+qn0K9UyjLfarBBR3bL/u9VrmtX1W8BoncCt/LZq HbNuGwEenBARINcCkdXD7NY3nNYt68FsrRB18NdWqtfx/QDzXcwIDMMsPBCqLMzKzOAh7t8LAeLh PM4fgc7nnM5dggKhMA5g1QTwMAGpmQJ1MApauQXiEA2s6bmuydmgy8+uQ9Ds/AD+DA/wQMboBa7d CA/CoAF1ggLQIAkZjQBKMAzDoAT+oARi4A8C4Ap3HA6nAAOeEAAj8AKSMAiNmXw12rwwEgnyuw1C AASHsAM7AAaLoAh1gLeKAAZgIAFxIAZs8AtisAQIkAhU/yAAeVAB/oC9/mjUR12C683eEeCylr4A FqzKGaCndRC3gZ0Q9X0QVI3f0/C0d+rAldrfGm7AD0Cxpy7VLwAFTerhl77C+dm0GFwAs77gtYrA 0QzD01AAtb4AuorM7v0PiU0Qm96pnp4Qd12zhOveH37LZ03MtNzqdXvifC0QA+OyIzEO+koNYDW5 RNCHY2cOUMCgVKzZUvC5nL3P3LpIBG0AET0VG0oE4lDag6C58JAG3LjG1jAEaXAAvRAKwtAFMzAD o2AMwlDRrnAKAiAAXO67S2APHxELL9APUCADI7AP8rAGIhAOpAAMAOAMjBAB7CAJKq/y8TAClcAB nN4N4//9BUugBb1wA1MgAInwCAJABWfACibgDw8QCY+O3kkJeZMOqns+7Jmu1gKRAXzK6Z9uEKFe 2DG7p1yq1xvMBbBa1QBspV46tFIKBS8QAWTv4Shb6xGQn4T6syD79lQv4qy814XdscNe7Ej79iB7 AHX99FHfqVNvtRvOwz5L96vM6wdh7VsN9lEq1yZu1SgeAC5LlYw7sY47sqvAYUQADQ/gDu5wAJ5/ ADm+71sgrVkMuj7ArWNvAPAABQZA0NyquYMw++LQ791oDcr6AF1gDh6gBK4wCv7gAUvA8GIg/IU+ 0f4QDeGwBDIgrEJwDKEABidwAj/QBo1AudyAAVKw55L/cAzRIAnRwA6rUAxaVwwcsApgoPx1oAmH MAUnYAUIwAZB7/Ns8AiAgADzIABnWKTqCxAAAPwjWNDgQYQkwiEkaCCcAYYHFUY0mCHCQ4r/wpGQ uJDhggUNwxUgQeLig2kGJxZUCNEhxIMvGa5UWJIElDowC4LMOCHcT6A/uRzcmFHmv5UIF0QgWDRi hqBRD1C0iDGmVZ4FI9RJmXRnSINOEYoteLQjwawHswb4F8BtAJCNGoEsVreYECEK/aCp5jPqz1HT tmwRN0iRFMTUqJEj58YxuVZEwhGhHKrOgVeZM4sTl9mHDzOdOvWwM8Tv32MzRgEaJsyfEkAzTnUR MwNe/7hNIwLEWgQ32qJFYQIFOrExQCM+4eic8ARkh4RFlWJNjyVEgjogMW63wGGPzrwrv1qc8lfI g75erFhV0AXBvXsG8eUDYDAwY0avBs1SzE9xQoGMyPrngXBSQgiKof4xq4BwXlDJo50mmGY/gqYJ 54GZPEpqGigkNCgthA640AASS1Qog7A4ouio/giqQ0UBDeIipxJLjGCC+/5D6CgQp6mDqf5A/AcK ABGCaqqDLMQwIY+EJIgLHNtq660JuAigkgXGqcQuvISYrBoRV3FnTHcOcEeyFwQbRJzDElPMMTcy gEyyIDLzJpQJvPHslcI86yQ00uwgkAsllNBECQ9cWf8gHCV6aUEYWxDoBZAuWnBFDCYeCaebWHjh QJtJxonGk1iYwWOXHcJ5J4dt3AmnhRN+AIGCHYBQhwMJRhhhEQnAAEKVNoSp4BQeenmEDQ/kmEIQ epaQA4EzWMmDkkjee08+bO/DD8KrdOKP24ycTPEgqJas6EKRvMUJRYLyy6AOLigkCAqwDioALK/e heLDehEqIMok4R13RataJNBBjVRkSMcdw0EyIid57PcfEQ8IcuIZDVSJK4boZehetCYmSEQD2Hor gJfkAmlLLr0koZoChGmiiUlqTiEFN+oIbItoxEHMzcbidGPOcDR75YU6QnnFh6X7/Ey0QIcwB5kq Wlj/ooxTxFiiC2iOEaAXSJU4ZewZxNBa00oWaQMFFLYYZxxPFhmBHxnUCccVB7YRsYUdQACCAmY4 OOCAD34AYhEFwPhBlT+OSW2TU2bwBQcwOKBHnxn0iSBaBOTwpz1rIcA2Pm2/jUheJmNSuKAXYhzY oALqQLjCA8zdz0coDOyvJqsOEnF1BdFFClyHivxH3H8sBL6g2F9niEVwFRS4qeVHbjCiCZgyYPnW l5cYoa24iF7Id5kyqPUEQxTQoSWR73ALgtzaYoJQKrly5ZYVcoeajWameZKbTcMcXOEZm4AGpwzI KTJF25OIzPEZH6wJgmboQaC0EY5RnGI8PDjFEpbQ/4tj1IEHo7CFLVYDCCZ0wYP20EQ4KpErIIxA FdFgxx9GAAZ+/GAE4ejCD/5wCuXsAAy7UMMJuqGLA9CBCG2QgCdGYENXeSAeKqgCDpjhgEl0gx5s qIAYTJAIOcBABWLwxwOMEDrRyad0EamJTWwyoZG4sSTeGp7vwlElE9UhdwFaHodeRKIHTKAO+ukd QZBWpBYtqpAGIdACpvIC8RmvPwRq3wTkWJJpKERjB2ndw1xXloIVyI1QCMcCNFbKS2IoAvtiY4FE hEcSkUCPm0xXyBDio58oRWQH0COGMsAgkTGylI+MZIQuyZEMCJIEg5HlBDLQiOOA5AVEKAkRGDQO NP8ohBwzqxkAUwBHlAxiApfQxCXMyYVLOCYDQ1ugZj7zinOE4xyfEcc4iWBOfKbBGsoZzxLo4KgW UGIGPOyCMerwiDyYIwJKGIUmYqEQxIHhA5NQRDTg1gYHUAAIEgjHJUZgDyCaQxOa6AJJNXGAbtDh jqMw0wGIUAdZyAEHIODACZhBDQlYIRHzoII/EKCGLeSUEgIQwxTOeK00MmCNz6vDXy40jdMEZWIH YGVF/gWUOhSAlgd6mEEy2dSfFIBdBEnmWAvygEFSrKoVmcAeI0LVh9xxdVT9mPkU4lQDRMB4H1EY FLpqJGcSJJB3/UkEzEWQi/yFK3U4bMAc9MvTZHX/q/8o65PSZxBe7tWyDHnBRahqSW3B1SGgZYlT w4GiacSOCzMqQBTe0ogCFCCxP7EkNaqhV/91E4DTmMY4iLCFS5gWBXFS4AOUxjQI+sAc8PhMcJ16 AHjAgwd0aEE8PgiCD8QhEMdQghgqYNqUhoIXihgBFjkwilFMogl/k8EHoPAALX5BGE6NhgL4gQJz RNYcMGDGCzxBjR+AAQwyoMIVHiEGQHxBFYYDhC+IagpGoBE+S6VwhY1iVgtXZHYZ5nCHPfxhEHfY ABgOcYlNHL8pvaUSK15xI1omhGrEuBrctFkAeTuYNilmMQhMIDl8EIQ6LS25yTXD00ZDmkwM4QV0 /+ABDhw1th2MwHAgkMENBHGKKfSCB8yYRDG2IENVqOJv3VAAB+IABE94ihkgcMAiPnCIOJxADTJo gwLmFrdJeIIfnmhCG/7gjhhIQBFAAIMfJjGNEYAABFaYgRaoAIgTbEERFLACD4ogCAFQogpGOCp8 RHdiUIda1KMmdalNfWpUo/hkJ5MLy+rSJRnP+H/e5K1gcOwmavC4x1vITCuG7INOgCbYwx5NJuyQ iTRsogVl4CAOWtACK4DBAWDwhCdO4AgrqKAXmT5cRoHgAAeoAA8x8ERNd5CKWKgDDDtwQBvkcAhP oAoE1wEDBRzQxB9QgAMAVIAEtjDejIJgEjbsBv8IYiCGRHhAEApIgQRA0AJfOAIIQJApJyDQ6Qmn WuMb53jHPf5xjZts1farRCNcfZdFwDjGufVmG3irilvjOmjqHNqPWyFkCA4b2KKBWtRisGxKtIAO m9iEICg3bQf8QQaH+EIcWqAFf8DqBsKRARBggAdYKMANJzhBDNpA3jZI4wv02MEHdsCMD7gZDOXl xQf+dm9V9FsRi9iCGyjghiaogwI3gIHnEjGDE9CsDV+4wS5+gARVOIIS7jgjxpUKcshHXvKTp3zH Rc7qkhfD1bCWMctpXWtbS1oKbZKCYhgjhZvj/Gk75znPkWyHF5ShCpvggSniUQaI46BvilMAEPD/ 0A0g3CAQS7hBGZZQBCv4DQZxqMIPOLCLMKgADCAAgwL+oIJDDPjMH5AAoX+QdhuOIBWLQPQI3MCL LXhC0E1wAzOsMAVGa4EHbZjEIn6Agx9MQwFNoEYYboADTuM0a6k8AixAAzxABGSIyzuZkmtAu7gL vFgEvoi13PqfFPCmm8nADJwGIAMy1QM21mu90bADO/AGKygDOjAFHMCaG2gBejAFEKiVH1AEs+OA NgABPJgCICgDAdCHePgCwguDKXA+FWA+dYCFAIOFONgBdYCBIpo3DtCojeIAAfuDRVAEAeM+RQgw RaiGP2CGKfgCHBADX5iCSYCxKeABIJiE/bMc/zkwBQO4uNBJQDqsQzu8Q1MzmRRziwY0uVbbEhd7 QCGAwC4RAjQwRENEA0VcRDRABUfMhSDwtZwTwdZDskx4AdqjBDoQwxYIhE6UA+qLIVXYwg/whG44 hCnYAV3QB304hS8oAxw4hCpQhw+QAWbIOlg4ATAIhEPoN1hgBhloNw5gBiD4Awn4gCrkhVT4gTJr AkXwBAVQgDbgADUogylogUSgByDghUbYAkfoxTYAlhMQhCKYAhQIwE7DQ3VcR3ZsR4pgCymJH8xb tdc6juOQC3zMRxcLxLrIgWLIAYBEhVxoBUk0MkrsgWKzgzTAAWfbhP+bgjJQgTIIBHpoNyBghv8/ +IOJ8xU8sIcfmIIiMIUyOAE6oASZcr5uYAYYcIAv2IVdcAR7eIE00DsbVAAZsDdpUMYRsD5ltDMp EIItUIAf2AJVoEYc2AUruAFm8IRKEIIYcAQKWAEJyLMfuAF6AEJ0lEN33Equ7Ep1FLk9pEd6hCay 1Ee58Md/FIKAXIFXKMgQrMQKMrYp2ARYXEFKkMj3k4MwUD8QYAZmrBUH4ACm+4EYOIRAgIH7c4RA sAJPgAVbhIURkIFdkIETeIBzIIIpUAMY8BUn3AV1GIEPoIAfuDezkyheiII6O7RuwIPkswI5oIBJ CIBpqLpFoJkR6AYwwIEiAIJuOMesDLUXAAn/4WwswcIQLtiwVJuQg+ACU2KeYBqQxjrO47mPCNCY BVCY7ckI6ZQR5IQryZI84QSJy2Kd8dSPCLhOA3kAkCBORlrPCgnPOtRDtwjLejTLs2wEgPxHgMwB NMgBgWzL5DrIChrQhVxBZ2sBZYkH11RKMJAAm0KzGPwDB+ibxowDFfgCB7ACw4wBBYgBm/IDP4MF GNgBIngHItiEMNgEB5ABOdBMHRpGmjrGenOAWFAEBfAEAOKAHbgBIJgCXWyCRkiBNqAGXkCDLaAA VJEDR/AEKkLHMwo1A4CCGiExpOCIBaAjVCsJtbiMCmkqNgKeNNGI+ygAJHkBnCgILmDPnaCj/yvF LClNHpCJvIcoEeRsiOd8lwfIK6Z4AL+iquoZkD6FAo6I0hI5QHiUT7FktXvMxxw4y7TkT0tAA1pA BSdAAgAFQQGNy0yIAYacLlPYBBwwBe6QARXYAQXghb/5gTZwDppyBBgAARigh0D4gh2wgjAIox+o AkdwhCooNxkIBDyABBOtAjWoAgX4gF0ARk8oSo36AF5wg+pLBSGIghtqgy1YzVT8AhAYgWJAgz5T hCaoBGpQAzmQgxMAgWlQgRtgBCflMJKYLAMQmV9Czyo9HoiYVxKYhgxYkjxtF/2AiX2F0wXQKt85 T63KAJDwloEtkgdgkAohgYFFERLggntRkf8HQBGPyKsFaKwHSJDVcqR5SaCKTYkHOIDrbNNpYE6I 9ZYJ2LAIQBF8JdkXqNgKqdiLzYADkC2RpVekWAqEgdgIQM7oyaSIVZCT5YJN6tgKWQgyHZnnbFqK CQktpUNETVR7tE+0BMj+VMRJrVQkyAVIvNS3HFCy9QYcgEge4CD4M4VA4FH+6reA+4NdOIRzldUd wL5AoMwyoIcb+AIwqIIwoAcYQNK+UwNYiAFO2IU4QIE2+IBZ4QAFkAY/4Ad1kIZi8AEJkIBWqARp eKI2aANstT5PaINGqAZViIWaEVc1KAIckKEUkAEYMIB2zbAMIAFLwrB4DRgS0Nh6vVIf2d3/8/QR gsiefzBTlVCR3I0tA4gt/biMvBKrhP0QtEIsAkGLCNgerqiJKLVSiFgIpMlTQa0IVoKCF5jY5JGQ PzrP45HSeIWIgc2r3nkBgPGq9A2JBehTxjqeAoBfEtkIlLCk5Q0JPt0eHBlg2yUK8LleWYKj641T hJBfidCsmQAQkAiH/DVA+aTP19LHfsSLHIhUR0QFJBhhJFiBFehAsR1bsq0gP1hBU6ADa3RIU5CD MrCHWVE/BzCVHzgBepCBL2jb7IgDbXUAJ5wCEFAHwIWBWYQBWJhbFOiGbogDPICBETAzZogBP3CA blADPNioGNQ3CVAAb3ODPwCBLyhGBegS/0WYjhQoBhAwhR5OAesDgi9AAXYNwA9Tz9VxCKAQYONx Ji290oYtCGe6UoQdpKltF+QNiQjgggzgrYqACfWs1w+JUgfhioVIJuZ5ABIoEk1uU6ZdEk02iNzR ZE0+gDT9Y4RFEkMGmAnQidxFiEEeXoRdkpIY5X945SgVLFWG2Mfq2V8Oi6CgLIApgDx1ZRLjkK6S Xyo9n8B6L2KuU5CrWrE0y1dTS/5UxBBGAq8t4RQ4YQ90y0wd0ExAAWcrAxjAAdrbBBVg3R1oA36A 2zXbYRuWgTCAAQVYzV34AAeYgjDQhQ9owiLiPj+ogiXkgBGABRBgPgVAgV3AgyooRmKVAf9YkACF vsWvi0IQ+INYyKgZ5LO7iIImiAVqGAE8eM0RmIQRONcLvWNO87CZ9Sv9mJhEvtJA3h6Fsek0vQkz 3bCpzV0zDQeZLojUIqUJkFrgudLVoquFiOUqTeSFAOXjiYrltJgiaVkusJicbl+0IJF6aVNDWiuW 2GqwnqOv9up2iQoDmIaLAC22lisEJqSg2N2zThJoZp2WpSybeOC8log/3bhD1eCrzUe7yIEuYcQQ FmESXoESRmGxjQLWQ0iyzQTKhsgpWEFla7I48D8QYKI2WARPYAYB2wEbngJeJcxDUAHlC4PkOwFd uGdYGLAqOIRdyDo/2IHvk4DbpgA/UAD/VfCDZnWzfDO0LeAAfvCDVJCADBgBRUjN3YixRQABj5SB EZiGFNhFe/Bh2cXjDDNZsJ5piUiflr1p8x3eF8gAIjGA1ZpfSs5dmJUl2CkAB8ndRO7qKOUCjvDe qiKJ8hZeqY6Ah8EwVAbwJ7mJTBLv4ISJKzXeefGWOjArMi3vXE5wRWbwIUFrpEgf1OIttEoTDped sOCkqkKRXZ6XDZPfwwokhKnd+h6Qvg7YApc8alZUDn6xRNRmR2yCbi5hcA4ygpxE1yPnTOiBDOCA aqA4U/hU3SvCQ0BMfmgDXgjtWjmBQLDQMEhWGAgDR/CbQPjnHfgCW1WBExiBGLDVXdDF/9k+gaxD gRNYXHVIhRgAxg9oAj8IsDTgBWlIBX5wgC0oBmMkymmoi0VoBCTghxOQAQloOCRYL3o4VxnwzZfO MBKQZqMll5xAChy56XeBiAMeEhw5gCqRCFOaBp6YAAxBGoOIAGTyGAnv6n+og7z2CNAygAeXpTQp gKGQaj6VWJEhJdbxmE3HdHt19fAlEG+B2PTkimA/4LLmCFMfkDkFi2Cn9dQCEKiaWWvv66ZACNBK pv7FkJtw5g3j08liJLdKnks3gMCKPLCs5kWVi2IIxEJE7BBuAhL+2m8Gspv78c+IArjsAco2tgxI gUpQBX4Yt8/sBhmwhym2qX7zhLPbgf842HKrjOjZhgEOcIAYUAMU8AQZyMwqOGJYqIIp9oO/DYND iAEyxwM14FB1+AIKwC7dPjtDS4Uo9IM/aIIPkKFJ4IVKaAIhCIAtYIY4kIEmABZFUAUVUIMvONdd QEco3SWfWAAHuWmKmfqf3RcLQc63tqSQkN878hawrxIcofW9atN/2fbiXZQJmAqT8AmClWqkaCqq T2CDeJGRwfphH/bgLKU3lZE6uN++BvVScpBmL15Sul8Mv/o7mgpSt2COeHy8D3FOWhS8j9JFqXut oGqw+onn7PxSKl6faHsZlxKrLUt8LGxCPEQcRwV7J+FcyPcO5HeDPDJNpWxvYEoJiAX/Vai/5oh5 CrAHHgCBHwjjswOCQ3cAe4iDzfyCOVOHl2/5xrw6GFAHBRh5w7V+FDgVWPAEToiDxfUEOFeDbiBo 0eaAKHcAfgCCU3UA5lYFXhACoK8EIIgDZlAA0La3EQACNQAIeyfkTDFg5OC/hAoXMmzo8CHEiBIn Uqxo8SLGjAmnGTCA8YHCCRk0kixp8iTKhAH+rWwZ4CXMRgEa0aRZrFGxYkJ2CkHjEw2qoEGREF2B ZEWQpK1etfLh1EenqJ16UO2R6Wombw4kLKrUJJanP4tGOACxQwUQEBLagKHwY8cJICoCVXEwJQ4M EB9g4P0BK1AYXUAcVLkRmIO6GDs4/3yQ4MetHwmKPvBzoIiXNzBg0vCS8oGCH0+TPoxQNSlnLCHF zI7YUo0DBRCTQOAJBEKOnCoHjaTs7fs38OC/F0QgsWCB8OTKl6tkyRIm9Jkza+LMqZPnT6BCiXJP sSJFUqZNn0qdSjWT1avePLX5UylWIyESWjfZwuyLCnttJPygAMSePSA4Qs8JFHyhxi477LCLGjCA IQNgujDzQxWAwfADhXjswoE0fkwIiyKpwMIMB6lgBsYIqQihiiL8/NEGL6kosEUblRRTiRCLSLGf FIv8MYInEnzgSBggOAAEDLsxtySTTTr50DQPkADSk1VaGVFLz0UnHXU2WYfdT0I1gf8Kd0aBF554 T0UhVVXpXeWGAgrYM8KNOLaRQiXVgIFHfjtIsINbeNgDYSAxAGFFGFN8wAEMeKCgjh+7xFGFJ0Bw AsMhujjwQRV4wPBBG4/t4EcbCnwAxgfqNJHGD5s1MRk/GajSmQSTNBFAJV7FMokqI3DQhidgGHkC IPSAMI0qIKCA0JXNOvsstNFK61CWW8Y0XU3WFZMDmD4JRSZ3SKSQS1JBiDeeD2tG1SZWQ7ihzg8g xMEPTry8p4oqizCTn1r9wQUCEIfEAYQnB8qgwJE/AONMGhzsAIsECsRwwsNtqDMiLKkoMiIIsEij yGOWNXHqCB/EIo06/HygQBMOzHj/K66KSLAFCGqooIAqFMQRiBqUhNGGKp7AYBBv0xp9NNJJK21R tdbK1OVNOfHUU5jblXlUuUG0srWabFrlphtugCADNWow00Qji6S2yFr8ORAHfyOMgCEI9qgggwyG VRHHDQkkQAABpQheSj0NcLLLIZx0iLE6+zTmiTe8SJOKZNIIkQoYkPPSgwMUfKBKE56UxstLlSgw ggKOqAHEJFvsQI8AAXqChAKe2MMDs0vrvjvvvTvZ9JZPQ31dt9oNFe5RZ6bZ9bpVtQsEBw548kMc DuAYC+mV8CIBEN3sAIYCFMx9ggxhOBIHhPQU8sQcuLg/R/ts5JOA4MB0zA8HIz7a/yGqaUySCmk+ IA1eZGI+ihCCNP7Aj1SoIgV/UMA0SNeISijCEwr4AjPAMAlPqMALgAABL9qACpqBgAfL8h0KU6jC FV4EeNERXra+VLxvNSFc3skaU56SLq+5KRND4EA3yAYGNdiDK5VAw0xyRQF7MCMO/eEHGNB3CBWA QAWFKEEJ2jePM1wBflj8ohbyIYoxtOEDIGAGLIBGGXWYLBUOqMwASeMJFUkjSH9oQgpU0YYmLCIA qlnEJGLhANTVDhC+oMcWpnEn29nthCx8JCQjyTsXvhBbMVTNTnKABqrRMFzfQUp4uOYUdZnnPOrp hkC2AIazgOEHqZlgrkYgAyAA4f97/AlQHGjzBCxqURImOAMrgomLL5ZADxfQhww+8AFmAKMN0qDM pmI0SFDFiB8KUEQxFKGABfJCFXFKwSL+EZ9K8GgED2IGD3xBgSYoIHMOoAcl7GGFokmynva8Z7Nc 4jRLVkdqU8tOUMbkyVycSWui3GHzTJmJDHzhCyD4kbBGAAIwxCKJ7wGDA+BCAQkwA2BAiMMueXmF eTziDL/4hQlMwIo5YFEPLjUmPUT3gUVMjh/SkEYsnOGJBdrKDUBSEeZK1k25neYfXimGBGIxjREw gxJx2MUu8PAFGTjCNkXQghxugAJ8crWrXgUOJa8Fter8E6BDqWF3QGmug5KyTVb/+eEuQFCq1hxM XusMQDECEIsH7cAeYODHvxwR0l3i4goI2OIvgIkLlhbzpS69AD1+4Id9OMMPYEiFM2KRiiClYpNb iMWdKLhNE21hRpOoxEuKEYtZKQIEYTAFCBbhADWYYheUwOoNCgGIQHjkq779LXAnEtaXwNBL/txJ dowHrjLhcGvj6YS6olCVVFCjG1OYggz+ILomAAGweFgd9mIRixEAIYo7AGwMYrCJLDS2BOzDBQKo 8IgKeIANjXXsBS6gh3KE4QOK4EQkOMGJNDQhqG5owv/44YktFENG/JDCrtbSBCHgyo9t2FXNTuCA WLihid04QSK0wIMQ3yAGwT0x/4qDO1wuDQ+T3epkd5DQXFFGASrr6kQGOLCINvyAGTFQweomESfN UGAHbOsK92iJAhREAhJ9OMcmHKuHJ4jBFVTIA5bzgIAn6De/Xs6vPiKRAEgYAhOYMEIavDECCahD CKGTgCdw6ob+HHgLI5BGE+yV10rMahIyEF+N9iMBVcQCCGEQRAsSIQgTp7jRjrbniotrXOJRzVuo aIIT0FqUghpUh9BdFzm68QNd6WsHRuJFLCK2Zk/sWG3j1UYkDNGBc/QhARt4wZcvwAZXeEAJWaYC Ffzx5XLkNxGusIAFDIEFRrjABQ1gADDgZKIgKPAPiljEqfihCNCOoA2TOG3pvP8dCwVIQAI3SSog KxGE+ThABVqYwqPjLW8Vrpifxp2aJqt2aSQ4Ia0FXQq61EWVOasDdYtYhBAm8YNF4Izha65RUl+S BixgwQUsEIUhxhACdRD7AuUoRBc8cOUK5KECwKZCIcqhcpWjwxWgsAAkONGABtxDHkeQBxwY0ANp VAIJMlPEFhbhBhRtgZ0j+HbE39OGGk0CkLFAwzR23IRKTIIrKZiEKUwx761zXWnDlYm9tVVWS19a 00S5YSgD/ukePHA/g+RFXn20gxE43JqgjcUiGMAIBgAADndodgiuIQEbsJwNHvBAyU1+8jywYeUq t4EhEpBxYCBCHjQABzhoQIP/JNwjE5Jr0R+kUYwtlDvPawkhOI2a6kCqLV9CIL23+cw2dUjgBPbo Ou5zDy19Oq1L/ZxapY2HaeStQK3OHSVCM4H0JrDl6JVYhCcowIz98GMtlSi3EbCgAc1rfhbyuAYx JOAFls9A5CXPA7A9MI88XMEG7ne/F7wBjPkDQwPcwDz+aaCDIZzsjRrzUcSEUK3IhwQIwT+oFt4l HGjBncxIAJ6owg+EASAcggK0ge5dIAY2SaRZkrZQmlkFlA2JS7lwzXisyZqkwtWt2cEdWSBhFGjN R1K1AQOIwPbl3+XtQSzwgxe4HzrE1+KhH+Kx3/vBnwTIwyzMnOXhnxKSQRNIr0HK0N64rcWOSZi3 hdMK5kQgpYC9SAMgTUMswIAA2MAuVKAqZKAZnuFv1JukkdXYKRcSaFoufJJSANwoQVcPKMKFqU0l TNAiVMNXHNmFGZEqMMAsaB7+EQM+bA8/UMAOuh8CKAGwYZnJId4ZJIIX7OAlegE/8MIncMP9fQIx fIIoiiI4HIEZeBOcIRi5SUATlBsglZsB5gh8CEEKxEITIFGvUIAcHEIgBMLRtSISBAQAOw== --_005_2DD56D786E600F45AC6BDE7DA4E8A8C1121E5F6Eeusaamb107erics_-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 21 08:23:06 2016 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 A51511A00B9 for ; Sun, 21 Feb 2016 08:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 flZbxpz7I5Bt for ; Sun, 21 Feb 2016 08:23:05 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 093B81A008F for ; Sun, 21 Feb 2016 08:23:05 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4631685F9C; Sun, 21 Feb 2016 16:23:03 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 844C885F38 for ; Sun, 21 Feb 2016 16:22:59 +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 D-hGBErqyqhX for ; Sun, 21 Feb 2016 16:22:58 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc0c::748]) by mail.netbsd.org (Postfix) with ESMTP id 616BD85E66 for ; Sun, 21 Feb 2016 16:22:55 +0000 (UTC) Received: from BLUPR05CA0051.namprd05.prod.outlook.com (10.141.20.21) by BY1PR0501MB1607.namprd05.prod.outlook.com (10.160.203.156) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sun, 21 Feb 2016 16:22:53 +0000 Received: from BN1BFFO11FD015.protection.gbl (2a01:111:f400:7c10::1:121) by BLUPR05CA0051.outlook.office365.com (2a01:111:e400:855::21) with Microsoft SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Sun, 21 Feb 2016 16:22:52 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) 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.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BN1BFFO11FD015.mail.protection.outlook.com (10.58.144.78) with Microsoft SMTP Server (TLS) id 15.1.422.5 via Frontend Transport; Sun, 21 Feb 2016 16:22:51 +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; Sun, 21 Feb 2016 08:22:50 -0800 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 u1LGMnD84501; Sun, 21 Feb 2016 08:22:49 -0800 (PST) (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 13C791141B; Sun, 21 Feb 2016 08:22:49 -0800 (PST) To: Simon Josefsson CC: denis bider , Subject: Re: Curve25519/448 key agreement for SSH In-Reply-To: <874mg9y7s9.fsf@latte.josefsson.org> References: <1023314969-1152@skroderider.denisbider.com> <874mg9y7s9.fsf@latte.josefsson.org> Comments: In-reply-to: Simon Josefsson message dated "Thu, 26 Nov 2015 00:32:38 +0100." From: "Mark D. Baushke" Date: Sun, 21 Feb 2016 08:22:48 -0800 Message-ID: <423.1456071768@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD015;1:WMwVkc7AcYj7zgxTXVdDII+jE4qfqaED6KDFqSsi6eeMEhS69bd6OG4EeSxtmG4Ply/7ODOJiBZQlVRwA2uTQgXkbEPH62wx6gM2Ha+ltrjm54EmAxlN7dX5A9Asftex5k4afMK/w2+0iRHUMaUrgBSa+lvDwKPivZ/nY8R6LRtQYgwfM8Ah/nBZZdQFD9Fe7oFCrZWNkZqLNrk3BA/6iv/Hh3FBXcuAtd6+UpvAW7ee5CC3PQH4ZowbxdCfn4wwGJ5rng7cpduDHt/aPlI0plUlHYRMOc3AkKtDjWKVsGGJN8bSnnabr/E9EYEMXyO+f1xismlRSDGUrIBmRWCOFk2QTwCyvZOUTLz3ZlU+78b9ADXaulDNODBXu5+N50QqRw4eNZ7nUW8RK37sf2bxFcvoSJ0NhlS3QcTMPpy6tD4= X-Forefront-Antispam-Report: CIP:66.129.239.19;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(199003)(189002)(105596002)(106466001)(1220700001)(1096002)(117636001)(189998001)(5001960100002)(50466002)(92566002)(76506005)(50986999)(76176999)(54356999)(586003)(2950100001)(15975445007)(53416004)(77096005)(48376002)(87936001)(11100500001)(19580395003)(47776003)(86362001)(6806005)(110136002)(2810700001)(4326007)(2906002)(5003600100002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR0501MB1607;H:p-emfe01b-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1607;2:Wx9bK+54brvwoQ0Xljiau26FgA4lRs7jgRCbmqmsSyT0juc/oVGmgbjN4guc145DLCOzeQHFfqZcrp+P+g6uJrYnYb87GtMY1qTTC54Y5L1XOjjqfuWS8d0Q3k8X+Tpqwdp7ziyJOubYubf1FR1u3Q==;3:rLzgUegfWWBdOgZAqx0mimMq1Jk2jD1cl1vJD3L1EemgIMAPSXHXu2qlepLS2qEtljuz9MSkYnTIa8drtrMIo4ksLIR4779zJlGQyIB+03kDnw29XV+N3sa3+vVsLCd2r93a3hwsOMOdYRuNvCvzsniKskGMZOQWZP1ZrNObtjtpzZqKuBPgxe0keZt66peCS92VaIgzCGCVwDdD/GA4Q57rnVnrP9Ka+V8aH2Gx8ok=;25:4jF33sYksOLYocTWU50RrxgfbwI0bJzfZ88qk6keOpUqReMwij15o3/mm0x6K7wHMY2NCLr9wVqu2fr0MwPw/Hto+cmEz0TuH8FuT6i+KRQv9PMVSm/PPMw7nxJ1UnLJCYHQgBlaVLvjORAfIqcxTbkMYJ2Yn3ENKhk0ErrIFpk826shrfZ8vcWlmupmL3o3w0Aob1WZ7gBQN/8+n2ocZLBjCG1y9Lde2Ac/4kkRvEeEnG+wl53DB7cBO37CK0ZLJA3sZTKyFpwlgA7NGSoCJk71x49zANV23o5mAZ1LSp/Svn5zLIjCn3KObkjKZt9elL4aFbYikKEPB895frj/fSHqBZBHVwD09E1PY0rjHe4= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1607; X-MS-Office365-Filtering-Correlation-Id: 290ec65a-4fdb-4f4b-7e0d-08d33adb3f41 X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1607;20:5vz+TABWQdXgXLKi/iyRIk0spcncJie4w8/0X8YNG9tRmS9e3xySk7vQ5hN+Bb1Qqf8es5+zpS31ITWQ0TpuVAvH39yXHGvjo/IoSQGIZpFu1VHPcIQohgMqR1bKA5YoE0fMXWNfPgDkU9E5deM5ZZnL3UJiYDwAJOpqXt+f1zuIHhNs+miKDpQs+XzO02PvDowZv5K53bVlWtJaZFN2jIIme1R9ULGsNklZq/idiusePILhZkKt83ZqqVHk8AOUrYBOCZMuZmgaINYHpxlq6+DCxFTgfT9UEwH+NEmE/vw1vXNzeBF1w50nAcZrjsiprMJyOhnZCuUqUsHH9C2FSmUB6uvGkjxwrln4ecvwMqvl5+jmnZs0rRrZkKE9kjmpdPKPdSM9zVlCw1py4Nmy7m0SEWHOCKaxiyqiXzaLmJgMEoxJ+7THlwjUT+D5GrR5rQtPYv0qD/u7cRIR878UJVQXbRXigXLDxSbDeXcxs9fJFOjedreRpXJ/CyviIBda X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13018025)(5005006)(13017025)(8121501046)(13015025)(13023025)(13024025)(3002001)(10201501046);SRVR:BY1PR0501MB1607;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1607; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1607;4:M/F0cCbmR1USEkA8O149/KElPMcQaRnO5IiK+KEcyJ+axkPpHQq/jdF7/hunmgUc77cvwnBcEt6ttuin3ZOm8275qFJv+ENrGY3DrT398wfjT8HrohRTi2cMVusSFgcMIMrGEhmCvzGX7eG9eBqRZn81ag/BXTMW00u9tDvgNJ7As60WMgwRvxF02CGjFS5iwv1Y2P+SWMl/lJ+RiJLrAeaj2DYVM0THmPLumY9d0UKWT+2v+PKM2yX8wL0U9ZmDauBvLVKT/UI3zuIVW5IhilH13HnL/jQkxiFDgVDDNt2oLFlXqkPwAHWZE+cGu9qVdsyuCTE3QXUXxfbA0IpG1j1Hbx+erf69keSuKjgVBIWZE1c3F/JgbVxhXS6n5qTO0UdliGN8xNUP+8RZqHa2mkfK7O/aVCJtBnKwpoKil0VHUp2djzXl6K0JkDRAlkvmjS0ha2VhAAqEvag/TwmDJw== X-Forefront-PRVS: 085956473E X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1607;23:3lcjkQVmbcA5/3OAeB9alXvv2Yp4qLHeNCcC71IKc4THmljoIvjWMuvPwefUfGRKe/7QL9kHLr904i5gq3MwK389s0QT9oteo2llGdx+gMKaGCf673fB98o6pyiIGMSlb7BFc+dBdyI8itfAoT5bHwc+H5tAEO3IELEXP3OKA9gvL/YQptd3eir7/NTxHHdjFVSfsEqLyTs2D2nt1FNkmERmhV4dRClHZPGwi/1+JsQYFihOdEuaU2Xw8P4PYwOIM63L7kdOzRQzBNbC/J0CkuhT530PF1HAYXodbkH9bgtqxUCfF8AO/kYOdB4/vId9EfjjL+uT1292ApbhGiQJh6glnZJBEZ400wkKTgV5jbdVdIAgs7PssE7ashdzkOuXjRUaRJSLOxjcXH01IjIO9CZkmT8T5tNetHvrfOcFUTz691UXc/HtsXYVGwtSceNZSA6lsqXqdchV++Kf7ztYWxwUQzzeQywnB3Eq3C1JRVgAJ+E1o6qd1EU+U9OXV3vRRyWKsYDzbDxKUXbZjwnECgLk3/HPv1bALmqqqFye/gbZc+ei45gG8VV4sogTe8ySqN6jPbR7bUUmyVDVDOIObKMIOGDJbfLigTOCz23Xj1gio9Koj2A1jZufdp6Q2redes66cXuKiepP3bVbt8te0NY5CPyNmoQ0WU94xdqDoDBQpw7Ri5v/hxRUMo4+Hp+laKLso7zqCy6HGhfUGaFpC6jVUo1Q3R/oLzZLXU2K2VKe8B0Y9SHc4PWdfETU9cwUk999naVf8CBVE8i/q0lBuPOrYeeeV1CajcRx8NfJQj3lQTP6jX6cluahWIJBjdwx0hvp3jqEx9+td8w3Y4q1D79QLyu5kZeWFxNWQK9nWa6WNsWnwCL9Bjc4DednI6mSyUKO78XZW4c7AmGdtl8qoyeZ/JIVz+8Xspz2nFd0GuV2xM6CgZx5xcqTW/pNqENi X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1607;5:D2ExXAfE7HJ0dWTFnIBxfDINDKIIDkX4Bbnmpk1mBsmich9ilDCvGSCC4rW19h7MAN66ta9HH2iHVMy2kXGbEoLhcPn6IYO3s4uLkenTgh9DE2kmMBg0tFfGKLJSzGjqGQV7mWAkwMe2tAiXIbLbtQ==;24:Qi96LQprqPWfPB7kNs6C0g9MXMa+/s3kEUgqanf5ITz438Y1WREDNB8qqzdBw8ejpG/ANT0Zh1/OTVZS53474wREY2v8JzsN1SUHxHqXSVk= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Feb 2016 16:22:51.9289 (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.19];Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1607 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Simon, Regarding https://datatracker.ietf.org/doc/draft-josefsson-ssh-curves/ could advise on the the following? | The protocol flow, the SSH_MSG_KEX_ECDH_INIT and | SSH_MSG_KEX_ECDH_REPLY messages, and the structure of the exchange | hash are identical to chapter 4 of [RFC5656]. | | The method names registered by this document are "curve25519-sha256" | and "curve448-sha256". The RFC5656 "4. ECDH Key Exchange" also says | The Elliptic Curve Diffie-Hellman (ECDH) key exchange method | generates a shared secret from an ephemeral local elliptic curve | private key and ephemeral remote elliptic curve public key. This key | exchange method provides explicit server authentication as defined in | [RFC4253] using a signature on the exchange hash. Every compliant | SSH ECC implementation MUST implement ECDH key exchange. which would seem to also implicitly reference RFC5656 3.1.1: | 3.1.1. Signature Algorithm | | Signing and verifying is done using the Elliptic Curve Digital | Signature Algorithm (ECDSA). ECDSA is specified in [SEC1]. The | message hashing algorithm MUST be from the SHA2 family of hash | functions [FIPS-180-3] and is chosen according to the curve size as | specified in Section 6.2.1. and if so, looking at 6.2.1: | 6.2.1. Elliptic Curve Digital Signature Algorithm | | The hashing algorithm defined by this family of method names is the | SHA2 family of hashing algorithms [FIPS-180-3]. The algorithm from | the SHA2 family that will be used is chosen based on the size of the | named curve specified in the public key: | | +----------------+----------------+ | | Curve Size | Hash Algorithm | | +----------------+----------------+ | | b <= 256 | SHA-256 | | | | | | | 256 < b <= 384 | SHA-384 | | | | | | | 384 < b | SHA-512 | | +----------------+----------------+ Is the hash to use driven by the table in RFC5656 as seen in 6.2.1 such that curve448 should use SHA-512? If so, why is the Key Exchange Method name "curve448-sha256" rather than "curve488-sha512" ? Also, should the current draft be updated to change references of [I-D.irtf-cfrg-curves] to [RFC7748] ? Thank you, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Feb 22 01:08:43 2016 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 5DA7C1B2C3B for ; Mon, 22 Feb 2016 01:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 D1j5NeuGwmfk for ; Mon, 22 Feb 2016 01:08:42 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 6A8321B2BA4 for ; Mon, 22 Feb 2016 01:08:42 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8E0AB8601C; Mon, 22 Feb 2016 09:08:40 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4A07C86011 for ; Mon, 22 Feb 2016 09:08:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 8nyUaS6yyTcR for ; Mon, 22 Feb 2016 09:08:38 +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 7731385E26 for ; Mon, 22 Feb 2016 09:08:38 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id B08244001B; Mon, 22 Feb 2016 10:08:34 +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 15D8C40019; Mon, 22 Feb 2016 10:08:33 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 22 Feb 2016 10:08:33 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: Simon Josefsson , denis bider , Subject: Re: Curve25519/448 key agreement for SSH References: <1023314969-1152@skroderider.denisbider.com> <874mg9y7s9.fsf@latte.josefsson.org> <423.1456071768@eng-mail01.juniper.net> Date: Mon, 22 Feb 2016 10:08:32 +0100 In-Reply-To: <423.1456071768@eng-mail01.juniper.net> (Mark D. Baushke's message of "Sun, 21 Feb 2016 08:22:48 -0800") 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 "Mark D. Baushke" writes: > If so, why is the Key Exchange Method name "curve448-sha256" rather than > "curve488-sha512" ? I think Damien Miller's argument for using sha512 here makes sense: "curve448 is a backup against as-yet-unknown attacks on curve25519. Since we're not likely to need it, we might as well pair it with SHA512 as a backup against as-yet-unknown attacks on SHA256." 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 Mon Feb 22 21:42:14 2016 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 BD84D1A8A57 for ; Mon, 22 Feb 2016 21:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 UYMVzgblsWQY for ; Mon, 22 Feb 2016 21:42:13 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 431E01A86FF for ; Mon, 22 Feb 2016 21:42:13 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A5FE486019; Tue, 23 Feb 2016 05:42:12 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 5A90B85F3C; Tue, 23 Feb 2016 05:42:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 22B238601A for ; Mon, 22 Feb 2016 08:47:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id HjWXmyrdCflV for ; Mon, 22 Feb 2016 08: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 4FFED84D04 for ; Mon, 22 Feb 2016 08:47:54 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 376924001B; Mon, 22 Feb 2016 09:47:47 +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 6AFFE40019; Mon, 22 Feb 2016 09:47:45 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 22 Feb 2016 09:47:45 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: denis bider , Stephen Farrell , , Watson Ladd , Daniel Migault , Curdle Chairs Subject: Re: AEAD in ssh References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> Date: Mon, 22 Feb 2016 09:47:44 +0100 In-Reply-To: ("Niels =?utf-8?Q?M?= =?utf-8?Q?=C3=B6ller=22's?= message of "Thu, 04 Feb 2016 13:09:05 +0100") 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 nisse@lysator.liu.se (Niels M=C3=B6ller) writes: > I'm also happy to say that I've gotten some time to work on a draft. > Hopefully I have something within a few days. I've now posted a first version, https://www.ietf.org/id/draft-nisse-secsh-aead-00.txt. I was advised by a collegue with a bit more ietf experience to include one concrete AEAD. So I added chacha-poly1305, to define something which is actually implementable. 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 Tue Feb 23 23:22:57 2016 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 043941B3B09 for ; Tue, 23 Feb 2016 23:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 ToZsfsFlDD6m for ; Tue, 23 Feb 2016 23:22:56 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 1393A1B38E1 for ; Tue, 23 Feb 2016 23:22:55 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E78EA85F16; Wed, 24 Feb 2016 07:22:54 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 97C1285E8D; Wed, 24 Feb 2016 07:22:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B781A85E6B for ; Wed, 24 Feb 2016 06:00:37 +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 OuYzbpSBmu7w for ; Wed, 24 Feb 2016 06:00:37 +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 D8CBB84D04 for ; Wed, 24 Feb 2016 06:00:36 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 4CE4440031; Wed, 24 Feb 2016 07:00:31 +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 D0E3C40012; Wed, 24 Feb 2016 07:00:28 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Wed, 24 Feb 2016 07:00:28 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Watson Ladd Cc: Bryan Ford , Daniel Migault , denis bider , ietf-ssh@netbsd.org, Stephen Farrell , "Mark D. Baushke" , Curdle Chairs Subject: Re: AEAD in ssh References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> <161DEFB5-1564-4F96-8E87-AE98BB07925E@gmail.com> Date: Wed, 24 Feb 2016 07:00:28 +0100 In-Reply-To: (Watson Ladd's message of "Tue, 23 Feb 2016 10:57:25 -0800") 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 Watson Ladd writes: > There already is a widely used SSH implementation with AEAD support. Copy > what they do. I'm aware of three different ways: 1. aes-gcm, according to 5647, implemented by some. 2. aes-gcm, according to openssh (with simpler negotiation rules, which I *do* copy). 3. chacha20-poly1305 according to openssh. I think the time is right to try to document a recommended way to do it. 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 Tue Feb 23 23:23:03 2016 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 783031B3D6F for ; Tue, 23 Feb 2016 23:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 fRmT6yPqSDZp for ; Tue, 23 Feb 2016 23:23:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 DAB261B3B09 for ; Tue, 23 Feb 2016 23:23:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A54CE85F3D; Wed, 24 Feb 2016 07:23:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 597C685E8D; Wed, 24 Feb 2016 07:23:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A6EA284CF0 for ; Tue, 23 Feb 2016 15:56:26 +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 KRQaey_2eMtD for ; Tue, 23 Feb 2016 15:56:26 +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 C910184CEA for ; Tue, 23 Feb 2016 15:56:24 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 22E7A4001A; Tue, 23 Feb 2016 16:56:22 +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 C67E840011; Tue, 23 Feb 2016 16:56:19 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 23 Feb 2016 16:56:19 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Bryan Ford Cc: "Mark D. Baushke" , denis bider , Stephen Farrell , ietf-ssh@NetBSD.org, Watson Ladd , Daniel Migault , Curdle Chairs Subject: Re: AEAD in ssh References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> Date: Tue, 23 Feb 2016 16:56:19 +0100 In-Reply-To: <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> (Bryan Ford's message of "Tue, 23 Feb 2016 06:15:52 -0800") 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 Bryan Ford writes: > I see that in 3.1 on =E2=80=9CEncrypting the packet length=E2=80=9D, you= =E2=80=99ve suggested > the same approach as one of the earlier approaches I suggested a while > ago in the corresponding TLS discussion. That=E2=80=99s a reasonable appr= oach > and I think would work, but I wanted to make sure you=E2=80=99re aware of > another alternative that I=E2=80=99ve come to think is both cleaner and s= afer: > just embed the length of the next packet within the normal > AEAD-encrypted payload of its immediately prior packet. Thanks for the update.=20 This could make a lot of sense for a new protocol or for a larger protocol update. But I think adding the length field to the preceding packet is a too large structural change of the ssh protocol to do just to support AEAD ciphers. 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 Tue Feb 23 23:23:11 2016 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 6BA9B1B3A1F for ; Tue, 23 Feb 2016 23:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 uNI6sORhg8b5 for ; Tue, 23 Feb 2016 23:23:10 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 BA8EC1B3ED6 for ; Tue, 23 Feb 2016 23:23:10 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 825EB86061; Wed, 24 Feb 2016 07:23:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 38BF185E8D; Wed, 24 Feb 2016 07:23:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A14AC84D04 for ; Wed, 24 Feb 2016 06:15:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id y8fmlNmK4lIQ for ; Wed, 24 Feb 2016 06:15:53 +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 BDC4285E6B for ; Wed, 24 Feb 2016 06:15:52 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id D974740031; Wed, 24 Feb 2016 07:15:50 +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 C2E4140012; Wed, 24 Feb 2016 07:15:49 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Wed, 24 Feb 2016 07:15:49 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Bryan Ford , "Mark D. Baushke" , Stephen Farrell , ietf-ssh@NetBSD.org, Watson Ladd , Daniel Migault , Curdle Chairs Subject: Re: AEAD in ssh References: <1100347732-1476@skroderider.denisbider.com> Date: Wed, 24 Feb 2016 07:15:49 +0100 In-Reply-To: <1100347732-1476@skroderider.denisbider.com> (denis bider's message of "Tue, 23 Feb 2016 22:00:21 +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 think lengths in AEAD > should just be encrypted with the same underlying block cipher in CTR > mode. No AEAD instance required. What do you think of the way it is specified in the draft? Which is well defined for an arbitrary AEAD, but boils down to plain CTR mode for typical AEAD block cipher modes, and boils down to plain cacha encryption for chacha-poly1305?=20 I think it is elegant, but it's not the only way of course. Closest alternative would be to use a separately keyed cipher (i.e., a larger output from session key generation) and leave to the particular AEAD to specify the cipher and how to use it. Thinking aloud, I think the drawback of doing that is that it leaves several arbitrary choices open, e.g., should lengths conceptually be packed back to back into a stream to be encrypted four bytes at a time (with AES-CTR, using the same block for four messages, and 16 messages for chacha), or should we use one underlying "block" per message? I would prefer consistency, and I don't see any drawback in trying to nail these things down. 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 Tue Feb 23 23:23:20 2016 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 1A28A1B3F32 for ; Tue, 23 Feb 2016 23:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 YVFVVOlfLafV for ; Tue, 23 Feb 2016 23:23:18 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 9CDC11B3D6F for ; Tue, 23 Feb 2016 23:23:18 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 20FC186074; Wed, 24 Feb 2016 07:23:18 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C6FE586059; Wed, 24 Feb 2016 07:23:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 49BAE8605E for ; Tue, 23 Feb 2016 18:41:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id pJKQNdPySP6K for ; Tue, 23 Feb 2016 18:41: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 6212885EA4 for ; Tue, 23 Feb 2016 18:41:53 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 21E4E40020; Tue, 23 Feb 2016 19:41:51 +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 C996A4000B; Tue, 23 Feb 2016 19:41:48 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 23 Feb 2016 19:41:48 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Bryan Ford Cc: "Mark D. Baushke" , denis bider , Stephen Farrell , ietf-ssh@NetBSD.org, Watson Ladd , Daniel Migault , Curdle Chairs Subject: Re: AEAD in ssh References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> <161DEFB5-1564-4F96-8E87-AE98BB07925E@gmail.com> Date: Tue, 23 Feb 2016 19:41:48 +0100 In-Reply-To: <161DEFB5-1564-4F96-8E87-AE98BB07925E@gmail.com> (Bryan Ford's message of "Tue, 23 Feb 2016 09:03:53 -0800") 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 Bryan Ford writes: > I can understand that position. However, one potentially > counter-balancing consideration is that the introduction of new > AEAD-based ciphersuites inherently introduces a new, > wire-protocol-incompatible =E2=80=9Crecord format=E2=80=9D anyway that ne= eds to be > negotiated. I agree, but at least it's only a different per-packet transformation. Having to guess future packet sizes or emit extra packets is much more than a new record format. I don't think it's a good tradeoff, too much new complexity for little benefit. My understanding is that cleartext length fields are believed to be secure, in that the only thing leaked are message boundaries. And hiding them using a separate stream cipher is a simple way to stop that leak (and the benefit of doing that is under debate). In particular, the even simpler alternative, to apply the AEAD to the 4-byte length field, including authentication, seems like overkill.=20 I think simplicity is essential for making progress here, if we go for a design of ssh version 3, discussion will never end. > Deferring useful record format changes until the next major protocol > version, I don't expect any need for a new major version of the ssh protocol for the next one or two decades. It's not too painful to add aead support (and all other additions of new algorithms have been smooth, as far as I can tell). 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 Tue Feb 23 23:24:53 2016 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 67CE41B4348 for ; Tue, 23 Feb 2016 23:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 9URzJPsB26Gn for ; Tue, 23 Feb 2016 23:24:52 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 3C6D31B40DE for ; Tue, 23 Feb 2016 23:24:52 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D383886076; Wed, 24 Feb 2016 07:24:51 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 8ABDD86066; Wed, 24 Feb 2016 07:24:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id ED24B85EC7 for ; Tue, 23 Feb 2016 22:09:51 +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 WBq9d2dedvKX for ; Tue, 23 Feb 2016 22:09:51 +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 54E0584CBD for ; Tue, 23 Feb 2016 22:09:51 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for watsonbladd@gmail.com; Tue, 23 Feb 2016 22:09:46 +0000 Date: Tue, 23 Feb 2016 22:09:46 +0000 Subject: Re: AEAD in ssh X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1102303688-2760@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: MIME-Version: 1.0 From: denis bider To: Watson Ladd , =?UTF-8?q?Niels_M=C3=B6ller?= Cc: Bryan Ford , Daniel Migault , ietf-ssh@netbsd.org, Stephen Farrell , "Mark D. Baushke" , Curdle Chairs Content-Type: multipart/alternative; boundary="=-CU04jD7RmdxERasGn3Ry" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-CU04jD7RmdxERasGn3Ry Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That implementation, with unencrypted packet lengths, sabotages any hope of= thwarting traffic analysis, even through high-overhead SSH_MSG_IGNORE padd= ing. If someone wants to do max bandwidth padding right now, using AES-CTR, they= can just do it. With AES-GCM, this is no longer viable. Internal padding i= s too inflexible. I think it's a shame to throw away implementation potential just because it= 's not currently being used. Right now we don't do max bandwidth padding be= cause it's seen as inefficient. That may no longer be the case in 10 years. 25 years ago, encryption seemed inefficient, and no one did it. Watson Ladd , 2/23/2016 6:57 PM: On Feb 23, 2016 10:41 AM, "Niels M=C3=B6ller" wrote= : > > Bryan Ford writes: > > > I can understand that position. However, one potentially > > counter-balancing consideration is that the introduction of new > > AEAD-based ciphersuites inherently introduces a new, > > wire-protocol-incompatible =E2=80=9Crecord format=E2=80=9D anyway that= needs to be > > negotiated. > > I agree, but at least it's only a different per-packet transformation. > Having to guess future packet sizes or emit extra packets is much more > than a new record format. I don't think it's a good tradeoff, too much > new complexity for little benefit. > > My understanding is that cleartext length fields are believed to be > secure, in that the only thing leaked are message boundaries. And hiding > them using a separate stream cipher is a simple way to stop that leak > (and the benefit of doing that is under debate). In particular, the even > simpler alternative, to apply the AEAD to the 4-byte length field, > including authentication, seems like overkill. > > I think simplicity is essential for making progress here, if we go for a > design of ssh version 3, discussion will never end. > > > Deferring useful record format changes until the next major protocol > > version, > > I don't expect any need for a new major version of the ssh protocol for > the next one or two decades. It's not too painful to add aead support > (and all other additions of new algorithms have been smooth, as far as I > can tell).=20 There already is a widely used SSH implementation with AEAD support. Copy w= hat they do. > > Regards, > /Niels > > -- > Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. > Internet email is subject to wholesale government surveillance. =20= --=-CU04jD7RmdxERasGn3Ry Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable That implementation, with unencrypted packet lengt= hs, sabotages any hope of thwarting traffic analysis, even through high-ove= rhead SSH_MSG_IGNORE padding.

If someone wants to do max bandwidth p= adding right now, using AES-CTR, they can just do it. With AES-GCM, this is= no longer viable. Internal padding is too inflexible.

I think it's = a shame to throw away implementation potential just because it's not curren= tly being used. Right now we don't do max bandwidth padding because it's se= en as inefficient. That may no longer be the case in 10 years.

25 ye= ars ago, encryption seemed inefficient, and no one did it.


= Watson Lad= d <watsonbladd@gmail.com>= , 2/23/2016 6:57 PM:


On Feb 23, 2016 10:41 AM, "Niels M=C3=B6ller" <nisse= @lysator.liu.se> wrote:
>
> Bryan Ford <brynosaurus@gmail.com> wri= tes:
>
> > I can understand that position. However, one potentially
> > counter-balancing consideration is that the introduction of new > > AEAD-based ciphersuites inherently introduces a new,
> > wire-protocol-incompatible =E2=80=9Crecord format=E2=80=9D anyway= that needs to be
> > negotiated.
>
> I agree, but at least it's only a different per-packet transformation.=
> Having to guess future packet sizes or emit extra packets is much more=
> than a new record format. I don't think it's a good tradeoff, too much=
> new complexity for little benefit.
>
> My understanding is that cleartext length fields are believed to be > secure, in that the only thing leaked are message boundaries. And hidi= ng
> them using a separate stream cipher is a simple way to stop that leak<= br> > (and the benefit of doing that is under debate). In particular, the ev= en
> simpler alternative, to apply the AEAD to the 4-byte length field,
> including authentication, seems like overkill.
>
> I think simplicity is essential for making progress here, if we go for= a
> design of ssh version 3, discussion will never end.
>
> > Deferring useful record format changes until the next major proto= col
> > version,
>
> I don't expect any need for a new major version of the ssh protocol fo= r
> the next one or two decades. It's not too painful to add aead support<= br> > (and all other additions of new algorithms have been smooth, as far as= I
> can tell).

There already is a widely used SSH implementation with AEAD support. Cop= y what they do.
>
> Regards,
> /Niels
>
> --
> Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. > Internet email is subject to wholesale government surveillance.

= --=-CU04jD7RmdxERasGn3Ry-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 23 23:25:06 2016 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 325991B4249 for ; Tue, 23 Feb 2016 23:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 BtsTF9iQNmii for ; Tue, 23 Feb 2016 23:25:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 860401B40DE for ; Tue, 23 Feb 2016 23:25:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 654878607A; Wed, 24 Feb 2016 07:25:01 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 07B6286066; Wed, 24 Feb 2016 07:25:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B060186061 for ; Tue, 23 Feb 2016 18:57:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KD1DYFqmzOJ4 for ; Tue, 23 Feb 2016 18:57:27 +0000 (UTC) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 E60CD86059 for ; Tue, 23 Feb 2016 18:57:26 +0000 (UTC) Received: by mail-yw0-x235.google.com with SMTP id h129so154526543ywb.1 for ; Tue, 23 Feb 2016 10:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+vSQtZ5Zlsx1HN4FhrxoCKwfAVfOeQZNOsSKpkI28Js=; b=03lhWMySStYcXW8RXNjHB07r4LWJeYryt3BnzXG/k85H3ECyaJe4MxrLtxMJS5kvGq 03ZjI826gQxrfc1LC/+WKV8ax2LeVNrBJujmDy2VVuBUSNF2q/Ft7KngGne2c9SajYHe j4d4PLTgS1BfMmI7QKPn/kOEfRsBlvS8ooJgNQLLusrZaPk7mYhnajIRqYYbNWnrFz/n G9hJFvgAQzTtJgnRMnFhiohRjnGg3hXgVeqBs002H+OXgSncTOreNUv46VfvBHl5puyl o5aQYaJEMuima+GTRimKa9TY7sP7jlWk79DToGTtRPxQOmurjHz99/Po2+x35jN6cJV2 8Hww== 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=+vSQtZ5Zlsx1HN4FhrxoCKwfAVfOeQZNOsSKpkI28Js=; b=OLsHEeVtiQgVGWmVZ9uDg/oG79qJ30plsAMImA7wuZEqG9zWflWYeziCpjonl064qk 17wV/m/Ud000+E/p7udgPIysrSinNKX6mPeQKP0WFKtxczxWn6ZiAyShhknNqT+/+TcQ GX/0gHasRYcgr/KXJ3udIevskur3v3jaC9A2gcg//gU1muw6IzhV3kM1yRtfjiipoFmD 03HCFBcoH3tZOJs41D4KMTbJxTVAOwYbHps/Wp7CvttM0JzzgvY59F2nExtegXu8FVlW um/uJ/MvPuvmjyhIuh95sjSyo34aGy3i/FItth9iO7X2hFW5RYQ35FZIpiZzfW22xXT1 jB9Q== X-Gm-Message-State: AG10YORBe43cQFvXTJiCK40pWfOQqf5L/sgUZZTfiFSYXrlk3dxNsNBxR1ZAWPU0QxNAsRWeE6t44PUbhFBQRA== MIME-Version: 1.0 X-Received: by 10.13.226.86 with SMTP id l83mr19287557ywe.239.1456253846028; Tue, 23 Feb 2016 10:57:26 -0800 (PST) Received: by 10.13.216.138 with HTTP; Tue, 23 Feb 2016 10:57:25 -0800 (PST) Received: by 10.13.216.138 with HTTP; Tue, 23 Feb 2016 10:57:25 -0800 (PST) In-Reply-To: References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> <161DEFB5-1564-4F96-8E87-AE98BB07925E@gmail.com> Date: Tue, 23 Feb 2016 10:57:25 -0800 Message-ID: Subject: Re: AEAD in ssh From: Watson Ladd To: =?UTF-8?Q?Niels_M=C3=B6ller?= Cc: Bryan Ford , Daniel Migault , denis bider , ietf-ssh@netbsd.org, Stephen Farrell , "Mark D. Baushke" , Curdle Chairs Content-Type: multipart/alternative; boundary=001a114fc15232091d052c748593 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --001a114fc15232091d052c748593 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Feb 23, 2016 10:41 AM, "Niels M=C3=B6ller" wrote: > > Bryan Ford writes: > > > I can understand that position. However, one potentially > > counter-balancing consideration is that the introduction of new > > AEAD-based ciphersuites inherently introduces a new, > > wire-protocol-incompatible =E2=80=9Crecord format=E2=80=9D anyway that = needs to be > > negotiated. > > I agree, but at least it's only a different per-packet transformation. > Having to guess future packet sizes or emit extra packets is much more > than a new record format. I don't think it's a good tradeoff, too much > new complexity for little benefit. > > My understanding is that cleartext length fields are believed to be > secure, in that the only thing leaked are message boundaries. And hiding > them using a separate stream cipher is a simple way to stop that leak > (and the benefit of doing that is under debate). In particular, the even > simpler alternative, to apply the AEAD to the 4-byte length field, > including authentication, seems like overkill. > > I think simplicity is essential for making progress here, if we go for a > design of ssh version 3, discussion will never end. > > > Deferring useful record format changes until the next major protocol > > version, > > I don't expect any need for a new major version of the ssh protocol for > the next one or two decades. It's not too painful to add aead support > (and all other additions of new algorithms have been smooth, as far as I > can tell). There already is a widely used SSH implementation with AEAD support. Copy what they do. > > Regards, > /Niels > > -- > Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. > Internet email is subject to wholesale government surveillance. --001a114fc15232091d052c748593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 23, 2016 10:41 AM, "Niels M=C3=B6ller" <nisse@lysator.liu.se> wrote:
>
> Bryan Ford <brynosaurus@gm= ail.com> writes:
>
> > I can understand that position. However, one potentially
> > counter-balancing consideration is that the introduction of new > > AEAD-based ciphersuites inherently introduces a new,
> > wire-protocol-incompatible =E2=80=9Crecord format=E2=80=9D anyway= that needs to be
> > negotiated.
>
> I agree, but at least it's only a different per-packet transformat= ion.
> Having to guess future packet sizes or emit extra packets is much more=
> than a new record format. I don't think it's a good tradeoff, = too much
> new complexity for little benefit.
>
> My understanding is that cleartext length fields are believed to be > secure, in that the only thing leaked are message boundaries. And hidi= ng
> them using a separate stream cipher is a simple way to stop that leak<= br> > (and the benefit of doing that is under debate). In particular, the ev= en
> simpler alternative, to apply the AEAD to the 4-byte length field,
> including authentication, seems like overkill.
>
> I think simplicity is essential for making progress here, if we go for= a
> design of ssh version 3, discussion will never end.
>
> > Deferring useful record format changes until the next major proto= col
> > version,
>
> I don't expect any need for a new major version of the ssh protoco= l for
> the next one or two decades. It's not too painful to add aead supp= ort
> (and all other additions of new algorithms have been smooth, as far as= I
> can tell).

There already is a widely used SSH implementation with AEAD = support. Copy what they do.
>
> Regards,
> /Niels
>
> --
> Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. > Internet email is subject to wholesale government surveillance.

--001a114fc15232091d052c748593-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 23 23:25:11 2016 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 992FC1B4348 for ; Tue, 23 Feb 2016 23:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 nj2Ao7FdFIl1 for ; Tue, 23 Feb 2016 23:25:10 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 5A0541B4249 for ; Tue, 23 Feb 2016 23:25:10 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3589B8607C; Wed, 24 Feb 2016 07:25:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id E114786066; Wed, 24 Feb 2016 07:25:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 57ED285EC7 for ; Tue, 23 Feb 2016 22:00:23 +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 Vhhr85xCuK0B for ; Tue, 23 Feb 2016 22:00:22 +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 A66B084CBD for ; Tue, 23 Feb 2016 22:00:22 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Tue, 23 Feb 2016 22:00:21 +0000 Date: Tue, 23 Feb 2016 22:00:21 +0000 Subject: Re: AEAD in ssh X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1100347732-1476@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , Bryan Ford Cc: "Mark D. Baushke" , Stephen Farrell , ietf-ssh@NetBSD.org, Watson Ladd , Daniel Migault , Curdle Chairs Content-Type: multipart/alternative; boundary="=-d/I3qtKG3R8ZpkOpTUxl" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-d/I3qtKG3R8ZpkOpTUxl Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've recently been implementing AES-GCM, and it has so far involved conside= rable architectural changes. The Bitvise SSH implementation abstracts crypt= ography into a pluggable crypto provider. Previously, the API to the crypto= provider was low-level, and the SSH implementation made the calls to encry= pt, decrypt, and calculate MAC. In order to implement AEAD, this had to be = turned on its head, so that the interface to the crypto provider is now fai= rly high-level. The crypto provider must now have awareness of the SSH pack= et format. To keep the same interface for AEAD and traditional ciphers, I h= ad to move the job of encrypting and decrypting a packet from the SSH imple= mentation into the crypto provider. (The alternative would be to have two i= nterfaces.) My point is that implementing AEAD may likely require restructuring as it i= s. I'm not sure this is a reason to dismiss the idea of encrypting the leng= th of the next packet as part of the previous packet. A good reason to set it aside, I think, is that we have a solution that's a= rchitecturally simpler than this. I think lengths in AEAD should just be en= crypted with the same underlying block cipher in CTR mode. No AEAD instance= required. Niels M=C3=B6ller , 2/23/2016 6:41 PM: Bryan Ford writes:=20 =20 > I can understand that position. However, one potentially=20 > counter-balancing consideration is that the introduction of new=20 > AEAD-based ciphersuites inherently introduces a new,=20 > wire-protocol-incompatible =E2=80=9Crecord format=E2=80=9D anyway that ne= eds to be=20 > negotiated.=20 =20 I agree, but at least it's only a different per-packet transformation.=20 Having to guess future packet sizes or emit extra packets is much more=20 than a new record format. I don't think it's a good tradeoff, too much=20 new complexity for little benefit.=20 =20 My understanding is that cleartext length fields are believed to be=20 secure, in that the only thing leaked are message boundaries. And hiding=20 them using a separate stream cipher is a simple way to stop that leak=20 (and the benefit of doing that is under debate). In particular, the even=20 simpler alternative, to apply the AEAD to the 4-byte length field,=20 including authentication, seems like overkill. =20 =20 I think simplicity is essential for making progress here, if we go for a=20 design of ssh version 3, discussion will never end.=20 =20 > Deferring useful record format changes until the next major protocol=20 > version,=20 =20 I don't expect any need for a new major version of the ssh protocol for=20 the next one or two decades. It's not too painful to add aead support=20 (and all other additions of new algorithms have been smooth, as far as I=20 can tell).=20 =20 Regards,=20 /Niels=20 =20 -- =20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26.=20 Internet email is subject to wholesale government surveillance.=20 = --=-d/I3qtKG3R8ZpkOpTUxl Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've recently been implementing AES-GCM, and it ha= s so far involved considerable architectural changes. The Bitvise SSH imple= mentation abstracts cryptography into a pluggable crypto provider. Previous= ly, the API to the crypto provider was low-level, and the SSH implementatio= n made the calls to encrypt, decrypt, and calculate MAC. In order to implem= ent AEAD, this had to be turned on its head, so that the interface to the c= rypto provider is now fairly high-level. The crypto provider must now have = awareness of the SSH packet format. To keep the same interface for AEAD and= traditional ciphers, I had to move the job of encrypting and decrypting a = packet from the SSH implementation into the crypto provider. (The alternati= ve would be to have two interfaces.)

My point is that implementing A= EAD may likely require restructuring as it is. I'm not sure this is a reaso= n to dismiss the idea of encrypting the length of the next packet as part o= f the previous packet.

A good reason to set it aside, I think, is th= at we have a solution that's architecturally simpler than this. I think len= gths in AEAD should just be encrypted with the same underlying block cipher= in CTR mode. No AEAD instance required.


Niels M=C3=B6ller <nisse@lysator.liu.se> , 2/23/= 2016 6:41 PM:
Bryan Ford <brynosaurus@gmail.com> writes:

> I can understand that position. However, one potentially
> counter-balancing consideration is that the introduction of new
> AEAD-based ciphersuites inherently introduces a new,
> wire-protocol-incompatible =E2=80=9Crecord format=E2=80=9D anyway = that needs to be
> negotiated.

I agree, but at least it's only a different per-packet transformation.
Having to guess future packet sizes or emit extra packets is much more
than a new record format. I don't think it's a good tradeoff, too much
new complexity for little benefit.

My understanding is that cleartext length fields are believed to be
secure, in that the only thing leaked are message boundaries. And hidin= g
them using a separate stream cipher is a simple way to stop that leak
(and the benefit of doing that is under debate). In particular, the eve= n
simpler alternative, to apply the AEAD to the 4-byte length field,
including authentication, seems like overkill.=20

I think simplicity is essential for making progress here, if we go for = a
design of ssh version 3, discussion will never end.

> Deferring useful record format changes until the next major protoc= ol
> version,

I don't expect any need for a new major version of the ssh protocol for
the next one or two decades. It's not too painful to add aead support
(and all other additions of new algorithms have been smooth, as far as = I
can tell).

Regards,
/Niels

--=20
Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
= --=-d/I3qtKG3R8ZpkOpTUxl-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 23 23:25:34 2016 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 386DC1B4698 for ; Tue, 23 Feb 2016 23:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 uKS4-RhTAEBp for ; Tue, 23 Feb 2016 23:25:33 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 347DE1B468B for ; Tue, 23 Feb 2016 23:25:33 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B00A68607B; Wed, 24 Feb 2016 07:25:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 5160786066; Wed, 24 Feb 2016 07:25:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4CA1885E5B for ; Tue, 23 Feb 2016 17:03:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id M2NtiH44ffSZ for ; Tue, 23 Feb 2016 17:03:57 +0000 (UTC) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 86E5985E1E for ; Tue, 23 Feb 2016 17:03:57 +0000 (UTC) Received: by mail-pf0-x236.google.com with SMTP id e127so115474465pfe.3 for ; Tue, 23 Feb 2016 09:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=aow8QLbXoYIh/SymnGLoNKfH40/wIPxV0QN7wCq4ikY=; b=r352kDjIhSEHnSme1JMQkXjgu7AQ3kFf3KYaQCBfU4+MlnVuq/1j84lfIHDYIvq8bC hUSkFMCpgo9BQpFS9KGOSqU2RZRxykS79baSC6g40OKSMwkfghZABZ3ep7IExeyWoOrp z4VX19yaSJfaeJBwaYcMardLdVXh7W4p1KPcn1j/fp5ScOyAHT1onthoL94OMOpZguBv sjNmEHKYyN+9NsPSAgnu95as1dKuwyQ/VNqFQ9uZuQeKsyFG2R/aC3DOeREtuxz8Tz3r EDpctD/U626onbGrCTBRlkLlCYSf3SC6titdQe287k76l7pjcqCW/2lvkTwo3WHCxMGL twcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=aow8QLbXoYIh/SymnGLoNKfH40/wIPxV0QN7wCq4ikY=; b=K+Ktd7Rf5+n0pICD8Ud6R6jUJoszJ6Tb20aEmltnkj5jLK3lhQbLsNVbfcv1D1/Y9H OnRoWiwMy/oH9gz1T1Ah9MBvopTiqN1SABFkvq0fVT/q6+JQsYjmkVN+Yp8Ef511BEm1 t1OFBA5Ie7olKYphi1j13ufc+Ex2oBydJLKQJJAF4LqeW5j6Nz8q4Rwy/8CDzzQQSjvR QWuB18dPBvglnS3JNXcaIwmMfo0HKGSQJRpmLOVzTO1he9MIFs1HpRGNSd0g24lVyR/h a22w2QqLu8SKj8d3wNThKgbeJ5OYf2FupNfMKGWJFFRpLzn0t89II9STnKlC6WHOYDLK 3Jkg== X-Gm-Message-State: AG10YOSprL74JFvqddjiJvdEZVAm/3R59cJv4nUaIpIB1iFrMFklLVYJlpSLW8e5pX8JVg== X-Received: by 10.98.10.86 with SMTP id s83mr47700222pfi.85.1456247037055; Tue, 23 Feb 2016 09:03:57 -0800 (PST) Received: from [172.25.0.204] (rrcs-67-52-140-5.west.biz.rr.com. [67.52.140.5]) by smtp.gmail.com with ESMTPSA id p21sm45450699pfj.67.2016.02.23.09.03.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Feb 2016 09:03:55 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_B60170FC-0F31-4067-A7CC-10BF5C8B0997"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: AEAD in ssh From: Bryan Ford In-Reply-To: Date: Tue, 23 Feb 2016 09:03:53 -0800 Cc: "Mark D. Baushke" , denis bider , Stephen Farrell , ietf-ssh@NetBSD.org, Watson Ladd , Daniel Migault , Curdle Chairs Message-Id: <161DEFB5-1564-4F96-8E87-AE98BB07925E@gmail.com> References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> To: =?utf-8?Q?Niels_M=C3=B6ller?= X-Mailer: Apple Mail (2.3112) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_B60170FC-0F31-4067-A7CC-10BF5C8B0997 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 23, 2016, at 7:56 AM, Niels M=C3=B6ller = wrote: > Bryan Ford writes: >=20 >> I see that in 3.1 on =E2=80=9CEncrypting the packet length=E2=80=9D, = you=E2=80=99ve suggested >> the same approach as one of the earlier approaches I suggested a = while >> ago in the corresponding TLS discussion. That=E2=80=99s a reasonable = approach >> and I think would work, but I wanted to make sure you=E2=80=99re = aware of >> another alternative that I=E2=80=99ve come to think is both cleaner = and safer: >> just embed the length of the next packet within the normal >> AEAD-encrypted payload of its immediately prior packet. >=20 > Thanks for the update.=20 >=20 > This could make a lot of sense for a new protocol or for a larger > protocol update. But I think adding the length field to the preceding > packet is a too large structural change of the ssh protocol to do just > to support AEAD ciphers. I can understand that position. However, one potentially = counter-balancing consideration is that the introduction of new = AEAD-based ciphersuites inherently introduces a new, = wire-protocol-incompatible =E2=80=9Crecord format=E2=80=9D anyway that = needs to be negotiated. No one will be able to decrypt a new = AEAD-encrypted record anyway unless it understands the new AEAD spec; it = wouldn=E2=80=99t be that hard for it to interpret the encrypted contents = of that record a bit differently at the same time. =20 This AEAD-induced incompatible change thus presents a natural point in = time in which to introduce other (minor) changes relatively painlessly = in the encrypted content of those records, without introducing any = =E2=80=9Cnew=E2=80=9D negotiation mechanisms. Just specify that all = legacy (non-AEAD) ciphers always use the =E2=80=9Cold=E2=80=9D internal = packet format, and new (AEAD) ciphers always use the =E2=80=9Cnew=E2=80=9D= internal packet format. Deferring useful record format changes until the next major protocol = version, in contrast, creates the risk that implementations of the next = major protocol version will need to support at least (a) legacy non-AEAD = ciphers using the old format, (b) AEAD ciphers using the old format, and = (c) AEAD ciphers using the new format. That=E2=80=99s more moving = parts, more protocol complexity, and greater risk of security bugs = compared with just being able to deal with situations (a) and (c) alone. Just some tradeoffs to be considered anyway. B= --Apple-Mail=_B60170FC-0F31-4067-A7CC-10BF5C8B0997 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMjMxNzAzNTRaMCMGCSqGSIb3DQEJBDEWBBSZsD7xPQwjwh8YChUUC86r4KfqBTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAWOZBOdQ3ioxqqRzmymUoNBxQ9NuhUgWP7ai/8iOQYf8+5tUpSBkA6rQOZ/SJFhUe SNGQ6Xs2qVgm76IO22HuHh+Vfds1qT3lpi6c2pOtOSKILfsS5Rh6cC1qyOfF06SegHI+xDjS/4v7 q3FmWrVWO2IxO0+ZUZcgDzWfcOpajVhJXHnnylo86yaLrfaI1CrOOvuBKD3SCjyqMndrr7oPocUs 3FW3hcJvOxdfDqlrNxx7R+iT75rnBav1CT45ZqZBu9fqZLOC8cP+xDlORzcHx7HwWHfYgZDkHngn mIohP0eJ3lXI+PE8AbtUEM7GiGiqQbte4tnFN1sm7iNbtHe3sQAAAAAAAA== --Apple-Mail=_B60170FC-0F31-4067-A7CC-10BF5C8B0997-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Feb 23 23:25:56 2016 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 8DE481B3217 for ; Tue, 23 Feb 2016 23:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 JYj3iYForKCa for ; Tue, 23 Feb 2016 23:25:55 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 70E241A8A6E for ; Tue, 23 Feb 2016 23:25:55 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id EA0748607D; Wed, 24 Feb 2016 07:25:54 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 74FE686066; Wed, 24 Feb 2016 07:25:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 70E928603F for ; Tue, 23 Feb 2016 14:15:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bHSS06jLeA9b for ; Tue, 23 Feb 2016 14:15:56 +0000 (UTC) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 9314F84CBD for ; Tue, 23 Feb 2016 14:15:56 +0000 (UTC) Received: by mail-pf0-x233.google.com with SMTP id x65so112997285pfb.1 for ; Tue, 23 Feb 2016 06:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AIu2ZQN7uBIvKYh36aJ3dFN2jtSUE+wwXiP17jU7quk=; b=usltOhzfLR0ZnVZrfiOatYC8FekesQgDVgmCi59BN8bga7Sj94halXBuV4j7xDTvgq olulvHZ4oKoDOB4zhKvYNhqs5RpMYR0kW6I7XSFZjL5blYNp5kBc5mIXPRUiDMC5QUW7 Kopj0hnPgElRGVAf674TjknXQKhf704geTyo+qQtw4o526ifbqae0deVo85ES33QE4WJ /IR7owJAPs+b27zoFHAkhefRiJise4Q/bo0UfK0r+KTmUemDh252U2zJwzNRgWo2KGbi MKXcNC7qZDvFYbswa6Y5cg6D4kF6mmwsDhoqwoBolKYquhYqKwF7b0fuY645799zpzPg RBFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=AIu2ZQN7uBIvKYh36aJ3dFN2jtSUE+wwXiP17jU7quk=; b=e8UOgtMrYrM1eWRtA6acFK6EVVkoZjtSMsxTo6DVP87RhWngJ6Qj6/tZWoc8MovB/h 7YJaE+/fMXVwWE6RlNqS/h3WP+XVRjN1eLCTn/BJAuTUPczIYHrgPGpWN9s3lGRdL5n0 iGovV5eRVJUufGAUKyl/ZW+F9L3aIZNtwPW8VGHJg08wnEhktsexJkqO+dQP19I/fKRC B0xMviOWtZrwyEV0GLoRL/MOoAXu931K+Dyfh9RK1M3TomJ/foponlwQeMS20ldYEdVP JOizIUv6k5nvtLcb151uFy9PlTc2OU+MHh1RZswTckdPUZ+kUys6ebvD3kmsRILDT5Pc QpPw== X-Gm-Message-State: AG10YORX3QxfiuKS9p5QvFCDWZ8gXhOdF0zj21/KVjFif+iXZmhiGUofNRsUIXoIL6eVyA== X-Received: by 10.98.93.211 with SMTP id n80mr46909152pfj.61.1456236956072; Tue, 23 Feb 2016 06:15:56 -0800 (PST) Received: from [172.25.0.204] (rrcs-67-52-140-5.west.biz.rr.com. [67.52.140.5]) by smtp.gmail.com with ESMTPSA id ud10sm44865985pab.27.2016.02.23.06.15.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Feb 2016 06:15:53 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_BD9E227C-B75A-4621-A75E-F002EAD3D64A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: AEAD in ssh From: Bryan Ford In-Reply-To: Date: Tue, 23 Feb 2016 06:15:52 -0800 Cc: "Mark D. Baushke" , denis bider , Stephen Farrell , ietf-ssh@NetBSD.org, Watson Ladd , Daniel Migault , Curdle Chairs Message-Id: <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> To: =?utf-8?Q?Niels_M=C3=B6ller?= X-Mailer: Apple Mail (2.3112) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_BD9E227C-B75A-4621-A75E-F002EAD3D64A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 22, 2016, at 12:47 AM, Niels M=C3=B6ller = wrote: > I've now posted a first version, > https://www.ietf.org/id/draft-nisse-secsh-aead-00.txt. I was advised = by > a collegue with a bit more ietf experience to include one concrete = AEAD. > So I added chacha-poly1305, to define something which is actually > implementable. Looks good. =20 I see that in 3.1 on =E2=80=9CEncrypting the packet length=E2=80=9D, = you=E2=80=99ve suggested the same approach as one of the earlier = approaches I suggested a while ago in the corresponding TLS discussion. = That=E2=80=99s a reasonable approach and I think would work, but I = wanted to make sure you=E2=80=99re aware of another alternative that = I=E2=80=99ve come to think is both cleaner and safer: just embed the = length of the next packet within the normal AEAD-encrypted payload of = its immediately prior packet. =20 This approach avoids either breaking the AEAD abstraction, or having to = =E2=80=9Cmisuse=E2=80=9D an AEAD as a stream cipher. It improves = efficiency by ensuring that the AEAD cipher primitive needs to be = invoked per packet, not twice. It improves security by ensuring that no = packet-length field is ever used in any way by the receiver before = it=E2=80=99s been cryptographically authenticated. In particular, it = eliminates the classic vulnerability where an attacker can corrupt the = length bits to make the length appear large and cause the receiver to = hang indefinitely on a long socket read(). The obvious, and I think only, key question is how the sender = =E2=80=9Cknows=E2=80=9D in advance what length to promise for the next = record, given that it can=E2=80=99t really see into the future. But = there are plenty of reasonable answers, from dead-simple to somewhat = smarter. A dead-simple sender could always send packets in pairs, the = first being minimum-size (e.g., zero-payload-bytes) but indicating the = second one=E2=80=99s length, the second packet containing the useful = variable-length payload. A slightly smarter sender could recognize when = it has a lot of data buffered (e.g., during file transfer) and send runs = of large packets and =E2=80=9Cpromise=E2=80=9D a minimum-sized one only = when its tx buffer runs dry.=20 A sender that pads for traffic analysis protection could always pad = packets to the same length, and thus trivially knows what to = =E2=80=9Cpromise=E2=80=9D in every packet. A smarter sender with = traffic analysis protection could pad packets to *multiples* of the same = length opportunistically when there is enough data in the tx buffer; = that=E2=80=99s more CPU- and bandwidth-efficient but to an adversary it = still looks indistinguishable from N of the shorter packets. There are more details in the relevant E-mails I posted back in December = on the TLS list: - = https://www.ietf.org/mail-archive/web/tls/current/msg18524.html - = https://www.ietf.org/mail-archive/web/tls/current/msg18710.html Cheers Bryan --Apple-Mail=_BD9E227C-B75A-4621-A75E-F002EAD3D64A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMjMxNDE1NTJaMCMGCSqGSIb3DQEJBDEWBBQgYwCGwyxm1JD2b+xOLnnYsjVHgDCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEANNAptVXNj/14t6osW1Cuf/lxNWjFDnq88x4qC1bbHO9bmnMzvbNIR1RfGFPxxa6n FIdo8Mp376mQyKHQB6xMliYz7+bPlfRQHwoJeZ+mEJRr4GQNPGioyRJ2df1z7fWAechbDXP5DXMi 9C6bIeioPWdJGL73dz6UZCxPEEZUYW4NzbS+uPL5S02X6I76JUIg4J/s+1wT2Zj60S3FJBnb66Nz J9SX8bjOypmN9xrQBWUuU+MFdmuX0jaVwl7TXdrO8gIP/VCyPryVLOC74do0InOwna0eHPelJrzn giTPaUU7n8L+fli+eSviEfs5BT3Ls/3fv3lpR0CJgSL0TnxkJAAAAAAAAA== --Apple-Mail=_BD9E227C-B75A-4621-A75E-F002EAD3D64A-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Feb 24 01:51:08 2016 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 4439B1B4971 for ; Wed, 24 Feb 2016 01:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 oVMyVpBD7rQb for ; Wed, 24 Feb 2016 01:51:07 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 5C0E81B4970 for ; Wed, 24 Feb 2016 01:51:06 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6908D86061; Wed, 24 Feb 2016 09:51: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 DDD9185E8D for ; Wed, 24 Feb 2016 09:51: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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id G9sgm5GFAhYW for ; Wed, 24 Feb 2016 09:51:02 +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 BFDCE85E6E for ; Wed, 24 Feb 2016 09:50:58 +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=1456307462; x=1487843462; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eGD0+t5P80FI6xpnSbYBfu3xWnZpih0l7bcf3kNaozM=; b=u4xIVqjAG1VTpL05hJNrGhdQxGE+uYXbxqvl+eRqK2A6CqDeYI+oddLY rsh9FF1QPUlt2X3WO3l/m250B3HFG8WlB+X+FYk5QCQERjoTV9tuwVQHD M1ABmV9PW1S9OxUU9zr8R2u+ZPFd+OI/JuclDibuzB6TJSmzFXtCcR/E3 TVo+xuFWGtUOP1gVX/1h7lZcynoMYnhrfDDue8k234gL0iMr3XGtMhzT7 q8WAG0+fp5ueXeAWzn0kWp1pTr9PGuTICzP68eO/02iP2+WIJlKX3vgn9 og4Lab3VdL0rBfNKZzFfei0wqgu08fe96+lXa4oRheow8MduSidOyTHK9 A==; X-IronPort-AV: E=Sophos;i="5.22,493,1449486000"; d="scan'208";a="70159246" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Feb 2016 22:50:28 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Wed, 24 Feb 2016 22:50:28 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Niels_M=F6ller?= , Bryan Ford CC: "Mark D. Baushke" , denis bider , Stephen Farrell , "ietf-ssh@NetBSD.org" , Watson Ladd , Daniel Migault , "Curdle Chairs" Subject: RE: AEAD in ssh Thread-Topic: AEAD in ssh Thread-Index: AQHRbmnaBfOcnKvI/0qJ+8iBK4Zo5J8688Hu Date: Wed, 24 Feb 2016 09:50:27 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BFF50B@uxcn10-5.UoA.auckland.ac.nz> References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> <161DEFB5-1564-4F96-8E87-AE98BB07925E@gmail.com>, In-Reply-To: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels M=F6ller writes:=0A= =0A= >My understanding is that cleartext length fields are believed to be secure= ,=0A= >in that the only thing leaked are message boundaries.=0A= =0A= They actually leak nothing, in that encrypting the length provides no secur= ity=0A= benefit at all. See for example "Peek-a-Book, I Still See You: Why Efficie= nt=0A= Traffic Analysis Countermeasures Fail" by Dyer, Coult, Ristenpart and=0A= Shrimpton. Their analysis, of TLS traffic with unencrypted lengths, complet= ely=0A= ignores TLS' plaintext length fields because they're irrelevant.=0A= =0A= The encryption-of-lengths debate is a classic example of the assume-a-can-= =0A= opener problem:=0A= =0A= A physicist, a chemist, and an economist were stranded on a desert island= =0A= with no implements and a can of food. The physicist and the chemist each= =0A= devised an ingenious mechanism for getting the can open; the economist=0A= merely said, "Assume we have a can opener".=0A= =0A= Instead of debating endlessly over the most efficient way to apply the assu= med=0A= can opener (encryption of lengths), we need to look at whether it serves an= y=0A= purpose (as Dyer at el point out, it doesn't), and if it does serve a purpo= se,=0A= whether it's worth the tradeoffs involved in implementing it (for which see= =0A= the previous point).=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Feb 24 01:52:15 2016 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 B23281B46F1 for ; Wed, 24 Feb 2016 01:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 qpLWgzzhN_cq for ; Wed, 24 Feb 2016 01:52:15 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 1BF851ACF03 for ; Wed, 24 Feb 2016 01:52:15 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B33C486084; Wed, 24 Feb 2016 09:52:14 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2AF9285E8D for ; Wed, 24 Feb 2016 09:52:13 +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 PtIwhDzPfbGl for ; Wed, 24 Feb 2016 09:52:12 +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 3EFA885E6E for ; Wed, 24 Feb 2016 09:52:11 +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=1456307532; x=1487843532; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IteSn9SKrU8XHFFvWuqqrDV9DUVH7gXJ7SYiiOuL9g8=; b=A/9RBETKUuWW+StsU05+37oMFk9cGpu8XbB24Ba/KEA9AI/F2FGe+Ar5 9itPwz0W2c9JksBws9j4B2ic45wsEvsvzR3PFaln9TBr2mb/3R/9Xc2FZ WCJOLHZpP/nzC8L1ngZfI01kkOovhrwxGZ8T3bhlmanIV+rZ13KByeJOz mSH2JEBjz+OkYGs4kvSCuUrj963FYIlINP+F2AsGm5ERPzqKl231P7EVa F5c6WgRaaeg6iFyLGgvoDztwsOSElui+X1ZSuAD2q/fRd+z327X4XQJD3 Odc824AU7cqsRp5OHIGbxw8/RtrIHBD2VsLzWlxeBCIJMZ92Ugj7eHwer Q==; X-IronPort-AV: E=Sophos;i="5.22,493,1449486000"; d="scan'208";a="70159390" 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/AES256-SHA; 24 Feb 2016 22:52:09 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Wed, 24 Feb 2016 22:52:09 +1300 From: Peter Gutmann To: denis bider , Watson Ladd , =?iso-8859-1?Q?Niels_M=F6ller?= CC: Bryan Ford , Daniel Migault , "ietf-ssh@netbsd.org" , Stephen Farrell , "Mark D. Baushke" , Curdle Chairs Subject: RE: AEAD in ssh Thread-Topic: AEAD in ssh Thread-Index: AQHRbobnBfOcnKvI/0qJ+8iBK4Zo5J869NYM Date: Wed, 24 Feb 2016 09:52:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BFF51D@uxcn10-5.UoA.auckland.ac.nz> References: ,<1102303688-2760@skroderider.denisbider.com> In-Reply-To: <1102303688-2760@skroderider.denisbider.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >That implementation, with unencrypted packet lengths, sabotages any hope o= f=0A= >thwarting traffic analysis, even through high-overhead SSH_MSG_IGNORE padd= ing.=0A= =0A= With encrypted packet lengths and padding you're still not thwarting traffi= c=0A= analysis, you're just making the job a lot more difficult for the implement= er.=0A= See my previous message.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Feb 24 16:17:01 2016 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 4C2FB1AC44D for ; Wed, 24 Feb 2016 16:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable 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 pP0eXgeQ-eEA for ; Wed, 24 Feb 2016 16:17:00 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 465A11AC44A for ; Wed, 24 Feb 2016 16:17:00 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2139F85EA8; Thu, 25 Feb 2016 00:16:59 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A8A2185E89 for ; Thu, 25 Feb 2016 00:16: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 IV7hj0vsT5WV for ; Thu, 25 Feb 2016 00:16:57 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id 8F24984D04 for ; Thu, 25 Feb 2016 00:16:53 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u1P0GGdB028540; Thu, 25 Feb 2016 10:16:16 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u1P0GGqq063066 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Feb 2016 10:16:16 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id u1P0GBqV020831; Thu, 25 Feb 2016 10:16:11 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id B48A3A4F32; Thu, 25 Feb 2016 11:16:11 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id B03E3A4F31; Thu, 25 Feb 2016 11:16:11 +1100 (AEDT) Date: Thu, 25 Feb 2016 11:16:11 +1100 (AEDT) From: Damien Miller To: Peter Gutmann cc: =?ISO-8859-15?Q?Niels_M=F6ller?= , Bryan Ford , "Mark D. Baushke" , denis bider , Stephen Farrell , "ietf-ssh@NetBSD.org" , Watson Ladd , Daniel Migault , Curdle Chairs Subject: RE: AEAD in ssh In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BFF50B@uxcn10-5.UoA.auckland.ac.nz> Message-ID: References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> <161DEFB5-1564-4F96-8E87-AE98BB07925E@gmail.com>, <9A043F3CF02CD34C8E74AC1594475C73F4BFF50B@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1456359379 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 24 Feb 2016, Peter Gutmann wrote: > They actually leak nothing, in that encrypting the length provides no > security benefit at all. See for example "Peek-a-Book, I Still See > You: Why Efficient Traffic Analysis Countermeasures Fail" by Dyer, > Coult, Ristenpart and Shrimpton. Their analysis, of TLS traffic with > unencrypted lengths, completely ignores TLS' plaintext length fields > because they're irrelevant. Peek-a-Boo makes clear that encrypted lengths aren't *sufficient*, but I don't think it's so clear that they aren't necessary or useful. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Feb 24 20:07:48 2016 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 42A441A901F for ; Wed, 24 Feb 2016 20:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] autolearn=unavailable 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 JC0TlNpBOGo4 for ; Wed, 24 Feb 2016 20:07:47 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 831771A8AF2 for ; Wed, 24 Feb 2016 20:07:47 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6A6B385ECC; Thu, 25 Feb 2016 04:07:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0998585EC9 for ; Thu, 25 Feb 2016 04:07:42 +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 Sh43ze5WSIf8 for ; Thu, 25 Feb 2016 04:07:41 +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 D52C085E74 for ; Thu, 25 Feb 2016 04:07:37 +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=1456373260; x=1487909260; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Xz2hY21SkHbQxPuviGXIqd9oNzflbS3QNF+JVaCuY4s=; b=vrq0g1tmuQYiarTud7vYUPl0A9MoeSpC6Q+UDYxFFRPuuqzaahGzjLYw tUSObwRJvDCKgZbBy6k0sWUBQ3RN0TYoTqlQ+k2wlar7JzWJS22cIkRnR es770fGDr7smS+C6jvCydBaHJXfPMjnvxFyn0+Fl4U+YlcyN5uAyLsS17 yw6wX+tdVJlIx4BgaumahCL7e8DbU7bpHLQ7JMc1WqqzzkwFPO/b39+yx D9ZC37H5toQAesamoKrxdTmye+Y/Tt8qzJhHby1t/QAlYJ6xbRgpmp1Ch RWBpaSJy37im0SH7mFXKdYqwSjs3eVALUYhPBcagjZixnXT9+RLS04mLC A==; X-IronPort-AV: E=Sophos;i="5.22,496,1449486000"; d="scan'208";a="70365206" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Feb 2016 17:07:34 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Thu, 25 Feb 2016 17:07:34 +1300 From: Peter Gutmann To: Damien Miller CC: =?Windows-1252?Q?Niels_M=F6ller?= , Bryan Ford , "Mark D. Baushke" , denis bider , Stephen Farrell , "ietf-ssh@NetBSD.org" , Watson Ladd , Daniel Migault , "Curdle Chairs" Subject: RE: AEAD in ssh Thread-Topic: AEAD in ssh Thread-Index: AQHRbmnaBfOcnKvI/0qJ+8iBK4Zo5J8688HugAAY84CAARptBA== Date: Thu, 25 Feb 2016 04:07:33 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C0025E@uxcn10-5.UoA.auckland.ac.nz> References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> <161DEFB5-1564-4F96-8E87-AE98BB07925E@gmail.com>, <9A043F3CF02CD34C8E74AC1594475C73F4BFF50B@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes:=0A= =0A= >Peek-a-Boo makes clear that encrypted lengths aren't *sufficient*, but I = =0A= >don't think it's so clear that they aren't necessary or useful.=0A= =0A= I assume you're referring to this subheading:=0A= =0A= Hiding packet lengths is not sufficient.=0A= =0A= This is followed by:=0A= =0A= We initiate a study of classifiers that do not directly use fine-grained = =0A= features such as individual packet lengths. The VNG++ classifier just =0A= mentioned uses only =93coarse=94 information, including overall time, tot= al =0A= bandwidth, and size of bursts. In fact, we provide a naiive Bayes =0A= classifier that uses only the total bandwidth for training and testing, = =0A= yet still achieves greater than 98% accuracy at k =3D 2 and 41% accuracy = at =0A= k =3D 128. =0A= =0A= So neither of the two classifiers they discuss use plaintext packet length = =0A= information even though it's readily available. They never really discuss = =0A= whether it's useful or not since they're totally ignoring it, because their= =0A= analysis doesn't need it in order to work.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Feb 24 20:17:58 2016 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 82D5B1B2CA2 for ; Wed, 24 Feb 2016 20:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 H2m-_LMt-IJZ for ; Wed, 24 Feb 2016 20:17:57 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 814011B2C82 for ; Wed, 24 Feb 2016 20:17:57 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 7FE5085EC9; Thu, 25 Feb 2016 04:17:56 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9DAFF85EB9 for ; Thu, 25 Feb 2016 04:17:53 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 9_4pzj7sCpJ6 for ; Thu, 25 Feb 2016 04:17:53 +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 90E7485E74 for ; Thu, 25 Feb 2016 04:17:52 +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=1456373872; x=1487909872; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CRHqerH4SJswp1+SMfIiICRnpAufc5j8i0Jax6wENoI=; b=YIh3W0bhj496rBulXDPcR8WRbSxqyZcCWmayrOCYUaxsoNc1dblLjRqp lQC5EEaMZnycvwHySBE3rJ/CSACzgOdBjesAiHouIxmEMV1sHmf7D+1dP qziG8JfaQiguwgsMpuojAs/WAgKR0sHT3vkT1GEo3Hc8LKEZicZO5j/za nHwMTvUmnNMBbdfPOfruuQvJglAA1XUldQtovUxKjvFvzquidJh7/ntvx iPzxuVx4RwAqUuuP1bkI26UMD99dsvfF/rk2pyEZENBihWw5FXACyicfu 8wI8QPaChsQGRHLDQdVmtAuEwwu148lSRuMb2tmeU5HEyXZdFsE5rQooJ A==; X-IronPort-AV: E=Sophos;i="5.22,496,1449486000"; d="scan'208";a="70367435" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Feb 2016 17:17:40 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Thu, 25 Feb 2016 17:17:40 +1300 From: Peter Gutmann To: denis bider , =?iso-8859-1?Q?Niels_M=F6ller?= CC: Bryan Ford , "Mark D. Baushke" , Stephen Farrell , Watson Ladd , Daniel Migault , "ietf-ssh@NetBSD.org" , Curdle Chairs Subject: RE: AEAD in ssh Thread-Topic: AEAD in ssh Thread-Index: AQHRb02qBfOcnKvI/0qJ+8iBK4Zo5J88J/5e Date: Thu, 25 Feb 2016 04:17:40 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C00292@uxcn10-5.UoA.auckland.ac.nz> References: <1184335675-492@skroderider.denisbider.com> In-Reply-To: <1184335675-492@skroderider.denisbider.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >I'm tempted to implement fixed-bandwidth SSH_MSG_IGNORE padding, just so I= =0A= >can point to an existing client and server which thwart traffic analysis, = =0A= >and need encrypted lengths.=0A= =0A= You'd need to point to actual analysis (of the kind done in Peek-a-boo) to= =0A= show that it works. That's the problem with SSH's encrypted lengths, twent= y=0A= years ago Tatu decided it was a good idea to use CRC32 as an ICV, RC4 as a= =0A= cipher, and encrypted lengths. Since then we've had attacks on CRC32, RC4,= =0A= and encrypted lengths. The response was to drop CRC32, drop RC4, and keep = =0A= using encrypted lengths even though the only thing they've demonstrably giv= en=0A= us so far is security vulnerabilities.=0A= =0A= The current discussion with AEAD is trying to perpetuate this cargo-cult = =0A= protocol design with increasingly awkward Rube-Goldberg hacks to try and = =0A= keep using something that was probably a mistake to begin with. Sure, it = =0A= was a well-intentioned mistake, but it doesn't do what people think it does= =0A= while at the same time creating real security vulnerabilities.=0A= =0A= >If my implementation consistently sends one ethernet frame (say 1450 bytes= ) =0A= >every 10 ms, this defeats traffic analysis at a cost of ~ 1.1 Mbps of fixe= d =0A= >bandwidth.=0A= =0A= So maybe we could do a profile for a special allegedly traffic-analysis =0A= resistant SSH, let's called it Data-oriented SSH or DoSSH, where you flood = a =0A= network link with unnecessary traffic. So if you wanted to DoSSH someone's= =0A= network you'd use that version, and everyone else could use standard SSH.= =0A= =0A= Peter.=0A= =0A= =0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Feb 25 03:53:03 2016 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 1E2CF1A1BB5 for ; Thu, 25 Feb 2016 03:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 WgSvwnOBTCYS for ; Thu, 25 Feb 2016 03:53:01 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 DE40A1A1BB0 for ; Thu, 25 Feb 2016 03:53:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B238C85EF7; Thu, 25 Feb 2016 11:53:00 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 70F4585EF2 for ; Thu, 25 Feb 2016 11:52:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id kJi64msDcvom for ; Thu, 25 Feb 2016 11:52:58 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 6BFDC85EEC for ; Thu, 25 Feb 2016 11:52:55 +0000 (UTC) Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::a86]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id u1PBqaK5019419 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 25 Feb 2016 12:52:37 +0100 Date: Thu, 25 Feb 2016 12:52:35 +0100 From: Simon Josefsson To: nisse@lysator.liu.se (Niels =?UTF-8?B?TcO2bGxlcg==?=) Cc: "Mark D. Baushke" , denis bider , Subject: Re: Curve25519/448 key agreement for SSH Message-ID: <20160225125235.3d72117f@latte.josefsson.org> In-Reply-To: References: <1023314969-1152@skroderider.denisbider.com> <874mg9y7s9.fsf@latte.josefsson.org> <423.1456071768@eng-mail01.juniper.net> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/zueZ+rZk0gK.ArpzO+k8p_g"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Sig_/zueZ+rZk0gK.ArpzO+k8p_g Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Den Mon, 22 Feb 2016 10:08:32 +0100 skrev Re: Curve25519/448 key agreement for SSH: > "Mark D. Baushke" writes: >=20 > > If so, why is the Key Exchange Method name "curve448-sha256" rather > > than "curve488-sha512" ? >=20 > I think Damien Miller's argument for using sha512 here makes sense: > "curve448 is a backup against as-yet-unknown attacks on curve25519. > Since we're not likely to need it, we might as well pair it with > SHA512 as a backup against as-yet-unknown attacks on SHA256." Hello Mark and Niels. Indeed there appears to be strong support from several people to couple Curve448 with SHA-512 instead of SHA-256. We are making this change and there will be a -04 out shortly. Mark's RFC quoting is a strong reason to make this change, but I believe there were sufficient motivation to do it anyway because of the hedge aspect. /Simon --Sig_/zueZ+rZk0gK.ArpzO+k8p_g Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWzusDAAoJEIYLf7sy+BGdSncIALHBL8hsPFMZlOHf/25wD96R Kzv7/tZdMYF1uNdZYM+vm0Wf/2cfQKpwtdSfD2Yw6rYQA+MXJwZcyZXhFdn4zoOk HdvKxEokLkZjxQw6UFw8HZxNrRrPiVcCD3bw8hssTS6tcAGlT05xYhdIWmb6nAgE xczKgDE7ZVtngUDI7JaX29JV/bjplWuDC7+/w4/+p4zzv9xJSQlC6BIQc9onP9YY TJwvKt3cqov7dExI98nuToQ5QPcJPCwdpi0OUumVpLYdo47gDncZNwoqDO/3zeeg 8yXCPib7y1qiQFQrTPwzme3rE9igWc9HucreKumf7fBEhSxQNAP4HlUmp3o2Wcw= =JQql -----END PGP SIGNATURE----- --Sig_/zueZ+rZk0gK.ArpzO+k8p_g-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Feb 25 21:47:04 2016 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 6912B1A1B28 for ; Thu, 25 Feb 2016 21:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 VjHw38mZBb-B for ; Thu, 25 Feb 2016 21:47:02 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 B069B1A1A91 for ; Thu, 25 Feb 2016 21:47:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2D6F185F25; Fri, 26 Feb 2016 05:47:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D3D3585EC9; Fri, 26 Feb 2016 05:47:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E6CBF85EE6 for ; Thu, 25 Feb 2016 12:31:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id IO5e6ltmyqkq for ; Thu, 25 Feb 2016 12:31:02 +0000 (UTC) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 BC40385E47 for ; Thu, 25 Feb 2016 12:31:01 +0000 (UTC) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id u1PCUQxQ023265 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 25 Feb 2016 13:30:27 +0100 From: Simon Josefsson To: denis bider Cc: "Mark D. Baushke" , Peter Gutmann , Niels =?iso-8859-1?Q?M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) References: <219217362-2196@skroderider.denisbider.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:160225:ietf-ssh3@denisbider.com::w/YnJyUJyH63av6w:1ze X-Hashcash: 1:22:160225:mdb@juniper.net::rDd750EjwBEisU2X:BwKr X-Hashcash: 1:22:160225:nisse@lysator.liu.se::nAlZd6EEQMeKenl3:WLMD X-Hashcash: 1:22:160225:pgut001@cs.auckland.ac.nz::mugST7CMYc62PVoo:B4l2 X-Hashcash: 1:22:160225:ietf-ssh@netbsd.org::nG1NI7BnuzMIPe3O:aP5i Date: Thu, 25 Feb 2016 13:30:25 +0100 In-Reply-To: <219217362-2196@skroderider.denisbider.com> (denis bider's message of "Sat, 13 Feb 2016 17:49:04 +0000") Message-ID: <87oab5t1jy.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable denis bider writes: > Comments: > > > - If we're being comprehensive, we should include a position with > regard to Curve25519 and Curve448: > > https://tools.ietf.org/html/draft-josefsson-ssh-curves-03 > > I suggest we take the following positions: > > curve25519-sha256=A0=A0=A0 SHOULD > curve448-sha256=A0=A0=A0=A0=A0 SHOULD, or MAY? > > That being said: > > > - Given the recent NSA recommendations, it seems to me it would be > prudent to update the Curve25519/Curve448 draft, and to replace the > SHA-256 algorithm with SHA-512 for Curve448. This would create the > method "curve448-sha512" instead of "curve448-sha256". > > Simon, what do you think? Could your draft be updated to do that? Yes, that will be part of -04. For what's it worth: I support curve25519-sha256 as MUST and curve448-sha512 as MAY in draft-baushke-ssh-dh-group-sha2. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWzvPhAAoJEIYLf7sy+BGdtUYIALJM2dYXfdAsl3tPy0hnYZR0 Lc7qX6Npa236NCkeb96MbczE1vAOK76D8n/jJTnOoXWscmPV5CEBYpKGVVUAwM/V Dgkn+HKAisiIpl7UDlegunTYBMNUcycj1HewHQNHp7/zxHrRSbYmWBLhSyNi02b+ I/KBppRcJHO9Zj3aI4EM1pAmJv71oFGESf2wHBcRNHx37OxA1ovbety8rsnXCHid QtWkhxjLyw38pu/QoSDV2HF835WtRNVlbA/ZXrv8E9+g6ILCrZ6EvEwacilbO+H/ 2gR2Wsz6Baxp2AlJV1qI5/QrE9HZDR/YbaKVY/3URy/Q/Xhx/MGd3voMEkyZ2Zs= =bCzK -----END PGP SIGNATURE----- --=-=-=-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Feb 25 21:47:20 2016 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 B82021A1BFF for ; Thu, 25 Feb 2016 21:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] autolearn=unavailable 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 M-5GbrOH0-HM for ; Thu, 25 Feb 2016 21:47:19 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 BC9261A1BEF for ; Thu, 25 Feb 2016 21:47:19 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5105E85F63; Fri, 26 Feb 2016 05:47:19 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0A65085EC9; Fri, 26 Feb 2016 05:47:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DB7A785F4C for ; Thu, 25 Feb 2016 20:05:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id OoH8hJX3oJOQ for ; Thu, 25 Feb 2016 20:05:57 +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 5967285EFB for ; Thu, 25 Feb 2016 20:05:57 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Thu, 25 Feb 2016 20:05:55 +0000 Date: Thu, 25 Feb 2016 20:05:55 +0000 Subject: Re: AEAD in ssh X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1266469733-2760@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann Cc: =?UTF-8?q?Niels_M=C3=B6ller?= , Bryan Ford , "Mark D. Baushke" , Stephen Farrell , Watson Ladd , Daniel Migault , Curdle Chairs , ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-j9ChPccrbTA6wQ5ncgtC" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-j9ChPccrbTA6wQ5ncgtC Content-Type: text/plain; charset="utf-8" > You'd need to point to actual analysis (of the kind done in Peek-a-boo) to show that it works. If I restrict myself to send the same amount of data, at regular intervals, independent of my packet queue; if I pick up packets from my queue if they are any, and send IGNORE messages otherwise; then this prevents keystroke analysis if done in 10 second bursts; and if I keep it up, it masks everything done on the connection. A paper is not useful to show that this works. It evidently works. Yet, we cannot prove a negative. There are possible ways to get it wrong in practice. If you can think of an attack, a paper can show if that particular attack is viable. But if you can't think of an attack, you can't write a paper to prove there isn't one. > twenty years ago Tatu decided it was a good idea to use CRC32 > as an ICV, RC4 as a cipher, and encrypted lengths By the same logic, Tatu also used C. Maybe we shouldn't use C because Tatu used that. > So maybe we could do a profile for a special allegedly > traffic-analysis resistant SSH, let's called it > Data-oriented SSH or DoSSH, You crack this joke, just after I pointed out that this costs 1 Mbps or less, whereas Netflix uses 3 - 5 Mbps. This is when Google Fiber is rolling out in the US, and we can expect 1 Gbps speeds to be normal in 15 years (if backward thinking people don't stop it). You appear to be engaging in deliberate misunderstandings. There's a repeated claim being made that there's an ongoing controversy about this topic. I'm now beginning to think that this would not be as much the case if we eliminated low-quality arguments. --=-j9ChPccrbTA6wQ5ncgtC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > You'd need to point to actual analysis (of th= e kind done in Peek-a-boo) to show that it works.

If I restrict myse= lf to send the same amount of data, at regular intervals, independent of my= packet queue; if I pick up packets from my queue if they are any, and send= IGNORE messages otherwise; then this prevents keystroke analysis if done i= n 10 second bursts; and if I keep it up, it masks everything done on the co= nnection.

A paper is not useful to show that this works. It evidentl= y works. Yet, we cannot prove a negative. There are possible ways to get it= wrong in practice.

If you can think of an attack, a paper can show = if that particular attack is viable. But if you can't think of an attack, y= ou can't write a paper to prove there isn't one.


> twenty yea= rs ago Tatu decided it was a good idea to use CRC32
> as an ICV, RC4 = as a cipher, and encrypted lengths

By the same logic, Tatu also used= C. Maybe we shouldn't use C because Tatu used that.


> So may= be we could do a profile for a special allegedly
> traffic-analysis r= esistant SSH, let's called it
> Data-oriented SSH or DoSSH,

Yo= u crack this joke, just after I pointed out that this costs 1 Mbps or less,= whereas Netflix uses 3 - 5 Mbps. This is when Google Fiber is rolling out = in the US, and we can expect 1 Gbps speeds to be normal in 15 years (if bac= kward thinking people don't stop it).

You appear to be engaging in d= eliberate misunderstandings.

There's a repeated claim being made tha= t there's an ongoing controversy about this topic. I'm now beginning to thi= nk that this would not be as much the case if we eliminated low-quality arg= uments.

= --=-j9ChPccrbTA6wQ5ncgtC-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Feb 25 21:47:29 2016 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 673B31A1BFF for ; Thu, 25 Feb 2016 21:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] autolearn=unavailable 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 yabQMWkHos3F for ; Thu, 25 Feb 2016 21:47:28 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 943F51A1BEF for ; Thu, 25 Feb 2016 21:47:28 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 66ECF85F62; Fri, 26 Feb 2016 05:47:28 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 20D4385EC9; Fri, 26 Feb 2016 05:47:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AC8AE860CF for ; Wed, 24 Feb 2016 22:12:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id tUO_XRFHC8wF for ; Wed, 24 Feb 2016 22:12:21 +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 36F9385E6A for ; Wed, 24 Feb 2016 22:12:21 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Wed, 24 Feb 2016 22:12:15 +0000 Date: Wed, 24 Feb 2016 22:12:15 +0000 Subject: Re: AEAD in ssh X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1188805182-3464@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann Cc: =?UTF-8?q?Niels_M=C3=B6ller?= , Watson Ladd , Bryan Ford , Daniel Migault , Stephen Farrell , "Mark D. Baushke" , Curdle Chairs , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-TzQLiLO3upqhLYTYj1jf" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-TzQLiLO3upqhLYTYj1jf Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If my implementation consistently sends one ethernet frame (say 1450 bytes)= every 10 ms, this defeats traffic analysis at a cost of ~ 1.1 Mbps of fixe= d bandwidth. Netflix uses 3 - 5 Mbps of fixed bandwidth. This protects a terminal session from keystroke analysis, while providing a= mple bandwidth. However, it needs encrypted lengths. ----- Original Message ----- From: Peter Gutmann=20 Sent: Wednesday, February 24, 2016 03:52 To: denis bider ; Watson Ladd ; Niels M=C3=B6ller=20 Cc: Bryan Ford ; Daniel Migault ; ietf-ssh@netbsd.org ; Stephen Farrell ; M= ark D. Baushke ; Curdle Chairs=20 Subject: RE: AEAD in ssh denis bider writes: >That implementation, with unencrypted packet lengths, sabotages any hope o= f >thwarting traffic analysis, even through high-overhead SSH_MSG_IGNORE padd= ing. With encrypted packet lengths and padding you're still not thwarting traffi= c analysis, you're just making the job a lot more difficult for the implement= er. See my previous message. Peter. = --=-TzQLiLO3upqhLYTYj1jf Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable If my implementation consistently sends one ethern= et frame (say 1450 bytes) every 10 ms, this defeats traffic analysis at a c= ost of ~ 1.1 Mbps of fixed bandwidth.

Netflix uses 3 - 5 Mbps of fix= ed bandwidth.

This protects a terminal session from keystroke analys= is, while providing ample bandwidth. However, it needs encrypted lengths.

----- Original Message -----
From: Peter Gutmann
Sent: Wed= nesday, February 24, 2016 03:52
To: denis bider ; Watson Ladd ; Niels M= =C3=B6ller
Cc: Bryan Ford ; Daniel Migault ; ietf-ssh@netbsd.org ; Step= hen Farrell ; Mark D. Baushke ; Curdle Chairs
Subject: RE: AEAD in ssh<= br>
denis bider <ietf-ssh3@denisbider.com> writes:

>That= implementation, with unencrypted packet lengths, sabotages any hope of
= >thwarting traffic analysis, even through high-overhead SSH_MSG_IGNORE p= adding.

With encrypted packet lengths and padding you're still not t= hwarting traffic
analysis, you're just making the job a lot more difficu= lt for the implementer.
See my previous message.

Peter.

= --=-TzQLiLO3upqhLYTYj1jf-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Feb 25 21:47:44 2016 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 337AC1A6F5A for ; Thu, 25 Feb 2016 21:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 cCYryzt3L2Ik for ; Thu, 25 Feb 2016 21:47:43 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 F3EDE1A21A4 for ; Thu, 25 Feb 2016 21:47:42 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9329685F66; Fri, 26 Feb 2016 05:47:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 4AE3385EC9; Fri, 26 Feb 2016 05:47:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D313B86084 for ; Wed, 24 Feb 2016 21:52:36 +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 E4mf5USpC3iq for ; Wed, 24 Feb 2016 21:52:36 +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 353B485E47 for ; Wed, 24 Feb 2016 21:52:36 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Wed, 24 Feb 2016 21:52:34 +0000 Date: Wed, 24 Feb 2016 21:52:34 +0000 Subject: Re: AEAD in ssh X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1184335675-492@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , Peter Gutmann Cc: Bryan Ford , "Mark D. Baushke" , Stephen Farrell , Watson Ladd , Daniel Migault , ietf-ssh@NetBSD.org, Curdle Chairs Content-Type: multipart/alternative; boundary="=-hFmZRjFZ7k9NQdm04Lu3" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-hFmZRjFZ7k9NQdm04Lu3 Content-Type: text/plain; charset="utf-8" Peter - see bottom. Niels: > What do you think of the way it is specified in the draft? > Which is well defined for an arbitrary AEAD, but boils > down to plain CTR mode for typical AEAD block cipher > modes, and boils down to plain cacha encryption > for chacha-poly1305? I think the intent is good, but the description is overly clever. You seem to recognize this: "For many AEAD algorithms, this seemingly complex procedure boils down to ..." Also, the described mechanism does not boil down exactly to CTR mode. The counter is initialized differently. It seems to me plain CTR would be better. It might be better to just ditch the complex description, and specify a separately-keyed instance of the underlying stream cipher. This might be either the cipher itself for ChaCha20; or a block cipher in CTR mode in the case of AES. > should lengths conceptually be packed back to back into > a stream to be encrypted four bytes at a time [...], > or should we use one underlying "block" per message? One underlying block per packet is slightly simpler with a block cipher. Back-to-back is more efficient - +0.25 or fewer additional block transformations per packet, instead of +1. I'm not sure that either option is problematic in terms of a timing side channel. A decent fixed-bandwidth implementation would be sending a fixed amount of data on a fixed timer. Back-to-back would make most sense with a stream cipher. It seems consistent to use the same with a block cipher in CTR mode. Peter: > encrypting the length provides no security benefit at all. > See for example "Peek-a-Book, I Still See You: Why Efficient > Traffic Analysis Countermeasures Fail" by Dyer, Coult, > Ristenpart and Shrimpton. This paper points out an inherent tradeoff between efficiency and pattern hiding. It says nothing about when efficiency does not matter, because you can maintain a fixed bandwidth. The problem with plaintext lengths is that they don't just defeat efficient countermeasures. They defeat ALL countermeasures to traffic analysis. In a time of always-on TV streaming, it's increasingly conceivable to maintain a fixed bandwidth for not only 10 second bursts, but for the entire connection. I'm tempted to implement fixed-bandwidth SSH_MSG_IGNORE padding, just so I can point to an existing client and server which thwart traffic analysis, and need encrypted lengths. I can then point to AES-GCM in our help text, and say: "This algorithm is not resistant to traffic analysis. It is counter-productive to enable it in conjunction with fixed-bandwidth connection padding." --=-hFmZRjFZ7k9NQdm04Lu3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Peter - see bottom.


Niels:

> = What do you think of the way it is specified in the draft?
> Which is= well defined for an arbitrary AEAD, but boils
> down to plain CTR mo= de for typical AEAD block cipher
> modes, and boils down to plain cac= ha encryption
> for chacha-poly1305?

I think the intent is goo= d, but the description is overly clever. You seem to recognize this:
"For many AEAD algorithms, this seemingly complex procedure boils down to = ..."

Also, the described mechanism does not boil down exactly to CTR= mode. The counter is initialized differently. It seems to me plain CTR wou= ld be better.

It might be better to just ditch the complex descripti= on, and specify a separately-keyed instance of the underlying stream cipher= . This might be either the cipher itself for ChaCha20; or a block cipher in= CTR mode in the case of AES.


> should lengths conceptually b= e packed back to back into
> a stream to be encrypted four bytes at a= time [...],
> or should we use one underlying "block" per message? <= br>
One underlying block per packet is slightly simpler with a block cip= her.

Back-to-back is more efficient - +0.25 or fewer additional bloc= k transformations per packet, instead of +1.

I'm not sure that eithe= r option is problematic in terms of a timing side channel. A decent fixed-b= andwidth implementation would be sending a fixed amount of data on a fixed = timer.

Back-to-back would make most sense with a stream cipher. It s= eems consistent to use the same with a block cipher in CTR mode.

Peter:

> encrypting the length provides no security benefit at a= ll.
> See for example "Peek-a-Book, I Still See You: Why Efficient> Traffic Analysis Countermeasures Fail" by Dyer, Coult,
> Risten= part and Shrimpton.

This paper points out an inherent tradeoff betwe= en efficiency and pattern hiding. It says nothing about when efficiency doe= s not matter, because you can maintain a fixed bandwidth.

The proble= m with plaintext lengths is that they don't just defeat efficient counterme= asures. They defeat ALL countermeasures to traffic analysis.

In a ti= me of always-on TV streaming, it's increasingly conceivable to maintain a f= ixed bandwidth for not only 10 second bursts, but for the entire connection= .

I'm tempted to implement fixed-bandwidth SSH_MSG_IGNORE padding, j= ust so I can point to an existing client and server which thwart traffic an= alysis, and need encrypted lengths.

I can then point to AES-GCM in o= ur help text, and say: "This algorithm is not resistant to traffic analysis= . It is counter-productive to enable it in conjunction with fixed-bandwidth= connection padding."

= --=-hFmZRjFZ7k9NQdm04Lu3-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Feb 25 21:48:39 2016 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 C263E1A21A4 for ; Thu, 25 Feb 2016 21:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] 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 fXbtjd5pg9gV for ; Thu, 25 Feb 2016 21:48:38 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 A541B1A1BFF for ; Thu, 25 Feb 2016 21:48:38 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 69D3985F25; Fri, 26 Feb 2016 05:48:38 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 184AF85EC9; Fri, 26 Feb 2016 05:48:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 86B7785ED1 for ; Thu, 25 Feb 2016 06:19:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id LudkNfx_FsKu for ; Thu, 25 Feb 2016 06:19:26 +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 9814E85ED0 for ; Thu, 25 Feb 2016 06:19:25 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3766F4003A; Thu, 25 Feb 2016 07:19:19 +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 9868840038; Thu, 25 Feb 2016 07:19:16 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 25 Feb 2016 07:19:16 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Peter Gutmann Cc: Bryan Ford , "Mark D. Baushke" , denis bider , Stephen Farrell , "ietf-ssh\@NetBSD.org" , Watson Ladd , Daniel Migault , "Curdle Chairs" Subject: Re: AEAD in ssh References: <1361670077-596@skroderider.denisbider.com> <62946.1454397657@eng-mail01.juniper.net> <7DBA88D2-7A40-4059-94BA-FD7D49BDA13A@gmail.com> <161DEFB5-1564-4F96-8E87-AE98BB07925E@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4BFF50B@uxcn10-5.UoA.auckland.ac.nz> Date: Thu, 25 Feb 2016 07:19:16 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BFF50B@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 24 Feb 2016 09:50:27 +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 Peter Gutmann writes: > They actually leak nothing, in that encrypting the length provides no sec= urity > benefit at all. See for example "Peek-a-Book, I Still See You: Why Effic= ient > Traffic Analysis Countermeasures Fail" by Dyer, Coult, Ristenpart and > Shrimpton. Their analysis, of TLS traffic with unencrypted lengths, compl= etely > ignores TLS' plaintext length fields because they're irrelevant. I've read that paper. It's good work, but I don't think it applies to all uses of ssh, and it doesn't apply at all to high-overhead padding. My understanding of that paper, as appliad to ssh, is that if you use ssh to download files (e.g., using tcp forwarding of browser traffic), the amount of data and the speed reveal a lot of what your downloading and from where. But that's only one of many ssh use cases. I'm more concerned about interactive use, in which case it may also be reasonable to use high-overhead padding). I agree completely that it's hard to defend against traffic analysis. But I disgree with your judgment that encrypted lenghts are totally useless period. I would also like to say that the intention of my draft is to leave this aspect of the protocol unchanged, because I think that's a decision orthogonal to AEAD support. Conversely, if I wanted to add encrypted length fields to TLS, I'd write a draft doing just that, not bundle that change with standardization of some other new features. 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 Sat Feb 27 00:22:39 2016 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 13E011B3793 for ; Sat, 27 Feb 2016 00:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.007 X-Spam-Level: X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 SAxKClImEEJF for ; Sat, 27 Feb 2016 00:22:36 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 BCA881B3794 for ; Sat, 27 Feb 2016 00:22:36 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0699C85ED6; Sat, 27 Feb 2016 08:22:36 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B3CCD85E6A; Sat, 27 Feb 2016 08:22:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BE3EE85F5E for ; Fri, 26 Feb 2016 11:15:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 5a6Lu8FDG9Tj for ; Fri, 26 Feb 2016 11:15:14 +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 4B36585E3C for ; Fri, 26 Feb 2016 11:15:14 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh@netbsd.org; Fri, 26 Feb 2016 11:15:07 +0000 Date: Fri, 26 Feb 2016 11:15:07 +0000 Subject: draft-ssh-fixed-bandwidth-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1321696115-2760@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1266469733-2760@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: ietf-ssh@netbsd.org Cc: =?UTF-8?q?Niels_M=C3=B6ller?= , "Mark D. Baushke" Content-Type: multipart/alternative; boundary="=-9sjDmBoITJL1StT+UZmH" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-9sjDmBoITJL1StT+UZmH Content-Type: text/plain; charset="utf-8" Hey everyone - pursuant to the recent discussion about what we can do about traffic analysis, I have written a draft for a mechanism to counter keystroke analysis, and generally provide more privacy for SSH terminal sessions. The first version of the draft is here: https://tools.ietf.org/html/draft-ssh-fixed-bandwidth-00 This does not go as far as providing a complete blanket of the entire SSH session, since I assume this would currently entail unattractive bandwidth tradeoffs. However, it does seem to me that this will provide much better privacy for SSH terminal sessions, at a very acceptable cost. The proposed mechanism is not defeated by unencrypted packet lengths. However, if packet lengths are encrypted, it will offer better privacy (fewer packets will stick out like sore thumbs because they can't be broken up, such as large channel requests); and when sending lots of data, it will be more efficient (less overhead due to larger packets allowed). I have requested my colleagues that we implement this for a future version of our SSH Server and Client. Comments welcome! denis --=-9sjDmBoITJL1StT+UZmH Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey everyone -

pursuant to the recent discu= ssion about what we can do about traffic analysis, I have written a draft f= or a mechanism to counter keystroke analysis, and generally provide more pr= ivacy for SSH terminal sessions. The first version of the draft is here:
https://tools.ietf.org/html/draft-ssh-fixed-bandwidth-00

This d= oes not go as far as providing a complete blanket of the entire SSH session= , since I assume this would currently entail unattractive bandwidth tradeof= fs. However, it does seem to me that this will provide much better privacy = for SSH terminal sessions, at a very acceptable cost.

The proposed m= echanism is not defeated by unencrypted packet lengths. However, if packet = lengths are encrypted, it will offer better privacy (fewer packets will sti= ck out like sore thumbs because they can't be broken up, such as large chan= nel requests); and when sending lots of data, it will be more efficient (le= ss overhead due to larger packets allowed).

I have requested my coll= eagues that we implement this for a future version of our SSH Server and Cl= ient.

Comments welcome!

denis

= --=-9sjDmBoITJL1StT+UZmH-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 28 01:23:15 2016 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 732241B3335 for ; Sun, 28 Feb 2016 01:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.094 X-Spam-Level: * X-Spam-Status: No, score=1.094 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 LG-4X6oGdp4t for ; Sun, 28 Feb 2016 01:23:14 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 6F3291B3334 for ; Sun, 28 Feb 2016 01:23:14 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id CA15385EC2; Sun, 28 Feb 2016 09:23:13 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 860F085E26; Sun, 28 Feb 2016 09:23:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DD6A085ED4 for ; Sun, 28 Feb 2016 02:54:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id gPYFeW_g8IFR for ; Sun, 28 Feb 2016 02:54: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 63E9584CEE for ; Sun, 28 Feb 2016 02:54:50 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Sun, 28 Feb 2016 02:54:48 +0000 Date: Sun, 28 Feb 2016 02:54:48 +0000 Subject: AEAD in SSH: Toss block alignment requirements X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1463563347-3264@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-03zM2rN/Ot24szm/2dEv" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-03zM2rN/Ot24szm/2dEv Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey everyone, while implementing the "fixed-bandwidth" proposal, I realize we ought to ge= t rid of block alignment requirements. Using AES-CTR and hmac-sha2-256, it's straightforward to pad outgoing packe= ts to some aligned size, e.g. 1024 bytes, using the following construction: =C2=A0 SSH_MSG_CHANNEL_DATA ciphertext - 16-byte aligned =C2=A0 SSH_MSG_CHANNEL_DATA mac - 32 bytes =C2=A0 SSH_MSG_IGNORE ciphertext - 16-byte aligned =C2=A0 SSH_MSG_IGNORE mac - 32 bytes All lengths are 16-byte aligned, so we can always target an aligned total s= ize. If we try to do the same with hmac-sha1, there's a problem. But hmac-sha1 i= s deprecated, so maybe that's not an issue. But with AEAD, we run into the issue again: =C2=A0 SSH_MSG_CHANNEL_DATA length - 4 bytes =C2=A0 SSH_MSG_CHANNEL_DATA ciphertext - 16-byte aligned =C2=A0 SSH_MSG_CHANNEL_DATA tag - 16 bytes =C2=A0 SSH_MSG_IGNORE length - 4 bytes =C2=A0 SSH_MSG_IGNORE ciphertext - 16-byte aligned =C2=A0 SSH_MSG_IGNORE tag - 16 bytes The result isn't 16-byte aligned. This means we can't target a consistent t= otal size, unless we ALWAYS add an SSH_MSG_IGNORE packet. But there is no actual reason to have block size alignment with AEAD - or e= ven CTR. I propose the following: - For inclusion in Niels's draft with AEAD guidelines, discourage or prohib= it unneeded block alignment for packet receivers. Optionally, we COULD also deprecate compulsory alignment for existing modes= that don't need it, i.e. CTR. However, there is currently no recommended C= TR + MAC combination where this would be a problem, since all plausible non= -deprecated MACs are 16-byte aligned. denis = --=-03zM2rN/Ot24szm/2dEv Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey everyone,

while implementing the "fixed= -bandwidth" proposal, I realize we ought to get rid of block alignment requ= irements.

Using AES-CTR and hmac-sha2-256, it's straightforward to p= ad outgoing packets to some aligned size, e.g. 1024 bytes, using the follow= ing construction:

  SSH_MSG_CHANNEL_DATA ciphertext - 16-byte a= ligned
  SSH_MSG_CHANNEL_DATA mac - 32 bytes
  SSH_MSG_IGNO= RE ciphertext - 16-byte aligned
  SSH_MSG_IGNORE mac - 32 bytes
=
All lengths are 16-byte aligned, so we can always target an aligned tot= al size.

If we try to do the same with hmac-sha1, there's a problem.= But hmac-sha1 is deprecated, so maybe that's not an issue.

But with= AEAD, we run into the issue again:

  SSH_MSG_CHANNEL_DATA leng= th - 4 bytes
  SSH_MSG_CHANNEL_DATA ciphertext - 16-byte aligned  SSH_MSG_CHANNEL_DATA tag - 16 bytes
  SSH_MSG_IGNORE length= - 4 bytes
  SSH_MSG_IGNORE ciphertext - 16-byte aligned
  = SSH_MSG_IGNORE tag - 16 bytes

The result isn't 16-byte aligned. This= means we can't target a consistent total size, unless we ALWAYS add an SSH= _MSG_IGNORE packet.

But there is no actual reason to have block size= alignment with AEAD - or even CTR.

I propose the following:

= - For inclusion in Niels's draft with AEAD guidelines, discourage or prohib= it unneeded block alignment for packet receivers.

Optionally, we COU= LD also deprecate compulsory alignment for existing modes that don't need i= t, i.e. CTR. However, there is currently no recommended CTR + MAC combinati= on where this would be a problem, since all plausible non-deprecated MACs a= re 16-byte aligned.

denis

= --=-03zM2rN/Ot24szm/2dEv-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Feb 28 18:34:22 2016 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 36ED01B2A2D for ; Sun, 28 Feb 2016 18:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=unavailable 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 udvwmedWl29a for ; Sun, 28 Feb 2016 18:34:20 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 72F181B2A3E for ; Sun, 28 Feb 2016 18:34:20 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 1A38485F2A; Mon, 29 Feb 2016 02:34:19 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 142DC85F29 for ; Mon, 29 Feb 2016 02:34:16 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id W8WnB-hi0d4T for ; Mon, 29 Feb 2016 02:34:15 +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 DE36D84CBD for ; Mon, 29 Feb 2016 02:34:10 +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=1456713255; x=1488249255; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7Vx5wfo1iZSKsVq0vf+UtYsEHbjsC9wp/gt7go5x2IM=; b=IMtU7mmOAtj1IaBWJQbePffbSgC/Ng6Yf9We16BKwBAWeehxa3Vmcj7l ZjZXR17yI0Gx3erG+mWwJGfEKoqu6y6L2J1qaOKaTcLwI82Y0FM3C3+uk ayC1qWxSGXp7asT3DjQmKJMvlCQttu49200hzP7A7lsfHNBBf6FJWxIZY IedWfta25opZ5o+7CcgYwqsySfbfzW8l3aSNVwof9Fp7TrVto+UYEDMxn Ud9TCqusOVY//I3ulnHmwdXtCYdJiUN2TOotHJsRldnRHsfsflT0vBFtp y9xVtwWdX4unWknwkWHV4pH+FD1mdTc2YFq5mgdkdzP6KAC3YtVGvWO4v w==; X-IronPort-AV: E=Sophos;i="5.22,518,1449486000"; d="scan'208";a="71004571" 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/AES256-SHA; 29 Feb 2016 15:33:51 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 29 Feb 2016 15:33:51 +1300 From: Peter Gutmann To: denis bider CC: =?iso-8859-1?Q?Niels_M=F6ller?= , Bryan Ford , "Mark D. Baushke" , Stephen Farrell , Watson Ladd , "Daniel Migault" , Curdle Chairs , "ietf-ssh@NetBSD.org" Subject: RE: AEAD in ssh Thread-Topic: AEAD in ssh Thread-Index: AQHRcAfvBfOcnKvI/0qJ+8iBK4Zo5J9CUuUG Date: Mon, 29 Feb 2016 02:33:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C03F05@uxcn10-5.UoA.auckland.ac.nz> References: <1266469733-2760@skroderider.denisbider.com> In-Reply-To: <1266469733-2760@skroderider.denisbider.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider writes:=0A= =0A= >If I restrict myself to send the same amount of data, at regular intervals= ,=0A= >independent of my packet queue; if I pick up packets from my queue if they= =0A= >are any, and send IGNORE messages otherwise; then this prevents keystroke= =0A= >analysis if done in 10 second bursts; and if I keep it up, it masks=0A= >everything done on the connection.=0A= =0A= Well, you *think* it does, in the same way that people once thought traffic= =0A= padding would mask everything on the connection (I'm assuming they did, giv= en=0A= that it's the only anti-TA measure present in both TLS and SSH). Show me= =0A= empirical data of it resisting attacks of the kind described in Peekaboo an= d=0A= other papers...=0A= =0A= >You crack this joke, just after I pointed out that this costs 1 Mbps or le= ss,=0A= >whereas Netflix uses 3 - 5 Mbps. This is when Google Fiber is rolling out = in=0A= >the US, and we can expect 1 Gbps speeds to be normal in 15 years (if backw= ard=0A= >thinking people don't stop it).=0A= =0A= Yeah, and that's part of the way-too-common thinking that in the future we'= ll=0A= all have infinite CPU, infinite RAM, and infinite bandwidth that leads to= =0A= people creating totally unworkable Rube-goldberg contraptions of crypto=0A= protocols. A few days ago I got to review two proposed ISO standards for I= oT=0A= in which a bunch of networking engineers tried to invent some sort of crypt= o=0A= mechanism that makes WEP look like a model of good design, because both TLS= =0A= and SSH are far too bloated to work for them. It's not their fault, they'r= e=0A= networking engineers and shouldn't be expected to have to do this, but the= =0A= crypto community just assumes infinite resources and goes from there. I've= =0A= got users who don't want to move from SHA-1 to SHA-256 because of the extra= =0A= size introduced by the larger MACs, and you're telling me that we can all= =0A= dream of 1GBPs in the near future...=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Feb 29 05:37:29 2016 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 DED9A1AC402 for ; Mon, 29 Feb 2016 05:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 ko3co1ICHAM2 for ; Mon, 29 Feb 2016 05:37:28 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 7EAD91A903E for ; Mon, 29 Feb 2016 05:37:27 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 45CDF85F11; Mon, 29 Feb 2016 13:37:27 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A277D85E78 for ; Mon, 29 Feb 2016 13:37:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id F-uR0xJ18SEi for ; Mon, 29 Feb 2016 13:37:24 +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 B1FDA85E6F for ; Mon, 29 Feb 2016 13:37:23 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 75E934001E; Mon, 29 Feb 2016 14:37:16 +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 E837B4001B; Mon, 29 Feb 2016 14:37:14 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 29 Feb 2016 14:37:14 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: ietf-ssh@NetBSD.org Subject: Re: AEAD in SSH: Toss block alignment requirements References: <1463563347-3264@skroderider.denisbider.com> Date: Mon, 29 Feb 2016 14:37:14 +0100 In-Reply-To: <1463563347-3264@skroderider.denisbider.com> (denis bider's message of "Sun, 28 Feb 2016 02:54:48 +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: > - For inclusion in Niels's draft with AEAD guidelines, discourage or > prohibit unneeded block alignment for packet receivers. In general, I'm thinking that padding is a useful complement to SSH_MSG_IGNORE. In current use, one effect is that SSH_MSG_USERAUTH "password" packets are close to fix size (in the absence of any other traffic analysis countermeasures). If I count correctly, the payload of a SSH_MSG_USERAUTH_REQUEST message requesting the "ssh-connection" service and using password authentication is 40 bytes + the actual sizes of username and password (and then it may be comprssed, I'm ignoring that complication here, but I wouldn't expect it to change the size very much). With a 16 byte block size and minimum 4 bytes of padding, it doesn't fit in three blocks, so it will be padded to 64 bytes + mac, with 19 bytes of padding. So if len(username) + len(password) <=3D 15, we're getting a cryptotext of 64 bytes, and if 16 <=3D len(username) + len(password) <=3D 31, we get 80 bytes. Which is a significant improvement over leaking the exact length.=20 (There are related issues for other message types, in particular SSH_MSG_CHANNEL data, where pad-to-block-size could help hiding the number of keystrokes. Assuming an implementation is able to collect quickly typed characters into a single data packet, e.g., by setting VMIN and VTIME on a unix terminal). For AEAD, I am tempted to drop all MUST requirements on padding lengths and leave it up to the implementation. However, I won't do that unless I see some additional support here. And if we go that way, I think we have to include some SHOULD rule which provides at least as good hiding of userauth passwords as the original spec. > Optionally, we COULD also deprecate compulsory alignment for existing > modes that don't need it, i.e. CTR.=20 I don't think it's a good idea to change the rules for non-AEAD ciphers. We'll get incompatible versions for very little benefit. And if you want to generate constant size TCP segments, you can do arbitrary segment size regardless of padding rules, by sending TCP segments which end with a partial SSH_MSG_IGNORE. 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 Mon Feb 29 21:30:13 2016 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 34C121ACE10 for ; Mon, 29 Feb 2016 21:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 E_xi7RKCK5Rd for ; Mon, 29 Feb 2016 21:30:10 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 5F8671ACE0F for ; Mon, 29 Feb 2016 21:30:10 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 018F885EBE; Tue, 1 Mar 2016 05:30:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id AAE4D85E58; Tue, 1 Mar 2016 05:30:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6C64B85EB5 for ; Tue, 1 Mar 2016 01:27:49 +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 ISYtnNCJA_KJ for ; Tue, 1 Mar 2016 01:27:48 +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 975B685E1E for ; Tue, 1 Mar 2016 01:27:48 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Tue, 1 Mar 2016 01:27:46 +0000 Date: Tue, 1 Mar 2016 01:27:46 +0000 Subject: Re: AEAD in SSH: Toss block alignment requirements X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1631451061-3620@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-44Zi7gZLZOF0o50lcpE9" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-44Zi7gZLZOF0o50lcpE9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The problem is not that the sender applies padding. The sender definitely s= hould. The problem is that block-aligned padding is enforced by the receive= r, even when this is not optimal. With AEAD, where the 4-byte length is separate from the alignment; this con= strains the sender in its ability to mask things. (This is also the case wi= th CTR and hmac-sha1.) With block alignment requirements in place, it is not possible to hide whet= her you're sending this: =C2=A0 SSH_MSG_LARGE_USEFUL_PACKET Or this: =C2=A0 SSH_MSG_SMALL_USEFUL_PACKET =C2=A0 SSH_MSG_IGNORE =C2=A0=20 In the former case - one packet - AEAD transmission size is going to be: =C2=A0=C2=A0=C2=A0 4 + 16*x + 16 =C2=A0 =3D (x+1)*16 + 4 =C2=A0=20 In the second case - two packets - AEAD transmission size is going to be: =C2=A0=C2=A0=C2=A0 4 + 16*x + 16 =C2=A0 + 4 + 16*y + 16 =C2=A0 =3D (x+y+2)*16 + 8 It is therefore trivially distinguishable whether you're sending one large = packet, or two packets back-to-back. With one packet, transmission length i= s coerced to (N mod 16) =3D=3D 4. With two packets, it's coerced to (N mod = 16) =3D=3D 8. To work around this, to effectively mask what you're sending, you must alwa= ys send either this: =C2=A0 SSH_MSG_LARGE_USEFUL_PACKET =C2=A0 SSH_MSG_IGNORE (small) =C2=A0=20 Or this: =C2=A0 SSH_MSG_SMALL_USEFUL_PACKET =C2=A0 SSH_MSG_IGNORE (large) It could be argued that this loss of flexibility - the inability to hide th= e number of packets in a transmission - has the upside of forcing naive or = negligent implementations to always pad outgoing packets. Such implementati= ons might otherwise not pad at all, revealing the lengths of passwords. That might be a compelling argument. I don't know. Regardless - block alignment is our current reality. I have altered the "fi= xed-bandwidth" draft to take this into account - to always send two packets= in a transmission, instead of sometimes two and sometimes one: https://tools.ietf.org/html/draft-ssh-fixed-bandwidth-02 ----- Original Message ----- denis bider writes: > - For inclusion in Niels's draft with AEAD guidelines, discourage or > prohibit unneeded block alignment for packet receivers. In general, I'm thinking that padding is a useful complement to SSH_MSG_IGNORE. In current use, one effect is that SSH_MSG_USERAUTH "password" packets are close to fix size (in the absence of any other traffic analysis countermeasures). If I count correctly, the payload of a SSH_MSG_USERAUTH_REQUEST message requesting the "ssh-connection" service and using password authentication is 40 bytes + the actual sizes of username and password (and then it may be comprssed, I'm ignoring that complication here, but I wouldn't expect it to change the size very much). With a 16 byte block size and minimum 4 bytes of padding, it doesn't fit in three blocks, so it will be padded to 64 bytes + mac, with 19 bytes of padding. So if len(username) + len(password) <=3D 15, we're getting a cryptotext of 64 bytes, and if 16 <=3D len(username) + len(password) <=3D 31, we get 80 bytes. Which is a significant improvement over leaking the exact length. (There are related issues for other message types, in particular SSH_MSG_CHANNEL data, where pad-to-block-size could help hiding the number of keystrokes. Assuming an implementation is able to collect quickly typed characters into a single data packet, e.g., by setting VMIN and VTIME on a unix terminal). For AEAD, I am tempted to drop all MUST requirements on padding lengths and leave it up to the implementation. However, I won't do that unless I see some additional support here. And if we go that way, I think we have to include some SHOULD rule which provides at least as good hiding of userauth passwords as the original spec. > Optionally, we COULD also deprecate compulsory alignment for existing > modes that don't need it, i.e. CTR. I don't think it's a good idea to change the rules for non-AEAD ciphers. We'll get incompatible versions for very little benefit. And if you want to generate constant size TCP segments, you can do arbitrary segment size regardless of padding rules, by sending TCP segments which end with a partial SSH_MSG_IGNORE. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-44Zi7gZLZOF0o50lcpE9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable The problem is not that the sender applies padding= . The sender definitely should. The problem is that block-aligned padding i= s enforced by the receiver, even when this is not optimal.

With AEAD= , where the 4-byte length is separate from the alignment; this constrains t= he sender in its ability to mask things. (This is also the case with CTR an= d hmac-sha1.)

With block alignment requirements in place, it is not = possible to hide whether you're sending this:

  SSH_MSG_LARGE_U= SEFUL_PACKET

Or this:

  SSH_MSG_SMALL_USEFUL_PACKET
&= nbsp; SSH_MSG_IGNORE
 
In the former case - one packet - AEAD t= ransmission size is going to be:

    4 + 16*x + 16  =3D (x+1)*16 + 4
 
In the second case - two packets - A= EAD transmission size is going to be:

    4 + 16*x + = 16
  + 4 + 16*y + 16
  =3D (x+y+2)*16 + 8

It is ther= efore trivially distinguishable whether you're sending one large packet, or= two packets back-to-back. With one packet, transmission length is coerced = to (N mod 16) =3D=3D 4. With two packets, it's coerced to (N mod 16) =3D=3D= 8.

To work around this, to effectively mask what you're sending, yo= u must always send either this:

  SSH_MSG_LARGE_USEFUL_PACKET  SSH_MSG_IGNORE (small)
 
Or this:

  SSH_MS= G_SMALL_USEFUL_PACKET
  SSH_MSG_IGNORE (large)

It could be a= rgued that this loss of flexibility - the inability to hide the number of p= ackets in a transmission - has the upside of forcing naive or negligent imp= lementations to always pad outgoing packets. Such implementations might oth= erwise not pad at all, revealing the lengths of passwords.

That migh= t be a compelling argument. I don't know.

Regardless - block alignme= nt is our current reality. I have altered the "fixed-bandwidth" draft to ta= ke this into account - to always send two packets in a transmission, instea= d of sometimes two and sometimes one:

https://tools.ietf.org/html/dr= aft-ssh-fixed-bandwidth-02



----- Original Message -----
d= enis bider <ietf-ssh3@denisbider.com> writes:

> - For inclu= sion in Niels's draft with AEAD guidelines, discourage or
> prohibit = unneeded block alignment for packet receivers.

In general, I'm think= ing that padding is a useful complement to
SSH_MSG_IGNORE. In current us= e, one effect is that SSH_MSG_USERAUTH
"password" packets are close to f= ix size (in the absence of any other
traffic analysis countermeasures). = If I count correctly, the payload of
a SSH_MSG_USERAUTH_REQUEST message = requesting the "ssh-connection"
service and using password authenticatio= n is 40 bytes + the actual sizes
of username and password (and then it m= ay be comprssed, I'm ignoring
that complication here, but I wouldn't exp= ect it to change the size very
much).

With a 16 byte block size a= nd minimum 4 bytes of padding, it doesn't fit
in three blocks, so it wil= l be padded to 64 bytes + mac, with 19 bytes
of padding. So if len(usern= ame) + len(password) <=3D 15, we're getting a
cryptotext of 64 bytes,= and if 16 <=3D len(username) + len(password) <=3D
31, we get 80 b= ytes. Which is a significant improvement over leaking the
exact length.<= br>
(There are related issues for other message types, in particular
= SSH_MSG_CHANNEL data, where pad-to-block-size could help hiding the
numb= er of keystrokes. Assuming an implementation is able to collect
quickly = typed characters into a single data packet, e.g., by setting
VMIN and VT= IME on a unix terminal).

For AEAD, I am tempted to drop all MUST req= uirements on padding lengths
and leave it up to the implementation. Howe= ver, I won't do that unless I
see some additional support here. And if w= e go that way, I think we have
to include some SHOULD rule which provide= s at least as good hiding of
userauth passwords as the original spec.
> Optionally, we COULD also deprecate compulsory alignment for exis= ting
> modes that don't need it, i.e. CTR.

I don't think it's = a good idea to change the rules for non-AEAD ciphers.
We'll get incompat= ible versions for very little benefit.

And if you want to generate c= onstant size TCP segments, you can do
arbitrary segment size regardless = of padding rules, by sending TCP
segments which end with a partial SSH_M= SG_IGNORE.

Regards,
/Niels

--
Niels M=C3=B6ller. PGP-e= ncrypted email is preferred. Keyid C0B98E26.
Internet email is subject t= o wholesale government surveillance.

= --=-44Zi7gZLZOF0o50lcpE9-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Feb 29 21:30:31 2016 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 63BCC1ACE09 for ; Mon, 29 Feb 2016 21:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 SSVcSm2ioroB for ; Mon, 29 Feb 2016 21:30:29 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 3191F1ACE12 for ; Mon, 29 Feb 2016 21:30:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 00C5E85ECA; Tue, 1 Mar 2016 05:30:29 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id AE40E85E58; Tue, 1 Mar 2016 05:30:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C657285E91 for ; Tue, 1 Mar 2016 01:37:26 +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 RFbjTSJCgiDI for ; Tue, 1 Mar 2016 01:37:26 +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 E31C084CEA for ; Tue, 1 Mar 2016 01:37:25 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Tue, 1 Mar 2016 01:37:23 +0000 Date: Tue, 1 Mar 2016 01:37:23 +0000 Subject: Re: AEAD in SSH: Toss block alignment requirements X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1633175543-3000@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1631451061-3620@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-xlZBuOE8pWaq0SfkkJKh" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-xlZBuOE8pWaq0SfkkJKh Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Also: > And if you want to generate constant size TCP segments, > you can do arbitrary segment size regardless of padding > rules, by sending TCP segments which end with a partial > SSH_MSG_IGNORE. You're right, this is true. Generate an SSH_MSG_IGNORE that's just big enou= gh, or slightly too large; then include any extra bytes as part of the next= transmission. I'm not sure that this has a decisive advantage compared to just always sen= ding an SSH_MSG_USEFUL_PACKET + SSH_MSG_IGNORE, though. denis bider , 3/1/2016 1:02 AM: The problem is not that the sender applies padding. The sender definitely s= hould. The problem is that block-aligned padding is enforced by the receive= r, even when this is not optimal. With AEAD, where the 4-byte length is separate from the alignment; this con= strains the sender in its ability to mask things. (This is also the case wi= th CTR and hmac-sha1.) With block alignment requirements in place, it is not possible to hide whet= her you're sending this: =C2=A0 SSH_MSG_LARGE_USEFUL_PACKET Or this: =C2=A0 SSH_MSG_SMALL_USEFUL_PACKET =C2=A0 SSH_MSG_IGNORE =C2=A0=20 In the former case - one packet - AEAD transmission size is going to be: =C2=A0=C2=A0=C2=A0 4 + 16*x + 16 =C2=A0 =3D (x+1)*16 + 4 =C2=A0=20 In the second case - two packets - AEAD transmission size is going to be: =C2=A0=C2=A0=C2=A0 4 + 16*x + 16 =C2=A0 + 4 + 16*y + 16 =C2=A0 =3D (x+y+2)*16 + 8 It is therefore trivially distinguishable whether you're sending one large = packet, or two packets back-to-back. With one packet, transmission length i= s coerced to (N mod 16) =3D=3D 4. With two packets, it's coerced to (N mod = 16) =3D=3D 8. To work around this, to effectively mask what you're sending, you must alwa= ys send either this: =C2=A0 SSH_MSG_LARGE_USEFUL_PACKET =C2=A0 SSH_MSG_IGNORE (small) =C2=A0=20 Or this: =C2=A0 SSH_MSG_SMALL_USEFUL_PACKET =C2=A0 SSH_MSG_IGNORE (large) It could be argued that this loss of flexibility - the inability to hide th= e number of packets in a transmission - has the upside of forcing naive or = negligent implementations to always pad outgoing packets. Such implementati= ons might otherwise not pad at all, revealing the lengths of passwords. That might be a compelling argument. I don't know. Regardless - block alignment is our current reality. I have altered the "fi= xed-bandwidth" draft to take this into account - to always send two packets= in a transmission, instead of sometimes two and sometimes one: https://tools.ietf.org/html/draft-ssh-fixed-bandwidth-02 ----- Original Message ----- denis bider writes: > - For inclusion in Niels's draft with AEAD guidelines, discourage or > prohibit unneeded block alignment for packet receivers. In general, I'm thinking that padding is a useful complement to SSH_MSG_IGNORE. In current use, one effect is that SSH_MSG_USERAUTH "password" packets are close to fix size (in the absence of any other traffic analysis countermeasures). If I count correctly, the payload of a SSH_MSG_USERAUTH_REQUEST message requesting the "ssh-connection" service and using password authentication is 40 bytes + the actual sizes of username and password (and then it may be comprssed, I'm ignoring that complication here, but I wouldn't expect it to change the size very much). With a 16 byte block size and minimum 4 bytes of padding, it doesn't fit in three blocks, so it will be padded to 64 bytes + mac, with 19 bytes of padding. So if len(username) + len(password) <=3D 15, we're getting a cryptotext of 64 bytes, and if 16 <=3D len(username) + len(password) <=3D 31, we get 80 bytes. Which is a significant improvement over leaking the exact length. (There are related issues for other message types, in particular SSH_MSG_CHANNEL data, where pad-to-block-size could help hiding the number of keystrokes. Assuming an implementation is able to collect quickly typed characters into a single data packet, e.g., by setting VMIN and VTIME on a unix terminal). For AEAD, I am tempted to drop all MUST requirements on padding lengths and leave it up to the implementation. However, I won't do that unless I see some additional support here. And if we go that way, I think we have to include some SHOULD rule which provides at least as good hiding of userauth passwords as the original spec. > Optionally, we COULD also deprecate compulsory alignment for existing > modes that don't need it, i.e. CTR. I don't think it's a good idea to change the rules for non-AEAD ciphers. We'll get incompatible versions for very little benefit. And if you want to generate constant size TCP segments, you can do arbitrary segment size regardless of padding rules, by sending TCP segments which end with a partial SSH_MSG_IGNORE. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-xlZBuOE8pWaq0SfkkJKh Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Also:

> And if you want to generate cons= tant size TCP segments,
> you can do arbitrary segment size regardles= s of padding
> rules, by sending TCP segments which end with a partia= l
> SSH_MSG_IGNORE.

You're right, this is true. Generate an SS= H_MSG_IGNORE that's just big enough, or slightly too large; then include an= y extra bytes as part of the next transmission.

I'm not sure that th= is has a decisive advantage compared to just always sending an SSH_MSG_USEF= UL_PACKET + SSH_MSG_IGNORE, though.


denis bider <ietf-ssh3@denisbider.com> , 3/1/2016 1= :02 AM:
The problem is not that the sender= applies padding. The sender definitely should. The problem is that block-a= ligned padding is enforced by the receiver, even when this is not optimal.<= br>
With AEAD, where the 4-byte length is separate from the alignment; t= his constrains the sender in its ability to mask things. (This is also the = case with CTR and hmac-sha1.)

With block alignment requirements in p= lace, it is not possible to hide whether you're sending this:

 = SSH_MSG_LARGE_USEFUL_PACKET

Or this:

  SSH_MSG_SMALL_US= EFUL_PACKET
  SSH_MSG_IGNORE
 
In the former case - one= packet - AEAD transmission size is going to be:

    = 4 + 16*x + 16
  =3D (x+1)*16 + 4
 
In the second case -= two packets - AEAD transmission size is going to be:

  &n= bsp; 4 + 16*x + 16
  + 4 + 16*y + 16
  =3D (x+y+2)*16 + 8
It is therefore trivially distinguishable whether you're sending one = large packet, or two packets back-to-back. With one packet, transmission le= ngth is coerced to (N mod 16) =3D=3D 4. With two packets, it's coerced to (= N mod 16) =3D=3D 8.

To work around this, to effectively mask what yo= u're sending, you must always send either this:

  SSH_MSG_LARGE= _USEFUL_PACKET
  SSH_MSG_IGNORE (small)
 
Or this:
<= br>  SSH_MSG_SMALL_USEFUL_PACKET
  SSH_MSG_IGNORE (large)
<= br>It could be argued that this loss of flexibility - the inability to hide= the number of packets in a transmission - has the upside of forcing naive = or negligent implementations to always pad outgoing packets. Such implement= ations might otherwise not pad at all, revealing the lengths of passwords.<= br>
That might be a compelling argument. I don't know.

Regardless= - block alignment is our current reality. I have altered the "fixed-bandwi= dth" draft to take this into account - to always send two packets in a tran= smission, instead of sometimes two and sometimes one:

https://to= ols.ietf.org/html/draft-ssh-fixed-bandwidth-02



----- Ori= ginal Message -----
denis bider <ietf-ssh= 3@denisbider.com> writes:

> - For inclusion in Niels's dra= ft with AEAD guidelines, discourage or
> prohibit unneeded block alig= nment for packet receivers.

In general, I'm thinking that padding is= a useful complement to
SSH_MSG_IGNORE. In current use, one effect is th= at SSH_MSG_USERAUTH
"password" packets are close to fix size (in the abs= ence of any other
traffic analysis countermeasures). If I count correctl= y, the payload of
a SSH_MSG_USERAUTH_REQUEST message requesting the "ssh= -connection"
service and using password authentication is 40 bytes + the= actual sizes
of username and password (and then it may be comprssed, I'= m ignoring
that complication here, but I wouldn't expect it to change th= e size very
much).

With a 16 byte block size and minimum 4 bytes = of padding, it doesn't fit
in three blocks, so it will be padded to 64 b= ytes + mac, with 19 bytes
of padding. So if len(username) + len(password= ) <=3D 15, we're getting a
cryptotext of 64 bytes, and if 16 <=3D = len(username) + len(password) <=3D
31, we get 80 bytes. Which is a si= gnificant improvement over leaking the
exact length.

(There are r= elated issues for other message types, in particular
SSH_MSG_CHANNEL dat= a, where pad-to-block-size could help hiding the
number of keystrokes. A= ssuming an implementation is able to collect
quickly typed characters in= to a single data packet, e.g., by setting
VMIN and VTIME on a unix termi= nal).

For AEAD, I am tempted to drop all MUST requirements on paddin= g lengths
and leave it up to the implementation. However, I won't do tha= t unless I
see some additional support here. And if we go that way, I th= ink we have
to include some SHOULD rule which provides at least as good = hiding of
userauth passwords as the original spec.

> Optionall= y, we COULD also deprecate compulsory alignment for existing
> modes = that don't need it, i.e. CTR.

I don't think it's a good idea to chan= ge the rules for non-AEAD ciphers.
We'll get incompatible versions for v= ery little benefit.

And if you want to generate constant size TCP se= gments, you can do
arbitrary segment size regardless of padding rules, b= y sending TCP
segments which end with a partial SSH_MSG_IGNORE.

R= egards,
/Niels

--
Niels M=C3=B6ller. PGP-encrypted email is p= referred. Keyid C0B98E26.
Internet email is subject to wholesale governm= ent surveillance.

= --=-xlZBuOE8pWaq0SfkkJKh-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Feb 29 21:30:41 2016 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 B42061ACE12 for ; Mon, 29 Feb 2016 21:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=unavailable 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 iOI71zsAw_vD for ; Mon, 29 Feb 2016 21:30:39 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 B6EF61ACE09 for ; Mon, 29 Feb 2016 21:30:39 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2BAAB85F93; Tue, 1 Mar 2016 05:30:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D5AB385E58; Tue, 1 Mar 2016 05:30:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B65FD85E1E for ; Tue, 1 Mar 2016 02:46:06 +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 ogphb6DQer_y for ; Tue, 1 Mar 2016 02:46:06 +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 E819385E5F for ; Tue, 1 Mar 2016 02:46:05 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Tue, 1 Mar 2016 02:46:04 +0000 Date: Tue, 1 Mar 2016 02:46:04 +0000 Subject: Re: AEAD in ssh X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Message-ID: <1635692869-2876@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann Cc: =?UTF-8?q?Niels_M=C3=B6ller?= , Bryan Ford , "Mark D. Baushke" , Stephen Farrell , Watson Ladd , Daniel Migault , Curdle Chairs , ietf-ssh@NetBSD.org Content-Type: multipart/alternative; boundary="=-H+b/2xluMktaV4NFv284" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-H+b/2xluMktaV4NFv284 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I can appreciate these concerns. I understand our markets are very differen= t. With our SSH Server and Client, we don't target anything below the hardw= are it takes to run Windows x86 or x64, desktop or server. We can expect at= LEAST hardware equivalent to an Amazon micro instance. This is of a larger= size today, than it was years ago. What is called "micro" now was called "= small". Yesterday, Raspberry Pi 3 came out. It still costs $35, and now has a 1.2 G= Hz 64-bit processor, integrated Bluetooth, and Wi-Fi: https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/ It may be that Moore's law is coming to an end, at the high end of the scal= e. But miniaturization and efficiency are not. For devices in lower price r= anges, performance per $ will continue to improve. It seems to me the only way you have a computing resource problem is if you= r customers' stinginess increases in tandem with miniaturization. For examp= le, maybe a number of years ago your customers were willing to pay $10 per = gadget. Now, perhaps they're willing to pay only $1, while keeping performa= nce the same. Is that the trend you see? If people are increasingly trying to put secure protocols on smaller device= s - yesterday $10; today $1; tomorrow a needle head that costs 10 cents - i= t seems to me that the needs of this market segment might indeed be best se= rved by some restricted subset of existing protocols, or a protocol designe= d specifically for that. >From my position, it's not a problem to support an algorithm that uses unen= crypted lengths, so it can be compatible with a 10 cent implementation the = size of a needle head. I don't want your 10 cent implementation to constrain me in what I can prov= ide to my users, however. Maybe you can't afford a fixed-bandwidth terminal= session. However, it seems like an excellent fit to provide privacy for in= teractive administration of a server in a data center. ----- Original Message ----- From: Peter Gutmann Sent: Sunday, February 28, 2016 20:33 To: denis bider Cc: Niels M=C3=B6ller ; Bryan Ford ; Mark D. Baushke ; Stephen Farrell ; Wa= tson Ladd ; Daniel Migault ; Curdle Chairs ; ietf-ssh@NetBSD.org Subject: RE: AEAD in ssh denis bider writes: >If I restrict myself to send the same amount of data, at regular intervals= , >independent of my packet queue; if I pick up packets from my queue if they >are any, and send IGNORE messages otherwise; then this prevents keystroke >analysis if done in 10 second bursts; and if I keep it up, it masks >everything done on the connection. Well, you *think* it does, in the same way that people once thought traffic padding would mask everything on the connection (I'm assuming they did, giv= en that it's the only anti-TA measure present in both TLS and SSH).=C2=A0 Show= me empirical data of it resisting attacks of the kind described in Peekaboo an= d other papers... >You crack this joke, just after I pointed out that this costs 1 Mbps or le= ss, >whereas Netflix uses 3 - 5 Mbps. This is when Google Fiber is rolling out = in >the US, and we can expect 1 Gbps speeds to be normal in 15 years (if backw= ard >thinking people don't stop it). Yeah, and that's part of the way-too-common thinking that in the future we'= ll all have infinite CPU, infinite RAM, and infinite bandwidth that leads to people creating totally unworkable Rube-goldberg contraptions of crypto protocols.=C2=A0 A few days ago I got to review two proposed ISO standards = for IoT in which a bunch of networking engineers tried to invent some sort of crypt= o mechanism that makes WEP look like a model of good design, because both TLS and SSH are far too bloated to work for them.=C2=A0 It's not their fault, t= hey're networking engineers and shouldn't be expected to have to do this, but the crypto community just assumes infinite resources and goes from there.=C2=A0= I've got users who don't want to move from SHA-1 to SHA-256 because of the extra size introduced by the larger MACs, and you're telling me that we can all dream of 1GBPs in the near future... Peter. = --=-H+b/2xluMktaV4NFv284 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I can appreciate these concerns. I understand our = markets are very different. With our SSH Server and Client, we don't target= anything below the hardware it takes to run Windows x86 or x64, desktop or= server. We can expect at LEAST hardware equivalent to an Amazon micro inst= ance. This is of a larger size today, than it was years ago. What is called= "micro" now was called "small".

Yesterday, Raspberry Pi 3 came out.= It still costs $35, and now has a 1.2 GHz 64-bit processor, integrated Blu= etooth, and Wi-Fi:

https://www.raspberrypi.org/blog/raspberry-pi-3-o= n-sale/

It may be that Moore's law is coming to an end, at the high = end of the scale. But miniaturization and efficiency are not. For devices i= n lower price ranges, performance per $ will continue to improve.

It= seems to me the only way you have a computing resource problem is if your = customers' stinginess increases in tandem with miniaturization. For example= , maybe a number of years ago your customers were willing to pay $10 per ga= dget. Now, perhaps they're willing to pay only $1, while keeping performanc= e the same. Is that the trend you see?

If people are increasingly tr= ying to put secure protocols on smaller devices - yesterday $10; today $1; = tomorrow a needle head that costs 10 cents - it seems to me that the needs = of this market segment might indeed be best served by some restricted subse= t of existing protocols, or a protocol designed specifically for that.
<= br>From my position, it's not a problem to support an algorithm that uses u= nencrypted lengths, so it can be compatible with a 10 cent implementation t= he size of a needle head.

I don't want your 10 cent implementation t= o constrain me in what I can provide to my users, however. Maybe you can't = afford a fixed-bandwidth terminal session. However, it seems like an excell= ent fit to provide privacy for interactive administration of a server in a = data center.


----- Original Message -----
From: Peter Gutmann=
Sent: Sunday, February 28, 2016 20:33
To: denis bider
Cc: Niels M= =C3=B6ller ; Bryan Ford ; Mark D. Baushke ; Stephen Farrell ; Watson Ladd ;= Daniel Migault ; Curdle Chairs ; ietf-ssh@NetBSD.org
Subject: RE: AEAD = in ssh

denis bider <ietf-ssh3@denisbider.com> writes:

&= gt;If I restrict myself to send the same amount of data, at regular interva= ls,
>independent of my packet queue; if I pick up packets from my que= ue if they
>are any, and send IGNORE messages otherwise; then this pr= events keystroke
>analysis if done in 10 second bursts; and if I keep= it up, it masks
>everything done on the connection.

Well, you= *think* it does, in the same way that people once thought traffic
paddi= ng would mask everything on the connection (I'm assuming they did, giventhat it's the only anti-TA measure present in both TLS and SSH).  Sho= w me
empirical data of it resisting attacks of the kind described in Pee= kaboo and
other papers...

>You crack this joke, just after I p= ointed out that this costs 1 Mbps or less,
>whereas Netflix uses 3 - = 5 Mbps. This is when Google Fiber is rolling out in
>the US, and we c= an expect 1 Gbps speeds to be normal in 15 years (if backward
>thinki= ng people don't stop it).

Yeah, and that's part of the way-too-commo= n thinking that in the future we'll
all have infinite CPU, infinite RAM,= and infinite bandwidth that leads to
people creating totally unworkable= Rube-goldberg contraptions of crypto
protocols.  A few days ago I = got to review two proposed ISO standards for IoT
in which a bunch of net= working engineers tried to invent some sort of crypto
mechanism that mak= es WEP look like a model of good design, because both TLS
and SSH are fa= r too bloated to work for them.  It's not their fault, they're
netw= orking engineers and shouldn't be expected to have to do this, but the
c= rypto community just assumes infinite resources and goes from there.  = I've
got users who don't want to move from SHA-1 to SHA-256 because of t= he extra
size introduced by the larger MACs, and you're telling me that = we can all
dream of 1GBPs in the near future...

Peter.

= --=-H+b/2xluMktaV4NFv284--