Re: SSH key algorithm updates

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Fri, 2015-11-06 at 06:16 +0100, Niels Möller wrote:


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

Agreed.



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

Your understanding matches mine.  However, it's still only a 160-bit
hash, and eventually that just stops being strong enough.  I'd like to
have something stronger implemented and reasonably widely deployed
before then.

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

Oh, hm; that may be the case.  


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

SSH's 3des-cbc is three-key EDE 3DES.  It has an effective key length of
112 bits, and so is weaker than AES128.  It's also a CBC mode and AFAIK
has the same problems as all of SSH's other CBC-mode ciphers.  So, the
main reason to deprecate it is indeed security.  The main reason _not_
to do so is interop, particularly with old things.


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

Group exchange doesn't have to mean live, dynamic group generation.  It
can work fine with a set of fixed groups, either manually configured or
compiled in.  I'd have to go back and look, but I think the sense of the
group at the time was that there was no reason to define more variations
with the group baked into the algorithm names.

In any case, there's a spec for SHA256 with group exchange, but not with
fixed groups.  So if we want to go that route, we have to specify new
algorithms and wait for them to be supported.



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

The latter, at least.  The SHA1 here is used to compute the exchange
hash, which is signed to authenticate the key exchange process and bind
it to the host's public key.  It's also used to derive the session keys.
I'm not sure what current thinking is about use of SHA1 for key
derivation, but for non-HMAC authentication it's definitely no longer
sufficient.


> >> 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'm not sure.  It's only a month old, and does have Simon's name on it.


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

Yup.