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

[denis bider <[e-mail]>]

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 <[e-mail]>
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, Румен Петров <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/curdle
>>
>
>