IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation



On Sun, 8 Nov 2015, denis bider wrote:

> (1) I have uploaded a new version of the RSA SHA-2 draft:
> 
> https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02

Some feedback on the draft:

> 1.  Overview and Rationale

The DSA bits in here don't seem very relevant. Could I suggest ditching
them or putting them in an appendix?

>   All aspects of the "ssh-rsa" format are kept, including the encoded
>   string "ssh-rsa", in order to allow users' existing RSA keys to be
>   used with the new signature formats, without requiring re-encoding,
>   or affecting already trusted key fingerprints.

I can see the argument for keeping "ssh-rsa" as the key name and
another name for the revised signature format. I'm not entirely sure
about it, I guess because I'm used to there being an identity between
key types and signature types in the SSH protocol.

> 3.  Discovery of signature algorithms supported by servers
> 
>   When a public key format can use multiple signature algorithms, it can
>   be useful for a mechanism to exist which a client can use to discover
>   signature algorithms accepted by a server for user authentication
>   without resorting to trial and error in authentication requests.
> 
>   Such a mechanism is defined in [SSH-EXT-INFO], which describes general
>   purpose extension negotiation for SSH, and specifies discovery of
>   signature algorithms as a usage case.

IMO a "publickey2" (or somesuch) method that included a custom failure
message to list the supported key types seems like a better way to offer
this.

>     Public Key Algorithm Name      Reference          Note
>     rsa-sha2-256                   [this document]    Section 2
>     rsa-sha2-512                   [this document]    Section 2

As mentioned in my other email, I don't feel super-strongly about
naming, but "rsa-pss-sha2-*" seems slightly more descriptive and
future-proof.

Is it worthwhile to specify a minimum key size for the new signature
schemes?

-d




Home | Main Index | Thread Index | Old Index