From Fedora Project Wiki

< Changes
Revision as of 07:41, 24 August 2022 by Asosedkin (talk | contribs) (fix links to Changes pages)

Strong crypto settings: phase 3, final stage

Summary

Cryptographic policies will be tightened in Fedora 38-39, SHA-1 signatures will no longer be trusted by default. The change is an opt-in in Fedora 36-37, a "jump scare" in Fedora 38 where it's reverted before the release, and now, in Fedora 39 it'll finally reach the users.

Owner


Current status

  • Targeted release: Fedora Linux 39
  • Last updated: 2022-08-24
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>


Detailed Description

Secure defaults are an evermoving target. Fedora 28 had StrongCryptoSettings. Fedora 33 had StrongCryptoSettings2. Fedora 39 should have StrongCryptoSettings3.

By Fedora 39, the policies will be, in TLS perspective: 

LEGACY
 MACs: All HMAC with SHA1 or better + all modern MACs (Poly1305 etc.)
 Curves: all prime >= 255 bits (including Bernstein curves)
 Signature algorithms: SHA-1 hash or better (no DSA)
 Ciphers: all available > 112-bit key, >= 128-bit block (no RC4 or 3DES)
 Key exchange: ECDHE, RSA, DHE (no DHE-DSS)
 DH params size: >=2048
 RSA params size: >=2048
 TLS protocols: TLS >= 1.2

DEFAULT
 MACs: All HMAC with SHA1 or better + all modern MACs (Poly1305 etc.)
 Curves: all prime >= 255 bits (including Bernstein curves)
 Signature algorithms: with SHA-224 hash or better (no DSA)
 Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20, including AES-CBC)
 Key exchange: ECDHE, RSA, DHE (no DHE-DSS)
 DH params size: >= 2048
 RSA params size: >= 2048
 TLS protocols: TLS >= 1.2

FUTURE
 MACs: All HMAC with SHA256 or better + all modern MACs (Poly1305 etc.)
 Curves: all prime >= 255 bits (including Bernstein curves)
 Signature algorithms: SHA-256 hash or better (no DSA)
 Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers
 Key exchange: ECDHE, DHE
 DH params size: >= 3072
 RSA params size: >= 3072
 TLS protocols: TLS >= 1.2

The flagship change this time will be distrusting SHA-1 signatures on the cryptographic library level, affecting more than just TLS.

OpenSSL will start blocking signature creation and verification by default, with the fallout anticipated to be wide enough for us to roll out the change across multiple cycles with multiple forewarnings to give developers and maintainers ample time to react:

Fedora 36:

  • SHA-1 signatures are distrusted in FUTURE policy (opt-in)
  • TEST-FEDORA39 policy is provided
  • creating and verifying SHA-1 signatures is logged to ease reporting bugs

Fedora 37 StrongCryptoSettings3Forewarning1:

  • (was initially reserved to implement logging of SHA-1 signature operations)

Fedora 38 StrongCryptoSettings3Forewarning2:

  • policies are updated, most notably
  • SHA-1 signatures are distrusted in DEFAULT policy
  • changes are reverted in branched f38 in time for Beta and do not reach users

Fedora 39 StrongCryptoSettings3:

  • changes reach users

The plan is subject to change if it goes sideways somewhere along the way.

So, in Fedora 36, 37 and 38 released distrusting SHA-1 signatures will be opt-in. In Fedora 38 rawhide and Fedora 39 distrusting SHA-1 signatures will happen by default. Just file bugs.


Feedback

A discussion has been raised on fedora-devel, a summary is available on LWN.

A change has the potential to prove disruptive and controversial, with much effort being focused on stretching it out in time.

There seems to be a consensus that the change has to be done eventually, but the ideal means of implementing it are in no way clear. The decision to discover code reliant on SHA-1 signatures by blocking creation/verification has not gathered many fans, but not many alternative proposals have been raised in return. A notable one, making the library somehow log the offending operations, has been incorporated in the proposal, though the effectiveness of it is yet to be seen in practice. Another notable takeaway point is the need to call for testing, which would be done in form of writing four Fedora Changes and testing SHA-1 signature distrusting during Fedora 37 & 38 Test Days. The change owner doesn't see the plan as an ideal one and continues to be open for feedback.


Benefit to Fedora

Fedora 39 will ship with more secure defaults to better match the everchanging landscape of cryptographic practices. TLS 1.0 / 1.1 protocol version will be disabled as they're deprecated, minimum key sizes will be raised to keep up with the computational advances etc.

Distrusting SHA-1 signatures specifically is expected to trigger a topical distribution-wide crackdown on weak cryptography, raising the security of the distribution moving forward.


Scope

  • Proposal owners: implement changes described in Summary and Dependencies sections
  • Other developers:

Test your applications with FUTURE policy. Move away from trusting SHA-1 signatures; ideally in time for F38 branch-off, for F39 release at the latest.

Follow SHA1SignaturesGuidance: 1. move away from trusting SHA-1 signatures entirely, or 2. distrust them by default and require explicit user opt-in to use a workaround

Mass rebuild will not be needed, as change will be introduced in Fedora 38 rawhide (and reverted in Fedora 38 release, but not Fedora 39 release, so it'll be present in 39 from the start).

  • Policies and guidelines: update needed

CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default and provide guidance for openssl and gnutls. Components using workaround APIs must not use them without explicit user opt-in and must be added to a list of applications using a workaround API.

  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives: not with Fedora 37-era ones


Upgrade/compatibility impact

See "User experience".

Upgrade-time issues aren't specifically anticipated; if any were to arise, testing should find them in F38-times, to be fixed by F39 release at the latest.

Administrators willing to sacrifice security can apply LEGACY or FEDORA38 policies.


How To Test

Proceed to use the system as usual, identify the workflows which are broken by blocking SHA-1 signature creation/verification, ideally also verify that update-crypto-policies --set FEDORA38 fixes them, file bug reports against the affected components if not filed already. Please start your ticket title with StrongCryptoSettings3: , mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work.

User Experience

Things will break. All kinds of things depending on SHA-1 signatures, openly and secretly.

  • On Fedora 36 they'll break opt-in.
  • On Fedora 37 they'll break opt-in, but it'll be possible to log them instead.
  • On Fedora 38 rawhide they'll break by default.
  • On Fedora 38 released they'll behave like in Fedora 37.
  • On Fedora 39 they'll break by default again, including the released version.


Dependencies

All reverse dependencies of core cryptographic libraries are affected, especially openssl ones relying on SHA-1 signatures.


Contingency Plan

  • Contingency mechanism: Change owner can decide to defer the change reaching users from Fedora 39 released to a later release with a revert like the one done in Fedora 38
  • Contingency deadline: Fedora 39 Beta Freeze
  • Blocks release? Yes


Documentation

Workaround API should be added to SHA1SignaturesGuidance. Packaging guidelines should be modified accordingly.


Release Notes

We'll need something to the tune of:

Cryptographic dependencies have been tightened. SHA-1 signatures are no longer trusted by default. FEDORA38 cryptographic policy or SHA1 cryptographic subpolicies can be used to opt out of the changes fully or partially at the expense of the system's security.

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/StrongCryptoSettings3&oldid=653247"