RE: SSH key algorithm updates / Proposal and intent to implement "dsa-sha2-256" SSH key algorithm

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

Mark D. Baushke:

> Should this Draft RFC also be the one that moves the "ssh-dss"
> public key algorithm from a "REQUIRED" and "MUST" implement
> algorithm to an "OPTIONAL" and "SHOULD NOT" implement algorithm?

I very much agree this should be done. However, it seems to me a separate purpose which may require a different type of consensus.

It seems we could very much use Stephen's (offered) help with this.


> Perhaps moving the Ed25519 algorithm

FIPS does not approve of it, so there's a huge swath of 
products aimed for government that can't use the supposed "required" 
method.

It's also not easily available everywhere. Crypto++ doesn't have it. Windows CNG doesn't have it. There's DJB's original code, which is native code, and is not the most user friendly.

I think RSA might fit the "required" role better. It's old, solid, universally available, and acceptable to everyone. All it needs is an update to use SHA-2 as the hash.


Jeffrey Hutzelman:

> I don't understand. The issue with ssh-dss was that we _didn't_
> allow for larger key sizes. 

The issue is that there was no standard for larger key sizes at the time "ssh-dss" was defined. Consequently, few implementations existed that could handle them. None existed that were completely general.

If we "allow for" larger key sizes, then ALL implementations must be able to straightforwardly and correctly support them in advance. If they do not - and they will not, because they don't perceive the need at this time - then this creates future compatibility problems.

For example, if I use Windows CNG to implement this algorithm, I can only implement 2048-bit and 3072-bit key sizes. I can't provide an implementation compliant with a requirement to support larger keys. Any future users that might use larger sizes will run into compatibility issues with software I create now. This software may very well be still in use in 2020, even 2025. We still hear from users running 9 year old versions of our software. Users running 5 year old versions are common (perhaps even a majority).


>  In fact, now that I think about it, we probably should have
> defined an rsa-sha256 public key algorithm.

There's no time like today. We can define "rsa-sha2-256" right now.

Since RSA keys aren't themselves hash-dependent, we could grandfather in existing RSA keys, and keep "ssh-rsa" in the public key format. This retains existing host key fingerprints, and allows the same keys to be used for both "ssh-rsa" and "rsa-sha2-256". This vastly simplifies migration. We change the signature specification to use the new name, and to use SHA-2 256.

I believe this would further provide a credible signature algorithm that we could suggest "recommended" or "required". It seems to me that none of the other candidates are good matches:

- without deterministic signatures, DSA has its weakness to anything but perfect RNG
- EdDSA is not FIPS acceptable
- ECDSA over NIST curves is not acceptable to others
- The existing "ssh-rsa" uses SHA-1

However, if we define "rsa-sha2-256", however, we could mandate it as at "recommended" (or even "required").


> - Upgrade ssh-rsa to REQUIRED

Not sure about that. It uses SHA-1. We should probably define "rsa-sha2-256".