Re: [Curdle] WG status and rsa-sha2 as public key algorithm

denis bider <> Fri, 05 May 2017 06:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B72FE1293F9 for <>; Thu, 4 May 2017 23:18:19 -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 uazi77IVBUfe for <>; Thu, 4 May 2017 23:18:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF5E4127097 for <>; Thu, 4 May 2017 23:18:17 -0700 (PDT)
Received: by with SMTP id p143so8647284yba.2 for <>; Thu, 04 May 2017 23:18: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; bh=usQO++vd4njiCQY7rra/iK0N5u4JDN37G3eIWKHNMbo=; b=LykUXsyOzOHDiW8wiaYNe3sQ6pcMO0duJ54Ha4zoepVOi1dquJ+zURNSMg8RL61qVg SwEvX9D2O7OsogT2LDWUReN8BCqFouKLjCnyHcJtsVOMC6O1hNUnV1vrbBtYHN8EvbTg 4eK3f+3qn/xkmWIfa3Liejkp5xuN1HWd2JzHpvWoK+DqK75aZ+n4ZKGaZ7rv2QbtoJqI pnwx8j0aYzX3gk9B8YIJfAIb00FRW4Tbqt47sJpSsfAxVJ0+BgoiH0erFSHvZ2lS2jhq H8qHC9tHXY81dIS1m4r1gH5fBMcLRoWdXAAk6tzqoYjwkt7Gkf0ymXatoVgG1oN3qbGe rppQ==
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; bh=usQO++vd4njiCQY7rra/iK0N5u4JDN37G3eIWKHNMbo=; b=HsOFBKxiea5BGGCs6kw867sHU5kjOvDn0Lj6TsqxOHkw2cLd89v/jaLs6El9xoh1ml gTJZHbrVfynqlxnaASUbsdPwaO0xL5XMTC+s91x84L/HiPZZZ4wIUhUOyVFBgaplWHel wQCMaJsGTiWXrAQvNJ5P21GeX+0LbX/i+cVwQ8XUFja51mkBmPAHStWc67Tfj8w2w5Xf 0jwQc/mCA0eliE+Zo2RQbYiiPXxCrxjekDNUtzYoAye7eCMOpAT7qp2IxtVQaeqx5X54 w6fiB9Q5s+nqrV2kd7igByjU/IHpQYy60AZ6FKOmteBK4TdeofH/yJibfLEITaeYfe/s Agjw==
X-Gm-Message-State: AN3rC/5S4FNCzko/fRDYW7DaPKYpY+cQzPzkJgS94oVDQxmDzX0sW51h pC7Z74/TbSCYPfcAH3WE/rzogIQVSs/v
X-Received: by with SMTP id q78mr39060119ybq.31.1493965097072; Thu, 04 May 2017 23:18:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 4 May 2017 23:18:16 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: denis bider <>
Date: Fri, 5 May 2017 00:18:16 -0600
Message-ID: <>
To: curdle <>
Content-Type: multipart/alternative; boundary=001a1143f9ceeb0116054ec0daca
Archived-At: <>
Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm
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: Fri, 05 May 2017 06:18:20 -0000

Although my below response was self-explanatory, it is not sufficient. It
requires elaboration:

- The extension being specified is already deployed in a variety of
implementations, not only OpenSSH. (See [1] at bottom)

- Since the draft thus far remains compatible with existing
implementations, changing the name of the extension would break

- Breaking compatibility with existing implementations requires a
substantive reason. I am currently not aware of a substantive reason to do

- A problem in particular versions of a particular implementation is not a
substantive reason. Idiosyncrasies of specific implementations are handled
by others recognizing the SSH version string, not diverging the protocol.

- It is not clear to me that the problem you reference in OpenSSH versions
prior to 7.5 is a problem that needs to be addressed at this level.

- In a previous message, Damien Miller, who is representative of OpenSSH in
this forum, has expressed a preference to keep the same extension name.

To be clear, the extension name is not one I'm overly happy with. In fact,
I had changed the name of the extension from "server-sig-algs" to something
more appropriate in an early version of the draft. However, by that time,
another implementation already picked up "server-sig-algs".

For this reason, I changed the spec back to "server-sig-algs". Although the
name is not ideal, it is now in use; and the name being ideal is strictly
less important than there being one identifier; and one identifier only;
for the same concept, if reasonably possible.

I stand by this decision, and think it's incorrect to modify the name at
this time, unless the mechanics of the extension are changed in some way
that's fundamental.

[1] According to this excellent, but at this time slightly outdated

... implementations of rsa-sha2-*** public key algorithms include AsyncSSH,
SmartFTP, and OpenSSH. Bitvise SSH Server and Client also support them, but
this is not listed in the chart. This leads me to believe there may be
other implementations also. I know that at least three of these
implementations also implement the "server-sig-algs" extension under its
current name.

On Thu, May 4, 2017 at 11:12 PM, denis bider <>

> > 10x for new versions.
> You don't even have the decency to spell that.
> > The name of extension "server-sig-algs" must be changed as well.
> No fucking way. Fuck off.
> On Thu, May 4, 2017 at 1:17 PM, Румен Петров <>
> wrote:
>> Hi denis,
>> denis bider wrote:
>>> Hello everyone,
>>> in the interest of consensus, I have adopted the requested terminology
>>> changes in the two drafts. What was previously "signature algorithm" is
>>> now
>>> "public key algorithm", and what was previously "public key algorithm" is
>>> now "public key format".
>>> Please review and let me know.
>> 10x for new versions.
>> Main context of *draft-ietf-curdle-rsa-sha2-07.txt* is fine with me.
>> I still think that chapter 4 IANA Considerations could be simplified to
>> list only public key algorithm but this is not so important.
>> The chapter refer to RFC4250 but section 7.1 Normative References lack
>> reference to it. May be is good to list RFC4250 as well.
>> No other remarks.
>> About draft-ietf-curdle-ssh-ext-info-06.txt:
>> The name of extension "server-sig-algs" must be changed as well.
>> First because extension contain  abbreviation of signature in name
>> (description is fine),
>> second because existing implementation does not follow rules from
>> RFC4250, section 4.6.1. "Conventions for Names" and
>> third(!) due to broken OpenSSH implementation: " ...where SHA2 RSA
>> signature methods were not being correctly advertised..." fixed in 7.5.
>> [SNIP]
>> Regards,
>> Roumen Petrov
>> _______________________________________________
>> Curdle mailing list