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

Mouse <mouse@Rodents-Montreal.ORG> Mon, 27 March 2017 05:33 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 81B2F1293F3 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sun, 26 Mar 2017 22:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 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, URIBL_BLOCKED=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 I8InwXamD3xH for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sun, 26 Mar 2017 22:33:41 -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 08CE3128BE1 for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Sun, 26 Mar 2017 22:33:41 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id C24A9855EB; Mon, 27 Mar 2017 05:33:40 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: by mail.netbsd.org (Postfix, from userid 1347) id 7F9B0855D8; Mon, 27 Mar 2017 05:33:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 80C64855B6 for <ietf-ssh@netbsd.org>; Sun, 26 Mar 2017 12:10:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at netbsd.org
Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 2KX2S8Gb93M5 for <ietf-ssh@netbsd.org>; Sun, 26 Mar 2017 12:10:55 +0000 (UTC)
Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 853918557F for <ietf-ssh@netbsd.org>; Sun, 26 Mar 2017 12:10:54 +0000 (UTC)
Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id IAA26334; Sun, 26 Mar 2017 08:10:53 -0400 (EDT)
Date: Sun, 26 Mar 2017 08:10:53 -0400
From: Mouse <mouse@Rodents-Montreal.ORG>
Message-Id: <201703261210.IAA26334@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: Sun, 26 Mar 2017 07:53:00 -0400 (EDT)
To: ietf-ssh@netbsd.org
Subject: Re: Fixing exchange of host keys in the SSH key exchange
In-Reply-To: <1490518384910.80699@cs.auckland.ac.nz>
References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <1490340148872.12344@cs.auckland.ac.nz>, <201703251227.IAA20189@Stone.Rodents-Montreal.ORG> <1490518384910.80699@cs.auckland.ac.nz>
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

>> 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.

Yes.  As denis recently said, that's the major point of it: some -
probably a minority, but so what? - server admins _want_ to break TOFU,
to ensure that their users are doing more secure key handling.

Another possibility is that users _do_ use TOFU, but are allowed to
only over secure-enough networks.  This allows configurations like
"You're coming from the office LAN, you can TOFU - but when you come in
over the open Internet, you have to already have the host key", by
providing a mechanism to enforce the second half of it.

> Since this is how the vast majority of all users use SSH [...], it
> means it would break SSH for them.  Conversely, it means the vast
> majority won't use it.

Which is fine.  Having it available does not mean it should be the
default.

>> 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.

Probably.  But better late than never.  Though, as remarked upthread,
it's not clear that breaking on pre-ID text in the client-to-server
direction _is_ a bug.

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

Ideally.  But that's true of any spec.

Those ssh implementations I mentioned upthread that crashed upon seeing
string@domain extensions?  We didn't discard them; we worked around
them.  I would have preferred to replace them, but that was not
practical at the time (this years ago was at work and they were
embedded servers on, IIRC, network switches - I hope we filed bug
reports with the vendor(s) in question, but I'm not sure of even that
much).

/~\ 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