DH group exchange (Re: SSH key algorithm updates)

[denis bider <[e-mail]>]

Some info on DH group exchange that one might find useful:

- Our SSH Server does not generate groups. It just gives the client group14, or else group1 if client’s max size is below group14.

- Our SSH Client cannot reliably digest broken groups generated by most implementations that actually generate groups on the fly.

The Client (and Server, but this is not a problem in the Server) uses a FIPS-compliant crypto provider (Crypto++ 5.3.0) which performs DH parameter validation that cannot be disabled. This validation fails on DH parameters with groups generated by most server implementations (including but not limited to OpenSSH). It is possible to connect, but with something like 50% chance of failure.

Since we cannot disable the DH parameter validation without compromising the FIPS module, the Client de-prioritizes DH-gex methods in favor of any other enabled key exchange method (by default ecdh, dh-group14).

So, yes. From our point of view:

>  I was thinking of the receiver of the group list,
> it has to be prepared to handle any group,
> and make an intelligent choice. My gut
> feeling is that there may be some subtleties there.

... there are indeed such "subtleties". :)

It is a fairly substantial problem that most dynamically generated groups aren't usable with our FIPS module.


----- Original Message -----
From: Niels "Möller" 
Sent: Friday, November 6, 2015 00:50
To: Jeffrey Hutzelman 
Cc: Mark D. Baushke ; denis bider ; [e-mail] ; [e-mail] ; [e-mail] 
Subject: Re: SSH key algorithm updates

Jeffrey Hutzelman <[e-mail]> writes:

> On Fri, 2015-11-06 at 06:16 +0100, Niels Möller wrote:

[about hmac-sha1]

> Your understanding matches mine.  However, it's still only a 160-bit
> hash, and eventually that just stops being strong enough.  I'd like to
> have something stronger implemented and reasonably widely deployed
> before then.

Reasonable. We need to specify a new REQUIRED algorithm. Demoting
HMAC-SHA1 to recommended lets implementations drop support in due time
without formally departing from the standard. It would kind-of make
sense to specify a flag day "algothithm X is REQUIRED until date Y,
after which is is only RECOMMENDED", but not worth the effort to
formalize.

> SSH's 3des-cbc is three-key EDE 3DES.  It has an effective key length of
> 112 bits, and so is weaker than AES128.

But the "effective key bits" attack is a time/memory-tradeoff which
requires a huge table, right? So in practice I'm not sure a brute force
attack on 3DES really can be expected to be 16 times faster than a brute
force attack on aes128.

> It's also a CBC mode and AFAIK has the same problems as all of SSH's
> other CBC-mode ciphers.

Right, reprecating CBC makes sense. What's the status of 3des-ctr mode?
Not at all as widely deployed as 3des-cbc, I imagine.

> Group exchange doesn't have to mean live, dynamic group generation.  It
> can work fine with a set of fixed groups, either manually configured or
> compiled in.  

Hmm. I was thinking of the receiver of the group list, it has to be
prepared to handle any group, and make an intelligent choice. My gut
feeling is that there may be some subtleties there. But maybe there's no
issue to trust the server and just choose the largest group you think
you can afford to compute with.

> I'd have to go back and look, but I think the sense of the
> group at the time was that there was no reason to define more variations
> with the group baked into the algorithm names.

I can see that argument. Perhaps we shouldn't get into that now, but I
could see scenarious where client might have a preference like

  1. Large Z_p group (preferred option)
  2. curve25519      (acceptable)
  3. Small Z_p group (not acceptable)

Then negotiation fails in the case that they agree on group exchange,
but the server offers only small Z_p groups. While with named groups,
they might have agreed to use curve25519.

Feel free to ignore this discussion if you find in untimely or
distracting. There's a spec for it and noone on the list have raised any
serious security concerns.

>> Is that related to the (now expireed, I think) draft I and Simon wrote
>> some time ago? I'm not following the cfrg work.
>
> I'm not sure.  It's only a month old, and does have Simon's name on it.

Hmm. It looks like like it's based on our earlier version. I think the python
reference implementation of ed25519 is the same. Nice.

Regards,
/Niels


-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.