Re: [Curdle] RFC 8308 on Extension Negotiation in the Secure Shell (SSH) Protocol

Peter Gutmann <> Thu, 22 March 2018 10:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 175AF126D05 for <>; Thu, 22 Mar 2018 03:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 bPHaSEiU2tSB for <>; Thu, 22 Mar 2018 03:13:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B75F11205D3 for <>; Thu, 22 Mar 2018 03:13:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1521713623; x=1553249623; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lElQ5do5njFyYt+jZjGMtKRxvqnu9Aj4fnJAf5ZNdTY=; b=i47wuLPaKvBe53P5v+2Vd45DPCpGkwWDxE5Kv1MvpsV88rPnAtBHY7FN MmsTBqThCcOLHb+cdFBXhgosPd5xpsdjCRQoZuUKdcfX0At8l8EWTTSa2 ZOdSbzrOsLePMnHxOaaNyzE+A5aBLI6uhvCMbGaey+wyYha+x6eMQbtun O/VgJvWhtl2Fktx3syAMr6AhAxi3bxG9yzrAMTCYpTEHqrOtNsXsDqLC7 k+H4T3AxqAZRWfBUMoBgJB6sL6004oDj8lstqd6QxFP772X9HgbpDR9hb Sx36S55tGF2/FWPg3om8VtcuMm4rC4fpdskDo3y96u5826J+XUnpBLBU0 A==;
X-IronPort-AV: E=Sophos;i="5.48,344,1517828400"; d="scan'208";a="5059747"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 22 Mar 2018 23:13:42 +1300
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 22 Mar 2018 23:13:41 +1300
Received: from ([]) by ([]) with mapi id 15.00.1263.000; Thu, 22 Mar 2018 23:13:41 +1300
From: Peter Gutmann <>
To: denis bider <>
CC: "" <>
Thread-Topic: [Curdle] RFC 8308 on Extension Negotiation in the Secure Shell (SSH) Protocol
Thread-Index: AQHTv9DqTztCRMPgtUCAF40z/7haeKPY3waBgAAapACAATcpaYAA7taAgADtYSA=
Date: Thu, 22 Mar 2018 10:13:40 +0000
Message-ID: <>
References: <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Curdle] RFC 8308 on Extension Negotiation in the Secure Shell (SSH) Protocol
X-Mailman-Version: 2.1.22
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: Thu, 22 Mar 2018 10:13:45 -0000

denis bider <> writes:

>Where I'm less comfortable is the hinges that are not yet widely deployed. As
>long as a hinge is not in common use, it is in danger of rusting. These hinges
>- EXT_INFO sent by client (only server sends it for "server-sig-algs").
>- Extensions with binary extension-value (for example "delay-compression").

I was going to try sending in extensions with undefined values, and binary
data embdded in them, to see what happens.  If it's the same as previous, in
some instances inadvertent, cases of sending unexpected data values then I
expect all sorts of fireworks.

>EXT_INFO with the "server-sig-algs" extension is widely deployed. It's well
>tested with rsa-sha2-256 and rsa-sha2-512 signatures, and I have no concerns
>about it. As far as I know, there are no compatibility issues to be
>experienced by an implementation that follows the just-published spec.

OK, that's good to know.