On 09/22/2017 03:22 PM, Daniel Kahn Gillmor wrote:> On Thu 2017-09-21 18:12:44 -0400, Joseph S Testa II wrote: >> I gotta say... having a fallback mechanism here seems pretty >> strange. The entire point of the group exchange is to use a dynamic >> group and not a static one. > > fwiw, i think dynamic groups for DHE key exchange is intrinsically > problematic when there is any computational expense in validating the > quality of the group parameters.While some may agree with this, the fact remains that the current implementation isn't working as expected. I'm interested in correcting the behavior. - Joe
Joseph S Testa II <jtesta at positronsecurity.com> writes:> On 09/22/2017 03:22 PM, Daniel Kahn Gillmor wrote: > > On Thu 2017-09-21 18:12:44 -0400, Joseph S Testa II wrote: > >> I gotta say... having a fallback mechanism here seems pretty > >> strange. The entire point of the group exchange is to use a dynamic > >> group and not a static one. > > > > fwiw, i think dynamic groups for DHE key exchange is intrinsically > > problematic when there is any computational expense in validating the > > quality of the group parameters. > > While some may agree with this, the fact remains that the current > implementation isn't working as expected. I'm interested in > correcting the behavior.Hmmm... the OpenSSH 7.5 sources use this method for the fallback: DH * dh_new_group_fallback(int max) { debug3("%s: requested max size %d", __func__, max); if (max < 3072) { debug3("using 2k bit group 14"); return dh_new_group14(); } else if (max < 6144) { debug3("using 4k bit group 16"); return dh_new_group16(); } debug3("using 8k bit group 18"); return dh_new_group18(); } Group 14 == 2048-bit DH group. (Group 15 == 3072-bit DH group.) Group 16 == 4096-bit DH group. (Group 17 == 6144-bit DH group.) Group 18 == 8192-bit DH group. I suppose you want to be more paranoid: DH * dh_new_group_fallback(int max) { debug3("%s: requested max size %d", __func__, max); if (max <= 2048) { debug3("using 2k bit group 14"); return dh_new_group14(); } else if (max <= 4096) { debug3("using 4k bit group 16"); return dh_new_group16(); } debug3("using 8k bit group 18"); return dh_new_group18(); } If so, you should probably open a bug against the dh.c::dh_new_group_fallback() function. -- Mark
Do I understand correctly, that you find the security of group 14 unacceptable
and yet you left it enabled?
On 9/22/17, 2:01 PM, "openssh-unix-dev on behalf of Joseph S Testa II"
<openssh-unix-dev-bounces+tim.broberg=servicenow.com at mindrot.org on behalf
of jtesta at positronsecurity.com> wrote:
On 09/22/2017 03:22 PM, Daniel Kahn Gillmor wrote:
> On Thu 2017-09-21 18:12:44 -0400, Joseph S Testa II wrote:
>> I gotta say... having a fallback mechanism here seems pretty
>> strange. The entire point of the group exchange is to use a
dynamic
>> group and not a static one.
>
> fwiw, i think dynamic groups for DHE key exchange is intrinsically
> problematic when there is any computational expense in validating the
> quality of the group parameters.
While some may agree with this, the fact remains that the current
implementation isn't working as expected. I'm interested in
correcting
the behavior.
- Joe
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.mindrot.org_mailman_listinfo_openssh-2Dunix-2Ddev&d=DwICAg&c=Zok6nrOF6Fe0JtVEqKh3FEeUbToa1PtNBZf6G01cvEQ&r=WxtmI2HcpDF2j1UPw-tBSatMtcAHcEc-gP6FGr3XijQ&m=fMI3Ao0UH8hvwBTkGGtmUAcxESVoEIlJMnu_UFC59Ps&s=PAGa24VxwyFcJP8QGus43lSGYkGU6OpQ0k0o2TCOejs&e=
On 09/22/2017 06:10 PM, Mark D. Baushke wrote:
> I suppose you want to be more paranoid:
>
> DH *
> dh_new_group_fallback(int max)
> {
> debug3("%s: requested max size %d", __func__, max);
> if (max <= 2048) {
> debug3("using 2k bit group 14");
> return dh_new_group14();
> } else if (max <= 4096) {
> debug3("using 4k bit group 16");
> return dh_new_group16();
> }
> debug3("using 8k bit group 18");
> return dh_new_group18();
> }
This wouldn't fix the underlying issue. I'm interested in having the
code respect the admin's wishes. If the admin edits out entries in
/etc/ssh/moduli, the server should follow that 100%, and not sometimes
make decisions on its own, against what the admin told it point-blank.
Both the existing code, and the above change results in unexpected behavior.
It seems like removing the fallback mechanism entirely is the way to go.
If the server and client can't agree on a group-exchange, then the
attempt should fail. And after all, the client is free to try again
with another kex.
FYI, the OpenSSH client (v6.6) in Linux Mint 17 (which is a couple years
old) requests a range of 1024 - 8192 bits by default. I can look into
what PuTTY does, if anyone is interested. I strongly suspect, though,
that modern clients aren't going to be impacted by removing the fallback.
- Joe
On 09/22/2017 06:55 PM, Tim Broberg wrote:> Do I understand correctly, that you find the security of group 14 unacceptable and yet you left it enabled?In the end, I'm trying to ensure a minimum equivalent of 128-bits of security. Group14 is 2048-bits, which roughly translates to 112-bits. [1] To this end, I disabled the "diffie-hellman-group14-sha1" and "diffie-hellman-group14-sha256" kex algorithms, but the problem is that the group exchange "diffie-hellman-group-exchange-sha256" is not respecting the admin's wishes, and falls back to group14, even when specifically told not to (by the admin removing 2048-bit groups in /etc/ssh/moduli). There's currently no way to ensure 100% that 2048-bit DH is disabled. - Joe [1] See NIST Special Publication 800-57, Part 1, Revision 4, p. 53, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf>.
I wish to withdraw my suggested patch to dh.c as what OpenSSH is using for falling back to a value related to the client max is correct for some flavors of that concept. That said, I suspect what Joe wants is for the max provided by the client to be advisory such that the minimum value provided by the moduli file would be used if the client max is smaller than that value. That is, if the client sent min=1024,n=1024,max=1025 and the minimum modulus in the moduli file was min_moduli=3072bits, that the client max value be ignored in favor of using the MAX(max,min_moduli). In this way, the adinistrator that no longer wanted to support 2048 bit group14 for clients would be able to support a 3072-bit minimum to be sent for the client. Is this what you wanted to address Joe? I would have no objection to such a patch for OpenSSH. -- Mark
On 09/24/2017 11:13 PM, Mark D. Baushke wrote:> I wish to withdraw my suggested patch to dh.c as what OpenSSH is using > for falling back to a value related to the client max is correct for > some flavors of that concept. > > That said, I suspect what Joe wants is for the max provided by the > client to be advisory such that the minimum value provided by the moduli > file would be used if the client max is smaller than that value. > > That is, if the client sent min=1024,n=1024,max=1025 and the minimum > modulus in the moduli file was min_moduli=3072bits, that the client max > value be ignored in favor of using the MAX(max,min_moduli). In this way, > the adinistrator that no longer wanted to support 2048 bit group14 for > clients would be able to support a 3072-bit minimum to be sent for the > client. > > Is this what you wanted to address Joe?Sure, that's one way to handle it. As I mentioned in my reply to djm, the server can either disconnect or just send the 3072-bit modulus and let the client decide what it wants to do. I don't feel too strongly about either option, as long as the end result is the code respects the admin's decision on minimum modulus sizes to use. That's my main concern.> I would have no objection to such a patch for OpenSSH. > > -- Mark