From Fedora Project Wiki
(Draft the initial version of StrongCryptoSettings3Forewarning1)
 
(Deprioritize testing FUTURE in favour of TEST-FEDORA39)
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<!-- Changes/StrongCryptoSettings3Forewarning1 -->
<!-- Changes/StrongCryptoSettings3Forewarning1 -->
= Strong crypto settings: phase 3, forewarning 1/3 =
= Strong crypto settings: phase 3, forewarning 1/2 =
 


== Summary ==
== Summary ==


TL;DR:
Cryptographic policies will be tightened in Fedora 38-39,
Cryptographic policies will be tightened in Fedora 38-39,
SHA-1 signatures will no longer be trusted by default.
SHA-1 signatures will no longer be trusted by default.
This is a forewarning filed for extra visibility.
Fedora 37 specifically doesn't come with any change of defaults,
Test your setup with FUTURE today and file bugs so you won't get bit by F38-39.
and this Fedora Change is an advance warning filed for extra visibility.
 
Test your setup with TEST-FEDORA39 today and file bugs so you won't get bit by Fedora 38-39.
As the next installment of our periodic tightening of cryptographic defaults,
we're intending to bringing several changes to Fedora 39.
The impact of them, notably distrusting SHA-1 signatures,
might be so profound we're smoothing the rollout in time
to give developers and maintainers ample time to react:
 
'''Fedora 36 [[StrongCryptoSettings3Forewarning1|Changes/StrongCryptoSettings3Forewarning1]]''':
* SHA-1 signatures are distrusted in FUTURE policy (opt-in)
* TEST-FEDORA39 policy is provided
 
Fedora 37 [[StrongCryptoSettings3Forewarning2|Changes/StrongCryptoSettings3Forewarning2]]:
* creating and verifying SHA-1 signatures is logged to ease reporting bugs
 
Fedora 38 [[StrongCryptoSettings3Forewarning3|Changes/StrongCryptoSettings3Forewarning3]]:
* 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/StrongCryptoSettings3]]:
* changes reach users
 
The plan is subject to change if it goes sideways somewhere along the way.
 


== Owner ==
== Owner ==
Line 46: Line 21:
== Current status ==
== Current status ==


[[Category:ChangePageIncomplete]]  
[[Category:ChangeAcceptedF37]]  
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 54: Line 29:
[[Category:SystemWideChange]]
[[Category:SystemWideChange]]


* Targeted release: [[Releases/<number> | Fedora Linux <number> ]]  
* Targeted release: [[Releases/37 | Fedora Linux 37 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 62: Line 37:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/SIASBM62XE6WJBNOA7H5CTOU3E6HNS32/ devel thread]
* Tracker bug: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2788 #2788]
* Release notes tracker: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2089811 #2089811]
 
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/841 #841]


== Detailed Description ==
== Detailed Description ==


Secure defaults are an evermoving target.
Secure defaults are an evermoving target.
Fedora 28 had [[StrongCryptoSettings|Changes/StrongCryptoSettings]].
Fedora 28 had [[Changes/StrongCryptoSettings|StrongCryptoSettings]].
Fedora 33 had [[StrongCryptoSettings2|Changes/StrongCryptoSettings2]].
Fedora 33 had [[Changes/StrongCryptoSettings2|StrongCryptoSettings2]].
Fedora 39 should have [[StrongCryptoSettings3|Changes/StrongCryptoSettings3]].
Fedora 39 should have [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]].
 
The impact of one upcoming change, notably distrusting SHA-1 signatures,
might be so profound we're smoothing the rollout in time
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 [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Forewarning1]]''':
* (was initially reserved to implement logging of SHA-1 signature operations)
 
Fedora 38 [[Changes/StrongCryptoSettings3Forewarning3|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 [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]]:
* changes reach users
 
The plan is subject to change if it goes sideways somewhere along the way.


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


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Test your applications with FUTURE policy.
Test your applications with TEST-FEDORA39 policy.
Move away from trusting SHA-1 signatures;
Move away from trusting SHA-1 signatures;
ideally in time for F38 branch-off,
ideally in time for F38 branch-off,
Line 170: Line 167:
2. distrust them by default and require explicit user opt-in to use a workaround
2. distrust them by default and require explicit user opt-in to use a workaround


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: https://pagure.io/releng/issue/10770
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->


Not sure if mass-rebuild is required if we land the change right after f38 branch-off. Maybe a "preview" mass-rebuild can be done with a special build in the F37 timeframe to cut down on F38 FTBFS.
Not sure if mass-rebuild is required if we land the change right after f38 branch-off. Maybe a "preview" mass-rebuild can be done with a special build in the Fedora 37 timeframe to cut down on Fedora 38 FTBFS.


* Policies and guidelines: update needed in time for F38
* Policies and guidelines: update needed in time for Fedora 38


CryptoPolicies section of the packaging guidelines
CryptoPolicies section of the packaging guidelines
Line 187: Line 184:
* Trademark approval: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)


* Alignment with Objectives: not with F36-era ones
* Alignment with Objectives: not with Fedora 37-era ones




== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==


Nothing will change for Fedora 36 by default, the change is opt-in for now.
Nothing will change for Fedora 37 by default, the change is opt-in for now.




== How To Test ==
== How To Test ==


On a Fedora 36 system,
=== Testing actively ===
install crypto-policies-scripts package and switch to a more restrictive policy
 
with either `update-crypto-policies --set FUTURE`
Install crypto-policies-scripts package and switch to a more restrictive policy
or `update-crypto-policies --set TEST-FEDORA39`.
with `update-crypto-policies --set TEST-FEDORA39`.


Proceed to use the system as usual,
Proceed to use the system as usual,
Line 207: Line 204:
Verify that the broken functionality works again
Verify that the broken functionality works again
if you the policy is relaxed back
if you the policy is relaxed back
with `update-crypto-policies --set FUTURE:SHA-1`,
with, e.g., `update-crypto-policies --set TEST-FEDORA39:SHA1`,
file bug reports against the affected components if not filed already.
file bug reports against the affected components if not filed already.
Please start your ticket title with `StrongCryptoSettings3: `,
Please start your ticket title with `StrongCryptoSettings3: `,
mention this change page, the version of crypto-policies package
mention this change page, the version of crypto-policies package
and the policies under which your workflow does and does not work.
and the policies under which your workflow does and does not work.
Especially brave souls can dare to try
`update-crypto-policies --set FUTURE` instead,
though this policy is more aggressive than the upcoming defaults.
=== Testing passively ===
Install a special logging tool from
https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer
Run it and proceed to use your system.
Once the tool notifies you about
about soon-to-be-blocked SHA-1 signature operations,
identify the component and actions leading to these operations,
verify that repeating them leads to logging more entries.
Ideally also verify that switching to a stricter policy breaks the workflow.
File bug reports against the affected components if not filed already.
Please start your ticket title with `StrongCryptoSettings3: `
and link to this change page.




Line 218: Line 234:
Things will break.
Things will break.
All kinds of things depending on SHA-1 signatures, openly and secretly.
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.'''
* 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 rawhide they'll break by default.
* On Fedora 38 released they'll behave like in Fedora 37.
* On Fedora 38 released they'll behave like in Fedora 37.
Line 227: Line 242:
== Dependencies ==
== Dependencies ==


No reverse dependencies of openssl have to react in time for Fedora 36.
While it would be welcome,
no reverse dependencies of openssl have to react in time for Fedora 37,
where the change is opt-in preview only.
For now, test, file bugs and spark discussions.
For now, test, file bugs and spark discussions.
A small coordinated change with openssl is required.
A small coordinated change with openssl is required.
Line 234: Line 251:
== Contingency Plan ==
== Contingency Plan ==


* Contingency mechanism: not needed for F36
* Contingency mechanism: not needed for F37
* Contingency deadline: not needed for F36
* Contingency deadline: not needed for F37
* Blocks release? no
* Blocks release? no


Line 252: Line 269:
== Release Notes ==
== Release Notes ==


Fedora 36-38: trusting SHA-1 signatures is deprecated,
https://pagure.io/fedora-docs/release-notes/issue/829
users are encouraged to test with restrictive policies and file bugs.
 
Fedora 39: SHA-1 signatures are no longer trusted by default.

Latest revision as of 14:22, 31 May 2022

Strong crypto settings: phase 3, forewarning 1/2

Summary

Cryptographic policies will be tightened in Fedora 38-39, SHA-1 signatures will no longer be trusted by default. Fedora 37 specifically doesn't come with any change of defaults, and this Fedora Change is an advance warning filed for extra visibility. Test your setup with TEST-FEDORA39 today and file bugs so you won't get bit by Fedora 38-39.

Owner


Current status

Detailed Description

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

The impact of one upcoming change, notably distrusting SHA-1 signatures, might be so profound we're smoothing the rollout in time 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.

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 (not 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 (not 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. 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.


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 https://datatracker.ietf.org/doc/rfc8996], 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 TEST-FEDORA39 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

Not sure if mass-rebuild is required if we land the change right after f38 branch-off. Maybe a "preview" mass-rebuild can be done with a special build in the Fedora 37 timeframe to cut down on Fedora 38 FTBFS.

  • Policies and guidelines: update needed in time for Fedora 38

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

Nothing will change for Fedora 37 by default, the change is opt-in for now.


How To Test

Testing actively

Install crypto-policies-scripts package and switch to a more restrictive policy with update-crypto-policies --set TEST-FEDORA39.

Proceed to use the system as usual, identify the workflows which are broken by this change.

Verify that the broken functionality works again if you the policy is relaxed back with, e.g., update-crypto-policies --set TEST-FEDORA39:SHA1, 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.

Especially brave souls can dare to try update-crypto-policies --set FUTURE instead, though this policy is more aggressive than the upcoming defaults.


Testing passively

Install a special logging tool from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer Run it and proceed to use your system. Once the tool notifies you about about soon-to-be-blocked SHA-1 signature operations, identify the component and actions leading to these operations, verify that repeating them leads to logging more entries. Ideally also verify that switching to a stricter policy breaks the workflow. File bug reports against the affected components if not filed already. Please start your ticket title with StrongCryptoSettings3: and link to this change page.


User Experience

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

  • On Fedora 37 they'll break opt-in.
  • 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

While it would be welcome, no reverse dependencies of openssl have to react in time for Fedora 37, where the change is opt-in preview only. For now, test, file bugs and spark discussions. A small coordinated change with openssl is required.


Contingency Plan

  • Contingency mechanism: not needed for F37
  • Contingency deadline: not needed for F37
  • Blocks release? no


Documentation

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


Release Notes

https://pagure.io/fedora-docs/release-notes/issue/829