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

[denis bider <ietf-ssh3%denisbider.com@localhost>]

Damien:


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

I have done so for the -03 version of the draft.


> 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.

It's the only way to allow existing, good RSA host keys and fingerprints to continue to be used.

If we change the key format, it requires users to re-do their host key and client key setups in order to use the new signature methods. In my experience, this is the one thing that costs users the most, and which they most want to avoid. They'll avoid the new format if it comes at the cost of re-keying. It would mean adoption would be pushed several years down the road.

Furthermore, transition to any other signature format - like from SHA-256 to SHA-512, or from SHA-2 to SHA-3 - would then mean paying this whole cost again, and again when the same keys could be used.

If we decouple the key type from signature type:
- adoption can happen faster, since the new signatures are compatible with existing keys
- the same keys can also be used if we want to migrate to SHA-2 512 or SHA-3

It took me a few days to implement this decoupling for Bitvise SSH Server and Client. Not too hard.


> 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.

There haven't been any other formats besides PSS and PKCS#1 v1.5 for a couple decades.

I'm proposing is to migrate to PSS for the reasons explained in my message dedicated to that.

If we settle on PSS, I think anyone who wants to use PKCS#1 v1.5, perhaps because they're lazy, should carry the shame of naming "pkcs1v15" in their signature format. 

If we decide on PSS, I think it should be implicitly baked in.

The signature format that's more desirable for the community should have the nicer / more default looking name, I think. Unless we must disambiguate from something previously existing.

We don't have to disambiguate from something that does not exist yet.


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

RFC 6187 goes so far as to put "2048" in the algorithm name.

I have decided against that because it's totally arbitrary and a matter of policy. We don't currently have "ssh-rsa-1024", even though that was the previous de facto minimum key size.

The next version of our SSH Server will have a setting which will allow a server-wide minimum size for RSA keys. This will be set to 2048 bits for new installations by default.

However, I don't see the need to hardcode this in an algorithm name. The Security Considerations section does already strongly suggest 2048-bit keys, or larger.


> 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.

It seems to me that SSH needs a proper extension mechanism to avoid version-string-based hacks and other kinds of hacks.

"publickey2" is not that much simpler to deploy. It requires changes to existing implementations, like EXT_INFO does. But it has none of the benefits:

- Does not solve the general problem of SSH protocol extension and feature discovery.
- Has a flat cost of an additional round-trip due to SERVICE_REQUEST and SERVICE_ACCEPT.
- Does not make signature algorithm information available in time for the client's first user auth request. This costs a round-trip if the client's first guess is incorrect.

I think it makes sense to expand the "server-sig-algs" extension to "auth-info", and include "methods that can continue" as part of that. This should avoid the need for clients to send "none", which adds yet an additional round-trip.

I have made this change for the next draft version.


----- Original Message -----
From: Damien Miller 
Sent: Tuesday, November 10, 2015 02:18
To: denis bider 
Cc: ietf-ssh%netbsd.org@localhost ; Jeffrey Hutzelman ; NielsMöller ; Mark D. Baushke ; stephen.farrell%cs.tcd.ie@localhost ; jon%siliconcircus.com@localhost ; Peter Gutmann ; Max Horn 
Subject: 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