Re: DH Group Exchange in SSH (RFC 4419) - Avoiding Backsdoors
"Mark D. Baushke" <[email protected]>
| Newsgroups | gmane.ietf.curdle,gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
Hi Damien, Damien Miller <[email protected]> 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