IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 27 April 2020 05:37 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 A237C3A0C64 for <curdle@ietfa.amsl.com>; Sun, 26 Apr 2020 22:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=auckland.ac.nz
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 1kDRB6r5hqJM for <curdle@ietfa.amsl.com>; Sun, 26 Apr 2020 22:37:11 -0700 (PDT)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 257023A0C63 for <curdle@ietf.org>; Sun, 26 Apr 2020 22:37:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1587965831; x=1619501831; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VO9R0tPYGWHF1oKMgxBErKQ9QlbfPCxvPiwCJBQ4DqM=; b=Hgezl8oTPSRa0L/u00sRiFdC1+d/XkC9HbVjQPncLsL32w+1EK5hxWqm I5qFMFs8lO8XP+Ergutl+YHMBV+LU8WLQgWZvb5RFrhkNvw3XPf1fC9Nu io+NZ58PuSTnsxkwjfT1xSe5RY1J6ZwtcSsReDQD+bj7bMqij+unete5a jj8+iLbYmjj3cvam5oLyGStMZRqpen4LgQoW+CEPkJFFUe+ropQ+kge44 o23GwuoGAcVSlvpqpTHzIXlUnzNc681QBvqZ4vfQzla22xIy4DBgB+lkQ LGnR7Fw3Ac88qmyLnq5yQbkK6isPLVVy/S43pQNybtBh6w0G49xzgG6m5 Q==;
X-IronPort-AV: E=Sophos;i="5.73,322,1583146800"; d="scan'208";a="130664647"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Apr 2020 17:37:08 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Apr 2020 17:37:07 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1497.006; Mon, 27 Apr 2020 17:37:07 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: denis bider <denisbider.ietf@gmail.com>, curdle <curdle@ietf.org>, "ietf-ssh@netbsd.org" <ietf-ssh@netbsd.org>, Damien Miller <djm@mindrot.org>
Thread-Topic: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
Thread-Index: AQHWG8K/y2ILacCI70qZEnF0K8IImaiMdBK7
Date: Mon, 27 Apr 2020 05:37:07 +0000
Message-ID: <1587965828521.34734@cs.auckland.ac.nz>
References: <CADPMZDBcOtUaUBJKn20yEpLi=pmse2SgiXpZXArAKLyKTeS-GQ@mail.gmail.com>
In-Reply-To: <CADPMZDBcOtUaUBJKn20yEpLi=pmse2SgiXpZXArAKLyKTeS-GQ@mail.gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/od_IEgB50u36-kLs5rGLkbM9UkY>
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 05:37:14 -0000

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.

v2.23.0 | Report a Bug | By Email