|Please consider subscribing to LWN|
Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.
The Fedora project is debating a number of proposals for changes to implement in Fedora 21. One of the proposals is to implement a "cryptographic policy" framework, so that a single setting could be used to configure the security options for a suite of related lower-level cryptographic libraries. But not everyone is sure that it is possible to craft a set of cross-library settings that are both meaningful and easy to understand. If such settings require digging into the details of every affected library anyway, they do not add much value, after all. Conversely, if there is never a good use case for settings other than "be as secure as possible," then a policy framework may be overkill.
Jaroslav Reznik sent the proposal to the fedora-devel list on February 27, although the "owner" of the proposal is Nikos Mavrogiannopoulos. The proposal is to offer a set of pre-defined "security levels," each of which encompasses settings for all of Fedora's major cryptographic libraries—initially GnuTLS, OpenSSL, and Network Security Services (NSS). The system administrator could then select a security level and expect a consistent level of protection for all of the applications using the libraries.
Each individual level would set a number of configuration options, including the ciphers and key exchange algorithms available for use, the preferred order of ciphers and algorithms, the allowable protocol versions, and other parameters or options enabled (such as TLS safe renegotiation). In the proposal, the example level names include some that relate to cipher strength (LEVEL-80, LEVEL-112, LEVEL-128, LEVEL-256, each corresponding to the bit-size of the ciphers used), and some that relate to government or international specifications (ENISA-LEGACY and ENISA-FUTURE for the European Network and Information Security Agency, plus SUITEB-128 and SUITEB-256 for the NSA's Suite B). The administrator would thus only need to select the proper level for the system, rather than setting every individual property and option. Nevertheless, the exact contents of these levels is not spelled out in the proposal.
The proposed implementation plan is to create a configuration option called SYSTEM for each application that relies on one of the libraries—for example, a dummy cipher named SYSTEM. That configuration option would then function as a reference to the system-wide settings stored in some well-known location like /etc/crypto-profiles/config. Although tuning the application with the SYSTEM setting will default to the specific security level configured by the system administrator, it would still be possible to specify override options for the individual application.
How the SYSTEM cipher setting is defined for each of the libraries will vary, of course. The proposal also notes that the security level approach is designed to ensure consistent behavior for applications that rely on automatic security settings or do not have user-configurable options.
Nevertheless, there were still plenty of pointed questions asked in reply on the fedora-devel list. Bill Nottingham asked how the configuration options and choices could be made meaningful to administrators so that they could make a sufficiently informed decision:
Along related lines, Richard Jones asked why there would need to be multiple options at all, rather than just configuring a secure default setting.
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).
To those criticisms, Mavrogiannopoulos replied that there was a need for administrators to make a resource trade-off decision. For most servers today, he said, security settings on par with 64- or 80-bit key sizes is the norm, but a particular system might want a different setting depending on its uses.
Andrew Lutomirski raised a more practical implementation question, asking what would break "if the administrator does something silly like setting LEVEL-256." After all, he said, AES-256 is cryptographically weak (at least according to Bruce Schneier), but the 256-bit-key alternatives (Salsa20 and ChaCha20) are not widely supported. Thus, setting a high system-level default would break a lot of applications by leaving them with no usable ciphers enabled. Perhaps, he continues, it would be more meaningful to provide security levels that correspond to different risks of attack, such as "probably already broken by people with deep pockets," "probably safe against classical computers for a long time," and "probably safe against quantum computers for a long time."
Mavrogiannopoulos responded that, yes, a lot would break if the administrator set the security level too high, "but I don't think we protect from someone doing rm -fr / either :)." He also argued that a lot of the theoretical and academic attacks against ciphers are not practical concerns, referencing the same Schneier blog entry, where Schneier comments that scenarios like related-key attacks and attacks that break reduced-round variants are not real-world causes for panic.
Eventually, Lutomirski argued that only full control over the ciphers, options, modes, and hashes would provide real security—to which Mavrogiannopoulos replied that the whole point of the proposal was to spare the administrator from having to specify all of the settings, by creating a set of well-defined presets.
A few other questions came up in the debate. Omair Majid noted that there are crypto-using applications that do not rely on GnuTLS, OpenSSL, or NSS (mainly Java). Miloslav Trmač commented that the project would need to decide whether or not the meaning of the predefined levels would be fixed permanently or could be updated: "Will we remove a weak cipher from an existing level (ever / during a single Fedora release)? Will we add a cipher to a level (ever / during a single Fedora release)?." He also asked whether the proposal would mean patching applications that currently do not specify any preferences about cryptography, "i.e., packages that probably don't care too much about the specifics."
The amount of patching that it would require to implement a system-wide cryptographic policy was raised in a number of other comments; Mavrogiannopoulos agreed that it would entail a considerable amount of work to implement. At this stage, an implementation plan that assesses the amount of work required seems to be the major missing piece, and it is one that could conceivably throw a wrench into the short-term plan. Most people (aside from Lutomirski) agreed that the ability to define a system-wide "minimum cryptographic level," so to speak, would be a valuable addition to Fedora.
How much control should be allowed and what the precise meaning of the policy levels is are the types of detail that can turn into bikeshedding arguments. But even if there is agreement on those points, actually updating every application that uses a standard crypto library is a major undertaking; one that will require brute force of the non-cryptographic variety.
Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds