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

Mouse <mouse@Rodents-Montreal.ORG> Thu, 06 April 2017 20:35 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 E94ED12941D for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Thu, 6 Apr 2017 13:35:07 -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 6xrVoAbrZnR6 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Thu, 6 Apr 2017 13:35:06 -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 0C2BD12965B for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Thu, 6 Apr 2017 13:35:03 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id 5EDF285654; Thu, 6 Apr 2017 20:34:45 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: by mail.netbsd.org (Postfix, from userid 1347) id 16C4D85645; Thu, 6 Apr 2017 20:34:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5DC598557E for <ietf-ssh@NetBSD.org>; Wed, 5 Apr 2017 08:03:14 +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 ITEfuVJGr1A9 for <ietf-ssh@netbsd.org>; Wed, 5 Apr 2017 08:03:13 +0000 (UTC)
Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id E55F6856D4 for <ietf-ssh@NetBSD.org>; Tue, 4 Apr 2017 22:06:58 +0000 (UTC)
Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id SAA17278; Tue, 4 Apr 2017 18:06:58 -0400 (EDT)
Date: Tue, 04 Apr 2017 18:06:58 -0400
From: Mouse <mouse@Rodents-Montreal.ORG>
Message-Id: <201704042206.SAA17278@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: Tue, 4 Apr 2017 18:04:03 -0400 (EDT)
To: ietf-ssh@NetBSD.org
Subject: Re: Fixing exchange of host keys in the SSH key exchange
In-Reply-To: <20170403200250.GB21972@serpens.de>
References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <20170403200250.GB21972@serpens.de>
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?

That actually is a very interesting argument I hadn't thought of for
something operationally like the proposed scheme: it permits the server
to support multiple host keys at once for a single algorithm.  (The
client, of course, already can, since in the current design it's the
one judging host key validity.)

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