Changes/GnutlsAllowlisting

Switch GnuTLS to allowlisting

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: Alexander Sosedkin, Daiki Ueno
• Email: asosedki@redhat.com

Current status

• Targeted release: Fedora Linux 36
• Last updated: 2021-12-13
• devel thread
• FESCo issue: #2712
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

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: [1]

Release engineering coordination is not required.

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