New subject: F36 Change: Switch GnuTLS to allowlisting (System-Wide Change proposal)

2 Dec 2021


      https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting
== Summary ==
Presently, crypto-policies controls GnuTLS in a way that
"hard-disables" select algorithms, leaving no option for the
applications using GnuTLS to reenable said algorithms back. We propose
switching to more future-proof allowlisting-based configuration method
and offering API within GnuTLS to loosen the system defaults for
specific processes.
== Owner ==
* Name: [[User:Asosedkin| Alexander Sosedkin]], [[User:ueno|Daiki Ueno]]
* Email: asosedki@redhat.com
== Detailed Description ==
crypto-policies is an abstraction layer to enable centralized
configuration of system-wide cryptographic defaults across different
applications and libraries.
Presently, crypto-policies controls GnuTLS back-end using a
configuration file that starts from GnuTLS internal defaults (NORMAL)
and further blocks specific algorithms from it:
[overrides]
  insecure-hash = SHA1
  insecure-hash = MD5
  ...
  disabled-version = DTLS1.0
[priorities]
  SYSTEM=NORMAL
This approach has the following identified downsides:
1. Developers of applications using GnuTLS cannot override the
restrictions put in place by crypto-policies
(examples for such demand:
https://bugzilla.redhat.com/show_bug.cgi?id=1960763,
https://pagure.io/fesco/issue/2659),
turning them from a defaults to a hard cap on the set of algorithms.
2. Algorithms that will be implemented in future GnuTLS releases will
have to require a synchronized update with crypto-policies or risk
being inadvertently enabled.
Same applies to removing algorithms from GnuTLS NORMAL.
An alternative allowlisting-based configuration method and a matching
GnuTLS API extension to control it currently under development:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1427. The change
will turn the interface upside-down, explicitly allowlisting trusted
algorithms:
[global]
  override-mode = allowlist
[overrides]
  secure-hash = SHA256
  secure-hash = SHA384
  ...
  enabled-version = DTLS1.2
[priorities]
  SYSTEM=NONE
and offering an interface to control the restrictions both ways with new API:
int gnutls_protocol_mark_enabled(gnutls_protocol_t version);
  int gnutls_protocol_mark_disabled(gnutls_protocol_t version);
We'd like to announce our intention to bring this change into Fedora 36.
== Feedback ==
The authors of the document don't have enough external feedback to the
change, presumably because, in theory, it is limited to the internal
interface between crypto-policies and gnutls.
== Benefit to Fedora ==
It will be possible for the applications using GnuTLS library to
reenable algorithms beyond those allowed by the system-wide policy
without the need to relax the said global policy.
== Scope ==
* Proposal owners:
GnuTLS merge request with the new functionality must be landed
downstream: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427
This change will be safe to land in isolation.
Then crypto-policies will have to switch over to using the new
configuration file format/paradigm, that's where the regressions might
crop up in other components.
* Other developers:
The scope is limited to GnuTLS dependencies and transitive dependencies.
Ideally, the change should be transparent to the applications, and is
likely to go unnoticed by most GnuTLS applications. But if one flips a
ship upside down, something will fall and break, even if everything
should be, in theory, bolted down. Components that supply custom
priority strings to GnuTLS are the most risky category and should be
tested in these scenarios.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: no
== Upgrade/compatibility impact ==
No special upgrade considerations should be required.
== How To Test ==
Wait until the packages with the change are available, smoke-test
GnuTLS dependencies. No observable changes should happen.
Use cases and functionality that rely on components supplying custom
priority strings to GnuTLS are more likely to be affected than those
relying on the system defaults. For example, if a library depending on
GnuTLS enables PSK key exchanges with
gnutls_set_default_priority_append(), the functionality relying on
that should be smoke-tested.
== User Experience ==
Ideally, the change would be transparent even for developers for all
components besides gnutls and crypto-policies, let alone end-users.
OpenConnect users will finally be able to connect to endpoints stuck
with DTLS 0.9 once OpenConnect is updated to use the new API and warn
the users of the security issues of using old protocols. Other
applications using GnuTLS will be offered an opt-in choice to stray
from the system-wide defaults set by crypto-policies to interoperate
with legacy systems or import data using encryption not approved by
the system-wide policy.
== Dependencies ==
GnuTLS is a low-level package with a sizeable reverse dependency tree.
Out of "household" names, QEMU, libvirt, Samba, OpenConnect and Wget
came to mind first.
== Contingency Plan ==
* Contingency mechanism: revert to the previous denylisting
configuration file format / not switch to the new allowlisting one
* Contingency deadline: Fedora 36 Beta Freeze
* Blocks release? Unlikely, unless a major new issue with the
implementation will be uncovered.
== Documentation ==
Documentation on the new GnuTLS interface will be handled upstream.
Announcement of the fact that crypto-policies switches to the new
configuration file format in Fedora was intended to be covered by this
Fedora Change page.
== Release Notes ==
The change is not supposed to be user-visible; I only imagine it
getting to release notes in case of late-discovered bugs with the
implementation.
-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis