----- Original Message -----
From: "Nikos Mavrogiannopoulos" <nmav(a)redhat.com>
To: security(a)lists.fedoraproject.org
Sent: Thursday, 27 March, 2014 12:13:33 PM
Subject: available crypto policies
Hello,
For the purposes of the Crypto Policies change proposal [0], I think
I've settled to the following three policy levels (inspired by the ENISA
levels but with a rename of the good LEGACY level to DEFAULT). Any
comments or suggestions are appreciated.
Can you give reasons why you want to limit the number of provided policies?
Do you plan some other mechanism for people to enforce strict
FIPS guidelines, 128 bit security level or Suite B crypto? In other words,
implement their own policy?
As these levels will be a moving target across releases (will
provide
defaults that reflect the current state of the art), levels of previous
fedora releases will be referenced as LEVELNAME-F21.
While "self-updating" policies are quite nice, I can see people
not trusting them (either as this implies that they will change, or that
they are not strict enough). That's why I think "security level" policies
would be better. With probably the LEGACY, DEFAULT and FUTURE defined as
aliases that will change.
Either way, the file in which the configuration is going to take place
should either contain a detailed description of available policies
or a reference to the appropriate man page.
The levels and their current settings:
=====LEGACY=====
A level that may include algorithms with known weaknesses (but not
completely broken) which will ensure maximum compatibility with legacy
systems. It should provide at least 64-bit security and include RC4, but
not MD5 as signature algorithm.
MACs: MD5, SHA1+
Curves: All supported
Signature algorithms: must use SHA-1 hash or better
Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC, RC4
Key exchange: ECDHE, RSA, DHE
DH params size: 768+
RSA params size: 768+
SSL Protocols: All supported (SSL3.0+)
I think we should do a 767, 1023 and 2047 as the values for RSA and DH,
some implementations (most common being Cisco routers) regularly generate
"off-by-one" RSA sizes.
=====DEFAULT======
A reasonable default for today's standards. For F21 it should provide
80-bit security and no broken ciphers like RC4.
MACs: SHA1+
Curves: All supported
Signature algorithms: must use SHA-1 hash or better
Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC
Key exchange: ECDHE, RSA, DHE
DH params size: 1024+
RSA params size: 1024+
SSL Protocols: All supported (SSL3.0+)
=====FUTURE======
A level that will provide security on a conservative level that is
believed to withstand any near-term future attacks. That will be
an 128-bit security level, without including protocols with known
attacks available (e.g. SSL 3.0/TLS 1.0). This level may prevent
communication with commonly used systems that provide weaker security
levels (e.g., systems that use SHA-1 as signature algorithm).
MACs: SHA1+
Curves: All supported
Signature algorithms: must use SHA-256 hash or better
Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC
Key exchange: ECDHE, RSA, DHE
DH params size: 2048+
RSA params size: 2048+
SSL Protocols: TLS1.1+
Shouldn't DH params and RSA params at 128 bit be 3072 bit in size?
And ECDSA curves at least 256 bit in size? (While we don't ship any
in Fedora now, it may change in future and it doesn't hurt to codify
that in policy.)
--
Regards,
Hubert Kario
BaseOS QE Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic