Re: SSH key algorithm updates

Jeffrey Hutzelman <[email protected]> writes:

> To summarize the changes, I propose:

I think this makes sense. I've been a bit out of the loop for this, wit
lsh being a mostly dormant project, but I'd like to offer my comments.
My apologies if I misremember some relevant details.

> For public key algorithms:
> - Downgrade ssh-dss, pgp-sign-dss, and x509v3-ssh-dss to NOT
> RECOMMENDED.
> - Upgrade ssh-rsa to REQUIRED

ssh-rsa is sha1 only, right? It's still stronger than ssh-dss (since it
allows larger keys), so if we want a widely deployed algorithm to
replace ssh-dss as REQUIRED, it makes sense. But defining ssh-sha256-rsa
as RECOMMENDED would make sense too.

And when it comes to sha1 weaknesses, using sha1 with a signature
algorithm seems more dangerous than using it for hmac or for key
expansion.

> - Upgrade ecdsa-sha2-* to RECOMMENDED
> - Add dsa-sha2-256 as RECOMMENDED

I have no strong opinion on whether these should be recommended or
optional. I think there are quite strong reasons to prefer deterministic
algorithms, but that's more a question of a recommendation for the
implementation, since it's not really visible on the wire what method
was used to produce the nonce.

> For MAC algorithms:
> - Upgrade hmac-sha2-256 to REQUIRED
> - Consider upgrading hmac-sha2-512 to RECOMMENDED
> - Downgrade hmac-md5 and hmac-md5-96 to NOT RECOMMENDED
> - Downgrade hmac-sha1-96 to NOT RECOMMENDED
> - Consider downgrading hmac-sha1 to RECOMMENDED
>
> HMAC-SHA1 is not (yet) considered insecure, it has been SSHv2's only
> required algorithm since RFC 425x were published, and it is probably the
> most widely deployed.  So, we should not downgrade it below RECOMMENDED.
> However, I think a case can be made for hmac-sha2-256 replacing it as
> the REQUIRED algorithm, if we think that has gained enough traction.

My understanding is that there are no known attacks on hmac-sha1, and
that the attacks on non-keyed hashfunctions in the family don't apply.
Is there any likely harm in keeping it as required for another decade?

> For encryption algorithms:
> - Upgrade aes128-ctr to REQUIRED
> - Consider downgrading 3des-cbc to RECOMMENDED
> - Downgrade all other *-cbc algorithms to NOT RECOMMENDED
> - Do we want to say anything about IDEA, CAST, or RC4?

The last 3 seem fairly irrelevant now. We could specify salsa20 or
chacha, to replace rc4 for high-performance use-cases.

> I chose aes128-ctr because RFC4253 listed aes128-cbc as
> RECOMMENDED while leaving the other sizes OPTIONAL.  I suspect this was
> done because at the time, some folks did not want to ship AES256 due to
> export restrictions and/or lack of utility.

What about the key-setup problems in aes256? I seem to recall that it's
not as much better than aes128 as was intended.

> We may wish to consider leaving 3des-cbc at SHOULD,

I think that makes sense, if the main problem with 3des is performance
rather than security.

> Finally, for key exchange algorithms:
> - Upgrade diffie-hellman-group-exchange-sha256 to REQUIRED
> - Upgrade ecdh-sha2-* to RECOMMENDED
> - Consider downgrading diffie-hellman-group14-sha1 to RECOMMENDED
> - Downgrade other diffie-hellman-*-sha1 to NOT RECOMMENDED
> - Downgrade rsa1024-sha1 to NOT RECOMMENDED

> Again, eliminating the SHA1-based DH algorithms in favor of GEX SHA256
> should be obvious,

I don't think choosing group-exchange is obvious; using a fixed group is
an obvious gain in terms of simplicity. Personally, I don't quite like
the complexity and validation issues with group-exchange (but maybe I
could be convinced it's no problem). So I hesitate to make it the
reqiured algorithm.

Why don't you like diffie-hellman-group14-sha1 as required? Is that group
considered too small these days, or is sha1 considered too weak for this
use?

To me it would make sense to also define diffie-hellman-group14-sha256 and/or
diffie-hellman-curve25519, but they can't be candidates for required  at
this time.

>> Or, is this better left to another RFC? Perhaps moving the Ed25519
>> algorithm created by
>> 
>>   https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 
>> 
>> into a MUST algorithm while deprecating "ssh-dss" for SSH?
>
> That's an unfinished, -00 version internet draft from CFRG. 

Is that related to the (now expireed, I think) draft I and Simon wrote
some time ago? I'm not following the cfrg work.

I think it would also be highly desirable to standardize use of
aead-algorithms. But as far as I remember, from last time this was
discussed, it was tricky to extend the algorithm negotiation in a clean
way. (And I'd like to do chacha-poly1305 sligthly different from the way
openssh does it, but we can get to that in due time).

So specifying AEAD is a different and harder problem than just updating
the list of recommended algorithms.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.