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.> OpenSSH 6.6 was first released on October 6, 2014.I brought up v6.6 to give an example that older clients wouldn't be impacted by the removal of the fallback mechanism.> You should also take a closer look at RFC 4419. I believe you will find > that returning the biggest prime the SSH daemon knows which is larger > than the requested prime is correct. Even if it is not necessarily in > the moduli file.Section 3 says: "The server should return the smallest group it knows that is larger than the size the client requested." Even though my system has values in /etc/ssh/moduli that are 3072-bits all the way up to 8192-bits, its still returning group14. I suppose with a loose interpretation, you could say OpenSSH is still adhering to the spec, since, technically, it does know about group14... 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. Written in March 2006, RFC 4419 also says "Servers and clients SHOULD support groups with a modulus length of k bits, where 1024 <= k <= 8192." Hence, removing this fallback mechanism "SHOULDN'T" be a problem, as clients have been encouraged for 11+ years to support groups up to 8192-bit. It strongly appears that the code can be reasonably changed to return the smallest group it knows (i.e.: the smallest value in /etc/ssh/moduli), without causing significant interoperability problems. Motion to remove the group-exchange fallback mechanism entirely. - Joe P.S. I volunteer to write the patch if this change would be accepted.
[+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
On 25 September 2017 at 02:32, Mark D. Baushke <mdb at juniper.net> wrote:> [+CC Loganaden Velvindron <logan at hackers.mu>] primary author of > the RFC 4419 refresh draft.https://datatracker.ietf.org/doc/draft-lvelvindron-curdle-dh-group-exchange/ ? Tangent: has any consideration been given to increasing the maximum allowed beyond 8192 bits (which is below the current NIST recommendation for 256 bits of security)? Last time I looked OpenSSL supported 10k bits out of the box so it probably wouldn't be hard to support that in OpenSSH. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On 09/24/2017 12:32 PM, Mark D. Baushke wrote:> 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)?Option A. Maybe option C would be to call fatal(), so as to draw the admin's attention immediately. Or perhaps that's too extreme. I don't have a strong opinion between A and C.> 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.Admins have the option of using pre-defined DH groups already, like "diffie-hellman-group14-sha256", "diffie-hellman-group16-sha512", etc. If they want a static group, then they should use those. However, admins that want dynamic groups have a reasonable expectation that "diffie-hellman-group-exchange-sha256" actually uses them. To me, this seems like the entire point of this group. - Joe