available crypto policies

[Aaron Zauner]

Hi Hubert,

Hubert Kario wrote:
> I don't disagree, but it does require a targeted attack. And targeted
> not at server but at the specific user. This is unlikely. As such it does
> provide security against opportunistic eavesdropper.
Well. We've seen a couple of directed, active attack schemes being
leaked over the last 9 months. Even going as far as beating service
providers in terms of latency at exchange points. Sure, it's not
feasible to do this wholesale, still it is cause for concern, I guess.

> There's still over 800 servers in the Alexa top 1M that use 768 bit DH:
> https://jve.linuxwall.info/blog/index.php?post/TLS_Survey
> 
> This is also not supposed to be the default but requiring action by
> the administrator to change to.
People might deploy this, e.g. because of lack of understanding. :/

> Windows 2003 is still supported and it doesn't support SSLv3 in default
> configuration. The same TLS Survey found over 4000 servers that support
> only SSLv3.
> 
> Most of those protocol flaws apply to TLSv1.0 too, and we certainly
> can't disallow it.
Sadly, this is true. Point taken.

> Default is usable only as long is it works for majority of users.
> There is still a lot of web servers that use 1024bit RSA out there,
> not to mention 1024bit DH which is the only option for admins
> running Apache 2.2 or not running the relatively new Apache 2.4.7+
>  
> It also matches the security of SHA-1 signatures. Again, we
> certainly can't disallow SHA-1 in the default configuration.
I've overlooked SHA-1 in there. This is correct.

The thing is, you might want to force administrators to deploy "newer"
and stronger cryptography, if you have the chance to, right? Still
referring to old standards as "DEFAULT" might not be the best idea, this
was the point I was trying to make and still am. These policies might be
deployed for a long time in servers (which often do not get upgraded on
a regular basis).

> +1. The idea is that we want ciphers that provides around
> 128 bit *effective* security. So they do qualify once they are
> accepted as standard.
I do hope they will be. Another thing would be Ed25519.

>> I'd actually go with TLS1.2+ and 4096bit RSA/DH. It's the
>> future, right? Is there any reason not to (e.g. performance)?
> 
> It's the future in the sense of "tomorrow", not as in "next year".
> 
> IOW, current best practice.
Shouldn't the current best practice be default instead of a setting
marked "FUTURE"?

General question: What will be the lifespan of these recommendations,
and if they're adopted in for example RHEL: how often will they be adapted?

Thanks,
Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/security/attachments/20140404/14deed9a/attachment-0001.sig>