----- Original Message -----
From: "Nikos Mavrogiannopoulos" <nmav(a)redhat.com>
To: "Hubert Kario" <hkario(a)redhat.com>
Sent: Thursday, 27 March, 2014 2:39:37 PM
Subject: Re: available crypto policies
On Thu, 2014-03-27 at 09:13 -0400, Hubert Kario wrote:
> ----- 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 , 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?
We must have a reasonable number of policies for the user to select,
that address common use-cases. If I had presented a list of 2^16
policies, an administrator would need an expert to translate the various
available options. I do expect though more policies to be added by time
if this feature proves useful.
I was thinking more on the lies of "provide ~10 policies but strongly
recommend using the DEFAULT as the policy with reasonable security and
compatibility". But giving just few that are most likely going to be used
and having the possibility to add more is a good starting point.
> 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?
I have not yet decided which scripting language to use to generate the
individual library settings from policies, but the idea is to allow
policies to be added.
However, it is not my intention to use that framework for custom
policies primarily. My goal is to be able to handle 99% percent of the
common use-cases with these three policies.
The devil is in the details as they say, and some people may have very
weird requirements (e.g. if auditors don't fully understand
the intent of some recommendations) so the configurability of it
may actually be the main selling point.
As far as scripting language: I don't think it will actually be necessary,
the set of algorithms supported by the libraries is closed and limited,
so with the exception of RSA and DH sizes, it should be possible to explicitly
list the allowed algorithms at specific levels. In case of RSA and DH
a set of "<=", "<", ">", ">=",
"==", "&&", "||" should be enough. Specific
cipher ordering may be achievable only using enumeration...
> > As these levels will be a moving target across releases
> > 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"
> would be better. With probably the LEGACY, DEFAULT and FUTURE defined as
> aliases that will change.
In effect these will be aliases, e.g., LEGACY is an alias for LEGACY-F21
in fedora 21, and an alias for LEGACY-F22 in 22. Does this align with
what you suggest?
I meant "DEFAULT" being alias for "LEVEL-80". But yes, providing
an alias for LEGACY-F22 *in* F22 is a very good idea.
Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic