----- 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? 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 -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
