On Mon, May 2, 2022 at 7:18 PM Robbie Harwood <rharwood(a)redhat.com> wrote:
Alexander Sosedkin <asosedkin(a)redhat.com> writes:
> crypto-policies' goal is to define system-wide *defaults*.
Well, that's certainly part of it, but...
"The purpose is to 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, irrespective of
the crypto library in use."
(from
https://gitlab.com/redhat-crypto/fedora-crypto-policies#purpose )
"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. The implementation approach will
be to initially modify SSL libraries to respect the policy and gradually
adding more libraries and applications."
(from
https://fedoraproject.org/wiki/Changes/CryptoPolicy#Summary )
So to restate: from what Nikos wrote, I read an additional goal of
unification and centralization that I don't hear echoed in what you're
saying.
Unification and centralization of defaults.
And yes, I can't vouch that the early crypto-policies goal was to set defaults,
in fact some of the changes by Nikos set hard non-sidesteppable limits.
Now we're moving away from that to setting soft-defaults.
> Cryptographic libraries already provide all kinds of finer API
to
> deviate from configuration file defaults that isn't just envvars or
> pointing to configuration files; API that applications are already
> supposed to be using if they want to ensure that a specific algorithm
> is available no matter what the local/vendor/whatever configuration
> is.
In many cases these APIs exist, but what you're proposing is a world
where applications generally need to care about their own crypto
settings. In that world, there's little incentive to use the systemwide
settings at all, and we're back to each application deciding crypto for
themselves - which doesn't strike me as appealing.
Absolutely not, quite the opposite, even.
I advocate for the world of applications that
1. practice cryptographic agility and trust the system defaults
2. when faced with an overly legacy scenario, fail by default
3. only if/when the operator explicitly opts to go unsafe,
grant itself an exception and relax the list of what's allowed
+ more or less conveniently adjustable system defaults don't hurt
What I tried to say is,
for each and every configurable aspect of the library
nobody guarantees the app author that it's allowed on a select system.
Thus applications must be ready for any algorithm to be restricted
and act sensibly when it is.
This is the case for all distros and
works the same in the crypto-policies-less world.
> The sad thing though is that it's been long limited to just
TLS and
> routinely needs expansion to cover more.
Yes, many things make the assumption that crypto == TLS.
crypto-policies already covers more than just TLS settings for
applications, so it needs to have solutions for more than just that.
> Envvars and custom config files do exist and do function, but I don't
> consider them enough.
So what solution do you propose that would be enough?
Something akin to gnutls' recently added gnutls_sign_set_secure,
we'll also need to propose something similar for OpenSSL.