[EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters

[Damien Miller]

On Thu, 23 Oct 2014, Daniel Kahn Gillmor wrote:

> For weaknesses that are detectable by the client, it does make sense
> that the client should be willing to detect and abort the session
> before compromising it.
>
> We already allow clients to constrain the set of choosable ciphers,
> for example, so clients who talk to a misconfigured/old/busted server
> that tries to select arcfour can reject the connection. It's not
> implausible that a client would also want to reject a server that
> offers an obviously non-prime DH modulus,

Checking for trivially non-prime is easy and maybe worthwhile to catch
broken implementations, but IMO there's little point when "subtly
non-prime" is still too expensive for the client to check - even a
few Miller-Rabin checks are too slow at the prime sizes required for
reasonable security in modp groups. Moreover, there are many, many ways
for an evil server to compromise the connection that are completely
undetectable (e.g. leak an encrypted copy of the server's PRNG key in
the KEXINIT cookie field).

I'd rather people use one of the EC DH modes - they are waaay faster
for the same security level.

> or a server's ephemeral DH public key if it is clearly bad (e.g. p-1
> or 1).

dh.c:dh_pub_is_valid() does this for modp values
sshkey.c:sshkey_ec_validate_public() does it for EC values (which AFAIK
are more sensitive for the NIST curve types)

-d

PS. it's amusing to see similar paranoia that motivated DH-GEX echoed in
the recent criticism of the NIST EC groups...