From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Dec 1 03:51:46 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D12A1A9107 for ; Tue, 1 Dec 2015 03:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTFipQANn2CH for ; Tue, 1 Dec 2015 03:51:45 -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 13AB41A9106 for ; Tue, 1 Dec 2015 03:51:45 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2D99585E66; Tue, 1 Dec 2015 11:51:43 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AD5FC85E64 for ; Tue, 1 Dec 2015 11:51:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ba8hUybeVVEZ for ; Tue, 1 Dec 2015 11:51:41 +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 D8B3D85E46 for ; Tue, 1 Dec 2015 11:51:40 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2F75140014; Tue, 1 Dec 2015 12:51: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 39EBD40009; Tue, 1 Dec 2015 12:51:32 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 01 Dec 2015 12:51:32 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Damien Miller , Simon Tatham , Simon Josefsson , ietf-ssh@netbsd.org Subject: Re: SSH v3? References: <1493720992-1452@skroderider.denisbider.com> Date: Tue, 01 Dec 2015 12:51:31 +0100 In-Reply-To: <1493720992-1452@skroderider.denisbider.com> (denis bider's message of "Tue, 1 Dec 2015 10:10:03 +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: > SSHv3 is based on UDP, not TCP. Why??? To me, a reliable byte stream as provided by tcp seems like a building block fitting ssh needs pretty well. If you want to do that, and support filetransfers or anything else with the potential to use significant bandwidth, and get it blessed by ietf, you'd have to implement your own congestion control. Not that I have anything against congestion control work in general. I have even given in to the temptation and designed my own, during my phd studies. See https://www.lysator.liu.se/~nisse/network-book/. But I don't think this is the right place for congestion control work. 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 Dec 1 18:44:36 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94DE1B3186 for ; Tue, 1 Dec 2015 18:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9InJsbXCokY for ; Tue, 1 Dec 2015 18:44:35 -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 962941B3185 for ; Tue, 1 Dec 2015 18:44:35 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A010685E5F; Wed, 2 Dec 2015 02:44:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3928885E5B for ; Wed, 2 Dec 2015 02:44:30 +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 yEUQuNnJ2CXe for ; Wed, 2 Dec 2015 02:44:29 +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 A7F1985E3F for ; Wed, 2 Dec 2015 02:44:28 +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=1449024268; x=1480560268; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=b/BEJqpJaaRhz4/JKCVoufTaEfIUc16h4R1zCGkOnFg=; b=WkJ7JDz+tMEC0A9GAeUsJ1red6QH/653ZByJf1KAHh2SjVE8RU8JNYew c8fWCvjgA9Xsl+ZCXrN6fNpG74XPsN9HCdF3pTfZ6AZ8mR5p7xJTQHyG6 Ri5ZoQofy6f9r/ctBybbup3ehW37fIBJRR+O5VBeAhr6dRxV0FHhwlvuK WGV93vahzdAkB+cCTiUlbYRrNLfmcyYUfji1KG3bqngk9/lRwna6Jht7j IbxObvbLVtV28HNMKfVqqTkcCIfyUyhRvt778swZeOHZrWK8Aq7BsePCo 8z3JS6rjGe+lBh/wAoMYVJyvwsnCOWvDzzGASK3HxiNw8IyQdeWf7rKS4 A==; X-IronPort-AV: E=Sophos;i="5.20,371,1444647600"; d="scan'208";a="57156016" 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; 02 Dec 2015 14:09:35 +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; Wed, 2 Dec 2015 14:09:34 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Niels_M=F6ller?= CC: Damien Miller , Simon Tatham , "Simon Josefsson" , "ietf-ssh@netbsd.org" Subject: RE: Binary packet protocol rethink Thread-Topic: Binary packet protocol rethink Thread-Index: AQHRK2HLMJRbFzQ1ukq+Xs4ulafSe5625PVi Date: Wed, 2 Dec 2015 01:09:33 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B95D3F@uxcn10-5.UoA.auckland.ac.nz> References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@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="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= >The ssh transport machinery can encrypt these, then split them into fixed= =0A= >size blocks and send off with pre-determined intervals, and whatever else = you=0A= >think is a useful counter measure to traffic analysis. When an input messa= ge=0A= >or message fragment is too short, insert ignore messages (preferable in=0A= >*front* of the real data, for the byte-by-byte dribble attack).=0A= =0A= The important point there is that it *can*, not that it actually *does*. I= 've=0A= heard that there was an OpenSSH patch some years ago that did something lik= e=0A= this, but in about 15 years of interop-testing my code I've never seen any= =0A= evidence that the other side is applying any traffic-analysis countermeasur= es.=0A= A quick Google turns up this blog post from a few months ago:=0A= =0A= http://malwaremusings.com/2015/07/13/traffic-analysis-openssh-with-an-inter= active-shell/=0A= =0A= which indicates that OpenSSH doesn't implement traffic-analysis protection= =0A= (not trying to single out OpenSSH here, but that seems to have the most bel= ls=0A= and whistles added to it so if it was implemented I'd sort of expect to see= it=0A= there first), and that some random guy with a copy of Wireshark (not an=0A= intelligence agency, if that's what the perceived threat is) doesn't have m= uch=0A= problem in doing traffic analysis on it.=0A= =0A= So there appears to be either zero or close to zero support out there for= =0A= anti-traffic-analysis. Even if, say, OpenSSH were to add support, that wou= ld=0A= only affect two similar OpenSSH implementations talking to each other. As= =0A= soon as you get a single other SSH implementation involved (and there are a= =0A= lot of them out there), you lose the anti-traffic analysis.=0A= =0A= >I'm happy to discuss the tradeoffs here, but it seems that you keep repeat= ing=0A= >that the attacker gets as much useful info from observing tcp segment=0A= >boundaries as from observing ssh message boundaries.=0A= =0A= At the moment it seems they do. Unless actual, real countermeasures to=0A= traffic analysis are actively applied by as many SSH implementations as=0A= possible, encrypting the headers does nothing more than inconvenience=0A= implementers.=0A= =0A= So, let's turn this around: Show me evidence of assorted SSH implementation= s=0A= performing anti-traffic-analysis measures, and then we can debate whether= =0A= encrypting the length hinders those countermeasures.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Dec 1 19:18:37 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367B41B3201 for ; Tue, 1 Dec 2015 19:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrHCbGehKBQe for ; Tue, 1 Dec 2015 19:18: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 A53B21B3200 for ; Tue, 1 Dec 2015 19:18:36 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9E88785E73; Wed, 2 Dec 2015 03:18:35 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0C2D385E3F for ; Wed, 2 Dec 2015 03:18:34 +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 Sh9y09DrtdZo for ; Wed, 2 Dec 2015 03:18:33 +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 1370384C6C for ; Wed, 2 Dec 2015 03:18:32 +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=1449026314; x=1480562314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HVMHvGYYeeTnNTZ9LxPhMlsr1DzxEMJPEtxrZFH7DUs=; b=SrOl/QiSae4azBe3hZy666mVV3tqb7xNhgsFJNyotCJfSdCOG3/MrEWe gFf43fdhqI6Ik1rKIr4cG0hPO6adCZc5S0T8lF0fka1UCkXqC3/FPlGVk pFMkS32zCb0p4xWTHrtlyvpZ9bIwVqSNFckVMV2lOwUAqAixx/4DBcu9l SMsU3LVzgIgtRcrNHAKw9UDxZrgZZiLuNYw6+6OK8w/DPYu49793lsfJH VVi3oykcvuU1kg8AnnmcUhAWMh9hBjLg8ljjlpTHNQe0Q8RFGq5WeQgKg EjCa7wtydcKvi3VK3jsovTwadpljhGeWGZhORXGbswW0MEJ+1dI9HDv7C w==; X-IronPort-AV: E=Sophos;i="5.20,371,1444647600"; d="scan'208";a="57190092" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe3.UoA.auckland.ac.nz) ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Dec 2015 16:18:31 +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; Wed, 2 Dec 2015 16:18:30 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Niels_M=F6ller?= CC: Damien Miller , Simon Tatham , "Simon Josefsson" , "ietf-ssh@netbsd.org" Subject: RE: Binary packet protocol rethink Thread-Topic: Binary packet protocol rethink Thread-Index: AQHRK2HLMJRbFzQ1ukq+Xs4ulafSe5625PVigAAkE94= Date: Wed, 2 Dec 2015 03:18:29 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B95E88@uxcn10-5.UoA.auckland.ac.nz> References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz>,,<9A043F3CF02CD34C8E74AC1594475C73F4B95D3F@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B95D3F@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="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 I wrote:=0A= =0A= >and then we can debate whether encrypting the length hinders those=0A= >countermeasures=0A= =0A= Sorry, missing negation, that should be "not encrypting the length".=0A= =0A= (See also my post to the TLS list today on how to progress this issue,=0A= unfortunately the debate is by now spread across three lists, SSH, TLS, and= =0A= CFRG).=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Dec 1 23:24:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5A61B33F2 for ; Tue, 1 Dec 2015 23:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B5Oii7GT25K for ; Tue, 1 Dec 2015 23:24: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 BDC081B33F3 for ; Tue, 1 Dec 2015 23:24:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 46A1185E8A; Wed, 2 Dec 2015 07:24:28 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id E9E4B85E56; Wed, 2 Dec 2015 07:24:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2B40B85E71 for ; Tue, 1 Dec 2015 12:31:11 +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 SrxEvFZl_JW4 for ; Tue, 1 Dec 2015 12:31: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 0D6AE85E68 for ; Tue, 1 Dec 2015 12:31:09 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F3CC840018; Tue, 1 Dec 2015 13:31: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 0306F40014; Tue, 1 Dec 2015 13:31:06 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 01 Dec 2015 13:31:06 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Bryan Ford Cc: Simon Tatham , Peter Gutmann , Damien Miller , Simon Josefsson , "ietf-ssh\@netbsd.org" Subject: Re: Binary packet protocol rethink References: <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> <1448874084-sup-4376@atreus.tartarus.org> <55D41D88-55E6-4FC7-890B-62B5E075B3B7@gmail.com> Date: Tue, 01 Dec 2015 13:31:05 +0100 In-Reply-To: <55D41D88-55E6-4FC7-890B-62B5E075B3B7@gmail.com> (Bryan Ford's message of "Mon, 30 Nov 2015 14:58:22 +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 Bryan Ford writes: > It=E2=80=99s hard for me to see how separately authenticating the length = field > would be a benefit; in fact I would worry about whether it could > introduce a weakness, e.g., where an attacker could somehow contrive > =E2=80=9Cmix-and-match=E2=80=9D attacks I'm also not sure there's a real benefit. If we do it, the length and payload data must be securely linked together. E.g., using a single incrementing sequence of nonces. And it *may* be worthwhile to do something with a short and therefore relatively weak authentication tag. > Thus, changing the header encoding while leaving the authentication > and body-encryption unchanged from standard AEAD practice cannot make > security any worse than just transmitting the header (AD part) in > cleartext, and can (sometimes) be a security benefit. This is a clear argument. For this to hold, it's crucial that the length encryption and the payload encryption are independent. In SSH, there's been subtle problem when encrypting length and payload together using CBC (I don't quite grasp the fine details, but there have been references posted to the list recently). > SSH, which did something like this, ran into trouble with attackers > being able to twiddle the record length field to make the record length > look big, causing the receiver to try to receive a very large record, > and hence appear to the user to hang, I don't think we have had this particular problem; any reasonable ssh implementation ought to disconnect with a protocol error if the length is unexpectedly large. Lengths are maximum 32K (unless both ends have negotiated something different, which I think is rare). There have been problems, but of a more subtle kind. Like observing when and how the other end disconnect to get partial information about the decryption, and in addition, infer information about the preceding cleartext block thanks to the CBC relation. > The conceptually simplest approach I can think of: In the specification > of how AEAD nonces are generated (section 5.2.2 of > draft-ietf-tls-tls13-07), reserve the least-significant bit of the > record sequence number, so that sequence numbers increment by 2 rather > than 1 each record. Thus, we get two unique nonces per record from the > same set of symmetric keys. We first use the nonce with a '0' > least-significant bit to perform the regular AEAD-encryption of the > record with the header info as additional_data. I think I'd use them in the opposite order (to get the sequence numbers in processing order; one has to process the lengths first, in particular on the decryption side), but that's a very minor detail. I like the alternating nonces idea. > Then for the same record we use the nonce with a '1' least-significant > to AEAD-encrypt a sequence of five zero bytes ("\0\0\0\0\0"), and use > the first five bytes of result as the cipherstream to XOR the 5-byte TLS > header with before transmitting. I think AEAD constructions of practical importance generate a key stream and xor it to the plaintext. In which case your proposal (as I'm sure you intended) boils down to generating a key stream with a different nonce than for the payload. Not sure if doing a "general" construction on top of an arbitrary AEAD is useful; the alternative would be to leave the details to the specification of any particular aead suite. We're kind of ending up with "authenticated encryption with auxillary authenticated data and auxillary encrypted data". That's going to be a really awful acronym. 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 Dec 2 00:35:09 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AD71ACED6 for ; Wed, 2 Dec 2015 00:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq5gRAtgxd7w for ; Wed, 2 Dec 2015 00:35:08 -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 42C451A1A80 for ; Wed, 2 Dec 2015 00:35:08 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5B9F085E5A; Wed, 2 Dec 2015 08:35:07 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 62D7785E6E for ; Wed, 2 Dec 2015 08:35:05 +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 RY2Cn0ygysop for ; Wed, 2 Dec 2015 08:35:04 +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 A8C6A85E4A for ; Wed, 2 Dec 2015 08:35:03 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F2C6540006; Wed, 2 Dec 2015 09:35: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 E8FF940003; Wed, 2 Dec 2015 09:34:58 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Wed, 02 Dec 2015 09:34:58 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Damien Miller , Simon Tatham , Simon Josefsson , ietf-ssh@netbsd.org Subject: Re: SSH v3? References: <1537810400-3144@skroderider.denisbider.com> Date: Wed, 02 Dec 2015 09:34:58 +0100 In-Reply-To: <1537810400-3144@skroderider.denisbider.com> (denis bider's message of "Tue, 1 Dec 2015 22:23:24 +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: > - On connections prone to random errors (wireless), large transfers > are bound for disconnects at a rate of 2^-16 per error. TCP just > corrupts the data in this case. SSH detects the corruption, but cannot > recover from it. > - A TCP connection can be reset by a single spoofed RST packet from > anyone who knows the IP address and port number of one of the end > points. So you're basically saying that tcp sucks. That's not very ssh specific. Maybe it would make sense with some mechanism to let ssh reconnect after a tcp connection fails. You may also want to have a look at mptcp, which, among other things, can let a connection survive failure of a single tcp flow. > - TCP prevents efficient tunneling of datagram flow over an SSH > session: introduces unnecessary lag to maintain stream abstraction for > applications that don't need it. It's definitely possible to tunnel udp over tcp (with or without ssh being involved). Whether or not that's good enough depends on the application. What are the usecases for udp-tunneling over ssh? You also have dtls, which might solve your problem in a better way than ssh (I'm sorry I don't know the details of that protocol). Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 2 03:41:30 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0CE1A8700 for ; Wed, 2 Dec 2015 03:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnK7GXiOwCcA for ; Wed, 2 Dec 2015 03:41: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 E1E731A01EC for ; Wed, 2 Dec 2015 03:41:28 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B3BB585E96; Wed, 2 Dec 2015 11:41: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 2F37F85E95 for ; Wed, 2 Dec 2015 11:41: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 3oYl4dialeTz for ; Wed, 2 Dec 2015 11:41:25 +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 5815285E73 for ; Wed, 2 Dec 2015 11:41:24 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2C81740015; Wed, 2 Dec 2015 12:41: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 5237340006; Wed, 2 Dec 2015 12:41:20 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Wed, 02 Dec 2015 12:41:20 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Peter Gutmann Cc: Damien Miller , Simon Tatham , "Simon Josefsson" , "ietf-ssh\@netbsd.org" Subject: Re: Binary packet protocol rethink References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B95D3F@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 02 Dec 2015 12:41:19 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B95D3F@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 2 Dec 2015 01:09:33 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > So, let's turn this around: Show me evidence of assorted SSH implementati= ons > performing anti-traffic-analysis measures, I implemented the type of hiding we're discussing almost a decade ago, and I'm using it daily. Now, I'm not working on lsh as actively these days as I'd like, but I'd really like this part to get better, not worse. If most other implementations don't care, that's unfortunate. I'm sure we could learn to do this quite well. 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 Dec 2 04:52:50 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14521A89AE for ; Wed, 2 Dec 2015 04:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-Svlv-LM1k0 for ; Wed, 2 Dec 2015 04:52:49 -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 0B0851A89AC for ; Wed, 2 Dec 2015 04:52:49 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6BC6885E89; Wed, 2 Dec 2015 12:45:13 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 439D385E87 for ; Wed, 2 Dec 2015 12:45: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 mniyyeDldRZe for ; Wed, 2 Dec 2015 12:45:09 +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 3A69E85E5C for ; Wed, 2 Dec 2015 12:45:07 +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 tB2BZIun001292 for ; Wed, 2 Dec 2015 21:35:18 +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 tB2BZI8R016948 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 2 Dec 2015 21:35:18 +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 tB2BZI2H016258 for ; Wed, 2 Dec 2015 21:35:18 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 6675BA4F2E; Wed, 2 Dec 2015 22:35:18 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 617CAA4F07 for ; Wed, 2 Dec 2015 22:35:18 +1100 (AEDT) Date: Wed, 2 Dec 2015 22:35:18 +1100 (AEDT) From: Damien Miller To: ietf-ssh@netbsd.org Subject: Feedback on draft-ssh-ext-info-00 Message-ID: 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: 1449056119 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi, Here's some feedback on draft-ssh-ext-info-00. > 3.1. Signaling of Extension Negotiation in KEXINIT ... > The indicator name is added without quotes, and MAY be added at any > position in the name-list, subject to proper separation from other > names as per name-list conventions. The suggested position is last in > the list, but implementations MUST recognize these indicator names > when included at any position. IMO it would be best to make it a MUST that the flags may only be sent as the last element. What rationale is there for putting it anywhere else? > 3.2. Mechanism Enabling Criteria This whole section seems over-complicated. I think a simpler scheme is: If a client or server offers "ext-info-c" or "ext-info-s" respectively, then it must be prepared to accept a SSH_MSG_EXT_INFO message from the peer. If this message is sent, then it will be the first message after the initial SSH_MSG_NEWKEYS. I.e. make it a simple advertisment that a client or server is willing to accept a notification message that might optionally be sent. Don't require both sides to offer acceptance, don't have the messages offer any sort of negotiation between the client and server (just statements of extensions/capabilities) and don't "replace" any messages like SSH_MSG_SERVICE_REQUEST. This would yield a much simpler specification IMO. > 4. Initially Defined Extensions > 4.2. "client-req-ok" I don't see the point of this: implementations that don't respond with SSH_MSG_REQUEST_FAILURE to unknown SSH_MSG_GLOBAL_REQUEST messages are incompliant with RFC4254 section 4. OpenSSH has sent various @openssh.com global requests for years, so most of the implementations that violate this should have long since been shaken out. > 4.3. "no-handbrake" This could be implemented more elegantly using new channel type names in SSH_MSG_CHANNEL_OPEN messages rather than the complicated and inflexible method proposed here (e.g. it's impossible to have one channel without the "handbrake" and one with normal flow control). It would be better to use the extension to signal that the peer is willing to accept SSH_MSG_CHANNEL_OPEN messages with new channel type names, and use these to selectively disable flow control. Given this, IMO this would be better off being replaced by a generic "these are the channel types I'm prepared to open" message, which would be useful even for implementation that don't want to turn off flow control but which do implement non-standard channel types (e.g. tun@openssh.com). -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 2 06:39:45 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF6F1A90D3 for ; Wed, 2 Dec 2015 06:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S40xuYExxRD4 for ; Wed, 2 Dec 2015 06:39:44 -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 964251A90DE for ; Wed, 2 Dec 2015 06:39:36 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8619085E95; Wed, 2 Dec 2015 14:39: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 C214785E93 for ; Wed, 2 Dec 2015 14:39:15 +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 WjIijkZdrFUM for ; Wed, 2 Dec 2015 14:39:15 +0000 (UTC) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 D325C85E8F for ; Wed, 2 Dec 2015 14:39:14 +0000 (UTC) Received: by wmvv187 with SMTP id v187so258084923wmv.1 for ; Wed, 02 Dec 2015 06:39:13 -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 :content-transfer-encoding:message-id:references:to; bh=5PBMG+LBV81D1tp3407bSS1RsKcJKzycOrld/iE6faY=; b=UQMbBhpPSs8dTt9HoCBbGjo6hXT3B3ljdjDoTLW/wtBIOdRpcCRf1OnrPe6EdhL9j8 lereqtY9OJMgu7RdolLxhG/7Oy87YDDqcUg8Wl8RNO7viiY+H0zb4lHIfOoou+MJ9K4Q jpc8r8f5wa51AUsDJV+WC2lY6FQOKvzSIsVGlq2V5chKw58Wlpykon69QbQI45kF0oeI 0fXi5biKzpSrUl5jEMT2HqG06Z47jffiNpDQNZ9GukcDNMuro70oNxxH45jZhDg7QSYB 5cLTJstuLNwfoMzqeruoIRenNivkQ4byLGQJdupLcIwNhpoAh4OwrDgEvufvdIZwnWTC 3enA== X-Received: by 10.28.46.206 with SMTP id u197mr42276867wmu.86.1449067153441; Wed, 02 Dec 2015 06:39:13 -0800 (PST) Received: from [172.23.1.24] (p3EE06EC7.dip0.t-ipconnect.de. [62.224.110.199]) by smtp.gmail.com with ESMTPSA id i18sm3528271wmf.6.2015.12.02.06.39.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 06:39:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Feedback on draft-ssh-ext-info-00 From: Markus Friedl In-Reply-To: Date: Wed, 2 Dec 2015 15:39:10 +0100 Cc: Damien Miller Content-Transfer-Encoding: 7bit Message-Id: References: To: ietf-ssh@netbsd.org X-Mailer: Apple Mail (2.3096.5) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I'm in the process of implementing draft-rsa-dsa-sha2-256-03 and welcome a way for signaling SHA2 support to the client for userauth, especially since I'm sabotaging protocol extensions with the strict message format checks I've added to OpenSSH before. However, I also agree with Damien that the suggested proposal seems unnecessary complex to me and will try to implement the simpler scheme he suggests. -m > Am 02.12.2015 um 12:35 schrieb Damien Miller : > > Hi, > > Here's some feedback on draft-ssh-ext-info-00. > >> 3.1. Signaling of Extension Negotiation in KEXINIT > ... >> The indicator name is added without quotes, and MAY be added at any >> position in the name-list, subject to proper separation from other >> names as per name-list conventions. The suggested position is last in >> the list, but implementations MUST recognize these indicator names >> when included at any position. > > IMO it would be best to make it a MUST that the flags may only be > sent as the last element. What rationale is there for putting it > anywhere else? > >> 3.2. Mechanism Enabling Criteria > > This whole section seems over-complicated. I think a simpler scheme > is: > > If a client or server offers "ext-info-c" or "ext-info-s" respectively, > then it must be prepared to accept a SSH_MSG_EXT_INFO message from the > peer. > > If this message is sent, then it will be the first message after the > initial SSH_MSG_NEWKEYS. > > I.e. make it a simple advertisment that a client or server is willing > to accept a notification message that might optionally be sent. > Don't require both sides to offer acceptance, don't have the messages > offer any sort of negotiation between the client and server (just > statements of extensions/capabilities) and don't "replace" any > messages like SSH_MSG_SERVICE_REQUEST. > > This would yield a much simpler specification IMO. > >> 4. Initially Defined Extensions >> 4.2. "client-req-ok" > > I don't see the point of this: implementations that don't respond with > SSH_MSG_REQUEST_FAILURE to unknown SSH_MSG_GLOBAL_REQUEST messages are > incompliant with RFC4254 section 4. > > OpenSSH has sent various @openssh.com global requests for years, > so most of the implementations that violate this should have long since > been shaken out. > >> 4.3. "no-handbrake" > > This could be implemented more elegantly using new channel type names > in SSH_MSG_CHANNEL_OPEN messages rather than the complicated and > inflexible method proposed here (e.g. it's impossible to have one > channel without the "handbrake" and one with normal flow control). > > It would be better to use the extension to signal that the > peer is willing to accept SSH_MSG_CHANNEL_OPEN messages with new channel > type names, and use these to selectively disable flow control. > > Given this, IMO this would be better off being replaced by a generic > "these are the channel types I'm prepared to open" message, which would > be useful even for implementation that don't want to turn off flow control > but which do implement non-standard channel types (e.g. tun@openssh.com). > > -d > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 2 15:14:36 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2A31A21BC for ; Wed, 2 Dec 2015 15:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oykCtt9ucJ6 for ; Wed, 2 Dec 2015 15:14:35 -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 06D9B1A1B1F for ; Wed, 2 Dec 2015 15:14:35 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id AE99485EC0; Wed, 2 Dec 2015 23:14:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2A0F785EB2 for ; Wed, 2 Dec 2015 23:14:32 +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 adxyG003RdCH for ; Wed, 2 Dec 2015 23:14:31 +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 F1A8F85E4A for ; Wed, 2 Dec 2015 23:14:26 +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=1449098071; x=1480634071; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RFidJvTdAHCD4NuHG39TkJ6E/6ylsY58/MnjgT/GOks=; b=A50QObgQRmNedSfsFaYCtjoDRRXJPAlI6qcMhFXy5Fgaq25b6gpp4+y7 eFEeKd14CUeM7q2c6TCTMdrsAwHqn/541jUuRT7KbDcgDgO0xAkpC196B LW/q5Lhjd6yxb/ye6uRuE4hTVhw3agjNtjqgQVs7+gjPAQfOmYwOLUy7f r3bY+En+jQl9Rjvhz3aNw56dSDm1dswyB1TbMHT/6o+jHl446dbl2IIBe WP/JO98nRYBkHVCoSmYH+HjCmxZCZVldBoCvi93KaBZdfnBLtyFCtUnTC HNKqwNKdfV3LNxlEX2XOUI9FdjG6i2QN4FVjkvuSFzW0gpj3jtBaBlfs8 A==; X-IronPort-AV: E=Sophos;i="5.20,375,1444647600"; d="scan'208";a="57322749" 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; 03 Dec 2015 12:14:24 +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, 3 Dec 2015 12:14:24 +1300 From: Peter Gutmann To: Markus Friedl , "ietf-ssh@netbsd.org" CC: Damien Miller Subject: RE: Feedback on draft-ssh-ext-info-00 Thread-Topic: Feedback on draft-ssh-ext-info-00 Thread-Index: AQHRLP9MOk6t5sv1I0ywABy5Xd0b7J626nwAgAFpxkc= Date: Wed, 2 Dec 2015 23:14:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9722B@uxcn10-5.UoA.auckland.ac.nz> References: , 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="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 Markus Friedl writes:=0A= =0A= >I'm in the process of implementing draft-rsa-dsa-sha2-256-03 and welcome a= =0A= >way for signaling SHA2 support to the client for userauth,=0A= =0A= Doesn't the presence of "rsa-sha2-256" do this? The client proposes it, an= d=0A= if the server supports it, they indicate via the algorithm string. It's=0A= pretty much independent of draft-ssh-ext-info-00 (I know it specifies=0A= "server-sig-algs", but it seems that specifying "rsa-sha2-256" was already= =0A= sufficient to indicate this).=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 2 15:23:36 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122FE1A906A for ; Wed, 2 Dec 2015 15:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7C7So6zT48Q for ; Wed, 2 Dec 2015 15:23:35 -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 0AD1B1A1A6A for ; Wed, 2 Dec 2015 15:23:35 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 1835685EA4; Wed, 2 Dec 2015 23:23: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 AA09C85E94 for ; Wed, 2 Dec 2015 23:23:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 1ytw8x_7oAkY for ; Wed, 2 Dec 2015 23:23:31 +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 A882085E4A for ; Wed, 2 Dec 2015 23:23:30 +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=1449098610; x=1480634610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wpqhHLE7RfQTccDRHlGB5pFArwlp+bC8fc9p+1EKmOw=; b=Y1JLqEzV2BTl5hXkpq3TFcXSAnUcYJS5FGJ+D/iUzFc4P/pLI3x63aCI uDNidiM2XNh3/Yk6BQ2ZAFywjOw3gMk6IXO+ghMUFpVa6E33FVhAzfdpU pKDXHEQgXNb+PzKrV0gXkTK7gAFPSv32PmznQuynCajBmAuAd3KuXbGuJ mIK4WlLyy7dlP31lpksMKxyXtX/qo0fr1WkMgQsvX+GjZTyjAW8oARP71 x62tzgzQ9XQikYRDLjoV1qh1mnA7Q6CDcfyI65w16wS+zzlcVgHSMkgA7 UBQNdJ2UhtRejvDanc37pKOOSmf55f9iFLqWwmgUU3jTOhODv9ho3SuW/ w==; X-IronPort-AV: E=Sophos;i="5.20,375,1444647600"; d="scan'208";a="57329158" 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; 03 Dec 2015 12:23:29 +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; Thu, 3 Dec 2015 12:23:29 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Niels_M=F6ller?= CC: Damien Miller , Simon Tatham , "Simon Josefsson" , "ietf-ssh@netbsd.org" Subject: RE: Binary packet protocol rethink Thread-Topic: Binary packet protocol rethink Thread-Index: AQHRLPZcMJRbFzQ1ukq+Xs4ulafSe564VSP5 Date: Wed, 2 Dec 2015 23:23:27 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B97254@uxcn10-5.UoA.auckland.ac.nz> References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B95D3F@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="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= >I implemented the type of hiding we're discussing almost a decade ago, and= =0A= >I'm using it daily. Now, I'm not working on lsh as actively these days as = =0A= >I'd like, but I'd really like this part to get better, not worse.=0A= =0A= Ah, so it was lsh, not OpenSSH, my bad. It'd be interesting to get some = =0A= guidance on what works and what doesn't, for example if you're doing bulk= =0A= file transfers it's easy enough to traffic-shape (and my code does that=0A= if possible, mostly to optimise network performance), but when you get into= =0A= things like interactive traffic or variable-size messages that have to be= =0A= sent right now (e.g. alerts/logging data), there's not much you can do=0A= beyond padding it.=0A= =0A= In addition a lot of SSH is produced as add-on libraries, for which the =0A= traffic being passed is opaque (and it's the same for TLS). So the=0A= traffic-shaping needs to be controlled by the developer that's using the = =0A= library, not the library author, and that's probably not going to happen.= =0A= One side can't take responsibility for the issue, and the other side=0A= doesn't want to because they have more pressing things to deal with.=0A= =0A= I'm not aware of any comprehensive analysis/guidance on dealing with these= =0A= issues...=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 2 16:59:42 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4031AD367 for ; Wed, 2 Dec 2015 16:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy-5W88o9rys for ; Wed, 2 Dec 2015 16:59: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 5695E1AD366 for ; Wed, 2 Dec 2015 16:59:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4282185EB0; Thu, 3 Dec 2015 00:59: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 6F0EF85E9E for ; Thu, 3 Dec 2015 00:59:38 +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 ixcWN-eZzfvH for ; Thu, 3 Dec 2015 00:59:38 +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 67C3A85E9A for ; Thu, 3 Dec 2015 00:59:35 +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 tB2NsRjq007474; Thu, 3 Dec 2015 09:54:27 +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 tB2NsRub030545 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Dec 2015 09:54:27 +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 tB2NsQSZ029310; Thu, 3 Dec 2015 09:54:26 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id C2807A4F32; Thu, 3 Dec 2015 10:54:26 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id C1E0CA4F30; Thu, 3 Dec 2015 10:54:26 +1100 (AEDT) Date: Thu, 3 Dec 2015 10:54:26 +1100 (AEDT) From: Damien Miller To: Peter Gutmann cc: Markus Friedl , "ietf-ssh@netbsd.org" Subject: RE: Feedback on draft-ssh-ext-info-00 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9722B@uxcn10-5.UoA.auckland.ac.nz> Message-ID: References: , <9A043F3CF02CD34C8E74AC1594475C73F4B9722B@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: 1449100467 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 2 Dec 2015, Peter Gutmann wrote: > Markus Friedl writes: > > >I'm in the process of implementing draft-rsa-dsa-sha2-256-03 and welcome a > >way for signaling SHA2 support to the client for userauth, > > Doesn't the presence of "rsa-sha2-256" do this? The client proposes it, and > if the server supports it, they indicate via the algorithm string. It's > pretty much independent of draft-ssh-ext-info-00 (I know it specifies > "server-sig-algs", but it seems that specifying "rsa-sha2-256" was already > sufficient to indicate this). The problem is that, for a client to test whether rsa-sha2-256 is supported, it must make publickey userauth with an included signature. A signature free PK_OK style request won't do since the key blob just contains ssh-rsa and not the signature algorithm. Making a signature-ful request means unwrapping the private key and, depending on the implementation, burning an authentication attempt at the server. Even then, the client only gets back a USERAUTH_FAILURE that doesn't indicate whether the attempt was refused because of the key itself, additional restrictions on the key or because the signature algorithm is not supported. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 2 19:10:25 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E291B3051 for ; Wed, 2 Dec 2015 19:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XySJoUKfW0lj for ; Wed, 2 Dec 2015 19:10:23 -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 E31301B304E for ; Wed, 2 Dec 2015 19:10:22 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id ADA9585EB0; Thu, 3 Dec 2015 03:10:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E3F5B85EB6 for ; Thu, 3 Dec 2015 03:10:15 +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 9OgcQ8jOk-zA for ; Thu, 3 Dec 2015 03:10:15 +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 C8C5985E89 for ; Thu, 3 Dec 2015 03:10:12 +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 tB33A5WU029381; Thu, 3 Dec 2015 13:10:05 +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 tB33A4t4025064 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Dec 2015 13:10:04 +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 tB33A4U7009893; Thu, 3 Dec 2015 13:10:04 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 14629A4F2E; Thu, 3 Dec 2015 14:10:04 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 0F2A6A4F07; Thu, 3 Dec 2015 14:10:04 +1100 (AEDT) Date: Thu, 3 Dec 2015 14:10:04 +1100 (AEDT) From: Damien Miller To: denis bider cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 In-Reply-To: <1631879346-2660@skroderider.denisbider.com> Message-ID: References: <1631879346-2660@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.79.58 X-UQ-FilterTime: 1449112206 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, 3 Dec 2015, denis bider wrote: > > IMO it would be best to make it a MUST that the flags > > may only be sent as the last element. What rationale is > > there for putting it anywhere else? > > In the event that there are two or more competing extension mechanisms, only > one of them can be last. If there's a functioning extension mechanism, then why would there be competition? Even if there were, then it's up to whoever writes the second one to deal with making their fit. > > and don't "replace" any messages like > > SSH_MSG_SERVICE_REQUEST. > > But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. :) > > Does no one agree that SERVICE_REQUEST + ACCEPT are pointless? > > A whole round-trip delay? For no benefit - in any known usage scenario? IMO replacing messages in the protocol is something best saved for SSH-3.x. IIRC I've heard of at least one server that doesn't implement ssh-userauth. > > OpenSSH has sent various @openssh.com global > > requests for years, so most of the implementations > > that violate this should have long since been shaken out. > > Do you happen to know: > > - Since which version the OpenSSH server has been sending global requests? 3.8ish, released early 2004 > - Since which version the OpenSSH client has been tolerating them? at least that long :) > There are still folks out there using OpenSSH 3.x and 4.x. I'm pretty sure I > saw our software being connected to by a client like that in the past week. 4.x should be fine, older 3.x might have problems - I haven't checked. Honestly though, anyone using OpenSSH 3.x has bigger problems than channel requests upsetting their connections. > > (e.g. it's impossible to have one channel without the > > "handbrake" and one with normal flow control) > > As discussed, this is on purpose. If you want multiplexing, implement > multiplexing, including flow control. > > If even one channel does not have flow control, this affects the transport > layer also. It affects keep-alive mechanisms, key exchange, and flow control > at the transport level. Right, "no-handbrake" breaks all of these. I'm not sure what the gain is either compared to making the SSH window match the TCP window size. It's not like SSH can go send more data than that. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 2 20:08:43 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5975B1B2F93 for ; Wed, 2 Dec 2015 20:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8zgFNQa4mfl for ; Wed, 2 Dec 2015 20:08: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 6FFB21B2F92 for ; Wed, 2 Dec 2015 20:08:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 1456485EB9; Thu, 3 Dec 2015 04: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 B664085EB6 for ; Thu, 3 Dec 2015 04:08:38 +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 yu8ZUluVYR47 for ; Thu, 3 Dec 2015 04:08:38 +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 EBC6F85E93 for ; Thu, 3 Dec 2015 04:08:37 +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 tB348XX7007627; Thu, 3 Dec 2015 14:08:33 +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 tB348X2k059004 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Dec 2015 14:08:33 +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 tB348WYT024602; Thu, 3 Dec 2015 14:08:33 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 7DCFDA4F2E; Thu, 3 Dec 2015 15:08:32 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 794DCA4F07; Thu, 3 Dec 2015 15:08:32 +1100 (AEDT) Date: Thu, 3 Dec 2015 15:08:32 +1100 (AEDT) From: Damien Miller To: denis bider cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 In-Reply-To: <1644184986-3540@skroderider.denisbider.com> Message-ID: References: <1644184986-3540@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.79.58 X-UQ-FilterTime: 1449115713 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, 3 Dec 2015, denis bider wrote: > Another possible way to use the key exchange algorithms field for an > extension in parallel with EXT_INFO might be to change the way SSH host key > algorithms are negotiated, for example. The current negotiation rules have > serious drawbacks, not least that the client has no way of learning the SSH > server's other host keys if it already trusts one. You might be interested in: https://anongit.mindrot.org/openssh.git/tree/PROTOCOL?id=f0191d7c8#n284 Hostkey rotation within the current protocol with no messing around with KEXINIT. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 2 22:31:43 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B0A1B31C2 for ; Wed, 2 Dec 2015 22:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBZOFPb9VhPe for ; Wed, 2 Dec 2015 22:31: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 401051B31C1 for ; Wed, 2 Dec 2015 22:31:41 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 434B385EBC; Thu, 3 Dec 2015 06:31: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 E5B3E85EB6 for ; Thu, 3 Dec 2015 06:31:37 +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 vp5ddpDdotGv for ; Thu, 3 Dec 2015 06:31:37 +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 D657185E57 for ; Thu, 3 Dec 2015 06:31:34 +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 tB36VRkP018392; Thu, 3 Dec 2015 16:31:28 +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 tB36VRNv047543 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Dec 2015 16:31:27 +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 tB36VQgd017316; Thu, 3 Dec 2015 16:31:27 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 924F8A4F30; Thu, 3 Dec 2015 17:31:26 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 91A8BA4F2F; Thu, 3 Dec 2015 17:31:26 +1100 (AEDT) Date: Thu, 3 Dec 2015 17:31:26 +1100 (AEDT) From: Damien Miller To: denis bider cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 In-Reply-To: <1647427311-3540@skroderider.denisbider.com> Message-ID: References: <1647427311-3540@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: 1449124288 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, 3 Dec 2015, denis bider wrote: > I have posted a new draft to address this: > > https://tools.ietf.org/html/draft-ssh-ext-info-03 > > The difference is that there is now a "services" field in EXT_INFO: > > byte SSH_MSG_EXT_INFO (value 7) > name-list services > uint32 nr-extensions > repeat "nr-extensions" times: > string extension-name > string extension-value > > And a section to describe it: > > 3.5. Service Negotiation > The client and server each include a name-list of supported services > in EXT_INFO. The name-lists are matched to negotiate a service in the > same way as name-lists are matched in KEXINIT. Clients and servers > that support only "ssh-userauth" MUST send this service name only. > Implementations supporting only one service MAY assume it will be > negotiated, and MAY send messages on that premise without waiting. > > Would you agree this makes EXT_INFO a proper superset of SERVICE_REQUEST + > ACCEPT? This is over-complicated. Why add fixed-function fields to a generic extension mechanism? I'd support a simple magic name, offered in KEXINIT to indicate that an implementation is prepared to accept a SSH_MSG_EXT_INFO packet. Merely advertising a willingness to accept SSH_MSG_EXT_INFO shouldn't have other further effects on the protocol. To do otherwise is IMO quite surprising. Then, if you want to define a "die-service-request-die" extension that changes the protocol flow then you can do that without requiring other implementations to follow suit. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 2 23:14:53 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A385A1B326B for ; Wed, 2 Dec 2015 23:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oShHJ7i0LwXH for ; Wed, 2 Dec 2015 23:14:52 -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 5AE931B324A for ; Wed, 2 Dec 2015 23:14:52 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 40B9E85EBD; Thu, 3 Dec 2015 07:14:51 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 88C8A85EBC for ; Thu, 3 Dec 2015 07:14: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 gZ3LX6mXvGK8 for ; Thu, 3 Dec 2015 07:14:49 +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 B5E7485EB6 for ; Thu, 3 Dec 2015 07:14:48 +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 tB37EfvN018207; Thu, 3 Dec 2015 17:14:42 +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 tB37Ef5r060673 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Dec 2015 17:14:41 +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 tB37Ee9n024424; Thu, 3 Dec 2015 17:14:41 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id BF374A4F31; Thu, 3 Dec 2015 18:14:40 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id BE97BA4F2F; Thu, 3 Dec 2015 18:14:40 +1100 (AEDT) Date: Thu, 3 Dec 2015 18:14:40 +1100 (AEDT) From: Damien Miller To: denis bider cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 In-Reply-To: <1654355845-3540@skroderider.denisbider.com> Message-ID: References: <1654355845-3540@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: 1449126883 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, 3 Dec 2015, denis bider wrote: > > Merely advertising a willingness to accept SSH_MSG_EXT_INFO > > shouldn't have other further effects on the protocol. To do > > otherwise is IMO quite surprising. > > Okay, imagine this: > > (1) Instead of the EXT_INFO message, we continue to send SERVICE_REQUEST + > ACCEPT. > > (2) The KEXINIT extension instead signals that extension fields can be added > to SERVICE_REQUEST + ACCEPT. > > (3) Presence of the KEXINIT extension further signals that the server can > send a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUEST. > > Do you see that this results in the same proposal, just with renamed > messages? At the risk of repeating myself, I think providing a simple transport layer extension mechanism is a fantastic idea, but don't agree that it should make other protocol changes (except, perhaps as extensions defined in the same document). -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 3 00:23:25 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2704A1B3164 for ; Thu, 3 Dec 2015 00:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id busp7MTLiTl6 for ; Thu, 3 Dec 2015 00:23:24 -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 A74231B3239 for ; Thu, 3 Dec 2015 00:23:22 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 71D3E85E8F; Thu, 3 Dec 2015 08:23:21 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5E29285E8A for ; Thu, 3 Dec 2015 08:23:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 4B-j70B4yAhv for ; Thu, 3 Dec 2015 08:23:18 +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 747ED85E47 for ; Thu, 3 Dec 2015 08:23:18 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 1517E4001B; Thu, 3 Dec 2015 09:23: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 914F840012; Thu, 3 Dec 2015 09:23:14 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 03 Dec 2015 09:23:14 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Damien Miller Cc: Peter Gutmann , Markus Friedl , "ietf-ssh\@netbsd.org" Subject: Re: Feedback on draft-ssh-ext-info-00 References: <9A043F3CF02CD34C8E74AC1594475C73F4B9722B@uxcn10-5.UoA.auckland.ac.nz> Date: Thu, 03 Dec 2015 09:23:14 +0100 In-Reply-To: (Damien Miller's message of "Thu, 3 Dec 2015 10:54:26 +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: > The problem is that, for a client to test whether rsa-sha2-256 is support= ed, > it must make publickey userauth with an included signature. A > signature free PK_OK style request won't do since the key blob just > contains ssh-rsa and not the signature algorithm. Hmm. This sounds like a serious breakage, and if that's the case, we really ought to use a new algorithm name also in the key blob. But is it really so? Looking at RFC 5252, we have byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC3629] string service name in US-ASCII string "publickey" boolean FALSE string public key algorithm name string public key blob and byte SSH_MSG_USERAUTH_PK_OK string public key algorithm name from the request string public key blob from the request I'd expect the "public key algorithm name" to be "ssh-rsa-sha2-256", and then it's fine if the string inside the keyblob is "ssh-rsa". There's no ambiguity as to what type of signature is intended. 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 Dec 3 00:32:21 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2081B32AB for ; Thu, 3 Dec 2015 00:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fIS49P2pDOE for ; Thu, 3 Dec 2015 00:32: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 5A6E21ACD46 for ; Thu, 3 Dec 2015 00:32:20 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 73B5D85E93; Thu, 3 Dec 2015 08:32: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 E042485E8A for ; Thu, 3 Dec 2015 08:32:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id V84NV57DfR76 for ; Thu, 3 Dec 2015 08:32:17 +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 3ABF985E47 for ; Thu, 3 Dec 2015 08:32:16 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3650440026; Thu, 3 Dec 2015 09:31:36 +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 DD18440021; Thu, 3 Dec 2015 09:31:34 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 03 Dec 2015 09:31:34 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Damien Miller Cc: denis bider , Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 References: <1631879346-2660@skroderider.denisbider.com> Date: Thu, 03 Dec 2015 09:31:34 +0100 In-Reply-To: (Damien Miller's message of "Thu, 3 Dec 2015 14:10:04 +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: >> But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. :) >>=20 >> Does no one agree that SERVICE_REQUEST + ACCEPT are pointless? >> >> A whole round-trip delay? For no benefit - in any known usage >> scenario? I think the entire point of the "awful" design, where you don't get a second chance, just a disconnect in case the service isn't available, is to eliminate that roundtrip delay. You can send a service request for "ssh-userauth", followed back-to-back by userauth requests for "none", PK_OK, whatever querying you like. And one roundtrip later, you can compute the needed signature for a likely successful publickey userauth request. 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 Dec 3 01:18:33 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0111B333C for ; Thu, 3 Dec 2015 01:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.279 X-Spam-Level: ** X-Spam-Status: No, score=2.279 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, FRT_STOCK2=3.988, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_z7dJLzjE0k for ; Thu, 3 Dec 2015 01:18:32 -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 146821B333B for ; Thu, 3 Dec 2015 01:18:32 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 31C9D85E9D; Thu, 3 Dec 2015 09:18:31 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C68D085E6E for ; Thu, 3 Dec 2015 09:18:23 +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 b-ohRLaB_0m6 for ; Thu, 3 Dec 2015 09:18:23 +0000 (UTC) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 82A7885EC2 for ; Thu, 3 Dec 2015 09:18:22 +0000 (UTC) Received: by wmww144 with SMTP id w144so12381554wmw.1 for ; Thu, 03 Dec 2015 01:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=2vLh0VYCYxGZZqZTz+8lZiIGwZc6khzacfxKQjGKd5I=; b=j0XgiVoAHIPjQlff4SAwf+XwhWPU0g0Hohhu39EFYbamy5lJ0UU+sbHZ9kidW/VQep CdU0g5IN0GDsbpcRWip0j0dHCRFIiKFXsuiOldVsHK3CgsdeT1dbU2nNBPNcjZf4hr2g /YFeCy3L8grOpQ8p6WmSz1N6tPEM6sJTIpNbD2faDhd49LGJIAiLWwg38xzLHL4ixPTJ 6w/KxPwux6a67ONGAEdXRLjn9Nrlg8Q14/H/bfaQ0LN/0SNqMy8mHaUrqUFsdXUvx55Y 27HRRxQMVFir7O5OIwaL5LXC/94jCw2y5PZIYiCEpT20wIAOLICEtoS72DqqHxoJFF9w kHYw== X-Received: by 10.194.184.104 with SMTP id et8mr10387567wjc.87.1449134300873; Thu, 03 Dec 2015 01:18:20 -0800 (PST) Received: from tsf-476-wpa-0-180.epfl.ch (tsf-476-wpa-0-180.epfl.ch. [128.179.176.180]) by smtp.gmail.com with ESMTPSA id t5sm7006029wmt.1.2015.12.03.01.18.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 01:18:19 -0800 (PST) Subject: Re: SSH v3? To: denis bider , =?UTF-8?Q?Niels_M=c3=b6ller?= References: <1639608151-3144@skroderider.denisbider.com> Cc: ietf-ssh@netbsd.org From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <566008DF.3030902@gmail.com> Date: Thu, 3 Dec 2015 10:18:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1639608151-3144@skroderider.denisbider.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020204010104030505050601" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a cryptographically signed message in MIME format. --------------ms020204010104030505050601 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/3/15 3:46 AM, denis bider wrote: > Hey Bryan - >=20 > thank you for sharing this, I was not previously aware of Minion. >=20 > The main issue I see is that Minion /does/ in fact seem to require > modification at the OS level. Even though the changes needed might be > small, this won't fly unless Linux and Windows both decide to support i= t. Yes, that's indeed the catch. And even though the kernel change required is only like a pretty trivial hundred lines or so (can't remember precisely), we have the chicken-and-egg problem that Linux and Windows kernel devs don't want to upstream it until a "major" user-space application wants to use it, but "major" user-space applications don't want to adopt it until it's supported in mainstream kernels. :/ But if (say) OpenSSH expressed serious interest in adopting Minion, I think that could easily break this chicken-and-egg deadlock. And it shouldn't constitute any "risk" that I can see, since Minion is backward-compatible and incrementally deployable in pretty much all the ways I can envision caring about, including in particular: - (a) if the user-space SSH implementation supports it but the kernel patch isn't present, nothing bad happens other than that endpoint doesn't get the performance benefit of being able to receive packets out-of-order. The SSH implementation basically just calls a setsockopt that the kernel doesn't support, the kernel returns an error, and the SSH implementation returns to in-order business as usual. - (b) if one SSH endpoint (and its kernel) supports Minion but the other endpoint (or its kernel) doesn't, you still get out-of-order performance benefits for traffic flowing in one direction but just not for traffic on the same connection flowing in the other direction. > Most SSH implementations I'm aware of are user-mode implementations, by= > organizations and/or volunteers who are not familiar with, and do not > have access to modify, the TCP stack on systems where their SSH > implementation runs. This is certainly true for me, I can't change the > TCP implementation in Windows. I wouldn't suggest it to be the task of SSH developers to implement the Windows/Linux/FoozleOS kernel patches required to support Minion, and there's no reason we should expect every mainstream OS to incorporate the kernel patch any time soon, but you still get incremental benefits as soon as even one OS and one user-space application (e.g., OpenSSH) supports it. And if the SSH community showed enough interest in adopting Minion to consider supporting it in the (next) protocol spec and prototyping it (even experimentally) in at least one SSH implementation, that would provide a much stronger basis on which to argue for the Minion kernel enhancement to be adopted in kernels, breaking the chicken-and-egg problem. > Without underlying platform support, it seems to me the best that SSH > can do is to either (1) implement support for UDP as an ancillary > transport for latency-sensitive traffic, or to (2) migrate wholesale to= UDP. >=20 > My "EST" suggestion rebuilds the whole protocol on top of UDP. But > perhaps, implementing support for UDP as an ancillary transport would b= e > a more compatible fit with current SSH usage. And also, as you point ou= t > in your paper, it would be a better fit for connections where UDP is no= t > available due to firewall/routing issues. I'm definitely not against designing protocols to be operable atop UDP as well; there are certainly tradeoffs each way. > If you can get Windows + Linux to implement uTCP though, that would hav= e > the benefit of avoiding even the firewall/routing issues still faced by= UDP. Exactly, that's one such tradeoff. Another is power efficiency for mobile devices: you can keep a mostly-idle TCP connection open for a lot longer than a mostly-idle UDP connection before typical middleboxes silently time-out and forget the state. (e.g., the BEHAVE spec requires TCP timeouts to be on the order of hours, as I recall, whereas UDP middlebox-state timeouts are typically on the order of minutes.) Cheers Bryan --------------ms020204010104030505050601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwMzA5MTgyM1owLwYJKoZIhvcNAQkEMSIEIBGgPdOPUGJNsOoyfGXjRjNiG2nFyaiC7KJQ YNgGbzf6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBACyfxzerz4h2WYKY XZ2Qq9pqu+1sr7iolhEgm9S2HG+yhqrySmiqfVryvvCo8ctzSK04VhgcuENPEbuCNiB3tAZa D0nIuSUCaPyr7x16cCgtF8Zywb00Sg/h+spsYKjHu1zeehisDEKPlhY1NeTs7kWHCMqLwkEL rNRlfOYZIm2xZsQYQUEs1ucQ4x3S1/fFszdu9UoxXu19XWh6Mex85ikTnb5doTapObphlRt3 gYbw429nC3sUUBqWCtVn9dlO0kH67OggoohmYrHSy2HPyPfh046FSddqKJ8RYslbIJ5RUo6v e/Pe/OlVpaakKc978lzUxi+Gmi57eP/kY54fO5AAAAAAAAA= --------------ms020204010104030505050601-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 3 01:32:26 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1320F1A8A20 for ; Thu, 3 Dec 2015 01:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJbZVRcxS-Vv for ; Thu, 3 Dec 2015 01:32:21 -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 468491A8AC8 for ; Thu, 3 Dec 2015 01:32:21 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 42AE485E9D; Thu, 3 Dec 2015 09:32:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 39A2A85E9C for ; Thu, 3 Dec 2015 09:32:15 +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 AxP1C9fPzskO for ; Thu, 3 Dec 2015 09:32:14 +0000 (UTC) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 2451785E6E for ; Thu, 3 Dec 2015 09:32:14 +0000 (UTC) Received: by wmec201 with SMTP id c201so17451307wme.0 for ; Thu, 03 Dec 2015 01:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vmHF6nGTIT1/UPc1RxlABPsjYVLRdnf1O6ZowsYZTMo=; b=xuKx01LlVSfIpu/vNAQiHM6+asTbYhLuBx++7XGEZ+B3h3NqXuXXWPQnOnWDdDzNOT 0upzFgptMJWGyQMFlxuvpYkZLXoVtpLKB63i/9Hm4F1kYXWeENdUUuUrGtw4umQ1jUki Ap9fEvNaBgtiwJ86duqgEg3i0eYRihTfqLXhRvY4C6U6X+z+cae23h1hMr3UwGnrPhQd 6XCuC6tn0ktTV13qHUgqtsJfTPS/uxnZ3c2mEpAH4bsqxLJgJtnFSRH0eiCYpqNv0B4b pOTYTKOS4xuU0ikaF4F63H7bnnqaJP+PmZ4tsZoI86Cj8vE0lCVFn2+fKX2sp1/ML7Ly 9Diw== X-Received: by 10.28.229.65 with SMTP id c62mr10457900wmh.25.1449135132349; Thu, 03 Dec 2015 01:32:12 -0800 (PST) Received: from p20030056c67f81a55c4fc75eee29fad3.dip0.t-ipconnect.de (p20030056C67F81A55C4FC75EEE29FAD3.dip0.t-ipconnect.de. [2003:56:c67f:81a5:5c4f:c75e:ee29:fad3]) by smtp.gmail.com with ESMTPSA id jt9sm6700635wjc.24.2015.12.03.01.32.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 01:32:11 -0800 (PST) Subject: Re: Feedback on draft-ssh-ext-info-00 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: text/plain; charset=us-ascii From: Markus Friedl X-Priority: 3 In-Reply-To: <16AF71A1-8021-4531-8ECA-5471DFD1CF7D@gmail.com> Date: Thu, 3 Dec 2015 10:32:10 +0100 Cc: Damien Miller , ietf-ssh@netbsd.org Content-Transfer-Encoding: 7bit Message-Id: <85FB8FEB-E280-4996-90E7-399DCAEDAF3D@gmail.com> References: <1631450999-4056@skroderider.denisbider.com> <16AF71A1-8021-4531-8ECA-5471DFD1CF7D@gmail.com> To: denis bider X-Mailer: Apple Mail (2.3096.5) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Here is what I've implemented for OpenSSH: 3. Extension Negotiation Mechanism 3.1. Signaling of Extension Negotiation in KEXINIT Applications implementing this mechanism MUST add to the field "kex_algorithms", in their KEXINIT packet sent for the first key exchange, one of the following indicator names: - When acting as server: "ext-info-s" - When acting as client: "ext-info-c" The indicator name is added without quotes, and MAY be added at any position in the name-list, subject to proper separation from other names as per name-list conventions. The names are added to the "kex_algorithms" field because this is one of two name-list fields in KEXINIT that do not have a separate copy for each data direction. The indicator names inserted by the client and server are different to ensure that these names will not produce a match, and will be neutral with respect to key exchange algorithm negotiation. The inclusion of textual indicator names is intended to provide a clue for implementers to discover this mechanism. 3.2. Mechanism Enabling Criteria If a client or server offers "ext-info-c" or "ext-info-s" respectively, then it must be prepared to accept a SSH_MSG_EXT_INFO message from the peer. Thus a server only needs to send "ext-info-s" if it intends to process SSH_MSG_EXT_INFO from the client. If a server receives an "ext-info-c", then it can send a SSH_MSG_EXT_INFO message, but it's not required to do so. If a SSH_MSG_EXT_INFO message is sent, then it MUST be the first message after the initial SSH_MSG_NEWKEYS. This way a server will send the SSH_MSG_EXT_INFO before sending a possible SERVICE_ACCEPT message. Implementations MUST NOT send an incorrect indicator name for their role. Implementations MAY disconnect if the counter-party does so. If an indicator name ("ext-info-c" or "ext-info-s") ends up being negotiated as a key exchange method, the parties MUST disconnect. 3.3. Indicating Extensions A party that received the "ext-info-c" or "ext-info-s" indicator can send the the following message: byte SSH_MSG_EXT_INFO (value 7) uint32 nr-extensions repeat "nr-extensions" times: string extension-name string extension-value This message is sent without delay, and immediately after SSH_MSG_NEWKEYS. 3.4. Interpretation of Extension Names and Values Each extension is identified by its extension-name, and defines the conditions under which the extension is considered to be in effect. Applications MUST ignore unrecognized extension-names. Extension-value fields are interpreted as defined by their respective extension. An extension-value field MAY be an empty string if so permitted by the extension. Applications that do not implement or recognize a particular extension MUST ignore the associated extension-value field, regardless of its size or content. The cumulative size of an SSH_MSG_EXT_INFO message is limited only by the maximum packet length that an implementation may apply in accordance with [RFC4253]. Implementations MUST accept well-formed SSH_MSG_EXT_INFO messages up to the maximum packet length they accept. 4. Initially Defined Extensions 4.1. "server-sig-algs" This extension is sent with the following extension name and value: string "server-sig-algs" name-list signature-algorithms-accepted Note that the name-list type is a strict subset of the string type, and is thus permissible as an extension-value. This extension is sent by the server only, and contains a list of signature algorithms that the server is able to process as part of a "publickey" authentication request. A client that wishes to proceed with public key authentication MAY wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" authentication request with an appropriate signature algorithm, rather than resorting to trial and error. Servers that implement public key authentication SHOULD implement this extension. If a server does not send this extension, a client SHALL NOT make any assumptions about the server's signature algorithm support, and MAY proceed with authentication request trial and error. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 3 02:59:04 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1B31B3386 for ; Thu, 3 Dec 2015 02:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cYuStK5jg2x for ; Thu, 3 Dec 2015 02:59:03 -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 261ED1B2DB1 for ; Thu, 3 Dec 2015 02:59:03 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0E87885EC1; Thu, 3 Dec 2015 10:59:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 459F285EBC for ; Thu, 3 Dec 2015 10:59:00 +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 TmB3TwDL9Oqn for ; Thu, 3 Dec 2015 10:58:59 +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 56AA385EAC for ; Thu, 3 Dec 2015 10:58:58 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 058464000F; Thu, 3 Dec 2015 11:58:56 +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 C0F3B4001B; Thu, 3 Dec 2015 11:58:54 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 03 Dec 2015 11:58:54 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Damien Miller , Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 References: <1661294754-3540@skroderider.denisbider.com> Date: Thu, 03 Dec 2015 11:58:54 +0100 In-Reply-To: <1661294754-3540@skroderider.denisbider.com> (denis bider's message of "Thu, 3 Dec 2015 08:39: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 Regarding sending SERVICE_REQUEST and userauth messages back-to-back, denis bider writes: > I'm not sure that we have a guarantee that the server must properly > handle this chaining. Have you seen any implementations broken is this way? I'd expect any reasonable server to process incoming messages properly, and in case it for some reason isn't ready to process the next logical message, simply delay reading and processing messages until it is ready. After all, the protocol is very intentionally designed to minimize the number of roundtrip delays. > One would imagine people would not do this, but I've dealt with an > implementation that discards KEXINIT if it's received in the same > network frame as the SSH version string. I think that's a different bug, and not very relevant. That's the point where you switch from new-line-delimited text data to the binary data, which needs some care to get right. 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 Dec 3 04:51:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1821B34F1 for ; Thu, 3 Dec 2015 04:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KpLDA2VF69H for ; Thu, 3 Dec 2015 04:51: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 0C1651A896D for ; Thu, 3 Dec 2015 04:51:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E600885EBD; Thu, 3 Dec 2015 12:51: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 19DD885EB0 for ; Thu, 3 Dec 2015 12:51: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 hCF7ZvRP-LSW for ; Thu, 3 Dec 2015 12:51:25 +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 62F3885E8A for ; Thu, 3 Dec 2015 12:51:24 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id BA26040011; Thu, 3 Dec 2015 13:51:21 +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 7FED740010; Thu, 3 Dec 2015 13:51:19 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 03 Dec 2015 13:51:19 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Markus Friedl Cc: denis bider , Damien Miller , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 References: <1631450999-4056@skroderider.denisbider.com> <16AF71A1-8021-4531-8ECA-5471DFD1CF7D@gmail.com> <85FB8FEB-E280-4996-90E7-399DCAEDAF3D@gmail.com> Date: Thu, 03 Dec 2015 13:51:19 +0100 In-Reply-To: <85FB8FEB-E280-4996-90E7-399DCAEDAF3D@gmail.com> (Markus Friedl's message of "Thu, 3 Dec 2015 10:32:10 +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 Markus Friedl writes: > Here is what I've implemented for OpenSSH: Looks nice and simple to me. The trick of adding foo-s and foo-c symbols to the kex_algorithms list could perhaps be reused in case we need to negotiate support for aead, to enable different rules for algorithm negotiation (including the rules for first_kex_packet_follows). > This extension is sent with the following extension name and value: > > string "server-sig-algs" > name-list signature-algorithms-accepted I still question the utility of this extension. I would expect the common case will be a large list of algorithms, and the the client needs to send a PK_OK request for each key it has anyway. But I don't object to it if others find it useful. Maybe "userauth-sig-algs" or "publickey-algs" is a better name, to make it clearer that it is related to publickey userauth. 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 Dec 3 19:24:46 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6601B2B52 for ; Thu, 3 Dec 2015 19:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb_L3bslSR2D for ; Thu, 3 Dec 2015 19:24:45 -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 AEE521B2AB3 for ; Thu, 3 Dec 2015 19:24:45 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5601185E8A; Fri, 4 Dec 2015 03:24: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 5801185E89 for ; Fri, 4 Dec 2015 03:24: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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id aB9rAWjYrUPq for ; Fri, 4 Dec 2015 03:24: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 4998585E54 for ; Fri, 4 Dec 2015 03:24:38 +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=1449199481; x=1480735481; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Cwhf1tB5L7vAGAysStOoJZZRBgQITnlWUuo5XE1IOxU=; b=WExVt6vb5qteBaVrqLtg+ZtpIDsI08wuaVuRP3LiAN9LkEp9xvJhSxOC GETG/iX2kYGd6bVumFwutsOm7yLJdZX65Y0K0DjJApMS797EZ03b2NxL7 NTn2RFss7eqE35JB1tFnkI8X1UrxRoEm7fm7SRP8ZmuQD4/oXPXBA5owr PwI/WWo0w5N/f/H76PJYX16w+fO/B2VF5Do9jOaxLOEb9WD8hJZpQTwxk SIJfeGQG+JgbYim4wzcZHn6ABLizNK2NUaAQVVYUy/HFdyej0dk5Q8AR+ 79f0azUzWmvo05XJv+fVERDI8GUTKzlQ5Vxn5utG6wpYSjZNcADL/8rd3 A==; X-IronPort-AV: E=Sophos;i="5.20,378,1444647600"; d="scan'208";a="57593828" 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; 04 Dec 2015 16:24:32 +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; Fri, 4 Dec 2015 16:24:32 +1300 From: Peter Gutmann To: denis bider , Markus Friedl , Damien Miller CC: "ietf-ssh@netbsd.org" Subject: RE: Feedback on draft-ssh-ext-info-00 Thread-Topic: Feedback on draft-ssh-ext-info-00 Thread-Index: AQHRLW84Ok6t5sv1I0ywABy5Xd0b7J66K2KO Date: Fri, 4 Dec 2015 03:24:31 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B986A0@uxcn10-5.UoA.auckland.ac.nz> References: <1637842921-3540@skroderider.denisbider.com> In-Reply-To: <1637842921-3540@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= >Presence of "rsa-sha2-256" as a host key signature algorithm cannot reliab= ly=0A= >serve as an indicator for user authentication, because it requires the ser= ver=0A= >to actually have an RSA host key.=0A= =0A= Ah, OK, I'd missed that. Maybe the -sha2 draft could point this out, I saw= =0A= section 3 but didn't connect it with the issues of identifying algorithms,= =0A= since my code does all of them so will just accept something like an ECDSA= =0A= server sig combined with an RSA client sig.=0A= =0A= >The server might only have an ECDSA host key; but may still accept and pre= fer=0A= >"rsa-sha2-256" signatures for client authentication.=0A= =0A= Hmm, which leads to a follow-on question, is this actually going to be an= =0A= issue? Are there going to be implementations out there that support signat= ure=0A= algorithm A in one case but only signature algorithm B in another?=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:05:01 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBCF1B2B8F for ; Sat, 5 Dec 2015 10:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOnthoPB9fwa for ; Sat, 5 Dec 2015 10:04: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 5DE5B1B2B8E for ; Sat, 5 Dec 2015 10:04:59 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D109A85F09; Sat, 5 Dec 2015 18:04:54 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 7AE7185F08; Sat, 5 Dec 2015 18:04:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 235EC85E94 for ; Fri, 4 Dec 2015 10:20:18 +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 zTwBD50QX37w for ; Fri, 4 Dec 2015 10:20:17 +0000 (UTC) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 4864485E83 for ; Fri, 4 Dec 2015 10:20:17 +0000 (UTC) Received: by wmvv187 with SMTP id v187so67410510wmv.1 for ; Fri, 04 Dec 2015 02:20:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=k+nQ/4nf/LLZPMpqOiRIRVKbYC+SM/YtRCNlNn7OPJY=; b=XeBdFVp0ruOD8TiOHOwVzmeoEgzwFnLQyt/Ap9e8NWnLGXOhshGH2w2MRhV0hwPj60 8Re0tAYfon89pgcha6CWLoLFFZBxamIpHbtpNDxLvuUsAMjsG2/UApED3N1nZci+738g w6kIzLaLaHNBEiQw1DrUyTJhTnpZWIzK6ZvNlZy33bnczk9328hzeyVXCgSv3H464teA AcE8VBa1aYNYplDlJ0qMh3nFbFrhc02TviEsjAH+n3y9WtqUgjy88yKMZeen5Oph+mLa jRidfJHL9nbcGuSdJMc9ug6bw/pZELk5+3sHf+c1Bvc2JztYkeXAvKTx+vWDcw3EmqUy 5DXw== X-Received: by 10.194.75.202 with SMTP id e10mr18673556wjw.160.1449224415655; Fri, 04 Dec 2015 02:20:15 -0800 (PST) Received: from icsil1noteb193.epfl.ch (icsil1noteb193.epfl.ch. [128.178.151.41]) by smtp.gmail.com with ESMTPSA id w4sm11429856wje.49.2015.12.04.02.20.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Dec 2015 02:20:14 -0800 (PST) Subject: Re: SSH v3? Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CD577F45-D9CF-4611-9627-EF174544E6E9"; protocol="application/pkcs7-signature"; micalg=sha1 From: Bryan Ford X-Priority: 3 In-Reply-To: <1665779424-2152@skroderider.denisbider.com> Date: Fri, 4 Dec 2015 11:20:13 +0100 Cc: =?utf-8?Q?Niels_M=C3=B6ller?= , Markus Friedl , Damien Miller , ietf-ssh@netbsd.org Message-Id: <3522C5F3-ED26-44A1-A44C-6FB1E8CCB4ED@gmail.com> References: <1665779424-2152@skroderider.denisbider.com> To: denis bider X-Mailer: Apple Mail (2.3096.5) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_CD577F45-D9CF-4611-9627-EF174544E6E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 03 Dec 2015, at 10:53, denis bider wrote: > On the Linux side, perhaps OpenSSH might indeed have an interest in = Minion, as an improvement to its existing capabilities of layer 2 and = layer 3 tunneling? Indeed I think that=E2=80=99s a perfect fit and motivation for Minion, = and if there=E2=80=99s interest I would be happy to do whatever I can to = assist in making that happen. > On the Windows side, it seems a good bet might be Skype. It's owned by = Microsoft, is a major application, and experiences TCP-related problems = that Minion would solve. Agreed, although I personally have less experience with Windows and no = immediate contacts with the Skype folks that I know of. > I'm not sure how hard it might be to attract the attention of some = Skype developers, but sometimes it can be as easy as Twitter. Indeed, worth a try! B= --Apple-Mail=_CD577F45-D9CF-4611-9627-EF174544E6E9 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 Fw0xNTEyMDQxMDIwMTRaMCMGCSqGSIb3DQEJBDEWBBRXAwaDhLn2RmQDMHNK8UFE4s3WqzCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAHqfKOlv6mDEZJjMfvcDgQnM8OroC0ZhgWZuqwS3+UYLobP/NuFisN7NRdpoNe6kr dyvK5no6R7iei9wdU+qIeKz5I6m7vD7TAtrYkPjgMmSkCTqKY9DelpPs9qq0///0eoZYrHItgZS7 BLin+CPPSzIKUqMszttIgw6G3gsseEOtSfSKXlHhbqQueJmUJRDnjp2pcByslyefHNGxdDr88Drk cQBmMy7FUXNX9/wzVz8FjONNw5iOp9SNf2QKsQixbKorQZVMYTnYNXiWC8GOwjpMrG5vRSipAUDE XffdK5aRafhdiUUvPSyYhusrKdW4wZw9mM4gq8RCD94RzuX7lwAAAAAAAA== --Apple-Mail=_CD577F45-D9CF-4611-9627-EF174544E6E9-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:08:34 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A135C1B2B9E for ; Sat, 5 Dec 2015 10:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f62gggQZudnl for ; Sat, 5 Dec 2015 10:08:32 -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 135D51B2B9D for ; Sat, 5 Dec 2015 10:08:32 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id AF9B485F08; Sat, 5 Dec 2015 18:08:18 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 4B64B85F17; Sat, 5 Dec 2015 18:07:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DCE6385EB0 for ; Thu, 3 Dec 2015 03:45:38 +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 fz7OYCyJCubE for ; Thu, 3 Dec 2015 03:45:38 +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 1D06385EA1 for ; Thu, 3 Dec 2015 03:45:38 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Thu, 3 Dec 2015 03:45:33 +0000 Date: Thu, 3 Dec 2015 03:45:33 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1642890958-3540@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Damien Miller , Markus Friedl Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-daI7qYVQxQi9CptQ/6b/" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-daI7qYVQxQi9CptQ/6b/ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > If there's a functioning extension mechanism, > then why would there be competition? To extend other aspects of SSH that EXT_INFO cannot. This could be to chang= e some aspect of algorithm negotiation, for example. For instance, there has been a problem in how AEAD is negotiated. Besides w= hat OpenSSH did - implementing a private algorithm for AES-GCM - another po= ssible solution could be an extension where both client and server put some= thing in their key exchange algorithms field. If both client and server do = this, then the result of MAC negotiation is ignored if an AEAD encryption a= lgorithm is negotiated. But why do you even feel the need to call this out? Is it any harder to cal= l: =C2=A0=C2=A0=C2=A0 is_in_namelist(name, namelist) instead of: =C2=A0=C2=A0=C2=A0 is_at_end_of_namelist(name, namelist) ? You are saying, "I can't envision a usage scenario for this, so let's prev= ent it." This is pompous, because you implicitly consider yourself capable = of predicting such scenarios. Further, you are doing this for zero benefit;= as a matter of principle; and just after we've been through conversations = where I've pointed out that we cannot predict future needs, and that this = attitude - "prohibit it because we can" - has already created problems. > IIRC I've heard of at least one server that doesn't > implement ssh-userauth. This is possible with EXT_INFO also. Send an extension name and value infor= ming the client of what you implement. No need to waste a round-trip for 99= .999% of other users. > I'm not sure what the gain is either compared to making > the SSH window match the TCP window size. It's not like > SSH can go send more data than that. Just simplicity, for implementations that want it. A user mode app doesn't necessarily have info about what goes on at the TCP= level, and if it does, it's something a single-channel implementation does= n't want to have to bother with. denis ----- Original Message ----- From: Damien Miller=20 Sent: Wednesday, December 2, 2015 21:10 To: denis bider=20 Cc: Markus Friedl ; ietf-ssh@netbsd.org=20 Subject: Re: Feedback on draft-ssh-ext-info-00 On Thu, 3 Dec 2015, denis bider wrote: > > IMO it would be best to make it a MUST that the flags > > may only be sent as the last element. What rationale is > > there for putting it anywhere else? >=20 > In the event that there are two or more competing extension mechanisms, o= nly > one of them can be last. If there's a functioning extension mechanism, then why would there be competition? Even if there were, then it's up to whoever writes the second one to deal with making their fit. > > and don't "replace" any messages like > > SSH_MSG_SERVICE_REQUEST. >=20 > But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. :) >=20 > Does no one agree that SERVICE_REQUEST + ACCEPT are pointless? >=20 > A whole round-trip delay? For no benefit - in any known usage scenario? IMO replacing messages in the protocol is something best saved for SSH-3.x. IIRC I've heard of at least one server that doesn't implement ssh-userauth. > > OpenSSH has sent various @openssh.com global > > requests for years, so most of the implementations > > that violate this should have long since been shaken out. >=20 > Do you happen to know: >=20 > - Since which version the OpenSSH server has been sending global requests= ? 3.8ish, released early 2004 > - Since which version the OpenSSH client has been tolerating them? at least that long :) > There are still folks out there using OpenSSH 3.x and 4.x. I'm pretty sur= e I > saw our software being connected to by a client like that in the past wee= k. 4.x should be fine, older 3.x might have problems - I haven't checked. Honestly though, anyone using OpenSSH 3.x has bigger problems than channel requests upsetting their connections. > > (e.g. it's impossible to have one channel without the > > "handbrake" and one with normal flow control) >=20 > As discussed, this is on purpose. If you want multiplexing, implement > multiplexing, including flow control. >=20 > If even one channel does not have flow control, this affects the transpor= t > layer also. It affects keep-alive mechanisms, key exchange, and flow cont= rol > at the transport level. Right, "no-handbrake" breaks all of these. I'm not sure what the gain is either compared to making the SSH window match the TCP window size. It's not like SSH can go send more data than that. -d = --=-daI7qYVQxQi9CptQ/6b/ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > If there's a functioning extension mechanism,=
> then why would there be competition?

To extend other aspect= s of SSH that EXT_INFO cannot. This could be to change some aspect of algor= ithm negotiation, for example.

For instance, there has been a proble= m in how AEAD is negotiated. Besides what OpenSSH did - implementing a priv= ate algorithm for AES-GCM - another possible solution could be an extension= where both client and server put something in their key exchange algorithm= s field. If both client and server do this, then the result of MAC negotiat= ion is ignored if an AEAD encryption algorithm is negotiated.

But wh= y do you even feel the need to call this out? Is it any harder to call:
=
    is_in_namelist(name, namelist)

instead of:
    is_at_end_of_namelist(name, namelist)

?
<= br>You are saying, "I can't envision a usage scenario for this, so let's prevent it." This is pompous, because yo= u implicitly consider yourself capable of predicting such scenarios.= Further, you are doing this for zero benefit; as a matter of princi= ple; and just after we've been through conversations where=20 I've pointed out that we cannot predict future needs, and that this = attitude - "prohibit it because we can" - has already created problems.
=

> IIRC I've heard of at least one server that doesn't
> im= plement ssh-userauth.

This is possible with EXT_INFO also. Send an e= xtension name and value informing the client of what you implement. No need= to waste a round-trip for 99.999% of other users.


> I'm not = sure what the gain is either compared to making
> the SSH window matc= h the TCP window size. It's not like
> SSH can go send more data than= that.

Just simplicity, for implementations that want it.

A u= ser mode app doesn't necessarily have info about what goes on at the TCP le= vel, and if it does, it's something a single-channel implementation doesn't= want to have to bother with.

denis


----- Original Messag= e -----
From: Damien Miller
Sent: Wednesday, December 2, 2015 21:10<= br>To: denis bider
Cc: Markus Friedl ; ietf-ssh@netbsd.org
Subject:= Re: Feedback on draft-ssh-ext-info-00

On Thu, 3 Dec 2015, denis bid= er wrote:

> > IMO it would be best to make it a MUST that the = flags
> > may only be sent as the last element. What rationale is<= br>> > there for putting it anywhere else?
>
> In the ev= ent that there are two or more competing extension mechanisms, only
>= one of them can be last.

If there's a functioning extension mechani= sm, then why would there be
competition?

Even if there were, then= it's up to whoever writes the second one to
deal with making their fit.=

> > and don't "replace" any messages like
> > SSH_MS= G_SERVICE_REQUEST.
>
> But but but I waaaant to replace this a= wful SSH_MSG_SERVICE_REQUEST. :)
>
> Does no one agree that SE= RVICE_REQUEST + ACCEPT are pointless?
>
> A whole round-trip d= elay? For no benefit - in any known usage scenario?

IMO replacing me= ssages in the protocol is something best saved for
SSH-3.x. IIRC I've he= ard of at least one server that doesn't implement
ssh-userauth.

&= gt; > OpenSSH has sent various @openssh.com global
> > requests= for years, so most of the implementations
> > that violate this s= hould have long since been shaken out.
>
> Do you happen to kn= ow:
>
> - Since which version the OpenSSH server has been send= ing global requests?

3.8ish, released early 2004

> - Since= which version the OpenSSH client has been tolerating them?

at least= that long :)

> There are still folks out there using OpenSSH 3.x= and 4.x. I'm pretty sure I
> saw our software being connected to by = a client like that in the past week.

4.x should be fine, older 3.x m= ight have problems - I haven't checked.

Honestly though, anyone usin= g OpenSSH 3.x has bigger problems than
channel requests upsetting their = connections.

> > (e.g. it's impossible to have one channel wit= hout the
> > "handbrake" and one with normal flow control)
>=
> As discussed, this is on purpose. If you want multiplexing, imple= ment
> multiplexing, including flow control.
>
> If even= one channel does not have flow control, this affects the transport
>= layer also. It affects keep-alive mechanisms, key exchange, and flow contr= ol
> at the transport level.

Right, "no-handbrake" breaks all = of these. I'm not sure what the gain is
either compared to making the SS= H window match the TCP window size. It's
not like SSH can go send more d= ata than that.

-d

= --=-daI7qYVQxQi9CptQ/6b/-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:09:17 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49F51B2BA6 for ; Sat, 5 Dec 2015 10:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLMtOW-yYkxy for ; Sat, 5 Dec 2015 10:09: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 BEA6D1B2BA5 for ; Sat, 5 Dec 2015 10:09:08 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 0F9C585F0D; Sat, 5 Dec 2015 18:08:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id A1AFF85F15; Sat, 5 Dec 2015 18:07:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F2ACC85E9C for ; Thu, 3 Dec 2015 10:34:46 +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 Lz_bPRKxXuly for ; Thu, 3 Dec 2015 10:34: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 0721085E47 for ; Thu, 3 Dec 2015 10:34:45 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for mfriedl@gmail.com; Thu, 3 Dec 2015 10:34:39 +0000 Date: Thu, 3 Dec 2015 10:34:39 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1668100891-3540@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Markus Friedl , Damien Miller Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-zu0PLbGyxRxe0A2M+GXB" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-zu0PLbGyxRxe0A2M+GXB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Excellent! I think this will work. I have updated the draft to reflect this: https://tools.ietf.org/html/draft-ssh-ext-info-04 I have shortened it much by removing the discussion section, which is now s= uperfluous because it has been discussed. I have kept the following section. I'm not sure if you currently implement = this. I think it's important for the client to tolerate a secondary EXT_INF= O just before USERAUTH_SUCCESS, so that servers can advertise additional ex= tensions after the client has been authenticated. 2.4.=C2=A0 Server's Secondary SSH_MSG_EXT_INFO =C2=A0 If the client sent "ext-info-c", the server MAY send, but is not =C2=A0 obligated to, send an SSH_MSG_EXT_INFO message immediately before =C2=A0 SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY se= nd =C2=A0 this message whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS. =C2=A0 This allows a server to reveal support for additional extensions tha= t =C2=A0 it was unwilling to reveal to an unauthenticated client. If a server =C2=A0 sends a subsequent SSH_MSG_EXT_INFO, this replaces any previous ones= , =C2=A0 and both the client and the server re-evaluate extensions in effect. =C2=A0 The server's last EXT_INFO is matched against the client's original. I have also renamed "no-handbrake" to "no-flow-control". What do you think? ----- Original Message ----- From: Markus Friedl=20 Sent: Thursday, December 3, 2015 03:32 To: denis bider=20 Cc: Damien Miller ; ietf-ssh@netbsd.org=20 Subject: Re: Feedback on draft-ssh-ext-info-00 Here is what I've implemented for OpenSSH: 3.=C2=A0 Extension Negotiation Mechanism 3.1.=C2=A0 Signaling of Extension Negotiation in KEXINIT =C2=A0 Applications implementing this mechanism MUST add to the field =C2=A0 "kex_algorithms", in their KEXINIT packet sent for the first key =C2=A0 exchange, one of the following indicator names: =C2=A0 - When acting as server: "ext-info-s" =C2=A0 - When acting as client: "ext-info-c" =C2=A0 The indicator name is added without quotes, and MAY be added at any =C2=A0 position in the name-list, subject to proper separation from other =C2=A0 names as per name-list conventions. =C2=A0 The names are added to the "kex_algorithms" field because this is on= e =C2=A0 of two name-list fields in KEXINIT that do not have a separate copy =C2=A0 for each data direction. =C2=A0 The indicator names inserted by the client and server are different = to =C2=A0 ensure that these names will not produce a match, and will be neutra= l =C2=A0 with respect to key exchange algorithm negotiation. =C2=A0 The inclusion of textual indicator names is intended to provide a cl= ue =C2=A0 for implementers to discover this mechanism. 3.2.=C2=A0 Mechanism Enabling Criteria =C2=A0 If a client or server offers "ext-info-c" or "ext-info-s" =C2=A0 respectively, then it must be prepared to accept a SSH_MSG_EXT_INFO =C2=A0 message from the peer. =C2=A0 Thus a server only needs to send "ext-info-s" if it intends to =C2=A0 process SSH_MSG_EXT_INFO from the client. =C2=A0 If a server receives an "ext-info-c", then it can send a =C2=A0 SSH_MSG_EXT_INFO message, but it's not required to do so. =C2=A0 If a SSH_MSG_EXT_INFO message is sent, then it MUST be the first =C2=A0 message after the initial SSH_MSG_NEWKEYS. =C2=A0 This way a server will send the SSH_MSG_EXT_INFO before sending =C2=A0 a possible SERVICE_ACCEPT message. =C2=A0 Implementations MUST NOT send an incorrect indicator name for their =C2=A0 role. Implementations MAY disconnect if the counter-party does so. =C2=A0 If an indicator name ("ext-info-c" or "ext-info-s") ends up being =C2=A0 negotiated as a key exchange method, the parties MUST disconnect. 3.3.=C2=A0 Indicating Extensions =C2=A0 A party that received the "ext-info-c" or "ext-info-s" indicator =C2=A0 can send the the following message: =C2=A0=C2=A0=C2=A0 byte=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SSH_MSG_EXT_INF= O (value 7) =C2=A0=C2=A0=C2=A0 uint32=C2=A0=C2=A0=C2=A0=C2=A0 nr-extensions =C2=A0=C2=A0=C2=A0 repeat "nr-extensions" times: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string=C2=A0=C2=A0 extension-name =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string=C2=A0=C2=A0 extension-value =C2=A0 This message is sent without delay, and immediately after =C2=A0 SSH_MSG_NEWKEYS. 3.4.=C2=A0 Interpretation of Extension Names and Values =C2=A0 Each extension is identified by its extension-name, and defines the =C2=A0 conditions under which the extension is considered to be in effect. =C2=A0 Applications MUST ignore unrecognized extension-names. =C2=A0 Extension-value fields are interpreted as defined by their respectiv= e =C2=A0 extension. An extension-value field MAY be an empty string if so =C2=A0 permitted by the extension. Applications that do not implement =C2=A0 or recognize a particular extension MUST ignore the associated =C2=A0 extension-value field, regardless of its size or content. =C2=A0 The cumulative size of an SSH_MSG_EXT_INFO message is limited only b= y =C2=A0 the maximum packet length that an implementation may apply in =C2=A0 accordance with [RFC4253]. Implementations MUST accept well-formed =C2=A0 SSH_MSG_EXT_INFO messages up to the maximum packet length they accep= t. 4. Initially Defined Extensions 4.1. "server-sig-algs" =C2=A0 This extension is sent with the following extension name and value: =C2=A0=C2=A0=C2=A0 string=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "server-sig-algs" =C2=A0=C2=A0=C2=A0 name-list=C2=A0=C2=A0 signature-algorithms-accepted =C2=A0 Note that the name-list type is a strict subset of the string type, =C2=A0 and is thus permissible as an extension-value. =C2=A0 This extension is sent by the server only, and contains a list of =C2=A0 signature algorithms that the server is able to process as part of a =C2=A0 "publickey" authentication request. =C2=A0 A client that wishes to proceed with public key authentication MAY =C2=A0 wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" =C2=A0 authentication request with an appropriate signature algorithm, rath= er =C2=A0 than resorting to trial and error. =C2=A0 Servers that implement public key authentication SHOULD implement th= is =C2=A0 extension. =C2=A0 If a server does not send this extension, a client SHALL NOT make an= y =C2=A0 assumptions about the server's signature algorithm support, and MAY =C2=A0 proceed with authentication request trial and error. = --=-zu0PLbGyxRxe0A2M+GXB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Excellent! I think this will work.

I have u= pdated the draft to reflect this:

https://tools.ietf.org/html/draft-= ssh-ext-info-04

I have shortened it much by removing the discussion = section, which is now superfluous because it has been discussed.

I h= ave kept the following section. I'm not sure if you currently implement thi= s. I think it's important for the client to tolerate a secondary EXT_INFO j= ust before USERAUTH_SUCCESS, so that servers can advertise additional exten= sions after the client has been authenticated.


2.4.  Server= 's Secondary SSH_MSG_EXT_INFO

  If the client sent "ext-info-c"= , the server MAY send, but is not
  obligated to, send an SSH_MSG_E= XT_INFO message immediately before
  SSH_MSG_USERAUTH_SUCCESS, as d= efined in [RFC4252]. The server MAY send
  this message whether or = not it sent EXT_INFO after SSH_MSG_NEWKEYS.

  This allows a ser= ver to reveal support for additional extensions that
  it was unwil= ling to reveal to an unauthenticated client. If a server
  sends a = subsequent SSH_MSG_EXT_INFO, this replaces any previous ones,
  and= both the client and the server re-evaluate extensions in effect.
 = The server's last EXT_INFO is matched against the client's original.

I have also renamed "no-handbrake" to "no-flow-control".

What = do you think?



----- Original Message -----
From: Markus F= riedl
Sent: Thursday, December 3, 2015 03:32
To: denis bider
Cc:= Damien Miller ; ietf-ssh@netbsd.org
Subject: Re: Feedback on draft-ssh= -ext-info-00

Here is what I've implemented for OpenSSH:


3= .  Extension Negotiation Mechanism

3.1.  Signaling of Exte= nsion Negotiation in KEXINIT

  Applications implementing this m= echanism MUST add to the field
  "kex_algorithms", in their KEXINIT= packet sent for the first key
  exchange, one of the following ind= icator names:

  - When acting as server: "ext-info-s"
 = - When acting as client: "ext-info-c"

  The indicator name is = added without quotes, and MAY be added at any
  position in the nam= e-list, subject to proper separation from other
  names as per name= -list conventions.

  The names are added to the "kex_algorithms= " field because this is one
  of two name-list fields in KEXINIT th= at do not have a separate copy
  for each data direction.

&n= bsp; The indicator names inserted by the client and server are different to=
  ensure that these names will not produce a match, and will be ne= utral
  with respect to key exchange algorithm negotiation.

=   The inclusion of textual indicator names is intended to provide a cl= ue
  for implementers to discover this mechanism.

3.2. = Mechanism Enabling Criteria

  If a client or server offers "ex= t-info-c" or "ext-info-s"
  respectively, then it must be prepared = to accept a SSH_MSG_EXT_INFO
  message from the peer.

 = Thus a server only needs to send "ext-info-s" if it intends to
  p= rocess SSH_MSG_EXT_INFO from the client.

  If a server receives= an "ext-info-c", then it can send a
  SSH_MSG_EXT_INFO message, bu= t it's not required to do so.

  If a SSH_MSG_EXT_INFO message i= s sent, then it MUST be the first
  message after the initial SSH_M= SG_NEWKEYS.

  This way a server will send the SSH_MSG_EXT_INFO = before sending
  a possible SERVICE_ACCEPT message.

  I= mplementations MUST NOT send an incorrect indicator name for their
 = ; role. Implementations MAY disconnect if the counter-party does so.
&nb= sp; If an indicator name ("ext-info-c" or "ext-info-s") ends up being
&n= bsp; negotiated as a key exchange method, the parties MUST disconnect.
<= br>3.3.  Indicating Extensions

  A party that received the= "ext-info-c" or "ext-info-s" indicator
  can send the the followin= g message:

    byte     &nbs= p; SSH_MSG_EXT_INFO (value 7)
    uint32   = ;  nr-extensions
    repeat "nr-extensions" times:      string   extension-name
 = ;     string   extension-value

  = This message is sent without delay, and immediately after
  SSH_MSG= _NEWKEYS.

3.4.  Interpretation of Extension Names and Values
  Each extension is identified by its extension-name, and defines= the
  conditions under which the extension is considered to be in = effect.
  Applications MUST ignore unrecognized extension-names.
  Extension-value fields are interpreted as defined by their resp= ective
  extension. An extension-value field MAY be an empty string= if so
  permitted by the extension. Applications that do not imple= ment
  or recognize a particular extension MUST ignore the associat= ed
  extension-value field, regardless of its size or content.
<= br>  The cumulative size of an SSH_MSG_EXT_INFO message is limited onl= y by
  the maximum packet length that an implementation may apply i= n
  accordance with [RFC4253]. Implementations MUST accept well-for= med
  SSH_MSG_EXT_INFO messages up to the maximum packet length the= y accept.

4. Initially Defined Extensions

4.1. "server-sig-al= gs"

  This extension is sent with the following extension name = and value:

    string      "= server-sig-algs"
    name-list   signature-algo= rithms-accepted

  Note that the name-list type is a strict subs= et of the string type,
  and is thus permissible as an extension-va= lue.

  This extension is sent by the server only, and contains = a list of
  signature algorithms that the server is able to process= as part of a
  "publickey" authentication request.

  A= client that wishes to proceed with public key authentication MAY
 = wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey"
&nb= sp; authentication request with an appropriate signature algorithm, rather<= br>  than resorting to trial and error.

  Servers that imp= lement public key authentication SHOULD implement this
  extension.=

  If a server does not send this extension, a client SHALL NOT= make any
  assumptions about the server's signature algorithm supp= ort, and MAY
  proceed with authentication request trial and error.=

= --=-zu0PLbGyxRxe0A2M+GXB-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:09:50 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829411B2BA5 for ; Sat, 5 Dec 2015 10:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyLJf8EOb35k for ; Sat, 5 Dec 2015 10:09:48 -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 CBC0A1B2B87 for ; Sat, 5 Dec 2015 10:09:48 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 78FDB85F1C; Sat, 5 Dec 2015 18:09:21 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 2E70785F11; Sat, 5 Dec 2015 18:09:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 61F6985E9E for ; Thu, 3 Dec 2015 02:06: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 4OpZLYyiUT5J for ; Thu, 3 Dec 2015 02:06: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 E0D2A85E57 for ; Thu, 3 Dec 2015 02:06:29 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for pgut001@cs.auckland.ac.nz; Thu, 3 Dec 2015 02:06:28 +0000 Date: Thu, 3 Dec 2015 02:06:28 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1637842921-3540@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Peter Gutmann , Markus Friedl , Damien Miller Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-X/P5WkkAij4BdLizwm+L" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-X/P5WkkAij4BdLizwm+L Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Presence of "rsa-sha2-256" as a host key signature algorithm cannot reliabl= y serve as an indicator for user authentication, because it requires the se= rver to actually have an RSA host key. The server might only have an ECDSA host key; but may still accept and pref= er "rsa-sha2-256" signatures for client authentication. Or the server might have an ECDSA host key, and NOT accept "rsa-sha2-256" f= or client authentication, but instead require "rsa-sha2-512". ----- Original Message ----- From: Peter Gutmann=20 Sent: Wednesday, December 2, 2015 17:14 To: Markus Friedl ; ietf-ssh@netbsd.org=20 Cc: Damien Miller=20 Subject: RE: Feedback on draft-ssh-ext-info-00 Markus Friedl writes: >I'm in the process of implementing draft-rsa-dsa-sha2-256-03 and welcome a= =20 >way for signaling SHA2 support to the client for userauth, Doesn't the presence of "rsa-sha2-256" do this?=C2=A0 The client proposes i= t, and if the server supports it, they indicate via the algorithm string.=C2=A0 It= 's pretty much independent of draft-ssh-ext-info-00 (I know it specifies "server-sig-algs", but it seems that specifying "rsa-sha2-256" was already sufficient to indicate this). Peter. = --=-X/P5WkkAij4BdLizwm+L Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Presence of "rsa-sha2-256" as a host key signature= algorithm cannot reliably serve as an indicator for user authentication, b= ecause it requires the server to actually have an RSA host key.

The = server might only have an ECDSA host key; but may still accept and prefer "= rsa-sha2-256" signatures for client authentication.

Or the server mi= ght have an ECDSA host key, and NOT accept "rsa-sha2-256" for client authen= tication, but instead require "rsa-sha2-512".


----- Original Mes= sage -----
From: Peter Gutmann
Sent: Wednesday, December 2, 2015 17:= 14
To: Markus Friedl ; ietf-ssh@netbsd.org
Cc: Damien Miller
Sub= ject: RE: Feedback on draft-ssh-ext-info-00

Markus Friedl <mfried= l@gmail.com> writes:

>I'm in the process of implementing draft= -rsa-dsa-sha2-256-03 and welcome a
>way for signaling SHA2 support t= o the client for userauth,

Doesn't the presence of "rsa-sha2-256" do= this?  The client proposes it, and
if the server supports it, they= indicate via the algorithm string.  It's
pretty much independent o= f draft-ssh-ext-info-00 (I know it specifies
"server-sig-algs", but it s= eems that specifying "rsa-sha2-256" was already
sufficient to indicate t= his).

Peter.

= --=-X/P5WkkAij4BdLizwm+L-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:10:17 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AB81B2BA6 for ; Sat, 5 Dec 2015 10:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROhKtBeS5Ocu for ; Sat, 5 Dec 2015 10:10: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 E33381B2BA3 for ; Sat, 5 Dec 2015 10:10:15 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id EE0F285F0B; Sat, 5 Dec 2015 18:09:41 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 971FE85F0B; Sat, 5 Dec 2015 18:09:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0603985E8A for ; Thu, 3 Dec 2015 08:39: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 3OAVxJHhM4ro for ; Thu, 3 Dec 2015 08:39: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 8114585E47 for ; Thu, 3 Dec 2015 08:39:54 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Thu, 3 Dec 2015 08:39:48 +0000 Date: Thu, 3 Dec 2015 08:39:48 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1661294754-3540@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?= , Damien Miller Cc: Markus Friedl , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-tmtoQiJcf9vmwgw5PE56" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-tmtoQiJcf9vmwgw5PE56 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm not sure that we have a guarantee that the server must properly handle = this chaining. A well-written server should. But a server could also perform preprocessing= of SSH packets before sending responses, and it could notice that it has r= eceived USERAUTH_REQUEST before it has sent SERVICE_ACCEPT. The server coul= d then choke on this. One would imagine people would not do this, but I've dealt with an implemen= tation that discards KEXINIT if it's received in the same network frame as = the SSH version string. Niels M=C3=B6ller , 12/3/2015 8:32 AM: Damien Miller writes:=20 =20 >> But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. :)=20 >> =20 >> Does no one agree that SERVICE_REQUEST + ACCEPT are pointless?=20 >>=20 >> A whole round-trip delay? For no benefit - in any known usage=20 >> scenario?=20 =20 I think the entire point of the "awful" design, where you don't get a=20 second chance, just a disconnect in case the service isn't available, is=20 to eliminate that roundtrip delay.=20 =20 You can send a service request for "ssh-userauth", followed back-to-back=20 by userauth requests for "none", PK_OK, whatever querying you like. And=20 one roundtrip later, you can compute the needed signature for a=20 likely successful publickey userauth request.=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 = --=-tmtoQiJcf9vmwgw5PE56 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm not sure that we have a guarantee that the ser= ver must properly handle this chaining.

A well-written server should= . But a server could also perform preprocessing of SSH packets before sendi= ng responses, and it could notice that it has received USERAUTH_REQUEST bef= ore it has sent SERVICE_ACCEPT. The server could then choke on this.
One would imagine people would not do this, but I've dealt with an impleme= ntation that discards KEXINIT if it's received in the same network frame as= the SSH version string.


Niels M=C3=B6ller <nisse@lysator.liu.se> , 12/3/2015 8:32 AM:
=
Damien Miller <djm@mindrot.org>= ; writes:

>> But but but I waaaant to replace this awful SSH_MSG_SERVICE_RE= QUEST. :)
>>=20
>> Does no one agree that SERVICE_REQUEST + ACCEPT are pointless?
>>
>> A whole round-trip delay? For no benefit - in any known usage
>> scenario?

I think the entire point of the "awful" design, where you don't get a
second chance, just a disconnect in case the service isn't available, i= s
to eliminate that roundtrip delay.

You can send a service request for "ssh-userauth", followed back-to-bac= k
by userauth requests for "none", PK_OK, whatever querying you like. And
one roundtrip later, you can compute the needed signature for a
likely successful publickey userauth request.

Regards,
/Niels

--=20
Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
= --=-tmtoQiJcf9vmwgw5PE56-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:22:59 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1271B2BDA for ; Sat, 5 Dec 2015 10:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIXXt6ep12wK for ; Sat, 5 Dec 2015 10:22:58 -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 0EF191B2BD7 for ; Sat, 5 Dec 2015 10:22:58 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 818AD85F24; Sat, 5 Dec 2015 18:10:08 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 38D0F85F09; Sat, 5 Dec 2015 18:10:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 24E6B85E93 for ; Wed, 2 Dec 2015 09:01:46 +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 J0cVxC8BjPJ7 for ; Wed, 2 Dec 2015 09:01:45 +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 76F7684C73 for ; Wed, 2 Dec 2015 09:01:45 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh3@denisbider.com; Tue, 1 Dec 2015 10:33:08 +0000 Date: Tue, 1 Dec 2015 10:33:08 +0000 Subject: Re: SSH v3? X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1494800581-3144@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1493720992-1452@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: denis bider , Damien Miller , Simon Tatham , =?UTF-8?q?Niels_M=C3=B6ller?= , Simon Josefsson , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-+UECYaUkOdnRFNRw7qLO" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-+UECYaUkOdnRFNRw7qLO Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just going briefly through the EST spec, the way I left it last year, I not= ice several things I would prefer to change: - I am no longer as much adverse against IETF standardization, as long as s= omeone else beside me is willing to jump through the hoops. - I have a better variable-length integer encoding format now, which I woul= d prefer to use instead of the one presented. - It might be necessary to change EST_HASH to use the full 32 bytes of the = HMAC-SHA2-256 construction, instead of just the first 20 bytes. - In the private key format, I'd replace PBKDF2 with Argon2, recent winner = of the password hashing competition: =C2=A0 https://password-hashing.net/ - Folks here would probably want to standardize "eddsa" instead of ECDSA ov= er secp256k1. - Then again, folks who need to support FIPS would prefer ECDSA. Free high = quality implementations of secp256k1 are available: =C2=A0 https://github.com/bitcoin/secp256k1 There are probably other tweaks I would make. Currently, the spec is posted= as-is, the way I left it before I shelved it. Comments welcome, if you guys want to do this. denis bider , 12/1/2015 10:01 AM: Very much agreed. Here's my wish: SSHv3 is based on UDP, not TCP. I actually have a whole spec for that ready-made, which includes things lik= e negotiating encryption + authentication as one thing... Heck, if you guys want to work on that, here's the spec: https://www.bitvise.com/files/EfficientSecureTransport.pdf The initial defined algorithms are kinda arbitrary and trivial to substitut= e. I was going to put in Ed25519 and AES GCM, but I didn't have access to t= hat at the time, so I put in something I had access to. I actually have a platform-independent C++ implementation, too.... Complete= , just never tested. Do you guys want to work on this? ----- Original Message ----- From: Damien Miller=20 Sent: Sunday, November 29, 2015 05:48 To: Simon Tatham=20 Cc: Niels M=C3=B6ller ; Simon Josefsson ; ietf-ssh@netbsd.org=20 Subject: Re: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for= SSH) While we're dropping wishlist items for SSH v.3, here's one of mine: Key exchange negotiates an AEAD rather than a cipher and a MAC separately, and does so from a greatly trimmed set of options. E.g. AES-GCM, chacha20+poly1305 and an AES-CTR+HMAC mode. IMO the AEAD primitive is the right metaphor for the security properties of the SSH transport protocol. Removing the large cartesian product of ciphers x MACs will make testing faster and binaries smaller too. -d = --=-+UECYaUkOdnRFNRw7qLO Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just going briefly through the EST spec, the way I= left it last year, I notice several things I would prefer to change:
- I am no longer as much adverse against IETF standardization, as long as= someone else beside me is willing to jump through the hoops.

- I ha= ve a better variable-length integer encoding format now, which I would pref= er to use instead of the one presented.

- It might be necessary to c= hange EST_HASH to use the full 32 bytes of the HMAC-SHA2-256 construction, = instead of just the first 20 bytes.

- In the private key format, I'd= replace PBKDF2 with Argon2, recent winner of the password hashing competit= ion:
  https://password-hashing.net/

- Folks here would prob= ably want to standardize "eddsa" instead of ECDSA over secp256k1.

- = Then again, folks who need to support FIPS would prefer ECDSA. Free high qu= ality implementations of secp256k1 are available:
  https://github.= com/bitcoin/secp256k1

There are probably other tweaks I would make. = Currently, the spec is posted as-is, the way I left it before I shelved it.=

Comments welcome, if you guys want to do this.


denis bi= der <ietf-ssh3@denisbider.com> , 12/1/2015 10:01 AM:
Very much agre= ed.

Here's my wish:

SSHv3 is based on UDP, not TCP.

I = actually have a whole spec for that ready-made, which includes things like = negotiating encryption + authentication as one thing...

Heck, if you= guys want to work on that, here's the spec:

https://www.bit= vise.com/files/EfficientSecureTransport.pdf

The initial defined = algorithms are kinda arbitrary and trivial to substitute. I was going to pu= t in Ed25519 and AES GCM, but I didn't have access to that at the time, so = I put in something I had access to.

I actually have a platform-indep= endent C++ implementation, too.... Complete, just never tested.

Do y= ou guys want to work on this?


----- Original Message -----
Fr= om: Damien Miller
Sent: Sunday, November 29, 2015 05:48
To: Simon Ta= tham
Cc: Niels M=C3=B6ller ; Simon Josefsson ; ietf-s= sh@netbsd.org
Subject: Re: Binary packet protocol rethink (was: Re:= ChaCha20-Poly1305 for SSH)

While we're dropping wishlist items for = SSH v.3, here's one of mine:

Key exchange negotiates an AEAD rather = than a cipher and a MAC
separately, and does so from a greatly trimmed s= et of options. E.g.
AES-GCM, chacha20+poly1305 and an AES-CTR+HMAC mode.=

IMO the AEAD primitive is the right metaphor for the security prope= rties
of the SSH transport protocol. Removing the large cartesian produc= t of
ciphers x MACs will make testing faster and binaries smaller too.
-d

= --=-+UECYaUkOdnRFNRw7qLO-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:27:59 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B11B2BE2 for ; Sat, 5 Dec 2015 10:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.066 X-Spam-Level: X-Spam-Status: No, score=-0.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTo19y7OtM6X for ; Sat, 5 Dec 2015 10:27:58 -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 827131A9040 for ; Sat, 5 Dec 2015 10:27:58 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9DE9E85F2A; Sat, 5 Dec 2015 18:09:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 57A5185F1D; Sat, 5 Dec 2015 18:09:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2F07485E93 for ; Wed, 2 Dec 2015 09:02:38 +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 V-bfKfA0U3wc for ; Wed, 2 Dec 2015 09:02:37 +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 7EDF684C73 for ; Wed, 2 Dec 2015 09:02:37 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Tue, 1 Dec 2015 22:23:24 +0000 Date: Tue, 1 Dec 2015 22:23:24 +0000 Subject: Re: SSH v3? X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1537810400-3144@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , Damien Miller , Simon Tatham , Simon Josefsson , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-gIckIBz9CDLBXXtohlDU" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-gIckIBz9CDLBXXtohlDU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable TCP is not reliable: - On connections prone to random errors (wireless), large transfers are bou= nd for disconnects at a rate of 2^-16 per error. TCP just corrupts the data= in this case. SSH detects the corruption, but cannot recover from it. - A TCP connection can be reset by a single spoofed RST packet from anyone = who knows the IP address and port number of one of the end points. Further: - TCP prevents efficient tunneling of datagram flow over an SSH session: in= troduces unnecessary lag to maintain stream abstraction for applications th= at don't need it. TCP is neither reliable, nor secure. Its weaknesses break SSH sessions beyo= nd recovery. It's the single biggest weakness of SSH in practice. ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Tuesday, December 1, 2015 05:51 To: denis bider=20 Cc: Damien Miller ; Simon Tatham ; Simon Josefsson ; ietf-ssh@netbsd.org=20 Subject: Re: SSH v3? denis bider writes: > SSHv3 is based on UDP, not TCP. Why??? To me, a reliable byte stream as provided by tcp seems like a building block fitting ssh needs pretty well. If you want to do that, and support filetransfers or anything else with the potential to use significant bandwidth, and get it blessed by ietf, you'd have to implement your own congestion control. Not that I have anything against congestion control work in general. I have even given in to the temptation and designed my own, during my phd studies. See https://www.lysator.liu.se/~nisse/network-book/. But I don't think this is the right place for congestion control work. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-gIckIBz9CDLBXXtohlDU Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable TCP is not reliable:

- On connections prone= to random errors (wireless), large transfers are bound for disconnects at = a rate of 2^-16 per error. TCP just corrupts the data in this case. SSH det= ects the corruption, but cannot recover from it.
- A TCP connection can = be reset by a single spoofed RST packet from anyone who knows the IP addres= s and port number of one of the end points.

Further:

- TCP pr= events efficient tunneling of datagram flow over an SSH session: introduces= unnecessary lag to maintain stream abstraction for applications that don't= need it.

TCP is neither reliable, nor secure. Its weaknesses break = SSH sessions beyond recovery. It's the single biggest weakness of SSH in pr= actice.


----- Original Message -----
From: Niels "M=C3=B6ller= "
Sent: Tuesday, December 1, 2015 05:51
To: denis bider
Cc: Dami= en Miller ; Simon Tatham ; Simon Josefsson ; ietf-ssh@netbsd.org
Subjec= t: Re: SSH v3?

denis bider <ietf-ssh3@denisbider.com> writes:<= br>
> SSHv3 is based on UDP, not TCP.

Why??? To me, a reliable= byte stream as provided by tcp seems like a
building block fitting ssh = needs pretty well.

If you want to do that, and support filetransfers= or anything else with
the potential to use significant bandwidth, and g= et it blessed by ietf,
you'd have to implement your own congestion contr= ol.

Not that I have anything against congestion control work in gene= ral. I
have even given in to the temptation and designed my own, during = my phd
studies. See https://www.lysator.liu.se/~nisse/network-book/. But= I
don't think this is the right place for congestion control work.
<= br>Regards,
/Niels

--
Niels M=C3=B6ller. PGP-encrypted email = is preferred. Keyid C0B98E26.
Internet email is subject to wholesale gov= ernment surveillance.

= --=-gIckIBz9CDLBXXtohlDU-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:28:06 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DF51A9043 for ; Sat, 5 Dec 2015 10:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7VY6G2PRGaz for ; Sat, 5 Dec 2015 10:28: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 7D7F91B2BE2 for ; Sat, 5 Dec 2015 10:28:01 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9F47E85F2C; Sat, 5 Dec 2015 18:08:29 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 5958885F2A; Sat, 5 Dec 2015 18:08:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A5EE085EAF for ; Thu, 3 Dec 2015 00:33:45 +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 DO36YCmKS0zy for ; Thu, 3 Dec 2015 00:33:44 +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 D369085E94 for ; Thu, 3 Dec 2015 00:33:44 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Thu, 3 Dec 2015 00:33:41 +0000 Date: Thu, 3 Dec 2015 00:33:40 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1631879346-2660@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Damien Miller , Markus Friedl Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-CXvAclTg4tLos6b2YZZF" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-CXvAclTg4tLos6b2YZZF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > IMO it would be best to make it a MUST that the flags > may only be sent as the last element. What rationale is > there for putting it anywhere else? In the event that there are two or more competing extension mechanisms, onl= y one of them can be last. > and don't "replace" any messages like > SSH_MSG_SERVICE_REQUEST. But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. :) Does no one agree that SERVICE_REQUEST + ACCEPT are pointless? A whole round-trip delay? For no benefit - in any known usage scenario? > OpenSSH has sent various @openssh.com global > requests for years, so most of the implementations > that violate this should have long since been shaken out. Do you happen to know: - Since which version the OpenSSH server has been sending global requests? - Since which version the OpenSSH client has been tolerating them? There are still folks out there using OpenSSH 3.x and 4.x. I'm pretty sure = I saw our software being connected to by a client like that in the past wee= k. > (e.g. it's impossible to have one channel without the > "handbrake" and one with normal flow control) As discussed, this is on purpose. If you want multiplexing, implement multi= plexing, including flow control. If even one channel does not have flow control, this affects the transport = layer also. It affects keep-alive mechanisms, key exchange, and flow contro= l at the transport level. > Given this, IMO this would be better off being replaced by a > generic "these are the channel types I'm prepared to open" > message, which would be useful even for implementation > that don't want to turn off flow control but which do > implement non-standard channel types (e.g. tun@openssh.com). Sounds like an idea for another extension: Name: supported-channels Value: name-list of accepted channel types ? :-) denis ----- Original Message ----- From: Damien Miller=20 Sent: Wednesday, December 2, 2015 05:35 To: ietf-ssh@netbsd.org=20 Subject: Feedback on draft-ssh-ext-info-00 Hi, Here's some feedback on draft-ssh-ext-info-00. > 3.1.=C2=A0 Signaling of Extension Negotiation in KEXINIT ... > The indicator name is added without quotes, and MAY be added at any > position in the name-list, subject to proper separation from other > names as per name-list conventions. The suggested position is last in > the list, but implementations MUST recognize these indicator names > when included at any position. IMO it would be best to make it a MUST that the flags may only be sent as the last element. What rationale is there for putting it anywhere else? > 3.2.=C2=A0 Mechanism Enabling Criteria This whole section seems over-complicated. I think a simpler scheme is: If a client or server offers "ext-info-c" or "ext-info-s" respectively, then it must be prepared to accept a SSH_MSG_EXT_INFO message from the peer.=20 If this message is sent, then it will be the first message after the initial SSH_MSG_NEWKEYS. I.e. make it a simple advertisment that a client or server is willing to accept a notification message that might optionally be sent. Don't require both sides to offer acceptance, don't have the messages offer any sort of negotiation between the client and server (just statements of extensions/capabilities) and don't "replace" any messages like SSH_MSG_SERVICE_REQUEST. This would yield a much simpler specification IMO. > 4. Initially Defined Extensions > 4.2.=C2=A0 "client-req-ok" I don't see the point of this: implementations that don't respond with SSH_MSG_REQUEST_FAILURE to unknown SSH_MSG_GLOBAL_REQUEST messages are incompliant with RFC4254 section 4. OpenSSH has sent various @openssh.com global requests for years, so most of the implementations that violate this should have long since been shaken out. > 4.3.=C2=A0 "no-handbrake" This could be implemented more elegantly using new channel type names in SSH_MSG_CHANNEL_OPEN messages rather than the complicated and inflexible method proposed here (e.g. it's impossible to have one channel without the "handbrake" and one with normal flow control). It would be better to use the extension to signal that the peer is willing to accept SSH_MSG_CHANNEL_OPEN messages with new channel type names, and use these to selectively disable flow control. Given this, IMO this would be better off being replaced by a generic "these are the channel types I'm prepared to open" message, which would be useful even for implementation that don't want to turn off flow control but which do implement non-standard channel types (e.g. tun@openssh.com). -d = --=-CXvAclTg4tLos6b2YZZF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > IMO it would be best to make it a MUST that t= he flags
> may only be sent as the last element. What rationale is> there for putting it anywhere else?

In the event that there ar= e two or more competing extension mechanisms, only one of them can be last.=


> and don't "replace" any messages like
> SSH_MSG_SERV= ICE_REQUEST.

But but but I waaaant to replace this awful SSH_MSG_SER= VICE_REQUEST. :)

Does no one agree that SERVICE_REQUEST + ACCEPT are= pointless?

A whole round-trip delay? For no benefit - in any known = usage scenario?


> OpenSSH has sent various @openssh.com globa= l
> requests for years, so most of the implementations
> that v= iolate this should have long since been shaken out.

Do you happen to= know:

- Since which version the OpenSSH server has been sending glo= bal requests?

- Since which version the OpenSSH client has been tole= rating them?

There are still folks out there using OpenSSH 3.x and 4= .x. I'm pretty sure I saw our software being connected to by a client like = that in the past week.


> (e.g. it's impossible to have one ch= annel without the
> "handbrake" and one with normal flow control)
=
As discussed, this is on purpose. If you want multiplexing, implement m= ultiplexing, including flow control.

If even one channel does not ha= ve flow control, this affects the transport layer also. It affects keep-ali= ve mechanisms, key exchange, and flow control at the transport level.

> Given this, IMO this would be better off being replaced by a
= > generic "these are the channel types I'm prepared to open"
> mes= sage, which would be useful even for implementation
> that don't want= to turn off flow control but which do
> implement non-standard chann= el types (e.g. tun@openssh.com).

Sounds like an idea for another ext= ension:

Name: supported-channels
Value: name-list of accepted cha= nnel types

? :-)

denis


----- Original Message ----= -
From: Damien Miller
Sent: Wednesday, December 2, 2015 05:35
To:= ietf-ssh@netbsd.org
Subject: Feedback on draft-ssh-ext-info-00

= Hi,

Here's some feedback on draft-ssh-ext-info-00.

> 3.1.&= nbsp; Signaling of Extension Negotiation in KEXINIT
...
> The indi= cator name is added without quotes, and MAY be added at any
> positio= n in the name-list, subject to proper separation from other
> names a= s per name-list conventions. The suggested position is last in
> the = list, but implementations MUST recognize these indicator names
> when= included at any position.

IMO it would be best to make it a MUST th= at the flags may only be
sent as the last element. What rationale is the= re for putting it
anywhere else?

> 3.2.  Mechanism Enabli= ng Criteria

This whole section seems over-complicated. I think a sim= pler scheme
is:

If a client or server offers "ext-info-c" or "ext= -info-s" respectively,
then it must be prepared to accept a SSH_MSG_EXT_= INFO message from the
peer.

If this message is sent, then it wil= l be the first message after the
initial SSH_MSG_NEWKEYS.

I.e. ma= ke it a simple advertisment that a client or server is willing
to accept= a notification message that might optionally be sent.
Don't require bot= h sides to offer acceptance, don't have the messages
offer any sort of n= egotiation between the client and server (just
statements of extensions/= capabilities) and don't "replace" any
messages like SSH_MSG_SERVICE_REQU= EST.

This would yield a much simpler specification IMO.

> = 4. Initially Defined Extensions
> 4.2.  "client-req-ok"

I= don't see the point of this: implementations that don't respond with
SS= H_MSG_REQUEST_FAILURE to unknown SSH_MSG_GLOBAL_REQUEST messages are
inc= ompliant with RFC4254 section 4.

OpenSSH has sent various @openssh.c= om global requests for years,
so most of the implementations that violat= e this should have long since
been shaken out.

> 4.3.  "n= o-handbrake"

This could be implemented more elegantly using new chan= nel type names
in SSH_MSG_CHANNEL_OPEN messages rather than the complica= ted and
inflexible method proposed here (e.g. it's impossible to have on= e
channel without the "handbrake" and one with normal flow control).
=
It would be better to use the extension to signal that the
peer is w= illing to accept SSH_MSG_CHANNEL_OPEN messages with new channel
type nam= es, and use these to selectively disable flow control.

Given this, I= MO this would be better off being replaced by a generic
"these are the c= hannel types I'm prepared to open" message, which would
be useful even f= or implementation that don't want to turn off flow control
but which do = implement non-standard channel types (e.g. tun@openssh.com).

-d
<= br>= --=-CXvAclTg4tLos6b2YZZF-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:28:16 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F901B2BE2 for ; Sat, 5 Dec 2015 10:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOMrT4InG1yi for ; Sat, 5 Dec 2015 10:28: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 7DE551A9043 for ; Sat, 5 Dec 2015 10:28:11 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 89AA485F21; Sat, 5 Dec 2015 18:08:21 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id DA7CF85F21; Sat, 5 Dec 2015 18:08:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0ADC485EB6 for ; Thu, 3 Dec 2015 07:11:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id BN8tzw6ipiee for ; Thu, 3 Dec 2015 07:11:17 +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 B9F9785E9A for ; Thu, 3 Dec 2015 07:11:17 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Thu, 3 Dec 2015 07:11:14 +0000 Date: Thu, 3 Dec 2015 07:11:14 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1656295172-2152@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1655861333-3540@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: Damien Miller Cc: Markus Friedl , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-nK+tO7uUaXgk0aomtMFW" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-nK+tO7uUaXgk0aomtMFW Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > mainly so the server can send a second EXT_INFO just > before USERAUTH_REQUEST. This way you can > advertise extensions that alter user auth; but you can > also have privacy for extensions that only take effect after. Sorry, that should be: "just before USERAUTH_SUCCESS" denis bider , 12/3/2015 7:03 AM: If after considering this, you still really want the SERVICE_REQUEST + ACCE= PT round-trip, then okay. I can change the spec to not alter this part, if = this way we have something we can all agree on. But if we change it this way, when do you want EXT_INFO to be sent? What is= the window in which it should be accepted? The current proposal makes the window: - between NEWKEYS and SERVICE_REQUEST for the client, sent one time=20 - between NEWKEYS and USERAUTH_SUCCESS for the server, sent any number of t= imes (mainly so the server can send a second EXT_INFO just before USERAUTH_= REQUEST. This way you can advertise extensions that alter user auth; but yo= u can also have privacy for extensions that only take effect after. If we change EXT_INFO the way you propose, and keep SERVICE_REQUEST + ACCEP= T as-is - are you okay with these windows? denis bider , 12/3/2015 6:38 AM: > Why add fixed-function fields to a generic extension mechanism?=20 So as to avoid ret-conning functionality provided by SERVICE_REQUEST + ACCE= PT. These two messages always negotiate the service (e.g. "ssh-userauth"). So E= XT_INFO, which is a replacement, also always negotiates the service. This is in fact simpler than adding a "services" extension, and then mandat= ing that this extension "MUST" be handled by all implementations. If some f= unctionality must always be handled, a fixed field is appropriate. > Merely advertising a willingness to accept SSH_MSG_EXT_INFO > shouldn't have other further effects on the protocol. To do > otherwise is IMO quite surprising.=20 =20 Okay, imagine this: (1) Instead of the EXT_INFO message, we continue to send SERVICE_REQUEST + = ACCEPT. (2) The KEXINIT extension instead signals that extension fields can be adde= d to SERVICE_REQUEST + ACCEPT. (3) Presence of the KEXINIT extension further signals that the server can s= end a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUEST. Do you see that this results in the same proposal, just with renamed messag= es? Damien Miller , 12/3/2015 6:31 AM: On Thu, 3 Dec 2015, denis bider wrote:=20 =20 > I have posted a new draft to address this:=20 > =20 > https://tools.ietf.org/html/draft-ssh-ext-info-03=20 > =20 > The difference is that there is now a "services" field in EXT_INFO:=20 > =20 > =C2=A0 =C2=A0 byte =C2=A0 =C2=A0 =C2=A0 SSH_MSG_EXT_INFO (value 7)=20 > =C2=A0 =C2=A0 name-list =C2=A0services=20 > =C2=A0 =C2=A0 uint32 =C2=A0 =C2=A0 nr-extensions=20 > =C2=A0 =C2=A0 repeat "nr-extensions" times:=20 > =C2=A0 =C2=A0 =C2=A0 string =C2=A0 extension-name=20 > =C2=A0 =C2=A0 =C2=A0 string =C2=A0 extension-value=20 > =20 > And a section to describe it:=20 > =20 > 3.5. =C2=A0Service Negotiation=20 > =C2=A0 The client and server each include a name-list of supported servic= es=20 > =C2=A0 in EXT_INFO. The name-lists are matched to negotiate a service in = the=20 > =C2=A0 same way as name-lists are matched in KEXINIT. Clients and servers= =20 > =C2=A0 that support only "ssh-userauth" MUST send this service name only.= =20 > =C2=A0 Implementations supporting only one service MAY assume it will be=20 > =C2=A0 negotiated, and MAY send messages on that premise without waiting.= =20 > =20 > Would you agree this makes EXT_INFO a proper superset of SERVICE_REQUEST = +=20 > ACCEPT?=20 =20 This is over-complicated. Why add fixed-function fields to a generic=20 extension mechanism?=20 =20 I'd support a simple magic name, offered in KEXINIT to indicate that an=20 implementation is prepared to accept a SSH_MSG_EXT_INFO packet.=20 Merely advertising a willingness to accept SSH_MSG_EXT_INFO shouldn't=20 have other further effects on the protocol. To do otherwise is IMO quite=20 surprising.=20 =20 Then, if you want to define a "die-service-request-die" extension that=20 changes the protocol flow then you can do that without requiring other=20 implementations to follow suit.=20 =20 -d=20 =20 = --=-nK+tO7uUaXgk0aomtMFW Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > mainly so the server can send a second EXT_IN= FO just
> before USERAUTH_REQUEST. This way you can
> advertise= extensions that alter user=20 auth; but you can
> also have privacy for extensions that only take e= ffect after.

Sorry, that should be:

"just before USERAUTH_SUCCESS"=


denis bider <ietf-ssh3@denisb= ider.com> , 12/3/2015 7:03 AM:
If after considering this, you still really want the SERVICE_REQUEST = + ACCEPT round-trip, then okay. I can change the spec to not alter this par= t, if this way we have something we can all agree on.

But if we chan= ge it this way, when do you want EXT_INFO to be sent? What is the window in= which it should be accepted?

The current proposal makes the window:=

- between NEWKEYS and SERVICE_REQUEST for the client, sent one time=

- between NEWKEYS and USERAUTH_SUCCESS for the server, sent any nu= mber of times (mainly so the server can send a second EXT_INFO just before = USERAUTH_REQUEST. This way you can advertise extensions that alter user aut= h; but you can also have privacy for extensions that only take effect after= .

If we change EXT_INFO the way you propose, and keep SERVICE_REQUES= T + ACCEPT as-is - are you okay with these windows?


denis bider= <ietf-ssh= 3@denisbider.com> , 12/3/2015 6:38 AM:
> Why add fixed-function fields to a generic exten= sion mechanism?

So as to avoid ret-conning functionality provided by SERVICE_REQUES= T + ACCEPT.

These two messages always negotiate the service (e.g. "s= sh-userauth"). So EXT_INFO, which is a replacement, also always negotiates = the service.

This is in fact simpler than adding a "services" extens= ion, and then mandating that this extension "MUST" be handled by all implem= entations. If some functionality must always be handled, a fixed field is a= ppropriate.


> Merely advertising a willingness to accept SSH_= MSG_EXT_INFO
> shouldn't have other further effects on the protocol. = To do
> otherwise is IMO quite surprising.

Okay, imagine this:

(1) Instead of the EXT_INFO message, we cont= inue to send SERVICE_REQUEST + ACCEPT.

(2) The KEXINIT extension ins= tead signals that extension fields can be added to SERVICE_REQUEST + ACCEPT= .

(3) Presence of the KEXINIT extension further signals that the ser= ver can send a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUEST= .

Do you see that this results in the same proposal, just with renam= ed messages?



Damien Miller= <djm@mindrot.org> , 12/3/2015= 6:31 AM:
On Thu, 3 Dec 2015, denis bid= er wrote:

> I have posted a new draft to address this:
>=20
> h= ttps://tools.ietf.org/html/draft-ssh-ext-info-03
>=20
> The difference is that there is now a "services" field in EXT_INFO= :
>=20
>     byte       SSH_MSG_EXT_INFO (value 7)
>     name-list  services
>     uint32     nr-extensions
>     repeat "nr-extensions" times:
>       string   extension-name
>       string   extension-value
>=20
> And a section to describe it:
>=20
> 3.5.  Service Negotiation
>   The client and server each include a name-list of supported= services
>   in EXT_INFO. The name-lists are matched to negotiate a serv= ice in the
>   same way as name-lists are matched in KEXINIT. Clients and = servers
>   that support only "ssh-userauth" MUST send this service nam= e only.
>   Implementations supporting only one service MAY assume it w= ill be
>   negotiated, and MAY send messages on that premise without w= aiting.
>=20
> Would you agree this makes EXT_INFO a proper superset of SERVICE_R= EQUEST +
> ACCEPT?

This is over-complicated. Why add fixed-function fields to a generic
extension mechanism?

I'd support a simple magic name, offered in KEXINIT to indicate that an
implementation is prepared to accept a SSH_MSG_EXT_INFO packet.
Merely advertising a willingness to accept SSH_MSG_EXT_INFO shouldn't
have other further effects on the protocol. To do otherwise is IMO quit= e
surprising.

Then, if you want to define a "die-service-request-die" extension that
changes the protocol flow then you can do that without requiring other
implementations to follow suit.

-d

= --=-nK+tO7uUaXgk0aomtMFW-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:28:19 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C0A1A9043 for ; Sat, 5 Dec 2015 10:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-kY5EAJMs6j for ; Sat, 5 Dec 2015 10:28: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 539CA1B2BE6 for ; Sat, 5 Dec 2015 10:28:16 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8D4E385F15; Sat, 5 Dec 2015 18:08:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 1C5D885F1B; Sat, 5 Dec 2015 18:07:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2BDC485EB0 for ; Thu, 3 Dec 2015 03:53:59 +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 kR4NkaTqlhOv for ; Thu, 3 Dec 2015 03:53:58 +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 453B385E54 for ; Thu, 3 Dec 2015 03:53:58 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for ietf-ssh3@denisbider.com; Thu, 3 Dec 2015 03:53:54 +0000 Date: Thu, 3 Dec 2015 03:53:54 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1644184986-3540@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1642890958-3540@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: denis bider , Damien Miller , Markus Friedl Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-y0WJ0pIZ95jg3V9W/Tfr" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-y0WJ0pIZ95jg3V9W/Tfr Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Another possible way to use the key exchange algorithms field for an extens= ion in parallel with EXT_INFO might be to change the way SSH host key algor= ithms are negotiated, for example. The current negotiation rules have serio= us drawbacks, not least that the client has no way of learning the SSH serv= er's other host keys if it already trusts one. To solve this, I could suggest an extension that enhances all key exchange = methods in the following way. Instead of sending: string public-key The server sends: string: =C2=A0 string negotiated-public-key =C2=A0 uint32 nr-other-public-keys =C2=A0 string other-public-keys[] =C2=A0 uint32 nr-revoked-public-keys =C2=A0 string revoked-public-key-fingerprints[] This extension would allow the SSH Server to gracefully rollover to a new h= ost key algorithm, or to increase key size, which it currently cannot witho= ut completely screwing up all its trust relationships with its clients. This extension could be negotiated in the key exchange algorithms field, ju= st like EXT_INFO; and could exist simultaneously and independently of EXT_I= NFO. denis bider , 12/3/2015 3:27 AM: > If there's a functioning extension mechanism, > then why would there be competition? To extend other aspects of SSH that EXT_INFO cannot. This could be to chang= e some aspect of algorithm negotiation, for example. For instance, there has been a problem in how AEAD is negotiated. Besides w= hat OpenSSH did - implementing a private algorithm for AES-GCM - another po= ssible solution could be an extension where both client and server put some= thing in their key exchange algorithms field. If both client and server do = this, then the result of MAC negotiation is ignored if an AEAD encryption a= lgorithm is negotiated. But why do you even feel the need to call this out? Is it any harder to cal= l: =C2=A0=C2=A0=C2=A0 is_in_namelist(name, namelist) instead of: =C2=A0=C2=A0=C2=A0 is_at_end_of_namelist(name, namelist) ? You are saying, "I can't envision a usage scenario for this, so let's prev= ent it." This is pompous, because you implicitly consider yourself capable = of predicting such scenarios. Further, you are doing this for zero benefit;= as a matter of principle; and just after we've been through conversations = where I've pointed out that we cannot predict future needs, and that this = attitude - "prohibit it because we can" - has already created problems. > IIRC I've heard of at least one server that doesn't > implement ssh-userauth. This is possible with EXT_INFO also. Send an extension name and value infor= ming the client of what you implement. No need to waste a round-trip for 99= .999% of other users. > I'm not sure what the gain is either compared to making > the SSH window match the TCP window size. It's not like > SSH can go send more data than that. Just simplicity, for implementations that want it. A user mode app doesn't necessarily have info about what goes on at the TCP= level, and if it does, it's something a single-channel implementation does= n't want to have to bother with. denis ----- Original Message ----- From: Damien Miller=20 Sent: Wednesday, December 2, 2015 21:10 To: denis bider=20 Cc: Markus Friedl ; ietf-ssh@netbsd.org=20 Subject: Re: Feedback on draft-ssh-ext-info-00 On Thu, 3 Dec 2015, denis bider wrote: > > IMO it would be best to make it a MUST that the flags > > may only be sent as the last element. What rationale is > > there for putting it anywhere else? >=20 > In the event that there are two or more competing extension mechanisms, o= nly > one of them can be last. If there's a functioning extension mechanism, then why would there be competition? Even if there were, then it's up to whoever writes the second one to deal with making their fit. > > and don't "replace" any messages like > > SSH_MSG_SERVICE_REQUEST. >=20 > But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. :) >=20 > Does no one agree that SERVICE_REQUEST + ACCEPT are pointless? >=20 > A whole round-trip delay? For no benefit - in any known usage scenario? IMO replacing messages in the protocol is something best saved for SSH-3.x. IIRC I've heard of at least one server that doesn't implement ssh-userauth. > > OpenSSH has sent various @openssh.com global > > requests for years, so most of the implementations > > that violate this should have long since been shaken out. >=20 > Do you happen to know: >=20 > - Since which version the OpenSSH server has been sending global requests= ? 3.8ish, released early 2004 > - Since which version the OpenSSH client has been tolerating them? at least that long :) > There are still folks out there using OpenSSH 3.x and 4.x. I'm pretty sur= e I > saw our software being connected to by a client like that in the past wee= k. 4.x should be fine, older 3.x might have problems - I haven't checked. Honestly though, anyone using OpenSSH 3.x has bigger problems than channel requests upsetting their connections. > > (e.g. it's impossible to have one channel without the > > "handbrake" and one with normal flow control) >=20 > As discussed, this is on purpose. If you want multiplexing, implement > multiplexing, including flow control. >=20 > If even one channel does not have flow control, this affects the transpor= t > layer also. It affects keep-alive mechanisms, key exchange, and flow cont= rol > at the transport level. Right, "no-handbrake" breaks all of these. I'm not sure what the gain is either compared to making the SSH window match the TCP window size. It's not like SSH can go send more data than that. -d = --=-y0WJ0pIZ95jg3V9W/Tfr Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Another possible way to use the key exchange algor= ithms field for an extension in parallel with EXT_INFO might be to change t= he way SSH host key algorithms are negotiated, for example. The current neg= otiation rules have serious drawbacks, not least that the client has no way= of learning the SSH server's other host keys if it already trusts one.
=
To solve this, I could suggest an extension that enhances all key excha= nge methods in the following way. Instead of sending:

string public-= key

The server sends:

string:
  string negotiated-pub= lic-key
  uint32 nr-other-public-keys
  string other-public= -keys[]
  uint32 nr-revoked-public-keys
  string revoked-pu= blic-key-fingerprints[]

This extension would allow the SSH Server to= gracefully rollover to a new host key algorithm, or to increase key size, = which it currently cannot without completely screwing up all its trust rela= tionships with its clients.

This extension could be negotiated in th= e key exchange algorithms field, just like EXT_INFO; and could exist simult= aneously and independently of EXT_INFO.


denis bider <ietf-ssh3@denisbider.com> , 12/3/20= 15 3:27 AM:
> If there's a functioning = extension mechanism,
> then why would there be competition?

To= extend other aspects of SSH that EXT_INFO cannot. This could be to change = some aspect of algorithm negotiation, for example.

For instance, the= re has been a problem in how AEAD is negotiated. Besides what OpenSSH did -= implementing a private algorithm for AES-GCM - another possible solution c= ould be an extension where both client and server put something in their ke= y exchange algorithms field. If both client and server do this, then the re= sult of MAC negotiation is ignored if an AEAD encryption algorithm is negot= iated.

But why do you even feel the need to call this out? Is it any= harder to call:

    is_in_namelist(name, namelist)
instead of:

    is_at_end_of_namelist(name, nam= elist)

?

You are saying, "I can't envision a usage scenario for this, so let's prevent it." This is pompous, because yo= u implicitly consider yourself capable of predicting such scenarios.= Further, you are doing this for zero benefit; as a matter of princi= ple; and just after we've been through conversations where=20 I've pointed out that we cannot predict future needs, and that this = attitude - "prohibit it because we can" - has already created problems.
=

> IIRC I've heard of at least one server that doesn't
> im= plement ssh-userauth.

This is possible with EXT_INFO also. Send an e= xtension name and value informing the client of what you implement. No need= to waste a round-trip for 99.999% of other users.


> I'm not = sure what the gain is either compared to making
> the SSH window matc= h the TCP window size. It's not like
> SSH can go send more data than= that.

Just simplicity, for implementations that want it.

A u= ser mode app doesn't necessarily have info about what goes on at the TCP le= vel, and if it does, it's something a single-channel implementation doesn't= want to have to bother with.

denis


----- Original Messag= e -----
From: Damien Miller
Sent: Wednesday, December 2, 2015 21:10<= br>To: denis bider
Cc: Markus Friedl ; ietf-ssh@netbs= d.org
Subject: Re: Feedback on draft-ssh-ext-info-00

On Thu,= 3 Dec 2015, denis bider wrote:

> > IMO it would be best to ma= ke it a MUST that the flags
> > may only be sent as the last eleme= nt. What rationale is
> > there for putting it anywhere else?
&= gt;
> In the event that there are two or more competing extension me= chanisms, only
> one of them can be last.

If there's a functio= ning extension mechanism, then why would there be
competition?

Ev= en if there were, then it's up to whoever writes the second one to
deal = with making their fit.

> > and don't "replace" any messages li= ke
> > SSH_MSG_SERVICE_REQUEST.
>
> But but but I waa= aant to replace this awful SSH_MSG_SERVICE_REQUEST. :)
>
> Doe= s no one agree that SERVICE_REQUEST + ACCEPT are pointless?
>
>= ; A whole round-trip delay? For no benefit - in any known usage scenario?
IMO replacing messages in the protocol is something best saved forSSH-3.x. IIRC I've heard of at least one server that doesn't implement
= ssh-userauth.

> > OpenSSH has sent various @openssh.com global=
> > requests for years, so most of the implementations
> &g= t; that violate this should have long since been shaken out.
>
&g= t; Do you happen to know:
>
> - Since which version the OpenSS= H server has been sending global requests?

3.8ish, released early 20= 04

> - Since which version the OpenSSH client has been tolerating= them?

at least that long :)

> There are still folks out t= here using OpenSSH 3.x and 4.x. I'm pretty sure I
> saw our software = being connected to by a client like that in the past week.

4.x shoul= d be fine, older 3.x might have problems - I haven't checked.

Honest= ly though, anyone using OpenSSH 3.x has bigger problems than
channel req= uests upsetting their connections.

> > (e.g. it's impossible t= o have one channel without the
> > "handbrake" and one with normal= flow control)
>
> As discussed, this is on purpose. If you wa= nt multiplexing, implement
> multiplexing, including flow control.>
> If even one channel does not have flow control, this affects= the transport
> layer also. It affects keep-alive mechanisms, key ex= change, and flow control
> at the transport level.

Right, "no-= handbrake" breaks all of these. I'm not sure what the gain is
either com= pared to making the SSH window match the TCP window size. It's
not like = SSH can go send more data than that.

-d

= --=-y0WJ0pIZ95jg3V9W/Tfr-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:48:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2FF1B2C43 for ; Sat, 5 Dec 2015 10:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywzZ4iwYblJN for ; Sat, 5 Dec 2015 10:48: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 1D44C1B2C3F for ; Sat, 5 Dec 2015 10:48:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 68B4B85F1F; Sat, 5 Dec 2015 18:17:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D314385F22; Sat, 5 Dec 2015 18:10:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D71F585EB6 for ; Thu, 3 Dec 2015 06:46: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 8M4qgGsue2v6 for ; Thu, 3 Dec 2015 06:46:25 +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 36EEB85E57 for ; Thu, 3 Dec 2015 06:46:25 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Thu, 3 Dec 2015 06:46:20 +0000 Date: Thu, 3 Dec 2015 06:46:20 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1654355845-3540@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: MIME-Version: 1.0 From: denis bider To: Damien Miller Cc: Markus Friedl , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-4wS1jWbnRrqXxzFUZZk3" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-4wS1jWbnRrqXxzFUZZk3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Why add fixed-function fields to a generic extension mechanism?=20 So as to avoid ret-conning functionality provided by SERVICE_REQUEST + ACCE= PT. These two messages always negotiate the service (e.g. "ssh-userauth"). So E= XT_INFO, which is a replacement, also always negotiates the service. This is in fact simpler than adding a "services" extension, and then mandat= ing that this extension "MUST" be handled by all implementations. If some f= unctionality must always be handled, a fixed field is appropriate. > Merely advertising a willingness to accept SSH_MSG_EXT_INFO > shouldn't have other further effects on the protocol. To do > otherwise is IMO quite surprising.=20 =20 Okay, imagine this: (1) Instead of the EXT_INFO message, we continue to send SERVICE_REQUEST + = ACCEPT. (2) The KEXINIT extension instead signals that extension fields can be adde= d to SERVICE_REQUEST + ACCEPT. (3) Presence of the KEXINIT extension further signals that the server can s= end a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUEST. Do you see that this results in the same proposal, just with renamed messag= es? Damien Miller , 12/3/2015 6:31 AM: On Thu, 3 Dec 2015, denis bider wrote:=20 =20 > I have posted a new draft to address this:=20 > =20 > https://tools.ietf.org/html/draft-ssh-ext-info-03=20 > =20 > The difference is that there is now a "services" field in EXT_INFO:=20 > =20 > =C2=A0 =C2=A0 byte =C2=A0 =C2=A0 =C2=A0 SSH_MSG_EXT_INFO (value 7)=20 > =C2=A0 =C2=A0 name-list =C2=A0services=20 > =C2=A0 =C2=A0 uint32 =C2=A0 =C2=A0 nr-extensions=20 > =C2=A0 =C2=A0 repeat "nr-extensions" times:=20 > =C2=A0 =C2=A0 =C2=A0 string =C2=A0 extension-name=20 > =C2=A0 =C2=A0 =C2=A0 string =C2=A0 extension-value=20 > =20 > And a section to describe it:=20 > =20 > 3.5. =C2=A0Service Negotiation=20 > =C2=A0 The client and server each include a name-list of supported servic= es=20 > =C2=A0 in EXT_INFO. The name-lists are matched to negotiate a service in = the=20 > =C2=A0 same way as name-lists are matched in KEXINIT. Clients and servers= =20 > =C2=A0 that support only "ssh-userauth" MUST send this service name only.= =20 > =C2=A0 Implementations supporting only one service MAY assume it will be=20 > =C2=A0 negotiated, and MAY send messages on that premise without waiting.= =20 > =20 > Would you agree this makes EXT_INFO a proper superset of SERVICE_REQUEST = +=20 > ACCEPT?=20 =20 This is over-complicated. Why add fixed-function fields to a generic=20 extension mechanism?=20 =20 I'd support a simple magic name, offered in KEXINIT to indicate that an=20 implementation is prepared to accept a SSH_MSG_EXT_INFO packet.=20 Merely advertising a willingness to accept SSH_MSG_EXT_INFO shouldn't=20 have other further effects on the protocol. To do otherwise is IMO quite=20 surprising.=20 =20 Then, if you want to define a "die-service-request-die" extension that=20 changes the protocol flow then you can do that without requiring other=20 implementations to follow suit.=20 =20 -d=20 =20 = --=-4wS1jWbnRrqXxzFUZZk3 Content-Type: text/html; charset="utf-8" > Why add fixed-function fields to a generic extension mechanism?

So as to avoid ret-conning functionality provided by SERVICE_REQUEST + ACCEPT.

These two messages always negotiate the service (e.g. "ssh-userauth"). So EXT_INFO, which is a replacement, also always negotiates the service.

This is in fact simpler than adding a "services" extension, and then mandating that this extension "MUST" be handled by all implementations. If some functionality must always be handled, a fixed field is appropriate.


> Merely advertising a willingness to accept SSH_MSG_EXT_INFO
> shouldn't have other further effects on the protocol. To do
> otherwise is IMO quite surprising.

Okay, imagine this:

(1) Instead of the EXT_INFO message, we continue to send SERVICE_REQUEST + ACCEPT.

(2) The KEXINIT extension instead signals that extension fields can be added to SERVICE_REQUEST + ACCEPT.

(3) Presence of the KEXINIT extension further signals that the server can send a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUEST.

Do you see that this results in the same proposal, just with renamed messages?



Damien Miller <djm@mindrot.org> , 12/3/2015 6:31 AM:
On Thu, 3 Dec 2015, denis bider wrote:

> I have posted a new draft to address this:
>
> https://tools.ietf.org/html/draft-ssh-ext-info-03
>
> The difference is that there is now a "services" field in EXT_INFO:
>
>     byte       SSH_MSG_EXT_INFO (value 7)
>     name-list  services
>     uint32     nr-extensions
>     repeat "nr-extensions" times:
>       string   extension-name
>       string   extension-value
>
> And a section to describe it:
>
> 3.5.  Service Negotiation
>   The client and server each include a name-list of supported services
>   in EXT_INFO. The name-lists are matched to negotiate a service in the
>   same way as name-lists are matched in KEXINIT. Clients and servers
>   that support only "ssh-userauth" MUST send this service name only.
>   Implementations supporting only one service MAY assume it will be
>   negotiated, and MAY send messages on that premise without waiting.
>
> Would you agree this makes EXT_INFO a proper superset of SERVICE_REQUEST +
> ACCEPT?

This is over-complicated. Why add fixed-function fields to a generic
extension mechanism?

I'd support a simple magic name, offered in KEXINIT to indicate that an
implementation is prepared to accept a SSH_MSG_EXT_INFO packet.
Merely advertising a willingness to accept SSH_MSG_EXT_INFO shouldn't
have other further effects on the protocol. To do otherwise is IMO quite
surprising.

Then, if you want to define a "die-service-request-die" extension that
changes the protocol flow then you can do that without requiring other
implementations to follow suit.

-d

--=-4wS1jWbnRrqXxzFUZZk3-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:53:30 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5057B1B2C5E for ; Sat, 5 Dec 2015 10:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnpP-_oP-rPc for ; Sat, 5 Dec 2015 10:53: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 466381B2C5A for ; Sat, 5 Dec 2015 10:53:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id DCDA785F2D; Sat, 5 Dec 2015 18:08:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 8C08085F2A; Sat, 5 Dec 2015 18:08:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 61DC285E94 for ; Thu, 3 Dec 2015 00:46: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=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 ZCr0RYf4a_Ch for ; Thu, 3 Dec 2015 00:46:13 +0000 (UTC) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 A4A0885E66 for ; Thu, 3 Dec 2015 00:46:12 +0000 (UTC) Received: by wmec201 with SMTP id c201so4110233wme.0 for ; Wed, 02 Dec 2015 16:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=0Amf/4y0WgyqQ4vyNRwcNUvH8urge9P8v7KdCr4GwDM=; b=w8XxnHc/89SraJbDPierESE+JrmBXYSz/qq0pbddarHgGpGAJz1yOelOYklX/A3lpu cOut111Ju2IVG43/8DB665Wq2ercMXVXkiKFxh/d9ODQL0F4wFDZZXEPBiAkl3BaDSKS blfUVGN6tVlilm7OXJDVTPdVYCj47HJwY54qf+bwPghgmZ/xdV8iK0a24mSeBBrLybUO SdzNXbR8syzwuAAb3knHk4mz2cXEQYKF+6n8qmcbR7RzzcUtE7xk7RDVtzy1lEXHWsrx HAWhTCOJlA7NIQYdUiNZs01Qv7fP7Q8oNuxgZPTT4vNZjtx0ghp9jNNBKqOcbUyD7QQX D8CQ== X-Received: by 10.28.182.134 with SMTP id g128mr49185395wmf.95.1449103571147; Wed, 02 Dec 2015 16:46:11 -0800 (PST) Received: from surfer-172-29-5-241-hotspot.internet-for-guests.com (p578b8de4.dip0.t-ipconnect.de. [87.139.141.228]) by smtp.gmail.com with ESMTPSA id wh10sm5042940wjb.45.2015.12.02.16.46.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 16:46:10 -0800 (PST) Subject: Re: Feedback on draft-ssh-ext-info-00 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_72E0E5F2-6B54-4453-875C-953E19FDF3EF" From: Markus Friedl X-Priority: 3 In-Reply-To: <1631450999-4056@skroderider.denisbider.com> Date: Thu, 3 Dec 2015 01:46:08 +0100 Cc: Damien Miller , ietf-ssh@netbsd.org Message-Id: <16AF71A1-8021-4531-8ECA-5471DFD1CF7D@gmail.com> References: <1631450999-4056@skroderider.denisbider.com> To: denis bider X-Mailer: Apple Mail (2.3096.5) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_72E0E5F2-6B54-4453-875C-953E19FDF3EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 03.12.2015 um 01:21 schrieb denis bider : >=20 >=20 > Sounds good. Can you post a writeup of the scheme you implement? >=20 > It doesn't have to be an Internet-Draft, just something better than = reverse engineering source code. >=20 I've implemented it exactly as Damien has specified it in his mail. -m= --Apple-Mail=_72E0E5F2-6B54-4453-875C-953E19FDF3EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Am 03.12.2015 um 01:21 schrieb denis bider <ietf-ssh3@denisbider.com>:


Sounds good. Can you post = a writeup of the scheme you implement?

It doesn't have to be an Internet-Draft, just = something better than reverse engineering source code.



I've implemented it exactly as Damien = has specified it in his mail.

-m
= --Apple-Mail=_72E0E5F2-6B54-4453-875C-953E19FDF3EF-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:53:30 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC091B2C5A for ; Sat, 5 Dec 2015 10:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.391 X-Spam-Level: * X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8dn92peohUJ for ; Sat, 5 Dec 2015 10:53: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 49BB81B2C5B for ; Sat, 5 Dec 2015 10:53:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 365DA85F35; Sat, 5 Dec 2015 18:17:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 3168585F09; Sat, 5 Dec 2015 18:10:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B2F9385E9E for ; Thu, 3 Dec 2015 02:46:18 +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 xvrvInWIXx_E for ; Thu, 3 Dec 2015 02:46: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 016D085E57 for ; Thu, 3 Dec 2015 02:46:17 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for brynosaurus@gmail.com; Thu, 3 Dec 2015 02:46:10 +0000 Date: Thu, 3 Dec 2015 02:46:10 +0000 Subject: Re: SSH v3? X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1639608151-3144@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Bryan Ford , =?UTF-8?q?Niels_M=C3=B6ller?= Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-BM5DHVtLMC+Di+c3vv1K" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-BM5DHVtLMC+Di+c3vv1K Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Bryan - thank you for sharing this, I was not previously aware of Minion. The main issue I see is that Minion does in fact seem to require modificati= on at the OS level. Even though the changes needed might be small, this won= 't fly unless Linux and Windows both decide to support it. Most SSH implementations I'm aware of are user-mode implementations, by org= anizations and/or volunteers who are not familiar with, and do not have acc= ess to modify, the TCP stack on systems where their SSH implementation runs= . This is certainly true for me, I can't change the TCP implementation in W= indows. Without underlying platform support, it seems to me the best that SSH can d= o is to either (1) implement support for UDP as an ancillary transport for = latency-sensitive traffic, or to (2) migrate wholesale to UDP. My "EST" suggestion rebuilds the whole protocol on top of UDP. But perhaps,= implementing support for UDP as an ancillary transport would be a more com= patible fit with current SSH usage. And also, as you point out in your pape= r, it would be a better fit for connections where UDP is not available due = to firewall/routing issues. If you can get Windows + Linux to implement uTCP though, that would have th= e benefit of avoiding even the firewall/routing issues still faced by UDP. denis ----- Original Message ----- From: Bryan Ford=20 Sent: Wednesday, December 2, 2015 03:39 To: Niels M=C3=B6ller=20 Cc: denis bider ; ietf-ssh@netbsd.org=20 Subject: Re: SSH v3? On 02 Dec 2015, at 09:34, Niels M?ller wrote: > denis bider writes: >> - TCP prevents efficient tunneling of datagram flow over an SSH >> session: introduces unnecessary lag to maintain stream abstraction for >> applications that don't need it. >=20 > It's definitely possible to tunnel udp over tcp (with or without ssh > being involved). Whether or not that's good enough depends on the > application. What are the usecases for udp-tunneling over ssh? You also > have dtls, which might solve your problem in a better way than ssh (I'm > sorry I don't know the details of that protocol). TCP?s enforced in-order delivery on protocols like SSH and TLS that are som= etimes used to forward datagrams can indeed create latency problems - and e= specially ?freezes?=C2=9D in audio/video protocols like Skype that easily t= olerate a single dropped frame but freak out when a whole RTT worth of fram= es gets delayed.=20 For that reason I?ve been hoping for a while now that some of these protoco= ls would adopt something like our Minion approach, which allows TCP-based p= rotocols to deliver tunneled datagrams out-of-order: Fitting Square Pegs Through Round Pipes: Unordered Delivery Wire-Compatible= with TCP and TLS http://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs I suspect it wouldn?t be that difficult to evolve OpenSSH protocol to be co= mpatible with Minion and hence able to forward tunneled UDP datagrams out-o= f-order.=C2=A0 I?d be happy to hear if there?s any interest.=C2=A0 I think = it would be easy to incorporate Minion support in OpenSSH in a way that wou= ld make things no more complicated for implementations that don?t support i= t, only a little more complicated for implementations that want to, and ens= ure that all implementations still interoperate perfectly regardless of whi= ch endpoints do and don?t support the out-of-order delivery extension. Cheers B = --=-BM5DHVtLMC+Di+c3vv1K Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Bryan -

thank you for sharing this, I w= as not previously aware of Minion.

The main issue I see is that Mini= on does in fact seem to require modification at the OS level. Even t= hough the changes needed might be small, this won't fly unless Linux and Wi= ndows both decide to support it.

Most SSH implementations I'm aware = of are user-mode implementations, by organizations and/or volunteers who ar= e not familiar with, and do not have access to modify, the TCP stack on sys= tems where their SSH implementation runs. This is certainly true for me, I = can't change the TCP implementation in Windows.

Without underlying p= latform support, it seems to me the best that SSH can do is to either (1) i= mplement support for UDP as an ancillary transport for latency-sensitive tr= affic, or to (2) migrate wholesale to UDP.

My "EST" suggestion rebui= lds the whole protocol on top of UDP. But perhaps, implementing support for= UDP as an ancillary transport would be a more compatible fit with current = SSH usage. And also, as you point out in your paper, it would be a better f= it for connections where UDP is not available due to firewall/routing issue= s.

If you can get Windows + Linux to implement uTCP though, that wou= ld have the benefit of avoiding even the firewall/routing issues still face= d by UDP.

denis


----- Original Message -----
From: Bry= an Ford
Sent: Wednesday, December 2, 2015 03:39
To: Niels M=C3=B6lle= r
Cc: denis bider ; ietf-ssh@netbsd.org
Subject: Re: SSH v3?
On 02 Dec 2015, at 09:34, Niels M?ller <nisse@lysator.liu.se> wrote:=
> denis bider <ietf-ssh3@denisbider.com> writes:
>> -= TCP prevents efficient tunneling of datagram flow over an SSH
>> = session: introduces unnecessary lag to maintain stream abstraction for
&= gt;> applications that don't need it.
>
> It's definitely p= ossible to tunnel udp over tcp (with or without ssh
> being involved)= . Whether or not that's good enough depends on the
> application. Wha= t are the usecases for udp-tunneling over ssh? You also
> have dtls, = which might solve your problem in a better way than ssh (I'm
> sorry = I don't know the details of that protocol).

TCP?s enforced in-order = delivery on protocols like SSH and TLS that are sometimes used to forward d= atagrams can indeed create latency problems - and especially ?freezes?=C2= =9D in audio/video protocols like Skype that easily tolerate a single dropp= ed frame but freak out when a whole RTT worth of frames gets delayed.
<= br>For that reason I?ve been hoping for a while now that some of these prot= ocols would adopt something like our Minion approach, which allows TCP-base= d protocols to deliver tunneled datagrams out-of-order:

Fitting Squa= re Pegs Through Round Pipes: Unordered Delivery Wire-Compatible with TCP an= d TLS
http://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs

I suspe= ct it wouldn?t be that difficult to evolve OpenSSH protocol to be compatibl= e with Minion and hence able to forward tunneled UDP datagrams out-of-order= .  I?d be happy to hear if there?s any interest.  I think it woul= d be easy to incorporate Minion support in OpenSSH in a way that would make= things no more complicated for implementations that don?t support it, only= a little more complicated for implementations that want to, and ensure tha= t all implementations still interoperate perfectly regardless of which endp= oints do and don?t support the out-of-order delivery extension.

Chee= rs
B

= --=-BM5DHVtLMC+Di+c3vv1K-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:53:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601F61B2C5B for ; Sat, 5 Dec 2015 10:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36obUYewrKVp for ; Sat, 5 Dec 2015 10:53: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 6D2631B2C5C for ; Sat, 5 Dec 2015 10:53:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8BA9785F2E; Sat, 5 Dec 2015 18:09:50 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 4299F85F1D; Sat, 5 Dec 2015 18:09:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 84D6B85E8A for ; Thu, 3 Dec 2015 08:32: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 EoRuVMbkv90N for ; Thu, 3 Dec 2015 08:32:33 +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 EC7BC85E47 for ; Thu, 3 Dec 2015 08:32:32 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Thu, 3 Dec 2015 08:31:56 +0000 Date: Thu, 3 Dec 2015 08:31:56 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1660946654-3540@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?= , Damien Miller Cc: Peter Gutmann , Markus Friedl , "ietf-ssh@netbsd.org" Content-Type: multipart/alternative; boundary="=-9RDsc7VEoU10WhYTAI/P" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-9RDsc7VEoU10WhYTAI/P Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable My implementation agrees with Niels's analysis. Even without signature, the= signature algorithm name ("rsa-sha2-256") is sent in USERAUTH_REQUEST as "= public key algorithm name", followed by public key blob encoding an "ssh-rs= a" public key. No signature is needed to find out whether the server will accept "rsa-sha2= -256". If you don't mind making multiple attempts - first "rsa-sha2-256", t= hen "rsa-sha2-512", then "ssh-rsa" - then no extensions are needed to disco= ver which signature algorithms will be accepted; and an actual signature is= needed only with the one that will be accepted. My concern with extensions is removing the trial and error, so that public = key authentication with Australia doesn't take 1.5 seconds. Niels M=C3=B6ller , 12/3/2015 8:23 AM: Damien Miller writes:=20 =20 > The problem is that, for a client to test whether rsa-sha2-256 is support= ed,=20 > it must make publickey userauth with an included signature. A=20 > signature free PK_OK style request won't do since the key blob just=20 > contains ssh-rsa and not the signature algorithm.=20 =20 Hmm. This sounds like a serious breakage, and if that's the case, we=20 really ought to use a new algorithm name also in the key blob.=20 =20 But is it really so? Looking at RFC 5252, we have=20 =20 =C2=A0 =C2=A0 =C2=A0byte =C2=A0 =C2=A0 =C2=A0SSH_MSG_USERAUTH_REQUEST=20 =C2=A0 =C2=A0 =C2=A0string =C2=A0 =C2=A0user name in ISO-10646 UTF-8 encod= ing [RFC3629]=20 =C2=A0 =C2=A0 =C2=A0string =C2=A0 =C2=A0service name in US-ASCII=20 =C2=A0 =C2=A0 =C2=A0string =C2=A0 =C2=A0"publickey"=20 =C2=A0 =C2=A0 =C2=A0boolean =C2=A0 FALSE=20 =C2=A0 =C2=A0 =C2=A0string =C2=A0 =C2=A0public key algorithm name=20 =C2=A0 =C2=A0 =C2=A0string =C2=A0 =C2=A0public key blob=20 =20 and=20 =20 =C2=A0 =C2=A0 =C2=A0byte =C2=A0 =C2=A0 =C2=A0SSH_MSG_USERAUTH_PK_OK=20 =C2=A0 =C2=A0 =C2=A0string =C2=A0 =C2=A0public key algorithm name from the= request=20 =C2=A0 =C2=A0 =C2=A0string =C2=A0 =C2=A0public key blob from the request=20 =20 I'd expect the "public key algorithm name" to be "ssh-rsa-sha2-256", and=20 then it's fine if the string inside the keyblob is "ssh-rsa". There's no=20 ambiguity as to what type of signature is intended.=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 = --=-9RDsc7VEoU10WhYTAI/P Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable My implementation agrees with Niels's analysis. Ev= en without signature, the signature algorithm name ("rsa-sha2-256") is sent= in USERAUTH_REQUEST as "public key algorithm name", followed by public key= blob encoding an "ssh-rsa" public key.

No signature is needed to fi= nd out whether the server will accept "rsa-sha2-256". If you don't mind mak= ing multiple attempts - first "rsa-sha2-256", then "rsa-sha2-512", then "ss= h-rsa" - then no extensions are needed to discover which signature algorith= ms will be accepted; and an actual signature is needed only with the one th= at will be accepted.

My concern with extensions is removing the tria= l and error, so that public key authentication with Australia doesn't take = 1.5 seconds.


Niels M=C3=B6ller <= nisse@lysator.liu.se> , 12/3/2015 8:23 AM:
Damien Miller <djm@mindrot.org> writes:

> The problem is that, for a client to test whether rsa-sha2-256 is = supported,
> it must make publickey userauth with an included signature. A
> signature free PK_OK style request won't do since the key blob jus= t
> contains ssh-rsa and not the signature algorithm.

Hmm. This sounds like a serious breakage, and if that's the case, we
really ought to use a new algorithm name also in the key blob.

But is it really so? Looking at RFC 5252, we have

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name in ISO-10646 UTF-8 e= ncoding [RFC3629]
     string    service name in US-ASCII
     string    "publickey"
     boolean   FALSE
     string    public key algorithm name
     string    public key blob

and

     byte      SSH_MSG_USERAUTH_PK_OK
     string    public key algorithm name from= the request
     string    public key blob from the reque= st

I'd expect the "public key algorithm name" to be "ssh-rsa-sha2-256", an= d
then it's fine if the string inside the keyblob is "ssh-rsa". There's n= o
ambiguity as to what type of signature is intended.

Regards,
/Niels

--=20
Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
= --=-9RDsc7VEoU10WhYTAI/P-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:53:35 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63AB1B2C5B for ; Sat, 5 Dec 2015 10:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBJvHr5GLKLx for ; Sat, 5 Dec 2015 10:53: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 71CF41B2C5D for ; Sat, 5 Dec 2015 10:53:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6591485F11; Sat, 5 Dec 2015 18:10:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 209FE85F09; Sat, 5 Dec 2015 18:10:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B476585EB6 for ; Thu, 3 Dec 2015 05:16: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 wCjoPmQ79hq5 for ; Thu, 3 Dec 2015 05:16: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 EFE7985E54 for ; Thu, 3 Dec 2015 05:16:13 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Thu, 3 Dec 2015 05:16:09 +0000 Date: Thu, 3 Dec 2015 05:16:09 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1647427311-3540@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1645695388-2152@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: Damien Miller Cc: Markus Friedl , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-VafB72+Ko25NnqXvA86p" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-VafB72+Ko25NnqXvA86p Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJJ2xsIHJlcGVhdCBteSBvcGluaW9uOiBhbiBleHRlbnNpb24gbWVjaGFuaXNtIGlzIG5vdA0K PiB0aGUgcGxhY2UgdG8gZnVuZGFtZW50YWxseSByZXRjb24gcGFydHMgb2YgdGhlIHByb3RvY29s Lg0KDQpJdCdzIG5vdCBpbnRlbmRlZCBhcyBhIHJldGNvbi4gSXQncyBhIG5lZ290aWF0ZWQgcmVw bGFjZW1lbnQgb2YgYW4gZXhpc3RpbmcgKGluZmxleGlibGUsIGluZWZmaWNpZW50LCBhbG1vc3Qg cG9pbnRsZXNzKSBtZWNoYW5pc20gd2l0aCBhIG5ldyAoZmxleGlibGUsIGVmZmljaWVudCwgd29y dGh3aGlsZSkgbWVjaGFuaXNtLg0KDQpDb21wYXJlIHRoaXMgdG8gU01UUCBIRUxPIHJlcGxhY2Vk IGJ5IEVITE8uIFRoaXMgZGlkIG5vdCByZXF1aXJlIGJ1bXBpbmcgdGhlIFNNVFAgcHJvdG9jb2wg dmVyc2lvbi4NCg0KVGhlIGNoYW5nZSBpcyBvbmx5IGEgcmV0Y29uIGlmIGl0IHJlbW92ZXMgZnVu Y3Rpb25hbGl0eSB0aGF0IFNFUlZJQ0VfUkVRVUVTVCArIEFDQ0VQVCBoYXZlLiBTbyBiYXNpY2Fs bHksIHlvdSdyZSBzYXlpbmcgdGhhdCB3aGlsZSB0aGUgbmVnb3RpYXRpb24gcHJvdmlkZWQgYnkg U0VSVklDRV9SRVFVRVNUIGlzIHBvaW50bGVzcyBpbiB0aGUgdmFzdCBtYWpvcml0eSBvZiBjYXNl cywgaXQgaXMgYmVpbmcgcmVsaWVkIHVwb24gYnkgYSBzbWFsbCBwZXJjZW50YWdlIG9mIGltcGxl bWVudGF0aW9ucywgYW5kIHRoaXMgc2hvdWxkIGJlIHJlc3BlY3RlZC4NCg0KSWYgdGhhdCdzIHdo YXQgeW91J3JlIHNheWluZywgeW91IGhhdmUgYSBwb2ludC4gSW4gb3JkZXIgdG8gYmUgYSBwcm9w ZXIgcmVwbGFjZW1lbnQsIGFuZCBub3QgYSByZXRjb24sIGl0IGhhcyB0byBwcmVzZXJ2ZSBleGlz dGluZyBmdW5jdGlvbmFsaXR5Lg0KDQpJIGhhdmUgcG9zdGVkIGEgbmV3IGRyYWZ0IHRvIGFkZHJl c3MgdGhpczoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNzaC1leHQtaW5m by0wMw0KDQpUaGUgZGlmZmVyZW5jZSBpcyB0aGF0IHRoZXJlIGlzIG5vdyBhICJzZXJ2aWNlcyIg ZmllbGQgaW4gRVhUX0lORk86DQoNCiAgICBieXRlICAgICAgIFNTSF9NU0dfRVhUX0lORk8gKHZh bHVlIDcpCiAgICBuYW1lLWxpc3QgIHNlcnZpY2VzCiAgICB1aW50MzIgICAgIG5yLWV4dGVuc2lv bnMKICAgIHJlcGVhdCAibnItZXh0ZW5zaW9ucyIgdGltZXM6CiAgICAgIHN0cmluZyAgIGV4dGVu c2lvbi1uYW1lCiAgICAgIHN0cmluZyAgIGV4dGVuc2lvbi12YWx1ZQ0KQW5kIGEgc2VjdGlvbiB0 byBkZXNjcmliZSBpdDoNCg0KMy41LiAgU2VydmljZSBOZWdvdGlhdGlvbiAgVGhlIGNsaWVudCBh bmQgc2VydmVyIGVhY2ggaW5jbHVkZSBhIG5hbWUtbGlzdCBvZiBzdXBwb3J0ZWQgc2VydmljZXMK ICBpbiBFWFRfSU5GTy4gVGhlIG5hbWUtbGlzdHMgYXJlIG1hdGNoZWQgdG8gbmVnb3RpYXRlIGEg c2VydmljZSBpbiB0aGUKICBzYW1lIHdheSBhcyBuYW1lLWxpc3RzIGFyZSBtYXRjaGVkIGluIEtF WElOSVQuIENsaWVudHMgYW5kIHNlcnZlcnMKICB0aGF0IHN1cHBvcnQgb25seSAic3NoLXVzZXJh dXRoIiBNVVNUIHNlbmQgdGhpcyBzZXJ2aWNlIG5hbWUgb25seS4KICBJbXBsZW1lbnRhdGlvbnMg c3VwcG9ydGluZyBvbmx5IG9uZSBzZXJ2aWNlIE1BWSBhc3N1bWUgaXQgd2lsbCBiZQogIG5lZ290 aWF0ZWQsIGFuZCBNQVkgc2VuZCBtZXNzYWdlcyBvbiB0aGF0IHByZW1pc2Ugd2l0aG91dCB3YWl0 aW5nLg0KV291bGQgeW91IGFncmVlIHRoaXMgbWFrZXMgRVhUX0lORk8gYSBwcm9wZXIgc3VwZXJz ZXQgb2YgU0VSVklDRV9SRVFVRVNUICsgQUNDRVBUPw0KDQoNCmRlbmlzIGJpZGVyIDxpZXRmLXNz aDNAZGVuaXNiaWRlci5jb20+ICwgMTIvMy8yMDE1IDQ6MTQgQU06DQo+IEknbSBzdWdnZXN0aW5n IHlvdSBzcGVjaWZ5IHdoYXQgaXMgc2VudCwgbm90IGhvdw0KPiBpbXBsZW1lbnRhdGlvbnMgdGVz dCBmb3IgaXQuIA0KDQpJdCBpcyBpbXBvcnRhbnQgdG8gc3BlY2lmeSB3aGF0IHRvIHRlc3QgZm9y LiBKdXN0IHdlZWtzIGFnbywgd2UgaGFkIGEgY29udmVyc2F0aW9uIGFib3V0IGhvdyBSRkMgNDI1 MyBzaG91bGQgaGF2ZSBzcGVsbGVkIG91dCB0aGF0IHRoZSAicmVzZXJ2ZWQiIGZpZWxkIG11c3Qg YmUgc2VudCBhcyB6ZXJvLCBidXQgbXVzdCBub3QgYmUgY2hlY2tlZCB0aGF0IGl0IGlzIHplcm8u DQoNCkl0IGlzIGltcG9ydGFudCB0byBzcGVjaWZ5IHdoYXQgdGhpbmdzIGltcGxlbWVudGF0aW9u cyBzaG91bGQgbm90IGNoZWNrIGZvciwgd2hlbiBpbmNvcnJlY3QgaW1wbGVtZW50YXRpb24gbWF5 IGNhdXNlIGNvbXBhdGliaWxpdHkgaXNzdWVzLg0KDQoNCj4gVGhlIGJlbmVmaXQgaXMgdGhhdCB+ IGEgcGFyYWdyYXBoIG9mIGZhaXJseQ0KPiB1c2VsZXNzIHZlcmJpYWdlIGluIHlvdXIgc3BlYyBk aXNhcHBlYXJzLiANCiANCllvdSBhcmUgbG9zaW5nIG15IHJlc3BlY3QgYXMgd2UgY29udGludWUu DQoNCg0KRGFtaWVuIE1pbGxlciA8ZGptQG1pbmRyb3Qub3JnPiAsIDEyLzMvMjAxNSA0OjA2IEFN Og0KT24gVGh1LCAzIERlYyAyMDE1LCBkZW5pcyBiaWRlciB3cm90ZTogDQogDQo+ID4gSWYgdGhl cmUncyBhIGZ1bmN0aW9uaW5nIGV4dGVuc2lvbiBtZWNoYW5pc20sIA0KPiA+IHRoZW4gd2h5IHdv dWxkIHRoZXJlIGJlIGNvbXBldGl0aW9uPyANCj4gIA0KPiBUbyBleHRlbmQgb3RoZXIgYXNwZWN0 cyBvZiBTU0ggdGhhdCBFWFRfSU5GTyBjYW5ub3QuIFRoaXMgY291bGQgYmUgdG8gY2hhbmdlIA0K PiBzb21lIGFzcGVjdCBvZiBhbGdvcml0aG0gbmVnb3RpYXRpb24sIGZvciBleGFtcGxlLiANCj4g IA0KPiBGb3IgaW5zdGFuY2UsIHRoZXJlIGhhcyBiZWVuIGEgcHJvYmxlbSBpbiBob3cgQUVBRCBp cyBuZWdvdGlhdGVkLiBCZXNpZGVzIA0KPiB3aGF0IE9wZW5TU0ggZGlkIC0gaW1wbGVtZW50aW5n IGEgcHJpdmF0ZSBhbGdvcml0aG0gZm9yIEFFUy1HQ00gLSBhbm90aGVyIA0KPiBwb3NzaWJsZSBz b2x1dGlvbiBjb3VsZCBiZSBhbiBleHRlbnNpb24gd2hlcmUgYm90aCBjbGllbnQgYW5kIHNlcnZl ciBwdXQgDQo+IHNvbWV0aGluZyBpbiB0aGVpciBrZXkgZXhjaGFuZ2UgYWxnb3JpdGhtcyBmaWVs ZC4gSWYgYm90aCBjbGllbnQgYW5kIHNlcnZlciANCj4gZG8gdGhpcywgdGhlbiB0aGUgcmVzdWx0 IG9mIE1BQyBuZWdvdGlhdGlvbiBpcyBpZ25vcmVkIGlmIGFuIEFFQUQgZW5jcnlwdGlvbiANCj4g YWxnb3JpdGhtIGlzIG5lZ290aWF0ZWQuIA0KPiAgDQo+IEJ1dCB3aHkgZG8geW91IGV2ZW4gZmVl bCB0aGUgbmVlZCB0byBjYWxsIHRoaXMgb3V0PyBJcyBpdCBhbnkgaGFyZGVyIHRvIA0KPiBjYWxs OiANCj4gIA0KPiDCoMKgwqAgaXNfaW5fbmFtZWxpc3QobmFtZSwgbmFtZWxpc3QpIA0KPiAgDQo+ IGluc3RlYWQgb2Y6IA0KPiAgDQo+IMKgwqDCoCBpc19hdF9lbmRfb2ZfbmFtZWxpc3QobmFtZSwg bmFtZWxpc3QpIA0KIA0KSSdtIHN1Z2dlc3RpbmcgeW91IHNwZWNpZnkgd2hhdCBpcyBzZW50LCBu b3QgaG93IGltcGxlbWVudGF0aW9ucyB0ZXN0IA0KZm9yIGl0LiBUaGUgYmVuZWZpdCBpcyB0aGF0 IH4gYSBwYXJhZ3JhcGggb2YgZmFpcmx5IHVzZWxlc3MgdmVyYmlhZ2UgDQppbiB5b3VyIHNwZWMg ZGlzYXBwZWFycy4gDQogDQo+ID4gSUlSQyBJJ3ZlIGhlYXJkIG9mIGF0IGxlYXN0IG9uZSBzZXJ2 ZXIgdGhhdCBkb2Vzbid0IA0KPiA+IGltcGxlbWVudCBzc2gtdXNlcmF1dGguIA0KPiAgDQo+IFRo aXMgaXMgcG9zc2libGUgd2l0aCBFWFRfSU5GTyBhbHNvLiBTZW5kIGFuIGV4dGVuc2lvbiBuYW1l IGFuZCB2YWx1ZSANCj4gaW5mb3JtaW5nIHRoZSBjbGllbnQgb2Ygd2hhdCB5b3UgaW1wbGVtZW50 LiBObyBuZWVkIHRvIHdhc3RlIGEgcm91bmQtdHJpcCANCj4gZm9yIDk5Ljk5OSUgb2Ygb3RoZXIg dXNlcnMuIA0KIA0KSSdsbCByZXBlYXQgbXkgb3BpbmlvbjogYW4gZXh0ZW5zaW9uIG1lY2hhbmlz bSBpcyBub3QgdGhlIHBsYWNlIHRvIA0KZnVuZGFtZW50YWxseSByZXRjb24gcGFydHMgb2YgdGhl IHByb3RvY29sLiBJdCBicmVha3Mgb3J0aGFnb25hbGl0eSANCmFuZCB0dXJucyBpbXBsZW1lbnRh dGlvbnMgaW50byBzcGFnaGV0dGkuIA0KIA0KUGVyaGFwcyB5b3Ugd2FudCBhICJuby1zZXJ2aWNl LXJlcXVlc3RzIiBleHRlbnNpb24gaW5zdGVhZD8gDQogDQotZA== --=-VafB72+Ko25NnqXvA86p Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I'll repeat my opinion: an extension mechanis= m is not
> the place to fundamentally retcon parts of the protocol.
It's not intended as a retcon. It's a negotiated replacement of an ex= isting (inflexible, inefficient, almost pointless) mechanism with a new (fl= exible, efficient, worthwhile) mechanism.

Compare this to SMTP HELO = replaced by EHLO. This did not require bumping the SMTP protocol version.
The change is only a retcon if it removes functionality that SERVICE_= REQUEST + ACCEPT have. So basically, you're saying that while the negotiati= on provided by SERVICE_REQUEST is pointless in the vast majority of cases, = it is being relied upon by a small percentage of implementations, and this = should be respected.

If that's what you're saying, you have a point.= In order to be a proper replacement, and not a retcon, it has to preserve = existing functionality.

I have posted a new draft to address this:
https://tools.ietf.org/html/draft-ssh-ext-info-03

The differen= ce is that there is now a "services" field in EXT_INFO:

    byte       SSH_MSG_EXT_INFO (value 7)
    name-list  services
    uint32     nr-extensions
    repeat "nr-extensions" times:
      string   extension-name
      string   extension-value

And a section to describe it:
3.5.  Service Negotiation
  The client and serv=
er each include a name-list of supported services
  in EXT_INFO. The name-lists are matched to negotiate a service in the
  same way as name-lists are matched in KEXINIT. Clients and servers
  that support only "ssh-userauth" MUST send this service name only.
  Implementations supporting only one service MAY assume it will be
  negotiated, and MAY send messages on that premise without waiting.
<= br>Would you agree this makes EXT_INFO a proper superset of SERVICE_REQUEST= + ACCEPT?


denis bider <ietf-s= sh3@denisbider.com> , 12/3/2015 4:14 AM:
> I'm suggesting you specify what is sent, not how
&g= t; implementations test for it.

It is important to specify what to = test for. Just weeks ago, we had a conversation about how RFC 4253 should h= ave spelled out that the "reserved" field must be sent as zero, but = must not be checked that it is zero.

It is important to speci= fy what things implementations should not check for, when incorrect = implementation may cause compatibility issues.


> The benefit = is that ~ a paragraph of fairly
> useless verbiage in your spec disap= pears.

You are losing my respect as we continue.


Damien Miller <djm@mindrot.org>= , 12/3/2015 4:06 AM:
On Thu, 3 Dec 2015, d= enis bider wrote:

> > If there's a functioning extension mechanism,
> > then why would there be competition?
>=20
> To extend other aspects of SSH that EXT_INFO cannot. This could be= to change
> some aspect of algorithm negotiation, for example.
>=20
> For instance, there has been a problem in how AEAD is negotiated. = Besides
> what OpenSSH did - implementing a private algorithm for AES-GCM - = another
> possible solution could be an extension where both client and serv= er put
> something in their key exchange algorithms field. If both client a= nd server
> do this, then the result of MAC negotiation is ignored if an AEAD = encryption
> algorithm is negotiated.
>=20
> But why do you even feel the need to call this out? Is it any hard= er to
> call:
>=20
>     is_in_namelist(name, namelist)
>=20
> instead of:
>=20
>     is_at_end_of_namelist(name, namelist)

I'm suggesting you specify what is sent, not how implementations test
for it. The benefit is that ~ a paragraph of fairly useless verbiage
in your spec disappears.

> > IIRC I've heard of at least one server that doesn't
> > implement ssh-userauth.
>=20
> This is possible with EXT_INFO also. Send an extension name and va= lue
> informing the client of what you implement. No need to waste a rou= nd-trip
> for 99.999% of other users.

I'll repeat my opinion: an extension mechanism is not the place to
fundamentally retcon parts of the protocol. It breaks orthagonality
and turns implementations into spaghetti.

Perhaps you want a "no-service-requests" extension instead?

-d
= --=-VafB72+Ko25NnqXvA86p-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:58:30 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E013E1B2C72 for ; Sat, 5 Dec 2015 10:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAltV4ByduMx for ; Sat, 5 Dec 2015 10:58: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 BA04B1B2C6D for ; Sat, 5 Dec 2015 10:58:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 790AF85F18; Sat, 5 Dec 2015 18:09:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D0F8485F02; Sat, 5 Dec 2015 18:09:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 770CE85E93 for ; Wed, 2 Dec 2015 09:03: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 1JzDdmnVraBZ for ; Wed, 2 Dec 2015 09:03: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 EBC5884C73 for ; Wed, 2 Dec 2015 09:03:45 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Tue, 1 Dec 2015 10:10:03 +0000 Date: Tue, 1 Dec 2015 10:10:03 +0000 Subject: SSH v3? X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1493720992-1452@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Damien Miller , Simon Tatham , =?UTF-8?q?Niels_M=C3=B6ller?= , Simon Josefsson , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-0h2+0S5b6q59C546vq5H" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-0h2+0S5b6q59C546vq5H Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Very much agreed. Here's my wish: SSHv3 is based on UDP, not TCP. I actually have a whole spec for that ready-made, which includes things lik= e negotiating encryption + authentication as one thing... Heck, if you guys want to work on that, here's the spec: https://www.bitvise.com/files/EfficientSecureTransport.pdf The initial defined algorithms are kinda arbitrary and trivial to substitut= e. I was going to put in Ed25519 and AES GCM, but I didn't have access to t= hat at the time, so I put in something I had access to. I actually have a platform-independent C++ implementation, too.... Complete= , just never tested. Do you guys want to work on this? ----- Original Message ----- From: Damien Miller=20 Sent: Sunday, November 29, 2015 05:48 To: Simon Tatham=20 Cc: Niels M=C3=B6ller ; Simon Josefsson ; ietf-ssh@netbsd.org=20 Subject: Re: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for= SSH) While we're dropping wishlist items for SSH v.3, here's one of mine: Key exchange negotiates an AEAD rather than a cipher and a MAC separately, and does so from a greatly trimmed set of options. E.g. AES-GCM, chacha20+poly1305 and an AES-CTR+HMAC mode. IMO the AEAD primitive is the right metaphor for the security properties of the SSH transport protocol. Removing the large cartesian product of ciphers x MACs will make testing faster and binaries smaller too. -d = --=-0h2+0S5b6q59C546vq5H Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Very much agreed.

Here's my wish:

SS= Hv3 is based on UDP, not TCP.

I actually have a whole spec for that = ready-made, which includes things like negotiating encryption + authenticat= ion as one thing...

Heck, if you guys want to work on that, here's t= he spec:

https://www.bitvise.com/files/EfficientSecureTransport.pdf<= br>
The initial defined algorithms are kinda arbitrary and trivial to su= bstitute. I was going to put in Ed25519 and AES GCM, but I didn't have acce= ss to that at the time, so I put in something I had access to.

I act= ually have a platform-independent C++ implementation, too.... Complete, jus= t never tested.

Do you guys want to work on this?


----- O= riginal Message -----
From: Damien Miller
Sent: Sunday, November 29,= 2015 05:48
To: Simon Tatham
Cc: Niels M=C3=B6ller ; Simon Josefsson= ; ietf-ssh@netbsd.org
Subject: Re: Binary packet protocol rethink (was= : Re: ChaCha20-Poly1305 for SSH)

While we're dropping wishlist items= for SSH v.3, here's one of mine:

Key exchange negotiates an AEAD ra= ther than a cipher and a MAC
separately, and does so from a greatly trim= med set of options. E.g.
AES-GCM, chacha20+poly1305 and an AES-CTR+HMAC = mode.

IMO the AEAD primitive is the right metaphor for the security = properties
of the SSH transport protocol. Removing the large cartesian p= roduct of
ciphers x MACs will make testing faster and binaries smaller t= oo.

-d

= --=-0h2+0S5b6q59C546vq5H-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:58:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570DA1B2C6D for ; Sat, 5 Dec 2015 10:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIPu_fLctTHR for ; Sat, 5 Dec 2015 10:58: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 D48551B2C6F for ; Sat, 5 Dec 2015 10:58:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 404A585F14; Sat, 5 Dec 2015 18:08:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id A900785F19; Sat, 5 Dec 2015 18:07:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 319FF85EB8 for ; Thu, 3 Dec 2015 04:16:54 +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 uCSl8mwHLOvf for ; Thu, 3 Dec 2015 04:16:53 +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 9A63585E93 for ; Thu, 3 Dec 2015 04:16:53 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Thu, 3 Dec 2015 04:16:49 +0000 Date: Thu, 3 Dec 2015 04:16:49 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1645695388-2152@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: MIME-Version: 1.0 From: denis bider To: Damien Miller Cc: Markus Friedl , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-Izc3JtNdO0fLCVyW8pif" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-Izc3JtNdO0fLCVyW8pif Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I'm suggesting you specify what is sent, not how > implementations test for it.=20 It is important to specify what to test for. Just weeks ago, we had a conve= rsation about how RFC 4253 should have spelled out that the "reserved" fiel= d must be sent as zero, but must not be checked that it is zero. It is important to specify what things implementations should not check for= , when incorrect implementation may cause compatibility issues. > The benefit is that ~ a paragraph of fairly > useless verbiage in your spec disappears.=20 =20 You are losing my respect as we continue. Damien Miller , 12/3/2015 4:06 AM: On Thu, 3 Dec 2015, denis bider wrote:=20 =20 > > If there's a functioning extension mechanism,=20 > > then why would there be competition?=20 > =20 > To extend other aspects of SSH that EXT_INFO cannot. This could be to cha= nge=20 > some aspect of algorithm negotiation, for example.=20 > =20 > For instance, there has been a problem in how AEAD is negotiated. Besides= =20 > what OpenSSH did - implementing a private algorithm for AES-GCM - another= =20 > possible solution could be an extension where both client and server put=20 > something in their key exchange algorithms field. If both client and serv= er=20 > do this, then the result of MAC negotiation is ignored if an AEAD encrypt= ion=20 > algorithm is negotiated.=20 > =20 > But why do you even feel the need to call this out? Is it any harder to=20 > call:=20 > =20 > =C2=A0=C2=A0=C2=A0 is_in_namelist(name, namelist)=20 > =20 > instead of:=20 > =20 > =C2=A0=C2=A0=C2=A0 is_at_end_of_namelist(name, namelist)=20 =20 I'm suggesting you specify what is sent, not how implementations test=20 for it. The benefit is that ~ a paragraph of fairly useless verbiage=20 in your spec disappears.=20 =20 > > IIRC I've heard of at least one server that doesn't=20 > > implement ssh-userauth.=20 > =20 > This is possible with EXT_INFO also. Send an extension name and value=20 > informing the client of what you implement. No need to waste a round-trip= =20 > for 99.999% of other users.=20 =20 I'll repeat my opinion: an extension mechanism is not the place to=20 fundamentally retcon parts of the protocol. It breaks orthagonality=20 and turns implementations into spaghetti.=20 =20 Perhaps you want a "no-service-requests" extension instead?=20 =20 -d= --=-Izc3JtNdO0fLCVyW8pif Content-Type: text/html; charset="utf-8" > I'm suggesting you specify what is sent, not how
> implementations test for it.

It is important to specify what to test for. Just weeks ago, we had a conversation about how RFC 4253 should have spelled out that the "reserved" field must be sent as zero, but must not be checked that it is zero.

It is important to specify what things implementations should not check for, when incorrect implementation may cause compatibility issues.


> The benefit is that ~ a paragraph of fairly
> useless verbiage in your spec disappears.

You are losing my respect as we continue.


Damien Miller <djm@mindrot.org> , 12/3/2015 4:06 AM:
On Thu, 3 Dec 2015, denis bider wrote:

> > If there's a functioning extension mechanism,
> > then why would there be competition?
>
> To extend other aspects of SSH that EXT_INFO cannot. This could be to change
> some aspect of algorithm negotiation, for example.
>
> For instance, there has been a problem in how AEAD is negotiated. Besides
> what OpenSSH did - implementing a private algorithm for AES-GCM - another
> possible solution could be an extension where both client and server put
> something in their key exchange algorithms field. If both client and server
> do this, then the result of MAC negotiation is ignored if an AEAD encryption
> algorithm is negotiated.
>
> But why do you even feel the need to call this out? Is it any harder to
> call:
>
>     is_in_namelist(name, namelist)
>
> instead of:
>
>     is_at_end_of_namelist(name, namelist)

I'm suggesting you specify what is sent, not how implementations test
for it. The benefit is that ~ a paragraph of fairly useless verbiage
in your spec disappears.

> > IIRC I've heard of at least one server that doesn't
> > implement ssh-userauth.
>
> This is possible with EXT_INFO also. Send an extension name and value
> informing the client of what you implement. No need to waste a round-trip
> for 99.999% of other users.

I'll repeat my opinion: an extension mechanism is not the place to
fundamentally retcon parts of the protocol. It breaks orthagonality
and turns implementations into spaghetti.

Perhaps you want a "no-service-requests" extension instead?

-d
--=-Izc3JtNdO0fLCVyW8pif-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:58:32 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EA31B2C6F for ; Sat, 5 Dec 2015 10:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDa_QstDUACJ for ; Sat, 5 Dec 2015 10:58: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 F19C61B2C70 for ; Sat, 5 Dec 2015 10:58:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 328B085F16; Sat, 5 Dec 2015 18:09:07 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D0D6B85F11; Sat, 5 Dec 2015 18:09:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 63A5A85E8F for ; Thu, 3 Dec 2015 08:55: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=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 UG_AsYBtLSqo for ; Thu, 3 Dec 2015 08:55:53 +0000 (UTC) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 9A61B85E47 for ; Thu, 3 Dec 2015 08:55:52 +0000 (UTC) Received: by wmuu63 with SMTP id u63so11633649wmu.0 for ; Thu, 03 Dec 2015 00:55:51 -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=4L2vDnBPeCl06GChOSdjn4zBo8Zx6Dv2ai8Kb4EA6kk=; b=MLitfUnsC5xivLDASu/zVVqpANgH6Fe0s6sbeeJuoITtN4HTFN4sKGF48ep6WSOeQd a7/DHueyP3tgERuaYto7Nat+6/2uDB3Kg+N7AjvEYsEQgW7LonJJxs1KPQQGsHi+NEke ZKXgYCJAvIQLfyaf6VbZIl6XI26WDiPHGj8lh8ltDEV4KR8AcZ+7wWHp0cAUNJkZynzO 5fsjq47WpCbo1N73f4e6OcVWkfVo0Ha30OHx1QoAqjS4+UTDmREYUmW67uUPtdcTKoH7 An3+YkeymHy4xmdqupZ6V2+euzKRbyck3k8+n+OI2Sd5pyGluwvlC8ehZOnRUwVXOl7T 9dOA== X-Received: by 10.28.3.133 with SMTP id 127mr51730023wmd.101.1449132951013; Thu, 03 Dec 2015 00:55:51 -0800 (PST) Received: from p20030056c67f81a55c4fc75eee29fad3.dip0.t-ipconnect.de (p20030056C67F81A55C4FC75EEE29FAD3.dip0.t-ipconnect.de. [2003:56:c67f:81a5:5c4f:c75e:ee29:fad3]) by smtp.gmail.com with ESMTPSA id uz5sm6510226wjc.8.2015.12.03.00.55.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 00:55:49 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D6F154B-3656-43E6-BD43-D748C9252B7D" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Feedback on draft-ssh-ext-info-00 From: Markus Friedl In-Reply-To: Date: Thu, 3 Dec 2015 09:55:50 +0100 Cc: Peter Gutmann , "ietf-ssh@netbsd.org" Message-Id: <02F1442A-6FB4-4A41-B880-62C6F2C4C17E@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4B9722B@uxcn10-5.UoA.auckland.ac.nz> To: Damien Miller X-Mailer: Apple Mail (2.3096.5) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_3D6F154B-3656-43E6-BD43-D748C9252B7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 03.12.2015 um 00:54 schrieb Damien Miller : >=20 > The problem is that, for a client to test whether rsa-sha2-256 is = supported, > it must make publickey userauth with an included signature. A > signature free PK_OK style request won't do since the key blob just > contains ssh-rsa and not the signature algorithm. For PK_OK the format is: string pkalg =3D { ssh-rss | rsa-sha2-512 } string keyblob so the server can tell the difference without having an actual = signature. However, many severs count these PK_OK checks as an authentication error, so looping over possible signature encodings will break setups. -m= --Apple-Mail=_3D6F154B-3656-43E6-BD43-D748C9252B7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Am 03.12.2015 um 00:54 schrieb Damien Miller <djm@mindrot.org>:

The problem is that, for a client to test = whether rsa-sha2-256 is supported,
it must make publickey userauth with an included = signature. A
signature free PK_OK style = request won't do since the key blob just
contains ssh-rsa and not the signature = algorithm.

For = PK_OK the format is:
     string = pkalg =3D { ssh-rss | rsa-sha2-512 }
    =  string keyblob
so the server can tell the = difference without having an actual signature.
However, many severs count these PK_OK checks as an = authentication
error, so looping over possible = signature encodings will break setups.

-m
= --Apple-Mail=_3D6F154B-3656-43E6-BD43-D748C9252B7D-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 10:58:32 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687B21B2C70 for ; Sat, 5 Dec 2015 10:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xcg_XtWmoLP7 for ; Sat, 5 Dec 2015 10:58:31 -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 1E5261B2C71 for ; Sat, 5 Dec 2015 10:58:30 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 1906C85F25; Sat, 5 Dec 2015 18:08:53 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id BB65B85F24; Sat, 5 Dec 2015 18:08:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4595B85E9C for ; Thu, 3 Dec 2015 09:10:33 +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 ThOpnhpzUrRm for ; Thu, 3 Dec 2015 09:10:32 +0000 (UTC) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 867A985E6E for ; Thu, 3 Dec 2015 09:10:32 +0000 (UTC) Received: by wmec201 with SMTP id c201so12995826wme.1 for ; Thu, 03 Dec 2015 01:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=Ws4NPcVaQriDPmg2ydQrjReibM8Bdb5sEouU+UA+yf4=; b=g2fLQ5ZGGm3/ZqDv0zOmXf4nzHLYsiVx4Ip/4qJUmoxoQzwf9yLj5JNLmnBcUGXtIN X7p66Mys+l+0qnUCewjds7/CF9FnQseV2nDImnJJ2nxdIZ5bHV5qkpbP5DqQS4S0lCOm QkaD6ZG73lkB0gBMJ1bKIpYbFNKFQElSx9kvTJW93wi9vH2KuRVg7EG12Y6Bl/Iqw89s gbfRHVRbHKvj8bOgzp/VouC6BOXdrybKtKZ1+6xgNdN0D7toKAjZW8/boMeRMCgjTopj k7lZGNWHvlZSQ5yppLHER5rlCvgBKSiPL2JXfRUP9cZNkcpqfRwawqoFaJUBamScDjSA pUCg== X-Received: by 10.194.232.230 with SMTP id tr6mr11111957wjc.21.1449133830915; Thu, 03 Dec 2015 01:10:30 -0800 (PST) Received: from [172.23.1.24] (p3EE06EC7.dip0.t-ipconnect.de. [62.224.110.199]) by smtp.gmail.com with ESMTPSA id pn6sm6567861wjb.15.2015.12.03.01.10.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 01:10:26 -0800 (PST) Subject: Re: Feedback on draft-ssh-ext-info-00 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_2AB6330D-5C70-47C8-9B18-41EB58F66501" From: Markus Friedl X-Priority: 3 In-Reply-To: <1631879346-2660@skroderider.denisbider.com> Date: Thu, 3 Dec 2015 10:10:25 +0100 Cc: Damien Miller , ietf-ssh@netbsd.org Message-Id: References: <1631879346-2660@skroderider.denisbider.com> To: denis bider X-Mailer: Apple Mail (2.3096.5) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_2AB6330D-5C70-47C8-9B18-41EB58F66501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 03.12.2015 um 01:33 schrieb denis bider : >=20 > But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. = :) >=20 > Does no one agree that SERVICE_REQUEST + ACCEPT are pointless? >=20 I don't think that the extension should redefine or replace existing = prorotocl messages. It should just be an additional message indicating the = extensions. -m= --Apple-Mail=_2AB6330D-5C70-47C8-9B18-41EB58F66501 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Am 03.12.2015 um 01:33 schrieb denis bider <ietf-ssh3@denisbider.com>:

But but but I waaaant to replace this = awful SSH_MSG_SERVICE_REQUEST. :)

Does no one agree that SERVICE_REQUEST + ACCEPT = are pointless?


I = don't think that the extension should redefine or replace existing = prorotocl
messages. It should just be an additional = message indicating the extensions.

-m
= --Apple-Mail=_2AB6330D-5C70-47C8-9B18-41EB58F66501-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 11:03:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404251B2C9A for ; Sat, 5 Dec 2015 11:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVarE1biWVL4 for ; Sat, 5 Dec 2015 11:03: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 0140E1B2C98 for ; Sat, 5 Dec 2015 11:03:30 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5A78985F02; Sat, 5 Dec 2015 18:09:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B3E8085F11; Sat, 5 Dec 2015 18:09:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E83D285EB6 for ; Thu, 3 Dec 2015 07:26: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 nFAqNGKjR-xO for ; Thu, 3 Dec 2015 07:26: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 64E4185E9A for ; Thu, 3 Dec 2015 07:26:57 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Thu, 3 Dec 2015 07:26:53 +0000 Date: Thu, 3 Dec 2015 07:26:53 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1656686251-2152@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: MIME-Version: 1.0 From: denis bider To: Damien Miller Cc: Markus Friedl , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-k53di3sVkKPlF4IJxpYX" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-k53di3sVkKPlF4IJxpYX Content-Type: text/plain; charset="utf-8" Okay, I'll modify the draft to this effect. This may take me a bit, I currently have a few urgent things to attend to. I would appreciate your thoughts on the question of EXT_INFO windows for client and server. Do you find it acceptable if the proposal requires both client and server to send their first EXT_INFO immediately after NEWKEYS? Specifically, that the server does not wait between EXT_INFO and NEWKEYS to receive anything more from the client? That way: - I can then put in an extension like "assume-service"; - the client can send EXT_INFO("assume-service") + SERVICE_REQUEST; - when the client sees the server's EXT_INFO("assume-service"), it can just continue with USERAUTH_REQUEST, and SERVICE_ACCEPT is not sent. Damien Miller , 12/3/2015 7:14 AM: On Thu, 3 Dec 2015, denis bider wrote: > > Merely advertising a willingness to accept SSH_MSG_EXT_INFO > > shouldn't have other further effects on the protocol. To do > > otherwise is IMO quite surprising. > > Okay, imagine this: > > (1) Instead of the EXT_INFO message, we continue to send SERVICE_REQUEST + > ACCEPT. > > (2) The KEXINIT extension instead signals that extension fields can be added > to SERVICE_REQUEST + ACCEPT. > > (3) Presence of the KEXINIT extension further signals that the server can > send a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUEST. > > Do you see that this results in the same proposal, just with renamed > messages? At the risk of repeating myself, I think providing a simple transport layer extension mechanism is a fantastic idea, but don't agree that it should make other protocol changes (except, perhaps as extensions defined in the same document). -d --=-k53di3sVkKPlF4IJxpYX Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Okay, I'll modify the draft to this effect. This m= ay take me a bit, I currently have a few urgent things to attend to.
I would appreciate your thoughts on the question of EXT_INFO windows for c= lient and server.

Do you find it acceptable if the proposal requires= both client and server to send their first EXT_INFO immediately after NEWK= EYS?

Specifically, that the server does not wait between EXT_INFO an= d NEWKEYS to receive anything more from the client?

That way:
- I= can then put in an extension like "assume-service";
- the client can se= nd EXT_INFO("assume-service") + SERVICE_REQUEST;
- when the client sees = the server's EXT_INFO("assume-service"), it can just continue with USERAUTH= _REQUEST, and SERVICE_ACCEPT is not sent.




Damien Miller <djm@mindrot.org> , 12/3/2015 7:14 AM:<= br>
On Thu, 3 Dec 2015, denis bider wrote:

> > Merely advertising a willingness to accept SSH_MSG_EXT_INFO
> > shouldn't have other further effects on the protocol. To do
> > otherwise is IMO quite surprising.
>=20
> Okay, imagine this:
>=20
> (1) Instead of the EXT_INFO message, we continue to send SERVICE_R= EQUEST +
> ACCEPT.
>=20
> (2) The KEXINIT extension instead signals that extension fields ca= n be added
> to SERVICE_REQUEST + ACCEPT.
>=20
> (3) Presence of the KEXINIT extension further signals that the ser= ver can
> send a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUES= T.
>=20
> Do you see that this results in the same proposal, just with renam= ed
> messages?

At the risk of repeating myself, I think providing a simple transport
layer extension mechanism is a fantastic idea, but don't agree that
it should make other protocol changes (except, perhaps as extensions
defined in the same document).

-d
= --=-k53di3sVkKPlF4IJxpYX-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 11:03:32 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEECE1B2C98 for ; Sat, 5 Dec 2015 11:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXr3Y28wJ0Hh for ; Sat, 5 Dec 2015 11:03: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 BBDA71B2C97 for ; Sat, 5 Dec 2015 11:03:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 1650F85F1E; Sat, 5 Dec 2015 18:08:40 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C301C85F0B; Sat, 5 Dec 2015 18:08:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 29D8E85E9E for ; Thu, 3 Dec 2015 01:51:08 +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 ylIYLCxEBcpi for ; Thu, 3 Dec 2015 01:51:07 +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 28BCD85E94 for ; Thu, 3 Dec 2015 01:51:07 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Thu, 3 Dec 2015 01:51:01 +0000 Date: Thu, 3 Dec 2015 01:51:01 +0000 Subject: Updated EXT_INFO draft - draft-ssh-ext-info-02 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1634365300-2152@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1631879346-2660@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: Damien Miller , Markus Friedl Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-6ZFcRhvoqLdeY44dSHr+" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-6ZFcRhvoqLdeY44dSHr+ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have posted an updated EXT_INFO draft here: https://tools.ietf.org/html/draft-ssh-ext-info-02 Most significant changes: - Included an "accept-channels" extension, as per Damien's suggestion. - Removed the "client-req-ok" extension. Responses to comments: (1) "The scheme is complex." The scheme is in fact simple: (a) Include indicator names in KEXINIT name-list. (b) If both client and server indicate support, replace SERVICE_REQUEST + A= CCEPT by sending EXT_INFO on both sides. This does not seem complex to me. The reason it may seem complex is because the spec tries to identify and sp= ecify as many corner cases as possible. This corner case coverage makes the= mechanism seem complex. But this coverage is a feature. A different mechanism may seem "simpler" without actually being simpler - i= f you realize that the "simplicity" comes from ignoring corner situations, = and leaving them unspecified. (2) "client-req-ok is unnecessary" I have identified OpenSSH 3.1, released March 2002, as the first version th= at does not disconnect if the server sends a global request. The oldest OpenSSH version I can confirm seeing recently is version 3.9. I = also remember sporadically seeing old versions of SunSSH, which might be ba= sed either on OpenSSH 3.5, or OpenSSH 2.3. So there might still be software= out there that disconnects if the server sends a global request, but it sh= ould be very old. You are right, I have removed this extension. (3) "Don't replace SERVICE_REQUEST + ACCEPT" I still believe SERVICE_REQUEST + ACCEPT serve no purpose, and waste a roun= d-trip for no reason. This seems like a great opportunity to do away with t= hem. (4) "no-handbrake should be per-channel" As stated previously, if even one channel does not have flow control, this = affects the transport layer, too. It affects keep-alive mechanisms, key ex= change, and flow control at the transport level. I have in fact strengthened the language, to exclude this extension from be= ing used for sessions that require proper multiplexing. If you want channel multiplexing, do it right. denis denis bider , 12/3/2015 12:24 AM: > IMO it would be best to make it a MUST that the flags > may only be sent as the last element. What rationale is > there for putting it anywhere else? In the event that there are two or more competing extension mechanisms, onl= y one of them can be last. > and don't "replace" any messages like > SSH_MSG_SERVICE_REQUEST. But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. :) Does no one agree that SERVICE_REQUEST + ACCEPT are pointless? A whole round-trip delay? For no benefit - in any known usage scenario? > OpenSSH has sent various @openssh.com global > requests for years, so most of the implementations > that violate this should have long since been shaken out. Do you happen to know: - Since which version the OpenSSH server has been sending global requests? - Since which version the OpenSSH client has been tolerating them? There are still folks out there using OpenSSH 3.x and 4.x. I'm pretty sure = I saw our software being connected to by a client like that in the past wee= k. > (e.g. it's impossible to have one channel without the > "handbrake" and one with normal flow control) As discussed, this is on purpose. If you want multiplexing, implement multi= plexing, including flow control. If even one channel does not have flow control, this affects the transport = layer also. It affects keep-alive mechanisms, key exchange, and flow contro= l at the transport level. > Given this, IMO this would be better off being replaced by a > generic "these are the channel types I'm prepared to open" > message, which would be useful even for implementation > that don't want to turn off flow control but which do > implement non-standard channel types (e.g. tun@openssh.com). Sounds like an idea for another extension: Name: supported-channels Value: name-list of accepted channel types ? :-) denis ----- Original Message ----- From: Damien Miller=20 Sent: Wednesday, December 2, 2015 05:35 To: ietf-ssh@netbsd.org=20 Subject: Feedback on draft-ssh-ext-info-00 Hi, Here's some feedback on draft-ssh-ext-info-00. > 3.1.=C2=A0 Signaling of Extension Negotiation in KEXINIT ... > The indicator name is added without quotes, and MAY be added at any > position in the name-list, subject to proper separation from other > names as per name-list conventions. The suggested position is last in > the list, but implementations MUST recognize these indicator names > when included at any position. IMO it would be best to make it a MUST that the flags may only be sent as the last element. What rationale is there for putting it anywhere else? > 3.2.=C2=A0 Mechanism Enabling Criteria This whole section seems over-complicated. I think a simpler scheme is: If a client or server offers "ext-info-c" or "ext-info-s" respectively, then it must be prepared to accept a SSH_MSG_EXT_INFO message from the peer.=20 If this message is sent, then it will be the first message after the initial SSH_MSG_NEWKEYS. I.e. make it a simple advertisment that a client or server is willing to accept a notification message that might optionally be sent. Don't require both sides to offer acceptance, don't have the messages offer any sort of negotiation between the client and server (just statements of extensions/capabilities) and don't "replace" any messages like SSH_MSG_SERVICE_REQUEST. This would yield a much simpler specification IMO. > 4. Initially Defined Extensions > 4.2.=C2=A0 "client-req-ok" I don't see the point of this: implementations that don't respond with SSH_MSG_REQUEST_FAILURE to unknown SSH_MSG_GLOBAL_REQUEST messages are incompliant with RFC4254 section 4. OpenSSH has sent various @openssh.com global requests for years, so most of the implementations that violate this should have long since been shaken out. > 4.3.=C2=A0 "no-handbrake" This could be implemented more elegantly using new channel type names in SSH_MSG_CHANNEL_OPEN messages rather than the complicated and inflexible method proposed here (e.g. it's impossible to have one channel without the "handbrake" and one with normal flow control). It would be better to use the extension to signal that the peer is willing to accept SSH_MSG_CHANNEL_OPEN messages with new channel type names, and use these to selectively disable flow control. Given this, IMO this would be better off being replaced by a generic "these are the channel types I'm prepared to open" message, which would be useful even for implementation that don't want to turn off flow control but which do implement non-standard channel types (e.g. tun@openssh.com). -d = --=-6ZFcRhvoqLdeY44dSHr+ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have posted an updated EXT_INFO draft here:
<= br>https://tools.ietf.org/html/draft-ssh-ext-info-02

Most significan= t changes:
- Included an "accept-channels" extension, as per Damien's su= ggestion.
- Removed the "client-req-ok" extension.

Responses to c= omments:


(1) "The scheme is complex."

The scheme i= s in fact simple:

(a) Include indicator names in KEXINIT name-list.<= br>(b) If both client and server indicate support, replace SERVICE_REQUEST = + ACCEPT by sending EXT_INFO on both sides.

This does not seem compl= ex to me.

The reason it may seem complex is because the spec = tries to identify and specify as many corner cases as possible. This corner= case coverage makes the mechanism seem complex. But this coverage is a fea= ture.

A different mechanism may seem "simpler" without actually being simpler - if you realize that the "simplicity" comes from ignoring= corner situations, and leaving them unspecified.


(2) "client= -req-ok is unnecessary"

I have identified OpenSSH 3.1, released = March 2002, as the first version that does not disconnect if the server sen= ds a global request.

The oldest OpenSSH version I can confirm seeing= recently is version 3.9. I also remember sporadically seeing old versions = of SunSSH, which might be based either on OpenSSH 3.5, or OpenSSH 2.3. So t= here might still be software out there that disconnects if the serve= r sends a global request, but it should be very old.

You are = right, I have removed this extension.


(3) "Don't replace SERV= ICE_REQUEST + ACCEPT"

I still believe SERVICE_REQUEST + ACCEPT s= erve no purpose, and waste a round-trip for no reason. This seems like a gr= eat opportunity to do away with them.


(4) "no-handbrake shoul= d be per-channel"

As stated previously, if even one channel does= not have flow control, this affects the=20 transport layer, too. It affects keep-alive mechanisms, key exchange,=20 and flow control at the transport level.

I have in fact strengthened= the language, to exclude this extension from being used for sessions that = require proper multiplexing.

If you want channel multiplexing, do it= right.

denis



denis bider <ietf-ssh3@denisbider.com> , 12/3/2015 12:24 AM:
> IMO it would be best to make it a MUST = that the flags
> may only be sent as the last element. What rationale= is
> there for putting it anywhere else?

In the event that th= ere are two or more competing extension mechanisms, only one of them can be= last.


> and don't "replace" any messages like
> SSH_MS= G_SERVICE_REQUEST.

But but but I waaaant to replace this awful SSH_M= SG_SERVICE_REQUEST. :)

Does no one agree that SERVICE_REQUEST + ACCE= PT are pointless?

A whole round-trip delay? For no benefit - in any = known usage scenario?


> OpenSSH has sent various @openssh.com= global
> requests for years, so most of the implementations
> = that violate this should have long since been shaken out.

Do you hap= pen to know:

- Since which version the OpenSSH server has been sendi= ng global requests?

- Since which version the OpenSSH client has bee= n tolerating them?

There are still folks out there using OpenSSH 3.x= and 4.x. I'm pretty sure I saw our software being connected to by a client= like that in the past week.


> (e.g. it's impossible to have = one channel without the
> "handbrake" and one with normal flow contro= l)

As discussed, this is on purpose. If you want multiplexing, imple= ment multiplexing, including flow control.

If even one channel does = not have flow control, this affects the transport layer also. It affects ke= ep-alive mechanisms, key exchange, and flow control at the transport level.=


> Given this, IMO this would be better off being replaced by= a
> generic "these are the channel types I'm prepared to open"
&g= t; message, which would be useful even for implementation
> that don'= t want to turn off flow control but which do
> implement non-standard= channel types (e.g. tun@openssh.com).

Sounds like an = idea for another extension:

Name: supported-channels
Value: name-= list of accepted channel types

? :-)

denis


----- O= riginal Message -----
From: Damien Miller
Sent: Wednesday, December = 2, 2015 05:35
To: ietf-ssh@netbsd.org
Subject:= Feedback on draft-ssh-ext-info-00

Hi,

Here's some feedback o= n draft-ssh-ext-info-00.

> 3.1.  Signaling of Extension Nego= tiation in KEXINIT
...
> The indicator name is added without quote= s, and MAY be added at any
> position in the name-list, subject to pr= oper separation from other
> names as per name-list conventions. The = suggested position is last in
> the list, but implementations MUST re= cognize these indicator names
> when included at any position.
IMO it would be best to make it a MUST that the flags may only be
sent = as the last element. What rationale is there for putting it
anywhere els= e?

> 3.2.  Mechanism Enabling Criteria

This whole sec= tion seems over-complicated. I think a simpler scheme
is:

If a cl= ient or server offers "ext-info-c" or "ext-info-s" respectively,
then it= must be prepared to accept a SSH_MSG_EXT_INFO message from the
peer.
If this message is sent, then it will be the first message after the<= br>initial SSH_MSG_NEWKEYS.

I.e. make it a simple advertisment that = a client or server is willing
to accept a notification message that migh= t optionally be sent.
Don't require both sides to offer acceptance, don'= t have the messages
offer any sort of negotiation between the client and= server (just
statements of extensions/capabilities) and don't "replace"= any
messages like SSH_MSG_SERVICE_REQUEST.

This would yield a mu= ch simpler specification IMO.

> 4. Initially Defined Extensions> 4.2.  "client-req-ok"

I don't see the point of this: imp= lementations that don't respond with
SSH_MSG_REQUEST_FAILURE to unknown = SSH_MSG_GLOBAL_REQUEST messages are
incompliant with RFC4254 section 4.<= br>
OpenSSH has sent various @openssh.com global requests for years,
= so most of the implementations that violate this should have long since
= been shaken out.

> 4.3.  "no-handbrake"

This could be= implemented more elegantly using new channel type names
in SSH_MSG_CHAN= NEL_OPEN messages rather than the complicated and
inflexible method prop= osed here (e.g. it's impossible to have one
channel without the "handbra= ke" and one with normal flow control).

It would be better to use the= extension to signal that the
peer is willing to accept SSH_MSG_CHANNEL_= OPEN messages with new channel
type names, and use these to selectively = disable flow control.

Given this, IMO this would be better off being= replaced by a generic
"these are the channel types I'm prepared to open= " message, which would
be useful even for implementation that don't want= to turn off flow control
but which do implement non-standard channel ty= pes (e.g. tun@openssh.com).

-d

= --=-6ZFcRhvoqLdeY44dSHr+-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 11:08:32 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022531B2CBE for ; Sat, 5 Dec 2015 11:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9HkNfVovXY8 for ; Sat, 5 Dec 2015 11:08: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 68FA61B2CB7 for ; Sat, 5 Dec 2015 11:08:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B62EB85F0A; Sat, 5 Dec 2015 18:05:35 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 5B50785F08; Sat, 5 Dec 2015 18:05:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DD32385E73 for ; Wed, 2 Dec 2015 09:31: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=gmail.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id m_4iLxDkrFcc for ; Wed, 2 Dec 2015 09:31:02 +0000 (UTC) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 CF1A984C73 for ; Wed, 2 Dec 2015 09:31:01 +0000 (UTC) Received: by wmww144 with SMTP id w144so48394843wmw.0 for ; Wed, 02 Dec 2015 01:31:00 -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=5BVq8/hl7EQDyYbk7nN5RhWuElHuweze72hTqw1Z6pE=; b=llodHSLvpr894GJMwZ3S5m6QEK48pAnetmMaNTsMvfvFqATILtiKzVlenwMyoTxGOl w2SgqbUdhYw0wwSkLnXhREEPf52yKvd8S9hpORekVPRcFMfEU/l3TT41c6awCQqDRbKv A7x0EcPJ+ucp43ZVOJN7wH+YV3dWjak8+NPbbOD3P62Q3Qumoa22ur6cWqODb28zNvZw lNHQsUuAb2BO9qjS++P6jumAaqd8dqRkzlODvmLHzCXjBM0cI1TelmBVHTESk/Vj6kpE s8aui63EJNkRb4Y6f4X+dk7Fs/OEW1qH+wVQRWY6opUaNb8e+eKN1Z8NQyBMXA8AxdYj hK5g== X-Received: by 10.194.110.35 with SMTP id hx3mr3720551wjb.0.1449048660192; Wed, 02 Dec 2015 01:31:00 -0800 (PST) Received: from icsil1noteb193.epfl.ch (icsil1noteb193.epfl.ch. [128.178.151.41]) by smtp.gmail.com with ESMTPSA id h7sm2329002wmf.0.2015.12.02.01.30.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 01:30:59 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_6B351A1E-F69B-4B22-9B33-368C0DE06CE6"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Binary packet protocol rethink From: Bryan Ford In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B95D3F@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 2 Dec 2015 10:30:58 +0100 Cc: =?utf-8?Q?Niels_M=C3=B6ller?= , Damien Miller , Simon Tatham , Simon Josefsson , "ietf-ssh@netbsd.org" Message-Id: <94C59487-9D91-436D-AAAB-D36881F65539@gmail.com> References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B95D3F@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3096.5) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_6B351A1E-F69B-4B22-9B33-368C0DE06CE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 02 Dec 2015, at 02:09, Peter Gutmann = wrote: > Niels M=C3=B6ller writes: >=20 >> The ssh transport machinery can encrypt these, then split them into = fixed >> size blocks and send off with pre-determined intervals, and whatever = else you >> think is a useful counter measure to traffic analysis. When an input = message >> or message fragment is too short, insert ignore messages (preferable = in >> *front* of the real data, for the byte-by-byte dribble attack). >=20 > The important point there is that it *can*, not that it actually = *does*. I've > heard that there was an OpenSSH patch some years ago that did = something like > this, but in about 15 years of interop-testing my code I've never seen = any > evidence that the other side is applying any traffic-analysis = countermeasures. > A quick Google turns up this blog post from a few months ago: >=20 > = http://malwaremusings.com/2015/07/13/traffic-analysis-openssh-with-an-inte= ractive-shell/ >=20 > which indicates that OpenSSH doesn't implement traffic-analysis = protection > (not trying to single out OpenSSH here, but that seems to have the = most bells > and whistles added to it so if it was implemented I'd sort of expect = to see it > there first), and that some random guy with a copy of Wireshark (not = an > intelligence agency, if that's what the perceived threat is) doesn't = have much > problem in doing traffic analysis on it. >=20 > So there appears to be either zero or close to zero support out there = for > anti-traffic-analysis. Even if, say, OpenSSH were to add support, = that would > only affect two similar OpenSSH implementations talking to each other. = As > soon as you get a single other SSH implementation involved (and there = are a > lot of them out there), you lose the anti-traffic analysis. That=E2=80=99s only the case with your approach of leaving all headers = (SSH or TLS) in cleartext. With cleartext headers, any SSH or TLS = implementation that fails to do padding gets basically no traffic = analysis protection at all, even if its communication partner does. = It=E2=80=99s indeed partly an =E2=80=9Cecosystem problem=E2=80=9D as = Eben Moglen would say, and in the long term we need to try to fix that, = but it=E2=80=99s hard. With encrypted headers, however, *every* SSH or TLS conversation can get = at least some (admittedly weak but still useful) protection against at = least passive traffic analysis. As many have said already, not all = attackers are active MITM attackers; we need to care about passive = attackers as well. =20 And as I pointed out on the TLS list, TCP segments can be desynchronized = from SSH or TLS records for many reasons and in a variety of points in = the network, either intentionally or unintentionally: e.g., in the SSH = or TLS implementation, in the TCP stack (by merging adjacent or = time-proximate writes), or in middleboxes that resegment TCP streams. = Even if none of those network elements are *intentionally* trying to = provide traffic analysis protection, even just the fact that they are = sometimes unintentionally =E2=80=9Cmessing up=E2=80=9D the TCP = segmentation boundaries makes things at least a bit harder and more = noisy for passive attackers who only get to watch segments fly past and = don=E2=80=99t get to mount dribble attacks and such. And a single = administrator can deploy a middlebox at the edge of a corporate or = campus network to provide even better (still weak but better) traffic = analysis protection for all SSH/TLS traffic crossing that middlebox, by = deliberately delaying TCP segments just slightly and re-segmenting them = on uniform MTU-size boundaries. But only if SSH maintains encrypted headers, or if TLS adopts encrypted = headers. >> I'm happy to discuss the tradeoffs here, but it seems that you keep = repeating >> that the attacker gets as much useful info from observing tcp segment >> boundaries as from observing ssh message boundaries. >=20 > At the moment it seems they do. Unless actual, real countermeasures = to > traffic analysis are actively applied by as many SSH implementations = as > possible, encrypting the headers does nothing more than inconvenience > implementers. >=20 > So, let's turn this around: Show me evidence of assorted SSH = implementations > performing anti-traffic-analysis measures, and then we can debate = whether > encrypting the length hinders those countermeasures. Your point that =E2=80=9Cserious" anti-traffic-analysis measures such as = uniform padding are (currently) rarely implemented, which I believe, = only makes the case stronger that we need to do everything we can to = make traffic streams coming from that vast majority of = non-traffic-analysis-protected implementations even just a bit more = protected =E2=80=9Cat the outset=E2=80=9D from even a subset of traffic = analysis attackers. Security is not a black-or-white, all-or-nothing = thing where you might as well give up unless you can win the whole war = in the first battle. B >=20 > Peter. --Apple-Mail=_6B351A1E-F69B-4B22-9B33-368C0DE06CE6 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 Fw0xNTEyMDIwOTMwNThaMCMGCSqGSIb3DQEJBDEWBBSv9gy4wJnIkBW8F8dn2Ck56AZ3iDCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAUXdhFkuB13aJoO7NvKAmaHKbF3BZY4BsRXeFcBZeyHb6T3lD0TGsAQhOyxU9BDjI xFP2pNxx0/lLxv2mUD7lCju4wSq49jVa2Zw/wwucX7ufq+9NmRJ7Au3aD5PLa67TYn5v4G4kZ9oF kC6XrDpjtunSaijXtYCa2YuTf5FbS410/XVH+IKXA0EjSHXTeH/nYD/N/iw6QaDCV+awMKBKjvAb s2tedskijqJwdWgYw/v2vgcyB5P+5qrE5xWZTM6lJLSlX5R3jTdNI4W2USCFML2V/AIh8hqBxHEV qZA3xoBPB7f7qE2Dgx4PftviDknmUXuMyQxAlKyQxSkiJyXJ+gAAAAAAAA== --Apple-Mail=_6B351A1E-F69B-4B22-9B33-368C0DE06CE6-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 11:38:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEF21A8AE3 for ; Sat, 5 Dec 2015 11:38:31 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3UPuzsdl9hU for ; Sat, 5 Dec 2015 11:38: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 4F9C81A8ADF for ; Sat, 5 Dec 2015 11:38:30 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 5430385F19; Sat, 5 Dec 2015 18:09:14 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0ED2785F11; Sat, 5 Dec 2015 18:09:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E06FF85EBC for ; Thu, 3 Dec 2015 11:14: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 NRIxSk0RLHTA for ; Thu, 3 Dec 2015 11:14: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 69C6B85E8A for ; Thu, 3 Dec 2015 11:14:29 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Thu, 3 Dec 2015 11:14:24 +0000 Date: Thu, 3 Dec 2015 11:14:24 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1670890688-3144@skroderider.denisbider.com> From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= Cc: Damien Miller , Markus Friedl , ietf-ssh@netbsd.org X-Priority: 3 Importance: Normal In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-/rmZYzDH9QxGEJIdeF7X" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-/rmZYzDH9QxGEJIdeF7X Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Point taken. You are probably right. Niels M=C3=B6ller , 12/3/2015 10:59 AM: Regarding sending SERVICE_REQUEST and userauth messages back-to-back,=20 =20 denis bider writes:=20 =20 > I'm not sure that we have a guarantee that the server must properly=20 > handle this chaining.=20 =20 Have you seen any implementations broken is this way?=20 =20 I'd expect any reasonable server to process incoming messages properly,=20 and in case it for some reason isn't ready to process the next logical=20 message, simply delay reading and processing messages until it is ready.=20 =20 After all, the protocol is very intentionally designed to minimize the=20 number of roundtrip delays.=20 =20 > One would imagine people would not do this, but I've dealt with an=20 > implementation that discards KEXINIT if it's received in the same=20 > network frame as the SSH version string.=20 =20 I think that's a different bug, and not very relevant. That's the point=20 where you switch from new-line-delimited text data to the binary data,=20 which needs some care to get right.=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 = --=-/rmZYzDH9QxGEJIdeF7X Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Point taken. You are probably right.


Nie= ls M=C3=B6ller <nisse@lysator.liu.se> , 12/3/2015 10:59 AM:
Regarding se= nding SERVICE_REQUEST and userauth messages back-to-back,

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

> I'm not sure that we have a guarantee that the server must properl= y
> handle this chaining.

Have you seen any implementations broken is this way?

I'd expect any reasonable server to process incoming messages properly,
and in case it for some reason isn't ready to process the next logical
message, simply delay reading and processing messages until it is ready= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 11:43:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8AA1A8AF1 for ; Sat, 5 Dec 2015 11:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OziY4kR9fdnf for ; Sat, 5 Dec 2015 11:43: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 2B07E1A8AEF for ; Sat, 5 Dec 2015 11:43:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 4172385F26; Sat, 5 Dec 2015 18:08:21 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 78E4685F20; Sat, 5 Dec 2015 18:08:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E05D585EB6 for ; Thu, 3 Dec 2015 07:09:34 +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 T-GkudPCvuOt for ; Thu, 3 Dec 2015 07:09:34 +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 2604385E9A for ; Thu, 3 Dec 2015 07:09:34 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for djm@mindrot.org; Thu, 3 Dec 2015 07:09:27 +0000 Date: Thu, 3 Dec 2015 07:09:27 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1655861333-3540@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <1654355845-3540@skroderider.denisbider.com> MIME-Version: 1.0 From: denis bider To: Damien Miller Cc: Markus Friedl , ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-RtG9GWnzFmDWZtSxXTIT" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-RtG9GWnzFmDWZtSxXTIT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If after considering this, you still really want the SERVICE_REQUEST + ACCE= PT round-trip, then okay. I can change the spec to not alter this part, if = this way we have something we can all agree on. But if we change it this way, when do you want EXT_INFO to be sent? What is= the window in which it should be accepted? The current proposal makes the window: - between NEWKEYS and SERVICE_REQUEST for the client, sent one time=20 - between NEWKEYS and USERAUTH_SUCCESS for the server, sent any number of t= imes (mainly so the server can send a second EXT_INFO just before USERAUTH_= REQUEST. This way you can advertise extensions that alter user auth; but yo= u can also have privacy for extensions that only take effect after. If we change EXT_INFO the way you propose, and keep SERVICE_REQUEST + ACCEP= T as-is - are you okay with these windows? denis bider , 12/3/2015 6:38 AM: > Why add fixed-function fields to a generic extension mechanism?=20 So as to avoid ret-conning functionality provided by SERVICE_REQUEST + ACCE= PT. These two messages always negotiate the service (e.g. "ssh-userauth"). So E= XT_INFO, which is a replacement, also always negotiates the service. This is in fact simpler than adding a "services" extension, and then mandat= ing that this extension "MUST" be handled by all implementations. If some f= unctionality must always be handled, a fixed field is appropriate. > Merely advertising a willingness to accept SSH_MSG_EXT_INFO > shouldn't have other further effects on the protocol. To do > otherwise is IMO quite surprising.=20 =20 Okay, imagine this: (1) Instead of the EXT_INFO message, we continue to send SERVICE_REQUEST + = ACCEPT. (2) The KEXINIT extension instead signals that extension fields can be adde= d to SERVICE_REQUEST + ACCEPT. (3) Presence of the KEXINIT extension further signals that the server can s= end a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUEST. Do you see that this results in the same proposal, just with renamed messag= es? Damien Miller , 12/3/2015 6:31 AM: On Thu, 3 Dec 2015, denis bider wrote:=20 =20 > I have posted a new draft to address this:=20 > =20 > https://tools.ietf.org/html/draft-ssh-ext-info-03=20 > =20 > The difference is that there is now a "services" field in EXT_INFO:=20 > =20 > =C2=A0 =C2=A0 byte =C2=A0 =C2=A0 =C2=A0 SSH_MSG_EXT_INFO (value 7)=20 > =C2=A0 =C2=A0 name-list =C2=A0services=20 > =C2=A0 =C2=A0 uint32 =C2=A0 =C2=A0 nr-extensions=20 > =C2=A0 =C2=A0 repeat "nr-extensions" times:=20 > =C2=A0 =C2=A0 =C2=A0 string =C2=A0 extension-name=20 > =C2=A0 =C2=A0 =C2=A0 string =C2=A0 extension-value=20 > =20 > And a section to describe it:=20 > =20 > 3.5. =C2=A0Service Negotiation=20 > =C2=A0 The client and server each include a name-list of supported servic= es=20 > =C2=A0 in EXT_INFO. The name-lists are matched to negotiate a service in = the=20 > =C2=A0 same way as name-lists are matched in KEXINIT. Clients and servers= =20 > =C2=A0 that support only "ssh-userauth" MUST send this service name only.= =20 > =C2=A0 Implementations supporting only one service MAY assume it will be=20 > =C2=A0 negotiated, and MAY send messages on that premise without waiting.= =20 > =20 > Would you agree this makes EXT_INFO a proper superset of SERVICE_REQUEST = +=20 > ACCEPT?=20 =20 This is over-complicated. Why add fixed-function fields to a generic=20 extension mechanism?=20 =20 I'd support a simple magic name, offered in KEXINIT to indicate that an=20 implementation is prepared to accept a SSH_MSG_EXT_INFO packet.=20 Merely advertising a willingness to accept SSH_MSG_EXT_INFO shouldn't=20 have other further effects on the protocol. To do otherwise is IMO quite=20 surprising.=20 =20 Then, if you want to define a "die-service-request-die" extension that=20 changes the protocol flow then you can do that without requiring other=20 implementations to follow suit.=20 =20 -d=20 =20 = --=-RtG9GWnzFmDWZtSxXTIT Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable If after considering this, you still really want t= he SERVICE_REQUEST + ACCEPT round-trip, then okay. I can change the spec to= not alter this part, if this way we have something we can all agree on.
But if we change it this way, when do you want EXT_INFO to be sent? Wh= at is the window in which it should be accepted?

The current proposa= l makes the window:

- between NEWKEYS and SERVICE_REQUEST for the cl= ient, sent one time

- between NEWKEYS and USERAUTH_SUCCESS for the = server, sent any number of times (mainly so the server can send a second EX= T_INFO just before USERAUTH_REQUEST. This way you can advertise extensions = that alter user auth; but you can also have privacy for extensions that onl= y take effect after.

If we change EXT_INFO the way you propose, and = keep SERVICE_REQUEST + ACCEPT as-is - are you okay with these windows?
<= br>
denis bider <ietf-ssh3@denisbider.= com> , 12/3/2015 6:38 AM:
> Why add fixed-function fields to a generic extension mechanism?

So as to avoid ret-conning functionality provided by SERVICE_REQUES= T + ACCEPT.

These two messages always negotiate the service (e.g. "s= sh-userauth"). So EXT_INFO, which is a replacement, also always negotiates = the service.

This is in fact simpler than adding a "services" extens= ion, and then mandating that this extension "MUST" be handled by all implem= entations. If some functionality must always be handled, a fixed field is a= ppropriate.


> Merely advertising a willingness to accept SSH_= MSG_EXT_INFO
> shouldn't have other further effects on the protocol. = To do
> otherwise is IMO quite surprising.

Okay, imagine this:

(1) Instead of the EXT_INFO message, we cont= inue to send SERVICE_REQUEST + ACCEPT.

(2) The KEXINIT extension ins= tead signals that extension fields can be added to SERVICE_REQUEST + ACCEPT= .

(3) Presence of the KEXINIT extension further signals that the ser= ver can send a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUEST= .

Do you see that this results in the same proposal, just with renam= ed messages?



Damien Miller <djm@mindrot.org> , 12/3/2015 6:31 AM:
On Thu, 3 Dec 2015, denis bider wrote:

> I have posted a new draft to address this:
>=20
> h= ttps://tools.ietf.org/html/draft-ssh-ext-info-03
>=20
> The difference is that there is now a "services" field in EXT_INFO= :
>=20
>     byte       SSH_MSG_EXT_INFO (value 7)
>     name-list  services
>     uint32     nr-extensions
>     repeat "nr-extensions" times:
>       string   extension-name
>       string   extension-value
>=20
> And a section to describe it:
>=20
> 3.5.  Service Negotiation
>   The client and server each include a name-list of supported= services
>   in EXT_INFO. The name-lists are matched to negotiate a serv= ice in the
>   same way as name-lists are matched in KEXINIT. Clients and = servers
>   that support only "ssh-userauth" MUST send this service nam= e only.
>   Implementations supporting only one service MAY assume it w= ill be
>   negotiated, and MAY send messages on that premise without w= aiting.
>=20
> Would you agree this makes EXT_INFO a proper superset of SERVICE_R= EQUEST +
> ACCEPT?

This is over-complicated. Why add fixed-function fields to a generic
extension mechanism?

I'd support a simple magic name, offered in KEXINIT to indicate that an
implementation is prepared to accept a SSH_MSG_EXT_INFO packet.
Merely advertising a willingness to accept SSH_MSG_EXT_INFO shouldn't
have other further effects on the protocol. To do otherwise is IMO quit= e
surprising.

Then, if you want to define a "die-service-request-die" extension that
changes the protocol flow then you can do that without requiring other
implementations to follow suit.

-d

= --=-RtG9GWnzFmDWZtSxXTIT-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 11:43:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01781A8AEF for ; Sat, 5 Dec 2015 11:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD7z2uvqrLSD for ; Sat, 5 Dec 2015 11:43: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 286011A8AED for ; Sat, 5 Dec 2015 11:43:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 208B185F20; Sat, 5 Dec 2015 18:08:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id E0FB485F1F; Sat, 5 Dec 2015 18:08:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D3EC385E94 for ; Thu, 3 Dec 2015 00:21:20 +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 o90vyBI58h-B for ; Thu, 3 Dec 2015 00:21:20 +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 1E76985E66 for ; Thu, 3 Dec 2015 00:21:20 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for mfriedl@gmail.com; Thu, 3 Dec 2015 00:21:13 +0000 Date: Thu, 3 Dec 2015 00:21:13 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1631450999-4056@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Markus Friedl , Damien Miller Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-55/Eyvnq5YdoCw0L2BIC" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-55/Eyvnq5YdoCw0L2BIC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable *blush* :) Sounds good. Can you post a writeup of the scheme you implement? It doesn't have to be an Internet-Draft, just something better than reverse= engineering source code. (A spec might not only make things easier for others, but also improve the = implementation. I find that writing things down helps call to mind corner c= ases I would have ignored otherwise.) ----- Original Message ----- From: Markus Friedl=20 Sent: Wednesday, December 2, 2015 08:39 To: ietf-ssh@netbsd.org=20 Cc: Damien Miller=20 Subject: Re: Feedback on draft-ssh-ext-info-00 I'm in the process of implementing draft-rsa-dsa-sha2-256-03 and welcome a way for signaling SHA2 support to the client for userauth, especially since I'm sabotaging protocol extensions with the strict message format checks I've added to OpenSSH before. However, I also agree with Damien that the suggested proposal seems unnecessary complex to me and will try to implement the simpler scheme he suggests. -m > Am 02.12.2015 um 12:35 schrieb Damien Miller : >=20 > Hi, >=20 > Here's some feedback on draft-ssh-ext-info-00. >=20 >> 3.1.=C2=A0 Signaling of Extension Negotiation in KEXINIT > ... >> The indicator name is added without quotes, and MAY be added at any >> position in the name-list, subject to proper separation from other >> names as per name-list conventions. The suggested position is last in >> the list, but implementations MUST recognize these indicator names >> when included at any position. >=20 > IMO it would be best to make it a MUST that the flags may only be > sent as the last element. What rationale is there for putting it > anywhere else? >=20 >> 3.2.=C2=A0 Mechanism Enabling Criteria >=20 > This whole section seems over-complicated. I think a simpler scheme > is: >=20 > If a client or server offers "ext-info-c" or "ext-info-s" respectively, > then it must be prepared to accept a SSH_MSG_EXT_INFO message from the > peer.=20 >=20 > If this message is sent, then it will be the first message after the > initial SSH_MSG_NEWKEYS. >=20 > I.e. make it a simple advertisment that a client or server is willing > to accept a notification message that might optionally be sent. > Don't require both sides to offer acceptance, don't have the messages > offer any sort of negotiation between the client and server (just > statements of extensions/capabilities) and don't "replace" any > messages like SSH_MSG_SERVICE_REQUEST. >=20 > This would yield a much simpler specification IMO. >=20 >> 4. Initially Defined Extensions >> 4.2.=C2=A0 "client-req-ok" >=20 > I don't see the point of this: implementations that don't respond with > SSH_MSG_REQUEST_FAILURE to unknown SSH_MSG_GLOBAL_REQUEST messages are > incompliant with RFC4254 section 4. >=20 > OpenSSH has sent various @openssh.com global requests for years, > so most of the implementations that violate this should have long since > been shaken out. >=20 >> 4.3.=C2=A0 "no-handbrake" >=20 > This could be implemented more elegantly using new channel type names > in SSH_MSG_CHANNEL_OPEN messages rather than the complicated and > inflexible method proposed here (e.g. it's impossible to have one > channel without the "handbrake" and one with normal flow control). >=20 > It would be better to use the extension to signal that the > peer is willing to accept SSH_MSG_CHANNEL_OPEN messages with new channel > type names, and use these to selectively disable flow control. >=20 > Given this, IMO this would be better off being replaced by a generic > "these are the channel types I'm prepared to open" message, which would > be useful even for implementation that don't want to turn off flow contro= l > but which do implement non-standard channel types (e.g. tun@openssh.com). >=20 > -d >=20 = --=-55/Eyvnq5YdoCw0L2BIC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable *blush* :)

Sounds good. Can you post a writ= eup of the scheme you implement?

It doesn't have to be an Internet-D= raft, just something better than reverse engineering source code.

(A= spec might not only make things easier for others, but also improve the im= plementation. I find that writing things down helps call to mind corner cas= es I would have ignored otherwise.)


----- Original Message -----=
From: Markus Friedl
Sent: Wednesday, December 2, 2015 08:39
To: = ietf-ssh@netbsd.org
Cc: Damien Miller
Subject: Re: Feedback on draf= t-ssh-ext-info-00

I'm in the process of implementing draft-rsa-dsa-s= ha2-256-03 and
welcome a way for signaling SHA2 support to the client fo= r userauth,
especially since I'm sabotaging protocol extensions with the= strict
message format checks I've added to OpenSSH before.

Howev= er, I also agree with Damien that the suggested proposal seems
unnecessa= ry complex to me and will try to implement the simpler
scheme he suggest= s.

-m



> Am 02.12.2015 um 12:35 schrieb Damien Mill= er <djm@mindrot.org>:
>
> Hi,
>
> Here's so= me feedback on draft-ssh-ext-info-00.
>
>> 3.1.  Signa= ling of Extension Negotiation in KEXINIT
> ...
>> The indica= tor name is added without quotes, and MAY be added at any
>> posit= ion in the name-list, subject to proper separation from other
>> n= ames as per name-list conventions. The suggested position is last in
>= ;> the list, but implementations MUST recognize these indicator names>> when included at any position.
>
> IMO it would be b= est to make it a MUST that the flags may only be
> sent as the last e= lement. What rationale is there for putting it
> anywhere else?
&g= t;
>> 3.2.  Mechanism Enabling Criteria
>
> Thi= s whole section seems over-complicated. I think a simpler scheme
> is= :
>
> If a client or server offers "ext-info-c" or "ext-info-s= " respectively,
> then it must be prepared to accept a SSH_MSG_EXT_IN= FO message from the
> peer.
>
> If this message is sent= , then it will be the first message after the
> initial SSH_MSG_NEWKE= YS.
>
> I.e. make it a simple advertisment that a client or se= rver is willing
> to accept a notification message that might optiona= lly be sent.
> Don't require both sides to offer acceptance, don't ha= ve the messages
> offer any sort of negotiation between the client an= d server (just
> statements of extensions/capabilities) and don't "re= place" any
> messages like SSH_MSG_SERVICE_REQUEST.
>
> = This would yield a much simpler specification IMO.
>
>> 4. = Initially Defined Extensions
>> 4.2.  "client-req-ok"
>=
> I don't see the point of this: implementations that don't respond= with
> SSH_MSG_REQUEST_FAILURE to unknown SSH_MSG_GLOBAL_REQUEST mes= sages are
> incompliant with RFC4254 section 4.
>
> Open= SSH has sent various @openssh.com global requests for years,
> so mos= t of the implementations that violate this should have long since
> b= een shaken out.
>
>> 4.3.  "no-handbrake"
>
= > This could be implemented more elegantly using new channel type names<= br>> in SSH_MSG_CHANNEL_OPEN messages rather than the complicated and> inflexible method proposed here (e.g. it's impossible to have one
= > channel without the "handbrake" and one with normal flow control).
= >
> It would be better to use the extension to signal that the> peer is willing to accept SSH_MSG_CHANNEL_OPEN messages with new chan= nel
> type names, and use these to selectively disable flow control.<= br>>
> Given this, IMO this would be better off being replaced by= a generic
> "these are the channel types I'm prepared to open" messa= ge, which would
> be useful even for implementation that don't want t= o turn off flow control
> but which do implement non-standard channel= types (e.g. tun@openssh.com).
>
> -d
>

<= /html>= --=-55/Eyvnq5YdoCw0L2BIC-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 11:43:33 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B621A8AED for ; Sat, 5 Dec 2015 11:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.379 X-Spam-Level: ** X-Spam-Status: No, score=2.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fJ0kYUjw7qc for ; Sat, 5 Dec 2015 11:43:31 -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 681241A8AF0 for ; Sat, 5 Dec 2015 11:43:29 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id F3FE685F12; Sat, 5 Dec 2015 18:08:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id EC6BE85F1C; Sat, 5 Dec 2015 18:07:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 98C1E85E9C for ; Thu, 3 Dec 2015 09:53:59 +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 DfHuUzunBcRV for ; Thu, 3 Dec 2015 09:53:58 +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 A9DE685E54 for ; Thu, 3 Dec 2015 09:53:58 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for brynosaurus@gmail.com; Thu, 3 Dec 2015 09:53:52 +0000 Date: Thu, 3 Dec 2015 09:53:52 +0000 Subject: Re: SSH v3? X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <1665779424-2152@skroderider.denisbider.com> X-Priority: 3 Importance: Normal In-Reply-To: <566008DF.3030902@gmail.com> MIME-Version: 1.0 From: denis bider To: Bryan A Ford , =?UTF-8?q?Niels_M=C3=B6ller?= , Markus Friedl , Damien Miller Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-HZERV3osSwtvrl9LKTVS" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-HZERV3osSwtvrl9LKTVS Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On the Linux side, perhaps OpenSSH might indeed have an interest in Minion,= as an improvement to its existing capabilities of layer 2 and layer 3 tunn= eling? On the Windows side, it seems a good bet might be Skype. It's owned by Micr= osoft, is a major application, and experiences TCP-related problems that Mi= nion would solve. I'm not sure how hard it might be to attract the attention of some Skype de= velopers, but sometimes it can be as easy as Twitter. Bryan A Ford , 12/3/2015 9:18 AM: On 12/3/15 3:46 AM, denis bider wrote:=20 > Hey Bryan -=20 > =20 > thank you for sharing this, I was not previously aware of Minion.=20 > =20 > The main issue I see is that Minion /does/ in fact seem to require=20 > modification at the OS level. Even though the changes needed might be=20 > small, this won't fly unless Linux and Windows both decide to support it.= =20 =20 Yes, that's indeed the catch. =C2=A0And even though the kernel change=20 required is only like a pretty trivial hundred lines or so (can't=20 remember precisely), we have the chicken-and-egg problem that Linux and=20 Windows kernel devs don't want to upstream it until a "major" user-space=20 application wants to use it, but "major" user-space applications don't=20 want to adopt it until it's supported in mainstream kernels. :/=20 =20 But if (say) OpenSSH expressed serious interest in adopting Minion, I=20 think that could easily break this chicken-and-egg deadlock. =C2=A0And it=20 shouldn't constitute any "risk" that I can see, since Minion is=20 backward-compatible and incrementally deployable in pretty much all the=20 ways I can envision caring about, including in particular:=20 =20 - (a) if the user-space SSH implementation supports it but the kernel=20 patch isn't present, nothing bad happens other than that endpoint=20 doesn't get the performance benefit of being able to receive packets=20 out-of-order. =C2=A0The SSH implementation basically just calls a setsockop= t=20 that the kernel doesn't support, the kernel returns an error, and the=20 SSH implementation returns to in-order business as usual.=20 =20 - (b) if one SSH endpoint (and its kernel) supports Minion but the other=20 endpoint (or its kernel) doesn't, you still get out-of-order performance=20 benefits for traffic flowing in one direction but just not for traffic=20 on the same connection flowing in the other direction.=20 =20 > Most SSH implementations I'm aware of are user-mode implementations, by=20 > organizations and/or volunteers who are not familiar with, and do not=20 > have access to modify, the TCP stack on systems where their SSH=20 > implementation runs. This is certainly true for me, I can't change the=20 > TCP implementation in Windows.=20 =20 I wouldn't suggest it to be the task of SSH developers to implement the=20 Windows/Linux/FoozleOS kernel patches required to support Minion, and=20 there's no reason we should expect every mainstream OS to incorporate=20 the kernel patch any time soon, but you still get incremental benefits=20 as soon as even one OS and one user-space application (e.g., OpenSSH)=20 supports it. =C2=A0And if the SSH community showed enough interest in=20 adopting Minion to consider supporting it in the (next) protocol spec=20 and prototyping it (even experimentally) in at least one SSH=20 implementation, that would provide a much stronger basis on which to=20 argue for the Minion kernel enhancement to be adopted in kernels,=20 breaking the chicken-and-egg problem.=20 =20 > Without underlying platform support, it seems to me the best that SSH=20 > can do is to either (1) implement support for UDP as an ancillary=20 > transport for latency-sensitive traffic, or to (2) migrate wholesale to U= DP.=20 > =20 > My "EST" suggestion rebuilds the whole protocol on top of UDP. But=20 > perhaps, implementing support for UDP as an ancillary transport would be=20 > a more compatible fit with current SSH usage. And also, as you point out=20 > in your paper, it would be a better fit for connections where UDP is not=20 > available due to firewall/routing issues.=20 =20 I'm definitely not against designing protocols to be operable atop UDP=20 as well; there are certainly tradeoffs each way.=20 =20 > If you can get Windows + Linux to implement uTCP though, that would have=20 > the benefit of avoiding even the firewall/routing issues still faced by U= DP.=20 =20 Exactly, that's one such tradeoff. =C2=A0Another is power efficiency for=20 mobile devices: you can keep a mostly-idle TCP connection open for a lot=20 longer than a mostly-idle UDP connection before typical middleboxes=20 silently time-out and forget the state. =C2=A0(e.g., the BEHAVE spec requir= es=20 TCP timeouts to be on the order of hours, as I recall, whereas UDP=20 middlebox-state timeouts are typically on the order of minutes.)=20 =20 Cheers=20 Bryan=20 =20 = --=-HZERV3osSwtvrl9LKTVS Content-Type: text/html; charset="utf-8" On the Linux side, perhaps OpenSSH might indeed have an interest in Minion, as an improvement to its existing capabilities of layer 2 and layer 3 tunneling?

On the Windows side, it seems a good bet might be Skype. It's owned by Microsoft, is a major application, and experiences TCP-related problems that Minion would solve.

I'm not sure how hard it might be to attract the attention of some Skype developers, but sometimes it can be as easy as Twitter.


Bryan A Ford <brynosaurus@gmail.com> , 12/3/2015 9:18 AM:
On 12/3/15 3:46 AM, denis bider wrote:
> Hey Bryan -
>
> thank you for sharing this, I was not previously aware of Minion.
>
> The main issue I see is that Minion /does/ in fact seem to require
> modification at the OS level. Even though the changes needed might be
> small, this won't fly unless Linux and Windows both decide to support it.

Yes, that's indeed the catch.  And even though the kernel change
required is only like a pretty trivial hundred lines or so (can't
remember precisely), we have the chicken-and-egg problem that Linux and
Windows kernel devs don't want to upstream it until a "major" user-space
application wants to use it, but "major" user-space applications don't
want to adopt it until it's supported in mainstream kernels. :/

But if (say) OpenSSH expressed serious interest in adopting Minion, I
think that could easily break this chicken-and-egg deadlock.  And it
shouldn't constitute any "risk" that I can see, since Minion is
backward-compatible and incrementally deployable in pretty much all the
ways I can envision caring about, including in particular:

- (a) if the user-space SSH implementation supports it but the kernel
patch isn't present, nothing bad happens other than that endpoint
doesn't get the performance benefit of being able to receive packets
out-of-order.  The SSH implementation basically just calls a setsockopt
that the kernel doesn't support, the kernel returns an error, and the
SSH implementation returns to in-order business as usual.

- (b) if one SSH endpoint (and its kernel) supports Minion but the other
endpoint (or its kernel) doesn't, you still get out-of-order performance
benefits for traffic flowing in one direction but just not for traffic
on the same connection flowing in the other direction.

> Most SSH implementations I'm aware of are user-mode implementations, by
> organizations and/or volunteers who are not familiar with, and do not
> have access to modify, the TCP stack on systems where their SSH
> implementation runs. This is certainly true for me, I can't change the
> TCP implementation in Windows.

I wouldn't suggest it to be the task of SSH developers to implement the
Windows/Linux/FoozleOS kernel patches required to support Minion, and
there's no reason we should expect every mainstream OS to incorporate
the kernel patch any time soon, but you still get incremental benefits
as soon as even one OS and one user-space application (e.g., OpenSSH)
supports it.  And if the SSH community showed enough interest in
adopting Minion to consider supporting it in the (next) protocol spec
and prototyping it (even experimentally) in at least one SSH
implementation, that would provide a much stronger basis on which to
argue for the Minion kernel enhancement to be adopted in kernels,
breaking the chicken-and-egg problem.

> Without underlying platform support, it seems to me the best that SSH
> can do is to either (1) implement support for UDP as an ancillary
> transport for latency-sensitive traffic, or to (2) migrate wholesale to UDP.
>
> My "EST" suggestion rebuilds the whole protocol on top of UDP. But
> perhaps, implementing support for UDP as an ancillary transport would be
> a more compatible fit with current SSH usage. And also, as you point out
> in your paper, it would be a better fit for connections where UDP is not
> available due to firewall/routing issues.

I'm definitely not against designing protocols to be operable atop UDP
as well; there are certainly tradeoffs each way.

> If you can get Windows + Linux to implement uTCP though, that would have
> the benefit of avoiding even the firewall/routing issues still faced by UDP.

Exactly, that's one such tradeoff.  Another is power efficiency for
mobile devices: you can keep a mostly-idle TCP connection open for a lot
longer than a mostly-idle UDP connection before typical middleboxes
silently time-out and forget the state.  (e.g., the BEHAVE spec requires
TCP timeouts to be on the order of hours, as I recall, whereas UDP
middlebox-state timeouts are typically on the order of minutes.)

Cheers
Bryan

--=-HZERV3osSwtvrl9LKTVS-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 12:32:20 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4C21A909E for ; Sat, 5 Dec 2015 12:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxXpEsQ4rt8K for ; Sat, 5 Dec 2015 12:32: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 67EA71A0363 for ; Sat, 5 Dec 2015 12:32:19 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id BBBA285EF0; Sat, 5 Dec 2015 20:32:17 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 6F8F985EE7; Sat, 5 Dec 2015 20:32:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E2C2C85EB6 for ; Thu, 3 Dec 2015 04:06:08 +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 Fn7ooqtixdIE for ; Thu, 3 Dec 2015 04:06:08 +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 D682485E93 for ; Thu, 3 Dec 2015 04:06:07 +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 tB345xni005356; Thu, 3 Dec 2015 14:06:00 +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 tB345xqS043774 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Dec 2015 14:05:59 +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 tB345wEK015629; Thu, 3 Dec 2015 14:05:59 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 84F3AA4F2E; Thu, 3 Dec 2015 15:05:58 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 7CACDA4F07; Thu, 3 Dec 2015 15:05:58 +1100 (AEDT) Date: Thu, 3 Dec 2015 15:05:58 +1100 (AEDT) From: Damien Miller To: denis bider cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 In-Reply-To: <1642890958-3540@skroderider.denisbider.com> Message-ID: References: <1642890958-3540@skroderider.denisbider.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="15775414878208-1821183572-1449115558=:12629" X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1449115560 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. --15775414878208-1821183572-1449115558=:12629 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Thu, 3 Dec 2015, denis bider wrote: > > If there's a functioning extension mechanism, > > then why would there be competition? > > To extend other aspects of SSH that EXT_INFO cannot. This could be to change > some aspect of algorithm negotiation, for example. > > For instance, there has been a problem in how AEAD is negotiated. Besides > what OpenSSH did - implementing a private algorithm for AES-GCM - another > possible solution could be an extension where both client and server put > something in their key exchange algorithms field. If both client and server > do this, then the result of MAC negotiation is ignored if an AEAD encryption > algorithm is negotiated. > > But why do you even feel the need to call this out? Is it any harder to > call: > >     is_in_namelist(name, namelist) > > instead of: > >     is_at_end_of_namelist(name, namelist) I'm suggesting you specify what is sent, not how implementations test for it. The benefit is that ~ a paragraph of fairly useless verbiage in your spec disappears. > > IIRC I've heard of at least one server that doesn't > > implement ssh-userauth. > > This is possible with EXT_INFO also. Send an extension name and value > informing the client of what you implement. No need to waste a round-trip > for 99.999% of other users. I'll repeat my opinion: an extension mechanism is not the place to fundamentally retcon parts of the protocol. It breaks orthagonality and turns implementations into spaghetti. Perhaps you want a "no-service-requests" extension instead? -d --15775414878208-1821183572-1449115558=:12629-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 15:23:31 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0CE1A930A for ; Sat, 5 Dec 2015 15:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.409 X-Spam-Level: * X-Spam-Status: No, score=1.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yFX8XTJPXGd for ; Sat, 5 Dec 2015 15:23: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 294F21A9308 for ; Sat, 5 Dec 2015 15:23:30 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A920A85F02; Sat, 5 Dec 2015 23:00:37 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 32FB185EC6; Sat, 5 Dec 2015 23:00:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 80B3885EE4 for ; Sat, 5 Dec 2015 21:03:15 +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 lfHNDio-bqA5 for ; Sat, 5 Dec 2015 21:03:15 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::704]) by mail.netbsd.org (Postfix) with ESMTP id 42EC485EC6 for ; Sat, 5 Dec 2015 21:03:10 +0000 (UTC) Received: from CY1PR05MB1947.namprd05.prod.outlook.com (10.162.216.17) by CY1PR05MB1947.namprd05.prod.outlook.com (10.162.216.17) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sat, 5 Dec 2015 21:03:07 +0000 Received: from CY1PR05MB1947.namprd05.prod.outlook.com ([10.162.216.17]) by CY1PR05MB1947.namprd05.prod.outlook.com ([10.162.216.17]) with mapi id 15.01.0331.023; Sat, 5 Dec 2015 21:03:07 +0000 From: Mark Baushke To: "ietf-ssh@NetBSD.org" Subject: Fwd: [tc-ssh] updated SSH EP for review Thread-Topic: [tc-ssh] updated SSH EP for review Thread-Index: AQHRLGPWmkBed20yxE+FTlKuyG2emQ== Date: Sat, 5 Dec 2015 21:03:07 +0000 Message-ID: <82265927-7DDF-4FC4-8E50-F5305D371336@juniper.net> References: <4389C2DD8202461999FFA3A07E14E69E.MAI@cfdme01.cfdynamics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mdb@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1;CY1PR05MB1947;5:DTDx59VDR7is5SB3h/z/oW/IvViTRPNd+NfkvLOXo0DDCVIRZi2Jeu6vTO96XYbV0G8ROrqVy5Meh+D3NyWteykm/vbc2h+mORckXvnRcygpskebQOYWulHEVk9CLPLL8wXOF7Rge0p8IWaRfCtOtQ==;24:CuEpfXnMJKR6ztcAyL2U0plvOH6u7v7AI4Kt+71z89pkMuts4AGCD0jpdIYtJZ0kkqpEivW+hSpmqtYSRekgJ8/gw58IXicPgpT9uSZEnhU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB1947; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046);SRVR:CY1PR05MB1947;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB1947; x-forefront-prvs: 07817FCC2D x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(377454003)(189002)(2473001)(199003)(30584003)(19580395003)(19580405001)(10400500002)(36756003)(7110500001)(40100003)(97736004)(189998001)(5001960100002)(122556002)(107886002)(110136002)(5002640100001)(16236675004)(87936001)(83716003)(2420400006)(586003)(3846002)(82746002)(102836003)(6116002)(1096002)(1220700001)(450100001)(92566002)(54356999)(76176999)(66066001)(2900100001)(101416001)(10710500006)(16601075003)(86362001)(5008740100001)(5004730100002)(106356001)(105586002)(106116001)(99286002)(50986999)(77096005)(15975445007)(19617315012)(2351001)(11100500001)(99936001)(33656002)(2501003)(5890100001)(81156007)(24704002)(42262002)(104396002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR05MB1947;H:CY1PR05MB1947.namprd05.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/mixed; boundary="_005_822659277DDF4FC48E50F5305D371336junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2015 21:03:07.1698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1947 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --_005_822659277DDF4FC48E50F5305D371336junipernet_ Content-Type: multipart/alternative; boundary="_000_822659277DDF4FC48E50F5305D371336junipernet_" --_000_822659277DDF4FC48E50F5305D371336junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, Those of you who need to worry about Common Criteria evaluations with regar= d to SSH via NIAP may already know about the Technical Committee on Secure = Shell for creation of an Extended Package for SSH (SSH EP). The National Information Assurance Partnership/Common Criteria Evaluati= on and Validation Scheme (NIAP/CCEVS) is inviting industry, government, end= users, academic institutions, and labs with relevant technology expertise = and research focus to participate in the following Technical Communities (T= Cs). If you are interested in joining a technical community and participati= ng in the development of Protection Profiles for these technologies, please= contact NIAP/CCEVS at: Secure Shell (SSH) tc-ssh-staff@niap-ccevs.org It is kind of late, but if you are interested in sending them comments by T= uesday, 08 December 2015 COB (I believe it is US Eastern Time), you still h= ave a little time. Begin forwarded message: From: > Subject: [tc-ssh] updated SSH EP for review Date: December 1, 2015 at 10:12:09 AM PST To: > Cc: > Reply-To: > TC members, Please review the updated draft SSH EP (http://common-criteria.rhcloud.com/= ssh/output/ssh-release.html) and provide comments to tc-ssh-staff@niap-ccevs.org and/o= r tc-ssh@niap-ccevs.org by COB Tuesday, 08 December 2015 using the attached= comment matrix. Thanks Dianne Hale National Information Assurance Partnership (NIAP) 410-854-2413 (office) /410-854-6615 (fax) Website: www.niap-ccevs.org --_000_822659277DDF4FC48E50F5305D371336junipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Folks,

Those of you who need to worry about Common Criteria evalua= tions with regard to SSH via NIAP may already know about the Technical Comm= ittee on Secure Shell for creation of an Extended Package for SSH (SSH EP).=

    The National Information A= ssurance Partnership/Common Criteria Evaluat= ion and Validation Scheme (NIAP/CCEVS) is inviting industry, government, end users, academic institutions, and labs with r= elevant technology expertise and research focus to participate in the following <= span style=3D"font-family: 'courier new', courier, arial, helvetica, sans-s= erif;" class=3D"">Technical Communities (TCs). If you are interested in joi= ning a technical community and participating in the development of Protection <= span style=3D"font-family: 'courier new', courier, arial, helvetica, sans-s= erif;" class=3D"">Profiles for these technologies, please contact NIAP/CCEV= S at:

   Secure Shell (SSH) tc-ssh-staff@niap-ccevs.org

It is kind of late, but if you are interested in sending them comments= by Tuesday, 08 December 2015 COB (I believe it is US Eastern Time), you st= ill have a little time.

Begin forwarded message:

From: <dmhale1@niap-ccevs.org>
Subject: [tc-ssh] updated SSH EP f= or review
Date: December 1, 2015 at 10:12:09 AM PST
To: <tc-ssh@niap-ccevs.org>
Cc: <tc-ssh-staff@niap-ccevs.org>
Reply-To: <tc-ssh@niap-ccevs.org>

TC members,

Please review the updated draft SSH EP (http:/= /common-criteria.rhcloud.com/ssh/output/ssh-release.html) and provide c= omments to tc-ssh-staff@niap-ccevs.org and/or tc-ssh@niap-ccevs.org by COB Tuesday, 08 December 2015 using the a= ttached comment matrix.



Thanks
Dianne Hale

National Information Assurance Partnership (NIAP)
410-854-2413 (office) /410-854-6615 (fax)
Website: www.niap-ccevs.or= g
--_000_822659277DDF4FC48E50F5305D371336junipernet_-- --_005_822659277DDF4FC48E50F5305D371336junipernet_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Comment Matrix - SSH EP.xlsx" Content-Description: Comment Matrix - SSH EP.xlsx Content-Disposition: attachment; filename="Comment Matrix - SSH EP.xlsx"; size=29574; creation-date="Sat, 05 Dec 2015 21:03:07 GMT"; modification-date="Sat, 05 Dec 2015 21:03:07 GMT" Content-ID: <51D46C1ECA464F47A9B6C7853C582485@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAhjEY6dgEAAIwFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE VMlqwzAQvRf6D0bXYivJoZQSJ4cuxzaQ9AMUa2yL2JLQTNLk7zt2FkrIgmmgFxtLmreMNW84XtdV tIKAxtlU9JOeiMBmThtbpOJr9h4/iQhJWa0qZyEVG0AxHt3fDWcbDxhxtcVUlET+WUrMSqgVJs6D 5Z3chVoRf4ZCepUtVAFy0Os9ysxZAksxNRhiNHyFXC0rit7WvLxVMjdWRC/bcw1VKpT3lckUsVC5 svqIJHZ5bjLQLlvWDJ2gD6A0lgBUV4kPhhnDFIjYGAp5kjNAhd1Id64SrmyFYWk8PrD1MwzNznlX u7pP/h3BaIgmKtCHqtm7XFfy24XF3LlFchmka2vaFiW1Mnav+wJ/exhl++rfWEjjrwXuqGPwTzqI 7zrI9vn3VrQwV4wjbSrAG7vdgl5jLlUAPSWeouLmAn5jX9LBoz0JziOnR4DuXdiPalMdewaCQAYO w3rq0h8YOXq6Ex4FEjTZpkGf4JZtlo5+AAAA//8DAFBLAwQUAAYACAAAACEAtVUwI/UAAABMAgAA CwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T76m5ICKGlu0xIuyFUHsAk7h+1jaMk QPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4rZ9WD6BiImdpFMcajhxhV93ebF94 pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl3JTlPYa/HlAtPNXBaggHeweqPvo8 +bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc0xHJ+yJjA54m2lxP9P+2OHEiS4nQ SODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD//wMAUEsDBBQABgAIAAAAIQBKqaZh +gAAAEcDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC8ks1qxDAMhO+FvoPRvXGS/lDKOnsphb222wcwsRKHTWxjqT95+5qU 7jawpJfQoyQ08zHMZvs59OIdI3XeKSiyHAS62pvOtQpe909X9yCItTO69w4VjEiwrS4vNs/Ya05P ZLtAIqk4UmCZw4OUVFscNGU+oEuXxsdBcxpjK4OuD7pFWeb5nYy/NaCaaYqdURB35hrEfgzJ+W9t 3zRdjY++fhvQ8RkLyYkLk6COLbKCafxeFlkCBXmeoVyT4cPHA1lEPnEcVySnS7kEU/wzzGIyt2vC kNURzQvHVD46pTNbLyVzsyoMj33q+rErNM0/9nJW/+oLAAD//wMAUEsDBBQABgAIAAAAIQBJLmVQ xgEAAAUEAAAPAAAAeGwvd29ya2Jvb2sueG1spJPLbtswEEX3BfoPLCEgq1oP201jWAqSNm29KYw2 TZYCK44sInwIJB0pf9+RFNdEiqCvFTlD8MydO+T6vFeS3IN1wuicprOEEtCV4ULvcvrt+sPrt5Q4 zzRn0mjI6QM4el68fLHujL37bswdQYB2OW28b1dx7KoGFHMz04LGk9pYxTyGdhe71gLjrgHwSsZZ kryJFROaToSV/ROGqWtRwXtT7RVoP0EsSOZRvmtE62ixroWEm6kjwtr2M1Oou5eUSOb8FRceeE6X GJoOjokFJXbfXu6FxNOzeTKncfGzya3FYOj2RkDnjvkhJP2t0Nx0OUXvHoJ9N6ZvBfcNOns2z/B8 yn0CsWs8JhfZfDnUiQP2aBDWGFeiR/XvjFLCewDyBe6xJs5ksHGDUlPUvRK4sRueDqzw3kY7b/fV 6E5wJwvuZGP9Q1EOtdDAB89QQhA9CrnqK5Dl4JLf6HJrhfblBY61TGlx8lTlyavoIkpX0cfodLGO A9hfkTNahG08Mi+jLP0n5rXwEtxzelHt8rfYspdazY7ND0+pYvLrYSTJs178Nxpt/sWMJ9DQaJwh Cqu2lgzL+Fyy5Wk2vbnDDy5+AAAA//8DAFBLAwQUAAYACAAAACEA3kYnoEwIAACjWgAADQAAAHhs L3N0eWxlcy54bWzkXFuP2jgUfl9p/0OUdxrCAB1GQNXpFKlSt1ptZ6V9DRCYqLmgJLTMrva/77ET E4fEjm1yozsvQww5/s453zm+e/7u5LnadzuMnMBf6Oaboa7Z/ibYOv5+of/5vBrc61oUW/7WcgPf XuivdqS/W/76yzyKX13764ttxxqI8KOF/hLHhwfDiDYvtmdFb4KD7cM3uyD0rBgew70RHULb2kbo Jc81RsPh1PAsx9cTCQ/eRkSIZ4XfjofBJvAOVuysHdeJX7EsXfM2D5/2fhBaaxegnsyxtSGy8UNB vOdswiAKdvEbEGcEu52zsYsoZ8bMAEnL+S7w40jbBEc/BlvNQDaq4uGbH/zwV+g7KE1/tpxHf2vf LRdKhrqxnPuWZyfP70PHclHRzvIc9zUpHKECA8lPalnO11CQF7EJ3CDUHH9rn+ztVXIdWvYUVX0h e3yPCpUw52SPS2SbWNdmZCviPtsZQ7uwhVmTLWpSW51NOc+YJZ6Z3il5nVhvpvT2muaimo1yAC69 V5O9MJOVSEvQKeaBnNfUlMmJuM7EisFLbNABRXBSjSCrOq57zt0TlKWhYDmHNiS2Q38FD1r6+fn1 AK2HD80dIrSR/K7i1/vQejVHE/EXosB1tgjF/kM+rY/fIiHry+IR9ptBwRWFxq4Jc7pQ0x1ODbXW hN1eqGiEW57SirDRwWnrINxC34Q0uWBgUracu/YuBkuFzv4F/Y+DA7JbEMfQki/nW8faB77lwkcj kcJ7E7o40JtZ6J69dY4eVHKRRXATYEAVCjWIycZqYC3Efq+G5cJOYlUlNhU3qZjUTOGz28ReFIUj Jg2xKCUReSF+gS4pgwIZavLrOilDZPIQ/AyA+TZrx8Z8DFdbmedCKnZFPC5LeF7V/yO9+A4ukoxn toY8BpkP4xBhQS8AE6B821Iku2hw4FG0YRarKrPKuRURqENMNqWG2AslYMiLPHKJxjcolmML3wkN gyGK8UFcYUJSAc9yLYUlX8fM0B1CJlXzobbnjl4FYa/AiHlKNCeISavB73xilQQi/4Xb1a8PZCJe l8yN9bokV3m4Xy/01WqI//AsSAnnKt6oSKTFKkpYV1EFj3bpNAHMOmxs1/2KJgT+2p2nHtC8/mmn +Udv5cWfYPodFkrQdD35CPNH6cdktiF5ALIYtLRENi12qCZYO+3ONcjDOr+tWYeD+4qWLtDKRfL0 iOdc0DOgl5UNQgiy2mWPapB9B15LXQXiMldV4EbTg5IWYtVUocV1NQEpM53g4WpfTBj2Au14shW0 YNU0brKmJu2Vk61orySG3rvO3vfsJEiXc4s8ai9B6PwNwYuWGVG+xYn3tGOHLWXkHDxFI7cFr4LJ LLbVDW+aBQP4Mws0sKpKMEjA24Dz7VBHC/Wxs0HuJiWxfYr/CGJYCUfr9zOw1I/QOjxDaZrBDR4f WBpB+U+m0dub1Qg2YOzKexdcH2XNeC08k2EVbIwoRQyatM4q6CNWZkUWXrTBI+1mJTbMd5RqSDsk irO4RnilQrg78LjFoVJSbdBhpbxpw1+NHWEsJbmp2JVsPUqZGnRBexIIdaQZRfZwRjvCMfbl6K3t cIW3vGXjhdrTxtXsZSlUFXnCjYqMH1HElIZS80RszJCK0DkcZOWb+tnOqqk9nSpqylioYK+KTshV ssXDRwF4wdHMYaFM8LGcLV6b9CAU9pCVx3uhztoTJ2lm8v0tcAZ3lARjh9L8hBRpuINYlqCU4bY0 CXFNl5Bl6uapoWJp4eDhEZkZxoXAujBsFQ9M8Pct8ZaNtxviKtu3n2RlmlcKbmNsZcVST5MsE243 XJWaMmBhlyJC1lGSGLmqJFlqjhIArvHqVLrU1sPGl44y6B5kcM2W5tglGwkWF8zmJ7XLyCDFY7at m5+/LgNf1WAwbd385HQZ3JpsXTGgWjGWThvOGmxuVAwue4A3l+bMGyAHk9i3Zut+4mWZdwRf9LAJ ZMHtpgGUy3KAsXTI1E9Loz5Fj+DKmZq1F6Gnpu4XXDlT31gXumtToyP2aLMNPh/JnRlEveROA5Ce 6sVXAwjirpkR0PNl7RSs20ScqrqePBTnTddIVWlTc3vD8WXLTRttENVhXDMNlwyylo1WnKAWjwBW J7FoRMb4kcOdq2VXjE1lXCKNpX69mFO2MnrAyKi0oSsued76HoiKMaDSvGf5uqNUJ45FpBuDW4xv xuGDihikc08N1mXRuwnrls3FVbU5XePrLVVVjMkKpSa4WSe+tshYi7PbMqYUWGrYA+t02eJM8+sF xRxFSmRaYRb+5ueICdps5wwpkcGPJrNLuxGj5icHCd5MA5G94f1DLEX4LuGXpT458KyjD52whfBH iu8Z3YHgWb4ZdbhJvKqrQe3Oyy1gww1kTa82EBNnIUpKKo0+Rj2k9DwuNUuR06C4BN/SWEVYC9Qz SZWgOil56rS0waSKJhQ++ChO7ZrGT6lJq1DSe01zLX6fI5A+mZEjcB9A4/PscIKdOiafOyR/Pu6u odsyF/oXdBjCpVLH+ui4seOfj69nB+RB5vaUHbnHl13G6C5ffBj/XAvQbWvvrKMbP5+/XOjZ59/w JX6QD9Jf/e58D2IsYqFnnz+jewNNfAUhHJb8HMEtcPBfO4bOQv/n4+Pb2dPH1WhwP3y8H4zv7Mlg Nnl8GkzGHx6fnlaz4Wj44V/QCV18/ACXAF9xsTC+ABmmz83xQ+TC9cNhqmwK/mtWttCphwQ+PtoG sGnss9F0+H5iDgeru6E5GE+t+8H99G4yWE3M0dN0/PhxsppQ2Cdq2M2hYZrJ7c0I/OQhdjzbdXzi K+IhuhScBI8cJQziCSM63y69/A8AAP//AwBQSwMEFAAGAAgAAAAhADttMkvBAAAAQgEAACMAAAB4 bC93b3Jrc2hlZXRzL19yZWxzL3NoZWV0MS54bWwucmVsc4SPwYrCMBRF9wP+Q3h7k9aFDENTNyK4 VecDYvraBtuXkPcU/XuzHGXA5eVwz+U2m/s8qRtmDpEs1LoCheRjF2iw8HvaLb9BsTjq3BQJLTyQ YdMuvpoDTk5KiceQWBULsYVRJP0Yw37E2bGOCamQPubZSYl5MMn5ixvQrKpqbfJfB7QvTrXvLOR9 V4M6PVJZ/uyOfR88bqO/zkjyz4RJOZBgPqJIOchF7fKAYkHrd/aea30OBKZtzMvz9gkAAP//AwBQ SwMEFAAGAAgAAAAhAO84zqv/BgAAfh4AABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0Mi54bWysmdty 2kgQhu+3at9BpfsAEggwZZyKEOjgE7XZbK5lMYDKEqIkEcd5+u05SKNRA8F2chHbn0Y9f/fMdDfM 9eefaaL9IHkRZ7upbnR6ukZ2UbaKd5up/u3fxaexrhVluFuFSbYjU/2VFPrnm7//un7J8udiS0ip gYVdMdW3ZbmfdLtFtCVpWHSyPdnBk3WWp2EJf+abbrHPSbhiL6VJ1+z1ht00jHc6tzDJL7GRrddx RJwsOqRkV3IjOUnCEvQX23hfVNbS6BJzaZg/H/afoizdg4mnOInLV2ZU19Jo4m92WR4+JeD3T2MQ RpVt9gcyn8ZRnhXZuuyAuS4Xin2+6l51wdLN9SoGD2jYtZysp/oXY7Lsm3r35poF6L+YvBSN37Vf WZZ+jcKEPNCIJrBWPVgrugpPWfZMh/urqd6jBrrIwoKtwjLXVmQdHpLyn+zFI/FmW4IZszOywDHq 32T16pAigsCCpQ4TE2UJyID/tTSmGwTiEv5kP1/iVbmd6v1BZ2xZg+GYWokORZml3/kTg2qp3zTF m/BTvGkYMMfYMqyhCa8W5SuNc79/zEqXy2B+OWEZ3lzn2YsGGwb0FPuQbj9jYgx1jXpkgtlaS+3m aReFKRCGTBn9zsWWwFeq6Au1M9Wv4NyAlgIW+sdN77r7A5YlEkPseggNEH3J46Q/YCGjxEckaJIu iK6DACFTlMP0/Vo2X3oWKRacAVtuvlC/C07lEp0AXLpquDRuuVQPofuvKW5wRBwY4gJa4gxw8W3K qHXwdljHzRZkVJOZIOOaOIjMEVkg4iLiIeIjEiByi8gdIveIPCDyiMiySZRFoOereUwgZoP6oDUW 4WgWqHYBNQLvQdapN/ZVaxeIIfzk0208E4TnEkocROaILBBxEfEQ8REJELlF5A6Re0QeEHlEZNkk SvAhLbWD3z92As4GnxqB4MsEYQti1dt6Jog8DA4ic0QWiLiIeIj4iASI3CJyh8g9Ig+IPCKybBIl 1qMLY80qn3W68lV7ntqD3ElLbb3pjXY6l4OqfD7jaCCzkCOIXJw5IgtEXEQ8RHxEAkRuEblD5B6R B0QeEVk2ibIUtHFs5xxYt+OJf/SGkl2tDZ0AjkSz0BpGKyGJMc3KZZj1GEUvjLlYr2nRvuDsgaXm prqlbJx+PTOr+rYYA02M3FyDeoyizgBDf1Ies9fWZ9Vzc33VIEXgsB6kCmy3YnRtTq33BfEzqD0Q CC2BDM6onlsIFIMUgbI1UQXS/unSDXmJQN6PWf06Adu0f6GaoQ5LzbJGqnKOdG1H43V2lxm871JE CNQUYcqUpYqgHcOfjAnvQJRdb7bPpMEHDZqH0jxxKA1aVS8ReD5KvDarstqHkU0Fi9fcS+ap00gL 0Mdl8TJmyRJu088w9OAwpC4VTbT1lDQbnDhf5yPB07UF09Q71ETHXuR0iJocdOrYK2n+3bJ4nrZk vbQNgVjbrkZCydTvnlIk36vG8eVoyD5EswQzM9AoB6M5Ri5GHkY+RoGCFL9NpQRwv4fHunje3Pym PjFrU30oe3W7QrJZn1VIjnIwmmPkYuRh5GMUKEj1nyb71gn4gP+8dCj+C9T0H41yTITmGLkYeRj5 GAUKUv1XCtiH15/XKsV/gZr+o1GOidAcIxcjDyMfo0BBqv9KxRT+QyI73lH+rj8zeZkcNj5RVUjm 41mF5CgHozlGboVkRvMw8jEKFKT6rxRr7r8JWRL5f7YCmLz6DuXXIXaFZCqcVUiOcjCaY+QKNJI5 1MPIxyhQkOq30gO822/eAyh+C9T0G41y2JeTkChlKOYYuQIpfnNbDeTjUYGCVL9pL9DKd+9Yb95R NFTYpkAyqc8qJJfNwWiOkYuRh5GPUaAg1e8jnc47/OZNjOK3QE2/0SjHRGiOkYuRh5GPUaAg1e8j rdSb/bbpG9AajmQSX1RIflJxKyTX28PIxyhQkCr/SFtGR78pPdkmb7gU+QI15QvUlI+QX9mSowIF KfL7NLF89LTZzApEv7HFKiRVOBjNMVpg5GLkYeRjFChI9Zu2My2/R1Aj3rZsfd4UwR1Q+/t/uNPC 9o9V7XNVy2ZWIK6snHL9/JaL3waxi6FlnpUkoheBWkES+O0ui57JakaSBA4EFcjot12iclCcknxD 2EAtyg70+qsPFzc1FTd05sRmp6rN+xOb7c02H01srrd+AFdp+3BD7sN8E+8KLSFrmKrHvobM+XUc /6PM9kzxU1bCfRq/vIGrUwLfn/c6lmGMe5b8B56tM3D9xENwj875lZSHvVbQG8SpPobStI7zolzC k4dD+sRe1rUsj+Hyj12mTvUEbn1h/J7AtRo8+JXBk8TZxxAc+n0oXBqXMZirCUy0ZSIXTI0WJvFm 9z0ut8Ld6nayvjm++R8AAP//AwBQSwMEFAAGAAgAAAAhALAR/MOEBwAAQSAAABMAAAB4bC90aGVt ZS90aGVtZTEueG1s7FlPbxtFFL8j8R1Ge29jJ05qR3Wq2LEbaNNGsVvU43h31jvN7M4yM07iG2qP SEiIgrggceOAgEqtxKV8mkARFKlfgTczu+udeE2SNgIBycGZnf3Ne2/e/5m9fuMoZuiACEl50vbq V2seIonPA5qM2969Yf9K00NS4STAjCek7U2J9G5svPvOdbyuIhITBOsTuY7bXqRUur60JH2YxvIq T0kC70IuYqzgUYyXAoEPgW7MlpZrtbWlGNPEQwmOgezdMKQ+QUNN0tvIifcYPCZK6gmfiYEmTZwV Bhvs1zVCTmWXCXSAWdsDPgE/HJIj5SGGpYIXba9m/ryljetLeD1bxNSCtaV1ffOXrcsWBPvLhqcY jwqm9X6jdW2roG8ATM3jer1et1cv6BkA9n3YqZWlTLPRb9Y7Oc0SyA7naXdrq7WGiy/RX5mTudXp dFZbmSyWqAHZYWMO36ytNTaXHbwBWfzqHL7R2ex21xy8AVn82hy+f6211nDxBhQxmuzPobVB+/2M egEJOduuhDcB3qxl8BkKvKHwLs0i5Ila5GsxfshFHwAayLCiCVLTlITYBy/u4ngkKNYM8DrBpTd2 ypdzU5oXkr6gqWp776cYImJG7/WL716/eIZev3h6/Oj58aMfjx8/Pn70g6XlLNzGybi88NU3n/7x 1Ufo92dfv3ryeTVelvG/fP/xzz99Vg2ECJpJ9PKLp78+f/ryy09++/ZJBXxT4FEZPqQxkegOOUR7 PIa9GcW4kpORON+KYYSpswJHQLuCdE9FDvDOFLMqXIe4yrsvIHlUAW9OHjqyDiIxUbSC860odoA7 nLMOF5UKuKV5lTQ8nCTjauZiUsbtYXxQxbuLE8e0vUkKWTN3Skf33Yg4Yu4ynCg8JglRSL/j+4RU 7O4BpY5ed6gvuOShQg8o6mBaqZIhHTmONFu0TWOwy7Rqz2BqRzc791GHs6pdb5EDFwkBgVmF8EPC HDXexBOF4yqSQxyzssJvYxVVCTmYCr+M60kFlh4TxlEvIFJWrbkrYL8lo9/CkK8qzb7DprGLFIru V9G8jTkvI7f4fjfCcVqFHdAkKmPfk/vgohjtclUF3+FuhOhnsANOFpr7PiWOuU9PBPfo2BFp5iD6 zURoW0KidvJvTJO/SsaMQja2PnCZjNveJpSmqpDYPpGCF+H+hYl3C0+SXQK+Pl94LvPuZd71/vN5 d1EsnzXbzhIs5F7dPNi+2HTJ8cImOaSMDdSUkdvS9MkSikXQh0m9zhwQSXFoSiMYZsndwY0FNmuQ 4OoDqqJBhFPoseueJjKWGemxRCmXcLYz05W0NR76dGVPhqv6zGDzgcRqhwd2ekVP50eDgowpOWNz /swZrWgCZ2W2ci0jCtt+E2Z1LdSZudWNaCbVOdyKLYMN57cGk4U2oQtB0LuAltfgiK5Zw9kEMxJo vdsCnJvFWOEiTSQjHJDMRnrf8zaqGyPlvmIuA8B3Kmykz3mnaK3EraXJvgW3sxipzK6xgF1uvbex Uu7BMyvpuD0RjiwpBydL0GHba60ur3rIx2nbC+FYC8M4BatL3fhhNoa7IV8J6/anBrOJ8pk1W/nG 3CCow02F1fvchp08kAqptrCMrGuYV5kLsERzsvIvr4JaL2oD1tPfQIqVJjjDPyYF6NE1LQlD4quy sUszWnf2MUulfKKIGETBIRqxidjDYH7tqrCfgEq4nTAZQT/AVZrWtnnlJucs6MoXWAZn5zFLI5yl Wx2ieSRbuInjQgbzVBIP9lYpu9nc+bdiQv6CtlJ24//ZVnQ9geuClUBbwIebXIGRjte2x4WKOGSh NKJ+X0DjYHIHeAtcx8JrcCq4Tzb/BTnQ/23MWRomrOHUp/boGAkK9UhFgpBdSEvG+04hVs9qlyXJ MkLGo0riytSKPSIHhA11DlzTtd1DEbi6ySZZGjC4k/7nPmcRNBrrJqccb04OKWqvjYG/u/OxwQyb cvOwaWhy/RciVlRVu94sz2tveSP6xazNauRRAcxKpaCVhf0binDOUmsz1tyOl1dz4cCK8zuGyaIh SuHSB+kfqH9U+Mx+nNAFdcj3ILci+NagiYHbgFdfsY0H0gnSTo6gcbKT1pk0KavarHXSWsuL9QV3 ugXfE8rWkp3F3udUdtGcueycWLxIZWcadnRt5xaqGix7MkRhKswPMsYw5qtW+cMTHz0EQ2/BFf+E 2U9RMoUnEwfprkCjQzhEwMEELhK5SXJHoYj1Wx6G6MikuGmW4KCGHSnkw2QdmgSYzZvqfIk/keom 4WY5PoCsYnx3HOQjHOUj/yjJhyLzQ+uD8AsqgV9wPWNlvK6dzoJht2UWbnYqV23nk5cDe7t2sczD +GHhiOWuckHLh9cFnySB0UlEcNBLAnOH2vYS+Dbp6RQekwAqC4HKokcGqTBlZ0GCbmxDWXQd1o8k GFmbc8SDKZgbvpWqu/ATMg78fEZTYAx1DnrlDydYgBjsvQQOpPXmchO+nSrzoI2SD0b5YJJCaYsg bRgvAO7Stmo528zJWHLpbW94OLn0NnRGb8ucDGJgPt1BzhIYDtoDU/WLRGIS5cafAAAA//8DAFBL AwQUAAYACAAAACEA7eY1cL5AAACesQEAGAAAAHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbLSd3ZIc 15Gk79ds34GG+yHRjX+aqLFhVmah62JtbWd/riEQEmEiCC4BSaN9+vVT4VERfrxJdVI1N4L4MeJU fV5Z1Y6WuvN3//ofH3744q/vfv70/uOP3zy6+fLxoy/e/fj243fvf/zTN4/+1//c/uXloy8+fX7z 43dvfvj447tvHv393adH//r7//pffve3jz//+dP37959/gIn/Pjpm0fff/7809dfffXp7ffvPrz5 9OXHn979iH/zx48/f3jzGf/485+++vTTz+/efHde+vDDV7ePHz//6sOb9z8+ihO+/vkhZ3z84x/f v313+Pj2Lx/e/fg5Dvn53Q9vPuP5f/r+/U+f8rQPbx9y3Ic3P//5Lz/9y9uPH37CEX94/8P7z38/ H/roiw9vv777048ff37zhx/g/R83T9+8zbPP/2DHf3j/9uePnz7+8fOXOO6reKLu/OqrV1/hpN// 7rv3MBixf/Hzuz9+8+jfbr4+Pb159eir3//unND/fv/ub5/af//i85s//Pu7H969/fzuO7xQj774 fx8/fvj3t2/Gk3uFV+3yj/9tJP5DwPEi/eHjxz+Pw+6w9hiP++l8yHjcN28/v//ru+XdD5j+tyd4 nf9vPJMnXx+fjOfx1eWJ9P+eT2o7v7L//ecvvnv3xzd/+eHz//j4t9fv3v/p+894drdfvniGsEZm X3/398O7T2/xYuHhv7wd5779+AMOwX9+8eH9uOiQ9Zv/OP/5t/ffff7+m0dPv3z24vGTm1uc8enz 34chZt7+5dPnjx/+T0zc8Jw44ZYn4E+e8OzLFzePXz0Zz+JBJ8D+/BzwJ094+eXT22cvXvYn8RKn /cqzeMoz8CfPuL398ubp4+fN4+Wvi+ABzk8Df/KImxc7s3jOI/Anj3j68svbl89unsnzePGrKvi3 5+eBP/OQFzsTxefG+YhXlyNezWHoi3iDi/i8Mf4LH/WJBfjr+d1crqXnT17W63D/I38V1+H5Ij+8 +fzm97/7+ePfvsCnEA759NOb8Zl28/V4MudL+vmXl1f/cpk/+uLz9+/f/vnbj+Oav/96f4Z33Ntx 6L+NU/GuxLPC9Cfgv/7+8e+++iveWm858u1lZLxJxtJi5GBkNbIZORp5HSTej+Oh7mZwChCfBEjm Eg/eZRIPrHCxxRsjPhTOaYzUnr36clz88e9abPd8Mjy5BDXOR1DYuwT15GZK6jJzScrIwchqZDNy NPI6yNPzJ845qRmcAjw7f2b2pMZnar+QhlamMSV1i7Qtpn90dT2pq2s8FE7HC1Gh3U6hXWYuoRk5 GFmNbEbw5YKPnie/DvKiQpvBKcBLCw1vkDm0GwR87/V1c9/F9Y9SwxWZ78nxWEgNH3OX1OYr7TKS aouRg5HVyGbkaOR1EHzk5GPdGTmRnD87v+oXG6Kw3H7pfXnz+PG9H2f3vC9vL2GNB8A7G6/bJaz5 CuMInuNl5IlehMs9I7cvdOYQMy/xJeRyzFMdWe8ZeaYj2z0jt6905sgZvCsvj/Rk+lR+HTPjUrvM PNdj7u4ZmZxO94zcvrwcI68kXrX5lbxF6ve+A15E1bKPjl99JccD4LKv6+xbkviKfP7KQ1JfIA42 sxrZbOto5DXJ+QvL+avcnZFT35Js8FZ9cDbPbvdf5ON8jYakRUPSorGZ1chmW0cjr0laNEZOfUui GX9Tm77a/PJlg8tx3zUzTtdgSFowJC0Ym1mNbLZ1NPKapAVj5NS3JBi8u/8TgxmnazAkLRiSFozN rEY22zoaeU3SgjFy6lsSzCi3D07mOd6T+y6Z8/EaTaKWTaIWTqKaWh1tiWrx6Oh1opaQo1Oi81ma 0ajB/3lvq/E3Flw+N9WUvk10rkb8awCnzt8eOKODT62ONqLbaq/HRPXp/zpR5X2XqMI9EcX3KDSj UYD/EzOKfi0ZEfWMiHpGNrWOKjnyrsWNSDKKqdueEVHPiKhnxOPPT0IzGn33oRnd4PsX+IT+1S/i o4jNVw5RyS051VOxqTWnanFLVItHIkklzsLfXi6VNad6KnzEe1IZdfaqqbAf9/cTUcktN0Qld0hU U6ujLVEtHokklTheUiHqqfQnodfKKItXTYXts6dCVL7LqLjjiiq5Q6KaWh1tiWrxSCSpxPGSClFP pT8JTWWUwqumEi1TPleIyne5ISq5Q6KaWh1tiWrxSCSpxPGSClFPpT8JTWX0waumEgVTUiEq3wX/ 2q4Vm1pzqha3RD2VWJRUiPrnClFPhY94PktTGWXwqqlEu5RUiEpuwZeVkcrLeo4HohfluxLJ1yAu Vks5ckpSiSm5VojqEU95/D2pjCZ41VSiWkoqRD2VQJJKIEnFFjd8Ep3j7KkEklSI+rVC1FMJdE97 wVnXTeV8oHa6RC0Vop4KUU/FF7dcbKkQ4Y/8Mvw6UUslUUuF6L5U9vTeh/QVXLXnT4z2NShRTyWm JJVAkgrPqsWNZ73sqcSUpELUUyHqqfB4fwfdjn53zXfQ+cDpWmGHLLmFU03uQCSp2OLmi0cifBe0 rpVY7J8rOdVT4fH3pDL63VVTYWHs1wpRTyWQpBJIUrHFbXxbZHxM92slkKRC1K8Vop5KoPveQaPf XTUVFsaeClFPpdfK+Lsi/mpzfuvV1OpoS1RfqY5E8g6Ks+RaIeqp9CchX5nH/x503VRYGHsqROW7 nB9Wu22imlodbYl6KnG8pEJUEdxxEW+kfJ+d5CxNZfS7q14rLIw9FaLyXW57reS1YlNrTtXiRiTv oFiUVIgqgjsuSir9SWgqo989OBU0oX3fn7plfewZEZXqklN1ARwS1dTqaCOSjOJ4yYioZ2ToxLOQ Hi4mzWgUwAdn9IDvK9xGo+ydLlH5Lol6KlysqTWnCm2JavFIJKnEWe0yucuperVOcpamMtreVVNh faxH//aWqOSWRCV3SFRTq6MtUS0eiSSVeERJxdBJzpJUnly76Z4P1PaSqHyXRCV3SFRTq6MtUS0e iXoqido7yNFJztJURtu75rXyhPWxXSuJyndJVHKHRDW1OtoS1eKRSFKxWnuXUxXUSc7SVEbbu2oq rI89FaLyXZ70khlfkRLV1OpoS9RTibMkFaKK4I6L7U11krM0ldH2rpoK62NPhah8lye9ZDIVm1pz qha3RD2VWJRUiHoqhk5ylqYy2t5VU2F97KkQldzypJdMpmJTa07V4paopxKLkgpRT8XQSc7SVEYn vGoqrLU9FaKSW/B/CjqX/ZI7JKqp1dGWqBaPRJJKHN/eLnc5VUGd5CxNZbS9q6bC+thTISrf5Ukv mbxWbGrNqVrcEvVUYlFSIaoI7rjYgjrJWZrKqHxXTSU6ZG9xT4hKbklUcodENbU62hLV4pFIUrEi e5dTFdRJztJUrt1tn3i3TVS+S6KSOySqqdXRlqgWj0SSinfbnOqp8Kmez9JURuW76rXCItvfQUTl uzwhKrlDoppaHW2JavFIJKnE8e3tcpdTPZX+JCSVp9futucDtdsmKt8lUckdEtXU6mhLVItHop5K oorgztFJztJUrt1tn3q3TVS+S6KSOySqqdXRlqgWj0SSinfbnKqg8NMU7QuhpjJa4DXfQU/ZWts7 KFH5LolK7pCoplZHW6JaPBJJKt5tc6qnwqd6PktTGZXvqqlEh+xfg54Sle+SqOQOiWpqdbQlqsUj kaRiRfYup3oqfF73pDIq31VTiQ4pqRCV7/KUqOQOiWpqdbQlqsUjkaQSx/dP25zqqfQnodfKaIFX TYWttb+DiMp3eUpUcodENbU62hLV4pFIUonjJRVDJzlLUxkt8KqpsKL2VIjKd3lKVHKHRDW1OtoS 1eKRSFKJ4yUVQyc5S1O5drd96t02UfkuiUrukKimVkdbolo8Ekkq3m1zqr+D+FTPZ2kq1+62T73b JirfJVHJHRLV1OpoS1SLRyJJxbttTvVUfrHbPh397qrvIBbG/g4iKt/l/LD6vw4lqqnV0ZaopxLH SypEFcEdF9ub6iRnybXy7Nrd9nygdttE5bskKrlDoppaHW2JavFI1FNJ1FJxdJKzNJVrd9tn3m0T le+SqOQOiWpqdbQlqsUjkaTi3TanKqiTnKWpXLvbPvNum6h8l0Qld0hUU6ujLVEtHokkFe+2OdVT +cVu+2z0u2t+rpwPnN5B3m1zquQOiXoqtrjlVC0eiSSVWGwfInc51VPh8eez9FoZ/e6qqbAwtk/b Z0TluyQquUOimlodbYlq8UgkqcQjSiqGTnKWpjIq31VTYWvtqRCV7/KMqOQOiWpqdbQlqsUj0Yta fE0kqcQjNnSSszSVUfmumgpba0+FqJ728oyo5A6Jamp1tCWqxSORpBLHtwjuONXQSc7SVK7dbZ95 t01UvkuikjskqqnV0ZaoFo9Ekop3W05JKr/YbZ9du9ueD5w+bdkhy3fJqZI7JKqp1dGWqBaPRJKK d1tOSSq/2G2fjRZ41XcQi2x/BxGV73J+WO22iWpqdbQl6qnE8ZJKoBbBHRcbOslZ8g56fu1uez5Q r5VE5bskKrlDoppaHW2JavFI1FMhahHcOTrJWZrKtbvtc++2icp3SVRyh0Q1tTraEtXikUhS8W7L qRbUSc7SVK7dbZ97t01UvkuikjskqqnV0ZaoFo9Ekop3W05JKr/YbZ+PfnfNz5XzgdM7yCrqklMl d0jUU7HFLadq8UjUW1yiKrJ3jk5yll4ro/JdNRUW2fZp+5yofJdEJXdIVFOroy1RLR6JJBUrsnc5 VUGd5CxNZVS+q6bC1tpTISrf5TlRyR0S1dTqaEtUi0ciSSWOb2+Xu5zqqfQnoamMFnjVVNhaeypE 5buMn6ieft4uUU2tjrZEPZU4S1IhqgjuuNiCOiXy/2fp82t32/OB0+cKO2T5LjlVcodENbU62hLV 4pFIUvFum1MV1EnO0mvl2t32OQtjv1aIynfJqZI7JKqp1dGWqBaPRJJKPGK7MO5yqqfC53U+S1MZ LfCq7yAW2Z4KUfkuz4lK7pCoplZHW6JaPBJJKnG8pGLolIv+Dnpx7W57PlDfQYnKd0lUcodENbU6 2hLV4pGop5KoLow7Ryc5S66VF9futucDp1RYd8t3yamSOySqqdXRlqgWj0SSinfbnKqgTnKWpnLt bvvCu22i8l0SldwhUU2tjrZEtXgkklS82+ZUT+UXu+2La3fb84HTtWIVdcmpkjsk6qnY4pZTtXgk klRisX+u5FRPhcefz9Jr5drd9oV320TluyQquUOimlodbYlq8UgkqXi3zameCp/qPamMfjd/DcJX rPihoOn37T3kJ1bPvz10ulbYIct3yamSOySqqdXRlqgWj0SSinfbnOqp/GK3fTFaYE/l/NssH/Bz QOfFyZ6FtbyWnCqJQ6KaWh1tiWrxSCT23mFzqttz6p6vwHOHfbA9i2nrHy+8qyYqiUOibm+LW07V 4pFI7GNRPicMneQs/ZwYfe03vfYset2eqLwWfBNj/vtLoppaHW2Jun2cJfZE9ULfcbEFcpKz1H5U td9kz1bZ7YnKa8HPGJu9Ta05VYtbom4fi2JP1O0NneQssX85d8+HXvnnRX3fJyqJJVFJHBLV1Opo S1SLR6Jun6jZOzrJWWo/d8wH27M4ttd+/M7m8df08loSlcQhUU2tjrZEtXgkEnvvkjlVgZzkLLWf u+SD7b0z4jcxmH2va/GzFD61OtoSdfs4S+yJSvWOi/19L2ep/ehNv+V9j5/UPav2156oXtUlp0ri kKimVkdbolo8Eol9PGJTvcupCuQkZ6n93A0f/Np7Bxy/Qnu+8nv94mtvU6svbom6fSyKPVGp3nGx BXKSs9R+7oAPtmeB6q89Ub2qy/gN8NN37BLV1OpoS9Tt4yyxJ+r2hk5yltr/1q73ksWu2xOV15JT JXFIVFOroy1RLR6JxJ4trtsbOslZaj+q0W9637OfdXui8lpeEpXEIVFNrY62RLV4JBL7OL5d5nc5 VYGc5Cy1H23pN9mzxXV7ovJaxi9jnq98m1pzqha3RN0+FsWeqFTvuNgCOclZaj+q0W+yj07V/9/4 L4lKYklUEodENbU62hLV4pFI7K3Y3eVUBXKSs8R+3P/jN9mfF7XrJSqvJVFJHBLV1OpoS1SLR6Ju n6hU7xyd5Cy1n7sertPxmyF+89/7X3kHTFS+S6KSOySqqdXRlqgWj0SSinfAnKqgTnKWpjJaVH9H /NOpsPW1z4lXROW7JCq5Q6KaWh1tiWrxSCSpeDfMqZ4Kn9f5LE1l7ob/dCreGV95Z0xUcodEPRVb 3HKqFo9Ekkosto/Ku5zqqfD4e1IZreuq1worYb9WiMp3GfdCmb6mJKqp1dGWqKcSZ0kqRBXBHRdb UCc5S6+VUb2umkp0uf61ZtzlZERQvkuikjskqqnV0ZaoFo9EkooVyrucqqBOcpamMirZVVNh0ezX ClH5LuPOJvO1YlNrTtXilqinEouSClFFcMdFuVb6k9BURnu7aipsmz0VopJbxp1L5lRsas2pWtwS 9VRiUVIh6qkYOslZmspodQ9J5Vd/0fWr6IbytiEqoyWnyuiQqKZWR1uiWjwSSRTxiPjdSvnb3O5y qtBJkEYxF1S8bPeWlF+PwtvqK2+rieqJHRL1KGxxy6laPBJJFLEoURg65eL5LIkCN5+5xmURx2h5 vbDyXC6srA4XVnO4w8B4WvJZjFsMkNUu7jEQrEdyYTV3dw/DbQa4e18qD62xv3qF3Dz28nphZYtU OFfPGKmQ1RxSMYZUbBepBNNUyOoxkIoxpNLZdK2MKvdPf4TcPGYjbB+nF1a2SKU3x/j21oXVHFLh XDGkYrtIJZimQiapGEMqnU2pjCp3hVTYCCUVsjJDKr05Zio2h1SMIRXbRSrBNBUyScUYUulsSmUU viukwloqqZBJKmT1jPEOsjmkYgyp2C5SCaapkNVj4B1kDKl0NqXy0Br7Dz5XvLzePPb2emH1jJGK zSEVY0iFrHaRSjBNhazmkIoxpNLZlMqocle4VtgI5Vohk2ulN8d8B9kcUjGGVGwXqQTTVMgkFWNI pbMpldHurpBKlMTe2G4ek0kqZPWMca3YHFIxhlRsF6kE01TI6jFwrRhDKp1NqVylxt489h57YZIK 5+oZIxWymkMqxpCK7SKVYJoKWT0GUjGGVDqbUhmd7wrXCmuovIPIyhZfg8jqGSMVm0MqxpCK7SKV YJoKWT0GUjGGVDrTVM43kvrnU+H9qOQdlKynkqyeMW4MZT0Wd4YyhltDkdUu7g3FftpuJHBhNYe7 Q3GuGG4P1dmUyih4V0gleqKmQiapkNWzQyo2h1SMIRXbRSrB5FpJVo+BVDhXDKl0NqUyCt4VUome qKmQSSpk9eyQis0hFWNIxXaRSjBNhaweA6kYQyqdTamMgneFVKInaipkkgpZPWOkYnNIxRhSsV2k EkxTIavHQCrGkEpnUyqj4F0hleiJmgqZpEJWzxip2BxSMYZUbBepBNNUyOoxkIoxpNLZlMooeFdI JXqipkImqZDVM0YqNodUjCEV20UqwTQVsnoMpGIMqXQ2pTIK3hVSiZ6oqZBJKmT1jJGKzSEVY0jF dpFKME2FrB4DqRhDKp1NqYyCd4VUoidqKmSSClk9Y6Ric0jFGFKxXaQSTFMhq8dAKsaQSmdTKqPg XSGV6Il4oPz2KG5jSSapkNUzRio2h1SMIRXbRSrBNBWyegykYgypdDalMgpeT+XX/27M+1SpfXRE PEgmstzkXD0z2Nsc7I3Bnqx2YR9M7clqDvbGYN+Z2uO8Pfbn8en7sMm6fbJ6ZoebZDWHO3RGj2zJ 4RadZLV7TIZ/lQm/vrCau7uHnZRN9qOwPfy1z3tY9Ss/WVktN8nqmcE+umEzhb0x2JPVLuyDqX0w 3OogE4G9Mdh3NtmPYrbDPnqcXPn4X8ym76PDnqwMYG9zsDcGe9uFfTC1D6b2xmDf2WQ/CtgO++hr ak8mrz2Z2Nsc7I3B3nZhH0ztg6m9Mdh3NtmPorXDPnqZ2pOJPZnY2xzsjcHedmEfTO2Dqb0x2Hc2 2Y9CtcM++pfak4k9mdjbHOyNwd52YR9M7YOpvTHYdzbZj+K0wz56ltqTiT2Z2Nsc7I3B3nZhH0zt g6m9Mdh3NtmPgrTDPvqU2pOJPZnY2xzsjcHedmEfTO2Dqb0x2Hc22Y8itMM+epPak4k9mdjbHOyN wd52YR9M7YOpvTHYdzbZjyK0wz56k9qTiT2Z2Nsc7I3B3nZhH0ztg6m9Mdh3pvbY3WN/Hp+6XrJu n6zbJ6s53Hf8nq6XrHZx5/GYE3sy/FFtx9kpd2Nush9F6OGvfd4tqXe9ZGWFe65Hv0LFzmd2uLCa gz3niuG267YL+2BqH0ztjcG+s8l+FKEd9tGb5MrPOyWVAew5J/ZkNQd7Y7C3XdgHU/tgam8M9p1N 9qMI7bCP3qT2ZGUFezKxtznYG4O97cI+mNoHU3tjsO9ssh9FaId99Ca1JxN7MrG3Odgbg73twj6Y 2gdTe2Ow72yyH0Voh330JrUnE3sysbc52BuDve3CPpjaB1N7Y7DvbLIfRWiHffQmtScTezKxtznY G4O97cI+mNoHU3tjsO9ssh9FaId99Ca1JxN7MrG3Odgbg73twj6Y2gdTe2Ow72yyH0Voh330JrUn E3sysbc52BuDve3CPpjaB1N7Y7DvbLIfRWiHffQmtScTezKxtznYG4O97cI+mNoHU3tjsO9M7c+3 CXq4fd5VqLedZN0+WbdPVnPrjbPtwmr3mEzsuSv2zk65G3OT/ShCO+yjN8lrn3cUKqvlJlkZHC6s 5mDP84rBnqx2YR9M7YOpvTHYdzbZjyK0wz56k9qTlQHsycoA9jYHe2Owt13YB1P7YGpvDPadTfaj CO2wj96k9mRiTyb2Ngd7Y7C3XdgHU/tgam8M9p1N9qMI7bCP3qT2ZGJPJvY2B3tjsLdd2AdT+2Bq bwz2nU32owjtsI/epPZkYk8m9jYHe2Owt13YB1P7YGpvDPadTfajCO2wj96k9mRiTyb2Ngd7Y7C3 XdgHU/tgam8M9p1N9qMI7bCP3qT2ZGJPJvY2B3tjsLdd2AdT+2Bqbwz2nU32owjtsI/epPZkYk8m 9jYHe2Owt13YB1P7YGpvDPadTfajCO2wj96k9mRiTyb2Ngd7Y7C3XdgHU/tgam8M9p2p/fm2OQ+3 z7vs9K6XrNsn6/bJam69cbZdWO0ek4k9d8Xe2Sl3Y26yH0Voh330Jnnt8w47ZbXcJCuDw4XVHOx5 XjHYk9Uu7IOpfTC1Nwb7zib7UYR22EdvUnuyMoA9WRnA3uZgbwz2tgv7YGofTO2Nwb6zyX4UoR32 0ZvUnkzsycTe5mBvDPa2C/tgah9M7Y3BvrPJfhShHfbRm9SeTOzJxN7mYG8M9rYL+2BqH0ztjcG+ s8l+FKEd9tGb1J5M7MnE3uZgbwz2tgv7YGofTO2Nwb6zyX4UoR320ZvUnkzsycTe5mBvDPa2C/tg ah9M7Y3BvrPJfhShHfbRm9SeTOzJxN7mYG8M9rYL+2BqH0ztjcG+s8l+FKEd9tGb1J5M7MnE3uZg bwz2tgv7YGofTO2Nwb6zyX4UoR320ZvUnkzsycTe5mBvDPa2C/tgah9M7Y3BvjO1P99G5uH2edeZ 3vWSdftk3T5Zza03zrYLq91jMrHnrtg7O+VuzE32owjtsI/eJK993nGmrJabZGVwuLCagz3PKwZ7 stqFfTC1D6b2xmDf2WQ/itAO++hNak9WBrAnKwPY2xzsjcHedmEfTO2Dqb0x2Hc22Y8itMM+epPa k4k9mdjbHOyNwd52YR9M7YOpvTHYdzbZjyK0wz56k9qTiT2Z2Nsc7I3B3nZhH0ztg6m9Mdh3NtmP IrTDPnqT2pOJPZnY2xzsjcHedmEfTO2Dqb0x2Hc22Y8itMM+epPak4k9mdjbHOyNwd52YR9M7YOp vTHYdzbZjyK0wz56k9qTiT2Z2Nsc7I3B3nZhH0ztg6m9Mdh3NtmPIrTDPnqT2pOJPZnY2xzsjcHe dmEfTO2Dqb0x2Hc22Y8itMM+epPak4k9mdjbHOyNwd52YR9M7YOpvTHYd6b259uqPNw+78LSu16y bp+s2yerufXG2XZhtXtMJvbcFXtnp9yNucl+FKEd9tGb5LXPO7CU1XKTrAwOF1ZzsOd5xWBPVruw D6b2wdTeGOw7m+xHEdphH71J7cnKAPZkZQB7m4O9MdjbLuyDqX0wtTcG+84m+1GEdthHb1J7MrEn E3ubg70x2Nsu7IOpfTC1Nwb7zib7UYR22EdvUnsysScTe5uDvTHY2y7sg6l9MLU3BvvOJvtRhHbY R29SezKxJxN7m4O9MdjbLuyDqX0wtTcG+84m+1GEdthHb1J7MrEnE3ubg70x2Nsu7IOpfTC1Nwb7 zib7UYR22EdvUnsysScTe5uDvTHY2y7sg6l9MLU3BvvOJvtRhHbYR29SezKxJxN7m4O9MdjbLuyD qX0wtTcG+84m+1GEdthHb1J7MrEnE3ubg70x2Nsu7IOpfTC1Nwb7ztT+fHuTh9vn3VB610vW7ZN1 +2Q1t9442y6sdo/JxJ67Yu/slLsxN9mPIrTDPnqTvPZ5h5SyWm6SlcHhwmoO9jyvGOzJahf2wdQ+ mNobg31nk/0oQjvsozepPVkZwJ6sDGBvc7A3BnvbhX0wtQ+m9sZg39lkP4rQDvvoTWpPJvZkYm9z sDcGe9uFfTC1D6b2xmDf2WQ/itAO++hNak8m9mRib3OwNwZ724V9MLUPpvbGYN/ZZD+K0A776E1q Tyb2ZGJvc7A3BnvbhX0wtQ+m9sZg39lkP4rQDvvoTWpPJvZkYm9zsDcGe9uFfTC1D6b2xmDf2WQ/ itAO++hNak8m9mRib3OwNwZ724V9MLUPpvbGYN/ZZD+K0A776E1qTyb2ZGJvc7A3BnvbhX0wtQ+m 9sZg39lkP4rQDvvoTWpPJvZkYm9zsDcGe9uFfTC1D6b2xmDfmdqfb2/ycPu8G0rvesm6fbJun6zm 1htn24XV7jGZ2HNX7J2dcjfmJvtRhHbYR2+S1z7vhFJWy02yMjhcWM3BnucVgz1Z7cI+mNoHU3tj sO9ssh9FaId99Ca1JysD2JOVAextDvbGYG+7sA+m9sHU3hjsO5vsRxHaYR+9Se3JxJ5M7G0O9sZg b7uwD6b2wdTeGOw7m+xHEdphH71J7cnEnkzsbQ72xmBvu7APpvbB1N4Y7Dub7EcR2mEfvUntycSe TOxtDvbGYG+7sA+m9sHU3hjsO5vsRxHaYR+9Se3JxJ5M7G0O9sZgb7uwD6b2wdTeGOw7m+xHEdph H71J7cnEnkzsbQ72xmBvu7APpvbB1N4Y7Dub7EcR2mEfvUntycSeTOxtDvbGYG+7sA+m9sHU3hjs O5vsRxHaYR+9Se3JxJ5M7G0O9sZgb7uwD6b2wdTeGOw7E/vb801AHmwf4/o7Vy6s2V9Ys7+wmlvv YduF1e4xWbdP1u3vYSdlk/0oQjvsozf11/427z9SVsuFlcHhwmoO9jyvGOzJahf2wdQ+mNobg31n k/0oQjvsozepPVkZwJ6sDGBvc7A3BnvbhX0wtQ+m9sZg39lkP4rQDvvoTWpPJvZkYm9zsDcGe9uF fTC1D6b2xmDf2WQ/itAO++hNak8m9mRib3OwNwZ724V9MLUPpvbGYN/ZZD+K0A776E1qTyb2ZGJv c7A3BnvbhX0wtQ+m9sZg39lkP4rQDvvoTWpPJvZkYm9zsDcGe9uFfTC1D6b2xmDf2WQ/itAO++hN ak8m9mRib3OwNwZ724V9MLUPpvbGYN/ZZD+K0A776E1qTyb2ZGJvc7A3BnvbhX0wtQ+m9sZg39lk P4rQDvvoTWpPJvZkYm9zsDcGe9uFfTC1D6b2xmDfmdqfb4rxcHveQ0Psk3X7ZN0+Wc2tt862C6vd YzKx567YOzvlbsxN9qMI7bCP3qT2ZGW13PKeGv33611YzcHedmFPJvbB1D6Y2huDfWeT/ShCO+yj N6k9WVnBnqwMDhdWc7C3XdjbLl77YGofTO2Nwb6zyX4UoR320ZvUnqysYE8m9jYHe2Owt13YB1P7 YGpvDPadTfajCO2wj96k9mRiTyb2Ngd7Y7C3XdgHU/tgam8M9p1N9qMI7bCP3qT2ZGJPJvY2B3tj sLdd2AdT+2Bqbwz2nU32owjtsI/epPZkYk8m9jYHe2Owt13YB1P7YGpvDPadTfajCO2wj96k9mRi Tyb2Ngd7Y7C3XdgHU/tgam8M9p1N9qMI7bCP3oQD8zfFfnvL+1K0uwLgU49zYk9WKcHeGOxtF/bB 1D6Y2huDfWeT/ShCO+yjN6k9WVnBnkzsbQ72xmBvu7APpvbB1N4Y7DtTe5y3x/48Pn1fL1m3T9bt k9Xceutsu7DaPSbDeF5zr5OJPc9r7KRzk/0oQg9/7fOeFv3KT1ZWy22yMjhcWM3BPnoYLs60gj1Z 7cI+mNoHa6Z3OdcY7PvcZD+K0A776E1y5ed9LsoA9pwrA9iT1RzsjcHedmEfTO2DNVPYG4N9Z5P9 KEI77KM3qT1ZWcGeTOxtDvbGYG+7sA+m9sHU3hjsO5vsRxHaYR+9Se3JxJ5M7G0O9sZgb7uwD6b2 wdTeGOw7m+xHEdphH71J7cnEnkzsbQ72xmBvu7APpvbB1N4Y7Dub7EcR2mEfvUntycSeTOxtDvbG YG+7sA+m9sHU3hjsO5vsRxHaYR+9Se3JxJ5M7G0O9sZgb7uwD6b2wdTeGOw7m+xHEdphH71J7cnE nkzsbQ72xmBvu7APpvbB1N4Y7Dub7EcR2mEfvUntycSeTOxtDvbGYG+7sA+m9sHU3hjsO1N77O6x P49PXS9Zt0/W7ZPV3HrrbLuw2j0mE3vu4o9sSnc519hJ2WQ/itDDX/u8p0XvesnKarlNVgaHC6s5 2EcPk66XrHZhH3Nq3zvc+U7ssDcG+84m+1GEdthHb5IrP+9zUVaw51wZwJ6s5mBvDK+97cI+mNoH a68z7I3BvrPJfhShHfbRm9SerKxgTyb2Ngd7Y7C3XdgHU/tgam8M9p1N9qMI7bCP3qT2ZGJPJvY2 B3tjsLdd2AdT+2Bqbwz2nU32owjtsI/epPZkYk8m9jYHe2Owt13YB1P7YGpvDPadTfajCO2wj96k 9mRiTyb2Ngd7Y7C3XdgHU/tgam8M9p1N9qMI7bCP3qT2ZGJPJvY2B3tjsLdd2AdT+2Bqbwz2nU32 owjtsI/epPZkYk8m9jYHe2Owt13YB1P7YGpvDPadTfajCO2wj96k9mRiTyb2Ngd7Y7C3XdgHU/tg am8M9p2p/flGEw+3z/tc9LaTrNsn6/bJam69dbZdWO0ek4k9d8Xe2Sl3Y26yH0Voh330Jnnt8z4X ZbXcJiuDw4XVHOx5XjHYk9Uu7IOpfTC1Nwb7zib7UYR22EdvUnuyMoA9WRnA3uZgbwz2tgv7YGof TO2Nwb6zyX4UoR320ZvUnkzsycTe5mBvDPa2C/tgah9M7Y3BvrPJfhShHfbRm9SeTOzJxN7mYG8M 9rYL+2BqH0ztjcG+s8l+FKEd9tGb1J5M7MnE3uZgbwz2tgv7YGofTO2Nwb6zyX4UoR320ZvUnkzs ycTe5mBvDPa2C/tgah9M7Y3BvrPJfhShHfbRm9SeTOzJxN7mYG8M9rYL+2BqH0ztjcG+s8l+FKEd 9tGb1J5M7MnE3uZgbwz2tgv7YGofTO2Nwb6zyX4UoR320ZvUnkzsycTe5mBvDPa2C/tgah9M7Y3B vjO1P99o4uH2eZ+L3vWSdftk3T5Zza23zrYLq91jMrHnrtg7O+VuzE32owjtsI/eJK993ueirJbb ZGVwuLCagz3PKwZ7stqFfTC1D6b2xmDf2WQ/itAO++hNak9WBrAnKwPY2xzsjcHedmEfTO2Dqb0x 2Hc22Y8itMM+epPak4k9mdjbHOyNwd52YR9M7YOpvTHYdzbZjyK0wz56k9qTiT2Z2Nsc7I3B3nZh H0ztg6m9Mdh3NtmPIrTDPnqT2pOJPZnY2xzsjcHedmEfTO2Dqb0x2Hc22Y8itMM+epPak4k9mdjb HOyNwd52YR9M7YOpvTHYdzbZjyK0wz56k9qTiT2Z2Nsc7I3B3nZhH0ztg6m9Mdh3NtmPIrTDPnqT 2pOJPZnY2xzsjcHedmEfTO2Dqb0x2Hc22Y8itMM+epPak4k9mdjbHOyNwd52YR9M7YOpvTHYd6b2 5xtNPNw+73PRu16ybp+s2yerufXW2XZhtXtMJvbcFXtnp9yNucl+FKEd9tGb5LXP+1yU1XKbrAwO F1ZzsOd5xWBPVruwD6b2wdTeGOw7m+xHEdphH71J7cnKAPZkZQB7m4O9MdjbLuyDqX0wtTcG+84m +1GEdthHb1J7MrEnE3ubg70x2Nsu7IOpfTC1Nwb7zib7UYR22EdvUnsysScTe5uDvTHY2y7sg6l9 MLU3BvvOJvtRhHbYR29SezKxJxN7m4O9MdjbLuyDqX0wtTcG+84m+1GEdthHb1J7MrEnE3ubg70x 2Nsu7IOpfTC1Nwb7zib7UYR22EdvUnsysScTe5uDvTHY2y7sg6l9MLU3BvvOJvtRhHbYR29SezKx JxN7m4O9MdjbLuyDqX0wtTcG+84m+1GEdthHb1J7MrEnE3ubg70x2Nsu7IOpfTC1Nwb7ztT+fKOJ h9vnfS5610vW7ZN1+2Q1t9462y6sdo/JxJ67Yu/slLsxN9mPIrTDPnqTvPZ5n4uyWm6TlcHhwmoO 9jyvGOzJahf2wdQ+mNobg31nk/0oQjvsozepPVkZwJ6sDGBvc7A3BnvbhX0wtQ+m9sZg39lkP4rQ DvvoTWpPJvZkYm9zsDcGe9uFfTC1D6b2xmDf2WQ/itAO++hNak8m9mRib3OwNwZ724V9MLUPpvbG YN/ZZD+K0A776E1qTyb2ZGJvc7A3BnvbhX0wtQ+m9sZg39lkP4rQDvvoTWpPJvZkYm9zsDcGe9uF fTC1D6b2xmDf2WQ/itAO++hNak8m9mRib3OwNwZ724V9MLUPpvbGYN/ZZD+K0A776E1qTyb2ZGJv c7A3BnvbhX0wtQ+m9sZg39lkP4rQDvvoTWpPJvZkYm9zsDcGe9uFfTC1D6b2xmDfmdqfbzTxcPu8 z0Xvesm6fbJun6zm1ltn24XV7jGZ2HNX7J2dcjfmJvtRhHbYR2+S1z7vc1FWy22yMjhcWM3BnucV gz1Z7cI+mNoHU3tjsO9ssh9FaId99Ca1JysD2JOVAextDvbGYG+7sA+m9sHU3hjsO5vsRxHaYR+9 Se3JxJ5M7G0O9sZgb7uwD6b2wdTeGOw7m+xHEdphH71J7cnEnkzsbQ72xmBvu7APpvbB1N4Y7Dub 7EcR2mEfvUntycSeTOxtDvbGYG+7sA+m9sHU3hjsO5vsRxHaYR+9Se3JxJ5M7G0O9sZgb7uwD6b2 wdTeGOw7m+xHEdphH71J7cnEnkzsbQ72xmBvu7APpvbB1N4Y7Dub7EcR2mEfvUntycSeTOxtDvbG YG+7sA+m9sHU3hjsO5vsRxHaYR+9Se3JxJ5M7G0O9sZgb7uwD6b2wdTeGOw7U/vzjSYebp/3uehd L1m3T9btk9Xceutsu7DaPSYTe+6KvbNT7sbcZD+K0A776E3y2ud9LspquU1WBocLqznY87xisCer XdgHU/tgam8M9p1N9qMI7bBnb7q5/Nzzt7dyX4rzTwPDPubwpTZ/Phr2ZPUz07DnecVgz7nnl13Y c+72wl5fWO3e3cNg3x9jsh9FaIc9e5PY9y6V9sHUnqyeLextF/acE3vOib3twt4Y7Dub7EcR2mHP 3iT2vUulfTC1JxN724U958Sec2Jvu7A3BvvOJvtRhHbYszeJfe9SaR9M7cnE3nZhzzmx55zY2y7s jcG+s8l+FKEd9uxNYt+7VNoHU3sysbdd2HNO7Dkn9rYLe2Ow72yyH0Vohz17k9j3LpX2wdSeTOxt F/acE3vOib3twt4Y7Dub7EcR2mHP3iT2vUulfTC1JxN724U958Sec2Jvu7A3BvvOJvtRhHbYszeJ fe9SaR9M7cnE3nZhzzmx55zY2y7sjcG+M7F/su++GTH+zSP8Io/8Ov7thZXVkqzbX1jNrclaY9mS 4a9m+RjHZPgVGsleX1idd3cPOymb7EcRevBr/yTvQSH2vUvFa59zah9z+MZjGsDedmHPObHnnNjb LuyNwb6zyX4UoR327E1i37tU2gdTezKxt13Yc07sOSf2tgt7Y7DvbLIfRWiHPXuT2PculfbB1J5M 7G0X9pwTe86Jve3C3hjsO5vsRxHaYc/eJPa9S6V9MLUnE3vbhT3nxJ5zYm+7sDcG+84m+1GEdtiz N4l971JpH0ztycTedmHPObHnnNjbLuyNwb6zyX4UoR327E1i37tU2gdTezKxt13Yc07sOSf2tgt7 Y7DvbLIfRWiHPXuT2PculfbB1J5M7G0X9pwTe86Jve3C3hjsO5vsRxHaYc/eJPa9S6V9MLUnE3vb hT3nxJ5zYm+7sDcG+84m+1GEdtizN4l971JpH0ztycTedmHPObHnnNjbLuyNwb4ztT/faOLh9v+f sjtcrSu7kjj+KkYPMJ0eeSCYuCEoUkdiMgSGkM9K+7YtoraMrJ6BefrUvruWz/rv6gHtfOqUa92r n48JhTOZU++l6PrKDtXVpTPoKzt619XD1qte19d3dH1lx+fd/sbn3TFb9GMIbei9m6DvW8rP3u+q oH72sPXwTovz7c1l3ULv74A+vlf6yKTv2aIfQ2hD790Efd9SpZ8Z9c6OZ6VnH7fSuwe9e9DHrfSR Sd+zRT+G0Ibeuwn6vqVKPzPqnUEft9K7B7170Met9JFJ37NFP4bQht67Cfq+pUo/M+qdQR+30rsH vXvQx630kUnfs0U/htCG3rsJ+r6lSj8z6p1BH7fSuwe9e9DHrfSRSd+zRT+G0Ibeuwn6vqVKPzPq nUEft9K7B7170Met9JFJ37NFP4bQht67Cfq+pUo/M+qdQR+30rsHvXvQx630kUnfs0U/htCG3rsJ +r6lSj8z6p1BH7fSuwe9e9DHrfSRSd+zRT+G0Ibeuwn6vqVKPzPqnUEft9K7B7170Met9JFJ3zPq 9d8L7ujP9eXv9So7VFeXzqCv7OhdVw9br3pdX9/R9ZUdn3f7G593x2zRjyH0+mdf76Doz76y46eQ fu4r6p0dPen7Djv/ubmpDH+rWT3o41b6yKTv2aIfQ2hD790Efd9S/pPvd1VQP3tYuninRendw7P3 d0Af3yt9ZNL3bNGPIbSh926Cvm+p0s+Memd49nGrZ+8e9O5BH7fSRyZ9zxb9GEIbeu8m6PuWKv3M qHcGfdxK7x707kEft9JHJn3PFv0YQht67ybo+5Yq/cyodwZ93ErvHvTuQR+30kcmfc8W/RhCG3rv Juj7lir9zKh3Bn3cSu8e9O5BH7fSRyZ9zxb9GEIbeu8m6PuWKv3MqHcGfdxK7x707kEft9JHJn3P Fv0YQht67ybo+5Yq/cyodwZ93ErvHvTuQR+30kcmfc8W/RhCG3rvJuj7lir9zKh3Bn3cSu8e9O5B H7fSRyZ9z6jXytrRn+vL1qvsUF1dOoO+sqN3XT39Uv03mzeVYe3Ud3R9Zcftbd22z7tjtujHEHr9 s693UPRnX9nxU0g/9xX1zo6e9H2Hnf/cSO9ef/bVgz5upY9M+p4t+jGENvTeTdD3LeU/+X5XBfWz h62Hd1qU3j3o/R3Qx/dKH5n0PVv0Ywht6L2boO9bqvQzo94Znn3c6tm7B7170Met9JFJ37NFP4bQ ht67Cfq+pUo/M+qdQR+30rsHvXvQx630kUnfs0U/htCG3rsJ+r6lSj8z6p1BH7fSuwe9e9DHrfSR Sd+zRT+G0Ibeuwn6vqVKPzPqnUEft9K7B7170Met9JFJ37NFP4bQht67Cfq+pUo/M+qdQR+30rsH vXvQx630kUnfs0U/htCG3rsJ+r6lSj8z6p1BH7fSuwe9e9DHrfSRSd+zRT+G0Ibeuwn6vqVKPzPq nUEft9K7B7170Met9JFJ3zPqzy+aeL2+3kvR9ZUdqqtLZ9BXdvSuq9e22U1l2Hr1HV1f2fF5t3Xb Pu+O2aIfQ2hD790Efd9SfvZ+VwX1s4e1g3danG+ld68/++pBH98rfWTS92zRjyG0ofdugr5vqdLP jHpnx7PSs49b6d2D3j3o41b6yKTv2aIfQ2hD790Efd9SpZ8Z9c6gj1vp3YPePejjVvrIpO/Zoh9D aEPv3QR931Klnxn1zqCPW+ndg9496ONW+sik79miH0NoQ+/dBH3fUqWfGfXOoI9b6d2D3j3o41b6 yKTv2aIfQ2hD790Efd9SpZ8Z9c6gj1vp3YPePejjVvrIpO/Zoh9DaEPv3QR931Klnxn1zqCPW+nd g9496ONW+sik79miH0NoQ+/dBH3fUqWfGfXOoI9b6d2D3j3o41b6yKTv2aIfQ2hD790Efd9SpZ8Z 9c6gj1vp3YPePejjVvrIpO8Z9ecXTbxeX++l6PrKDtXVpTPoKzt619Vr2+ymMmy9+o6ur+z4vNu6 bZ93x2zRjyG0ofdugr5vKT97v6uC+tnD1sM7Lc630rvXn331oI/vlT4y6Xu26McQ2tB7N0Hft1Tp Z0a9s+NZ6dnHrfTuQe8e9HErfWTS92zRjyG0ofdugr5vqdLPjHpn0Met9O5B7x70cSt9ZNL3bNGP IbSh926Cvm+p0s+MemfQx6307kHvHvRxK31k0vds0Y8htKH3boK+b6nSz4x6Z9DHrfTuQe8e9HEr fWTS92zRjyG0ofdugr5vqdLPjHpn0Met9O5B7x70cSt9ZNL3bNGPIbSh926Cvm+p0s+MemfQx630 7kHvHvRxK31k0vds0Y8htKH3boK+b6nSz4x6Z9DHrfTuQe8e9HErfWTS92zRjyG0ofdugr5vqdLP jHpn0Met9O5B7x70cSt9ZNL3jPrziyZer6/3UnR9ZYfq6tIZ9JUdvevqtW12Uxm2Xn1H11d2fN5t 3bbPu2O26McQ2tB7N0Hft5Sfvd9VQf3sYevhnRbnW+nd68++etDH90ofmfQ9W/RjCG3ovZug71uq 9DOj3tnxrPTs41Z696B3D/q4lT4y6Xu26McQ2tB7N0Hft1TpZ0a9M+jjVnr3oHcP+riVPjLpe7bo xxDa0Hs3Qd+3VOlnRr0z6ONWevegdw/6uJU+Mul7tujHENrQezdB37dU6WdGvTPo41Z696B3D/q4 lT4y6Xu26McQ2tB7N0Hft1TpZ0a9M+jjVnr3oHcP+riVPjLpe7boxxDa0Hs3Qd+3VOlnRr0z6ONW evegdw/6uJU+Mul7tujHENrQezdB37dU6WdGvTPo41Z696B3D/q4lT4y6Xu26McQ2tB7N0Hft1Tp Z0a9M+jjVnr3oHcP+riVPjLpe0b9+UUTr9fXeym6vrJDdXXpDPrKjt519do2u6kMW6++o+srOz7v tm7b590xW/RjCG3ovZug71vKz97vqqB+9rD18E6L86307vVnXz3o43ulj0z6ni36MYQ29N5N0Pct VfqZUe/seFZ69nErvXvQuwd93EofmfQ9W/RjCG3ovZug71uq9DOj3hn0cSu9e9C7B33cSh+Z9D1b 9GMIbei9m6DvW6r0M6PeGfRxK7170LsHfdxKH5n0PVv0Ywht6L2boO9bqvQzo94Z9HErvXvQuwd9 3EofmfQ9W/RjCG3ovZug71uq9DOj3hn0cSu9e9C7B33cSh+Z9D1b9GMIbei9m6DvW6r0M6PeGfRx K7170LsHfdxKH5n0PVv0Ywht6L2boO9bqvQzo94Z9HErvXvQuwd93EofmfQ9W/RjCG3ovZug71uq 9DOj3hn0cSu9e9C7B33cSh+Z9D2jXttjR3+uL//bjMoO1dWlM+grO3rX1Wvb7KYybL36jq6v7Pi8 27ptn3fHbNGPIfT6Z1/voOjPvrLjp5B+7ivqnR096fsOO/+5kd69/uyrB33cSh+Z9D1b9GMIbei9 m6DvW8p/8v2uCupnT4+s/jc40set9O5B7x70cSt9ZNL3bNGPIbSh926Cvm+p0s+MemfQx6307kHv HvRxK31k0vds0Y8htKH3boK+b6nSz4x6Z9DHrfTuQe8e9HErfWTS92zRjyG0ofdugr5vqdLPjHpn 0Met9O5B7x70cSt9ZNL3bNGPIbSh926Cvm+p0s+MemfQx6307kHvHvRxK31k0vds0Y8htKH3boK+ b6nSz4x6Z9DHrfTuQe8e9HErfWTS92zRjyG0ofdugr5vqdLPjHpn0Met9O5B7x70cSt9ZNL3bNGP IbSh926Cvm+p0s+MemfQx6307kHvHvRxK31k0veM+vOLJl6vr/dSdH1lh+rq0hn0lR296+q1bXZT GbZefUfXV3Z83m3dts+7Y7boxxDa0Hs3Qd+3lJ+931VB/exh7eCdFudb6d3rz7560Mf3Sh+Z9D1b 9GMIbei9m6DvW6r0M6Pe2fGs9OzjVnr3oHcP+riVPjLpe7boxxDa0Hs3Qd+3VOlnRr0z6ONWeveg dw/6uJU+Mul7tujHENrQezdB37dU6WdGvTPo41Z696B3D/q4lT4y6Xu26McQ2tB7N0Hft1TpZ0a9 M+jjVnr3oHcP+riVPjLpe7boxxDa0Hs3Qd+3VOlnRr0z6ONWevegdw/6uJU+Mul7tujHENrQezdB 37dU6WdGvTPo41Z696B3D/q4lT4y6Xu26McQ2tB7N0Hft1TpZ0a9M+jjVnr3oHcP+riVPjLpe7bo xxDa0Hs3Qd+3VOlnRr0z6ONWevegdw/6uJU+Mul7Bv3bvfdmzDr/Xu9bdqiuKuv6b9nRu66sbbOb yvrWq0z/LzTq74X+/C07Pu/2N7I7Zot+DKFXP/u39Q6K9uy/ZcdPIf3cV9Q7O3rS9x12/nMjvXvt 2VdGfdxKH5n0PVv0Ywht6L2boO9bav7Jf1vvvmjvSPuWQR+30s+Mz949PPu4lT4y6Xu26McQ2tB7 N0Hft1TpZ8Zn7wz6uJXePTx796CPW+kjk75ni34MoQ29dxP0fUuVfmbUO4M+bqV3D3r3oI9b6SOT vmeLfgyhDb13E/R9S5V+ZtQ7gz5upXcPevegj1vpI5O+Z4t+DKENvXcT9H1LlX5m1DuDPm6ldw96 96CPW+kjk75ni34MoQ29dxP0fUuVfmbUO4M+bqV3D3r3oI9b6SOTvmeLfgyhDb13E/R9S5V+ZtQ7 gz5upXcPevegj1vpI5O+Z4t+DKENvXcT9H1LlX5m1DuDPm6ldw9696CPW+kjk75n1J9fPvF6fb2r ousrO1RXb51BX9nRu64etl71ur6+o+srOz7v9jc+747Zoh9DaEPv3QR931J+9vXui752Kjt+Wunj 9qYyrJ3qQR+30kcmfc8W/RhCG3rvJuj7lir9zPjsnUEft9K7h2fvHvRxK31k0vds0Y8htKH3boK+ b6nSz4x6Z9DHrfTuQe8e9HErfWTS92zRjyG0ofdugr5vqdLPjHpn0Met9O5B7x70cSt9ZNL3bNGP IbSh926Cvm+p0s+MemfQx6307kHvHvRxK31k0vds0Y8htKH3boK+b6nSz4x6Z9DHrfTuQe8e9HEr fWTS92zRjyG0ofdugr5vqdLPjHpn0Met9O5B7x70cSt9ZNL3bNGPIbSh926Cvm+p0s+MemfQx630 7kHvHvRxK31k0vds0Y8htKH3boK+b6nSz4x6Z9DHrfTuQe8e9HErfWTS92zqv/v66XR6+dP9y/0P fzj/41+fn15OP708PH1+8/X0qH/6z6ef/nn6cHV6fPz6/mIMhnP6t8+PzPX3bL+cnj+ezsU3Pz39 +vnl/cXbi5a+eT79/P7ij9+/+/H8e/at7fzf3/14Nq355bsfL8ff4q3523c/njfUd99+4esPf/hy //H0l/vnjw+fv755PP2sH+F3/6b/sHt++Pip/vnl6YvTfzy9vDz94n/z6XT/4fR8/jfff//73/3H 8S+Zf37Sb8r/84v60ca3/vfp5dcvb77+dP94en8x/k8If354/vryV/3Kf/36yz/Oxxdvnp4fTp9f 7sfv7vuLx/vPH9T/crp480m/8H9P+pXHP3150F+Xjr9l/Z/T88uDPu5Int89fHh/8Xz74fz7N3/g m/NP9ub+8eHj578/vHwyXo7xe/bd/z49//P8WH/4lwAAAAD//wMAUEsDBBQABgAIAAAAIQDRLb9x 6AQAAP4NAAAUAAAAeGwvc2hhcmVkU3RyaW5ncy54bWy8V2tP40YU/V6p/+HKfChUELPQl1DwigbQ Im2XiLA/YGLfJLO1Z9yZcSD763vGY5vECYVdoSII8Z3XfZxz7nj4/rHIacnGSq3Oo3eD44hYpTqT an4efb6/PvojIuuEykSuFZ9HK7bR++THH4bWOsJaZc+jhXPlWRzbdMGFsANdssLITJtCODyaeWxL wyKzC2ZX5PHJ8fFvcSGkiijVlXLn0ekvEVVK/lPxqDGcRsnQymToks+fRh8vJpOb65ury2HskmHs 7WHs52ttsEdRsHKE04x8JKmsM1XqEJA9JMtM0c2aKSInpiQcTbVzuqCcZ27Q33fUbLnXHxiLOVPP auClT8WZLUWKFCFWy2bJUTK+HdGNmukz2voJG2Op/x3jYxonQ4k/+5WWIkcpjiM8mWuNyGrDhZEi 97aZKGS+CsYTb4jrDVxya+ZCya/Ch35In0TBh3QvXY5/4wWqd0hXyHreHd0l8vkI2kTcr0o+o27l Gzp9kRVSSZQMbi+Z9i8OKKZJNfWgC5aJt4yMdDIVOe2PDjo3ugBccpGmXLow8oSPO/7C6Za1Deqv AJh1dGxu8HxexkYvZcYk8rzFn6WZAZ5WujKUcSmMq1EJgIIBXV0ATxK7E7lZ+VTnWCpVxo+cfRcc LDjsa5+CCDqXmXCcdalbr+Dmwd8Cud2wb5jYsAonrdVppPOqUHTJNjWyrEm6mfNnqNTWbO+oheFT lScLXeUZauFFZkVTlKUCtQEoAAZMUVUxZcPZIU0rR26B72TDGswFMZoZBMkiFukCqoH6IV9tbfsC sTvuIA4A6xiL50aUC9rD00eJE/Zo228vXvVxeua9skynONDnB8JV5ixgcSCeH2xdxJKcnWMPjdoe FuArJO1BAo6O8VFZeqjjBBxJIF7DMzYGiCCn26WZTiuP0VdG14iZV3UIzHY4LSe8t1C+nywpSBCh d4QA8BCL6dTwUtY7UAh7gx7xE3MGFDb0PgtLRYW6AMpOpA4BhO4CP/xYqa2V05xDAhaclz4BQAOW NN74sDNp08raQNE0SLx9XfAt/NZ1sAXg8yrhZ7+G699CuSS6iLZY/OYMljUiW/iTtGJTpj1yM+m0 70mHqCA1C6S1FWM6Ke3IyrmSM5AQLYyVruaohqYHYYy31EKpp16gfRkx4ktVQqnSFc21LzuKjNlZ U6J1IXkh59Ek2s77WyfJq4Vda1QtokI+fCJsQ8taniA1r0gI7hcqXYE7gHrKRrVCtZGbNjEe+9IO nkLthNbnJ6nhF43+B7j4VEDPQ4d+IQ+pqKBrdfVDsL70SqsjH3FlOmx3sfx3R7B9IXoBGpDN+uzS aMgGZ5QuhJqzV9y6p3vc2ZJTD1yUd44h9E3KMamCvwN6yjZO6q5u3w+u5I5DxrK1YyB3uF/D7jXN Lep7Rt/jHbRwyV0trSLns15bTYKaej0mfiwRTxDhmL7gqJqmNQ99KXcm6HVCea9JZOjFGdQBtMaF zegH8CCwO1zR+xWD13K+QLig/t9tc5oJ3+lmjvbnhlcHyEV9cfDdxHIO0aAIN302btDgu5Vjl4SG 24+/y0x/YNR0gp59d4/vdtm60b/S0DslufavSTndoSvyA7W+UHM39dWYTD7Q1bi3brd3dAn1vcTF BW8co9s/6fh33LRS9tcfOjl+9+vTJjHe35J/AQAA//8DAFBLAwQUAAYACAAAACEAdyLIAGQBAACd AgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAfJJfS8MwFMXfBb9DybNtmm1uI7QdqOxpg4EVxbeQ3K3BJi1JtNu3N+3WWv/gYzjn/nLO5Sar oyqDDzBWVjpFJIpRAJpXQupDip7ydbhEgXVMC1ZWGlJ0AotW2fVVwmvKKwM7U9VgnAQbeJK2lNcp KpyrKcaWF6CYjbxDe3FfGcWcf5oDrhl/YwfAkzieYwWOCeYYboFhPRDRBSn4gKzfTdkBBMdQggLt LCYRwV9eB0bZPwc6ZeRU0p1q3+kSd8wW/CwO7qOVg7FpmqiZdjF8foJftpvHrmoodbsrDihLBKfc AHOVybbMOXYTbCUvGJTBJsEjsV1kyazb+p3vJYi7UyZUwUogCf4t9e6dkdqByCYxiUMyCcltTuZ0 Nqdk+jrM9Safpat+DgQi8GXouXqvPE/vH/I1+slb0Hjmeb2rK+R/HYDqEvp/4m2bMCY5WdJ4QQkZ EXtA1oX+flDZJwAAAP//AwBQSwMEFAAGAAgAAAAhADYUTvKdAAAA+AMAACcAAAB4bC9wcmludGVy U2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5iaW4KZkhlyGNIYVBgCGHIB5L+QF4qgx+QXQKkFRiM GAwYDBmMGXABRhZmtjsMMszM+gwMTAyMDK+48jlSgDQ/QwQTiB/BxAwkfYBmlYBNLMJlEAnijFC1 IJoJiEH0fyCACsMpF0+/UCWGA0DXMTCsEb5xAC6BhcEKFmPHIjMqNFJCAJauiPHvAaCiYN8QL5Ba AYYNIGpIAQAAAAD//wMAUEsDBBQABgAIAAAAIQBGdgBT3gEAAHkEAAAQAAgBZG9jUHJvcHMvYXBw LnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxUTW/bMAy9D9h/8HTpqZHT ZR8IZBVduqEFti5o0u4YaDIdC7UlQ2LcZL++srUkTuYM2G4U+fD4+ESJXa7LIqrBOmV0QoaDmESg pUmVXibkYf7l/COJHAqdisJoSMgGHLnkr1+xqTUVWFTgIk+hXUJyxGpMqZM5lMINfFn7SmZsKdAf 7ZKaLFMSro1claCRXsTxewprBJ1Cel7tCElgHNf4v6SpkY0+9zjfVF4wZ1dVVSgp0E/JvylpjTMZ Rp/XEgpGu0Xm1c1ArqzCDY8Z7R7ZTIoCJp6YZ6JwwOg+wW5ANKZNhbKOsxrHNUg0NnLql7dtRKKf wkEjJyG1sEpo9LIaWDi0cVE5tPyHsU8uB0DHqAeEZBt2sd1YjfhFC/DBX4GB606UkEb3Qi/hX1q8 62/RaAyz+t6HLswVFuC+Z1NhsceUD11TWmnBkqByYspSIQJE91AreG67/zZjZ8ut9o6tZHOvB6Ps AO0VLz6tVIG3ejG1SuPiyoJYDHv5TsKDv8ft++Bh6BP8Z8dTnb3Za+pV1J3wBPbgBo48/6r0k3uo 5uZaIGzX9jDJZrmwkPpN39b3CXbjN9YWDckkbxYm3WL+LDSP7DH8JHw4GsRvY/9+OjlG938GfwEA AP//AwBQSwECLQAUAAYACAAAACEAIYxGOnYBAACMBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAAAAAAAAAAAAAAAAK8D AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBKqaZh+gAAAEcDAAAaAAAAAAAAAAAAAAAAANUG AAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQBJLmVQxgEAAAUEAAAP AAAAAAAAAAAAAAAAAA8JAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAAACEA3kYnoEwIAACj WgAADQAAAAAAAAAAAAAAAAACCwAAeGwvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQA7bTJLwQAA AEIBAAAjAAAAAAAAAAAAAAAAAHkTAAB4bC93b3Jrc2hlZXRzL19yZWxzL3NoZWV0MS54bWwucmVs c1BLAQItABQABgAIAAAAIQDvOM6r/wYAAH4eAAAYAAAAAAAAAAAAAAAAAHsUAAB4bC93b3Jrc2hl ZXRzL3NoZWV0Mi54bWxQSwECLQAUAAYACAAAACEAsBH8w4QHAABBIAAAEwAAAAAAAAAAAAAAAACw GwAAeGwvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQDt5jVwvkAAAJ6xAQAYAAAAAAAA AAAAAAAAAGUjAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECLQAUAAYACAAAACEA0S2/cegE AAD+DQAAFAAAAAAAAAAAAAAAAABZZAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAA ACEAdyLIAGQBAACdAgAAEQAAAAAAAAAAAAAAAABzaQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAU AAYACAAAACEANhRO8p0AAAD4AwAAJwAAAAAAAAAAAAAAAAAObAAAeGwvcHJpbnRlclNldHRpbmdz L3ByaW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAEZ2AFPeAQAAeQQAABAAAAAAAAAA AAAAAAAA8GwAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAA0ADQBsAwAABHAAAAAA --_005_822659277DDF4FC48E50F5305D371336junipernet_ Content-Type: text/html; name="ATT00001.htm" Content-Description: ATT00001.htm Content-Disposition: attachment; filename="ATT00001.htm"; size=708; creation-date="Sat, 05 Dec 2015 21:03:07 GMT"; modification-date="Sat, 05 Dec 2015 21:03:07 GMT" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWwgY2hhcnNldD11cy1hc2NpaSI+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWwgY2hhcnNldD11cy1hc2NpaSI+PC9oZWFkPjxib2R5IHN0eWxlPSJ3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1s aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGRp dj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48ZGl2IGNsYXNzPSIiPjwvZGl2Pjwv YmxvY2txdW90ZT48L2Rpdj48YnIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0 ZS1zcGFjZTogcHJlOyI+CTwvc3Bhbj5FbmpveSE8L2Rpdj48ZGl2IGNsYXNzPSIiPjxzcGFuIGNs YXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij4JPC9zcGFuPi0t Jm5ic3A7TWFyazwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2Pjxi ciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQoNCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPjwvZGl2PjwvYm9keT48L2h0bWw+ --_005_822659277DDF4FC48E50F5305D371336junipernet_-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 15:31:14 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8241AC3A1 for ; Sat, 5 Dec 2015 15:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWNgkGHrr3Nu for ; Sat, 5 Dec 2015 15:31:11 -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 33DE01AC39D for ; Sat, 5 Dec 2015 15:31:11 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 68E4485F0C; Sat, 5 Dec 2015 23:31: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 8A51D85EFC for ; Sat, 5 Dec 2015 23:31: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 8UygbMBEWhao for ; Sat, 5 Dec 2015 23:31: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 6EFAE85E57 for ; Sat, 5 Dec 2015 23:31: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=1449358267; x=1480894267; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dK6gQ03gAWofKIMrKLPLU+oOLU76GppTtj8wh0bFirM=; b=ETze42II3oau8U6lyh0oA9sCeSxPzhGExVb8qCv96Q3XhKb60edmsU1P 52eViMN5S4ITij6vti5mDYQTOo5+OLz/p/801VXtF5n7QTYBziJQS9iY6 fyezKXrQTFMjBIBs64pniUurb2LkNtjgUnfMNZLCi1OCaO3u/8nLMEY5r pUP7AIYMjTw0j1liqR+9uBDf+r2nolyjoMQJc4dgdeKLjAwxIO34op/5C OwvbNsQ0o8mrEsW7zKSNwlhKB3rLTNd32Ho/IypTDKcVw08hIPeGgn/DK oIChDl0ktrM06++AbGdN2CsBUdQHrZIbsyYjFq09Nkp0ts/QdFr1h4IYU w==; X-IronPort-AV: E=Sophos;i="5.20,387,1444647600"; d="scan'208";a="57770828" 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; 06 Dec 2015 12:31:00 +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, 6 Dec 2015 12:30:59 +1300 From: Peter Gutmann To: denis bider , Damien Miller , Simon Tatham , =?iso-8859-1?Q?Niels_M=F6ller?= , Simon Josefsson , "ietf-ssh@netbsd.org" Subject: RE: SSH v3? Thread-Topic: SSH v3? Thread-Index: AQHRLCBxa1dVWM0hO02hXU7458W5dZ69EXzl Date: Sat, 5 Dec 2015 23:30:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9B35B@uxcn10-5.UoA.auckland.ac.nz> References: <1493720992-1452@skroderider.denisbider.com> In-Reply-To: <1493720992-1452@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= >Do you guys want to work on this?=0A= =0A= Argh, no! Look over to the TLS WG for the train wreck that "TLS 1.3" has= =0A= turned into, incorporating every hipster algorithm and pet idea from everyo= ne=0A= on the mailing list. Not only is it no longer "TLS 1.anything", it barely= =0A= qualifies as TLS 2.0, more like a completely new protocol. It's going to e= nd=0A= up in the weird parallel existence that IPv4/v6 have been stuck in for the= =0A= past 15 years, and that HTTP4Google, a.k.a. HTTP 2.0, will be in for the=0A= indefinite future.=0A= =0A= If you really want to design a new protocol, you can contribute to the TLS= =0A= "1.3" clusterfsck :-).=0A= =0A= Peter.=0A= =0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 15:37:25 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B0F1AC3D3 for ; Sat, 5 Dec 2015 15:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJFQT2jW56Vq for ; Sat, 5 Dec 2015 15:37:24 -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 A7B8B1AC3CD for ; Sat, 5 Dec 2015 15:37:24 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E79B885F05; Sat, 5 Dec 2015 23:37:23 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A717985EFC for ; Sat, 5 Dec 2015 23:37:21 +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 RJpBygd0FRGn for ; Sat, 5 Dec 2015 23:37:21 +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 AB0A685E57 for ; Sat, 5 Dec 2015 23:37:19 +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=1449358641; x=1480894641; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WTY/RBuItMVVnxtxN2vqssR0wUJfiFex6Vj7U0qbEQc=; b=weMcs/QG/ieKKcMJqmQYSN0bJyRVrX0SOmy29WhtthbFOX4RMZwQZosX CuptkkfvQ/8V9h9tk5UtP/elS9qHNVMiHvg5f/7kuMgnm2SqfQQQFQ5ga Yg3Ib+638s5tpDdBRKwvH6/FJ8YykSnvZ9PW0pOG3x+v4nB2GoEsbqvgt 2qB9D/SSpkR2bgZDN2IC7yvdzkQLIPvkmlc4Bwb63psZYDkyq7ePbJ6Ss SXufGvFw113bEHl8Ao6iNCWcn739wjBcXStVRpiE6VGFazPdv/cH2M7H3 9ajrr2X3ronqSgf19csF2Mq0s6WPp+XRr3IROFK+/kFGcsZz0ylxY5fP/ g==; X-IronPort-AV: E=Sophos;i="5.20,387,1444647600"; d="scan'208";a="57771195" 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; 06 Dec 2015 12:37:18 +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; Sun, 6 Dec 2015 12:37:18 +1300 From: Peter Gutmann To: denis bider , =?iso-8859-1?Q?Niels_M=F6ller?= , Damien Miller , Simon Tatham , Simon Josefsson , "ietf-ssh@netbsd.org" Subject: RE: SSH v3? Thread-Topic: SSH v3? Thread-Index: AQHRLIbka1dVWM0hO02hXU7458W5dZ69EmeR Date: Sat, 5 Dec 2015 23:37:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9B36D@uxcn10-5.UoA.auckland.ac.nz> References: <1537810400-3144@skroderider.denisbider.com> In-Reply-To: <1537810400-3144@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= >TCP is neither reliable, nor secure. Its weaknesses break SSH sessions bey= ond=0A= >recovery. It's the single biggest weakness of SSH in practice.=0A= =0A= TCP is good enough for most purposes. SSH's initial purpose was to replace= =0A= telnet and FTP, which a TCP-based mechanism does admirably. It's only when= =0A= SSH2 tried to also be a VPN that problems arose. So for people using it fo= r=0A= its initial purpose, it's just fine.=0A= =0A= Another problem with switching to UDP is that you now have to emulate TCP's= =0A= reliable transport using UDP. Your SSH implementation needs to reinvent a = lot=0A= of TCP just to work, which is a lot of pain and complexity to deal with. N= ot=0A= to mention that every single new implementation gets to make all the mistak= es=0A= that have been bred out of TCP stacks over the last 20-30 years all over=0A= again.=0A= =0A= (I don't really have anything against an option to do SSH over UDP if peopl= e=0A= want to, which means you've now got SSH trying to compete with both IPsec a= nd=0A= DTLS, but I don't want to see it made mandatory. Approximately, oh, 100.0%= of=0A= my users use SSH as a secure telnet and FTP, not a VPN).=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 5 15:42:38 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448491AC3F5 for ; Sat, 5 Dec 2015 15:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6JW-6bul01U for ; Sat, 5 Dec 2015 15:42: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 3FB3D1AC3F2 for ; Sat, 5 Dec 2015 15:42:37 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6A50B85F08; Sat, 5 Dec 2015 23:42:36 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7590D85EFC for ; Sat, 5 Dec 2015 23:42:34 +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 XcAzKiDVcTY1 for ; Sat, 5 Dec 2015 23:42:33 +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 2329785E57 for ; Sat, 5 Dec 2015 23:42:32 +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=1449358953; x=1480894953; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Fi4svz4FhEH3Zkbs1PIjXe+O+hN+NojVeAgtqsFR95U=; b=WzxC/4I6NjyiiI4SvXwWdi91v+kp6QOPaG0nOI405A1oBoZwBwrtgup6 5oVP1bKJAeZymelAVowYwek4/l9q2YhfKFzCg+KvTPKJF6D2xOnOs0dgN u/2Y3BBox7dTiHEuglJgKVvmt/thTgzwNafP0pJWsju2W2W8U8SV6VCdY QGdlmuPVz1OX4H6svF2nmEqVtO92/ND17ivHqHYoRUzn4+O8IBov41dgR EzNcwsZR678yD/wyy0ThcUBhAJjogGzjCD5HsCbHPmldqZ8bbCZjezjw/ XuaHf9cYOcu3hJQWhKYR8fQJY94q+agyhgXjJRJwfxngZAyoMM2doH2o8 g==; X-IronPort-AV: E=Sophos;i="5.20,387,1444647600"; d="scan'208";a="57771440" 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; 06 Dec 2015 12:42:31 +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; Sun, 6 Dec 2015 12:42:31 +1300 From: Peter Gutmann To: Damien Miller , denis bider CC: Markus Friedl , "ietf-ssh@netbsd.org" Subject: RE: Feedback on draft-ssh-ext-info-00 Thread-Topic: Feedback on draft-ssh-ext-info-00 Thread-Index: AQHRLX0POk6t5sv1I0ywABy5Xd0b7J63yusAgAVHG+k= Date: Sat, 5 Dec 2015 23:42:30 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9B382@uxcn10-5.UoA.auckland.ac.nz> References: <1642890958-3540@skroderider.denisbider.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="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= >I'll repeat my opinion: an extension mechanism is not the place to=0A= >fundamentally retcon parts of the protocol. =0A= =0A= Why not? I would have thought that's what it was there for. TLS has been= =0A= using extensions to fix protocol problems for years without any real proble= ms.=0A= Taking one case that I'm pretty familiar with, the encrypt-then-MAC extensi= on,=0A= the impact was very minimal, you add an entry to an extension en/decoding= =0A= table, and then have a boolean flag to swap the order of calls to encrypt a= nd=0A= MAC routines. It was, I dunno, maybe a dozen lines of code and a hour's wo= rk=0A= to fix a problem that had been plagueing the protocol for at least fifteen= =0A= years. It's a really easy way to fix issues in the protocol, I just wish S= SH=0A= had had an extension mechanism of the kind that Denis is working on a long= =0A= time ago.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Dec 6 06:07:36 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543DA1A1BE4 for ; Sun, 6 Dec 2015 06:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEESv3EdWQvJ for ; Sun, 6 Dec 2015 06:07: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 5AE661A1BF2 for ; Sun, 6 Dec 2015 06:07:33 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2CD6085E13; Sun, 6 Dec 2015 14:07:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B0FC685E0B for ; Sun, 6 Dec 2015 14:07:30 +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 VuONQxryyPmm for ; Sun, 6 Dec 2015 14:07:30 +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 A2C0985DF8 for ; Sun, 6 Dec 2015 14:07:25 +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=1449410850; x=1480946850; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qmHCFkziv5gl313KiR1oCrAtuJB/Pln/LQc2qKfPoAA=; b=sSVDtQG9Df+QFzsOp8HHHJI9yHT/O40xzgnxuhRPDSbp1oK5gKTXV+hT xuGVmdYoXQJlRYU1D/zV34xLVxqMBOYm9s7NxFU+ddIviz3lRYKyxE6sx auIyeDONiMpPWyzqLoy5gsUAQQVvxUlMvnhVezWmHSUqZWPYfeAqUWTOR dCPYOLcnf5KYjTsPR7slz17c09WA5kDvqOJNsO5BjIkWTUa8pxfeMPaU/ eZ1FaShxDVFc1cmQhOzb7PRpl+DIdGPTI4SHA2fNdVb7Bg0pzYMgcIuF7 C7necpRqIuKTk0vnQtRDu5INZyi+bfyrT3l8vTOaHqQdvsI0U+xT0LSM7 w==; X-IronPort-AV: E=Sophos;i="5.20,390,1444647600"; d="scan'208";a="57815820" 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; 07 Dec 2015 03:07:24 +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; Mon, 7 Dec 2015 03:07:23 +1300 From: Peter Gutmann To: Stephen Farrell , "ietf-ssh@netbsd.org" Subject: RE: SSH v3? Thread-Topic: SSH v3? Thread-Index: AQHRLCBxa1dVWM0hO02hXU7458W5dZ69EXzlgAAXQoCAAN1ksQ== Date: Sun, 6 Dec 2015 14:07:21 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BA08A6@uxcn10-5.UoA.auckland.ac.nz> References: <1493720992-1452@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B35B@uxcn10-5.UoA.auckland.ac.nz>,<56643DCF.9090705@cs.tcd.ie> In-Reply-To: <56643DCF.9090705@cs.tcd.ie> 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 Stephen Farrell writes:=0A= =0A= >my belief is that you and maybe one or two others share that opinion about= =0A= >TLS1.3=0A= =0A= Oh, it's quite a lot more than "one or two others". Most of them have give= n=0A= up contributing to the TLS discussion though, so it's not very visible outs= ide=0A= of private email.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Dec 6 07:12:35 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0C51A8BB1 for ; Sun, 6 Dec 2015 07:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCzxm5aqNMqg for ; Sun, 6 Dec 2015 07:12:34 -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 DC5221A8ADA for ; Sun, 6 Dec 2015 07:12:34 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id DD9AD85E59; Sun, 6 Dec 2015 15:12:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6AB6D85E57 for ; Sun, 6 Dec 2015 15:12:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id kT10_deJSo3v for ; Sun, 6 Dec 2015 15:12:31 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A26A285E13 for ; Sun, 6 Dec 2015 15:12:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3D28EBE2F; Sun, 6 Dec 2015 13:53:21 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5y0mSRTrC-W; Sun, 6 Dec 2015 13:53:20 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.30.27]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 72DA0BE2C; Sun, 6 Dec 2015 13:53:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449410000; bh=jsupPSIaydghK1v+Z42aB2HfHaCoOjQATSuI8SDTNtY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BNg005nC0QtKTE2CCJwsKFNC2SNDL8N1mfQAijb4XcgY93le2IPg7WIexF5jyJpqk KDQDqUHVGdUpSsodhI8ISJIpbEWpudOuBbxrayRiyViGimqo7mxa6ZRsv0oAsE0zjp TyEJ05NCL0MjyS3E2XT4EapT9dBaSsBxSan3xAic= Subject: Re: SSH v3? To: Peter Gutmann , denis bider , Damien Miller , Simon Tatham , =?UTF-8?Q?Niels_M=c3=b6ller?= , Simon Josefsson , "ietf-ssh@netbsd.org" References: <1493720992-1452@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B35B@uxcn10-5.UoA.auckland.ac.nz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56643DCF.9090705@cs.tcd.ie> Date: Sun, 6 Dec 2015 13:53:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B35B@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Peter, On 05/12/15 23:30, Peter Gutmann wrote: > train wreck that "TLS 1.3" FWIW, my belief is that you and maybe one or two others share that opinion about TLS1.3. Many people are working on it, I assume, on the basis that they want it to be widely deployed. We should start to know whether TLS1.3 will see widespread deployment in about a year or so and will be able to reach sensible conclusions about that in maybe 3 or 4 years. But I guess your crystal ball is better than mine and you know the answer already;-) S. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Dec 6 07:32:39 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41F51ACCF8 for ; Sun, 6 Dec 2015 07:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQerbf48wo9I for ; Sun, 6 Dec 2015 07:32:38 -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 C1F501ACCF3 for ; Sun, 6 Dec 2015 07:32:38 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 8688785E6F; Sun, 6 Dec 2015 15:32:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B05AF85E6B for ; Sun, 6 Dec 2015 15:32:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id IXynQF2w_-qZ for ; Sun, 6 Dec 2015 15:32:30 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id DF4FC85E47 for ; Sun, 6 Dec 2015 15:32:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E2B9DBE49; Sun, 6 Dec 2015 14:14:54 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAMUPmLYXz4q; Sun, 6 Dec 2015 14:14:53 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.30.27]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 195D2BE38; Sun, 6 Dec 2015 14:14:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449411293; bh=ghLeX/GO7X/68qkgFoPUlG7grjbP08SMcQQXQAO6GnU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=18vC+AYXgXN5L4ybhuUaI/B/CTcK1Q9rllZltYpcjB3/AAIpSc4XKrpCDNHsmrXZn HIGlDBcEqgkDz1gKZrL+zBdTI8rFwNWJIABUYIPPRnD+bfiVoDArJNVNW9YXmTvDuE qy0kfyqeH9Gmp54yJaM6Vv7ue69tzA85oyQPUSr0= Subject: Re: SSH v3? To: Peter Gutmann , "ietf-ssh@netbsd.org" References: <1493720992-1452@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B35B@uxcn10-5.UoA.auckland.ac.nz> <56643DCF.9090705@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73F4BA08A6@uxcn10-5.UoA.auckland.ac.nz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <566442DC.5000702@cs.tcd.ie> Date: Sun, 6 Dec 2015 14:14:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BA08A6@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 06/12/15 14:07, Peter Gutmann wrote: > Stephen Farrell writes: > >> my belief is that you and maybe one or two others share that opinion about >> TLS1.3 > > Oh, it's quite a lot more than "one or two others". Most of them have given > up contributing to the TLS discussion though, so it's not very visible outside > of private email. Could be, but we'll not know for some time as I said. (It's also interesting that about every new or major change in the IETF seems to see that same point made, but such is life.) S. > > Peter. > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Dec 6 15:32:18 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3401A1A0119 for ; Sun, 6 Dec 2015 15:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIAEB7nxQPUF for ; Sun, 6 Dec 2015 15:32:17 -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 0ACA31A0115 for ; Sun, 6 Dec 2015 15:32:17 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C2FCD85EE9; Sun, 6 Dec 2015 23:32:15 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3DCAD85E47 for ; Sun, 6 Dec 2015 23:32:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 aU8JWqzjZdZy for ; Sun, 6 Dec 2015 23:32:12 +0000 (UTC) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by mail.netbsd.org (Postfix) with ESMTP id 4376A85E13 for ; Sun, 6 Dec 2015 23:32:11 +0000 (UTC) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 0354318343C; Sun, 6 Dec 2015 23:13:28 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 0354318343C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1449440009; bh=pC+EZw0YlWmvfsJZu9SsY4D2MvBVfaCUorTQ8FUXmHU=; h=Reply-To:Subject:References:To:Cc:From:Message-ID:Date: MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UYIUfZ18pWrjO2gKrJ7i3wBOvgEddOjq2Ar9w2XT/vNV7Sug7mhwvROiXOXIvQkDe XugBqVChB07QZP3GtmrAip/qWnG4fAzpHzm36DmT/65o+dSS/LOJZAmprHkXsUER2M 0cdNiyIony9TNZq2g4fJ2gjVD5wT4Tj9laUbvr1s= Reply-To: Olivier.Bonaventure@uclouvain.be Subject: Re: SSH v3? References: <1537810400-3144@skroderider.denisbider.com> To: =?UTF-8?Q?Niels_M=c3=b6ller?= , denis bider Cc: Damien Miller , Simon Tatham , Simon Josefsson , ietf-ssh@netbsd.org From: Olivier Bonaventure Message-ID: <5664B308.6050605@uclouvain.be> Date: Sun, 6 Dec 2015 23:13:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 0354318343C.A09ED X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels, Denis, > >> - On connections prone to random errors (wireless), large transfers >> are bound for disconnects at a rate of 2^-16 per error. TCP just >> corrupts the data in this case. SSH detects the corruption, but cannot >> recover from it. >> - A TCP connection can be reset by a single spoofed RST packet from >> anyone who knows the IP address and port number of one of the end >> points. > > So you're basically saying that tcp sucks. That's not very ssh specific. > > Maybe it would make sense with some mechanism to let ssh reconnect after > a tcp connection fails. You may also want to have a look at mptcp, > which, among other things, can let a connection survive failure of a > single tcp flow. Indeed, mptcp can cope with several of the issues that you mention. Upon reception of a (spurious, fake, middlebox-generated,...) RST, MPTCP can preserve the connection and restablish a subflow. MPTCP is also able to use different paths simultaneously, which brings interesting benefits and challenges from a security viewpoint. MPTCP has been standardised by the IETF (RFC6824), and there are implementations for Linux (http://www.multipath-tcp.org), Apple (iOS and Macos ship it but only enable it for Siri), FreeBSD (partial) and Oracle. It is also possible to better integrate a security protocol like SSH with the underlying MPTCP. I wrote a first step in this direction last year for TLS : https://tools.ietf.org/html/draft-bonaventure-mptcp-tls-00 A similar approach could be used for SSH. Basically, the main idea is to delegate the authentication of the received data to MPTCP so that MPTCP can detect packet errors and recover at this layer (e.g. by releasing a subflow and restating another one) without forcing the security protocol to terminate the session because an invalid data was received. Olivier From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Dec 9 03:29:09 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9389F1A6FB9 for ; Wed, 9 Dec 2015 03:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfU5s7G3G54O for ; Wed, 9 Dec 2015 03:29: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 D10221A6FAC for ; Wed, 9 Dec 2015 03:29:07 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 715A985E85; Wed, 9 Dec 2015 11:29: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 CF05685E63 for ; Wed, 9 Dec 2015 11:29:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id lzHPfMLG3rtw for ; Wed, 9 Dec 2015 11:29:04 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 00ABC85E1A for ; Wed, 9 Dec 2015 11:29:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6C590BE5C for ; Wed, 9 Dec 2015 11:28:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOPpJK-8XpiT for ; Wed, 9 Dec 2015 11:28:58 +0000 (GMT) Received: from [10.14.104.136] (unknown [136.173.180.16]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A74BBE54 for ; Wed, 9 Dec 2015 11:28:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449660538; bh=jD9VLtdmzOPa0g53tEbDyA486+5q7A6+jezRff2SPwg=; h=To:From:Subject:Date:From; b=xC8vREi9Gw6hCUBNxXF2gBDYtuf24Ob9ozucao7iCjYa/fGDbbFGeQIpOaahouIet IJ5JYhCKg2ETZSTNR7vd7E6+Eos3uRjST/7AEVXIBtxP4RDoLJSVwQe2jHEewN+Kep +JZ2E6l4OodJpyiOijaxejb6Wkrq9A2VMU6jbyHE= To: "ietf-ssh@netbsd.org" From: Stephen Farrell Subject: curdle wg-in-formation Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56681079.4020307@cs.tcd.ie> Date: Wed, 9 Dec 2015 11:28:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hiya, (Tom Petch pointed out that I'd not sent a mail to this list, which I should have done before, sorry.) There are a bunch of internet drafts related to assigning code points for curve25519 in various IETF protocols. The IETF is considering handling those (and a few other odds and ends) via a new working group. See [1] for details of the drafts and the proposed charter. Some of that relates to SSH, hence this mail, so comments are welcome, preferably before Dec 17th. Sending comments here or to curdle@ietf.org are both fine. (Or to ietf@ietf.org if you want.) Cheers, S. [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 10 05:50:44 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0421B1A92FB for ; Thu, 10 Dec 2015 05:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdzleXo-0MDk for ; Thu, 10 Dec 2015 05:50:40 -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 D72B61B2DF7 for ; Thu, 10 Dec 2015 05:50:39 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 82DD785EE0; Thu, 10 Dec 2015 13:50: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 1B63785ED9 for ; Thu, 10 Dec 2015 13:50: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 GTTLiNJbV_qs for ; Thu, 10 Dec 2015 13:50:22 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc0c::735]) by mail.netbsd.org (Postfix) with ESMTP id 90FDE85EB5 for ; Thu, 10 Dec 2015 13:50:18 +0000 (UTC) Received: from CO2PR05CA045.namprd05.prod.outlook.com (10.141.241.173) by BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) with Microsoft SMTP Server (TLS) id 15.1.337.19; Thu, 10 Dec 2015 13:50:15 +0000 Received: from BL2FFO11FD013.protection.gbl (2a01:111:f400:7c09::101) by CO2PR05CA045.outlook.office365.com (2a01:111:e400:1429::45) with Microsoft SMTP Server (TLS) id 15.1.337.19 via Frontend Transport; Thu, 10 Dec 2015 13:50:15 +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-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Thu, 10 Dec 2015 13:50:14 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 10 Dec 2015 05:44:57 -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 tBADisD92058; Thu, 10 Dec 2015 05:44:54 -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 DAC7711490; Thu, 10 Dec 2015 05:44:53 -0800 (PST) To: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6ller=3F=3D?= CC: Damien Miller , Peter Gutmann , denis bider , "Jeffrey Hutzelman" , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> <67048.1447534953@eng-mail01.juniper.net> <26466.1447573713@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 "Sun, 15 Nov 2015 09:14:01 +0100." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD013;1:UJu+KuF8xdq/1hR8fVyLNvUQKBW5tCDHWmFsg+mGBDADrebaXAGU8d1etfwdPquNUnyFM09gzBRgqOCAucUf/PXCaaqLzXe5sB5zBgz30cOcxwYB+mdJnzmaBbRqyFW90vC25fivjYIJrH7ip8V/RMJlT+MGid9yHDtO4Nsr3J+hWJh19qtCrldjYFVaG7fDcuoXZ7QKU00sNmveF6PWF+6fPtTNHhsvuJ/eKXQPBNDK50Jvm8hGOT0SHpLs7i4STy+wdOmokbwunzUl55DsMFmujT+79+w8awGxsg9xfYSDh4bme8pO+iFujKsVY3TxsQ9B3RlGzFm5wYo+DtWgu6XS/5dUSqsH9HN3P4bRaMhTC6l1/cGdqVu1DWTg9uiJOndLESXVU/ZA8tdvYl+XP7BqcERBIF5x9/mhEzvatdw= X-Forefront-Antispam-Report: CIP:66.129.239.18;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(164054003)(243025005)(199003)(189002)(586003)(50986999)(87936001)(5003600100002)(50466002)(7110500001)(53416004)(97736004)(76176999)(92566002)(117636001)(77096005)(15975445007)(93886004)(2420400006)(47776003)(110136002)(5001960100002)(69596002)(81156007)(86362001)(6806005)(2950100001)(1096002)(106466001)(189998001)(105596002)(1220700001)(50226001)(76506005)(23676002)(19580395003)(19580405001)(10710500006)(11100500001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR05MB053;H:p-emfe01b-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB053;2:K1Qa6XOLJMqpaSOxhJuOhnzfuk8bjMOldGUg9jBM+DUJZJwKuN5M/2iDdE8t2SXCrdQRGxOwGKCQi0IqZ90WCOVsHcdnhd2xGZGtYX7yJ6vnEqsq4aV9lplR7ZHx7UVwASrtOZNzgDWQ5a5Sjp4gGA==;3:G8RSatlCCLe4y0e6kfAflhqKw/GVN4kOiVnIQPjOit2J0LBlkUPHxOaUV2Mipfu1SUySOnVXktgWnlhlaH69hQQT6SSdipmnzYzxCZq7pgMT3lPgmUEdVMiLB/J4Ucgk95KKV4h+jkZ/MzTJJupgUNGr+HpCrAsKlNAUhxb6fqd/qQ1AanmfUPqP2JRXcxoCumf3lI7RIv8GV5vD9cU+GmG+W1nwPAUN5WjUigsSuJc=;25:cfEjn/lX/LTiCjTQQXXNMXh6QPtGvDAXQvMN6qoQrw+AkpODKnsZoex6VzfbjpKq+M/v/gmT4tHYw4Sm/movyELaZDxaXBhXJpNkyl6LNCce49ePznSqEu8DYWVS1r7pG+hNy08tBtxo+V/AoCPN6/oBqa2Fufg78NbO9LZHU5BSyV5NqkKfjfASyxr6pewAV17+bqyMX5BEyz6rmTATl0qLI2qoccPtbHdpgodRuUAO8HQ1o99LWup4fY1FxHnQCWSotadId6QlWznzKgsnwA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB053; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB053;20:9uySAS1vjMv+kTTFpCHl46YlTAJJlH2IeMjdayMHlQpnDLIO6AT8/CENlZGzeivdSxYs1S/+byYNx0zBWUxA0AqTChPj3UP358OlA37nb10j3vRv0eORWbEIoEwCDh9/XqWC0V47k7pQMSgnD3v+7rGt2vo2uAVmVD0jS+KB9/jBsLVTmvsSNLyXl8HZ30mWesnAZNDWL/B47W3kA+iK5vVaWYJS9LquDw5q0WyCGq2UGLoFRgOoB5Rc4OnHE7HDrwRUEHUFWsj/aXz+HUdJZcOh2atdQjpVg3c2SLrSNQ3+UbRbOEOPEqY4oImi/xFy/zEwdfj1XaioQStWMvdgl75CFszonau9SXCbGpPY49+9kAaHJD3JSPFU9u/gW9k+1LcG9l6LN3AFWKRwaY0vlME1LwZYeap34rPthYL4sW9E4iXdKj18T7BqXZNGDo5PAekF8/6q2jUXQ+idj2agSlccozmB19LPx9f2KODKL4XtCnVa9xeWddPd/UZsUjbK X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(65766998875637); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001);SRVR:BLUPR05MB053;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB053; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB053;4:rULDBgLWCx5hvMeHhGtusZm0hWRqcGJx3XCVcuiTY/rikKZx+kbPHBjXH+ZUqbcZyMh6sTIztgHxgXG2qJRc1F6+qzNh9iQluHko4CELe2sUpcX9HuUi4+v10dSEq9CIizTc7RSwx81qx03nodTdtroS3/2zxTfuWrLnwdb4JcpxsKXTwcmhcR6mVNBjAkGOlHuCDUuTRWUTi7Y391OPKj2G84pNRkQ+24EiJrsG4acYp+Nhzj/fKGTm4NqA+tBN78RqVfJF1vWhqzSCIGpJotO7YpAwUp4Xwv/jj/M+bLy2dzutCDG4pZnDDZHhF/jdtw0COLQqmvgglj66QsQKgtKZGkKZo2v7JLw/lmNrcigOlUcqESfWsDXGXPobOGmpgJq1WTi6JEq72NypPGAVN7hD4xc0slI/qSTS9vnj3s0XsNK/vsYoKU5hJPaNZ9q70iffbRNIrG5foQCaGdde+Q== X-Forefront-PRVS: 078693968A X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1TUIwNTM7MjM6eEtZZmVGbzVpZjdkSTIvRG1yVExNTWlkbVpx?= =?utf-8?B?dEVpR3Nyd0dmSnBSSEhaY3dSejdqeFR4ZlJYdzN4UjJpV0lNNzlGVFhBMHhr?= =?utf-8?B?blI1ZHRrZVFPaHVQZlU3Y0FDVk5MZjNjaWp1eEFpN2F4WWhhZ3NDd3pJbThs?= =?utf-8?B?YzFZZ3lhOGIzajJBMDhPWmZIclpWWVJQMXlhUzJGWlBjaWxia1VKR2RPeGhR?= =?utf-8?B?UFVOSEFLVEVNcnFIR1dzNlJYOUxKUHdhd0FRUVVVdm1WVGoyMU1kSjFQT0pF?= =?utf-8?B?ZFZmTmJNS3JZaXVVZlJWSHFLWmI3d0hUbUlxbGlhNHloaGI2OWFZNDB4bW9i?= =?utf-8?B?T3pVYm5FaHZieHNTMmZQTDJ5RFRyTXVkSVc3NWlpT1FFUkpEMXhXb2hiMXY2?= =?utf-8?B?OHkrRjhGZjNkL2dOT0tNNUNQcDg3NURvTWRQREpQTk83ZEZ2WUVWLzZMaDlM?= =?utf-8?B?bmZ5SkZTS0t6dThINWJsQ1pvc3hobnBUVVQvRnEyUVhPdk43YzQ4S2FmNTRB?= =?utf-8?B?VEE4RUs3VXlxbnJ2azFTemROa0VVN1h1MUtUMzZtUTRmdlQ5c1JCNGRDNWo3?= =?utf-8?B?bzNyR3E3VzdEWTVNbStKY0wySU5MN294ZGlDWk1hd3krVTRuTjgxSU9FcDlC?= =?utf-8?B?VTRMbEsrZVUzSUIrWDdmWGVpcnBqTW51NkxHZUNjYUJzQXFwUjZVbHNpMnhD?= =?utf-8?B?TmpJWXFrU2VTWjNOZlBWWjlwUzJmaXVMUjh2bGs4Lzh3a3JNaXpLNVBPY3k0?= =?utf-8?B?Zm84TkE3Yms3VnUzeXhKdkttK2FHY3YzNVhOTlRSOU1wMGduT2dFS2pNWVVD?= =?utf-8?B?c2gvWk9sU2lKZGFzSHNYUjBSbG9hYkYya2thSWxRcmJQRFJUbjBxZkxKTnh4?= =?utf-8?B?Q1g3cmRVbXkrTUk5Ry9vQVk4a2trd3NaUWFFaU9FaGp1a1cwdjVVSzhPazJv?= =?utf-8?B?NGxSdVJYR1ExREozWnlnV0ljem92a3BZRzF3NjYvUktQeXRldkwzRkw1NWho?= =?utf-8?B?bGtwdWh4aFZFb0ppWDEyZzlRN1NEajM2RDNxZys4Qi9HVUo0RDJwOWNyZ2pD?= =?utf-8?B?UGhPem9wVGorMXExOGZZUHFlSENVK1hsQXNRcHFxcTV2LzN0T2I2YnhYQ1hU?= =?utf-8?B?QnY2WVdXSm02b3pGZHg1NHNNdUs2dDc4Y0hoUGZaZjhNZVRRWmZEL2M3M29j?= =?utf-8?B?Y0U4WTEyTVJjUUtObWgyVDlXaHVWL2JKQlQ4S09uY01kcyt3aWRTUFEwd3A3?= =?utf-8?B?M2pOTnZ5ODg2NlgxbkdBL0YrcVpMUlgrRmo3cjM2OHVhdGcxR2NuS3Z6Zk1p?= =?utf-8?B?QkloY2VxQzNqRCtpY0tYUXlGSjlEZm5XcHBqbEU5NWVMWHJvSjNLUXhEQlBy?= =?utf-8?B?c1Z3UnlQaEJtbmgvRUh1emt6TWJiS0djQ08rRTFhYXlvRWpqZ1cvYXIxUlh3?= =?utf-8?B?Z09OQ0gyVXR6blJFWUg5UnpTQjdkQUppV2FVV0RsOHdWMU5wc2NYRHg2YWZp?= =?utf-8?Q?hNjozYQLk9ZeNmJjfIU1mnus=3D?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB053;5:KlxbfcLo9IHYQrR1Ed4rswmgF1tjZRh8GHpvJzQz3EWwMv1no7nZHih62nA3d7oreLb9hRnbDa+KF7p5rkhhdqgxmPl7SIszwJzeUjiPYkQdXe3r+hfsALpISNLUZ1j2x355fT9VCUFsUcV6HaCqRg==;24:6jpo36mCoD/UdN/mEfyIgfwHdNSYFe0oi2xSNaL5YLf1cH79BlArjL9CCOXAqhFHgtNhBGSLU0kxpCuX7JgwEdjbzFI/pEDGHlO331Tcyjw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2015 13:50:14.1934 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB053 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels M=C3=B6ller writes: > "Mark D. Baushke" writes: > > > Given your point about sha2-384, I think there are three possibilities > > that remain: > > > > sha2-512 > > sha3-256 > > sha3-512 > > sha3-384 could also be on that list. Unlike for sha*2*-384, it's a > different security/performance tradeoff than sha3-512. > > > fwiw: I have no idea if the SSH community is ready to consider the use > > of sha3 (FIPS PUB 202 style) at this time, > > Me neither. Okay. Well, what do other folks on the list think? Is it time to add SHA3 to the SSH standard for DH Group15 and DH Group16? If so, what values make the most sense? fwiw: I do not believe that the SHA-3 family (sha3-224, SHA3-256, SHA3-512, SHAKE128 and SHAKE256) from FIPS PUB 202 have been added as an RFC yet. So, what would be the correct way to handle specification of ay of those algorithms in an Internet Draft? I can certainly write an update to RFC 4253 that moves 'diffie-hellman-group1-sha1' to 'NOT RECOMMENDED' and adds 'diffie-hellman-group14-sha256' as 'RECOMMENDED', but I am less sure about what to add for a diffie-hellman-groupNN- where groupNN are names from RFC 3526 and sha3-HHH are recommended sizes of the SHA-3 family. I suppose I could just add a or something, with SHA-3 Standard: Permutation-Based Hash and Extendable-Outp= ut Functions National Institute of Standards and Technology
Gaithersburg MD 20899-8900 US
but it seems like having an RFC defining the SHA-3 family and its security considerations first might be reasonable? Thanks, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 10 07:43:13 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3221A00CD for ; Thu, 10 Dec 2015 07:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgZrMtn6iQMU for ; Thu, 10 Dec 2015 07:43:11 -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 BAE4C1A00CA for ; Thu, 10 Dec 2015 07:43:11 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A227585EE2; Thu, 10 Dec 2015 15:43: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 86E0485E5E for ; Thu, 10 Dec 2015 15:43:08 +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 mbPQNbhR1INb for ; Thu, 10 Dec 2015 15:43:07 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::702]) by mail.netbsd.org (Postfix) with ESMTP id A0EF285E4A for ; Thu, 10 Dec 2015 15:43:01 +0000 (UTC) Received: from BLUPR05CA0064.namprd05.prod.outlook.com (10.141.20.34) by BN3PR0501MB1377.namprd05.prod.outlook.com (10.160.117.11) with Microsoft SMTP Server (TLS) id 15.1.337.19; Thu, 10 Dec 2015 15:42:58 +0000 Received: from BL2FFO11FD028.protection.gbl (2a01:111:f400:7c09::183) by BLUPR05CA0064.outlook.office365.com (2a01:111:e400:855::34) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Thu, 10 Dec 2015 15:42:58 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) 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.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BL2FFO11FD028.mail.protection.outlook.com (10.173.161.107) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Thu, 10 Dec 2015 15:42:58 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 10 Dec 2015 07:42:25 -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 tBAFgND00740; Thu, 10 Dec 2015 07:42:23 -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 6425C1144F; Thu, 10 Dec 2015 07:42:23 -0800 (PST) To: Niels =?utf-8?Q?M=C3=B6ller?= CC: Damien Miller , Peter Gutmann , denis bider , "Jeffrey Hutzelman" , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> <67048.1447534953@eng-mail01.juniper.net> <26466.1447573713@eng-mail01.juniper.net> <29562.1449755093@eng-mail01.juniper.net> Comments: In-reply-to: Niels =?utf-8?Q?M=C3=B6ller?= message dated "Thu, 10 Dec 2015 15:51:05 +0100." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD028;1:j/6QWizE0uBdpPb5fAAvZKWwoIIPTuBLJNNwKI/MLKwSD73dkSUUV0qpOC5RjDU+wkxy1qghIbNWPD4IKBZWjS+5juzpLhdEroqdRVfROF8V5UC2f/HAFf7qWZjFpU49nc/C2blZzY2RZs019dTk520W6zD1YcIQQJb8UqBJrpa89wAD6CnRxyOWmKUfBQ0r59x0LpXlze6uIGSV0Rw2nIo9d59WDPZqI+QnSwYSxusIS8cMS18EycTtvv9SZ70VjfkGX4TLCC613mHkAOOLUNRnwHq3/tZRNV5CS3Ykr8CPi21c6eZYwWcQRGRWwhfgl5rbbsPIY8hwXVXGV29t2vUqqfgiJyv3o6LE9k7TF4LkjMXi4QCJQwJdMtxDLIUGg2wuc5koltNXqVHCC8oFOx0s0bptEQM0ZZ1VVAjQVM4= X-Forefront-Antispam-Report: CIP:66.129.239.19;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(2980300002)(189002)(199003)(81156007)(50466002)(93886004)(586003)(19580395003)(5001960100002)(47776003)(11100500001)(110136002)(1220700001)(5003940100001)(87936001)(189998001)(105596002)(97736004)(1096002)(5003600100002)(69596002)(48376002)(6806005)(92566002)(15975445007)(86362001)(77096005)(117636001)(76176999)(50226001)(76506005)(2950100001)(53416004)(106466001)(50986999)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR0501MB1377;H:p-emfe01b-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN3PR0501MB1377;2:ZNL4Ehzuyar69uxcC29mUnS5+2mmb4GII3cIb/3unteJleCB59qFCOWaNNOwKAP6PILI0xb0TBDu2GLnuC6o0ljPqlu5DC/F4+ySyicMRCICNAnOFFVKrbGHk3vmNCJjQtvBIMKBIqmgqDgbGCni9A==;3:2Y/9+Ng6c4qeZpJSvM+DA4UCIFyCpT/UI8kS/GoCShbNu1FFC8RKPNcnAIcgRLbfep4CHRIuUJR/MHR3XHTql3ZqckkPoLzikcM4Ge0PVtu9od1ZFiDXCVGkLt+PbtZWhrRWCa1nhfvmn4VtpO4OqJnPCvvvAsWbKT+4hN3s7lP+bStD7+3dc2huS5prKIHxXy5UKgyG1b7t2s0eQl6lg88sxHdK3LMiSH0vJT6HlQ4=;25:jc8i85uKYUIuqYShPnWx26yHmXQNsfqpDaJNIDZ5CLh0spG+7UYBGzQw8QrnwExHVlINoi0KV0Llqy0hrFTyhGzcQv19B7FLnhpgzALhoWkTGi/OIT4pp6mLeXKy3IabI7jUvw/vWTRlNCYAN6ZUVkPiXU2TFmzoKvscbi5jMhuLWR7yQwV05Hh6+p70Z7U4earT3NpOLdVHMP/OaxnszDzGWTHkrJPs9gSaBJkG5s+4cL5CpEeMuKICzPeq9mAmBLFdal+ZwsG213jZimdTGQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1377; X-Microsoft-Exchange-Diagnostics: 1;BN3PR0501MB1377;20:tHVgBcXeUDOljU1EMjE5EZxJv5cwXjTnPbFyvr//1n0KK5TebND+CNSOFPOt9FiO/c3sHH1gsan5onBseM3uJWErGKI+pPNfQjI53NGcvCfImBUyhGAi1qsuwiuarS2EjNc3ObJIltjeKcsRrMetEcWLaBGqdySKjLXVcKYGlIhtwTNdAJeRtpJTj11q6J/hdH7axMyGk/8hCdAQyDYVVy+nnIGBtC8yXGhPYMngSEu4GC1VZpvOog9MvAsMDGF8cziMfCr2WzKbXeA10psFtE9PJaqHsaAfDkD0Z6iMTOq18149kr22Bb6codOmegUXzcjLTMWCZjhigqPE97qX5MJaI1X2jJmof8OAL0MGpXxAYhW9otZg43jiykFeO0oN7zzAJ9el3QkAJUsskD3XhN1soOMcDPjl5VuZGiiH//KkG6Yce/TFd0VztqN5Htv8x+C7RmlrUd7rpVcyiphsIW5iIHSGkkESfTz9Srhnj+vZ970nMs7ECzDuKR9TK61v;4:59OkJ5+jT6MVG8BaVVkHbOe9wWcGy25i/JFhpKRFM+2s2GuvT76uG28Jp266qeui7k1JLJkUZ2g4ypaO4iIJECXwpfQSt3bNSaeL/cI/VANt0KeCkiLRHWJwq7WKv5OEpHMpWTvL1Vz+dXqvDo6S19/ZyX8k/vMxEy9i2AZZ5WCMDxfzzznvsrBaokTy23NOd06opJeS3x9qz0dN3Bz7eF7l1066EgLBS2NzsvmlfeyZMg+ASm2Xrt17GBcgJHIFhPdwhLs6JbdJP/f8zPIJdUlu6O7mp66RVpaltwO56ThMdUdmL8xF0edwaU9pl5CESH9HcYZkVh5De8nYStCBAIeIoFfUFb9AhGbBYqqhlzl7rsWKYNhqAmgynstSHY9p X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001);SRVR:BN3PR0501MB1377;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1377; X-Forefront-PRVS: 078693968A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN3PR0501MB1377;23:+1jAYMX0wAVd4FsbRS0rQ5HYkNh4whJn51SWFfP?= =?us-ascii?Q?0uCtDmsHPlOnNdEks9W4vZS53/85GxPSFvyAqv2Exqb5VUTfdWCOn1fVPunN?= =?us-ascii?Q?Wm8foBDxV7CJW3ZF+aGMwiP7n4BoHUYsRGK3C5qWB2hqMJuORQocr5VNQ+KN?= =?us-ascii?Q?wlon0E3FKqiWKBkhqdrcM1+0qGFdARhXCD3CWkvAZAA+wjAhOYgT3jOHl6fu?= =?us-ascii?Q?8VfS/b30+IwfG4K2OF0ysixc421PNLaEUWYpjtJuYNZPL13+3BYDTSqERmuo?= =?us-ascii?Q?1CtLpX9OvxrGKXoNFZ0Px1joJkFgGhtYfvxP6eLpH9Oz3U1niHl2oH6+nD5N?= =?us-ascii?Q?j4rD9dc6ctTViuVa1YIRpzQ8I+kNzjHZUAdVD75IS7blr/XZgsVU4qj0plRL?= =?us-ascii?Q?bJT1d8CPy5vqWf1n5yMqGCxTWPk47DJf9BfRd4U7RS6bytRb/jrI7oU0o1+T?= =?us-ascii?Q?EpMu+Pz7Bo1rnn2kFzTF5Ya9479+gzte62UkR9Gcv8vVSqesAf1L/IUBwSJF?= =?us-ascii?Q?4qe0J5kjB35Xd0afxJJaWi7WJPx/wPGNuiZ7JhKfDRnqV+WGPlQI9Qu+HxCV?= =?us-ascii?Q?MZxZDvl/9IO36uuzDV/6wJ3322KbbcL648o4SOFTjSay0FcJhadPEjuyZ3jW?= =?us-ascii?Q?eXeWyGdgK7S0Eob9uA7qy9UotfrJAoNndS4PJ/jbpf0RrR3X64fi4HZ06ASO?= =?us-ascii?Q?wX59zv6QP5lmDbO1bC4xcYFaPKu8q19/4AJqAHBuUJRaW1wyBmEQaabv4YKj?= =?us-ascii?Q?ArqRxcm6iwj7wL5Lthk4AXL+txByO9+2gVlGDZgQ6Kv0mydKcz89AuTBpKf5?= =?us-ascii?Q?o8jGJY9h34taR3rG2LXCHHpgOFW9/TAVUgagXGGOhtjMM+YaDm02fWNA5nPA?= =?us-ascii?Q?tZBidC7xZ5U6/w5nuDpo7S960rHWioD50Trlg1AGOMWwviSAakOUYLVJb5c1?= =?us-ascii?Q?W6IGO1TZ68wYi2HZQ4PHLfDdXtK2RoQdHbOg1rJsLVNA46nqVsXmYcfBd2Bv?= =?us-ascii?Q?2N+AufQFJd/ruLmF2hnZgEaBM?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR0501MB1377;5:yKYyurMPBAV1T5zHpv7MXGzy76Zq9MRXB3pQ9Y9hQa3ZFxCUKuwdEN19N7I4rdnCIAFPb/6pyEeXnfastCnHz6bnooD6kRmxJyVLF/mz1Yc211fZrt1poJcNca9x1gHHwKnVaqpl+rjDwo5EU36BuA==;24:N7DGwHrmkpPcdqrF6xvc27WUro9wiSQORY1q5itkv/QQjPXgANQmr9QL/AjgnSBLWRSq20dblL86LrRsGtz0tz2RiNWOMPuYoU0SvljS+3c= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2015 15:42:58.0179 (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: BN3PR0501MB1377 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I have posted draft-baushke-ssh-dh-group-sha2-00 URL: https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/ to handle starting to remove diffie-hellman-group1-sha1 from the REQUIRED list and adding group14, group15 and group16 using sha256 to the RECOMMENDED, RECOMMENDED, OPTIONAL lists. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Dec 10 20:34:56 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728401A6F01 for ; Thu, 10 Dec 2015 20:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7t5vY_Et8f98 for ; Thu, 10 Dec 2015 20:34:55 -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 0DE401A3BA7 for ; Thu, 10 Dec 2015 20:34:55 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id C26CD85F20; Fri, 11 Dec 2015 04:34:53 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EEE1285E89 for ; Fri, 11 Dec 2015 04:34:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=dtucker-net.20150623.gappssmtp.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id FjcffPuCPKGN for ; Fri, 11 Dec 2015 04:34:51 +0000 (UTC) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 3D16885EE0 for ; Fri, 11 Dec 2015 04:34:51 +0000 (UTC) Received: by iofh3 with SMTP id h3so115745857iof.3 for ; Thu, 10 Dec 2015 20:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dtucker-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0olX2ACqraCzb2ArYjVMSD2dTMOc6awwL0U1zM3+MZY=; b=GHFce8pu06Dr7l/AJUnTbpCB9Fb40uknHhNBsok1KVW9+K6PkRxmPOOB2jY/dOel+R CsbECDPaKeFEJkBDD+WKjtgBwVE9SZWSph5q5g5Mhkr6j12eZgY7NCNQuPO6YrT8Z2gL fBhGspJMTLxaLD+AN24Q6ovMiL52yzjgWpErKHAhoscxWxHRjDSWdU2fOixk43DFuhO2 zijtDHU+GqdmYKIpDIe3sirJysDnuOECgXgFF5QqMlTndpPiSqGtqLOzL6MPYNi1rCO1 B70JKqBLjM8h2RwFcZcpM78orT5uQg7FkIFCbq4d8InhXd1lV4iJt+Gb2UtOTYjsEAk9 y3lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=0olX2ACqraCzb2ArYjVMSD2dTMOc6awwL0U1zM3+MZY=; b=Kd2ViOjOVMnCCw5Q3uVY241wWRjxDequhOAdj4nwtrs3J7o+B/89MG117HfR/31QMO IWMV1e5CeZSvHVRj6yPJcl06ZbqyuJa0qnbmjlB/c5AXpMdQHDxQHqQqTZPzNGWdvU1I qrZuRw50N4REujq7YxalQWnCZa34fyx301gdUtngg+Gcj0DQHdvCA3jfZELkXRV9STuT ubuHAbtGkYRYCmfCKvDSqmQGe2XYptf4q0DMXPKPkev/Y25I5jdCqCZCTzEVhIrRSv1o UnHMfada0eJpHYEC4xHa1tsy2kmdE1ZYaTeDW/D215wY4aYZQdPuBNu6xW0R4VXTUr2/ 0jeA== X-Gm-Message-State: ALoCoQluPJy0nNLaQsRhij/rqVFHUADgFF0KuhtB/dlyIj0K2B8OPf+cx0SH9i5KrayNLbsJdBPAX/6TLDitMrOa9J6OLPC5og== X-Received: by 10.107.11.23 with SMTP id v23mr16885204ioi.184.1449808490234; Thu, 10 Dec 2015 20:34:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.132.226 with HTTP; Thu, 10 Dec 2015 20:34:30 -0800 (PST) In-Reply-To: <83020.1449762143@eng-mail01.juniper.net> References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> <67048.1447534953@eng-mail01.juniper.net> <26466.1447573713@eng-mail01.juniper.net> <29562.1449755093@eng-mail01.juniper.net> <83020.1449762143@eng-mail01.juniper.net> From: Darren Tucker Date: Fri, 11 Dec 2015 15:34:30 +1100 X-Google-Sender-Auth: 4o97gxTZpc8DEtG-tDbruQDT68g Message-ID: Subject: Re: DH group exchange (Re: SSH key algorithm updates) To: "Mark D. Baushke" Cc: =?UTF-8?Q?Niels_M=C3=B6ller?= , Damien Miller , Peter Gutmann , denis bider , Jeffrey Hutzelman , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Content-Type: text/plain; charset=UTF-8 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, Dec 11, 2015 at 2:42 AM, Mark D. Baushke wrote: > I have posted draft-baushke-ssh-dh-group-sha2-00 I've implemented this for OpenSSH (against -current, but the diff will also apply to 7.1p1 with some fuzz) if anyone would like to try it. Patch is at https://bugzilla.mindrot.org/show_bug.cgi?id=2515. Please let me know if you have any comments or you can report success or failure with it. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Dec 11 00:39:50 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087221ACDCE for ; Fri, 11 Dec 2015 00:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCd93GvVwMtZ for ; Fri, 11 Dec 2015 00:39: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 498BC1ACDCB for ; Fri, 11 Dec 2015 00:39:46 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3E3EF85F07; Fri, 11 Dec 2015 08:39:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B481085EFC for ; Fri, 11 Dec 2015 08:39:27 +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 C9ylgZwtzygv for ; Fri, 11 Dec 2015 08:39:27 +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 C80C785E6C for ; Fri, 11 Dec 2015 08:39:25 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E133040012; Fri, 11 Dec 2015 09:39: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 BF7394000F; Fri, 11 Dec 2015 09:39:21 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Fri, 11 Dec 2015 09:39:21 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Damien Miller , Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 References: <1656686251-2152@skroderider.denisbider.com> Date: Fri, 11 Dec 2015 09:39:21 +0100 In-Reply-To: <1656686251-2152@skroderider.denisbider.com> (denis bider's message of "Thu, 3 Dec 2015 07:26:53 +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: > Okay, I'll modify the draft to this effect. This may take me a bit, I cur= rently have a few urgent things to attend to. > > I would appreciate your thoughts on the question of EXT_INFO windows for = client and server. > > Do you find it acceptable if the proposal requires both client and server= to send their first EXT_INFO immediately after NEWKEYS? I think that's a reasonable place to send it. I view EXT_INFO as a part of the transport layer, and then the spec ought to not depend on messages belonging to the ssh-userauth or the ssh-connection service.=20 =20 But maybe I'm missing the issue... As a client, you want to know what extensions are supported *before* you send the SERVICE_REQUEST message? But it it's optional, you can't know if the server is not sending any EXT_INFO, or if it's going to send it but you haven't received it yet. Is that right? Since the protocol is specified as running over a byte stream, we ought not to reason in terms of the EXT_INFO arriving in the same packet as the NEWKEYS, even if that probably would work in practice. To remove the ambiguity, negotiation has to be a bit more complex. We'd need four more magic symbols, ext_info_{send,recv}_{c,s} and specify that the server MUST send EXT_INFO if and only if the client advertised ext_info_recv_c and the server advertised ext_info_send_s.=20 Then the client knows unabiguously if there will be an EXT_INFO following the NEWKEYS. And similarly for the other direction. Is there any simpler 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 Fri Dec 11 07:32:16 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1D11B2B18 for ; Fri, 11 Dec 2015 07:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEbyg8TKBkFM for ; Fri, 11 Dec 2015 07:32: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 C926A1B2B45 for ; Fri, 11 Dec 2015 07:32:11 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 02D9585EE7; Fri, 11 Dec 2015 15:32: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 6F2A185E83 for ; Fri, 11 Dec 2015 15:32:08 +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 CjlpmGGcSjDJ for ; Fri, 11 Dec 2015 15:32:07 +0000 (UTC) Received: from mail-ext-sout1.uwa.edu.au (mail-ext-sout1.uwa.edu.au [130.95.128.72]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 1D3E585EE7 for ; Fri, 11 Dec 2015 15:32:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CqBAAJ7GpW/8+AX4JehA1uvx8XCoVuAoF7AQEBAQEBgQuENAEBAQMBI1YFCwsYAgImAgI8GwYTCYgeCA2tCpIAAQEBAQEFAQEBAQEBHYEBh2SCboQ7AQEFF4JkOhMcgRoFjTN1iEqFNYhsgUeabGOCER2BYzE0AQGEIoFBAQEB X-IPAS-Result: A2CqBAAJ7GpW/8+AX4JehA1uvx8XCoVuAoF7AQEBAQEBgQuENAEBAQMBI1YFCwsYAgImAgI8GwYTCYgeCA2tCpIAAQEBAQEFAQEBAQEBHYEBh2SCboQ7AQEFF4JkOhMcgRoFjTN1iEqFNYhsgUeabGOCER2BYzE0AQGEIoFBAQEB X-IronPort-AV: E=Sophos;i="5.20,414,1444665600"; d="scan'208";a="187357373" Received: from f5-new.net.uwa.edu.au (HELO mooneye.ucc.gu.uwa.edu.au) ([130.95.128.207]) by mail-ext-out1.uwa.edu.au with ESMTP/TLS/ADH-AES256-SHA; 11 Dec 2015 23:31:45 +0800 Received: from smtp by mooneye (authenticated submission) with ESMTPSA id AAB5E66001; Fri, 11 Dec 2015 23:31:45 +0800 (AWST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Feedback on draft-ssh-ext-info-00 From: Matt Johnston In-Reply-To: Date: Fri, 11 Dec 2015 23:31:45 +0800 Cc: denis bider , Damien Miller , Markus Friedl , ietf-ssh@netbsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3EEF3162-0795-4269-BE33-877680BCC9FF@ucc.asn.au> References: <1656686251-2152@skroderider.denisbider.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 > On Fri 11/12/2015, at 4:39 pm, Niels M=C3=B6ller = wrote: > ... > Since the protocol is specified as running over a byte stream, we = ought > not to reason in terms of the EXT_INFO arriving in the same packet as > the NEWKEYS, even if that probably would work in practice. >=20 > To remove the ambiguity, negotiation has to be a bit more complex. > We'd need four more magic symbols, >=20 > ext_info_{send,recv}_{c,s} >=20 > and specify that the server MUST send EXT_INFO if and only if the > client advertised ext_info_recv_c and the server advertised > ext_info_send_s.=20 Why not keep just ext_info_{c,s} and specify that client and server both = MUST send SSH_MSG_EXT_INFO immediately after SSH_NEWKEYS iff both sent = ext_info_{c,s}? Then they both know what to expect. Regarding the secondary SSH_MSG_EXT_INFO before SSH_MSG_USERAUTH_SUCCESS = there's a race condition - the server can't tell if subsequent packets = it receives were sent by the client prior to receiving SSH_MSG_EXT_INFO = - the same as the delayed zlib race [1]. Probably won't be a problem for = the current extensions but it could cause trouble if it's used for = transport-level extensions. I think "server-sig-algs" should have "auth" somewhere in the name to = avoid confusion with hostkey algorithms. Not a huge deal. As a small data point Dropbear client has been sending SERVICE_REQUEST = and USERAUTH_REQUEST in the same TCP packet since 2013 (2013.57) with no = reports of problems. That said Dropbear is a lot more widely used as a = server than client - I'm sure there could be something that wouldn't = handle it. FWIW Dropbear is already using the kex algorithm = "kexguess2@matt.ucc.asn.au" to signal more permissive = first_kex_packet_follows negotiation. [2] Cheers, Matt [1] Simon's comment = http://thread.gmane.org/gmane.ietf.secsh/6108/focus=3D6110 [2] http://www.ietf.org/mail-archive/web/secsh/current/msg00657.html= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Dec 11 07:55:44 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7F41B2B32 for ; Fri, 11 Dec 2015 07:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKUsR_gl6w3g for ; Fri, 11 Dec 2015 07:55: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 725681B2AC8 for ; Fri, 11 Dec 2015 07:55:43 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B1F7085EDD; Fri, 11 Dec 2015 15:55: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 B8C9485E5E for ; Fri, 11 Dec 2015 15:55: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 YULD_sjaRfsr for ; Fri, 11 Dec 2015 15:55:40 +0000 (UTC) Received: from mail-ext-sout1.uwa.edu.au (mail-ext-sout1.uwa.edu.au [130.95.128.72]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 927D485E59 for ; Fri, 11 Dec 2015 15:55:39 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CqBAAz2mpW/8+AX4JehA1ugmK8PSGFbgKBewEBAQEBAYELhDQBAQEDATo/BQsLDgouPBsGE4gnCA2+bQEBAQEBBQEBAQEBAQEYBIhlgm6EWYNNgRoFjiiISoU1iGx+hEWWcGOEETE0AYVWAQEB X-IPAS-Result: A2CqBAAz2mpW/8+AX4JehA1ugmK8PSGFbgKBewEBAQEBAYELhDQBAQEDATo/BQsLDgouPBsGE4gnCA2+bQEBAQEBBQEBAQEBAQEYBIhlgm6EWYNNgRoFjiiISoU1iGx+hEWWcGOEETE0AYVWAQEB X-IronPort-AV: E=Sophos;i="5.20,413,1444665600"; d="scan'208";a="187347000" Received: from f5-new.net.uwa.edu.au (HELO mooneye.ucc.gu.uwa.edu.au) ([130.95.128.207]) by mail-ext-out1.uwa.edu.au with ESMTP/TLS/ADH-AES256-SHA; 11 Dec 2015 22:19:54 +0800 Received: from smtp by mooneye (authenticated submission) with ESMTPSA id 5849466001; Fri, 11 Dec 2015 22:19:54 +0800 (AWST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: DH group exchange (Re: SSH key algorithm updates) From: Matt Johnston In-Reply-To: Date: Fri, 11 Dec 2015 22:20:04 +0800 Cc: "Mark D. Baushke" , =?utf-8?Q?Niels_M=C3=B6ller?= , Damien Miller , Peter Gutmann , denis bider , Jeffrey Hutzelman , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Content-Transfer-Encoding: quoted-printable Message-Id: <52B062CA-0159-4ED9-AF58-BBED122D6F09@ucc.asn.au> References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> <67048.1447534953@eng-mail01.juniper.net> <26466.1447573713@eng-mail01.juniper.net> <29562.1449755093@eng-mail01.juniper.net> <83020.1449762143@eng-mail01.juniper.net> To: Darren Tucker X-Mailer: Apple Mail (2.3112) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I've added preliminary diffie-hellman-group14-sha256 to Dropbear, = https://secure.ucc.asn.au/hg/dropbear/rev/d2f9ef67af15 The OpenSSH patch seems to have problems, I've replied in bugzilla. Cheers, Matt > On Fri 11/12/2015, at 12:34 pm, Darren Tucker = wrote: >=20 > On Fri, Dec 11, 2015 at 2:42 AM, Mark D. Baushke = wrote: >> I have posted draft-baushke-ssh-dh-group-sha2-00 >=20 > I've implemented this for OpenSSH (against -current, but the diff will > also apply to 7.1p1 with some fuzz) if anyone would like to try it. > Patch is at https://bugzilla.mindrot.org/show_bug.cgi?id=3D2515. = Please > let me know if you have any comments or you can report success or > failure with it. >=20 > Thanks. >=20 > --=20 > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. >=20 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Dec 11 10:30:11 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9781D1A924B for ; Fri, 11 Dec 2015 10:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5987xlKhMF2a for ; Fri, 11 Dec 2015 10:30: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 3E4EB1A90AC for ; Fri, 11 Dec 2015 10:30:09 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id E868F85EF8; Fri, 11 Dec 2015 18:30:08 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9549585E58; Fri, 11 Dec 2015 18:30:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 199A485EE2 for ; Thu, 10 Dec 2015 14:51: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 bE2G6-7FLAKp for ; Thu, 10 Dec 2015 14:51:12 +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 5D87585E1E for ; Thu, 10 Dec 2015 14:51:10 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 160F94001E; Thu, 10 Dec 2015 15:51:08 +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 6B3D840004; Thu, 10 Dec 2015 15:51:05 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 10 Dec 2015 15:51:05 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" Cc: Damien Miller , Peter Gutmann , denis bider , "Jeffrey Hutzelman" , "ietf-ssh\@NetBSD.org" , "stephen.farrell\@cs.tcd.ie" , "jon\@siliconcircus.com" Subject: Re: DH group exchange (Re: SSH key algorithm updates) References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> <67048.1447534953@eng-mail01.juniper.net> <26466.1447573713@eng-mail01.juniper.net> <29562.1449755093@eng-mail01.juniper.net> Date: Thu, 10 Dec 2015 15:51:05 +0100 In-Reply-To: <29562.1449755093@eng-mail01.juniper.net> (Mark D. Baushke's message of "Thu, 10 Dec 2015 05:44: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 "Mark D. Baushke" writes: > Okay. Well, what do other folks on the list think? Is it time to add > SHA3 to the SSH standard for DH Group15 and DH Group16? If so, what > values make the most sense? I think it is important to keep these two upgrades separately. As far as I'm aware, there's no reason to try to avoid sha256, so I'd prefer that we go with what you suggested a few weeks back: > diffie-hellman-group15-sha256 (3072-bit MODP group ~130 bits of securit= y) > diffie-hellman-group16-sha256 (4096-bit MODP group ~150 bits of securit= y) I think it would make sense with at least the first one as RECOMMENDED. As for sha3, what would we want to use it for?=20 As an alternative for key exchange and key derivation? Makes sense to me as alternatives with group14, 15 and 16. Not that I think this is urgent, but it makes me feel a little better if we are prepared with an alternative to sha256. As a mac? It's possible to to hmac-sha3-nnn, but I hope we'll see some standards for a keyed sha3 mac and/or a keccak-based aead, without doing the hmac construction. So maybe that's premature. 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 Fri Dec 11 20:50:52 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873F81A0062 for ; Fri, 11 Dec 2015 20:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnhRF8wYHIBB for ; Fri, 11 Dec 2015 20:50:48 -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 69A6D1A0061 for ; Fri, 11 Dec 2015 20:50:48 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id A7A43861EE; Sat, 12 Dec 2015 04:50:47 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B453A861ED for ; Sat, 12 Dec 2015 04:50:45 +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 OdNj2qu7WTuN for ; Sat, 12 Dec 2015 04:50:45 +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 742CC861EB for ; Sat, 12 Dec 2015 04:50:38 +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=1449895844; x=1481431844; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5sPZjsWwGnE7X6WzQqYb9oLNK0+9cbQZ/n/W2OfC/Dg=; b=cnzZrRtjgLteKWNWFXyf1wjrtAM371NCBaTGmdKL5zQhp9YF0svfo7hL oHqao7fDZMA/UIXEjZZL/ynbTH/gS+PHpq7cvG5N58pi/L1S6gHcDoCuO a45+mGwZG6hpPetqrGLEq1rDqWnkhB54YLoVXjtwf7A1uK2loEWNbFXdN 1HzmcOSf2y4DUn7+HtNKR4MPk1rpWbyltIVFJbHZF1mXCd1/9NBuIpOlH jU94lsiCLibso9IuYwLYE6s+B8faCPvNyq2JwXawwU6Yn4hGSazLm7OT/ 6T6ZKAB8j9Wwcc/BxlRNEhqeqe1LkZTFPXhvBBF0LD1u4LTD/uWKrPc6v Q==; X-IronPort-AV: E=Sophos;i="5.20,416,1444647600"; d="scan'208";a="58884136" 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; 12 Dec 2015 17:50:33 +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, 12 Dec 2015 17:50:33 +1300 From: Peter Gutmann To: "Mark D. Baushke" , =?iso-8859-1?Q?Niels_M=F6ller?= CC: Damien Miller , denis bider , Jeffrey Hutzelman , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Subject: RE: DH group exchange (Re: SSH key algorithm updates) Thread-Topic: DH group exchange (Re: SSH key algorithm updates) Thread-Index: AQHRM1G1N/YsUT4SL0yYPYnr9roRzp7GyoYx Date: Sat, 12 Dec 2015 04:50:32 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BA61E8@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> <67048.1447534953@eng-mail01.juniper.net> <26466.1447573713@eng-mail01.juniper.net> ,<29562.1449755093@eng-mail01.juniper.net> In-Reply-To: <29562.1449755093@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= >Well, what do other folks on the list think? Is it time to add SHA3 to the= =0A= >SSH standard for DH Group15 and DH Group16?=0A= =0A= Nope. We know, from the outcome of the SHA-3 competition, that SHA-2 is=0A= actually a lot stronger than people thought. So adding SHA-3 would be addi= ng=0A= yet another extra algorithm that's not noticeably stronger than SHA-2 (just= =0A= different), but a whole lot slower. If there's some desperate demand for a= =0A= new hash algorithm, I'd rather have Blake2, which is at least an improvemen= t=0A= on SHA-2.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Dec 12 00:14:47 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229E61A1BC6 for ; Sat, 12 Dec 2015 00:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoI1PDC22gwl for ; Sat, 12 Dec 2015 00:14: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 269F61A1BC3 for ; Sat, 12 Dec 2015 00:14:46 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id ED8588627A; Sat, 12 Dec 2015 08:14: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 BBBF386278 for ; Sat, 12 Dec 2015 08:14:43 +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 3KtYdGDqIbit for ; Sat, 12 Dec 2015 08:14:43 +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 EE28B85F13 for ; Sat, 12 Dec 2015 08:14:41 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 131B640009; Sat, 12 Dec 2015 09:14:40 +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 4683940006; Sat, 12 Dec 2015 09:14:38 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Sat, 12 Dec 2015 09:14:38 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Matt Johnston Cc: denis bider , Damien Miller , Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 References: <1656686251-2152@skroderider.denisbider.com> <3EEF3162-0795-4269-BE33-877680BCC9FF@ucc.asn.au> Date: Sat, 12 Dec 2015 09:14:37 +0100 In-Reply-To: <3EEF3162-0795-4269-BE33-877680BCC9FF@ucc.asn.au> (Matt Johnston's message of "Fri, 11 Dec 2015 23:31:45 +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 Matt Johnston writes: > Why not keep just ext_info_{c,s} and specify that client and server > both MUST send SSH_MSG_EXT_INFO immediately after SSH_NEWKEYS iff both > sent ext_info_{c,s}? Then they both know what to expect. Sounds ok to me. 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 Dec 12 00:56:36 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A621A21A6 for ; Sat, 12 Dec 2015 00:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqG3DJPeDKmp for ; Sat, 12 Dec 2015 00:56: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 47DFB1A21A3 for ; Sat, 12 Dec 2015 00:56:35 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id BAA148629D; Sat, 12 Dec 2015 08:56:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EB3EB862A1 for ; Sat, 12 Dec 2015 08:56:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=dtucker-net.20150623.gappssmtp.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id Fd7G7Ewft2MY for ; Sat, 12 Dec 2015 08:56:31 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 2FDD68629D for ; Sat, 12 Dec 2015 08:56:29 +0000 (UTC) Received: by igbxm8 with SMTP id xm8so54486978igb.1 for ; Sat, 12 Dec 2015 00:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dtucker-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=79dSm9Dhh/bw2NTjvSpZHutYXDNLk/tP0cDtILeoWVM=; b=E00mN4T9ux5tgppafWxW6vZJr+tiZw7W7gAzT0D/wqEEcIPJnTgQvivNUtqqIO1w5D CO90UX9PWcQloS6AEMqQPrRcLJHJRnaV2xliirigzHgMlDitxy6YmqzkuHMlUnZ4RvWD 3elttv1xyFRIDmF4J/fYjD01BoaH87VyWwgl6d2G8OMuN0fSQ1iEgOS8nBltEbxNYxnn UAdTIztKpk+FgrQYSLQ422qkiKseePMUpQg9PUSVh6iTHq1HHb4IPlKX75uAhidOAran vHd+NNOcSLjaxauX1YTqU+/zhfIAM7ce4tmuwx+STqP2SVNHrMlaku4gmTWh9VfC9mbc 3PIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=79dSm9Dhh/bw2NTjvSpZHutYXDNLk/tP0cDtILeoWVM=; b=W+0x25dfcg4Njc0cJ8yIyujaboQ9PAlk0X3MBHTnbyO/ehZL9pfKSIOA9v+PKQ6bwl olJlBsr6lLV61+//mxO5hLYvanu36wGR0vZ5VJYPUYGEHGx2/GA5KW5CwG/way/lU2ok yTZNAhUCrpOB9OA0U0fTeH/ENOB6QOBtogF7RpKzmahOJWo+ZWbwBC9m6TtRIiDRqyU1 gFxqVNozx2elzEa93q/Oynrs9W4AWwzTFSpvh6kiLcvquuzXpvn9jCDQqtqY6LPlj0DX JQ+BWezUxbjbtWa5SJHqt1RGWg7WkAvu5C9vMymYo7DNKyVNwYPsvdcz4CHmTheZirSz VYoA== X-Gm-Message-State: ALoCoQl64r3w+2EsRPk5CR6W/uqFLV9P5sqd1HMpfqCEJns0drCEZb+T72l01e/RVj4Y/GJ/AEYokY80Fm2czCWYVSdWXOjChA== X-Received: by 10.50.22.33 with SMTP id a1mr7212579igf.52.1449910588647; Sat, 12 Dec 2015 00:56:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.132.226 with HTTP; Sat, 12 Dec 2015 00:56:09 -0800 (PST) In-Reply-To: <52B062CA-0159-4ED9-AF58-BBED122D6F09@ucc.asn.au> References: <9A043F3CF02CD34C8E74AC1594475C73F4B5993D@uxcn10-5.UoA.auckland.ac.nz> <2096379125-720@skroderider.denisbider.com> <9A043F3CF02CD34C8E74AC1594475C73F4B599ED@uxcn10-5.UoA.auckland.ac.nz> <55190.1447001241@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5A9BC@uxcn10-5.UoA.auckland.ac.nz> <65113.1447107876@eng-mail01.juniper.net> <90378.1447145301@eng-mail01.juniper.net> <41119.1447226323@eng-mail01.juniper.net> <67048.1447534953@eng-mail01.juniper.net> <26466.1447573713@eng-mail01.juniper.net> <29562.1449755093@eng-mail01.juniper.net> <83020.1449762143@eng-mail01.juniper.net> <52B062CA-0159-4ED9-AF58-BBED122D6F09@ucc.asn.au> From: Darren Tucker Date: Sat, 12 Dec 2015 19:56:09 +1100 X-Google-Sender-Auth: PM7MQsFVKHaVqKui3vo8i-cKP68 Message-ID: Subject: Re: DH group exchange (Re: SSH key algorithm updates) To: Matt Johnston Cc: "Mark D. Baushke" , =?UTF-8?Q?Niels_M=C3=B6ller?= , Damien Miller , Peter Gutmann , denis bider , Jeffrey Hutzelman , "ietf-ssh@NetBSD.org" , "stephen.farrell@cs.tcd.ie" , "jon@siliconcircus.com" Content-Type: text/plain; charset=UTF-8 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sat, Dec 12, 2015 at 1:20 AM, Matt Johnston wrote: > I've added preliminary diffie-hellman-group14-sha256 to Dropbear, https://secure.ucc.asn.au/hg/dropbear/rev/d2f9ef67af15 > > The OpenSSH patch seems to have problems, I've replied in bugzilla. Damien implemented the missing code and I've updated the patch in the bug. With that change, openssh client interops with dropbear server. There's some problem with dropbear client and openssh server, but that combination doesn't work for me without my changes using group14-sha1 so I'll follow up with that off-list. Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Dec 14 11:08:06 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DE81B2DB5 for ; Mon, 14 Dec 2015 11:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6viU5iBs5dbo for ; Mon, 14 Dec 2015 11:08: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 9681C1B2DB0 for ; Mon, 14 Dec 2015 11:08:00 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 2E09485EB4; Mon, 14 Dec 2015 19:07:59 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id DC09D85EA1; Mon, 14 Dec 2015 19:07:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 11AE985E2B for ; Mon, 14 Dec 2015 00:27:56 +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 lGeDHz-TTNrA for ; Mon, 14 Dec 2015 00:27:55 +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 8BDEF85E1E for ; Mon, 14 Dec 2015 00:27:55 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Mon, 14 Dec 2015 00:27:44 +0000 Date: Mon, 14 Dec 2015 00:27:44 +0000 Subject: Re: Feedback on draft-ssh-ext-info-00 X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <420676586-2960@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , Matt Johnston , Damien Miller , Markus Friedl Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-impCIMnbHR/o7k0Ppmw+" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-impCIMnbHR/o7k0Ppmw+ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This is what I would prefer also. However, as far as I've understood, it's = not what Markus implemented for OpenSSH. If Markus and Damien wanted to implement this - that both sides presenting = ext-info-{s,c} should reliably lead to both sides sending SSH_MSG_EXT_INFO = - then I would prefer to modify the draft this way. However, it would be counter-productive to knowingly specify behavior diffe= rent from this major implementation. ----- Original Message ----- From: Niels "M=C3=B6ller"=20 Sent: Saturday, December 12, 2015 02:14 To: Matt Johnston=20 Cc: denis bider ; Damien Miller ; Markus Friedl ; ietf-ssh@netbsd.org=20 Subject: Re: Feedback on draft-ssh-ext-info-00 Matt Johnston writes: > Why not keep just ext_info_{c,s} and specify that client and server > both MUST send SSH_MSG_EXT_INFO immediately after SSH_NEWKEYS iff both > sent ext_info_{c,s}? Then they both know what to expect. Sounds ok to me. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. = --=-impCIMnbHR/o7k0Ppmw+ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable This is what I would prefer also. However, as far = as I've understood, it's not what Markus implemented for OpenSSH.

If= Markus and Damien wanted to implement this - that both sides presenting ex= t-info-{s,c} should reliably lead to both sides sending SSH_MSG_EXT_INFO - = then I would prefer to modify the draft this way.

However, it would = be counter-productive to knowingly specify behavior different from this maj= or implementation.


----- Original Message -----
From: Niels "= M=C3=B6ller"
Sent: Saturday, December 12, 2015 02:14
To: Matt Johnst= on
Cc: denis bider ; Damien Miller ; Markus Friedl ; ietf-ssh@netbsd.or= g
Subject: Re: Feedback on draft-ssh-ext-info-00

Matt Johnston &= lt;matt@ucc.asn.au> writes:

> Why not keep just ext_info_{c,s}= and specify that client and server
> both MUST send SSH_MSG_EXT_INFO= immediately after SSH_NEWKEYS iff both
> sent ext_info_{c,s}? Then t= hey both know what to expect.

Sounds ok to me.

Regards,
/N= iels

--
Niels M=C3=B6ller. PGP-encrypted email is preferred. Key= id C0B98E26.
Internet email is subject to wholesale government surveilla= nce.

= --=-impCIMnbHR/o7k0Ppmw+-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Dec 14 11:08:16 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937DD1B2DB1 for ; Mon, 14 Dec 2015 11:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.209 X-Spam-Level: X-Spam-Status: No, score=-0.209 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjPJWxR--JES for ; Mon, 14 Dec 2015 11:08: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 743871B2DB6 for ; Mon, 14 Dec 2015 11:08:09 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 126CD85EA8; Mon, 14 Dec 2015 19:08:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C179E85EA1; Mon, 14 Dec 2015 19:08:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E525D85E68 for ; Mon, 14 Dec 2015 00:53:36 +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 2yav7k8vH5ye for ; Mon, 14 Dec 2015 00:53: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 3548685E4A for ; Mon, 14 Dec 2015 00:53:36 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for matt@ucc.asn.au; Mon, 14 Dec 2015 00:53:25 +0000 Date: Mon, 14 Dec 2015 00:53:25 +0000 Subject: Post-user-auth compression as an extension? (Re: Feedback on draft-ssh-ext-info-00) X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <422177518-2040@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: Matt Johnston , =?UTF-8?q?Niels_M=C3=B6ller?= , Damien Miller , Markus Friedl Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-8mfort3DKpwa7UzIh1Et" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-8mfort3DKpwa7UzIh1Et Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Regarding the secondary SSH_MSG_EXT_INFO before > SSH_MSG_USERAUTH_SUCCESS there's a race condition - the server > can't tell if subsequent packets it receives were sent by the > client prior to receiving SSH_MSG_EXT_INFO It seems to me that resolving this race condition in a generic manner requi= res an acknowledgment from the client that it has received the second SSH_M= SG_EXT_INFO. However, it seems weird to be defining such an acknowledgment = for hypothesized extensions, without a known extension using it. But perhaps we should define such an extension. :-) How about defining an extension for negotiation of post-user-auth compressi= on? That would: - Allow the client and server to avoid re-doing key exchange, which is curr= ently required for safe implementation of the popular post-user-auth compre= ssion scheme. - Allow for the server to avoid advertising it supports compression to unau= thenticated clients. - Provide a specific case to justify the client sending an acknowledgment t= hat it has received SSH_MSG_EXT_INFO. ----- Original Message ----- From: Matt Johnston=20 Sent: Friday, December 11, 2015 09:31 To: Niels M=C3=B6ller=20 Cc: denis bider ; Damien Miller ; Markus Friedl ; ietf-ssh@netbsd.org=20 Subject: Re: Feedback on draft-ssh-ext-info-00 > On Fri 11/12/2015, at 4:39 pm, Niels M=C3=B6ller w= rote: > ... > Since the protocol is specified as running over a byte stream, we ought > not to reason in terms of the EXT_INFO arriving in the same packet as > the NEWKEYS, even if that probably would work in practice. >=20 > To remove the ambiguity, negotiation has to be a bit more complex. > We'd need four more magic symbols, >=20 >=C2=A0 ext_info_{send,recv}_{c,s} >=20 > and specify that the server MUST send EXT_INFO if and only if the > client advertised ext_info_recv_c and the server advertised > ext_info_send_s.=20 Why not keep just ext_info_{c,s} and specify that client and server both MU= ST send SSH_MSG_EXT_INFO immediately after SSH_NEWKEYS iff both sent ext_in= fo_{c,s}? Then they both know what to expect. Regarding the secondary SSH_MSG_EXT_INFO before SSH_MSG_USERAUTH_SUCCESS th= ere's a race condition - the server can't tell if subsequent packets it rec= eives were sent by the client prior to receiving SSH_MSG_EXT_INFO - the sam= e as the delayed zlib race [1]. Probably won't be a problem for the current= extensions but it could cause trouble if it's used for transport-level ext= ensions. I think "server-sig-algs" should have "auth" somewhere in the name to avoid= confusion with hostkey algorithms. Not a huge deal. As a small data point Dropbear client has been sending SERVICE_REQUEST and = USERAUTH_REQUEST in the same TCP packet since 2013 (2013.57) with no report= s of problems. That said Dropbear is a lot more widely used as a server tha= n client - I'm sure there could be something that wouldn't handle it. FWIW Dropbear is already using the kex algorithm "kexguess2@matt.ucc.asn.au= " to signal more permissive first_kex_packet_follows negotiation. [2] Cheers, Matt [1] Simon's comment http://thread.gmane.org/gmane.ietf.secsh/6108/focus=3D6= 110 [2] http://www.ietf.org/mail-archive/web/secsh/current/msg00657.html= --=-8mfort3DKpwa7UzIh1Et Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Regarding the secondary SSH_MSG_EXT_INFO befo= re
> SSH_MSG_USERAUTH_SUCCESS there's a race condition - the server> can't tell if subsequent packets it receives were sent by the
>= ; client prior to receiving SSH_MSG_EXT_INFO

It seems to me that res= olving this race condition in a generic manner requires an acknowledgment f= rom the client that it has received the second SSH_MSG_EXT_INFO. However, i= t seems weird to be defining such an acknowledgment for hypothesized extens= ions, without a known extension using it.

But perhaps we should defi= ne such an extension. :-)

How about defining an extension for negoti= ation of post-user-auth compression?

That would:

- Allow the = client and server to avoid re-doing key exchange, which is currently requir= ed for safe implementation of the popular post-user-auth compression scheme= .

- Allow for the server to avoid advertising it supports compressio= n to unauthenticated clients.

- Provide a specific case to justify t= he client sending an acknowledgment that it has received SSH_MSG_EXT_INFO.<= br>

----- Original Message -----
From: Matt Johnston
Sent: Fr= iday, December 11, 2015 09:31
To: Niels M=C3=B6ller
Cc: denis bider = ; Damien Miller ; Markus Friedl ; ietf-ssh@netbsd.org
Subject: Re: Feed= back on draft-ssh-ext-info-00

> On Fri 11/12/2015, at 4:39 pm, Ni= els M=C3=B6ller <nisse@lysator.liu.se> wrote:
> ...
> Sin= ce the protocol is specified as running over a byte stream, we ought
>= ; not to reason in terms of the EXT_INFO arriving in the same packet as
= > the NEWKEYS, even if that probably would work in practice.
> > To remove the ambiguity, negotiation has to be a bit more complex.> We'd need four more magic symbols,
>
>  ext_info_{s= end,recv}_{c,s}
>
> and specify that the server MUST send EXT_= INFO if and only if the
> client advertised ext_info_recv_c and the s= erver advertised
> ext_info_send_s.

Why not keep just ext_inf= o_{c,s} and specify that client and server both MUST send SSH_MSG_EXT_INFO = immediately after SSH_NEWKEYS iff both sent ext_info_{c,s}? Then they both = know what to expect.


Regarding the secondary SSH_MSG_EXT_INFO be= fore SSH_MSG_USERAUTH_SUCCESS there's a race condition - the server can't t= ell if subsequent packets it receives were sent by the client prior to rece= iving SSH_MSG_EXT_INFO - the same as the delayed zlib race [1]. Probably wo= n't be a problem for the current extensions but it could cause trouble if i= t's used for transport-level extensions.

I think "server-sig-algs" s= hould have "auth" somewhere in the name to avoid confusion with hostkey alg= orithms. Not a huge deal.

As a small data point Dropbear client has = been sending SERVICE_REQUEST and USERAUTH_REQUEST in the same TCP packet si= nce 2013 (2013.57) with no reports of problems. That said Dropbear is a lot= more widely used as a server than client - I'm sure there could be somethi= ng that wouldn't handle it.

FWIW Dropbear is already using the kex a= lgorithm "kexguess2@matt.ucc.asn.au" to signal more permissive first_kex_pa= cket_follows negotiation. [2]

Cheers,
Matt

[1] Simon's com= ment http://thread.gmane.org/gmane.ietf.secsh/6108/focus=3D6110
[2] http= ://www.ietf.org/mail-archive/web/secsh/current/msg00657.html= --=-8mfort3DKpwa7UzIh1Et-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Dec 15 00:32:26 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83AC1A0021 for ; Tue, 15 Dec 2015 00:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Vij7p6r26CO for ; Tue, 15 Dec 2015 00:32: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 A769A1A001D for ; Tue, 15 Dec 2015 00:32:20 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 7441385E66; Tue, 15 Dec 2015 08:32: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 A672D85E63 for ; Tue, 15 Dec 2015 08:32:17 +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 PtbP91N61AHI for ; Tue, 15 Dec 2015 08:32:17 +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 F21F985E5C for ; Tue, 15 Dec 2015 08:32:15 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 6FEA3400A7; Tue, 15 Dec 2015 09:32:12 +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 9C48940033; Tue, 15 Dec 2015 09:32:10 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 15 Dec 2015 09:32:10 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Damien Miller , Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Updated EXT_INFO draft - draft-ssh-ext-info-02 References: <1634365300-2152@skroderider.denisbider.com> Date: Tue, 15 Dec 2015 09:32:10 +0100 In-Reply-To: <1634365300-2152@skroderider.denisbider.com> (denis bider's message of "Thu, 3 Dec 2015 01:51:01 +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: > (3) "Don't replace SERVICE_REQUEST + ACCEPT" > > I still believe SERVICE_REQUEST + ACCEPT serve no purpose, and waste a > round-trip for no reason.=20 I still fail to see why SERVICE_REQUEST costs a roundtrip time. IIRC, you claimed or guessed that some implementations can't handle NEWKEYS + SERVICE_REQUEST + UERAUTH_REQUEST sent back-to-back. But I don't think I've seen any details. And I really don't think replacing SERVICE_REQUEST is an appropriate or proportionate workaround for such bugs. > This seems like a great opportunity to do away with them. It's fine to have a proposed change to replace SERVICE_REQUEST depend on the proposed extension mechanism. But please don't introduce a reverse dependency.=20 I don't think there's likely to be consensus that we should do anything about SERVICE_REQUEST now, so it's going to be an obstacle to the extension mechanism which is a lot easier to agree on. 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 Dec 15 00:45:04 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A6D1A0020 for ; Tue, 15 Dec 2015 00:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw_AFIbLznD0 for ; Tue, 15 Dec 2015 00:45:03 -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 59D551A0061 for ; Tue, 15 Dec 2015 00:45:03 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 88BDF85E69; Tue, 15 Dec 2015 08:45:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id ACD6185E63 for ; Tue, 15 Dec 2015 08:45:00 +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 E-TNi-TxH_up for ; Tue, 15 Dec 2015 08:45:00 +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 093B085E5C for ; Tue, 15 Dec 2015 08:44:59 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0E3C1400E5; Tue, 15 Dec 2015 09:44:58 +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 C5DCA400E4; Tue, 15 Dec 2015 09:44:56 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 15 Dec 2015 09:44:56 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Matt Johnston , Damien Miller , Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 References: <420676586-2960@skroderider.denisbider.com> Date: Tue, 15 Dec 2015 09:44:56 +0100 In-Reply-To: <420676586-2960@skroderider.denisbider.com> (denis bider's message of "Mon, 14 Dec 2015 00:27:44 +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: > This is what I would prefer also. However, as far as I've understood, > it's not what Markus implemented for OpenSSH. And to be clear, the problem with that way of doing it is that the client has no way to know reliably whether or not to expect SSH_EXT_INFO, and in particular, to know it *before* deciding what to put in its SERVICE_REQUEST. I think it's desirable to be able to know whether or not the peer is going to send SSH_EXT_INFO, even if I don't agree at all with your dislike for SERVICE_REQUEST. One scenario where it matters, is if we define an extension that lists which services the server is offering. > However, it would be counter-productive to knowingly specify behavior > different from this major implementation. I wouldn't put it that way. I'd say that we should strive for consensus, and it's pretty important that that our consensus includes the openssh folks. 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 Dec 15 00:53:26 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB701A00E1 for ; Tue, 15 Dec 2015 00:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbnP4oIWilwN for ; Tue, 15 Dec 2015 00:53:25 -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 821691A00DA for ; Tue, 15 Dec 2015 00:53:25 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id AB3D285E73; Tue, 15 Dec 2015 08:53:24 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4304585E6C for ; Tue, 15 Dec 2015 08:53: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 fSXRqo1rmU5l for ; Tue, 15 Dec 2015 08:53:22 +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 9865985E5C for ; Tue, 15 Dec 2015 08:53:22 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id DC4E2400E3; Tue, 15 Dec 2015 09:53:20 +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 A746040004; Tue, 15 Dec 2015 09:53:19 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 15 Dec 2015 09:53:19 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: denis bider Cc: Matt Johnston , Damien Miller , Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Post-user-auth compression as an extension? (Re: Feedback on draft-ssh-ext-info-00) References: <422177518-2040@skroderider.denisbider.com> Date: Tue, 15 Dec 2015 09:53:19 +0100 In-Reply-To: <422177518-2040@skroderider.denisbider.com> (denis bider's message of "Mon, 14 Dec 2015 00:53:25 +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: > How about defining an extension for negotiation of post-user-auth compres= sion? Maybe. But to make progress, I'd recommend focusing in getting the extension mechanism landed first. About the race, Simon (referred to in Matt's reply) describes the proper solution: Define a "NEWCOMPRESS" message, sent in each direction, just prior to the first compressed message. > [1] Simon's comment http://thread.gmane.org/gmane.ietf.secsh/6108/focus= =3D6110 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 Sun Dec 20 06:33:09 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0101B2DA0 for ; Sun, 20 Dec 2015 06:33:09 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf6QJ1wywyKd for ; Sun, 20 Dec 2015 06:33:08 -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 7CC571B2D9F for ; Sun, 20 Dec 2015 06:33:08 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id D460784CE8; Sun, 20 Dec 2015 14:33:06 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 91AE684CE7; Sun, 20 Dec 2015 14:33:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5DA4385EEB for ; Fri, 18 Dec 2015 06:16: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 EzFzqB4YQzlY for ; Fri, 18 Dec 2015 06:16: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 DD35585EE5 for ; Fri, 18 Dec 2015 06:16:57 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Fri, 18 Dec 2015 06:16:51 +0000 Date: Fri, 18 Dec 2015 06:16:51 +0000 Subject: draft-ssh-ext-info-05 available X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Message-ID: <783754389-3212@skroderider.denisbider.com> X-Priority: 3 Importance: Normal MIME-Version: 1.0 From: denis bider To: =?UTF-8?q?Niels_M=C3=B6ller?= , Matt Johnston , Damien Miller , Markus Friedl Cc: ietf-ssh@netbsd.org Content-Type: multipart/alternative; boundary="=-iUk8+3ZaauQQnHMS6IC5" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --=-iUk8+3ZaauQQnHMS6IC5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have submitted a new version of the SSH_MSG_EXT_INFO draft: https://tools.ietf.org/html/draft-ssh-ext-info-05 Changes: - New extension: "elevation". This is useful when connecting to Windows ser= vers where the SSH server needs to know at the time of creating the logon s= ession whether the client wants the session to be elevated or not. - New extension: "delay-compression". This is a generic mechanism for enabl= ing delayed compression whose main goal is to fix the race condition inhere= nt in zlib@openssh.com. I would like to make the following change, but cannot unless this can be ag= reed by Markus and/or Damien: - Matt Johnston, Niels M=C3=B6ller, and myself have expressed a preference = for mandating the following behavior: Matt: Why not [...] specify that client and server both MUST send SSH_MSG_E= XT_INFO immediately after SSH_NEWKEYS iff both sent [ext-info-{c,s}]? Then = they both know what to expect. The spec currently dictates this instead: Markus: If a client or server offers "ext-info-c" or "ext-info-s" respectiv= ely, it must be prepared to accept a SSH_MSG_EXT_INFO message from the peer= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Dec 20 06:40:36 2015 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CCF1B2DC3 for ; Sun, 20 Dec 2015 06:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDIAC_-BJ9fd for ; Sun, 20 Dec 2015 06:40: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 D58E61B2DC1 for ; Sun, 20 Dec 2015 06:40:33 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 3844A84CEB; Sun, 20 Dec 2015 14:40:33 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 36C6E84CEA for ; Sun, 20 Dec 2015 14:40:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id h_wpHz4l3lWZ for ; Sun, 20 Dec 2015 14:40:26 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0C92084CE8 for ; Sun, 20 Dec 2015 14:40:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C05A9BEEC for ; Sun, 20 Dec 2015 14:40:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uyy6DY7mpNZW for ; Sun, 20 Dec 2015 14:40:18 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.22.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1F915BEEA for ; Sun, 20 Dec 2015 14:40:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450622418; bh=quFamldCpVADfgaQBcToQX3z3aznSTHYevQy5hYHYR8=; h=Subject:References:To:From:Date:In-Reply-To:From; b=owdQrCrr6UgDK3qoawK7QfNWFkOTIqm2+O+ypziRizN3CDQw4RaE7g4EI9JXy11CN iOinlJhVl5BhFlZMUjuQ9tIpryWA2faiP6zdJ24wbmhDAVmas71Ic6aGt/eZ+Skgxu MevBcUjg16MDDNrBdeBILV73SECp9iBmdG2rGOxM= Subject: Fwd: Re: [Curdle] WG Action: Formed CURves, Deprecating and a Little more Encryption (curdle) References: <56743AD9.6@cs.tcd.ie> To: "ietf-ssh@netbsd.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <56743AD9.6@cs.tcd.ie> Message-ID: <5676BDD1.2080906@cs.tcd.ie> Date: Sun, 20 Dec 2015 14:40:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56743AD9.6@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Sorry - forgot to forward this here. The curdle WG that is planned to handle a few ssh algorithm issues has been formed. Please join that list if you're interested in those drafts (mainly [6] and [7] below I guess). Cheers, S. -------- Forwarded Message -------- Subject: Re: [Curdle] WG Action: Formed CURves, Deprecating and a Little more Encryption (curdle) Date: Fri, 18 Dec 2015 16:56:57 +0000 From: Stephen Farrell To: curdle@ietf.org Thanks all for the help with writing docs and the charter to get this going. And now off you go to get the work done! Cheers, S. On 18/12/15 16:52, The IESG wrote: > A new IETF working group has been formed in the Security Area. For > additional information please contact the Area Directors or the WG > Chairs. > > CURves, Deprecating and a Little more Encryption (curdle) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Daniel Migault > Rich Salz > > Assigned Area Director: > Stephen Farrell > > Mailing list > Address: curdle@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/curdle > Archive: https://mailarchive.ietf.org/arch/browse/curdle/ > > Charter: > > CURDLE - CURves, Deprecating and a Little more Encryption > > The CURDLE working group is chartered to add a small set of cryptographic > mechanisms to some IETF protocols, and to make implementation > requirements including deprecation of old algorithms where there is IETF > consensus to do so. The focus with regards to adding mechanisms is for > those mechanisms that enjoy broad support from implementers. > > The set of cryptographic mechanisms that can be introduced are limited to > key agreement (ECDH) and digital signatures (EdDSA) with Curve25519 and > Curve448 as defined by CFRG [1] [2], and the AEAD mode ciphers consisting > of ChaCha20 and Poly1305 also defined by CFRG [3]. Other variants of > mechanisms, such as the ChaCha20-Poly1305 construct deployed for SSH, may > also be considered as well as AES-CCM[4] and AES-GCM [5] where those are > not already defined and where there is implementer interest. Related > specifications such as private and public key formats are also within > scope. > > The protocols the WG intends to work on are Secure Shell (SSH), DNSSEC, > PKIX, CMS, XML Digital Signatures and potentially XML Encryption, > Kerberos and JSON. > > Where initial drafts for this work have been produced those will be > immediately considered for adoption as working group documents. These > include, for SSH, Curve25519/Curve448 digital signatures [6] and key > exchange [7]; for DNSSEC, Ed25519 [8] and Curve448 [9]; for PKIX, > Curve25519/448 NamedCurve [10] and EdDSA signatures [11]; for JSON curves > and signatures [12]. > > The CURDLE working group will be handling changes to protocols and > registries some of which include what are now considered outdated > algorithm options, and may propose deprecation of such algorithms. Such > deprecation needs to be done with care, ensuring that interoperability > and the needs of existing implementers and deployments are properly > considered. Where deprecation is practical, the working group is > encouraged to deprecate. > > Where there is an IETF working group or area group with expertise in a > relevant topic the CURDLE working group will defer to the consensus of > the more specific working group as to where work will be done. For > example, the TLS, OpenPGP and IPSECME WGs are actively considering some > of these topics. > > The CURDLE working group will liaise with W3C to ensure that XML digital > signature and XML encryption work does not conflict with W3C. > > The CURDLE working group is expected to be a short-lived working group > that may not need to ever meet face-to-face. Once the work on the > initially adopted set of drafts has completed the working group will > close or re-charter. > > The CURDLE working group is not chartered to consider allocating new > codepoints for any algorithms or modes other than those mentioned above. > Should someone wish to propose such work, a re-charter will be required. > At this time, there is no expectation that such a re-charter will be > requested. > > [1] https://tools.ietf.org/html/draft-irtf-cfrg-curves > [2] https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 > [3] RFC 7539 > [4] RFC 3610 > [5] RFC5288 > [6] https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02 > [7] https://tools.ietf.org/html/draft-josefsson-ssh-curves-00 > [8] https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03 > [9] https://tools.ietf.org/html/draft-sury-dnskey-ed448-00 > [10] https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 > [11] https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 > [12] http://www.ietf.org/mail-archive/web/jose/current/msg05357.html > > > Milestones: > Jan 2016 - Decision on which drafts to adopt > Jun 2016 - Send last draft to IESG > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle