Hi,
I'm interested in requiring a minimum of 3072-bit DH moduli when
using the "diffie-hellman-group-exchange-sha256" kex, so I edited my
/etc/ssh/moduli file such that only 3071+ moduli are left. However,
when clients ask for a max of 2048-bit moduli, they actually get one
(!). I poked around and found that a fallback mechanism exists
(dh.c:185), which returns back the fixed group14 Group in that case
(dh.c:441).
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. Otherwise, the admin would have chosen to
use "diffie-hellman-group[14,16,18]-sha256". Letting the kex fail
when
clients ask for groups that the admin disabled would be the correct
behavior.
To be clear, this would involve removing the fallback mechanism
entirely. I can submit a patch to do this, if others agree. Otherwise,
what would be a better approach?
Thanks,
- Joe
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. The party receiving the group is basically at the mercy of the party proposing the group -- they hope that they've done something sensible, because no client is going to try to do things like an expensive primality test on a large integer that they just received. Sticking to the standard groups -- large size, well-vetted, with publicly-published primality proofs for finite-field moduli, and generated with a minimal amount of wiggle-room for malicious creation (aka "nothing up my sleeve", "NUMS", or "safecurves") values are the way to go. they're (marginally) easier on the bandwidth too, because you can just pick one from a table that's already well-known, and you don't have to transmit the large group in addition to the public share. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170922/80506efe/attachment.asc>
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
On Thu, 21 Sep 2017, Joseph S Testa II wrote:> Hi, > > I'm interested in requiring a minimum of 3072-bit DH moduli when using the > "diffie-hellman-group-exchange-sha256" kex, so I edited my /etc/ssh/moduli > file such that only 3071+ moduli are left. However, when clients ask for a > max of 2048-bit moduli, they actually get one (!). I poked around and found > that a fallback mechanism exists (dh.c:185), which returns back the fixed > group14 Group in that case (dh.c:441).What behaviour would you like for this case? We can't send a group that is larger than 2048, because the client has said that is the maxiumum that will accept. Would you prefer the server disconnect at that point? -d
On 25 September 2017 at 08:01, Damien Miller <djm at mindrot.org> wrote: [...]> What behaviour would you like for this case? We can't send a group that is > larger than 2048, because the client has said that is the maxiumum that > will accept. Would you prefer the server disconnect at that point?Maybe only offer group14 in dh-gex the fallback path if the group14 methods are in KexAlgorithms? -- 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 06:01 PM, Damien Miller wrote:> On Thu, 21 Sep 2017, Joseph S Testa II wrote: > >> Hi, >> >> I'm interested in requiring a minimum of 3072-bit DH moduli when using the >> "diffie-hellman-group-exchange-sha256" kex, so I edited my /etc/ssh/moduli >> file such that only 3071+ moduli are left. However, when clients ask for a >> max of 2048-bit moduli, they actually get one (!). I poked around and found >> that a fallback mechanism exists (dh.c:185), which returns back the fixed >> group14 Group in that case (dh.c:441). > > What behaviour would you like for this case? We can't send a group that is > larger than 2048, because the client has said that is the maxiumum that > will accept. Would you prefer the server disconnect at that point?Yeah, I suppose a disconnect would be the option that most closely follows RFC4419. Or the code could bend the rules, return the smallest modulus (3072-bit), and let the client decide if it wants to continue or not (or crash). I don't have a strong opinion on this part, personally. - Joe