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

"denis bider \(Bitvise\)" <ietf-ssh3@denisbider.com> Mon, 27 March 2017 01:20 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 236951289B5 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sun, 26 Mar 2017 18:20:56 -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 EY6bDY1zFdLn for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sun, 26 Mar 2017 18:20:53 -0700 (PDT)
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 BD63C12894E for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Sun, 26 Mar 2017 18:20:53 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id DC9C78559F; Mon, 27 Mar 2017 01:20:51 +0000 (UTC)
Delivered-To: ietf-ssh@NetBSD.org
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3980885588 for <ietf-ssh@NetBSD.org>; Mon, 27 Mar 2017 01:20:48 +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 ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id Bj6uLxxSIPUm for <ietf-ssh@netbsd.org>; Mon, 27 Mar 2017 01:20:47 +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 A98F784CDE for <ietf-ssh@NetBSD.org>; Mon, 27 Mar 2017 01:20:47 +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=iBjwBBimQkC3yjRI+4tnm6y/bagkLYP8eAnUkqsFpyQ=; b=d4WYEDrGPjZ4xVK5TRIdmzGAbp1k/FA7jPjjaFPbasDVoouK/pJtkQVde6ojoFHGds0IsXBmy1PIM SIjNfxkET20W5bWDH2L/sSqws6GYbqlg4WurpaCkUnoNHe8zvgBzbIlxjIjenj+RSa9+wSLhp250L1 p820dm+2P5hrsQ09ecPEP/tN8ioPXFSLj7UfAeCuuAaJTZSQ+KFBgrnCp0c4lrxHgEnBVooLNMWaZT 2VeOfXOTAQfUxdrypge8zRl8uGtvmIafJ55NRBWjZJq84d+c+r6wuQLTm64+0t7/mVfCS2nD0oS6H0 hSY80BsuQJvJKPA7NGz33aw9i89Le7g==
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:20:36 +0100
Message-ID: <AF94B953EDE7493782D80E299F0B24E2@Khan>
From: "denis bider (Bitvise)" <ietf-ssh3@denisbider.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Mouse <mouse@Rodents-Montreal.ORG>, ietf-ssh@NetBSD.org
References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan><1490340148872.12344@cs.auckland.ac.nz>, <201703251227.IAA20189@Stone.Rodents-Montreal.ORG> <1490518384910.80699@cs.auckland.ac.nz>
In-Reply-To: <1490518384910.80699@cs.auckland.ac.nz>
Subject: Re: Fixing exchange of host keys in the SSH key exchange
Date: Sun, 26 Mar 2017 19:20:47 -0600
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
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

Peter:


> https://www.usenix.org/system/files/login/articles/
> 105484-Gutmann.pdf

This article is actually a strong argument in favor of Expect-Key, or 
something like it.

What you found is NOT that people use TOFU (Trust On First Use). They use 
TWAT - Trust Whatever, Any Time:


> I asked the IT support staff how many users had called
> or emailed to verify the SSH server key whenever it had
> changed in the past several years. They were unable to
> recall a single case, or locate any records, of any user
> ever verifying any SSH server key out-of-band

This is highly problematic because it means that, while SSH is supposed to 
defend against MITM in theory, it does not defend in practice.

OpenSSH already addresses this in their client, I believe, by making it 
really quite hard to verify a changed key. Many users further configure the 
OpenSSH client to require a key to be set up for the first connection, to 
begin with.

Expect-Key just extends that - which I think is a good practice - to all 
clients, in general, enforceable as a server-side policy. It defeats TWAT.


> Conversely, it means the vast majority won't use it.

Users will use what administrators set up for them. If admins don't want to 
set up Expect-Key, fine. But this gives them a tool.

denis



----- Original Message -----
From: Peter Gutmann
Sent: Sunday, March 26, 2017 02:53
To: Mouse ; ietf-ssh@NetBSD.org
Subject: Re: Fixing exchange of host keys in the SSH key exchange

Mouse <mouse@Rodents-Montreal.ORG> writes:

>As far as I can see, this affects the user only in that "pick up the host 
>key
>on first connect" no longer works.

It breaks TOFU.  Since this is how the vast majority of all users use SSH
(ref: 
https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf),
it means it would break SSH for them.  Conversely, it means the vast 
majority
won't use it.

>Then this suggestion has the additional feature that it will smoke out such
>bugs!

Trying to smoke out non-standards-compliant implementations at this point,
about twenty-odd after SSH2 started getting deployed, is probably a bit late
in the game.

Also, does this mean any implemenation that doesn't correctly implement a 
MUST
or MUST NOT can regarded as broken and discarded?

Peter.