Re: Fixing exchange of host keys in the SSH key exchange

Mouse <mouse@Rodents-Montreal.ORG> Sat, 25 March 2017 09:39 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB85F127843 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; 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 <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; 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 <secsh-tyoxbijeg7-archive@lists.ietf.org>; 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 <ietf-ssh@NetBSD.org>; 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 <ietf-ssh@netbsd.org>; 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 <ietf-ssh@NetBSD.org>; 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
From: Mouse <mouse@Rodents-Montreal.ORG>
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