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

Mouse <mouse@Rodents-Montreal.ORG> Sun, 26 March 2017 07:06 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 CCFD9129431 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; 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 <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; 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 <secsh-tyoxbijeg7-archive@lists.ietf.org>; 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 <ietf-ssh@NetBSD.org>; 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 <ietf-ssh@netbsd.org>; 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 <ietf-ssh@NetBSD.org>; 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 <mouse@Rodents-Montreal.ORG>
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