Re: DH Group Exchange in SSH (RFC 4419) - Avoiding Backsdoors

["Mark D. Baushke" <mdb%juniper.net@localhost>]

Hi Damien,

Damien Miller <djm%mindrot.org@localhost> writes:

> On Thu, 29 Sep 2016, Mark D. Baushke wrote:

> > Question:
> > 
> > Should RFC 4419 - "Diffie-Hellman Group Exchange for the Secure Shell
> > (SSH) Transport Layer Protocol" be deprecated?
> > 
> > Background:
> > 
> > The paper "How to Backdoor Diffie-Hellman" by David Wong
> > https://eprint.iacr.org/2016/644.pdf describes two ways
> > of creating a Nobody-But-Us (NOBUS) Diffie-Hellman backdoor:
> 
> NOBUS backdoors aren't the only concern; another motivation was
> logjam-style precomputation attacks.

Yes, the creation of a new set of DH parameters allows us to avoid
logjam precomputation attacks against a well known set of DH groups.

That said, with NOBUS, how is an SSH client able to identify improper
ephemeral DH parameters that have been intesionally weakened?

Had RFC4419 sent all three of p,q,g to the client, then the client would
may have been able to do more validity checks.

However, RFC 4419 does NOT send q AND the methods to select g as given
in the RFC is not always going to generate a q-orded subgroup of p. 

If g is not able to generate a proper q-ordered subgroup value, then
concerns of NOBUS arise and in turn means that an attacker may be able
to learn the parity of the secret (thus losing only) one bit of
security. However, a misconfigured g could also be an indication that
there is a NOBUS DH backdoor in the server connection.

Moving to the MODP group16 for DH key exchange reduces the ability for a
full precomputation logjam type attack.

So, I am asking if it is time to deprecate the RFC 4419 kex methods.

Failing that, what may be done to enhance a RFC4419bis to handle both
logjam and NOBUS attack vectors?

	Thanks,
	-- Mark