Implementation-hazards list [was Re: Fixing exchange of host keys in the SSH key exchange]

Mouse <mouse@Rodents-Montreal.ORG> Tue, 28 March 2017 05:38 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 E02D5126C89 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Mon, 27 Mar 2017 22:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 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] 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 Ojb7jkXuxYwc for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Mon, 27 Mar 2017 22:38:03 -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 54804128AB0 for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Mon, 27 Mar 2017 22:37:59 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id 7A962855B8; Tue, 28 Mar 2017 05:37:48 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: by mail.netbsd.org (Postfix, from userid 1347) id 345FF855B0; Tue, 28 Mar 2017 05:37:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B92CA85585 for <ietf-ssh@netbsd.org>; Mon, 27 Mar 2017 22:05:01 +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 BxeyG8nFShL1 for <ietf-ssh@netbsd.org>; Mon, 27 Mar 2017 22:05:01 +0000 (UTC)
Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id B5D0684CDA for <ietf-ssh@netbsd.org>; Mon, 27 Mar 2017 22:05:00 +0000 (UTC)
Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id SAA12391; Mon, 27 Mar 2017 18:04:59 -0400 (EDT)
Date: Mon, 27 Mar 2017 18:04:59 -0400
From: Mouse <mouse@Rodents-Montreal.ORG>
Message-Id: <201703272204.SAA12391@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: Mon, 27 Mar 2017 17:49:56 -0400 (EDT)
To: ietf-ssh@netbsd.org
Subject: Implementation-hazards list [was Re: Fixing exchange of host keys in the SSH key exchange]
In-Reply-To: <BE0AC8D434BC4010842179F29664E7A7@Khan>
References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG>, <B27F1BAE8F974449B6EE8B7DF50ED3A9@Khan> <1490595711031.1686@cs.auckland.ac.nz> <BE0AC8D434BC4010842179F29664E7A7@Khan>
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

>>> For the most recent example, an older version of a popular library
>>> used to have the "maximum channel packet size" concept completely
>>> borked up.  For a channel opened by the remote party, this library
>>> would overwrite its own maximum packet size with the remote one.
>> It seems like every implementer has stories like this, but no-one
>> can really mention them in public because you don't want to
>> embarrass a particular vendor...

Well, in many cases.  I, for example, am not at all chary about naming
OpenSSH as the implementation whose misfeature prompted me to add
-share-number to moussh (even the moussh manpage does so), and I'd name
the vendor of the devices whose implementation crashed when given
string@domianname extensions if I remembered it (and were sure I
rememebred it right).  But I can certainly understand at least a few of
the reasons not everyone is as willing as I am to do that.

However...

>> would there be any interest in having a private list of email
>> addresses of people to exchange information like this with?

...I don't see any need to name-and-shame on such a list.  It's the
misbehaviour, not whose implementation exhbits it, that matters for
implementation purposes.

There might perhaps be value in an implementation with options to make
it exhibit various kinds of misbehaviour, for testing against.  (I'm
tempted to turn moussh into such a one, but now is not a good time for
me to be taking on more timesinks.)

> That sounds like a good idea. I would be interested to follow and
> participate.

Me too.

> The obstacle seems to be getting people together.  Those of us
> whoâ??ve been around for 15 years may be on this mailing list.  Iâ??m
> not sure if this is true for authors of newer implementations, who
> might benefit from this information most.

I'm not sure either.  Perhaps if the list were archived and the
archives were up somewhere on the Web, the new crowd who expects
everything to be Web this and Web that might be able to find it?

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