[Pkg-openssl-devel] Bug#747453: Arbitrary key size limitations causing hard-to-diagnose problems when establishing a connection

[Wilfried Klaebe]

severity 747453 important
thanks

Am Fri, May 09, 2014 at 08:27:02PM +0200 schrieb Kurt Roeckx:
> On Fri, May 09, 2014 at 07:55:32PM +0200, Benny Baumann wrote:
> > 
> > --> I'd call even 16384 bit RSA when using AES256 a sane and expected
> > configuration.
> 
> I agree that it has about an equivalant strength.  I'm not sure I
> agree that it's an expected combination or configuration.  But if
> your security level should be 256 bits, you need to fix more than
> the RSA key.  For instance you would also need to use hash
> algorithms that have a 256 bit security level which might mean
> something SHA256 or SHA512 depending for what you're using it for.
> And as far as I know there isn't a GCM cipher with SHA512, and you
> really should be using GCM.

Correct. But with TLS 1.3 (or 1.4 or 2.0 ...) there might be. And I
don't expect the limitation to 4096 bit RSA to suddenly go away just
because someone specified and someone implemented GCM cipher suites
with SHA512.

The point that a limitation to 4096 bit RSA is no longer reasonable
still holds.

> Also please note that that NIST recommendation is only about
> cryptography and doesn't say anything about SSL/TLS.

And TLS is about magical fairy dust, not cryptography. Yeah, right.

> > The DSA limit by the way doesn't even make sense when comparing it with
> > RSA: RSA and DSA are assumed to be roughly equal in strength when
> > measured in bits of key size used (putting away some flaws of DSA for a
> > moment). Given this assumption it's illogical to limit RSA at 4096 bit
> > while keeping DSA open up to 10000 bit.
> 
> It makes little sense to me why the limit for DSA should be there.

A patch to raise the DSA key limit to 8200 octets should be as trivial
as the one for RSA. I think Benny and me would even develop, test and
submit it if that sped up things.

On a longer term, having those limits be configurable at runtime would
be even better, of course, but for now, let's just workaround this too
low limit by raising it.

> > That's a different story altogether as most XMPP server software doesn't
> > even properly allow to setup cipher strings or accepted TLS versions
> > (BTW: ejabberd in Debian supports neither, just BTW).
> 
> If there is no bug about this yet, please file it.

We're on it.

Kind regards,
Wilfried
-- 
Irgendwas ist ja immer...