F21 System Wide Change: System-wide crypto policy

[Jaroslav Reznik]

= Proposed System Wide Change: System-wide crypto policy =
https://fedoraproject.org/wiki/Changes/CryptoPolicy

Change owner(s): Nikos Mavrogiannopoulos <nmav(a)redhat.com&gt;

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-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Colin Walters]

On Thu, Feb 27, 2014 at 11:22 AM, Jaroslav Reznik <jreznik(a)redhat.com&gt; 
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?

[Nikos Mavrogiannopoulos]

On Thu, 2014-02-27 at 16:35 +0000, 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

[Miloslav Trmač]

2014-02-27 18:30 GMT+01:00 Nikos Mavrogiannopoulos <nmav(a)redhat.com&gt;:

>  On Thu, 2014-02-27 at 16:35 +0000, 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

[Toshio Kuratomi]

On Feb 27, 2014 8:25 AM, "Jaroslav Reznik" <jreznik(a)redhat.com&gt; 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

[Nikos Mavrogiannopoulos]

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

[Bill Nottingham]

Jaroslav Reznik (jreznik(a)redhat.com) said: 
>  = Proposed System Wide Change: System-wide crypto policy =
>  https://fedoraproject.org/wiki/Changes/CryptoPolicy
>  
>  Change owner(s): Nikos Mavrogiannopoulos <nmav(a)redhat.com&gt;
>  
>  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

[Richard W.M. Jones]

On Thu, Feb 27, 2014 at 11:52:01AM -0500, Bill Nottingham wrote:
>  Jaroslav Reznik (jreznik(a)redhat.com) said: 
>  > = Proposed System Wide Change: System-wide crypto policy =
>  > https://fedoraproject.org/wiki/Changes/CryptoPolicy
>  > 
>  > Change owner(s): Nikos Mavrogiannopoulos <nmav(a)redhat.com&gt;
>  > 
>  > 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

[Nikos Mavrogiannopoulos]

On Thu, 2014-02-27 at 17:59 +0000, 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

[Nikos Mavrogiannopoulos]

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

[Bill Nottingham]

Nikos Mavrogiannopoulos (nmav(a)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

[Andrew Lutomirski]

On Thu, Feb 27, 2014 at 9:22 AM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  = Proposed System Wide Change: System-wide crypto policy =
>  https://fedoraproject.org/wiki/Changes/CryptoPolicy
>
>  Change owner(s): Nikos Mavrogiannopoulos <nmav(a)redhat.com&gt;
>
>  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

[Nikos Mavrogiannopoulos]

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

[Andrew Lutomirski]

On Thu, Feb 27, 2014 at 10:49 AM, Nikos Mavrogiannopoulos
<nmav(a)redhat.com&gt; 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

[Stephen John Smoogen]

On 27 February 2014 10:58, Andrew Lutomirski <luto(a)mit.edu&gt; 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.

[Andrew Lutomirski]

On Thu, Feb 27, 2014 at 10:26 AM, Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  On 27 February 2014 10:58, Andrew Lutomirski <luto(a)mit.edu&gt; 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

[Nikos Mavrogiannopoulos]

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

[Nikos Mavrogiannopoulos]

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

[Andrew Lutomirski]

On Fri, Feb 28, 2014 at 2:52 AM, Nikos Mavrogiannopoulos
<nmav(a)redhat.com&gt; 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
<nmav(a)redhat.com&gt; 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

[Martin Langhoff]

On Thu, Feb 27, 2014 at 11:22 AM, Jaroslav Reznik <jreznik(a)redhat.com&gt; 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.langhoff(a)gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

[Omair Majid]

* Jaroslav Reznik <jreznik(a)redhat.com&gt; [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

[Miloslav Trmač]

2014-02-27 17:22 GMT+01:00 Jaroslav Reznik <jreznik(a)redhat.com&gt;:

>  = 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.


>  == 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. 

The difficult-to-coordinate work is updating the application-sid, so as
long as the API doesn't change, changing the predefined security levels is
something that needs to be done within a single package only, i.e.
comparatively easier, so I'm not *too* concerned about the particular
choices.

I do think we need a *single*, clear "Fedora recommended default".  Beyond
that, we need some flexibility, but it's far too easy to start asking for
too many options, and to get deep into bikeshedding.

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?).


>  * 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).


>  * 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?

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?
    Mirek

[Nikos Mavrogiannopoulos]

On Tue, 2014-03-04 at 17:19 +0100, Miloslav Trmač wrote:
>  2014-02-27 17:22 GMT+01:00 Jaroslav Reznik
> <jreznik(a)redhat.com&gt;:
>          = 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

[Miloslav Trmač]

2014-03-05 9:58 GMT+01:00 Nikos Mavrogiannopoulos <nmav(a)redhat.com&gt;:

>  > 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