openssh unix dev - Oct 2014 - [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters

Hey.

AFAIU, all the key exchange algorithms in SSH (or perhaps better said
OpenSSH, since the RFCs would allow for MQV) are basically
Diffie-Hellman based[0]. Or the ECC versions (the ECDH versions with
NIST curves or curve25519).


1) I guess ALL these are ephemeral versions of DH/ECDC, in order to get
FS/PFS, right?

Just out of curiosity,... what is done to make the the DH authenticated?
I guess it depends on the chosen HostKeyAlogrithm (so either RSA, DSS,
ECDSA or EdDSA)... but do client/server exchange the DH parameters
signed or doe they exchange a signed version of the agreed key?




2) Now the security of DH/ECDH obviously depends on the parameters, e.g.
having a 16 bit DH group makes it useless....

AFAIU for diffie-hellman-group1-sha1 anddiffie-hellman-group14-sha1 and
the parameters are fixed (with 1024 and 2048 bit groups)

The same for the the four ECDH versions (ecdh-sha2-nistp* and
curve25519-sha256 at libssh.org), they all have fixed values

So if I'd find that to be too weak, then the only thing one could do is
disable those, right?


But for the diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256 the /etc/ssh/moduli file is used to
find parameters, right?

a) Documentations seems to imply that this is only used by sshd?
So how does the ssh client come to his accepted parameters? Does he
simply take anything a SSH server proposes?

b) How can I restrict what the server accepts as parameters?
E.g. if I think 1024 bit groups are to weak, can I simply remove those
entries from the moduli file and such groups will no longer be used?

c) How can I do the same for the client?



Thanks,
Chris.


[0] diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,
diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
curve25519-sha256 at libssh.org
-------------- 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/20141018/930b4b3e/attachment.bin>

On 2014-10-18, Christoph Anton Mitterer <calestyo at scientia.net> wrote:
> 1) I guess ALL these are ephemeral versions of DH/ECDC, in order to get
> FS/PFS, right?
Yes.
> Just out of curiosity,... what is done to make the the DH authenticated?
> I guess it depends on the chosen HostKeyAlogrithm (so either RSA, DSS,
> ECDSA or EdDSA)... but do client/server exchange the DH parameters
> signed or doe they exchange a signed version of the agreed key?
https://tools.ietf.org/html/rfc4253#section-8
> AFAIU for diffie-hellman-group1-sha1 anddiffie-hellman-group14-sha1 and
> the parameters are fixed (with 1024 and 2048 bit groups)
>
> The same for the the four ECDH versions (ecdh-sha2-nistp* and
> curve25519-sha256 at libssh.org), they all have fixed values
>
> So if I'd find that to be too weak, then the only thing one could do is
> disable those, right?
Right.
> But for the diffie-hellman-group-exchange-sha1
> diffie-hellman-group-exchange-sha256 the /etc/ssh/moduli file is used to
> find parameters, right?
>
> a) Documentations seems to imply that this is only used by sshd?
> So how does the ssh client come to his accepted parameters? Does he
> simply take anything a SSH server proposes?
The client sends the minimal/preferred/maximal group size, and the
server picks a group and responds with the modulus and generator
for the group.
https://tools.ietf.org/html/rfc4419
> b) How can I restrict what the server accepts as parameters?
> E.g. if I think 1024 bit groups are to weak, can I simply remove those
> entries from the moduli file and such groups will no longer be used?
If the server doesn't find (a suitable group in) /etc/moduli, it
will fall back to the group from diffie-hellman-group14-sha1.

The elliptic curve key exchanges have pretty much obsoleted the
Diffie-Hellman group exchange.

-- 
Christian "naddy" Weisgerber                          naddy at
mips.inka.de