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. > 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. > > 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? > 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. Indeed. > 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. ok. > > =====FUTURE====== > [...] > > 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.) Nice catch. Corrected. regards, Nikos -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
