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
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Fixing exchange of host keys in the SSH key excha… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Implementation-hazards list [was Re: Fixing excha… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Implementation-hazards list [was Re: Fixing e… Peter Gutmann
- Re: Implementation-hazards list [was Re: Fixing e… Darren Tucker
- Re: Implementation-hazards list [was Re: Fixing e… Mouse
- Re: Implementation-hazards list [was Re: Fixing e… denis bider (Bitvise)
- Re: Implementation-hazards list [was Re: Fixing e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… S.P.Zeidler
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Mouse