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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
