3des cipher and DH group size

[Hubert Kario]

----- Original Message -----
> From: "Damien Miller" <djm at mindrot.org>
> To: "Hubert Kario" <hkario at redhat.com>
> Cc: openssh-unix-dev at mindrot.org
> Sent: Tuesday, 4 February, 2014 11:42:31 PM
> Subject: Re: 3des cipher and DH group size
> 
> On Tue, 4 Feb 2014, Hubert Kario wrote:
> 
> > Hi all!
> > 
> > Continuing the discussion from
> > https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032037.html
> > 
> > I have looked at the changes made to implement automatic selection of DH
> > groups and there are few changes confusing to me, to say the least.
> > 
> > Especially 1.97~1.96 rev diff of kex.c:
> > 
> > > +		 dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher));
> > 
> > Why "MAX("? Why security of chosen dh moduli should match the _most_
> > secure primitive? Since DH KEX is computationally expensive (think
> > smartphones),
> > shouldn't we try to use as small DH parameters as possible?
> 
> I think that it's reasonable for users, when they select a cipher of a
> given strength, to expect that ssh actually provides enough key material
> to properly use it.

The previous version did bind cipher to DH sizes so this expectation was
met.

Problem is, that now when you're running in FIPS mode the chosen HMAC
in worst case is sha1-based so the DH moduli end up being 7680 bits in
size even when the selected cipher is 3DES:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent

as a result, connection to cryptlib server in FIPS mode doesn't work.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
http://wiki.brq.redhat.com/hkario
Email: hkario at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic