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

Mouse <mouse@Rodents-Montreal.ORG> Fri, 07 April 2017 21:02 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 A75E3127867 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Fri, 7 Apr 2017 14:02:27 -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 y39dGYCKHHC2 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Fri, 7 Apr 2017 14:02:25 -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 ECAC812786A for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Fri, 7 Apr 2017 14:02:25 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id 00ADB84D73; Fri, 7 Apr 2017 21:02:24 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: by mail.netbsd.org (Postfix, from userid 1347) id A398B84CE2; Fri, 7 Apr 2017 21:02:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DE2A484D74 for <ietf-ssh@NetBSD.org>; Fri, 7 Apr 2017 20:41:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at netbsd.org
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 FOrDVtHedFH4 for <ietf-ssh@netbsd.org>; Fri, 7 Apr 2017 20:41:51 +0000 (UTC)
Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 7DC94859C9 for <ietf-ssh@NetBSD.org>; Fri, 7 Apr 2017 15:29:33 +0000 (UTC)
Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA27568; Fri, 7 Apr 2017 11:29:32 -0400 (EDT)
Date: Fri, 7 Apr 2017 11:29:32 -0400 (EDT)
From: Mouse <mouse@Rodents-Montreal.ORG>
Message-Id: <201704071529.LAA27568@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: Fri, 7 Apr 2017 11:08:21 -0400 (EDT)
To: ietf-ssh@NetBSD.org
Subject: Re: Fixing exchange of host keys in the SSH key exchange
In-Reply-To: <05DC33124D144EC0B39A5BF58C8E3A33@Khan>
References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <20170403200250.GB21972@serpens.de> <05DC33124D144EC0B39A5BF58C8E3A33@Khan>
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

>> if I may stick an oar in sideways: if you go to all the trouble,
>> could you add a mechanism by which the server could advise that the
>> host key used by the client was still valid but deprecated, and to
>> download the new host key once connected?

> OpenSSH documents this as a private extension: [...]

They say, when describing hostkeys-00@openssh.com and
hostkeys-prove-00@openssh.com, that "[i]t also supports graceful key
rotation: a server may offer multiple keys of the same type for a
period (to give clients an opportunity to learn them using this
extension) before removing the deprecated key from those offered".

I cannot see how this is even possible, at least not without a custom
kex algorithm.  With, for example, Diffie-Hellman as defined in 4253
section 8, the server presents only one host key to the client, and
must choose which one to present before kex (and thus authentication)
completes.  This then gives no room to "offer multiple keys of the same
type".

The only way I can see that making any sense at all is if the server
continues to use the old key, but advertises both keys with
hostkeys-00@ for a period before bringing the new key into use.  Maybe
that's what they're talking about, but if so I think the wording is
rather confusing.  I much prefer the client-specified list of host keys
such as is made possible by what we started out this thread discussing.

I also don't see anything in the OpenSSH stuff that allows the server
to indicate that certain of the keys listed in hostkeys-00@ are
deprecated, which is at least part of what I read spz as asking for.

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