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

denis bider <> Thu, 22 March 2018 09:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4671126C19 for <>; Thu, 22 Mar 2018 02:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 9oxef3CZh2fV for <>; Thu, 22 Mar 2018 02:03:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 104D91250B8 for <>; Thu, 22 Mar 2018 02:03:17 -0700 (PDT)
Received: by with SMTP id i8so8145573qtj.0 for <>; Thu, 22 Mar 2018 02:03:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i9nIwmuew3YqBuoixpTWjSEL+5iXdiGjD4YgcVnqexg=; b=Uyf3euw388QcCO8Hcx8s+gWzx1DpWzgnuDExylta3XeWVBL9JVRRFxYozj2qppaQIU 8lJHUYgp7VHKBLBmxUz8BQ1P+flq1dcukhL6RmHDOzn3eWA/4eRffRKyUxQSzoCoC/2D uAZVQFYj8j41LE/QjZL3Z9B3T0r95r33e+rD1GbdzedxLOOwDAqgMcUrHMmdN1beD8fx 01HYHfaixUfhuEOEa5lCi8rhGOMYdwZ+7VR8TXyHR84BHHweCT0r+RmlubgNH5PZyc2c 4QYbLp7uWg1q4ralZWDoqjF26sRWMUU2piTqIJnTHw2gYi69chTJtKCm9s7JhLrHREt4 nGAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i9nIwmuew3YqBuoixpTWjSEL+5iXdiGjD4YgcVnqexg=; b=G3dHi2fq1C5yQht7ADLRlgLi3ftryWdHG4ikctCgAcRQhvOhGKQF00w4PelgPj9Iux 07HI7gHQMx1woe6uPoEBqlkhnUIsrDW/pE8BdLRQGWtVB+wSNwrF70ynQMIP5orKS7uu UV32mIrh+7pKxkTuiSfMSh5aoiwX57WV56Rdec+kHo8jhr66I+IdLMxPzpva2YG0KT2G F6/XmZh4wKwBWaMPCwjprFKibcm8fGyrH6AYxmSynLn6EVHnR6HMFFZVScDK5ZD7ZiOa VTCWTrKZ1xk0/5OZihxwM1SiYUfkf7NEbCfRmHC63DA1p/DfxHTZ1DVe1D1+qbj6bjZt aRiw==
X-Gm-Message-State: AElRT7EgjLgao3FNZcKWTZlVoNHUMhDgxQwPHd35X0Mi3mip08xV6eTT wi3Vo4tUr5//xAs6/JGADJTBlg66dXIJud70vzBQJg==
X-Google-Smtp-Source: AG47ELt5BYiywdfAtWCfeTnBsD1f+4lXz1xDEFMfmDAkcUvKzvhl8R0YbVP8f6Ojn+fsDHzU/GGB8jSx2AGuOML8G1U=
X-Received: by with SMTP id j27mr33878449qtj.331.1521709396216; Thu, 22 Mar 2018 02:03:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 22 Mar 2018 02:03:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: denis bider <>
Date: Thu, 22 Mar 2018 04:03:15 -0500
Message-ID: <>
To: Peter Gutmann <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a1141af38034f400567fc94bb"
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 09:03:24 -0000

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.

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 include:

- EXT_INFO sent by client (only server sends it for "server-sig-algs").

- Extensions with binary extension-value (for example "delay-compression").

Both of these hinges will be exercised in our next SSH Server and Client
versions (8.xx). However, our implementation has presence on only one
platform, so I would love to see "delay-compression" implemented more
widely so that these hinges do not rust.

This hinge did already rust in the initial implementation by OpenSSH
(binary extension-value caused disconnect until version 7.5).

"delay-compression" involves both client-side EXT_INFO and a binary
extension-value, so it is the single most effective thing to implement to
avoid rust.

On Wed, Mar 21, 2018 at 12:48 AM, Peter Gutmann <>

> denis bider <> writes:
> >That depends - which extensions do you have in mind to test? In what way
> in
> >particular would you like to test them?
> It was actually meant for both of the new RFCs, the RSA one to
> regression-test
> that nothing has broken since versions based on the drafts were written
> (e.g.
> in regard to fixed- vs variable-length RSA blocks :-), the extension one
> just
> to check that extensions sent and received are correctly handled without
> anything choking.  The actual extension doesn't matter, just the message
> flow
> handling.
> >If you are looking for "server-sig-algs", this is by now fairly widely
> >implemented in e.g. the latest versions of OpenSSH, and Bitvise SSH Server
> >and Client versions 7.xx.
> OK, I'll see if I can set up a recent OpenSSH to bounce some messages
> off.  I
> just want to make sure that both RSA and extension messages are handled
> correctly.
> Peter.