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

"denis bider \(Bitvise\)" <ietf-ssh3@denisbider.com> Mon, 27 March 2017 05:32 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 861631241FC for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; 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 <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; 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 <secsh-tyoxbijeg7-archive@lists.ietf.org>; 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 <ietf-ssh@NetBSD.org>; 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 <ietf-ssh@netbsd.org>; 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 <ietf-ssh@NetBSD.org>; 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: <B27F1BAE8F974449B6EE8B7DF50ED3A9@Khan>
From: "denis bider \(Bitvise\)" <ietf-ssh3@denisbider.com>
To: "Mouse" <mouse@Rodents-Montreal.ORG>, <ietf-ssh@NetBSD.org>
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