Re: F21 System Wide Change: System-wide crypto policy
On Tue, 2014-03-04 at 17:19 +0100, Miloslav Trmač wrote: 2014-02-27 17:22 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: = Proposed System Wide Change: System-wide crypto policy = https://fedoraproject.org/wiki/Changes/CryptoPolicy Unify the crypto policies used by different applications and libraries. Is this for TLS only? The description suggest this, but it's not explicit. I've made it explicit, thanks. The above proposed levels broadly make sense (taking 80/128/256 as a nice round numbers that stand for detailed strenghts), we would probably want to explicitly document the semantics (Is the semantics of a level fixed forever or will it be updated? Will we remove a weak cipher from an existing level (ever / during a single Fedora release)? Will we add a cipher to alevel (ever / during a single Fedora release?). Would that be required to be part of the fedora change? I'd prefer if the semantics are not fixed before the actual levels are fixed. * Proposal owners: For GnuTLS and OpenSSL the SYSTEM cipher needs to be understood and behave as described. For NSS the NSS_SetDomesticPolicy() can be overloaded to behave as above. Please update the NSS part with the current proposal (based on our discussion). Updated. * Other developers: Packages that use SSL crypto libraries should, after the previous change is complete, start replacing the default cipher strings with SYSTEM. How can we find out which packages would be affected? Anything that requires the library, or only users that refer to a specific symbol? I've updated the text. The idea is to start with a small set of packages using the new method in F21 and increase gradually. What about packages that currently don't explicitly set any policy string (i.e. packages that probably don't care too much about the specifics)? Would this mean adding a call to use SYSTEM to these packages, or would we change the semantics of the API to use SYSTEM by default? I think that we should change the semantics of the API to use the SYSTEM by default. I've updated the text to reflect that. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
2014-03-05 9:58 GMT+01:00 Nikos Mavrogiannopoulos n...@redhat.com: The above proposed levels broadly make sense (taking 80/128/256 as a nice round numbers that stand for detailed strenghts), we would probably want to explicitly document the semantics (Is the semantics of a level fixed forever or will it be updated? Will we remove a weak cipher from an existing level (ever / during a single Fedora release)? Will we add a cipher to alevel (ever / during a single Fedora release?). Would that be required to be part of the fedora change? I'd prefer if the semantics are not fixed before the actual levels are fixed. I don't think it's required for FESCo to make a decision (but I can't speak for other FESCo members); it should be defined by F21 release so that the users know what they have been promised. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
2014-02-27 18:30 GMT+01:00 Nikos Mavrogiannopoulos n...@redhat.com: On Thu, 2014-02-27 at 16:35 +, Colin Walters wrote: wrote: and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically) Was the option of patching the libraries to *directly* read this new config file and prefer it over their own internal ones considered? Hello, Do you mean ignoring any other configured option? I think Colin was suggesting that the update-crypto-profiles step would be redundant if the individual libraries were directly patched to read the new config files, or to call something that reads the new config files (only if the magic SYSTEM string were used). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, 2014-02-27 at 10:58 -0700, Andrew Lutomirski wrote: For reference, there isn't a well-established, widely accepted symmetric cipher with 256-bit security. AES-256 is weak [1] and should probably not be used at all, let alone by anyone who wants a 256-bit security level. AES-128 is broken too: http://www.kuleuven.be/english/newsletter/newsflash/encryption_standard.html (in short it provides 126-bit security instead of 128). _However_, this and the attacks your describe on AES-256 don't matter for practical purposes. Schneier explains in the blog you quote, but I recap: 1. Related key attacks are nice for publishing papers, but they have almost no practical relevance (AES or any other modern cipher isn't designed to resist related key attacks). 2. Attacking on reduced round variants of ciphers, doesn't matter either except for academics and for getting the future trend of security of the cipher. We use the full-round variants that resist the published attacks. 3. Breaking a cipher in the academic term means finding an attack that is faster than brute force. The brute force level of AES-256 is terribly high so breaking AES-256 in 2^245 steps is still very reassuring. So, in summary: - LEVEL-256 provides well under 256-bit security. - This is fine because no one actually needs 256-bit security. So *why on earth* would it make sense to implement this proposal? It sounds like we'd be offering options that (a) don't perform as advertised and (b) don't serve any purpose anyway. I don't really understand what you are arguing about. Are you complaining that AES-256 doesn't offer the advertized 256-bit security, or that a consistent security policy isn't required? regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, 2014-02-27 at 17:59 +, Richard W.M. Jones wrote: How is an admin supposed to know what levels such as the above are, and why they might choose a particular one? Supplemental question: Why wouldn't you always want to choose the most secure one? I believe the proposal is trying to answer this question here: It may be that setting a high security level could prevent applications that connected to servers below that level to connect but it's rather unclear, and could do with at least more explanation and ideally some examples of things that wouldn't work. In any case, I can't imagine I'd ever want a Fedora machine that wasn't most secure (discounting external connections). Most secure means spending more resources and not all servers would agree with that. Today 64-bit to 80-bit security is the norm for typical internet secure connections. As you note, this proposal is about setting the bar for the default settings on a particular system. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, 2014-02-27 at 10:37 -0800, Andrew Lutomirski wrote: In that case, why not give full control: allowed_ciphers = AES-192, AES-256, Salsa20/12, Salsa20/20 allowed_groups = modp = 2048, P-256, Curve25519 allowed_hashes = SHA-3, ... allowed_modes = CTR, OCB, XTS, GCM allowed_macs = ... Because of two reasons: 1. A typical administrator isn't a cryptographer. Most people cannot distinguish noise from the algorithms that you mention above. 2. That proposal has to work with very different libraries that don't provide the same level of access to their internals. Thus the practical solution is to handle pre-defined common policies rather than provide unlimited tuning for every possible purpose (that can be done by overriding the defaults). regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, 2014-02-27 at 11:52 -0500, Bill Nottingham wrote: == Detailed Description == The idea is to have some predefined security levels such as LEVEL-80, LEVEL-128, LEVEL-256, or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically) How is an admin supposed to know what levels such as the above are, and why they might choose a particular one? They will be documented. They could be part of the configuration file that be edited. The policies above are a indicative, so if there are suggestions they will be considered. * Proposal owners: For GnuTLS and OpenSSL the SYSTEM cipher needs to be understood and behave as described. For NSS the NSS_SetDomesticPolicy() can be overloaded to behave as above. After that a mechanism to specify crypto policies for Fedora has to be devised, as well as the extraction to each libraries' settings. * Other developers: Packages that use SSL crypto libraries should, after the previous change is complete, start replacing the default cipher strings with SYSTEM. This implies a potentially not insignificant local patch load. Am I misunderstanding it? You are correctly understanding. This is not a small project and any help is appreciated. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
Nikos Mavrogiannopoulos (n...@redhat.com) said: On Thu, 2014-02-27 at 11:52 -0500, Bill Nottingham wrote: == Detailed Description == The idea is to have some predefined security levels such as LEVEL-80, LEVEL-128, LEVEL-256, or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically) How is an admin supposed to know what levels such as the above are, and why they might choose a particular one? They will be documented. They could be part of the configuration file that be edited. The policies above are a indicative, so if there are suggestions they will be considered. Well, even if they're documented, I don't know if they're particularly meaningful items. For example although I 'know' what SUITEB might refer to, it still amounts to 'a set of algorithms the NSA deems sufficient'; it does not give me any meaningful knowledge to compare it to other settings. And for all I know I'm aobve the curve on understanding what some of these are; your typical administrator is likely to know even less. If they're merely described in terms of what they represent - is it going to make the choice clearer, or not? i.e., how do ensure that the configuration choices are meaningful and explicable to the administrators such they can make an informed decision outside of I checked the SUITEB-256 box because that's what the standard 243213 chapter 33 subsection 24 sentence 1 says. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Fri, Feb 28, 2014 at 2:52 AM, Nikos Mavrogiannopoulos n...@redhat.com wrote: On Thu, 2014-02-27 at 10:58 -0700, Andrew Lutomirski wrote: - LEVEL-256 provides well under 256-bit security. - This is fine because no one actually needs 256-bit security. So *why on earth* would it make sense to implement this proposal? It sounds like we'd be offering options that (a) don't perform as advertised and (b) don't serve any purpose anyway. I don't really understand what you are arguing about. Are you complaining that AES-256 doesn't offer the advertized 256-bit security, or that a consistent security policy isn't required? I'm arguing that there is no sensible setting. If you want 256-bit security as your consistent security policy, then either (a) you won't actually get 256-bit security or (b) you won't have any legal well-tested block ciphers at all. Saying that AES-256 is good enough is specious: if the administrator ask for 256-bit security and if you assume that giving the administrator this kind of control makes sense in the first place, then you should interpret the administrator's request to mean, literally, 256 bits. In particular, reinterpreting the request to mean 256 bits would be nice, but 245 is okay, and maybe other numbers are okay too depending on whether related key attacks are relevant is, IMO, a terrible idea. On Fri, Feb 28, 2014 at 2:59 AM, Nikos Mavrogiannopoulos n...@redhat.com wrote: On Thu, 2014-02-27 at 10:37 -0800, Andrew Lutomirski wrote: In that case, why not give full control: allowed_ciphers = AES-192, AES-256, Salsa20/12, Salsa20/20 allowed_groups = modp = 2048, P-256, Curve25519 allowed_hashes = SHA-3, ... allowed_modes = CTR, OCB, XTS, GCM allowed_macs = ... Because of two reasons: 1. A typical administrator isn't a cryptographer. Most people cannot distinguish noise from the algorithms that you mention above. 2. That proposal has to work with very different libraries that don't provide the same level of access to their internals. Now you and smooge appear to want different things out of this proposal. smooge wants to comply with arcane governmental rules, which, for better or for worse, are probably fairly specific. In that case, just saying LEVEL=whatever will not solve the problem. What is the actual point of this proposal? What is it trying to accomplish? Why is whatever it's trying to accomplish something that Fedora should be interested in? --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
* Jaroslav Reznik jrez...@redhat.com [2014-02-27 11:25]: = Proposed System Wide Change: System-wide crypto policy = https://fedoraproject.org/wiki/Changes/CryptoPolicy An idea of how this will be implemented is to have each Fedora application's configuration file or compilation option will set a system default option. That is for example for applications that use GnuTLS or OpenSSL a priority string or cipher named SYSTEM. Then the shipped library will make sure that once the SYSTEM option is encountered the preconfigured system settings will be applied. == Scope == There are changes required in GnuTLS, OpenSSL and NSS libraries. On a second phase non-SSL crypto libraries could use these settings. What about applications that do not use GnuTLS, OpenSSL and NSS? I believe both OpenJDK and Bouncy Castle fall under this category. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: System-wide crypto policy
= Proposed System Wide Change: System-wide crypto policy = https://fedoraproject.org/wiki/Changes/CryptoPolicy Change owner(s): Nikos Mavrogiannopoulos n...@redhat.com Unify the crypto policies used by different applications and libraries. That is allow setting a consistent security level for crypto on all applications in a Fedora system. == Detailed Description == The idea is to have some predefined security levels such as LEVEL-80, LEVEL-128, LEVEL-256, or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically) After that the administrator should be assured that any application that uses the system settings will follow a policy that adheres to the configured profile. Ideally setting a profile should be setting: * the acceptable TLS/SSL (and DTLS) versions * the acceptable ciphersuites and the preferred order * acceptable parameters in certificates and key exchange, i.e.: ** the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA) ** the acceptable elliptic curves (ECDH,ECDSA) ** the acceptable signature hash functions * other TLS options such as: ** safe renegotiation An idea of how this will be implemented is to have each Fedora application's configuration file or compilation option will set a system default option. That is for example for applications that use GnuTLS or OpenSSL a priority string or cipher named SYSTEM. Then the shipped library will make sure that once the SYSTEM option is encountered the preconfigured system settings will be applied. The preconfigured settings for each SSL library will be auto-generated from the default profile in /etc/crypto-profiles/generated/$(libname)/config == Scope == There are changes required in GnuTLS, OpenSSL and NSS libraries. On a second phase non-SSL crypto libraries could use these settings. * Proposal owners: For GnuTLS and OpenSSL the SYSTEM cipher needs to be understood and behave as described. For NSS the NSS_SetDomesticPolicy() can be overloaded to behave as above. After that a mechanism to specify crypto policies for Fedora has to be devised, as well as the extraction to each libraries' settings. * Other developers: Packages that use SSL crypto libraries should, after the previous change is complete, start replacing the default cipher strings with SYSTEM. * Release engineering: This feature does not require coordination with release engineering. * Policies and guidelines: After the change is complete the packaging guidelines, should mention above replacing the default cipher strings with SYSTEM. This of course need not affect programs that do not have a mechanism for setting ciphers/modes that is already in wide use (e.g., browsers). It mostly targets applications that use some reasonable (or unreasonable) defaults and the user/administrator has little control of them. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, Feb 27, 2014 at 11:22 AM, Jaroslav Reznik jrez...@redhat.com wrote: and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically) Was the option of patching the libraries to *directly* read this new config file and prefer it over their own internal ones considered? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Feb 27, 2014 8:25 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: System-wide crypto policy = https://fedoraproject.org/wiki/Changes/CryptoPolicy == Detailed Description == The idea is to have some predefined security levels such as LEVEL-80, LEVEL-128, LEVEL-256, or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically) After that the administrator should be assured that any application that uses the system settings will follow a policy that adheres to the configured profile. Ideally setting a profile should be setting: * the acceptable TLS/SSL (and DTLS) versions * the acceptable ciphersuites and the preferred order * acceptable parameters in certificates and key exchange, i.e.: ** the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA) ** the acceptable elliptic curves (ECDH,ECDSA) ** the acceptable signature hash functions * other TLS options such as: ** safe renegotiation Does this configuration limit the algorithms that are available or only the options that can be given to those algorithms or only the default values of those algorithms? -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: System-wide crypto policy = https://fedoraproject.org/wiki/Changes/CryptoPolicy Change owner(s): Nikos Mavrogiannopoulos n...@redhat.com Unify the crypto policies used by different applications and libraries. That is allow setting a consistent security level for crypto on all applications in a Fedora system. == Detailed Description == The idea is to have some predefined security levels such as LEVEL-80, LEVEL-128, LEVEL-256, or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically) How is an admin supposed to know what levels such as the above are, and why they might choose a particular one? * Proposal owners: For GnuTLS and OpenSSL the SYSTEM cipher needs to be understood and behave as described. For NSS the NSS_SetDomesticPolicy() can be overloaded to behave as above. After that a mechanism to specify crypto policies for Fedora has to be devised, as well as the extraction to each libraries' settings. * Other developers: Packages that use SSL crypto libraries should, after the previous change is complete, start replacing the default cipher strings with SYSTEM. This implies a potentially not insignificant local patch load. Am I misunderstanding it? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, Feb 27, 2014 at 9:22 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: System-wide crypto policy = https://fedoraproject.org/wiki/Changes/CryptoPolicy Change owner(s): Nikos Mavrogiannopoulos n...@redhat.com Unify the crypto policies used by different applications and libraries. That is allow setting a consistent security level for crypto on all applications in a Fedora system. == Detailed Description == The idea is to have some predefined security levels such as LEVEL-80, LEVEL-128, LEVEL-256, or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config How much of the system will break if the administrator does something silly like setting LEVEL-256? For reference, there isn't a well-established, widely accepted symmetric cipher with 256-bit security. AES-256 is weak [1] and should probably not be used at all, let alone by anyone who wants a 256-bit security level. 3-DES is slow and doesn't offer 256-bit security. Salsa20 and ChaCha20 are probably okay for 256-bit security, but they aren't widely supported yet. This means that sensible websites (and browsers!) don't enable the AES-256 cipher suites. Should a system set to LEVEL-256 disallow access to those sites? What about disallowing use of CA certificates that use SHA-1? (Oops, there goes the Internet.) If someone sets SUITEB-whatever, is Curve25519 acceptable? How many people even know what an ENISA algorithm is? (I don't.) I would maybe support a division into probably already broken by people with deep pockets (e.g. DES, RC4, MD5, maybe SHA-1 in some use cases), probably safe against classical computers for a long time (everything at 128 bits or higher, RSA with, say, 3072 bits and up, maybe RSA2048, and Suite B, depending on your philosophical views), and probably safe against quantum computers for a long time (Probably Salsa20, ChaCha20, and a handful of public-key cryptosystems that are either patent-encumbered, insecure, impractical, or more than one of the above.) Alternatively, a systemwide setting like avoid modp groups below X bits could make sense. Far too many things 1024-bit modp groups. This includes *SSH* until very recently. Having a single switch to turn that cr*p off would be very useful, although it might imply a lot of patches. [1] https://www.schneier.com/blog/archives/2009/07/another_new_aes.html --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, 2014-02-27 at 16:35 +, Colin Walters wrote: wrote: and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically) Was the option of patching the libraries to *directly* read this new config file and prefer it over their own internal ones considered? Hello, Do you mean ignoring any other configured option? If we enforce something like that, there will not be any easy way to override the defaults, and I think that it would most probably result into forum advices like delete the crypto profile file, or set a very weak profile that would work everywhere. That result would be undesirable, but there is a practical reason too. There are strings in openssl and gnutls that enable PSK ciphersuites or other exotic options for some applications, that we will not have enabled in a system wide policy (not initially at least). regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, 2014-02-27 at 08:42 -0800, Toshio Kuratomi wrote: After that the administrator should be assured that any application that uses the system settings will follow a policy that adheres to the configured profile. Ideally setting a profile should be setting: * the acceptable TLS/SSL (and DTLS) versions * the acceptable ciphersuites and the preferred order * acceptable parameters in certificates and key exchange, i.e.: ** the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA) ** the acceptable elliptic curves (ECDH,ECDSA) ** the acceptable signature hash functions * other TLS options such as: ** safe renegotiation Does this configuration limit the algorithms that are available or only the options that can be given to those algorithms or only the default values of those algorithms? I'm not sure I fully understand the question. This configuration will limit the available algorithms (e.g., will disable RC4), but it will also limit some options of the algorithms (e.g., RSA using 1024 bits or more - at least for the libraries that have support for such options). Does this answer your question? regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, 2014-02-27 at 10:12 -0700, Andrew Lutomirski wrote: == Detailed Description == The idea is to have some predefined security levels such as LEVEL-80, LEVEL-128, LEVEL-256, or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config How much of the system will break if the administrator does something silly like setting LEVEL-256? Probably a lot, but I don't think we protect from someone doing rm -fr / either :) For reference, there isn't a well-established, widely accepted symmetric cipher with 256-bit security. AES-256 is weak [1] and should probably not be used at all, let alone by anyone who wants a 256-bit security level. AES-128 is broken too: http://www.kuleuven.be/english/newsletter/newsflash/encryption_standard.html (in short it provides 126-bit security instead of 128). _However_, this and the attacks your describe on AES-256 don't matter for practical purposes. Schneier explains in the blog you quote, but I recap: 1. Related key attacks are nice for publishing papers, but they have almost no practical relevance (AES or any other modern cipher isn't designed to resist related key attacks). 2. Attacking on reduced round variants of ciphers, doesn't matter either except for academics and for getting the future trend of security of the cipher. We use the full-round variants that resist the published attacks. 3. Breaking a cipher in the academic term means finding an attack that is faster than brute force. The brute force level of AES-256 is terribly high so breaking AES-256 in 2^245 steps is still very reassuring. access to those sites? What about disallowing use of CA certificates that use SHA-1? (Oops, there goes the Internet.) We have to document that, but there will be always ways to shoot someones foot. There are legitimate uses of increasing a security level (if one for example sets up machines to be used in a LAN). If someone sets SUITEB-whatever, is Curve25519 acceptable? SuiteB only allows two curves. SECP256 and SECP384 if I remember well. How many people even know what an ENISA algorithm is? (I don't.) ENISA is not an algorithm. It is the European Union Agency for Network and Information Security and they have some papers proposing various security levels, similarly to NIST. https://www.enisa.europa.eu/ Alternatively, a systemwide setting like avoid modp groups below X bits could make sense. Far too many things 1024-bit modp groups. This includes *SSH* until very recently. Having a single switch to turn that cr*p off would be very useful, although it might imply a lot of patches. That's the idea. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, Feb 27, 2014 at 11:22 AM, Jaroslav Reznik jrez...@redhat.com wrote: Unify the crypto policies used by different applications and libraries. That is allow setting a consistent security level for crypto on all applications in a Fedora system. As others have noted, crypto tech compatibility is tricky. Clients and servers that you want to interoperate with have interesting mixes of supported crypto suites. And the quality of crypto suites is very-nonlinear and multidimensional. Every crypto suite choice is fraught with tricky tradeoffs in threat vs interoperability, and this is different on each protocol. Personally, I cannot picture a good way to consolidate this into a single policy... m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, Feb 27, 2014 at 10:49 AM, Nikos Mavrogiannopoulos n...@redhat.com wrote: On Thu, 2014-02-27 at 10:12 -0700, Andrew Lutomirski wrote: == Detailed Description == The idea is to have some predefined security levels such as LEVEL-80, LEVEL-128, LEVEL-256, or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config How much of the system will break if the administrator does something silly like setting LEVEL-256? Probably a lot, but I don't think we protect from someone doing rm -fr / either :) For reference, there isn't a well-established, widely accepted symmetric cipher with 256-bit security. AES-256 is weak [1] and should probably not be used at all, let alone by anyone who wants a 256-bit security level. AES-128 is broken too: http://www.kuleuven.be/english/newsletter/newsflash/encryption_standard.html (in short it provides 126-bit security instead of 128). _However_, this and the attacks your describe on AES-256 don't matter for practical purposes. Schneier explains in the blog you quote, but I recap: 1. Related key attacks are nice for publishing papers, but they have almost no practical relevance (AES or any other modern cipher isn't designed to resist related key attacks). 2. Attacking on reduced round variants of ciphers, doesn't matter either except for academics and for getting the future trend of security of the cipher. We use the full-round variants that resist the published attacks. 3. Breaking a cipher in the academic term means finding an attack that is faster than brute force. The brute force level of AES-256 is terribly high so breaking AES-256 in 2^245 steps is still very reassuring. So, in summary: - LEVEL-256 provides well under 256-bit security. - This is fine because no one actually needs 256-bit security. So *why on earth* would it make sense to implement this proposal? It sounds like we'd be offering options that (a) don't perform as advertised and (b) don't serve any purpose anyway. access to those sites? What about disallowing use of CA certificates that use SHA-1? (Oops, there goes the Internet.) We have to document that, but there will be always ways to shoot someones foot. There are legitimate uses of increasing a security level (if one for example sets up machines to be used in a LAN). If someone sets SUITEB-whatever, is Curve25519 acceptable? SuiteB only allows two curves. SECP256 and SECP384 if I remember well. I understand why people implement ridiculous FIPS modes: it's to comply with government rules. I don't see why Fedora should add to the mess. How many people even know what an ENISA algorithm is? (I don't.) ENISA is not an algorithm. It is the European Union Agency for Network and Information Security and they have some papers proposing various security levels, similarly to NIST. https://www.enisa.europa.eu/ Alternatively, a systemwide setting like avoid modp groups below X bits could make sense. Far too many things 1024-bit modp groups. This includes *SSH* until very recently. Having a single switch to turn that cr*p off would be very useful, although it might imply a lot of patches. That's the idea. Then let's do that. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, Feb 27, 2014 at 11:52:01AM -0500, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: System-wide crypto policy = https://fedoraproject.org/wiki/Changes/CryptoPolicy Change owner(s): Nikos Mavrogiannopoulos n...@redhat.com Unify the crypto policies used by different applications and libraries. That is allow setting a consistent security level for crypto on all applications in a Fedora system. == Detailed Description == The idea is to have some predefined security levels such as LEVEL-80, LEVEL-128, LEVEL-256, or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically) How is an admin supposed to know what levels such as the above are, and why they might choose a particular one? Supplemental question: Why wouldn't you always want to choose the most secure one? I believe the proposal is trying to answer this question here: It may be that setting a high security level could prevent applications that connected to servers below that level to connect but it's rather unclear, and could do with at least more explanation and ideally some examples of things that wouldn't work. In any case, I can't imagine I'd ever want a Fedora machine that wasn't most secure (discounting external connections). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On 27 February 2014 10:58, Andrew Lutomirski l...@mit.edu wrote: We have to document that, but there will be always ways to shoot someones foot. There are legitimate uses of increasing a security level (if one for example sets up machines to be used in a LAN). If someone sets SUITEB-whatever, is Curve25519 acceptable? SuiteB only allows two curves. SECP256 and SECP384 if I remember well. I understand why people implement ridiculous FIPS modes: it's to comply with government rules. I don't see why Fedora should add to the mess. Because such .gov rules are pushing throughout the industry and university systems. You may be a research professor who has a grant which requires you to show your systems are on such level as someone in the granting agency doesn't want its grants to have stored their records in plain text or worse the algorithms the professor knew back in the 1970's when he was a grad student. [Been there, done that] You may be a university hospital which has to show that it is keeping confidentiality through various levels [Fedora like many linuxes gets used to be embedded in hardware you might scratch your head but it is what it is.] You may be a EU giant accelerator which finds that its funding has new riders and while you don't use Fedora, you use a rebuild and will want to show you can meet those riders in X years (which is usually good enough for the financial auditors). It is basically to help make the work easier so that when someone is told you have to make your system compliant they can do it in one spot versus 500. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: System-wide crypto policy
On Thu, Feb 27, 2014 at 10:26 AM, Stephen John Smoogen smo...@gmail.com wrote: On 27 February 2014 10:58, Andrew Lutomirski l...@mit.edu wrote: We have to document that, but there will be always ways to shoot someones foot. There are legitimate uses of increasing a security level (if one for example sets up machines to be used in a LAN). If someone sets SUITEB-whatever, is Curve25519 acceptable? SuiteB only allows two curves. SECP256 and SECP384 if I remember well. I understand why people implement ridiculous FIPS modes: it's to comply with government rules. I don't see why Fedora should add to the mess. Because such .gov rules are pushing throughout the industry and university systems. You may be a research professor who has a grant which requires you to show your systems are on such level as someone in the granting agency doesn't want its grants to have stored their records in plain text or worse the algorithms the professor knew back in the 1970's when he was a grad student. [Been there, done that] You may be a university hospital which has to show that it is keeping confidentiality through various levels [Fedora like many linuxes gets used to be embedded in hardware you might scratch your head but it is what it is.] You may be a EU giant accelerator which finds that its funding has new riders and while you don't use Fedora, you use a rebuild and will want to show you can meet those riders in X years (which is usually good enough for the financial auditors). It is basically to help make the work easier so that when someone is told you have to make your system compliant they can do it in one spot versus 500. In that case, why not give full control: allowed_ciphers = AES-192, AES-256, Salsa20/12, Salsa20/20 allowed_groups = modp = 2048, P-256, Curve25519 allowed_hashes = SHA-3, ... allowed_modes = CTR, OCB, XTS, GCM allowed_macs = ... If the point is to comply with requirements that we don't even know about yet, then allowing LEVEL-256 to mean 256 bits or more, by some particular mapping between modp length and bits, and, oh, by the way, AES-256 is okay is asking for this thing to end up being useless. Also, please keep this proposal the heck away from my desktop box. On the other hand, if something can warn about the use of particular primitives, that would be great -- it might have caused people to notice the IMO disastrous OpenSSH 1024-bit crap much sooner. I suspect that several governments know a lot of my passwords as a result of that screwup. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
