Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!

denis bider <> Mon, 27 April 2020 09:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 866013A144D for <>; Mon, 27 Apr 2020 02:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b3MI0RRuKzDd for <>; Mon, 27 Apr 2020 02:00:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2553E3A1348 for <>; Mon, 27 Apr 2020 02:00:24 -0700 (PDT)
Received: by with SMTP id g14so24875020otg.10 for <>; Mon, 27 Apr 2020 02:00:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=clmCD4OVGFlUWkFWAeEE5VY18Zxxytyh0GJ1w7s4kkk=; b=CiUojHYEhIXEIzLXpF6qBYOfiGzYgKqY5X7NfytfWvG4aytZ0sxY+bEuxhcsIKTSh2 urE/MzgnPs7T39GE6P54mXFqFXlAazCMMiNp9PL0ArITZpUgZkVpucPaLF0R3FEgowUk x+K3aT6PH/2Do4170ZSTuT/LCR9fbL4hjJ03rDGGvm+YO7R5EL/TLZKXvK/ndVXPJ+xL SMXWpItohRWbqJdFxxhHVQDG1pOQoBhjaFjgJQ4d6PziS82H9gvDnzdcLbeYvbZBjlr1 XN41XFE164QKCAwwt5c8X7Dns00ih1bB/sq9j6SGiW/NCMJ+vN2DZj+n/6a+VdsbuX6M lACw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=clmCD4OVGFlUWkFWAeEE5VY18Zxxytyh0GJ1w7s4kkk=; b=iNMCJDYmPLrdUmzWoKTj/SrA0fvnbkSI/klJlWc+rmAQFl7LfdXUxiTfo1SIqxbsg3 Sql4FIM9gf8OqGZ6hlcox2W9SEOaR1gK+Lz20NMhyzZEWwdp7L+rqYDLKZvhVR72PO5s dZdB2r2VeFFhmdXu1WocoAp31kWAqB5hZ0sJoLDCRXYfTRN8y4EgEa6muXXTrFMjdtPz A0sN0Tf34WtKt1Ct/rTXCnsubYE2BMqa+slbH1QyWkxD9qOkWlRMJnyvsPbgdElE809h ZsM8glmILry8y116x0DrHWnMsh+3YplEreZP9EyFZjI3NkWkSIawXu3vcvTPetx/CTAf BH9Q==
X-Gm-Message-State: AGi0PuZZA5P/XmlRbAw3VHkQsTMKTG3nVsAdxeOCtBZDgtyUVL3jufNB j9P/XLlqFfeHbAB/05DdXLBI4ImCqNoMn/BJi8Q=
X-Google-Smtp-Source: APiQypLFtuhsO15x9RwKhdbhBbITcqGAtP+TvGvr1VpQ/UsDAIZ8Si2F6C/1IpwL/Pc+o4YxichnsX7hA+d5lQGm+q4=
X-Received: by 2002:a05:6808:7dc:: with SMTP id f28mr3203938oij.88.1587978023317; Mon, 27 Apr 2020 02:00:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: denis bider <>
Date: Mon, 27 Apr 2020 04:00:12 -0500
Message-ID: <>
To: Peter Gutmann <>
Cc: curdle <>, "" <>, Damien Miller <>
Content-Type: multipart/alternative; boundary="000000000000fdb2a605a441f1ba"
Archived-At: <>
Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Apr 2020 09:00:33 -0000

About this:

> TLS dealt with this to some extent by adding a mechanism
> bacronym'd as GREASE for sending random information in
> extensions to detect implementations that broke on them,
> perhaps something similar could be done for SSH.

The challenge with this is that some widely used implementation -
*cough*OpenSSH*cough* - would need to exercise all functions of the
protocol that are legal, but not necessarily in widespread use. If they
want to prevent rusting at the joints, OpenSSH would have to do so for most
features, including those they do not CURRENTLY find useful.

For example, if a common problem is that clients fail to correctly handle
global requests if they receive them while waiting for channel open
confirmation - this is a bug that both OpenSSH and PuTTY had, at some point
long ago - then the way to exercise that would be to include a trivial
global request, in say 10% of cases, before a channel open confirmation.

I would welcome that, personally, and hence that's why I originally
included Damien in this thread. :)


On Mon, Apr 27, 2020 at 12:37 AM Peter Gutmann <>

> denis bider <> writes:
> >it has come to my attention that at least one SSH server implementation
> (a)
> >advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b)
> >disconnects on actual receipt of an EXT_INFO message from the client.
> Not wanting to do a public name-and-shame on this, but could you share the
> ID
> string needed to fingerprint this server?  Looks like a lot of
> implementations
> will need to be able to deal with this...
> >This happens when we define a general mechanism, but then the most widely
> >used implementations only use certain aspects of it.
> That's a more specific version of "an implementation is fully SSH
> standards-
> compliant when it can connect to OpenSSH (client) or Putty can connect to
> it
> (server)".  Those two are the universal benchmark for SSH implementations,
> for
> better or for worse.  TLS dealt with this to some extent by adding a
> mechanism
> bacronym'd as GREASE for sending random information in extensions to detect
> implementations that broke on them, perhaps something similar could be done
> for SSH.
> Peer.