DH Group Exchange Fallback

Mark D. Baushke mdb at juniper.net
Mon Sep 25 02:32:51 AEST 2017


[+CC Loganaden Velvindron <logan at hackers.mu>] primary author of
the RFC 4419 refresh draft. The question, what should a conformant
RFC 4419 (or later) server do when the moduli requested by the
server is not available in the cached moduli file?

Joseph S Testa II <jtesta at positronsecurity.com> writes:

> On 09/24/2017 12:21 AM, Mark D. Baushke wrote:
> > I suggest you upgrade to a more recent edition of the OpenSSH software.
> > The most recent release is OpenSSH 7.5 and OpenSSH 7.6 will be released
> > very soon.
> 
> This problem is in v7.5 and v7.6.  See dh.c:436.

I agree that the current dh_new_group_fallack() is not providing
a DH group with at least max bits in it.

--- dh.c~	2017-04-02 08:46:42.000000000 -0700
+++ dh.c	2017-09-24 09:18:54.000000000 -0700
@@ -436,10 +436,10 @@
 dh_new_group_fallback(int max)
 {
 	debug3("%s: requested max size %d", __func__, max);
-	if (max < 3072) {
+	if (max <= 2048) {
 		debug3("using 2k bit group 14");
 		return dh_new_group14();
-	} else if (max < 6144) {
+	} else if (max <= 4096) {
 		debug3("using 4k bit group 16");
 		return dh_new_group16();
 	}

in this case, if you ask for a 3072-bit prime and all that the moduli
file has is 2048 bit primes, you would get a 4096-bit prime from the
server. Of course, if all that the moduli file had were 6144-bit primes
that might be the wrong thing to do as the asministrator my wish to
limit the primes being returned to 6144-bit values when anything smaller
is requested.

> However, my main point still stands.  The admin is unambiguously
> saying "ONLY use these groups", yet in some cases, the present code
> disregards this and unexpectedly does something else.

You point is fair, but you have not completely specified all of the
possible options.

> Motion to remove the group-exchange fallback mechanism entirely.

Please answer this question first:

Q1: If the moduli file is currently empty as in zero entries (apparently
the server has not yet populated it, or the administrator has truncated
the file to zero bytes). The server should do the following:

  a) Do not send the diffie-hellman-group-exchange-sha256 or
     diffie-hellman-group-exchange-sha1 option even if it is
     configured in the sshd_config file, or

  b) Send a DH group that it 'knows about' (be it group14, group16,
     group18, or some other DH group it has on hand)?

In my opinion, if the group exchange is configured in the sshd_config
file (or the default), I personally believe that if there is no entries
at all in the moduli file it should send a pre-defined DH MODP group
when there is no entry at all in the moduli file. I have no problems
with trying to send a DH moduli that closely matches the requested
value.

However, I do tend to agree with you that if there is one or more
entries in the moduli file, then one of those groups should be selected
rather than doing a fallback to a fixed group.

> P.S.  I volunteer to write the patch if this change would be accepted.

You should probably submit your bug report with your patch to the
OpenSSH bug tracking system in any case. However, I suggest you may
wish to also deal with my question above as well.

	-- Mark


More information about the openssh-unix-dev mailing list