Hello all,
I have recently had cause to dig a little into the specifics of how
diffie-hellman-group-exchange-sha256 group sizes work.
The belief in the wild, perpetuated by multiple sources of logjam
mediation papers and also Andras Stribnik's very influential piece
"Secure Secure Shell", is that server operators can force the use of a
minimum group size by removing moduli smaller than that group size from
the file pointed to by ModuliFile. I was very surprised to learn this
isn't the case. OpenSSH will happily (and almost silently) default to
using canned moduli if it doesn't find one less than the client's sent
MAX. I am hoping to convince devs of the usefulness of changing this
behaviour so that a server will refuse to complete a KEX with a client
if a generated modulus doesn't exist.
I think it is reasonable that server operators can set minimum KEX
standards. With a KEX like diffie-hellman-group-exchange-sha256, which
is inherently variable, there is currently no way for a server operator
to do this. Vanilla DH is actually becoming more attractive, after the
rush to abandon it post logjam, since vanilla Diffie Hellman is far
(many orders of magnitude) more resistant to quantum attack than ECC.
In fact, for even modest key sizes, the quantum gate requirement for
Vanilla DH will likely always be out of reach, making vanilla DH
essentially itself a post-quantum algorithm.
I would like to advocate for:
- Change behaviour of the server to allow server operators to set the
minimum modulus group size allowable for a connection using
diffie-hellman-group-exchange-sha256
Whether this is by having the server refuse to allow smaller moduli to
be used than exist in ModuliFile, or another explicit configuration
setting is added, it doesn't matter
- Modernize DH_GRP_MAX to >= 16384. The current value is based on
pre-quantum recommendations (and it is stated only as a recommendation)
in an 18-year-old RFC (4416)
- Modernize the client to allow explicit setting of its MIN, REQUESTED,
and MAX group sizes
For your consideration.
Kurt Fitzner
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
