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

denis bider <denisbider.ietf@gmail.com> Fri, 05 May 2017 10:15 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 8358F129494 for <curdle@ietfa.amsl.com>; Fri, 5 May 2017 03:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: 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 yl0ygwOY2DMU for <curdle@ietfa.amsl.com>; Fri, 5 May 2017 03:15:37 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 0F25B129501 for <curdle@ietf.org>; Fri, 5 May 2017 03:15:37 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id p143so149057yba.2 for <curdle@ietf.org>; Fri, 05 May 2017 03:15:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=bMEP6I29IbkF/th9c179MmRnf1nUEG2d/6mhRr4y8aM=; b=rrRik44DL9lqkRawB1dhMfgnSaoz3bqYhedGRcZ6TjMVUuCz0gbGdCciMUX82ci3jx mtIm+gVZf7lCONFdwUrimHSpEcRndvnW9TPu8vcdRtIXp8Fi/E3UuRn6lYIFMMRXJLW5 dn+m4J1ei/E/LB7Ohl+rqWow166HIlQasupgu/krU0/w9k+hWORBbSrdCe+2uhVFz6If BwwHRyDgavnDSvatXpO6GKL2LfQciIjtNI79/PNNbale5n2M4p8RqhNQgfQOho8mtot4 LWkTWWZjPDAofaSUcHMwlukHPdQZdQOSnu4zrGO/uDNbBII29C3/X2lFqbAjdkJrJz/u n03g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=bMEP6I29IbkF/th9c179MmRnf1nUEG2d/6mhRr4y8aM=; b=rYjRNQ/SX2TO2dIByJX9h9gyLrdVSM04ysMF985nzBTZi2hsVlJz7VgsPoM5Rxukup qs3Y+wjeFlShyaho4NsgdrcVSiyO0W0UdaY9qIfcHmVdKv8HzKZr5kGJcPJBHak4+gpf C6tTTr6KRjFdejqrPsEBvjduUsBgrF/RhOM1v4vWZKfM0gBPBPNWx/kZGQsoNfOwqOZT 4R3UpTz8S989x7t5qoj6c79KwEgT/iijSVTWFCJir8ZzAdq1TYcsivXmocgsxHElw8lk N9Y3zPi5II+tlgKw9VYsXnBrt+74BMBQpPn9v5tLk4NYrzhn1bkpQfW78QB4Mw7tCBcm sm/A==
X-Gm-Message-State: AN3rC/4C29EGvzSCYeqx1qxTF6Zhf5jGcdUEisuKEx2Ij/pM1/ixm2Y9 6PqhlcogQ9r4CQKubqdQD3WHv488mw==
X-Received: by 10.37.64.20 with SMTP id n20mr39460585yba.39.1493979336147; Fri, 05 May 2017 03:15:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.21.65 with HTTP; Fri, 5 May 2017 03:15:35 -0700 (PDT)
In-Reply-To: <CADPMZDAgByY+ULK-OvxdyNrNF123Q0cZN-xjn2e4oFXT+WprJw@mail.gmail.com>
References: <CADZyTkkd-JpsE89z=P10Y0esc1NCZydD5NqMTs8E5xUz-DMT_g@mail.gmail.com> <58F475B5.4090504@roumenpetrov.info> <CADPMZDBjgpzMKp1UJqWMC_xRZpfce=wOOsE51HwY2dEO73kKeA@mail.gmail.com> <CADPMZDBS3yFxWmioNRV+Vx-ThTPW636ydr1fz76vNP52DjAtZA@mail.gmail.com> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> <CADZyTknNkAWHUeqk-BQqYU_6jTGVgPurhqF7=Am7Xk7OT=D-gQ@mail.gmail.com> <CADZyTk=3pZb40upVHPuG8hYEWOCpu2hhdyBpiZ9t5+v2_AYzAQ@mail.gmail.com> <590A2FA0.3070601@roumenpetrov.info> <CADZyTknVERTsAWeU-Gk92_25JvK9otQ_9PLY=m19XM-eVH-efQ@mail.gmail.com> <590ABDAD.6000900@roumenpetrov.info> <CADPMZDB0+SdzYvMEaREHDK1C9dm+TcfehVatVtF8MMah92813A@mail.gmail.com> <590B7E60.8000204@roumenpetrov.info> <CADPMZDCY2gduQ5vGG9DhbnjdhHFOZw0H-xFDs8fu07Pj+nqVPQ@mail.gmail.com> <CADPMZDAgByY+ULK-OvxdyNrNF123Q0cZN-xjn2e4oFXT+WprJw@mail.gmail.com>
From: denis bider <denisbider.ietf@gmail.com>
Date: Fri, 05 May 2017 04:15:35 -0600
Message-ID: <CADPMZDCLiFPJtL0rERT9EA3uvJtL5GifO9pAsU0Me5JiTYzFdA@mail.gmail.com>
To: curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c029b2a232b2054ec42b1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/LcdacY8DtYwuCqOoJ5Gjawcyo48>
Subject: Re: [Curdle] WG status and rsa-sha2 as public key algorithm
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 05 May 2017 10:15:39 -0000

Talking to Roumen off-list to gain a better understanding of his
implementation, and why it has trouble dealing with "server-sig-algs" sent
by OpenSSH versions before 7.5. Our implementation does not have trouble.
His implementation might though, perhaps due to different combinations of
supported algorithms, and/or a different design approach. Trying to
understand this better. Will post when I do.

On Fri, May 5, 2017 at 12:18 AM, denis bider <denisbider.ietf@gmail.com>
wrote:

> 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
> compatibility.
>
> - Breaking compatibility with existing implementations requires a
> substantive reason. I am currently not aware of a substantive reason to do
> this.
>
> - 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
> comparison:
>
> http://ssh-comparison.quendi.de/comparison/hostkey.html
>
> ... 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 <denisbider.ietf@gmail.com>
> wrote:
>
>> > 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, Румен Петров <pkixssh@roumenpetrov.info>
>> 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
>>> Curdle@ietf.org
>>> https://www.ietf.org/mailman/listinfo/curdle
>>>
>>
>>
>