From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 22 02:58:21 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B66131692 for ; Wed, 22 Mar 2017 02:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LtdOtp16bgtC for ; Wed, 22 Mar 2017 02:58:18 -0700 (PDT) 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 C2DE5131694 for ; Wed, 22 Mar 2017 02:58:15 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 535B7855DC; Wed, 22 Mar 2017 09:58:14 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 452D6855DB for ; Wed, 22 Mar 2017 09:58: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 Vdxc7-UbNOlI for ; Wed, 22 Mar 2017 09:58:12 +0000 (UTC) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 B07D584CED for ; Wed, 22 Mar 2017 09:58:12 +0000 (UTC) Received: by mail-it0-x22f.google.com with SMTP id y18so22168110itc.0 for ; Wed, 22 Mar 2017 02:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=QuCHtXilYHJxaFqW17G6j6RSnqjINT3Hl5J7s3Q+/+o=; b=f7KqWTjcDYcY3K4Oo79W3k2fsZ2Zxv/ttj+APKC9UJQfGRA9/d+qMM/ngWqf9ISI5C IhG12M6IeeYwhTa4x1bw41liH9DlznH10AczA72hwTcEylAVo1KKo/hh7KlU0bFbyqfu bccWiv83sdqYU5lFbxztmyDzR8tsuEAd1IgYDMh2NunpBZaprzwa9IldUjpDfe2AO+AB LTuPZxKGANfH6zimDRx3PnOhJ5aGV5/481dKZ+iJN+gZRZ09uZN6j+j/s5hiXcf1dKub 8WESLhWlctfeRlBbYLRMTo5X3nk+elBVsJigCj4zEO0nay5j270GyzTB7DqGjNjhEEZ7 nC1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QuCHtXilYHJxaFqW17G6j6RSnqjINT3Hl5J7s3Q+/+o=; b=jBeijUvePRMm9+wEdifIMvZOOMR0ZgIFbGDu3YPkgulywNsiwqg0YjQ+AVPrGnRvFY /guItC70vlJ4rzXk22teZlYk2UHak4bilfYmg555MEQKHV+UXiPn/L4W7AyBFO8rXe10 QrOxH6uBUSKzdM3/pYmEoj1x8R8wZ2cE0w+ziYHgat0257JpIZzK6WMFi1Brdv9fmGHW 4xJxusl5TiOq3VdGl7As3ytMk26StlXorCko32ABtBcSI7+Pm4GgWfMzlKPwOAebCLjD 0RWduc9/+bkKXg1//x3S4UQPmRuB3P8WdGuxF6oVP7qcr55I9ctbl8lSIkue5W0fV+BU d3vA== X-Gm-Message-State: AFeK/H2r5kCjvHmACk0BdqGxySI/jaTIqq6MgzQOxr4ay/pIK6FKJOaboDOdFIcEuST6cAeP1mAfggY6n2mhPw== X-Received: by 10.36.118.84 with SMTP id z81mr1474194itb.99.1490176691764; Wed, 22 Mar 2017 02:58:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.97.101 with HTTP; Wed, 22 Mar 2017 02:58:11 -0700 (PDT) From: Loganaden Velvindron Date: Wed, 22 Mar 2017 13:58:11 +0400 Message-ID: Subject: secsh wg status To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=UTF-8 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hello, The secsh wg has been declared as "concluded": https://tools.ietf.org/wg/secsh/. However, there is still work to do as various implementations move forward such as OpenSSH & dropbear. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 22 06:10:17 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12311297EC for ; Wed, 22 Mar 2017 06:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 x9xEvEihJfZG for ; Wed, 22 Mar 2017 06:10:14 -0700 (PDT) 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 60CC412985F for ; Wed, 22 Mar 2017 06:10:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 498A7855F4; Wed, 22 Mar 2017 13:10: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 B75FB855F7 for ; Wed, 22 Mar 2017 13:10:07 +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 RPP8c1w6fP34 for ; Wed, 22 Mar 2017 13:10:07 +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 D72C6855F4 for ; Wed, 22 Mar 2017 13:10:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E9897BE53; Wed, 22 Mar 2017 11:54:00 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG__Q-URFGAx; Wed, 22 Mar 2017 11:54:00 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C854DBEF2; Wed, 22 Mar 2017 11:53:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1490183640; bh=i6KnHPVzU//w7wkqXKvDZ9iB/49yqUSgKOef+gNdwqA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=fjqg0mUSyWSIZkG7bD8BA4Qi0lOMe5khsJ/e3We8kh4BCBmnTYxqFwPBR1HOqIRaK oquV1IlRfLGJMgjkF3SthUzl63scJ7GTa5R3DalDL//7p4ki+on5urzQLgOHR4oajO a1g02gtqex6CCITGpOMfWkhFFMgycbScFefSvHsM= Subject: Re: secsh wg status To: Loganaden Velvindron , ietf-ssh@netbsd.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <64d6da52-bed1-1388-383e-5023b07c8311@cs.tcd.ie> Date: Wed, 22 Mar 2017 11:53:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BxCobVFV5CO2Ftc2TdmdtQ5auoRmDnn2N" Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BxCobVFV5CO2Ftc2TdmdtQ5auoRmDnn2N Content-Type: multipart/mixed; boundary="QSJ3v2KUG3Hfs9tjRp7U4FssSxEd8NHJ1"; protected-headers="v1" From: Stephen Farrell To: Loganaden Velvindron , ietf-ssh@netbsd.org Message-ID: <64d6da52-bed1-1388-383e-5023b07c8311@cs.tcd.ie> Subject: Re: secsh wg status References: In-Reply-To: --QSJ3v2KUG3Hfs9tjRp7U4FssSxEd8NHJ1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 22/03/17 09:58, Loganaden Velvindron wrote: > Hello, >=20 > The secsh wg has been declared as "concluded": > https://tools.ietf.org/wg/secsh/. However, there is still work to do > as various implementations move forward such as OpenSSH & dropbear. >=20 If there're enough folks who want to do enough good work to justify the IETF WG being reformed, then I'd be happy to help with the administrivia and I doubt there'd be much of a problem with that. We did just that a while back for openpgp, though to be honest, that's going more slowly than hoped. There's also some ssh related work being handled in the curdle WG [1], but I'm not sure if it's charter would or would not cover what you have in mind. Cheers, S. [1] https://tools.ietf.org/wg/curdle/ PS: Note that from next Wednesday I'll no longer be an IETF security area director, but I'll still be happy to advise and to put folks in touch with Kathleen or Eric who'll then be the relevant powers-that-be:-) --QSJ3v2KUG3Hfs9tjRp7U4FssSxEd8NHJ1-- --BxCobVFV5CO2Ftc2TdmdtQ5auoRmDnn2N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY0mXWAAoJEC88hzaAX42izekIAJKl12TW3Clx/1Ji7vH/LqVL z0k/gigH8FUpDMlNWUBvoqVjbrHSU8ZkILGINpdAe2ZpfxITh/5TLTglA/KGu79W fGq2CgP2b0iQtRdfa0ufpvmW1kX3TP5OQR892SrwB5RSdpywk1bP8CIzJu3yYqe2 L+p6zUDo9rJtNh2vWheanw+PhrN/lFSe0njRhB/Qw860PGVOeRkF/Z2oXEJ0lGrI nIRltwjmi6AUPeef9z82w2pLqMbbAF1f8F621jlvFi/1p7z6eeKCZlA7gX5PVKIO 1Rlxs7PUF5ZzaUA0LT6uV+FiHOlWbTXYLDaY7RBUSdScbKIp/uLhGa2rbjp5X1s= =Y244 -----END PGP SIGNATURE----- --BxCobVFV5CO2Ftc2TdmdtQ5auoRmDnn2N-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 22 23:53:58 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEDE127843 for ; Wed, 22 Mar 2017 23:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com 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 HdXsl2V5LfvM for ; Wed, 22 Mar 2017 23:53:56 -0700 (PDT) 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 97996124BE8 for ; Wed, 22 Mar 2017 23:53:56 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 48A11855E6; Thu, 23 Mar 2017 06:53:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id EF9A7855BE; Thu, 23 Mar 2017 06:53:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E1837855D0 for ; Thu, 23 Mar 2017 04:10:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 6jetgHh9Ivsf for ; Thu, 23 Mar 2017 04:10:11 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 5A44285568 for ; Thu, 23 Mar 2017 04:10:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding; bh=qCdOWn4/0E5dTWGkHjqm0e7lKTtpLK1p7j9toqFvGwE=; b=FnCIgqhF8bZJwi8KMzYKB7AeHxXS+Fds4YDKEFiIugrmZAiWjuLpsOa8xPH52/cotjvf7VANhKGyd Xd0E4o+BE60BwHw1P2edc7UdMIKgxIQRiliRvOq0VwEcmiwHcAcJ8KOjwOHdg4D+cY1YwEH0geuFsy WWfbv1ehqM01ptDVsoWgIEVnvgbwXhBuy7E1Lb/TuM7/CpLrD7p/sKFaelWz7VpHS0pbZ8wA8gVQzC q+sfA1z8Wabg6WvvYb2066vmURXP+cWM6uoCg8erMU7ExQ/GKXFoUqWk0CESxiKU8zKyCuthMuSQL/ GNfQywksCxehimVAIMIhv9NRfZMCLdg== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 23 Mar 2017 04:09:54 +0000 Message-ID: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> From: "denis bider \(Bitvise\)" To: Cc: , "Simon Tatham" Subject: Fixing exchange of host keys in the SSH key exchange Date: Wed, 22 Mar 2017 22:09:54 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hello everyone, I’m wondering if anyone - OpenSSH and PuTTY in particular? - would be interested in implementing an extension to the way the initial SSH handshake is done, in a way that would allow the SSH server to require the client to communicate one or more fingerprints of the server’s host key(s), before exchanging KEXINIT. This would have multiple benefits: (1) Security benefit: although the client could still not verify the server’s signature during key exchange, or could do any number of other things incorrectly; under reasonable assumptions, if the client has to communicate one or more fingerprints of the server’s host key(s) before KEXINIT, this prevents the situation where the client will present the user with a host key verification dialog, and the user will just click through it. (2) Security benefit: on servers that enable this policy, and prevent connections where the client does not communicate a correct server host key, drive-by password guessing becomes largely impossible, since unknown attackers do not know the server’s host key. (3) Practical benefit: the server knows which ones of its host keys the client trusts, and can avoid the situation where introduction of a new host key, with no change to previous host keys, would break connections for existing clients that prefer to negotiate the algorithm of the new host key, but do not actually trust it. The server can avoid this by restricting its list of host key algorithms presented in KEXINIT to match what the client already trusts. Implementation: We have room for textual data that can be sent before the SSH version string. To implement this, the client would send one or more lines such as: Expect-Key: \r\n A server that implements this as a requirement would wait for the “Expect-Key” lines before sending its KEXINIT. If the client just sends a version string, without at least one correct Expect-Key, the server could disconnect - perhaps with an informative SSH_MSG_DISCONNECT message. The rest of the protocol could remain unchanged. Server implementations that do not know about this extension, but correctly implement the spec, would ignore the unknown lines, and would be unaffected. If the rest of the protocol is unchanged, the Expect-Key lines will NOT be verified as part of the SSH key exchange hash, which means a "helpful" man-in-the-middle (such as a proxy) could insert Expect-Key lines and cause the connection to work, when it otherwise wouldn't. This might be a feature, or a misfeature. However, we could also change the protocol to include the Expect-Key lines in the SSH key exchange hash. In this case, the client would signal support by sending at least one Expect-Key line, and the server would signal support in another way. One way would be to include the name "expect-key" among its host key algorithms in KEXINIT. If the client has sent at least one Expect-Key line, and the server includes the name "expect-key" in its host key algorithms, the Expect-Key lines would become part of the SSH key exchange hash. denis From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 22 23:54:16 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C34127843 for ; Wed, 22 Mar 2017 23:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 uMiblhPxMA1J for ; Wed, 22 Mar 2017 23:54:15 -0700 (PDT) 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 4AED212420B for ; Wed, 22 Mar 2017 23:54:15 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id DA325855FB; Thu, 23 Mar 2017 06:54:14 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 93C1B855F8; Thu, 23 Mar 2017 06:54:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 852FD855EB for ; Wed, 22 Mar 2017 13:34:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 0I48t2GgtVxN for ; Wed, 22 Mar 2017 13:34:47 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id A846484CEA for ; Wed, 22 Mar 2017 13:34:46 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA23120; Wed, 22 Mar 2017 09:34:45 -0400 (EDT) Date: Wed, 22 Mar 2017 09:34:45 -0400 (EDT) From: Mouse Message-Id: <201703221334.JAA23120@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 22 Mar 2017 09:24:03 -0400 (EDT) To: ietf-ssh@netbsd.org Cc: Stephen Farrell Subject: Re: secsh wg status In-Reply-To: <64d6da52-bed1-1388-383e-5023b07c8311@cs.tcd.ie> References: <64d6da52-bed1-1388-383e-5023b07c8311@cs.tcd.ie> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> The secsh wg has been declared as "concluded" [...] > If there're enough folks who want to do enough good work to justify > the IETF WG being reformed, [...] Personally, and as an implementer, I see no current need for a WG (especially given the general direction I see IETF going), but it does sound good to me to keep the mailing list alive. I do want to talk ssh implementations occasionally, albeit no more than occasionally. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 22 23:54:29 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C454129422 for ; Wed, 22 Mar 2017 23:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com 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 8kqSgrDXtE3G for ; Wed, 22 Mar 2017 23:54:26 -0700 (PDT) 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 7B137124BE8 for ; Wed, 22 Mar 2017 23:54:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 33666855FD; Thu, 23 Mar 2017 06:54:26 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D8E2F855FC; Thu, 23 Mar 2017 06:54:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C0A8A85574 for ; Wed, 22 Mar 2017 11:19: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=denisbider.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id uZN89_nLljJe for ; Wed, 22 Mar 2017 11:19:02 +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 3CFBF84CE5 for ; Wed, 22 Mar 2017 11:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=LeyP3P2SluKqfbYmGT/c13WVKqt8Uo/yy2zn3IicivE=; b=HFcfX3DQjuOZoeFOZGnfLT5/tXcoJEgcE8KLIRI19zowqrxX1/qXA9kSkSL/Yfp08/wOaBdUDolCE jIRG9JQG4xCmFJWJkRTqr5fqYIN16r/4IkFwddSSvu2wmjcawQaETFcd+oiVKfvZtGDMpGO0/gDFS3 FBsRK3QfCrB6cRPhhp++jMUu31qv3VtLV6F3aEoyDFCM8PsRE7J+et+WVWo2I7FIGII7rtMHoqjIWv UekgCfCMfd6TbGziG0fUWxvD6PC7s+Ht/3trUOnWcdBHEIC7Z3KjkihRa1hEJbJHm+keGqCh5i7y+b 8C3PFIzFcAaQWS5xCEvgMIocCqgwXYg== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 22 Mar 2017 10:13:37 +0000 Message-ID: From: "denis bider \(Bitvise\)" To: "Loganaden Velvindron" , References: In-Reply-To: Subject: Re: secsh wg status Date: Wed, 22 Mar 2017 04:13:45 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01D2A2C2.B2EEB830" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0089_01D2A2C2.B2EEB830 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes. Some work is currently taking place in the =E2=80=9CCurdle=E2=80=9D = working group, but this is temporary; is concerned mainly with crypto = updates; and will also conclude when these updates are finished. There really ought to be an on-going group, but it appears as though the = design of the IETF is stacked against it. From: Loganaden Velvindron=20 Sent: Wednesday, March 22, 2017 03:58 To: ietf-ssh@netbsd.org=20 Subject: secsh wg status Hello, The secsh wg has been declared as "concluded": https://tools.ietf.org/wg/secsh/. However, there is still work to do as various implementations move forward such as OpenSSH & dropbear. ------=_NextPart_000_0089_01D2A2C2.B2EEB830 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes. Some work is currently taking place in the = =E2=80=9CCurdle=E2=80=9D working group, but=20 this is temporary; is concerned mainly with crypto updates; and will = also=20 conclude when these updates are finished.
 
There really ought to be an on-going group, but it appears as = though the=20 design of the IETF is stacked against it.
 
 
Sent: Wednesday, March 22, 2017 03:58
Subject: secsh wg status
 
Hello,

The=20 secsh wg has been declared as = "concluded":
https://tools.ietf.org/wg/secsh/.=20 However, there is still work to do
as various implementations move = forward=20 such as OpenSSH & dropbear.
------=_NextPart_000_0089_01D2A2C2.B2EEB830-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Mar 23 23:06:12 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAFA1296D4 for ; Thu, 23 Mar 2017 23:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2KiDm4ctcTTb for ; Thu, 23 Mar 2017 23:06:10 -0700 (PDT) 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 2A9681296C3 for ; Thu, 23 Mar 2017 23:06:10 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B60D6855B6; Fri, 24 Mar 2017 06:06:08 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 7428B855B4; Fri, 24 Mar 2017 06:06:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 66CEC855F4 for ; Thu, 23 Mar 2017 12:24: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 zg1z0UKqwBor for ; Thu, 23 Mar 2017 12:24:25 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 06BF184D04 for ; Thu, 23 Mar 2017 12:24:24 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id IAA22091; Thu, 23 Mar 2017 08:24:24 -0400 (EDT) Date: Thu, 23 Mar 2017 08:24:24 -0400 (EDT) From: Mouse Message-Id: <201703231224.IAA22091@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 23 Mar 2017 07:28:28 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Fixing exchange of host keys in the SSH key exchange In-Reply-To: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > I??m wondering if anyone - OpenSSH and PuTTY in particular? - would > be interested in implementing an extension to the way the initial SSH > handshake is done, in a way that would allow the SSH server to > require the client to communicate one or more fingerprints of the > server??s host key(s), before exchanging KEXINIT. > This would have multiple benefits: > (1) Security benefit: [...] if the client has to communicate one or > more fingerprints of the server??s host key(s) before KEXINIT, this > prevents the situation where the client will present the user with a > host key verification dialog, and the user will just click through > it. How? As far as I can see, in order to do that, you have to move that decision from the client to the server. This carries its own prices. > (2) Security benefit: on servers that enable this policy, and prevent > connections where the client does not communicate a correct server > host key, drive-by password guessing becomes largely impossible, > since unknown attackers do not know the server??s host key. Yes...but if the server does that, it also becomes impossible for the client to do the now-usual "just accept the key on the first connection" thing. You have to provide the host key to the client by some out-of-band means. This of course could be an upside or a downside, depending. > (3) Practical benefit: the server [...] can avoid the situation where > introduction of a new host key, with no change to previous host keys, > would break connections for existing clients that prefer to negotiate > the algorithm of the new host key, but do not actually trust it. True. Another possible benefit would be automatic defeat of host-key-gathering bots. My logs are full of clients that connect, get my host key, and then disconnect. A few of them are honest about what they're doing ("SSH-2.0-ZGrab ZGrab SSH Survey", or "SSH-2.0-OpenSSH-keyscan"); others are...less so ("SSH-2.0-PUTTY"). Most just report a library version (eg, "SSH-2.0-sshlib-0.1"). Or, rather, clients used to be doing that; I now disconnect such clients before giving them any host keys (I prefer to not talk about the details of what I've configured my server to require to get it to talk to a specific client). > Implementation: > We have room for textual data that can be sent before the SSH version > string. To implement this, the client would send one or more lines > such as: > Expect-Key: \r\n I strongly suggest that it instead be something like Expect-Key: so that when SHA256 finally shows weaknesses, it does not become a major headache to switch hash algorithms. If the server thinks the hash algorithm is too weak, or doesn't recognize it at all, it can ignore that line. The client can of course send hashes of the same key under multiple algorithms, if it wants. I can't help wondering if perhaps this is time to use the uint32 in SSH_MSG_KEXINIT that is "0 (reserved for future extension)", though, rather than shoehorning it into something that's currently outside the protocol (almost) entirely. I see no guidance in 4253 for implementation behaviour if that value isn't 0 - but see below. Also, 4253 says the server MAY send text before its version number, but is silent on the question of whether the client also may. (I suspect most server implementations share that code with their corresponding client implementations, though.) > However, we could also change the protocol to include the Expect-Key > lines in the SSH key exchange hash. In this case, the client would > signal support by sending at least one Expect-Key line, and the > server would signal support in another way. One way would be to > include the name "expect-key" among its host key algorithms in > KEXINIT. The server has at least as much room to send text before its version string as the client does. It seems more elegant to me for the server to signal support with something like Accept-Expect-Key: yes there - or perhaps to use that RFU uint32 in SSH_MSG_KEXINIT if the client signals support (which would avoid the issue of an unaware client printing that and thus confusing the user and possibly breaking scripted uses, and also restrict nonzero values to implementations that have already advertised awareness of this extension). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 24 01:32:43 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B95113010D for ; Fri, 24 Mar 2017 01:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 tIR3fFI-bSV9 for ; Fri, 24 Mar 2017 01:32:41 -0700 (PDT) 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 611B312E872 for ; Fri, 24 Mar 2017 01:32:41 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B935E8557D; Fri, 24 Mar 2017 08:32:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 07FCB84CEA for ; Fri, 24 Mar 2017 08:32:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id zr-nO7WNXx72 for ; Fri, 24 Mar 2017 08:32:35 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 B829584CDD for ; Fri, 24 Mar 2017 08:32:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490344354; x=1521880354; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NrxQ1pmtNLfa1+68ztwgcAUaJMvrJTrxWx2bF7zy1ms=; b=mDZ+Esx3rNHUG3lOQXrnWfLiRUK7C3dV2fFwqJqxZ/6RXggtvQV3JpwK NLkl5zoDFjkooHNLhP9pZCR+Hm96uXVzdYww8oHNZWU5kMo2iYosdgs6x 5fHoAtk3hCy4TGPkde9bGQr4TAZi9HpLjSiQNXboEPHr/XOZJEHcBaEDY j7bJOFNMaxOQdzKT4/09JV28scuvw9nXEBfE7dwBjHJf3FeUwnOuB3ibg cjttehnuiExh6WFsVUXF/Ak/21/ysQbhFsd3p480mD1R2EuQ40rNAjNlG R4bdsBX7A6b2Teues6uwXU2B8SMZloj/PGrBX2kDZcVpFuSKeP7KC4XJu A==; X-IronPort-AV: E=Sophos;i="5.36,214,1486378800"; d="scan'208";a="145192820" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Mar 2017 21:02:40 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 24 Mar 2017 21:02:39 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 24 Mar 2017 21:02:40 +1300 From: Peter Gutmann To: Mouse , "ietf-ssh@NetBSD.org" Subject: Re: Fixing exchange of host keys in the SSH key exchange Thread-Topic: Fixing exchange of host keys in the SSH key exchange Thread-Index: AQHSo6JCh/pnJs1+UUq8ewlt+ue/5qGhf50AgAIjC1I= Date: Fri, 24 Mar 2017 08:02:39 +0000 Message-ID: <1490342550681.12528@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan>,<201703231224.IAA22091@Stone.Rodents-Montreal.ORG> In-Reply-To: <201703231224.IAA22091@Stone.Rodents-Montreal.ORG> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted 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 Mouse writes:=0A= =0A= >Another possible benefit would be automatic defeat of host-key-gathering= =0A= >bots. My logs are full of clients that connect, get my host key, and then= =0A= >disconnect. A few of them are honest about what they're doing ("SSH-2.0-= =0A= >ZGrab ZGrab SSH Survey", or "SSH-2.0-OpenSSH-keyscan"); others are...less = so=0A= >("SSH-2.0-PUTTY"). Most just report a library version (eg, "SSH-2.0-=0A= >sshlib-0.1").=0A= =0A= I assume this is for weak-key-checking/key-sharing detection for research= =0A= purposes, or is there some malicious use for the info?=0A= =0A= >I can't help wondering if perhaps this is time to use the uint32 in=0A= >SSH_MSG_KEXINIT that is "0 (reserved for future extension)", though, rathe= r=0A= >than shoehorning it into something that's currently outside the protocol= =0A= >(almost) entirely. I see no guidance in 4253 for implementation behaviour= if=0A= >that value isn't 0 - but see below.=0A= =0A= I think this was discussed in the context of SSH extensions and the conclus= ion=0A= was that far too many things would break if this was nonzero. So even thou= gh=0A= it's marked as RFU, in practice it's "always set to zero".=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 24 13:24:37 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970BC1294A3 for ; Fri, 24 Mar 2017 13:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6kpRzafuxFyM for ; Fri, 24 Mar 2017 13:24:36 -0700 (PDT) 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 00047127ABE for ; Fri, 24 Mar 2017 13:24:35 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5E477855B9; Fri, 24 Mar 2017 20:24: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 CCAA4855AF for ; Fri, 24 Mar 2017 20:24:25 +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 IEw9IPrTqOmu for ; Fri, 24 Mar 2017 20:24:25 +0000 (UTC) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 3733884CE3 for ; Fri, 24 Mar 2017 20:24:25 +0000 (UTC) Received: by mail-it0-x231.google.com with SMTP id 190so1297154itm.0 for ; Fri, 24 Mar 2017 13:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2T54XRfco41kVrGwsR77HxwlaVIl5CMcHKNbcViWe6k=; b=DlT4NSNxThf6F3qcjHKKn0qoE+WAul8LsXbg0zEAal1JdLTZT4lVi/+ceBKFNErUzO nPUMKrolr7AEEbJQWfzLWl3dOZdQn5SDeQix3gSDIQ++R0I8a7MWvsrRg9DqcwqdqprL nDXVAgRbqY+z4uPpCyV+P8zOGo5tuXL1rhnI49ctqaMwQ3eQpEryeEB5IOl9cG/yebd0 7UAiG/3kO10KGEU+9xbRP4z6KSkjO8kcwWF8QMm6nS0Kcp2HmC3GQGP9zsr7IwPUFwTW uu8g2F2p04n3Q4eVV9nEC7Q2uBUJmj3UfpXK+xTq8+5Obk2O0KVIhXKqfZCrIh9GIINH 48Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2T54XRfco41kVrGwsR77HxwlaVIl5CMcHKNbcViWe6k=; b=jm97M2T1AjHVwETKRJQMpCEQpj3nvYla9S8CEyoR26/DVManoZhTdYBBrY1SQVMlQm AoLTec+vluCPiSUCrAWEoqvCGJXJXq3X7kQahNhZOEzcGjV4r6vdhN7rmiA8YjSplF9I LpmcyAdGc9QOkiZ2nFbxsLoXuYYCqOvJ8bZrVC1uRxoLtGy6lSlbrMBY1JyfH6PThu8e 9oISy1lSsRolRgMD+ELcUMa++YzLpsE+cScJFPmCzMvWWuML1scPjhCURnoFmM6G1YBe Ftr8v4xY+ssSC4GL3qjSwm+/kcW9nmisX1ncauwMrLk5KgO606VLLpYSaLhov3qiNSdu ztpA== X-Gm-Message-State: AFeK/H2ejit2GCMWr5cAW3ipFKlXYngX7PzSwGOhoxMj42fSh/IWlzt2WV+3G/ieAKs8iGE20jD42+mrXfQaqQ== X-Received: by 10.107.138.206 with SMTP id c75mr10266863ioj.32.1490387064488; Fri, 24 Mar 2017 13:24:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.97.101 with HTTP; Fri, 24 Mar 2017 13:24:24 -0700 (PDT) In-Reply-To: <201703221334.JAA23120@Stone.Rodents-Montreal.ORG> References: <64d6da52-bed1-1388-383e-5023b07c8311@cs.tcd.ie> <201703221334.JAA23120@Stone.Rodents-Montreal.ORG> From: Loganaden Velvindron Date: Sat, 25 Mar 2017 00:24:24 +0400 Message-ID: Subject: Re: secsh wg status To: Mouse Cc: ietf-ssh@netbsd.org, Stephen Farrell Content-Type: text/plain; charset=UTF-8 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Mar 22, 2017 at 5:34 PM, Mouse wrote: >>> The secsh wg has been declared as "concluded" [...] >> If there're enough folks who want to do enough good work to justify >> the IETF WG being reformed, [...] > > Personally, and as an implementer, I see no current need for a WG > (especially given the general direction I see IETF going), but it does > sound good to me to keep the mailing list alive. I do want to talk ssh > implementations occasionally, albeit no more than occasionally. > Well, not having RFCs match what the latest versions of implementations are doing does not sound good. I agree that receiving too many mails from a WG is not desirable. If we could find the right balance, I think that a WG is useful. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Mar 25 02:39:23 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB85F127843 for ; Sat, 25 Mar 2017 02:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 NfrVRq8ZL7TQ for ; Sat, 25 Mar 2017 02:39:21 -0700 (PDT) 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 A2150124BE8 for ; Sat, 25 Mar 2017 02:39:21 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 002B8855E7; Sat, 25 Mar 2017 09:39:19 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B161D855CF; Sat, 25 Mar 2017 09:39:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1A79D84CFB for ; Fri, 24 Mar 2017 11:24:52 +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 8u4QOA8yJLjg for ; Fri, 24 Mar 2017 11:24:51 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 3C0F184CDD for ; Fri, 24 Mar 2017 11:24:51 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id HAA19888; Fri, 24 Mar 2017 07:24:46 -0400 (EDT) Date: Fri, 24 Mar 2017 07:24:46 -0400 (EDT) From: Mouse Message-Id: <201703241124.HAA19888@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 24 Mar 2017 07:10:59 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Fixing exchange of host keys in the SSH key exchange In-Reply-To: <1490342550681.12528@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan>,<201703231224.IAA22091@Stone.Rodents-Montreal.ORG> <1490342550681.12528@cs.auckland.ac.nz> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> Another possible benefit would be automatic defeat of >> host-key-gathering bots. [...] > I assume this is for weak-key-checking/key-sharing detection for > research purposes, or is there some malicious use for the info? Well, I don't run one, and have never (knowingly) communicated with anyone who does, so I don't actually know the intent behind them. But the way so many different hosts have been connecting and getting dumped (and blocked at my border) after so long with the block in place makes me think much of it is done by one or more botnets, which makes it difficult for me to believe it's not malicious. The few that are at least a little honest about what they're doing (eg, ZGrab) have pretty much gone away since the block went in. Possible malicious use would be to break the host keys for hosts that have too weak a key (whatever "too weak" means for the botnet herder in question). As for research, I don't consider it acceptable to co-opt others' hosts for research without verifying their consent first, especially not when it involves trawling for security-sensitive material. I see no reason anyone whom I don't want to actually authenticate to me should have a copy of my host keys. >> I can't help wondering if perhaps this is time to use the uint32 in >> SSH_MSG_KEXINIT that is "0 (reserved for future extension)", [...] > I think this was discussed in the context of SSH extensions and the > conclusion was that far too many things would break if this was > nonzero. So even though it's marked as RFU, in practice it's "always > set to zero". Well, it seems to me that it could be used if the other end first indicates support for whatever the use is. There won't be many such, since either that has to be done in the clear or it has to not apply to the first kex, but this could be an example: the client indicates its support before the server has to generate its KEXINIT packet. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Mar 25 02:39:45 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45054120726 for ; Sat, 25 Mar 2017 02:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 HlsSqjfEEDO2 for ; Sat, 25 Mar 2017 02:39:43 -0700 (PDT) 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 17676124BE8 for ; Sat, 25 Mar 2017 02:39:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id BF7BA855EE; Sat, 25 Mar 2017 09:39:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 6AEA7855ED; Sat, 25 Mar 2017 09:39:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4C5C685570 for ; Fri, 24 Mar 2017 08:53: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=auckland.ac.nz Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id jdX2ly0rJVQ8 for ; Fri, 24 Mar 2017 08:53:17 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 1315984CEA for ; Fri, 24 Mar 2017 08:53:16 +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=1490345597; x=1521881597; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Z33E0p7jjYebOKeH0dr3aguCYUA5q3jg5oh0rVeq8yM=; b=JJC43SCb8f17rra8YaJTcozIrDWeNlPLutUyG/FYqAwKF4RsHsuf6G+r PE0aksuuWtjqg8sn10xIDyOSkm3yB6NIxdY6xkSSWKoItk+gXiVK/19n7 R0qnyC7Yci+bquKCsB6SJh5UC+WaGJ7xppLdECPuaE50ZC8rnyT80SoWZ 0x5ntzNLxdX8lO7e2EiBVLYxf5RXzxYw3s7sZt/MW/o7enMK2ysQgXfKk qvSxZ/28X0snuY6Gwnl4fLvRYJlK22DYEjCgaIODWuMTj7RRzucxCoY7W Odh7h3c0khBO1DPOZntOyIW8nSrrDS0BGA9jtMFt4aGF/yWoxgwF31UpB w==; X-IronPort-AV: E=Sophos;i="5.36,213,1486378800"; d="scan'208";a="145188219" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Mar 2017 20:22:38 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 24 Mar 2017 20:22:37 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 24 Mar 2017 20:22:37 +1300 From: Peter Gutmann To: "denis bider (Bitvise)" , "ietf-ssh@netbsd.org" CC: "djm@mindrot.org" , Simon Tatham Subject: Re: Fixing exchange of host keys in the SSH key exchange Thread-Topic: Fixing exchange of host keys in the SSH key exchange Thread-Index: AQHSo6JCh/pnJs1+UUq8ewlt+ue/5qGjlx6Q Date: Fri, 24 Mar 2017 07:22:37 +0000 Message-ID: <1490340148872.12344@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> In-Reply-To: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider (Bitvise) writes:=0A= =0A= >(1) Security benefit: although the client could still not verify the serve= r=92s=0A= >signature during key exchange, or could do any number of other things=0A= >incorrectly; under reasonable assumptions, if the client has to communicat= e=0A= >one or more fingerprints of the server=92s host key(s) before KEXINIT, thi= s=0A= >prevents the situation where the client will present the user with a host = key=0A= >verification dialog, and the user will just click through it.=0A= =0A= It also makes things a lot more painful for the user. If you regularly nee= d=0A= to SSH into a dozen different devices to administer them, it gets even wors= e.=0A= =0A= >(2) Security benefit: on servers that enable this policy, and prevent=0A= >connections where the client does not communicate a correct server host ke= y,=0A= >drive-by password guessing becomes largely impossible, since unknown=0A= >attackers do not know the server=92s host key.=0A= =0A= This is really just an awkward form of port-knocking. If you want to use a= =0A= port-knocking-style mechanism, you should probably do it properly. If you= =0A= want to bind a client to a server ("only this client, only this server") th= en=0A= there are better ways of doing it than this.=0A= =0A= >Server implementations that do not know about this extension, but correctl= y=0A= >implement the spec, =0A= =0A= How do we know what percentage of servers do this? It's true that the spec= =0A= says you should expect other stuff in the textual data, but since pretty mu= ch=0A= everything out there only ever sends the SSH ID string, it's quite likely t= hat=0A= lots of implementations will choke on unexpected extra lines of text. Even= in=0A= cases where the code does try and handle non-SSH-ID lines, the absence of= =0A= anything that sends them means it's probably never been tested.=0A= =0A= This doesn't seem like a good idea, it has the potential to break lots of= =0A= things, while what you're getting in return could be done better in other= =0A= ways.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Mar 25 02:57:25 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181411200C1 for ; Sat, 25 Mar 2017 02:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 ABBbhP0ltpHu for ; Sat, 25 Mar 2017 02:57:23 -0700 (PDT) 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 4D25E124BE8 for ; Sat, 25 Mar 2017 02:57:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 84BC6855F3; Sat, 25 Mar 2017 09:57: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 ACFC0855EE for ; Sat, 25 Mar 2017 09:57:17 +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 4P95e6mObcJf for ; Sat, 25 Mar 2017 09:57:17 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 9270784CDD for ; Sat, 25 Mar 2017 09:57:15 +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=1490435836; x=1521971836; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/KCvue+CJFQyARsaog7kx5artQlh5EBKKkbI3RDX0j8=; b=5m2/T4JJI++q4OCsQsEj1A5dkmdm+WwOPLw0vwQicyHmYxkcNYmfNVBr r+3PC9BFVf4V9Iks80uUouU19n134ZVy2T5IY/wrSKt0B8IBHCpnfsrg8 2DwEpaHUFCsQkVW3fCpDwpYMN1oWci7/Mh89LhrF1pDUlmz9KyYqPnekL rDRv/VuUQAefyXu5KCD9wG0QouEtjnyCOPBymsbc5/Rv6u6Qc/N1pTqj7 BnOOIppCKZWoveHvLUqaGxVYWdsWmoiwF6cMiJY5bquJINcC/0G1IErc5 YafJiKjkKd0Ogj8qjRzsWYXqNDUPVmN4ZiqDPR+XWjso/QlizpmYPyyPJ g==; X-IronPort-AV: E=Sophos;i="5.36,219,1486378800"; d="scan'208";a="145349417" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Mar 2017 22:56:40 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 25 Mar 2017 22:56:39 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Sat, 25 Mar 2017 22:56:39 +1300 From: Peter Gutmann To: Mouse , "ietf-ssh@NetBSD.org" Subject: Re: Fixing exchange of host keys in the SSH key exchange Thread-Topic: Fixing exchange of host keys in the SSH key exchange Thread-Index: AQHSo6JCh/pnJs1+UUq8ewlt+ue/5qGhf50AgAIjC1L//16gAIACU2cG Date: Sat, 25 Mar 2017 09:56:38 +0000 Message-ID: <1490435787911.30810@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan>,<201703231224.IAA22091@Stone.Rodents-Montreal.ORG> <1490342550681.12528@cs.auckland.ac.nz>,<201703241124.HAA19888@Stone.Rodents-Montreal.ORG> In-Reply-To: <201703241124.HAA19888@Stone.Rodents-Montreal.ORG> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted 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 Mouse writes:=0A= =0A= >Well, it seems to me that it could be used if the other end first indicate= s=0A= >support for whatever the use is. There won't be many such, since either t= hat=0A= >has to be done in the clear or it has to not apply to the first kex, but t= his=0A= >could be an example: the client indicates its support before the server ha= s=0A= >to generate its KEXINIT packet.=0A= =0A= Hmm, so you need to signal that you want to use the RFU field to signal tha= t=0A= you want to do something else?=0A= =0A= https://www.youtube.com/watch?v=3DAW2xyXl2tTI=0A= =0A= Prepare to use the RFU field!=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Mar 25 11:28:58 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8621294C2 for ; Sat, 25 Mar 2017 11:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.861 X-Spam-Level: X-Spam-Status: No, score=-3.861 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com 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 hgTO6CS3pSiA for ; Sat, 25 Mar 2017 11:28:55 -0700 (PDT) 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 9FA081288B8 for ; Sat, 25 Mar 2017 11:28:55 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id BF0E9855AF; Sat, 25 Mar 2017 18:28: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 D2B7685589 for ; Sat, 25 Mar 2017 18:28:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 6zpuszmJ65yl for ; Sat, 25 Mar 2017 18:28:38 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E3F5D84CDE for ; Sat, 25 Mar 2017 18:28:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=53olr3EfTKczBSP1hSskOrX/Dwgmwc2hJfLH0Y24JVQ=; b=hzGgjZqW8/Mqj6OBLgzYWCw93gKrnRHC41M+sh4FTfeoC2IeANOW408ivUzHwKKrZzakbnh27KSG1 T7GD7dXWpFmFLztwWayWQQIW2P+qS4Vg2M9L/kyEvG/Tnedb0OHkXhwk7YWzXgWkLynxwtZGP4KBdE w4MU1HA7yrz53M0mPAHqM82jyFk4YcCZ2HB3WCGLdq8J15R9jZd58oxA+9Mpd9VcqKTrg5ge3m5Tvb lldVwoFoB7FfBNL0u+F+Wd2Y+7F7yqhFt0k9TW7VoMiOorXhRYusxS1fLBnU8audoqpEu5WzAYQsOL K2cWP0Q/dr5Yn0myMsUBBQA+Wm8w+Kg== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 25 Mar 2017 18:28:16 +0000 Message-ID: <589D55C2CF5942E9910482788CBDB445@Khan> From: "denis bider \(Bitvise\)" To: "Mouse" , References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG> In-Reply-To: <201703231224.IAA22091@Stone.Rodents-Montreal.ORG> Subject: Re: Fixing exchange of host keys in the SSH key exchange Date: Sat, 25 Mar 2017 12:28:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mouse: > > if the client has to communicate one or more fingerprints > > of the server's host key(s) before KEXINIT, this prevents > > the situation where the client will present the user with > > a host key verification dialog, and the user will just > > click through it. > How? A server that enforces this policy (not all would) will reject the connection outright if the client fails to send at least one correct Expect-Key. The client must therefore have it. > Yes...but if the server does that, it also becomes > impossible for the client to do the now-usual "just > accept the key on the first connection" thing. Preventing this, and requiring a stringent host key setup, is the central feature of this mechanism. It's an option that some of our users would like. > You have to provide the host key to the client by > some out-of-band means. Yes. The idea is to make sure this actually happens. > Another possible benefit would be automatic defeat of > host-key-gathering bots. Interesting. Yes, that would be a side effect for hosts that configure this policy. > I strongly suggest that it instead be something like > Expect-Key: Agreed. Yes, definitely - for the reasons you described. > I can't help wondering if perhaps this is time to use > the uint32 in SSH_MSG_KEXINIT that is "0 (reserved for > future extension)", Unfortunately, there exist implementations that disconnect, or generate an invalid key exchange hash, if that value is not zero. When I last checked in 2015, libssh was one. > Also, 4253 says the server MAY send text before its > version number, but is silent on the question of > whether the client also may. Hmm, keen observation. Of course, even if it did say otherwise, there could exist server implementations that do not handle this properly. It seems that testing would be in order. > It seems more elegant to me for the server to signal > support with something like > Accept-Expect-Key: yes Or maybe the server sends something like "Expect-Key: support|require". The format can vary between client and server. That might still not work if there are clients that violate 4253, though. Another way that would work for sure would be: - The server includes "expect-key" among its host key algorithms. The client never includes this algorithm. Instead it just sends signature algorithms that correspond to keys it knows for this server. - If client sees "expect-key" among server's host key algorithms, then immediately after its own KEXINIT, it sends a newly defined message, SSH_MSG_EXPECT_KEYS, which contains fingerprints of host keys trusted for this server. The server can now act according to its policy, based on whether it receives SSH_MSG_EXPECT_KEYS, and what it finds in it. This approach has downsides compared to Expect-Key before version string: - If client is required to send Expect-Key before version string, server can just be quiet and send nothing. The server can avoid being accurately fingerprinted. The server can't do this in the method that uses KEXINIT. - The method that requires EXPECT_KEYS after KEXINIT complicates guessed key exchange, since the client does not know upfront if the server supports it. Generally, if the client could send fingerprints without the server signaling anything, this would be superior. It would allow the server to not let itself be fingerprinted as accurately. (The OS can still be fingerprinted based on properties of its TCP stack, even if the SSH server application sends nothing.) denis ----- Original Message ----- From: Mouse Sent: Thursday, March 23, 2017 06:24 To: ietf-ssh@NetBSD.org Subject: Re: Fixing exchange of host keys in the SSH key exchange > I??m wondering if anyone - OpenSSH and PuTTY in particular? - would > be interested in implementing an extension to the way the initial SSH > handshake is done, in a way that would allow the SSH server to > require the client to communicate one or more fingerprints of the > server??s host key(s), before exchanging KEXINIT. > This would have multiple benefits: > (1) Security benefit: [...] if the client has to communicate one or > more fingerprints of the server??s host key(s) before KEXINIT, this > prevents the situation where the client will present the user with a > host key verification dialog, and the user will just click through > it. How? As far as I can see, in order to do that, you have to move that decision from the client to the server. This carries its own prices. > (2) Security benefit: on servers that enable this policy, and prevent > connections where the client does not communicate a correct server > host key, drive-by password guessing becomes largely impossible, > since unknown attackers do not know the server??s host key. Yes...but if the server does that, it also becomes impossible for the client to do the now-usual "just accept the key on the first connection" thing. You have to provide the host key to the client by some out-of-band means. This of course could be an upside or a downside, depending. > (3) Practical benefit: the server [...] can avoid the situation where > introduction of a new host key, with no change to previous host keys, > would break connections for existing clients that prefer to negotiate > the algorithm of the new host key, but do not actually trust it. True. Another possible benefit would be automatic defeat of host-key-gathering bots. My logs are full of clients that connect, get my host key, and then disconnect. A few of them are honest about what they're doing ("SSH-2.0-ZGrab ZGrab SSH Survey", or "SSH-2.0-OpenSSH-keyscan"); others are...less so ("SSH-2.0-PUTTY"). Most just report a library version (eg, "SSH-2.0-sshlib-0.1"). Or, rather, clients used to be doing that; I now disconnect such clients before giving them any host keys (I prefer to not talk about the details of what I've configured my server to require to get it to talk to a specific client). > Implementation: > We have room for textual data that can be sent before the SSH version > string. To implement this, the client would send one or more lines > such as: > Expect-Key: \r\n I strongly suggest that it instead be something like Expect-Key: so that when SHA256 finally shows weaknesses, it does not become a major headache to switch hash algorithms. If the server thinks the hash algorithm is too weak, or doesn't recognize it at all, it can ignore that line. The client can of course send hashes of the same key under multiple algorithms, if it wants. I can't help wondering if perhaps this is time to use the uint32 in SSH_MSG_KEXINIT that is "0 (reserved for future extension)", though, rather than shoehorning it into something that's currently outside the protocol (almost) entirely. I see no guidance in 4253 for implementation behaviour if that value isn't 0 - but see below. Also, 4253 says the server MAY send text before its version number, but is silent on the question of whether the client also may. (I suspect most server implementations share that code with their corresponding client implementations, though.) > However, we could also change the protocol to include the Expect-Key > lines in the SSH key exchange hash. In this case, the client would > signal support by sending at least one Expect-Key line, and the > server would signal support in another way. One way would be to > include the name "expect-key" among its host key algorithms in > KEXINIT. The server has at least as much room to send text before its version string as the client does. It seems more elegant to me for the server to signal support with something like Accept-Expect-Key: yes there - or perhaps to use that RFU uint32 in SSH_MSG_KEXINIT if the client signals support (which would avoid the issue of an unaware client printing that and thus confusing the user and possibly breaking scripted uses, and also restrict nonzero values to implementations that have already advertised awareness of this extension). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Mar 25 12:10:03 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906B2124234 for ; Sat, 25 Mar 2017 12:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com 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 R0KzZ_H2-NDy for ; Sat, 25 Mar 2017 12:10:01 -0700 (PDT) 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 A2D871252BA for ; Sat, 25 Mar 2017 12:10:01 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 36B17855BC; Sat, 25 Mar 2017 19:10:01 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CDEA3855B7 for ; Sat, 25 Mar 2017 19:09:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 4WcsrVqm_1C3 for ; Sat, 25 Mar 2017 19:09:55 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2A0B0855AF for ; Sat, 25 Mar 2017 19:09:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=41QjRDozVcoP6T5bMxuubtfLq/nUo4LVKETbi15LUSA=; b=St5oFHQds6HtWn2DOPPzr34PlaS6nvuZ59Qxmy+jXURMm8w6Y8W2TOERORVz+JJBFDUquAAlwnIpe R5voLd4cI3R3hcoEcVWqAgXmUkLsAGk7ioqJjDq6DWnUJ8hA9EDJcJEsAt2uosPBGpSbOaNfFn8ygq D+yb2Zl8BvGp4OfOKWUhh7u8DF+CdErvYFim3TJbcnNq+EdYZIkZQmS/6mQmYtGLNBaIWs+LBW5ZqA evndFAGvT4K+5DZuZXTUBaa/+41RC7oaaI9/7HmXQ0yX5dt/kICJMu0YencKG7NqDxKFBbea3DorfE 8GudiZqUqKvITJsiqKsLgSQaDI38e7w== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 25 Mar 2017 19:09:30 +0000 Message-ID: From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , Cc: , "Simon Tatham" References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <1490340148872.12344@cs.auckland.ac.nz> In-Reply-To: <1490340148872.12344@cs.auckland.ac.nz> Subject: Re: Fixing exchange of host keys in the SSH key exchange Date: Sat, 25 Mar 2017 13:09:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter: > > this prevents the situation where the client will present > > the user with a host key verification dialog, and the user > > will just click through it. > > It also makes things a lot more painful for the user. It helps ensure secure host key configuration. There are administrators who would prefer this. If this involves more pain than previously, the user was most likely not managing host key trust to the same standards. > If you regularly need to SSH into a dozen different devices > to administer them, it gets even worse. This is meant for administrators who would want to enable this policy. This would be a server-side policy, so if you're administering machines, you could avoid configuring this policy. > > drive-by password guessing becomes largely impossible, > > since unknown attackers do not know the servers host key. > > This is really just an awkward form of port-knocking. Yes, and we have other mechanisms for this (e.g. protocol obfuscation). In this case, it's a nice effect you get for free, in case you enable this policy. > > Server implementations that do not know about this extension, > > but correctly implement the spec, > > How do we know what percentage of servers do this? We don't, it would be necessary to test this. Which means, probably, I would have to test this. Mouse pointed out I was wrong about the spec. It turns out RFC 4253 provides for text before version string when sent by servers, not by clients. It's definitely necessary to test. As discussed with Mouse, if this exact method doesn't work, there are alternatives. Server could send "expect-key" host key alg in KEXINIT, and client could send a new message SSH_MSG_EXPECT_KEYS after its KEXINIT. This would still solve the primary objective, but would not have all the same nice properties. E.g. the server could not use that to avoid fingerprinting. > it has the potential to break lots of things That seems to be the main potential downside of the method as presented. But there are other ways to do it, and the suggested approach could be proven safe in testing. denis ----- Original Message ----- From: Peter Gutmann Sent: Friday, March 24, 2017 01:22 To: denis bider (Bitvise) ; ietf-ssh@netbsd.org Cc: djm@mindrot.org ; Simon Tatham Subject: Re: Fixing exchange of host keys in the SSH key exchange denis bider (Bitvise) writes: >(1) Security benefit: although the client could still not verify the servers >signature during key exchange, or could do any number of other things >incorrectly; under reasonable assumptions, if the client has to communicate >one or more fingerprints of the servers host key(s) before KEXINIT, this >prevents the situation where the client will present the user with a host >key >verification dialog, and the user will just click through it. It also makes things a lot more painful for the user. If you regularly need to SSH into a dozen different devices to administer them, it gets even worse. >(2) Security benefit: on servers that enable this policy, and prevent >connections where the client does not communicate a correct server host >key, >drive-by password guessing becomes largely impossible, since unknown >attackers do not know the servers host key. This is really just an awkward form of port-knocking. If you want to use a port-knocking-style mechanism, you should probably do it properly. If you want to bind a client to a server ("only this client, only this server") then there are better ways of doing it than this. >Server implementations that do not know about this extension, but correctly >implement the spec, How do we know what percentage of servers do this? It's true that the spec says you should expect other stuff in the textual data, but since pretty much everything out there only ever sends the SSH ID string, it's quite likely that lots of implementations will choke on unexpected extra lines of text. Even in cases where the code does try and handle non-SSH-ID lines, the absence of anything that sends them means it's probably never been tested. This doesn't seem like a good idea, it has the potential to break lots of things, while what you're getting in return could be done better in other ways. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 00:05:54 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D79D129431 for ; Sun, 26 Mar 2017 00:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HlaqOtdx4aQi for ; Sun, 26 Mar 2017 00:05:52 -0700 (PDT) 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 6628A1243F6 for ; Sun, 26 Mar 2017 00:05:52 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 918E0855BE; Sun, 26 Mar 2017 07:05:50 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 502E584CE1; Sun, 26 Mar 2017 07:05:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AA8C585604 for ; Sat, 25 Mar 2017 12:27:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id SBMAGlxsLHgJ for ; Sat, 25 Mar 2017 12:27:39 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 84EE385600 for ; Sat, 25 Mar 2017 12:27:38 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id IAA20189; Sat, 25 Mar 2017 08:27:37 -0400 (EDT) Date: Sat, 25 Mar 2017 08:27:37 -0400 (EDT) From: Mouse Message-Id: <201703251227.IAA20189@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 25 Mar 2017 07:43:11 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Fixing exchange of host keys in the SSH key exchange In-Reply-To: <1490340148872.12344@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <1490340148872.12344@cs.auckland.ac.nz> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> (1) Security benefit: although [...]; under reasonable assumptions, >> if the client has to communicate one or more fingerprints of the >> server?s host key(s) before KEXINIT, this prevents the situation >> where the client will present the user with a host key verification >> dialog, and the user will just click through it. > It also makes things a lot more painful for the user. How? As far as I can see, this affects the user only in that "pick up the host key on first connect" no longer works. In particular... > If you regularly need to SSH into a dozen different devices to > administer them, it gets even worse. ...I can't see how it affects the user if the client already has a correct host key for the server. >> (2) Security benefit: [...] > This is really just an awkward form of port-knocking. Awkward? _Less_ awkward in some respects - significantly easier to set up in most cases, for example, with no need for anything client-side beyond a client that knows the extension. But weaker in other respects; for example, it reveals the presence of an ssh server to anyone, even someone who doesn't know the knock (well, probable presence; nothing says someone can't use port 22 for something else). >> Server implementations that do not know about this extension, but >> correctly implement the spec, [...] > How do we know what percentage of servers do this? We don't, of course. But note that the spec does not say that the _client_ may send text before its version string, only that the _server_ may. (Or, at least, if it says that about the client, I haven't found where.) Furthermore, just because some implementations are broken (if the consensus is that that constitutes brokenness, of course) is not a reason to fail to call them on their brokenness. I've run into ssh servers that fall over hard when confronted with clients using the string@domainname extension mechanism. Should we stop using it as a result? No, we should get the relevant servers fixed (and, as an interim measure for the immediate term, tell clients to not use extensions when talking with such broken servers). > It's true that the spec says you should expect other stuff in the > textual data, but since pretty much everything out there only ever > sends the SSH ID string, it's quite likely that lots of > implementations will choke on unexpected extra lines of text. Well, if the consensus is that the client is allowed to send text there (if not, this becomes a private protocol change, not suitable for interoperation use), then my stance is that that's their problem. My advice for users dealing with such servers would be "either get the server fixed or turn off the extension when using it". > Even in cases where the code does try and handle non-SSH-ID lines, > the absence of anything that sends them means it's probably never > been tested. Then this suggestion has the additional feature that it will smoke out such bugs! Hmm, I think I'll give moussh a configuration option to send things before the ID string, for exactly that reason. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 00:06:06 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFD9129431 for ; Sun, 26 Mar 2017 00:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 J5POWiSL0iKN for ; Sun, 26 Mar 2017 00:06:05 -0700 (PDT) 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 4BEBB1243F6 for ; Sun, 26 Mar 2017 00:06:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 127F7855CC; Sun, 26 Mar 2017 07:06:05 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C1F77855CA; Sun, 26 Mar 2017 07:06:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 95A10855C4 for ; Sun, 26 Mar 2017 02:43:39 +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 G3Qw4gxDxurB for ; Sun, 26 Mar 2017 02:43:39 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 66B7C85589 for ; Sun, 26 Mar 2017 02:43:36 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id WAA05983; Sat, 25 Mar 2017 22:43:35 -0400 (EDT) Date: Sat, 25 Mar 2017 22:43:35 -0400 (EDT) From: Mouse Message-Id: <201703260243.WAA05983@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 25 Mar 2017 22:18:31 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Fixing exchange of host keys in the SSH key exchange In-Reply-To: <589D55C2CF5942E9910482788CBDB445@Khan> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG> <589D55C2CF5942E9910482788CBDB445@Khan> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> I can't help wondering if perhaps this is time to use the uint32 in >> SSH_MSG_KEXINIT that is "0 (reserved for future extension)", > Unfortunately, there exist implementations that disconnect, or > generate an invalid key exchange hash, if that value is not zero. I'm not sure what my stance is on that. In general, I take the stand that if there are implementations that don't implement the spec correctly, that's their problem, not a reason to avoid using that part of the spec. But, here, I don't think there's any current spec for what an implementation should do if it finds a nonzero value there, so I'm not sure to what extent _any_ behaviour in response to that constitutes misbehaviour. In retrospect, I think specifying that RFU zero without giving any explicit guidance for behaviour upon finding it nonzero was a mistake. >> Also, 4253 says the server MAY send text before its version number, >> but is silent on the question of whether the client also may. > Of course, even if it did say otherwise, there could exist server > implementations that do not handle this properly. Of course - but then it would clearly be a case of the servers in question being broken (and my stance would be that it's the server's problem - see above). As it is, it's not clear. > It seems that testing would be in order. Probably. But it seems to me that any implementation SHOULD have client configuration knobs so that Expect-Key: is not sent unless the server is expected to be prepared to handle it. > Or maybe the server sends something like "Expect-Key: > support|require". The format can vary between client and server. > That might still not work if there are clients that violate 4253, > though. That's the problem of any such clients. IMO. (As I think I said upthread, I've encountered servers that misbehave - crash or something equivalent from the client's point of view - when faced with the string@domainname extension feature. Is that a reason to not use it?) > Another way that would work for sure would be: > - The server includes "expect-key" among its host key algorithms. > [...] > - If client sees "expect-key" among server's host key algorithms, > [...] Yesss...though there may exist implementations that misbehave upon seeing a non-extension algorithm name they do not recognize. (My stance, as above, would be that such implementations are broken and deserve nothing but ridicule, but your remarks above seem to imply you don't take that stance, or at least not as much as I do.) > This approach has downsides compared to Expect-Key before version > string: [...] Both true, though the second one (that it interferes with guessed kex) is weak in that all it means is that clients and servers using this extension can't really do guessed kex. But all guessed kex really buys you is one network roundtrip fewer, and I submit that if that matters then either you have a _really_ laggy network or your PK crypto is so weak that your security is questionable anyway. :-) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 01:53:27 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24AF124B0A for ; Sun, 26 Mar 2017 01:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 b6MRJq14LELH for ; Sun, 26 Mar 2017 01:53:25 -0700 (PDT) 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 B4D4E12420B for ; Sun, 26 Mar 2017 01:53:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 81CF1855B0; Sun, 26 Mar 2017 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 58D46855A1 for ; Sun, 26 Mar 2017 08:53:22 +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 HcLT3LqfSXJY for ; Sun, 26 Mar 2017 08:53:21 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 47BD184CDD for ; Sun, 26 Mar 2017 08:53:20 +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=1490518401; x=1522054401; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mdb0BejDVks1bB3c2GA6N97JiPexb56ixio/Y33Gkos=; b=mg1QGmyMt5mb1ToDLMIXCNxL/7ighegMHLErDODUGfVcjgjh4nFd+B0C XskltTSkBsSqDE0P+odSWGS1aWHytj6t53FsiioveNYBJ0cAK6h6fTG3Y /IteTdoux+vmvFXJ3Pi4b5CTjC+uuEnMzbno47NBOriMBM3/OFdjEgQLJ 9vM21E+xP8t1gXH/rTJGbHz3riMDetK3mvXjd3c1mX0iizzT5UVf0aaPM qdfUfTNdqBr0aaSzKkN9/8cTfce+2l9C6GbUu4pzxzQr8FyNQ0eNeKNKJ Gxg0KantQwWOuH/J8Fmg/WY1hqdTEwV64DySKG15TgqH/0WdoXm5p/4yJ Q==; X-IronPort-AV: E=Sophos;i="5.36,225,1486378800"; d="scan'208";a="145554127" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 26 Mar 2017 21:53:18 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 26 Mar 2017 21:53:18 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Sun, 26 Mar 2017 21:53:18 +1300 From: Peter Gutmann To: Mouse , "ietf-ssh@NetBSD.org" Subject: Re: Fixing exchange of host keys in the SSH key exchange Thread-Topic: Fixing exchange of host keys in the SSH key exchange Thread-Index: AQHSo6JCh/pnJs1+UUq8ewlt+ue/5qGjlx6QgAEOD4CAAi+kRQ== Date: Sun, 26 Mar 2017 08:53:18 +0000 Message-ID: <1490518384910.80699@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <1490340148872.12344@cs.auckland.ac.nz>,<201703251227.IAA20189@Stone.Rodents-Montreal.ORG> In-Reply-To: <201703251227.IAA20189@Stone.Rodents-Montreal.ORG> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted 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 Mouse writes:=0A= =0A= >As far as I can see, this affects the user only in that "pick up the host = key=0A= >on first connect" no longer works.=0A= =0A= It breaks TOFU. Since this is how the vast majority of all users use SSH= =0A= (ref: https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf= ),=0A= it means it would break SSH for them. Conversely, it means the vast majori= ty=0A= won't use it.=0A= =0A= >Then this suggestion has the additional feature that it will smoke out suc= h=0A= >bugs!=0A= =0A= Trying to smoke out non-standards-compliant implementations at this point,= =0A= about twenty-odd after SSH2 started getting deployed, is probably a bit lat= e=0A= in the game.=0A= =0A= Also, does this mean any implemenation that doesn't correctly implement a M= UST=0A= or MUST NOT can regarded as broken and discarded?=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 18:20:56 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236951289B5 for ; Sun, 26 Mar 2017 18:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.861 X-Spam-Level: X-Spam-Status: No, score=-3.861 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com 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 EY6bDY1zFdLn for ; Sun, 26 Mar 2017 18:20:53 -0700 (PDT) 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 BD63C12894E for ; Sun, 26 Mar 2017 18:20:53 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id DC9C78559F; Mon, 27 Mar 2017 01:20: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 3980885588 for ; Mon, 27 Mar 2017 01:20:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id Bj6uLxxSIPUm for ; Mon, 27 Mar 2017 01:20:47 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A98F784CDE for ; Mon, 27 Mar 2017 01:20:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=iBjwBBimQkC3yjRI+4tnm6y/bagkLYP8eAnUkqsFpyQ=; b=d4WYEDrGPjZ4xVK5TRIdmzGAbp1k/FA7jPjjaFPbasDVoouK/pJtkQVde6ojoFHGds0IsXBmy1PIM SIjNfxkET20W5bWDH2L/sSqws6GYbqlg4WurpaCkUnoNHe8zvgBzbIlxjIjenj+RSa9+wSLhp250L1 p820dm+2P5hrsQ09ecPEP/tN8ioPXFSLj7UfAeCuuAaJTZSQ+KFBgrnCp0c4lrxHgEnBVooLNMWaZT 2VeOfXOTAQfUxdrypge8zRl8uGtvmIafJ55NRBWjZJq84d+c+r6wuQLTm64+0t7/mVfCS2nD0oS6H0 hSY80BsuQJvJKPA7NGz33aw9i89Le7g== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 27 Mar 2017 02:20:36 +0100 Message-ID: From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , "Mouse" , References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan><1490340148872.12344@cs.auckland.ac.nz>,<201703251227.IAA20189@Stone.Rodents-Montreal.ORG> <1490518384910.80699@cs.auckland.ac.nz> In-Reply-To: <1490518384910.80699@cs.auckland.ac.nz> Subject: Re: Fixing exchange of host keys in the SSH key exchange Date: Sun, 26 Mar 2017 19:20:47 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter: > https://www.usenix.org/system/files/login/articles/ > 105484-Gutmann.pdf This article is actually a strong argument in favor of Expect-Key, or something like it. What you found is NOT that people use TOFU (Trust On First Use). They use TWAT - Trust Whatever, Any Time: > I asked the IT support staff how many users had called > or emailed to verify the SSH server key whenever it had > changed in the past several years. They were unable to > recall a single case, or locate any records, of any user > ever verifying any SSH server key out-of-band This is highly problematic because it means that, while SSH is supposed to defend against MITM in theory, it does not defend in practice. OpenSSH already addresses this in their client, I believe, by making it really quite hard to verify a changed key. Many users further configure the OpenSSH client to require a key to be set up for the first connection, to begin with. Expect-Key just extends that - which I think is a good practice - to all clients, in general, enforceable as a server-side policy. It defeats TWAT. > Conversely, it means the vast majority won't use it. Users will use what administrators set up for them. If admins don't want to set up Expect-Key, fine. But this gives them a tool. denis ----- Original Message ----- From: Peter Gutmann Sent: Sunday, March 26, 2017 02:53 To: Mouse ; ietf-ssh@NetBSD.org Subject: Re: Fixing exchange of host keys in the SSH key exchange Mouse writes: >As far as I can see, this affects the user only in that "pick up the host >key >on first connect" no longer works. It breaks TOFU. Since this is how the vast majority of all users use SSH (ref: https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf), it means it would break SSH for them. Conversely, it means the vast majority won't use it. >Then this suggestion has the additional feature that it will smoke out such >bugs! Trying to smoke out non-standards-compliant implementations at this point, about twenty-odd after SSH2 started getting deployed, is probably a bit late in the game. Also, does this mean any implemenation that doesn't correctly implement a MUST or MUST NOT can regarded as broken and discarded? Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 18:24:23 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFEB1274D2 for ; Sun, 26 Mar 2017 18:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 09vFWJoEx6Xg for ; Sun, 26 Mar 2017 18:24:22 -0700 (PDT) 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 27290127058 for ; Sun, 26 Mar 2017 18:24:22 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 26AD4855B6; Mon, 27 Mar 2017 01:24: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 7925F855B0 for ; Mon, 27 Mar 2017 01:24:19 +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 6_IoFWLmMQcr for ; Mon, 27 Mar 2017 01:24:18 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 68D2E85588 for ; Mon, 27 Mar 2017 01:24:17 +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=1490577858; x=1522113858; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=s11kwKx1ZCWEjZMp9R+BdPUUfSBmMJaaZenwvYz8M1o=; b=tYo432Ujkg0A/IbbY7iPI3kIfedjyjwLA46J6rOLitRv62Mv1Arg635l stvPkb3+Iuoro6lehnxMPlnO7g+lQ4UHH2zCW8YAt3UAr8xZ5Rq2PRLGq +MhSn5TOxg5ZNAUQE+Mg8qnHd7iuU/xI2Vc0MIJoDCrK8ufHyg+4/V0ME nAJBrd08k0IWfA1t3EHqrHP49BJTZSYbGmpR4FmO6DDOyRVDYjE15wbze cE38txwydUsmbbgQ5jG4X10UMr0CLObNy4yPTfx7BFlgCD8GleT0sfU3R S5xqdjGBUttuMjHIqoDTlQ+E1V2kCTpQLMP9oxkLXdoA2nPC4OI3VVrp5 w==; X-IronPort-AV: E=Sophos;i="5.36,229,1486378800"; d="scan'208";a="145826810" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Mar 2017 14:24:15 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 27 Mar 2017 14:24:14 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Mon, 27 Mar 2017 14:24:14 +1300 From: Peter Gutmann To: "denis bider (Bitvise)" , Mouse , "ietf-ssh@NetBSD.org" Subject: Re: Fixing exchange of host keys in the SSH key exchange Thread-Topic: Fixing exchange of host keys in the SSH key exchange Thread-Index: AQHSo6JCh/pnJs1+UUq8ewlt+ue/5qGjlx6QgAEOD4CAAi+kRYAAOraAgADa1j4= Date: Mon, 27 Mar 2017 01:24:13 +0000 Message-ID: <1490577838596.99358@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan><1490340148872.12344@cs.auckland.ac.nz>,<201703251227.IAA20189@Stone.Rodents-Montreal.ORG> <1490518384910.80699@cs.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-ms-exchange-transport-fromentityheader: Hosted 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 (Bitvise) writes:=0A= =0A= >What you found is NOT that people use TOFU (Trust On First Use). They use= =0A= >TWAT - Trust Whatever, Any Time:=0A= =0A= Damn, I could've used that in the article :-).=0A= =0A= >This is highly problematic because it means that, while SSH is supposed to= =0A= >defend against MITM in theory, it does not defend in practice.=0A= =0A= Yeah, as the article points out, X.509 fans can point out that SSH is no=0A= better, and SSH fans can point out that SSH is no worse.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 22:32:55 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861631241FC for ; Sun, 26 Mar 2017 22:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.861 X-Spam-Level: X-Spam-Status: No, score=-3.861 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com 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 yVLdutoomX_6 for ; Sun, 26 Mar 2017 22:32:53 -0700 (PDT) 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 88C9C1274D0 for ; Sun, 26 Mar 2017 22:32:53 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 3EF12855C1; Mon, 27 Mar 2017 05:32:52 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id E5356855BA; Mon, 27 Mar 2017 05:32:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C211985588 for ; Mon, 27 Mar 2017 01:08:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 11yvQsuRmwWR for ; Mon, 27 Mar 2017 01:08:38 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0DB9584CDE for ; Mon, 27 Mar 2017 01:08:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=wN6XqiTuGysgRWBcpmMHKnUpzLU6/j9q/M//aGG82lU=; b=Pu4d/aK98SOJwe6wFi0+7+AiavrKpk5xqOcwTfltVhLMDnOjiov+og+oRxIKsykmVeKRXDhTGeAz9 TX4/igcCbBjkOijFUGXXFERnY9f6/fPKFZQymK2xKpY1bPzo4Rn5ct6L+3TToEQpWU1XPeSDtldDd+ lyWfEeJLI99aDc5ihVOi9/KjiDFkJRyeVzGGBGq/HD6JH7FMsVJsL5oqoWNOcdjc8YJkiMUSjz5WXC YjxBZf02TJeGMf9QST4rX2shGwK3lSObng0fh59MSRY0K9jNBV0TBDz5yoR6/1gaHyEJIAE8qPEmk3 gOzcmDzOm3zPFqWiv5i2het90r/D0kg== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 27 Mar 2017 02:08:33 +0100 Message-ID: From: "denis bider \(Bitvise\)" To: "Mouse" , References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG> In-Reply-To: <201703260243.WAA05983@Stone.Rodents-Montreal.ORG> Subject: Re: Fixing exchange of host keys in the SSH key exchange Date: Sun, 26 Mar 2017 19:08:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mouse: > I've encountered servers that misbehave – crash or something > equivalent from the client's point of view - when faced with > the string@domainname extension feature. I am flummoxed by the existence of such implementations. Surely, that would not even be compatible with OpenSSH? Have you seen any of these recently? Was that perhaps a decade ago, when OpenSSH maybe didn't have a KEXINIT full of string@domain algorithms by default? > My stance, as above, would be that such implementations are > broken and deserve nothing but ridicule, but your remarks > above seem to imply you don't take that stance, or at least > not as much as I do. I do take the stance that a broken implementation is broken, but this does not change that I'm usually expected to do something about it, and folks want me to work around it so it works. For the most recent example, an older version of a popular library used to have the "maximum channel packet size" concept completely borked up. For a channel opened by the remote party, this library would overwrite its own maximum packet size with the remote one. This caused at least two different kinds of session-ending problems to arise. The library fixed this problem years ago. But a customer wrote an application using the old version - it worked until then, why fix it?! - and deployed that on N installations. These installations now wouldn't work with our software, but are difficult to update. It was less costly if we implement a coping mechanism. So we did. I'd like to think our implementation is close to defect-free, but chances are someone somewhere was tasked to implement a workaround for a bug that existed in our software, even if it had long since been fixed. We judge our own software based on the next version we're about to release; and other people's software based on all versions that existed. :) > Hmm, I think I'll give moussh a configuration option to > send things before the ID string, for exactly that reason. That would be amazing. I could implement it as an option, but unless it is on by default, there's no way we'll get feedback. At this point, the most feasible option I see is the type of probing you said you don't like: blind connections to random IP addresses to produce statistics how often it works or not. denis ----- Original Message ----- From: Mouse Sent: Saturday, March 25, 2017 20:43 To: ietf-ssh@NetBSD.org Subject: Re: Fixing exchange of host keys in the SSH key exchange >> I can't help wondering if perhaps this is time to use the uint32 in >> SSH_MSG_KEXINIT that is "0 (reserved for future extension)", > Unfortunately, there exist implementations that disconnect, or > generate an invalid key exchange hash, if that value is not zero. I'm not sure what my stance is on that. In general, I take the stand that if there are implementations that don't implement the spec correctly, that's their problem, not a reason to avoid using that part of the spec. But, here, I don't think there's any current spec for what an implementation should do if it finds a nonzero value there, so I'm not sure to what extent _any_ behaviour in response to that constitutes misbehaviour. In retrospect, I think specifying that RFU zero without giving any explicit guidance for behaviour upon finding it nonzero was a mistake. >> Also, 4253 says the server MAY send text before its version number, >> but is silent on the question of whether the client also may. > Of course, even if it did say otherwise, there could exist server > implementations that do not handle this properly. Of course - but then it would clearly be a case of the servers in question being broken (and my stance would be that it's the server's problem - see above). As it is, it's not clear. > It seems that testing would be in order. Probably. But it seems to me that any implementation SHOULD have client configuration knobs so that Expect-Key: is not sent unless the server is expected to be prepared to handle it. > Or maybe the server sends something like "Expect-Key: > support|require". The format can vary between client and server. > That might still not work if there are clients that violate 4253, > though. That's the problem of any such clients. IMO. (As I think I said upthread, I've encountered servers that misbehave - crash or something equivalent from the client's point of view - when faced with the string@domainname extension feature. Is that a reason to not use it?) > Another way that would work for sure would be: > - The server includes "expect-key" among its host key algorithms. > [...] > - If client sees "expect-key" among server's host key algorithms, > [...] Yesss...though there may exist implementations that misbehave upon seeing a non-extension algorithm name they do not recognize. (My stance, as above, would be that such implementations are broken and deserve nothing but ridicule, but your remarks above seem to imply you don't take that stance, or at least not as much as I do.) > This approach has downsides compared to Expect-Key before version > string: [...] Both true, though the second one (that it interferes with guessed kex) is weak in that all it means is that clients and servers using this extension can't really do guessed kex. But all guessed kex really buys you is one network roundtrip fewer, and I submit that if that matters then either you have a _really_ laggy network or your PK crypto is so weak that your security is questionable anyway. :-) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 22:33:42 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B2F1293F3 for ; Sun, 26 Mar 2017 22:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 I8InwXamD3xH for ; Sun, 26 Mar 2017 22:33:41 -0700 (PDT) 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 08CE3128BE1 for ; Sun, 26 Mar 2017 22:33:41 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id C24A9855EB; Mon, 27 Mar 2017 05:33:40 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 7F9B0855D8; Mon, 27 Mar 2017 05:33:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 80C64855B6 for ; Sun, 26 Mar 2017 12:10:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 2KX2S8Gb93M5 for ; Sun, 26 Mar 2017 12:10:55 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 853918557F for ; Sun, 26 Mar 2017 12:10:54 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id IAA26334; Sun, 26 Mar 2017 08:10:53 -0400 (EDT) Date: Sun, 26 Mar 2017 08:10:53 -0400 (EDT) From: Mouse Message-Id: <201703261210.IAA26334@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sun, 26 Mar 2017 07:53:00 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Fixing exchange of host keys in the SSH key exchange In-Reply-To: <1490518384910.80699@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <1490340148872.12344@cs.auckland.ac.nz>,<201703251227.IAA20189@Stone.Rodents-Montreal.ORG> <1490518384910.80699@cs.auckland.ac.nz> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> As far as I can see, this affects the user only in that "pick up the >> host key on first connect" no longer works. > It breaks TOFU. Yes. As denis recently said, that's the major point of it: some - probably a minority, but so what? - server admins _want_ to break TOFU, to ensure that their users are doing more secure key handling. Another possibility is that users _do_ use TOFU, but are allowed to only over secure-enough networks. This allows configurations like "You're coming from the office LAN, you can TOFU - but when you come in over the open Internet, you have to already have the host key", by providing a mechanism to enforce the second half of it. > Since this is how the vast majority of all users use SSH [...], it > means it would break SSH for them. Conversely, it means the vast > majority won't use it. Which is fine. Having it available does not mean it should be the default. >> Then this suggestion has the additional feature that it will smoke >> out such bugs! > Trying to smoke out non-standards-compliant implementations at this > point, about twenty-odd after SSH2 started getting deployed, is > probably a bit late in the game. Probably. But better late than never. Though, as remarked upthread, it's not clear that breaking on pre-ID text in the client-to-server direction _is_ a bug. > Also, does this mean any implemenation that doesn't correctly > implement a MUST or MUST NOT can regarded as broken and discarded? Ideally. But that's true of any spec. Those ssh implementations I mentioned upthread that crashed upon seeing string@domain extensions? We didn't discard them; we worked around them. I would have preferred to replace them, but that was not practical at the time (this years ago was at work and they were embedded servers on, IIRC, network switches - I hope we filed bug reports with the vendor(s) in question, but I'm not sure of even that much). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 22:34:24 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1314A126C7B for ; Sun, 26 Mar 2017 22:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 cvtN804zL0QN for ; Sun, 26 Mar 2017 22:34:22 -0700 (PDT) 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 AA2C9126C7A for ; Sun, 26 Mar 2017 22:34:22 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6FE39855FF; Mon, 27 Mar 2017 05:34:22 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 2CF57855FD; Mon, 27 Mar 2017 05:34:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2425A855F3 for ; Mon, 27 Mar 2017 03:27:31 +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 f9OgAnrALA94 for ; Mon, 27 Mar 2017 03:27:30 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 2AF07855EB for ; Mon, 27 Mar 2017 03:27:29 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id XAA25497; Sun, 26 Mar 2017 23:27:29 -0400 (EDT) Date: Sun, 26 Mar 2017 23:27:29 -0400 (EDT) From: Mouse Message-Id: <201703270327.XAA25497@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sun, 26 Mar 2017 22:26:16 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Fixing exchange of host keys in the SSH key exchange In-Reply-To: References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> I've encountered servers that misbehave ?? crash or something >> equivalent from the client's point of view - when faced with the >> string@domainname extension feature. > I am flummoxed by the existence of such implementations. So was I! > Surely, that would not even be compatible with OpenSSH? I don't know. I suspect I tried OpenSSH against them, since I can't imagine why I would have suspected it were DNS-based extensions causing trouble without "works" and "fails" traces to compare, and OpenSSH is the most plausible other implementation for me to have had at hand. But it would have been OpenSSH of that era. This was relatively long ago; in particular, it was before 2008-07-03 - that's the oldest moussh source tree I have at ready hand, and it's got -no-private (see below). > Have you seen any of these recently? No, but I haven't had much opportunity to, either. (They were the SSH listeners on devices such as switches.) > Was that perhaps a decade ago, when OpenSSH maybe didn't have a > KEXINIT full of string@domain algorithms by default? That timing is about right. I don't, and didn't, track what OpenSSH does (resp. is doing), though. > I do take the stance that a broken implementation is broken, but this > does not change that I'm usually expected to do something about it, > and folks want me to work around it so it works. I sympathize. Those switches (or whatever they were) are the reason moussh has -no-private: -no-private Disables attempts to use private requests and algorithms (any- thing using the DNS extensibility mechanism, basically). This should never be needed, but at least one commercial server is known to break when faced with such names. [...] > I'd like to think our implementation is close to defect-free, but > chances are someone somewhere was tasked to implement a workaround > for a bug that existed in our software, even if it had long since > been fixed. Probably. Same goes for moussh, though it's more likely nobody has cared enough since moussh surely has a much smaller user base. > We judge our own software based on the next version we're about to > release; and other people's software based on all versions that > existed. :) That is a common problem. Stance. Whatever you want to call it. :-) >> Hmm, I think I'll give moussh a configuration option to send things >> before the ID string, for exactly that reason. > That would be amazing. I could implement it as an option, but unless > it is on by default, there's no way we'll get feedback. I'll try to remember to mention it here when I finally get around to adding it. So far I've added it to nothing but my TODO list. > At this point, the most feasible option I see is the type of probing > you said you don't like: blind connections to random IP addresses to > produce statistics how often it works or not. Quite aside from whether it's moral to use others' servers for your own purposes like that, that isn't going to tell you more than whether they are willing to talk to you. If they drop the connection, you will not be in a position to tell whether it's because they crashed upon seeing your pre-version text, or they're configured (as mine are) to refuse to talk to third parties who don't exhibit whatever behaviour they're configured to look for, or they crashed for an unrelated reason, or what. Also, would "fraction of random IP addresses with ssh servers that don't crash upon seeing $THING" really be useful statistic, even if were one you could get? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 22:34:48 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3399E126C7A for ; Sun, 26 Mar 2017 22:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 mfD_HM1l1aEA for ; Sun, 26 Mar 2017 22:34:46 -0700 (PDT) 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 C11221241FC for ; Sun, 26 Mar 2017 22:34:46 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 8E95A855FD; Mon, 27 Mar 2017 05:34:46 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 4B3E4855C1; Mon, 27 Mar 2017 05:34:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F38DA855F3 for ; Mon, 27 Mar 2017 03:30:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id RvZ6hOLumArS for ; Mon, 27 Mar 2017 03:30:06 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 21DFE855EB for ; Mon, 27 Mar 2017 03:30:06 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id XAA28787; Sun, 26 Mar 2017 23:30:05 -0400 (EDT) Date: Sun, 26 Mar 2017 23:30:05 -0400 (EDT) From: Mouse Message-Id: <201703270330.XAA28787@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sun, 26 Mar 2017 23:28:24 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Fixing exchange of host keys in the SSH key exchange In-Reply-To: References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan><1490340148872.12344@cs.auckland.ac.nz>,<201703251227.IAA20189@Stone.Rodents-Montreal.ORG> <1490518384910.80699@cs.auckland.ac.nz> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > This is highly problematic because it means that, while SSH is > supposed to defend against MITM in theory, it does not defend in > practice. Not in the hands of "the masses", no. But very little will. It _does_ give the tools to those competent to use them; I think that's about all any such protocol can really expect to do. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 22:47:37 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0475128B4E for ; Sun, 26 Mar 2017 22:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 0DSebkN1eunO for ; Sun, 26 Mar 2017 22:47:36 -0700 (PDT) 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 E945D126C7B for ; Sun, 26 Mar 2017 22:47:35 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id E491D855D5; Mon, 27 Mar 2017 05:47: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 E6ABA855BA for ; Mon, 27 Mar 2017 05:47: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 nN3m7hBKce4b for ; Mon, 27 Mar 2017 05:47:32 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 8DFC88559A for ; Mon, 27 Mar 2017 05:47: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=1490593651; x=1522129651; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=4eEltawMZJjZYcbo0+tTEQplV49a2zL5FsQbNwQq2SU=; b=18pMgymQ1WoXsuddKutHlEO5z7MdRcboG3UMjAhQcA+5Valv6vhEhyVk Vadw4wNq6WH4h5BBNhP3vgegous4iviPcvzB8jNJhR4TdjkfMOFfig+j8 Vdc4j3WLCgn6Bq3HKh86Z70egCvZvgbzlB6NlsVv9+8WcqK0LdFM3KbT/ FEhTnGYYaoPf31Cpje5D20l9nEv68At4/otV+w8yrL5rr+Mj1YtvhGRO5 DaQvDXuIsCtZylkoRx0DkzteIkuL9b9D6HfIb6hcDX8XE1YvVv4hIgqWN vjKiLN9ZueUqQS1B7WUXCa0f8gwwrI+oh7/dqXEIxRWawcdAdgnzS1Fsa A==; X-IronPort-AV: E=Sophos;i="5.36,229,1486378800"; d="scan'208";a="145878513" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Mar 2017 18:47:29 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 27 Mar 2017 18:47:28 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Mon, 27 Mar 2017 18:47:28 +1300 From: Peter Gutmann To: Mouse , "ietf-ssh@netbsd.org" Subject: Re: Fixing exchange of host keys in the SSH key exchange Thread-Topic: Fixing exchange of host keys in the SSH key exchange Thread-Index: AQHSo6JCh/pnJs1+UUq8ewlt+ue/5qGhf50AgAOKXICAAIpbgIABd8WAgAAm1ICAAQBvHg== Date: Mon, 27 Mar 2017 05:47:28 +0000 Message-ID: <1490593648496.70339@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG> ,<201703270327.XAA25497@Stone.Rodents-Montreal.ORG> In-Reply-To: <201703270327.XAA25497@Stone.Rodents-Montreal.ORG> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted 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 Mouse writes:=0A= =0A= >(They were the SSH listeners on devices such as switches.)=0A= =0A= It seems to be an unwritten law that big-iron networking hardware has to ru= n=0A= 15-to-20-year-old unpatched copies of some version of SSH that the=0A= switch/router vendor found in a dumpster somewhere. I've seen late-1990s= =0A= ssh.com implementations as recently as a few years ago, which is why I have= to=0A= keep active old SSH bug-workarounds that should have been retired a decade = or=0A= more ago. Being able to remotely crash a carrier-grade router [0] by sendi= ng=0A= it an SSH option it didn't expect is a bit disturbing... this is why my cod= e=0A= grew a dump-full-packet-trace-to-debug-console option at some point in the= =0A= past.=0A= =0A= Peter.=0A= =0A= [0] I guess the SSH part is excluded from the carrier-grade categorisation.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 22:55:11 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FA21293DA for ; Sun, 26 Mar 2017 22:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 fSpSbC_yAr5T for ; Sun, 26 Mar 2017 22:55:10 -0700 (PDT) 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 F3076126C7A for ; Sun, 26 Mar 2017 22:55:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6AA7C855BA; Mon, 27 Mar 2017 05:55:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 6E03C8559A for ; Mon, 27 Mar 2017 05:55:07 +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 SIQ1kkjXjDKH for ; Mon, 27 Mar 2017 05:55:06 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 62B1084CDA for ; Mon, 27 Mar 2017 05:55:06 +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=1490594106; x=1522130106; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gEOOPt1/uHpvsXFcq9j7T2YljlpYry+fH6e/RnNy97w=; b=g/1dnKjqJKVmgdagnb2PQhHYzK105I/wv0BoOJa+UXaH782/kh74JCkw MG0H+N56Zv8Og4VUSJUr5X42cvl8ZgaMmwHTK8AFkciDvSwa8Fi5otHPY o4dqUGxWuV63Z0GOuZllNabVVt8UgBjqFOIo0UDsVI36k0bF/aheoBYSv sx9lQF7QDepxbCEjNGBZ/sUKJgq/kwt3y3oPDB0/VZL1/jlXSQyBBXJfG 0bNLWmsQCIm9Tmu5otKzGA1UtCbIHNR4B/fEgSsjfbic5pKhK3NNgQ9/2 voI+rRg6uuLm/FCsRO9y31adyIb2vE/iAWAdxWqosse4U1Lk/JGAfzhDF w==; X-IronPort-AV: E=Sophos;i="5.36,229,1486378800"; d="scan'208";a="145879177" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Mar 2017 18:55:04 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 27 Mar 2017 18:55:04 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Mon, 27 Mar 2017 18:55:04 +1300 From: Peter Gutmann To: Mouse , "ietf-ssh@netbsd.org" Subject: Re: Fixing exchange of host keys in the SSH key exchange Thread-Topic: Fixing exchange of host keys in the SSH key exchange Thread-Index: AQHSo6JCh/pnJs1+UUq8ewlt+ue/5qGjlx6QgAEOD4CAAi+kRYAAOraAgAAkIICAAQIltw== Date: Mon, 27 Mar 2017 05:55:04 +0000 Message-ID: <1490594103881.5135@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan><1490340148872.12344@cs.auckland.ac.nz>,<201703251227.IAA20189@Stone.Rodents-Montreal.ORG> <1490518384910.80699@cs.auckland.ac.nz> ,<201703270330.XAA28787@Stone.Rodents-Montreal.ORG> In-Reply-To: <201703270330.XAA28787@Stone.Rodents-Montreal.ORG> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted 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 Mouse writes:=0A= =0A= >It _does_ give the tools to those competent to use them; I think that's ab= out=0A= >all any such protocol can really expect to do.=0A= =0A= It also warns about key changes so you can take action if necessary, which = is=0A= something that SSL doesn't. Bank of America web site now hosted in the=0A= Ukraine on a Windows 7 Home Premium box? Let's see, it has a $5.99 GoDaddy= =0A= certificate. Seems legit [0].=0A= =0A= (I've only ever encountered one SSL-using app that warns that the key/cert= =0A= you're getting now differs from the one you got last time. I'm sure there = are=0A= more out there, but none of the mainstream stuff does it).=0A= =0A= Peter.=0A= =0A= [O] I know, I like to bash PKI, but with farcical behaviour like this it's= =0A= hard not to.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 26 23:21:59 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6268A129410 for ; Sun, 26 Mar 2017 23:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 ZrRmrhlWp2Vu for ; Sun, 26 Mar 2017 23:21:58 -0700 (PDT) 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 04F501293FD for ; Sun, 26 Mar 2017 23:21:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id DBF84855B6; Mon, 27 Mar 2017 06:21:56 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id ECC45855A7 for ; Mon, 27 Mar 2017 06:21:54 +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 5i3WIvAWXguT for ; Mon, 27 Mar 2017 06:21:54 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 C111684CDA for ; Mon, 27 Mar 2017 06:21:53 +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=1490595713; x=1522131713; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/wD8cv68lUnss4/Wecc+Y+S3BfyDFi8VteZn5gYscWo=; b=goAVHCCMyIuOsepXBruI/roihvR5FV2RUyC0HGSYw3vThzV5AJv18RKF bHqaBZQ7yNA2x8Qsv/v9VerkLt2xr4bVvQBvjY3zJwhDDo38hiq/iDi3I lrDNhPVDNtB9Pn2XPyLQL+kEeQop+ABFtA901Kux+D1qQtXBojhgPXBVf LbD3I0vIxSzW0LQj2yqcXr5b9i/1slGEthTVW9mterZufpW9zzF5/Ygz8 Jv/EgrDjzwKRHP/idAOCmJpF2funxftVW+qXx0C2y8dmbEzY41Mo6rZuT tS+fTXXEgRtLBMcuFVLbB8YPVnzm5gJnXwyCUGUlcqRwhJcM14Lm8TQGM A==; X-IronPort-AV: E=Sophos;i="5.36,229,1486378800"; d="scan'208";a="145882866" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Mar 2017 19:21:52 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 27 Mar 2017 19:21:51 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Mon, 27 Mar 2017 19:21:51 +1300 From: Peter Gutmann To: "denis bider (Bitvise)" , Mouse , "ietf-ssh@NetBSD.org" Subject: Re: Fixing exchange of host keys in the SSH key exchange Thread-Topic: Fixing exchange of host keys in the SSH key exchange Thread-Index: AQHSo6JCh/pnJs1+UUq8ewlt+ue/5qGhf50AgAOKXICAAIpbgIABd8WAgAExZak= Date: Mon, 27 Mar 2017 06:21:51 +0000 Message-ID: <1490595711031.1686@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted 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 (Bitvise) writes:=0A= =0A= >For the most recent example, an older version of a popular library used to= =0A= >have the "maximum channel packet size" concept completely borked up. For a= =0A= >channel opened by the remote party, this library would overwrite its own= =0A= >maximum packet size with the remote one. This caused at least two differen= t=0A= >kinds of session-ending problems to arise.=0A= =0A= It seems like every implementer has stories like this, but no-one can reall= y=0A= mention them in public because you don't want to embarrass a particular=0A= vendor... would there be any interest in having a private list of email=0A= addresses of people to exchange information like this with? That way we co= uld=0A= compare notes on necessary fixes that otherwise would need to be rediscover= ed=0A= for each new implementation.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Mar 27 16:57:54 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C61296CC for ; Mon, 27 Mar 2017 16:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 Wa9XAQxj7tO9 for ; Mon, 27 Mar 2017 16:57:52 -0700 (PDT) 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 88CC71296CB for ; Mon, 27 Mar 2017 16:57:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id D16BC8559C; Mon, 27 Mar 2017 23:57: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 8142585598 for ; Mon, 27 Mar 2017 23:57:40 +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 vdYvuH7zf0wB for ; Mon, 27 Mar 2017 23:57:39 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 C248584CED for ; Mon, 27 Mar 2017 23:57:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490659058; x=1522195058; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NYwIAjI8Bqwxy5A6EJcGhNJyEhGVIZmrZQSofQCGLGA=; b=HkkllN4lXJAKJF6nyoJsVLJENMWsQge1o3p1ffBor5I1QQo1RZTqQ5EB 0qjSPASJkcalZMY1Y+avD1aBEE0PXcMt4gdn3r0KefCW4NmD11+MnqQOk 76Y9dtqUfwjqQin223FpX5f71XWafQtDo4yVJ0quB9GSa7UPbOQsymckw 0jqd/+VvJyLk0eMwo7xzNEBf5XJsh0Qez8VJhedbNkDBOeZeUIP+mAroJ 4fHsRX6ZkIxr0EiF+DTgZaitACh5A8iIMsG+CyXhRKUFNr4pXXnGvGwJm RydUaBL+QBxJTQ858ywNtfTrC01f7CtVH0+SQz0pE16A3JW018DA66XlM g==; X-IronPort-AV: E=Sophos;i="5.36,234,1486378800"; d="scan'208";a="146053379" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Mar 2017 12:57:35 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 28 Mar 2017 12:57:34 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 28 Mar 2017 12:57:34 +1300 From: Peter Gutmann To: "denis bider (Bitvise)" , Mouse , "ietf-ssh@NetBSD.org" Subject: Re: Fixing exchange of host keys in the SSH key exchange Thread-Topic: Fixing exchange of host keys in the SSH key exchange Thread-Index: AQHSo6JCh/pnJs1+UUq8ewlt+ue/5qGhf50AgAOKXICAAIpbgIABd8WAgAExZamAACCUAIABBjdN Date: Mon, 27 Mar 2017 23:57:34 +0000 Message-ID: <1490659054508.71711@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>, <1490595711031.1686@cs.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-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider (Bitvise) writes:=0A= =0A= >The obstacle seems to be getting people together. Those of us who=92ve bee= n=0A= >around for 15 years may be on this mailing list. I=92m not sure if this is= true=0A= >for authors of newer implementations, who might benefit from this informat= ion=0A= >most.=0A= =0A= We can't solve every possible problem with incompatibilities, but we can at= =0A= least get good coverage of a lot of them.=A0 I think there are quite a few= =0A= oddball SSH implementations whose developers have never been on this list a= nd=0A= who we can't get to, but it can at least help those on the list.=0A= =0A= Just thinking about this a bit more, we'd maybe need two things, a means of= =0A= discussing quirks of other implementations, and an (informal) registry of S= SH=0A= ID strings and who to contact if you find a problem with that ID, because= =0A= that's been another problem, "I've found a bug with X, who do I report it= =0A= to?".=A0 Going through standard tech-support channels often doesn't work be= cause=0A= you're not a customer and there's no obvious way to get past the front-end= =0A= people to talk to a developer.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Mar 27 18:16:12 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A525D1297E6 for ; Mon, 27 Mar 2017 18:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 N3xwJvo_Z-K1 for ; Mon, 27 Mar 2017 18:16:11 -0700 (PDT) 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 3B2311297D6 for ; Mon, 27 Mar 2017 18:16:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0D27F8559C; Tue, 28 Mar 2017 01:16: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 4921385598 for ; Tue, 28 Mar 2017 01:16: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 ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id A-fYWT3UtOhi for ; Tue, 28 Mar 2017 01:16:07 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 5BAED84CEE for ; Tue, 28 Mar 2017 01:16:07 +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=1490663767; x=1522199767; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kD/VqJSMKbsNhQtP5YUwbJN6XiKQ93qPE6xvwp8FwFk=; b=LFcMROzopQs6Giw08J26lP8C/L2QoeKqPHNYzfUa3whUOaJety4zd3k0 NUzOCBh54VysOuak3P2Hy/UFLHhEUFM+SnB1vQ+70OUOhoh5PCCm6iVky Cc102d0jWfvJf5VJ35RGi+3fwIATUI0+Q0d/2O8lokrL6kdUKRaPhKLiU MjXqCtFYEBjC0kISAZenRnyANYyk3FWusI+hkWTwLZnKqpjD/iSJKvZnY 6+4TouCj9+LwbvhEjmOQ6BGTMOQk+BO53rmRprdvugqFS5HSZGHn0nAE6 ihoN3JH1ThH03tVxvNyIBOh21i6ZiVE4buRzxb32PTACy2nOejtA+Py1D A==; X-IronPort-AV: E=Sophos;i="5.36,234,1486378800"; d="scan'208";a="146072710" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from uxcn13-tdc-b.uoa.auckland.ac.nz ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Mar 2017 14:16:05 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 28 Mar 2017 14:16:05 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 28 Mar 2017 14:16:05 +1300 From: Peter Gutmann To: "denis bider (Bitvise)" , Mouse , "ietf-ssh@NetBSD.org" , Max Horn Subject: Re: Fixing exchange of host keys in the SSH key exchange Thread-Topic: Fixing exchange of host keys in the SSH key exchange Thread-Index: AQHSo6JCh/pnJs1+UUq8ewlt+ue/5qGhf50AgAOKXICAAIpbgIABd8WAgAExZamAACCUAIABBjdN//8tRwCAAOjHGg== Date: Tue, 28 Mar 2017 01:16:04 +0000 Message-ID: <1490663764701.80050@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>, <1490595711031.1686@cs.auckland.ac.nz>, <1490659054508.71711@cs.auckland.ac.nz>,<4F251D0448CB4B2EB006DE86972EBB81@Khan> In-Reply-To: <4F251D0448CB4B2EB006DE86972EBB81@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider (Bitvise) writes:=0A= =0A= >This is currently the most comprehensive list of SSH implementations I=92m= =0A= >familiar with:=0A= > =0A= >http://ssh-comparison.quendi.de/=0A= > =0A= >It=92s done by Max Horn, who participated on this list as recently as in= =0A= >September, so he might be reading.=0A= =0A= Wow, that's really impressive, because it'd involve either reading source c= ode=0A= or downloading and installing each one to scan it and see what it does.=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Mar 27 22:37:06 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F39128AB0 for ; Mon, 27 Mar 2017 22:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8m9PfSPsPFUa for ; Mon, 27 Mar 2017 22:37:05 -0700 (PDT) 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 3DD7C126C89 for ; Mon, 27 Mar 2017 22:37:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 199678556B; Tue, 28 Mar 2017 05:37:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C99AB84CEE; Tue, 28 Mar 2017 05:37:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 47EB985576 for ; Mon, 27 Mar 2017 11:58:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id LI8XXCQtS1dW for ; Mon, 27 Mar 2017 11:58:46 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 7B5D084CDE for ; Mon, 27 Mar 2017 11:58:46 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id HAA12060; Mon, 27 Mar 2017 07:58:45 -0400 (EDT) Date: Mon, 27 Mar 2017 07:58:45 -0400 (EDT) From: Mouse Message-Id: <201703271158.HAA12060@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Mon, 27 Mar 2017 07:24:09 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Fixing exchange of host keys in the SSH key exchange In-Reply-To: <1490594103881.5135@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan><1490340148872.12344@cs.auckland.ac.nz>,<201703251227.IAA20189@Stone.Rodents-Montreal.ORG> <1490518384910.80699@cs.auckland.ac.nz> ,<201703270330.XAA28787@Stone.Rodents-Montreal.ORG> <1490594103881.5135@cs.auckland.ac.nz> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> [SSH] _does_ give the tools to those competent to use them; I think >> that's about all any such protocol can really expect to do. > It also warns about key changes so you can take action if necessary, > which is something that SSL doesn't. Most implementations of SSH do; most implementations of SSL don't. Neither protocol requires or forbids it (a protocol is not really in a position to either compel or prohibit such a thing - fuzzy memory says the SSH RFCs have some SHOULDs on the matter, though). > (I've only ever encountered one SSL-using app that warns that the > key/cert you're getting now differs from the one you got last time. > I'm sure there are more out there, but none of the mainstream stuff > does it). Of course not. That might confuse users! > [O] I know, I like to bash PKI, but with farcical behaviour like this > it's hard not to. It's part of why I don't like SSL: it isn't really providing the security it pretends to be providing. The human-layer mechanisms don't help; far too many people - users and service providers both - think of security as a boolean: "It's Secure!". Never mind that the correct reaction to that is "...secure against what?". /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Mar 27 22:37:44 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C08126C89 for ; Mon, 27 Mar 2017 22:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com 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 3cEN-fya0UGt for ; Mon, 27 Mar 2017 22:37:41 -0700 (PDT) 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 E8895128AB0 for ; Mon, 27 Mar 2017 22:37:40 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 1510F855BA; Tue, 28 Mar 2017 05:37:38 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B697F855A1; Tue, 28 Mar 2017 05:37:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D77B28556B for ; Mon, 27 Mar 2017 21:03: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=denisbider.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id l9hxMfml8Me6 for ; Mon, 27 Mar 2017 21:03:18 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 4350684CED for ; Mon, 27 Mar 2017 21:03:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=mGIoia6S13EX5d6taEGDzTeypLiOUdq5W6yy/PxAWP8=; b=l41+nuvVtC3714cYXNvZIbC9Pnbg9VdzQ+I9IGfqhKOwOEwI4jzViROcnoJNGgBRYV5HyalRyu5MS OJxLYhNtC/Nc0lEgtJ5SvAhphIII8HPSJO7z+MlAxz6c80QIUAmaVcpodr+jbeRqOPOBAEn22vsaS4 MY2nRuaZ9hSWeSXmfmuScw10kMOVqd1QLj90Mdyg+/4ZM3LP4Q815ydgGRRX9p82mmbSipbD1KnBme FoZBrfHn4PmBKYkgXdJRXX7zgMKKdmuN4jq8fuC70G8gqV3/LU7X2mRM6eLGH8T8Rhln8krOhCrjo1 8XdUi2jWd+oJ1y+AQxbrnXqpBcazTKQ== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 27 Mar 2017 22:03:04 +0100 Message-ID: <21FC219108254FE6957257AE39C86BEE@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , "Mouse" , References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>,<201703270327.XAA25497@Stone.Rodents-Montreal.ORG> <1490593648496.70339@cs.auckland.ac.nz> In-Reply-To: <1490593648496.70339@cs.auckland.ac.nz> Subject: Re: Fixing exchange of host keys in the SSH key exchange Date: Mon, 27 Mar 2017 15:03:05 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0255_01D2A70B.3D03BE20" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0255_01D2A70B.3D03BE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This medium lacks appropriate smileys to react to this text. :D From: Peter Gutmann=20 Sent: Sunday, March 26, 2017 23:47 To: Mouse ; ietf-ssh@netbsd.org=20 Subject: Re: Fixing exchange of host keys in the SSH key exchange Mouse writes: >(They were the SSH listeners on devices such as switches.) It seems to be an unwritten law that big-iron networking hardware has to = run 15-to-20-year-old unpatched copies of some version of SSH that the switch/router vendor found in a dumpster somewhere. I've seen = late-1990s ssh.com implementations as recently as a few years ago, which is why I = have to keep active old SSH bug-workarounds that should have been retired a = decade or more ago. Being able to remotely crash a carrier-grade router [0] by = sending it an SSH option it didn't expect is a bit disturbing... this is why my = code grew a dump-full-packet-trace-to-debug-console option at some point in = the past. Peter. [0] I guess the SSH part is excluded from the carrier-grade = categorisation. ------=_NextPart_000_0255_01D2A70B.3D03BE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This medium lacks appropriate smileys to react to this text. = :D
 
 
Sent: Sunday, March 26, 2017 23:47
To: Mouse ; ietf-ssh@netbsd.org
Subject: Re: Fixing exchange of host keys in the SSH key=20 exchange
 
Mouse=20 <mouse@Rodents-Montreal.ORG> writes:

>(They were the SSH = listeners on devices such as switches.)

It seems to be an = unwritten law=20 that big-iron networking hardware has to run
15-to-20-year-old = unpatched=20 copies of some version of SSH that the
switch/router vendor found in = a=20 dumpster somewhere.  I've seen late-1990s
ssh.com = implementations as=20 recently as a few years ago, which is why I have to
keep active old = SSH=20 bug-workarounds that should have been retired a decade or
more = ago. =20 Being able to remotely crash a carrier-grade router [0] by sending
it = an SSH=20 option it didn't expect is a bit disturbing... this is why my = code
grew a=20 dump-full-packet-trace-to-debug-console option at some point in=20 the
past.

Peter.

[0] I guess the SSH part is excluded = from the=20 carrier-grade categorisation.
------=_NextPart_000_0255_01D2A70B.3D03BE20-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Mar 27 22:38:01 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BAB1293E1 for ; Mon, 27 Mar 2017 22:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com 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 fT5MH073jyeF for ; Mon, 27 Mar 2017 22:37:58 -0700 (PDT) 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 3366B128D44 for ; Mon, 27 Mar 2017 22:37:54 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5C4DD855DA; Tue, 28 Mar 2017 05:37:43 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 07FE48561F; Tue, 28 Mar 2017 05:37:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D16348556B for ; Mon, 27 Mar 2017 21:18: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=denisbider.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id EhT0UnPRFwLK for ; Mon, 27 Mar 2017 21:18:08 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 358BA84CED for ; Mon, 27 Mar 2017 21:18:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=6Lyj/Vnt2hn+rhMWDNERNQ9h5jq1tU2kqpB99QxJMi0=; b=l4rOnAI1k5/Z1ZDwqnNx2qAj0216Ahz1/MF4cViRZDzhe6ASSd2Jx4KH37IrssPe2CUwxetwUea7B EOic7Wz6erxBmbGl3n88lEfOfVoeFfgZZirnIfcAbdjb/quH8k9msJMyb3imvpYxGyp75qMEEin93V OHdQ4ozLO9HAJ52v8ljDc54KFlT/KJI07SCx3BfX/BufOupviro2F12LOvkH6g7j0l5wSYgNhoNYHm 32dYDIfsayDL2OnrIxfWgaWSYVATCHjo8931X28d+cTGx2VWvhdDaw4Wzjkh9ndat4YUU0BI3fSS4O /6rqKHobAZyyxhKRUOGPerbc1G575xg== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 27 Mar 2017 22:17:55 +0100 Message-ID: From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , "Mouse" , References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>, <1490595711031.1686@cs.auckland.ac.nz> In-Reply-To: <1490595711031.1686@cs.auckland.ac.nz> Subject: Re: Fixing exchange of host keys in the SSH key exchange Date: Mon, 27 Mar 2017 15:18:10 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0293_01D2A70D.584954E0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0293_01D2A70D.584954E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That sounds like a good idea. I would be interested to follow and = participate. The obstacle seems to be getting people together. Those of us = who=E2=80=99ve been around for 15 years may be on this mailing list. = I=E2=80=99m not sure if this is true for authors of newer = implementations, who might benefit from this information most. From: Peter Gutmann=20 Sent: Monday, March 27, 2017 00:21 To: denis bider (Bitvise) ; Mouse ; ietf-ssh@NetBSD.org=20 Subject: Re: Fixing exchange of host keys in the SSH key exchange denis bider (Bitvise) writes: >For the most recent example, an older version of a popular library used = to >have the "maximum channel packet size" concept completely borked up. = For a >channel opened by the remote party, this library would overwrite its = own >maximum packet size with the remote one. This caused at least two = different >kinds of session-ending problems to arise. It seems like every implementer has stories like this, but no-one can = really mention them in public because you don't want to embarrass a particular vendor... would there be any interest in having a private list of email addresses of people to exchange information like this with? That way we = could compare notes on necessary fixes that otherwise would need to be = rediscovered for each new implementation. Peter. ------=_NextPart_000_0293_01D2A70D.584954E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That sounds like a good idea. I would be interested to follow and=20 participate.
 
The obstacle seems to be getting people together. Those of us = who=E2=80=99ve been=20 around for 15 years may be on this mailing list. I=E2=80=99m not sure if = this is true=20 for authors of newer implementations, who might benefit from this = information=20 most.
 
 
Sent: Monday, March 27, 2017 00:21
To: denis bider (Bitvise) ; Mouse ; ietf-ssh@NetBSD.org
Subject: Re: Fixing exchange of host keys in the SSH key=20 exchange
 
denis=20 bider (Bitvise) <ietf-ssh3@denisbider.com> writes:

>For = the most=20 recent example, an older version of a popular library used = to
>have the=20 "maximum channel packet size" concept completely borked up. For = a
>channel=20 opened by the remote party, this library would overwrite its = own
>maximum=20 packet size with the remote one. This caused at least two = different
>kinds=20 of session-ending problems to arise.

It seems like every = implementer has=20 stories like this, but no-one can really
mention them in public = because you=20 don't want to embarrass a particular
vendor... would there be any = interest in=20 having a private list of email
addresses of people to exchange = information=20 like this with?  That way we could
compare notes on necessary = fixes that=20 otherwise would need to be rediscovered
for each new=20 implementation.

Peter.
------=_NextPart_000_0293_01D2A70D.584954E0-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Mar 27 22:38:04 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02D5126C89 for ; Mon, 27 Mar 2017 22:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ojb7jkXuxYwc for ; Mon, 27 Mar 2017 22:38:03 -0700 (PDT) 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 54804128AB0 for ; Mon, 27 Mar 2017 22:37:59 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 7A962855B8; Tue, 28 Mar 2017 05:37:48 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 345FF855B0; Tue, 28 Mar 2017 05:37:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B92CA85585 for ; Mon, 27 Mar 2017 22:05:01 +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 BxeyG8nFShL1 for ; Mon, 27 Mar 2017 22:05:01 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id B5D0684CDA for ; Mon, 27 Mar 2017 22:05:00 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id SAA12391; Mon, 27 Mar 2017 18:04:59 -0400 (EDT) Date: Mon, 27 Mar 2017 18:04:59 -0400 (EDT) From: Mouse Message-Id: <201703272204.SAA12391@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Mon, 27 Mar 2017 17:49:56 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Implementation-hazards list [was Re: Fixing exchange of host keys in the SSH key exchange] In-Reply-To: References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>, <1490595711031.1686@cs.auckland.ac.nz> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >>> For the most recent example, an older version of a popular library >>> used to have the "maximum channel packet size" concept completely >>> borked up. For a channel opened by the remote party, this library >>> would overwrite its own maximum packet size with the remote one. >> It seems like every implementer has stories like this, but no-one >> can really mention them in public because you don't want to >> embarrass a particular vendor... Well, in many cases. I, for example, am not at all chary about naming OpenSSH as the implementation whose misfeature prompted me to add -share-number to moussh (even the moussh manpage does so), and I'd name the vendor of the devices whose implementation crashed when given string@domianname extensions if I remembered it (and were sure I rememebred it right). But I can certainly understand at least a few of the reasons not everyone is as willing as I am to do that. However... >> would there be any interest in having a private list of email >> addresses of people to exchange information like this with? ...I don't see any need to name-and-shame on such a list. It's the misbehaviour, not whose implementation exhbits it, that matters for implementation purposes. There might perhaps be value in an implementation with options to make it exhibit various kinds of misbehaviour, for testing against. (I'm tempted to turn moussh into such a one, but now is not a good time for me to be taking on more timesinks.) > That sounds like a good idea. I would be interested to follow and > participate. Me too. > The obstacle seems to be getting people together. Those of us > who??ve been around for 15 years may be on this mailing list. I??m > not sure if this is true for authors of newer implementations, who > might benefit from this information most. I'm not sure either. Perhaps if the list were archived and the archives were up somewhere on the Web, the new crowd who expects everything to be Web this and Web that might be able to find it? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Mar 27 22:38:14 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C37B128D44 for ; Mon, 27 Mar 2017 22:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7L_geIBIi_jD for ; Mon, 27 Mar 2017 22:38:09 -0700 (PDT) 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 70A29126C89 for ; Mon, 27 Mar 2017 22:38:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id E16DA8559C; Tue, 28 Mar 2017 05:37:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 94B6F85585; Tue, 28 Mar 2017 05:37:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AC94F85590 for ; Tue, 28 Mar 2017 01:30:31 +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 NdtJDiBOKaer for ; Tue, 28 Mar 2017 01:30:31 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id D929F84CEE for ; Tue, 28 Mar 2017 01:30:30 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id VAA11469; Mon, 27 Mar 2017 21:30:30 -0400 (EDT) Date: Mon, 27 Mar 2017 21:30:30 -0400 (EDT) From: Mouse Message-Id: <201703280130.VAA11469@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Mon, 27 Mar 2017 21:17:38 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Fixing exchange of host keys in the SSH key exchange In-Reply-To: <1490659054508.71711@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>, <1490595711031.1686@cs.auckland.ac.nz>, <1490659054508.71711@cs.auckland.ac.nz> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > Just thinking about this a bit more, we'd maybe need two things, a > means of discussing quirks of other implementations, and an > (informal) registry of SSH ID strings and who to contact if you find > a problem with that ID, because that's been another problem, "I've > found a bug with X, who do I report it to?". Going through standard > tech-support channels often doesn't work because you're not a > customer and there's no obvious way to get past the front-end people > to talk to a developer. (Well, to be fair, _should_ they be interested in talking to a non-customer? Thirty years ago, most admins would have cared about the problem for its own sake. That, much as it pains me, is not today's net.) Yes, I would support - and participate in, provided it isn't done in a way that ends up excluding me - such an effort. There are a bunch of other things that could be recorded about the various implementations, such as what they support (not just crypto, as in the quendi.de list, but other things as well). It also might be interesting to do interop testing. I know *I* would be interested in interop tests - in both directions - with the various other implementations. There are a few things I know I don't support and a bunch I'm fairly sure I do; I'd like to verify the support I think I have in place, make sure I fail gracefully on the things I know I don't do, and find out the status of anything in neither category. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Mar 27 22:49:22 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F444129630 for ; Mon, 27 Mar 2017 22:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com 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 P21uvDhT0xy0 for ; Mon, 27 Mar 2017 22:49:20 -0700 (PDT) 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 76A911294CE for ; Mon, 27 Mar 2017 22:49:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id BBEC7855BD; Tue, 28 Mar 2017 05:37:53 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 671A7855B0; Tue, 28 Mar 2017 05:37:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 632FB85598 for ; Tue, 28 Mar 2017 00:22:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 oi3NsrcPEJMe for ; Tue, 28 Mar 2017 00:22:47 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9F09A84CED for ; Tue, 28 Mar 2017 00:22:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=F3QYvWDvrAF79nLllVwzsFHeSSKfu+gQeGr0mnqAnR0=; b=YUjjdYu4P7mO21V+DsMh0A3HbPUnduES5jjeevLMQWtenasfAz7uX92EJbZAb0bIUK7I58hZXx9wQ 37nQ3Z5aiojUK4IHHFUWF4cboxDfv2TKtD4ahy0j3Ou8vuXKzCeARGLSbWl3cgbJgnggsl78OZTYs3 OhNax+Yg08ZbQj2dNBVZwADWeqpGv1kLj4y9LByAsFUqbybzZ0ksScm0caB+9AMu5MAlJ/tvDeUV5x w7fud3QYQ/SPsXZUK99hMk5VX7FzEGb3rDXOWwmtMe1Yw4N1DjhnmK9CR9sUXBvFR5KS7xxziShdK4 e/cJY9UIcu5f1GMEid337guudT4cZrw== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 28 Mar 2017 01:22:39 +0100 Message-ID: <4F251D0448CB4B2EB006DE86972EBB81@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , "Mouse" , , "Max Horn" References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>, <1490595711031.1686@cs.auckland.ac.nz>, <1490659054508.71711@cs.auckland.ac.nz> In-Reply-To: <1490659054508.71711@cs.auckland.ac.nz> Subject: Re: Fixing exchange of host keys in the SSH key exchange Date: Mon, 27 Mar 2017 18:22:28 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E4_01D2A727.175F2440" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_00E4_01D2A727.175F2440 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is currently the most comprehensive list of SSH implementations = I=92m familiar with: http://ssh-comparison.quendi.de/ It=92s done by Max Horn, who participated on this list as recently as in = September, so he might be reading. Come to think of it =96 Max=92s SSH comparison might be an excellent way = to figure out how many servers will reject text from the client before = the SSH version string. I understand that this might be quite a bit of = work. However, Bitvise would be willing to sponsor such an effort.=20 Max? Are you there? :-) From: Peter Gutmann=20 Sent: Monday, March 27, 2017 17:57 To: denis bider (Bitvise) ; Mouse ; ietf-ssh@NetBSD.org=20 Subject: Re: Fixing exchange of host keys in the SSH key exchange denis bider (Bitvise) writes: >The obstacle seems to be getting people together. Those of us who=92ve = been >around for 15 years may be on this mailing list. I=92m not sure if this = is true >for authors of newer implementations, who might benefit from this = information >most. We can't solve every possible problem with incompatibilities, but we can = at least get good coverage of a lot of them. I think there are quite a few oddball SSH implementations whose developers have never been on this = list and who we can't get to, but it can at least help those on the list. Just thinking about this a bit more, we'd maybe need two things, a means = of discussing quirks of other implementations, and an (informal) registry = of SSH ID strings and who to contact if you find a problem with that ID, = because that's been another problem, "I've found a bug with X, who do I report = it to?". Going through standard tech-support channels often doesn't work = because you're not a customer and there's no obvious way to get past the = front-end people to talk to a developer. Peter. ------=_NextPart_000_00E4_01D2A727.175F2440 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
This is currently the most comprehensive list of SSH = implementations I=92m=20 familiar with:
 
 
It=92s done by Max Horn, who participated on this list as recently = as in=20 September, so he might be reading.
 
Come to think of it =96 Max=92s SSH comparison might be an = excellent way to=20 figure out how many servers will reject text from the client before the = SSH=20 version string. I understand that this might be quite a bit of work. = However,=20 Bitvise would be willing to sponsor such an effort.
 
Max? Are you there? :-)
 
 
Sent: Monday, March 27, 2017 17:57
To: denis bider (Bitvise) ; Mouse ; ietf-ssh@NetBSD.org
Subject: Re: Fixing exchange of host keys in the SSH key=20 exchange
 
denis=20 bider (Bitvise) <ietf-ssh3@denisbider.com> writes:

>The = obstacle=20 seems to be getting people together. Those of us who=92ve = been
>around for=20 15 years may be on this mailing list. I=92m not sure if this is = true
>for=20 authors of newer implementations, who might benefit from this=20 information
>most.

We can't solve every possible problem = with=20 incompatibilities, but we can at
least get good coverage of a lot of=20 them.  I think there are quite a few
oddball SSH implementations = whose=20 developers have never been on this list and
who we can't get to, but = it can=20 at least help those on the list.

Just thinking about this a bit = more,=20 we'd maybe need two things, a means of
discussing quirks of other=20 implementations, and an (informal) registry of SSH
ID strings and who = to=20 contact if you find a problem with that ID, because
that's been = another=20 problem, "I've found a bug with X, who do I report it
to?".  = Going=20 through standard tech-support channels often doesn't work = because
you're not=20 a customer and there's no obvious way to get past the = front-end
people to=20 talk to a developer.

Peter.
------=_NextPart_000_00E4_01D2A727.175F2440-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 29 20:38:28 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25312955F for ; Wed, 29 Mar 2017 20:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 m4UUywHaeKZk for ; Wed, 29 Mar 2017 20:38:26 -0700 (PDT) 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 21DC0129528 for ; Wed, 29 Mar 2017 20:38:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 77CF7855B9; Thu, 30 Mar 2017 03:38: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 69899855B0 for ; Thu, 30 Mar 2017 03:38:22 +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 LlZiJm-epiuT for ; Thu, 30 Mar 2017 03:38:21 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 06F8684CDB for ; Thu, 30 Mar 2017 03:38: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=1490845100; x=1522381100; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hBcOLh7Fl7tvwESx5PtfEA773lRZdC8wIdAGTL3PawQ=; b=yWMdk7hbh+U8cIR2oXmVDzEATsPtjLqWzWkA6ok4X13Tptx5wgXSFRKs +Hm5umCU3mQDSaG5t1cW6S638gBwMAn70t/KtDg1SxDn60F9DbwKKi8e5 YA+oed6j0sQmcVgyqIuim4js4izu/bzCWva89V3Cuei87vMYslSI9QiqL I2nIrjyDCuQDQfgBAjbH5vuH8/6GL9yunM2Lel80TUFmLCXQ+WufOUgzM QcFLzmXZJPzte9Y1y4QQWTy7Ej+8g9QhdjK46eCoLPWmEIj5iFFkAvCRm pgKdJGTMmG18LJgLjiywxV9Bwg9ua2QJYixjySG30oFeWNfEax8HA7WFJ g==; X-IronPort-AV: E=Sophos;i="5.36,244,1486378800"; d="scan'208";a="146583199" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Mar 2017 16:38:15 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 30 Mar 2017 16:38:15 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Thu, 30 Mar 2017 16:38:15 +1300 From: Peter Gutmann To: Mouse , "ietf-ssh@netbsd.org" Subject: Re: Implementation-hazards list [was Re: Fixing exchange of host keys in the SSH key exchange] Thread-Topic: Implementation-hazards list [was Re: Fixing exchange of host keys in the SSH key exchange] Thread-Index: AQHSp4V2GJRs3v7ZZUiGtMS6SlJtjqGsvvT1 Date: Thu, 30 Mar 2017 03:38:14 +0000 Message-ID: <1490845094618.54847@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>, <1490595711031.1686@cs.auckland.ac.nz> ,<201703272204.SAA12391@Stone.Rodents-Montreal.ORG> In-Reply-To: <201703272204.SAA12391@Stone.Rodents-Montreal.ORG> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted 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 Mouse writes:=0A= =0A= >...I don't see any need to name-and-shame on such a list. It's the=0A= >misbehaviour, not whose implementation exhbits it, that matters for=0A= >implementation purposes.=0A= =0A= It's not so much concerns about name-and-shame, it's that it's=0A= impossible not to name vendors when you need to know whose SSH ID=0A= to check for to add a workaround. So it's pretty much something that =0A= can't be discussed in public for most people.=0A= =0A= >Yes, I would support - and participate in, provided it isn't done in =0A= >a way that ends up excluding me - such an effort. =0A= =0A= I wasn't necessarily thinking a full email list, that's way too=0A= organised, just a list of CC: addresses of people who'd be willing to=0A= share info. So far we've got you, me, and Denis AFAIK.=0A= =0A= >It also might be interesting to do interop testing. =0A= =0A= Or just some agreement to run an instance of your implementation at=0A= some fixed location so people could bounce messages off it.=0A= =0A= Peter.=0A= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 29 23:02:34 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4765F127058 for ; Wed, 29 Mar 2017 23:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=dtucker-net.20150623.gappssmtp.com 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 Bgf_9ZECakTf for ; Wed, 29 Mar 2017 23:02:31 -0700 (PDT) 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 C7C8D1204DA for ; Wed, 29 Mar 2017 23:02:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 72582855BD; Thu, 30 Mar 2017 06:02:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 1740E855BB; Thu, 30 Mar 2017 06:02:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 220B58556B for ; Tue, 28 Mar 2017 05:57: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=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 PCInyv40XZAV for ; Tue, 28 Mar 2017 05:57:01 +0000 (UTC) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 5AABD84CE5 for ; Tue, 28 Mar 2017 05:57:01 +0000 (UTC) Received: by mail-qt0-x22c.google.com with SMTP id n21so55848871qta.1 for ; Mon, 27 Mar 2017 22:57:01 -0700 (PDT) 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; bh=j1XID5reF3EjgOwep2U+uzeIamQ53D0az99gGEroSvE=; b=FW1FvuTd5kaRoRBNMAZr8lZbLywo+4hmzhkwbYC2tl2obIMJ5F2EWpMo1j9hereNwI IOCPbm6BQasF1rmW5hxrXd/wfWQV4EHaFRLvqLWTntJjpnxt02dF+odLTiVuLgguNsxQ yu2bphS0soO6R50Di3T5ShV29bcPf4tHieYNIGYNySM5ktUnn8S9lbLCyfdvXvBW5RqN cM/ivsDNfAS9OzSwQh5NT8Bir8KsO6Q1k/HX3Zd3wuKm7ySyVmUfehiTUNosFGbhThfN RYqJueL0qh8ufBWoRdm7zE4wShmXwBOd8Oznuxzoh86Kp52WmW/xS8o6vUzpHA4Z+Kmd uE9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=j1XID5reF3EjgOwep2U+uzeIamQ53D0az99gGEroSvE=; b=RYCgMH5eg9za89VmW8ZSCd4mudBeookk/X3JZLRGyo64EmKGrFzmMeXsHyCrj2k25x Cu7OqBGcQWoGVVUf7jF9MXHIClAnnhCx0OdML1j2nWPlGIdamo58LVG/DtGBRo9EF5d9 xSlms8tpKYJkIN4HyW/P5FvqyoI6sJOiH4TRd6jfAqvEvfFTBNfvMXz6GhP8ZVyvXX28 ORCgUwik9W6mgNPcFS5ttTggEsWZ4/eXxVQNNQI70/jfeX94yB9EcBo1sAu6RF81jXgi mJQJZY6NUaQCm2maydFbJb8Qt7dBgpO3dSrUB7x6BZjLeUopAMDj3RWcWbkjFZ676GnZ KNJw== X-Gm-Message-State: AFeK/H3WsJABL8A2nq0i1AS1SOD+KdWtNst73a91+fx72NB4TH1Ktgc0L3ElHfjChfzufSjbjx6lv0HYYIuFkg== X-Received: by 10.200.52.65 with SMTP id v1mr26888460qtb.166.1490680620170; Mon, 27 Mar 2017 22:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.111.130 with HTTP; Mon, 27 Mar 2017 22:56:39 -0700 (PDT) In-Reply-To: <201703272204.SAA12391@Stone.Rodents-Montreal.ORG> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG> <589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG> <1490595711031.1686@cs.auckland.ac.nz> <201703272204.SAA12391@Stone.Rodents-Montreal.ORG> From: Darren Tucker Date: Tue, 28 Mar 2017 16:56:39 +1100 X-Google-Sender-Auth: gDCdbjCLNzekaZrWNh2ZP4TMuFk Message-ID: Subject: Re: Implementation-hazards list [was Re: Fixing exchange of host keys in the SSH key exchange] To: Mouse Cc: "ietf-ssh@NetBSD.org" Content-Type: multipart/alternative; boundary=001a1141a6aed70bb2054bc420dd Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --001a1141a6aed70bb2054bc420dd Content-Type: text/plain; charset=UTF-8 On Tue, Mar 28, 2017 at 9:04 AM, Mouse wrote: > [...] > Well, in many cases. I, for example, am not at all chary about naming > OpenSSH as the implementation whose misfeature prompted me to add > -share-number to moussh (even the moussh manpage does so) I was curious about what that was so I looked. Quoting moussh(1): There is a misfeature (I would call it a bug, except that reading the source makes it clear it was done deliberately) in OpenSSH's server. (Similar issues may exist with others, but I have no knowledge of them.) It gratuitously refuses to permit more than ten sessions per connection. This means that using moussh's connection-sharing feature to connect to such a server will work fine until you try to open too many remote login sessions, at which point you will get refusals from the remote server. Worst of all, OpenSSH does not provide any way for the server admin to raise this limit; it is hardwired into the code! That last sentence is not accurate, OpenSSH has provided a MaxSessions config option since the 5.1 (2008): https://www.openssh.com/releasenotes.html#5.1 -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. --001a1141a6aed70bb2054bc420dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 28, 2017 at 9:04 AM, Mouse <mouse@rodents-montreal.org> wrote:
[.= ..]
Well, in many cases.=C2=A0 I, for example, am not at all chary about naming=
OpenSSH as the implementation whose misfeature prompted me to add
-share-number to moussh (even the moussh manpage does so)
=
I was curious about what that was so I looked.=C2=A0 Quoting= moussh(1):

=C2=A0 =C2=A0 =C2=A0There is a mi= sfeature (I would call it a bug, except that reading the
=C2=A0 = =C2=A0 =C2=A0source makes it clear it was done deliberately) in OpenSSH'= ;s server.
=C2=A0 =C2=A0 =C2=A0(Similar issues may exist with oth= ers, but I have no knowledge of them.)
=C2=A0 =C2=A0 =C2=A0It gra= tuitously refuses to permit more than ten sessions per connection.
=C2=A0 =C2=A0 =C2=A0This means that using moussh's connection-sharing= feature to connect to
=C2=A0 =C2=A0 =C2=A0such a server will wor= k fine until you try to open too many remote login
=C2=A0 =C2=A0 = =C2=A0sessions, at which point you will get refusals from the remote server= .
=C2=A0 =C2=A0 =C2=A0Worst of all, OpenSSH does not provide any = way for the server admin to
=C2=A0 =C2=A0 =C2=A0raise this limit;= it is hardwired into the code!


--
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6F= A / A86E 3E07 5B19 5880 E860 =C2=A037F4 9357 ECEF 11EA A6FA (new)
=C2=A0= =C2=A0 Good judgement comes with experience. Unfortunately, the experience=
usually comes from bad judgement.
--001a1141a6aed70bb2054bc420dd-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Mar 30 23:56:15 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEEE1275C5 for ; Thu, 30 Mar 2017 23:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 5E4I-MIkNxwM for ; Thu, 30 Mar 2017 23:56:13 -0700 (PDT) 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 C519312871F for ; Thu, 30 Mar 2017 23:56:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 69E1A85587; Fri, 31 Mar 2017 06:56:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 2556385570; Fri, 31 Mar 2017 06:56:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CE7CB84CDE for ; Thu, 30 Mar 2017 11:36:30 +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 I3GBf72EaraS for ; Thu, 30 Mar 2017 11:36:30 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id F0B7E84CDD for ; Thu, 30 Mar 2017 11:36:29 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id HAA28900; Thu, 30 Mar 2017 07:36:29 -0400 (EDT) Date: Thu, 30 Mar 2017 07:36:29 -0400 (EDT) From: Mouse Message-Id: <201703301136.HAA28900@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 30 Mar 2017 07:27:57 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Implementation-hazards list [was Re: Fixing exchange of host keys in the SSH key exchange] In-Reply-To: <1490845094618.54847@cs.auckland.ac.nz> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>, <1490595711031.1686@cs.auckland.ac.nz> ,<201703272204.SAA12391@Stone.Rodents-Montreal.ORG> <1490845094618.54847@cs.auckland.ac.nz> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> ...I don't see any need to name-and-shame on such a list. It's the >> misbehaviour, not whose implementation exhbits it, that matters for >> implementation purposes. > It's not so much concerns about name-and-shame, it's that it's > impossible not to name vendors when you need to know whose SSH ID to > check for to add a workaround. Oh, hmm, true. I wasn't thinking it through enough. >> Yes, I would support - and participate in, provided it isn't done in >> a way that ends up excluding me - such an effort. > I wasn't necessarily thinking a full email list, that's way too > organised, :-) >> It also might be interesting to do interop testing. > Or just some agreement to run an instance of your implementation at > some fixed location so people could bounce messages off it. That's pretty much what I was thinking - interop testing can also be done informally. :-) There are a lot of details, but I would expect they can be worked out in most cases. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Mar 30 23:56:19 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001DD12704B for ; Thu, 30 Mar 2017 23:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com 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 rv-nHMJDquQ4 for ; Thu, 30 Mar 2017 23:56:16 -0700 (PDT) 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 50FA71205D3 for ; Thu, 30 Mar 2017 23:56:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 798C7855D1; Fri, 31 Mar 2017 06:56:15 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 2657D85570; Fri, 31 Mar 2017 06:56:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9951E84CDE for ; Thu, 30 Mar 2017 18:58:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 bfhb_OZKfzU8 for ; Thu, 30 Mar 2017 18:58:05 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id CD1CA84CDD for ; Thu, 30 Mar 2017 18:58:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=V0gh0uu2BzmJ1lVROkNAhvn3zTLO64GNCSkVBKKxuZM=; b=qQ9qN5/5eeBSdmfQeyPNQt/EZZWp167hgJMMDCNnbXZIqS6Rz8z1lAiT4O7k1Yd4/28E6ZoutW2ZN sJD4AwPQWUlvRTfajpur/cuKGS7cqCWhE9ETZc68VvcftdXFQjjsvmOID3jjRGaKV5SSPGRzURTfsd CiJjpEGEwEX9oWURqMHY4KbEEHRHh/TiMX7KO0JQZplnRr9DpwAsyuBBiRcLn4nzx3BD1HwvAxeuu6 vK7XBcwK1nmgNZWL3z44xNxJrpzqRuwdPypoA0bSBuyCo0WKqSo0gUFn4GWC4ll3lyPmpztyU3BRSe hKSWfHFLXFScSnmKAlYLvpDd8XjoEJw== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 30 Mar 2017 19:57:49 +0100 Message-ID: <1A92E96F87CA4B70A939D3E0F1A719B4@Khan> From: "denis bider \(Bitvise\)" To: "Darren Tucker" , "Mouse" Cc: "ietf-ssh@NetBSD.org" References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG> <589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG> <1490595711031.1686@cs.auckland.ac.nz> <201703272204.SAA12391@Stone.Rodents-Montreal.ORG> In-Reply-To: Subject: Re: Implementation-hazards list [was Re: Fixing exchange of host keys in the SSH key exchange] Date: Thu, 30 Mar 2017 12:57:59 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0117_01D2A955.424C80F0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0117_01D2A955.424C80F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Also, unfortunately, the OpenSSH =E2=80=9CMaxSessions=E2=80=9D setting = is often configured with the value 1. This is really awful for a graphical client such as Bitvise SSH Client, = which hopes to be able to open at least 2 channels in the same session = (one for SFTP, one for terminal). I=E2=80=99m not sure who sets that default to 1 =E2=80=93 maybe = it=E2=80=99s a distribution, or maybe some zealous administrator. = However, I would suggest a sensible minimum might be at least 2 for = servers that allow terminal shell and SFTP access. denis From: Darren Tucker=20 Sent: Monday, March 27, 2017 23:56 To: Mouse=20 Cc: ietf-ssh@NetBSD.org=20 Subject: Re: Implementation-hazards list [was Re: Fixing exchange of = host keys in the SSH key exchange] On Tue, Mar 28, 2017 at 9:04 AM, Mouse = wrote: [...] Well, in many cases. I, for example, am not at all chary about naming OpenSSH as the implementation whose misfeature prompted me to add -share-number to moussh (even the moussh manpage does so) I was curious about what that was so I looked. Quoting moussh(1): There is a misfeature (I would call it a bug, except that reading = the source makes it clear it was done deliberately) in OpenSSH's = server. (Similar issues may exist with others, but I have no knowledge of = them.) It gratuitously refuses to permit more than ten sessions per = connection. This means that using moussh's connection-sharing feature to = connect to such a server will work fine until you try to open too many remote = login sessions, at which point you will get refusals from the remote = server. Worst of all, OpenSSH does not provide any way for the server admin = to raise this limit; it is hardwired into the code! That last sentence is not accurate, OpenSSH has provided a MaxSessions = config option since the 5.1 (2008): = https://www.openssh.com/releasenotes.html#5.1 --=20 Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA = (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. ------=_NextPart_000_0117_01D2A955.424C80F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Also, unfortunately, the OpenSSH =E2=80=9CMaxSessions=E2=80=9D = setting is often configured=20 with the value 1.
 
This is really awful for a graphical client such as Bitvise SSH = Client,=20 which hopes to be able to open at least 2 channels in the same session = (one for=20 SFTP, one for terminal).
 
I=E2=80=99m not sure who sets that default to 1 =E2=80=93 maybe = it=E2=80=99s a distribution, or=20 maybe some zealous administrator. However, I would suggest a sensible = minimum=20 might be at least 2 for servers that allow terminal shell and SFTP = access.
 
denis
 
 
Sent: Monday, March 27, 2017 23:56
To: Mouse
Subject: Re: Implementation-hazards list [was Re: Fixing = exchange of=20 host keys in the SSH key exchange]
 
On Tue, Mar 28, 2017 at 9:04 AM, Mouse <mouse@rodents-montreal.org> wrote:
[...]
Well,=20 in many cases.  I, for example, am not at all chary about=20 naming
OpenSSH as the implementation whose misfeature prompted me = to=20 add
-share-number to moussh (even the moussh manpage does = so)
 
I was curious about what that was so I looked.  Quoting=20 moussh(1):
 
     There is a misfeature (I would call it a = bug,=20 except that reading the
     source makes it clear it was done = deliberately) in=20 OpenSSH's server.
     (Similar issues may exist with others, but = I have=20 no knowledge of them.)
     It gratuitously refuses to permit more = than ten=20 sessions per connection.
     This means that using moussh's = connection-sharing=20 feature to connect to
     such a server will work fine until you try = to open=20 too many remote login
     sessions, at which point you will get = refusals=20 from the remote server.
     Worst of all, OpenSSH does not provide any = way for=20 the server admin to
     raise this limit; it is hardwired into the = code!
 
That last sentence is not accurate, OpenSSH has provided a = MaxSessions=20 config option since the 5.1 (2008): https://www.openss= h.com/releasenotes.html#5.1
 
--
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 = 5880=20 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good = judgement=20 comes with experience. Unfortunately, the experience
usually comes = from bad=20 judgement.
------=_NextPart_000_0117_01D2A955.424C80F0-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Mar 30 23:56:27 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978DF12704B for ; Thu, 30 Mar 2017 23:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zqfS-oLg0Iud for ; Thu, 30 Mar 2017 23:56:26 -0700 (PDT) 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 B9F5C1205D3 for ; Thu, 30 Mar 2017 23:56:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 54528855E1; Fri, 31 Mar 2017 06:56:25 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0F34585570; Fri, 31 Mar 2017 06:56:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DDDB584CDE for ; Thu, 30 Mar 2017 19:54:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id tmgKAVBEmS-2 for ; Thu, 30 Mar 2017 19:54:54 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id BB7BE84CDD for ; Thu, 30 Mar 2017 19:54:53 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA29106; Thu, 30 Mar 2017 15:54:52 -0400 (EDT) Date: Thu, 30 Mar 2017 15:54:52 -0400 (EDT) From: Mouse Message-Id: <201703301954.PAA29106@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 30 Mar 2017 15:27:01 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: Implementation-hazards list [was Re: Fixing exchange of host keys in the SSH key exchange] In-Reply-To: <1A92E96F87CA4B70A939D3E0F1A719B4@Khan> References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG> <589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG> <1490595711031.1686@cs.auckland.ac.nz> <201703272204.SAA12391@Stone.Rodents-Montreal.ORG> <1A92E96F87CA4B70A939D3E0F1A719B4@Khan> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > I was curious about what that was so I looked. Quoting moussh(1): > [...] > Worst of all, OpenSSH does not provide any way for the server admin to > raise this limit; it is hardwired into the code! > That last sentence is not accurate, OpenSSH has provided a > MaxSessions config option since [] 5.1 (2008) [...] I've updated moussh.1: commit 58da35d27000668ec6c9125790c47cbfed430669 Author: Mouse Date: Tue Mar 28 08:21:05 2017 -0400 Update the manpage description of the OpenSSH connection-limit misfeature. diff --git a/moussh/moussh.1 b/moussh/moussh.1 index 2bfc901..e235526 100644 --- a/moussh/moussh.1 +++ b/moussh/moussh.1 @@ -747,7 +747,8 @@ to open .Ar N parallel connections to the server. The sharing clients are then load-shared among the server connections. This option is designed to -work around a misfeature in OpenSSH; see the +work around a misfeature in some OpenSSH versions, still useful with +current versions in some circumstances; see the .Sx CONNECTION SHARING section for more. .It Fl just-die @@ -1142,18 +1143,21 @@ option variables false.) There is a misfeature (I would call it a bug, except that reading the source makes it clear it was done deliberately) in OpenSSH's server. (Similar issues may exist with others, but I have no knowledge of -them.) It gratuitously refuses to permit more than ten sessions per -connection. This means that using +them.) It gratuitously refuses to permit more than some number of +sessions per connection. This number defaults to 10, and some versions +(before 5.1, I believe) have it hardwired to 10 in the code. (As far +as I know no version has a way to remove the limit entirely, though for +most purposes specifying a large number like 1000 is equivalent.) This +means that using .Nm moussh Ap s connection-sharing feature to connect to such a server will work fine until you try to open too many remote login sessions, at which point -you will get refusals from the remote server. Worst of all, OpenSSH -does not provide any way for the server admin to raise this limit; it -is hardwired into the code! +you will get refusals from the remote server. .Pp .Nm -contains a workaround for this: when establishing a connection-sharing -server, you can specify +contains a workaround for this, in case the server is a version old +enough to have it hardwired or its admin doesn't want to raise the +limit: when establishing a connection-sharing server, you can specify .Fl share-number (or the corresponding config-file variable) to make .Nm /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B