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... _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
