[EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters

[Christoph Anton Mitterer]

On Tue, 2014-10-21 at 21:15 +0000, Christian Weisgerber wrote: 
> > Why is there never a step, in which the server S somehow verifies that e
> > actually comes from C (i.e. authenticating C)?
> That's just the overall protocol design.  There is no client
> authentication at this stage, only server authentication.
> Client authentication happens in the SSH authentication protocol
> https://tools.ietf.org/html/rfc4252
> Typical client authentication relies on the user's public key or
> password.  What would be gained by authenticating the client's host?

I rather wondered here, how one defends against Mallory at this stage of
the DH handshake... but it's probably enough to check at either client
or server side that e respectively f is from the authenticated Alice or
Bob, in order to prevent MitM, right?
Cause already if one side notices the attack, the handshake won't
complete.


> > Wouldn't it be nice to have an option to set min/pref/max?
> No.
Well why not?
There what's the current value for min/max?
#define DH_GRP_MIN      1024
#define DH_GRP_MAX      8192

Right?
When you go for the ECRYPT II estimations, 1024 is only enough for the
very short term.
Of course an "evil" server can just always publish your data, stronger
DH params or not... but I think the question is mainly about avoiding
"accidental" weak defaults.

And 8192 is at least to small for the forseeable future. Now I
understand that there is this limit from the RFC, but AFAICS this is
only a suggested limit and not a hard one, isn't it?


> What is your attack scenario here?  If the server can't be trusted,
> your session isn't protected.  That is trivial.
See above: it's all about simple checks against weak defaults.
If this wouldn't make sense, then one could also set min=0 and simply
blindly trust the server.

> Hey, the server might accidentally use a weak random number generator.
> That isn't even hypothetical.
Sure, but that's nothing we could check.

Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20141024/57d32b14/attachment-0001.bin>