Fixing exchange of host keys in the SSH key exchange

"denis bider \(Bitvise\)" <ietf-ssh3@denisbider.com> Thu, 23 March 2017 06:53 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 8DEDE127843 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; 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 <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; 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 <secsh-tyoxbijeg7-archive@lists.ietf.org>; 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 <ietf-ssh@netbsd.org>; 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 <ietf-ssh@netbsd.org>; 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 <ietf-ssh@netbsd.org>; 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\)" <ietf-ssh3@denisbider.com>
To: <ietf-ssh@netbsd.org>
Cc: <djm@mindrot.org>, "Simon Tatham" <anakin@pobox.com>
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: <base64-sha256-fingerprint>\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