Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
denis bider <denisbider.ietf@gmail.com> Mon, 27 April 2020 09:00 UTC
Return-Path: <denisbider.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866013A144D for <curdle@ietfa.amsl.com>; Mon, 27 Apr 2020 02:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 b3MI0RRuKzDd for <curdle@ietfa.amsl.com>; Mon, 27 Apr 2020 02:00:29 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2553E3A1348 for <curdle@ietf.org>; Mon, 27 Apr 2020 02:00:24 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id g14so24875020otg.10 for <curdle@ietf.org>; Mon, 27 Apr 2020 02:00:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CADPMZDBcOtUaUBJKn20yEpLi=pmse2SgiXpZXArAKLyKTeS-GQ@mail.gmail.com> <1587965828521.34734@cs.auckland.ac.nz>
In-Reply-To: <1587965828521.34734@cs.auckland.ac.nz>
From: denis bider <denisbider.ietf@gmail.com>
Date: Mon, 27 Apr 2020 04:00:12 -0500
Message-ID: <CADPMZDA33QGM15jq94sDWCyg60pjdT2VWR2-_iRbfBnYBYs4MA@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: curdle <curdle@ietf.org>, "ietf-ssh@netbsd.org" <ietf-ssh@netbsd.org>, Damien Miller <djm@mindrot.org>
Content-Type: multipart/alternative; boundary="000000000000fdb2a605a441f1ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/-I2TXq1TNkYxLn1AOW_0n3ykQLc>
Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=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. :) denis On Mon, Apr 27, 2020 at 12:37 AM Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote: > denis bider <denisbider.ietf@gmail.com> 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.
- [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or … denis bider
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… Ron Frederick
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… denis bider
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… Peter Gutmann
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… denis bider
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… denis bider
- [Curdle] Fwd: Client-side SSH_MSG_EXT_INFO: Use i… denis bider
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… Ron Frederick
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… denis bider