----- Original Message ----- > From: "Nikos Mavrogiannopoulos" <nmav@xxxxxxxxxx> > To: "Hubert Kario" <hkario@xxxxxxxxxx> > Cc: security@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxx> > > > To: security@xxxxxxxxxxxxxxxxxxxxxxx > > > 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? > > 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 (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. > > 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 LEGACY as an alias for LEGACY-F22 *in* F22 is a very good idea. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team http://wiki.brq.redhat.com/hkario Email: hkario@xxxxxxxxxx Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
