|
|
| Line 1: |
Line 1: |
| <!-- Changes/StrongCryptoSettings3Forewarning3 --> | | <!-- Changes/StrongCryptoSettings3Forewarning3 --> |
| = Strong crypto settings: phase 3, forewarning 3/3 =
| |
|
| |
|
| | | The page is no longer needed since the Change filing plan has shifted one release earlier. |
| == Summary ==
| | See |
| | | [[Changes/StrongCryptoSettings3Forewarning1|StrongCryptoSettings3Forewarning1]] |
| TL;DR:
| | [[Changes/StrongCryptoSettings3Forewarning2|StrongCryptoSettings3Forewarning2]] |
| Cryptographic policies will be tightened in Fedora '''38'''-39,
| | and [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]]. |
| SHA-1 signatures will no longer be trusted by default.
| |
| Test your setup with FUTURE today and file bugs so you won't get bit by F'''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 [[Changes/StrongCryptoSettings3Forewarning1|StrongCryptoSettings3Forewarning1]]:
| |
| * SHA-1 signatures are distrusted in FUTURE policy (opt-in)
| |
| * TEST-FEDORA39 policy is provided
| |
| * creating and verifying SHA-1 signatures can be logged to ease reporting bugs
| |
| | |
| Fedora 37 [[Changes/StrongCryptoSettings3Forewarning2|StrongCryptoSettings3Forewarning2]]:
| |
| * (was initially reserved to implement logging of SHA-1 signature operations)
| |
| | |
| '''Fedora 38 [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Forewarning3]]''':
| |
| * polices 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.
| |
| | |
| | |
| == Owner ==
| |
| | |
| * Name: [[User:Asosedkin| Alexander Sosedkin]]
| |
| * Email: asosedki@redhat.com
| |
| <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
| |
| * FESCo shepherd: [[User:FASAccountName| Shepherd name]] <email address>
| |
| -->
| |
| | |
| | |
| == Current status ==
| |
| | |
| [[Category:ChangePageIncomplete]]
| |
| <!-- When your change proposal page is completed and ready for review and announcement -->
| |
| <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
| |
| <!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
| |
| <!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
| |
| | |
| [[Category:SystemWideChange]]
| |
| | |
| * Targeted release: [[Releases/<number> | Fedora Linux <number> ]]
| |
| * 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
| |
| Bugzilla state meanings:
| |
| ASSIGNED -> accepted by FESCo with ongoing development
| |
| MODIFIED -> change is substantially done and testable
| |
| ON_QA -> change is fully code complete
| |
| -->
| |
| * 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 [[Changes/StrongCryptoSettings|StrongCryptoSettings]].
| |
| Fedora 33 had [[Changes/StrongCryptoSettings2|StrongCryptoSettings2]].
| |
| Fedora 39 should have [[Changes/StrongCryptoSettings3|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.
| |
| 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 ==
| |
| | |
| [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP A discussion]
| |
| has been raised on fedora-devel,
| |
| [https://lwn.net/Articles/887832 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 [https://datatracker.ietf.org/doc/rfc8996 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 [https://eprint.iacr.org/2020/014 weak] cryptography,
| |
| raising the security of the distribution moving forward.
| |
| | |
| | |
| == Scope ==
| |
| | |
| * Proposal owners: implement changes described in Summary and Dependencies sections
| |
| <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
| |
| | |
| * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
| 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 | 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
| |
| | |
| * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
| <!-- 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 -->
| |
| | |
| 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.
| |
| | |
| * 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 F36-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 ==
| |
| | |
| == How To Test ==
| |
| | |
| === Testing actively ===
| |
| | |
| On a Fedora 36-37 or ''38 released'' system,
| |
| install crypto-policies-scripts package and switch to a more restrictive policy
| |
| with either `update-crypto-policies --set FUTURE`
| |
| or `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 FUTURE:SHA-1`,
| |
| 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.
| |
| | |
| | |
| === Testing passively ===
| |
| | |
| On a Fedora 36-37 or ''38 released'' system, 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.
| |
| | |
| On a Fedora 38 pre-Beta, SHA-1 signature operations will be blocked by default.
| |
| | |
| == 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 ==
| |
| | |
| A small coordinated change with openssl is required.
| |
| In ''Fedora 38'' (pre-Beta, then Fedora 39),
| |
| openssl should start distrusting SHA-1 signatures
| |
| when used with no configuration file.
| |
| This does not affect the majority of scenarios,
| |
| only applications that do not follow system-wide cryptographic policies.
| |
| | |
| All 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
| |
| * Contingency deadline: Fedora 39 Beta Freeze
| |
| * Blocks release? Yes
| |
| | |
| | |
| == Documentation ==
| |
| | |
| <!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. -->
| |
| | |
| Workaround API
| |
| should be added to [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
| |
| Packaging guidelines should be modified accordingly.
| |
| | |
| <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
| | |
| | |
| == Release Notes ==
| |
| | |
| Fedora 36-38: trusting SHA-1 signatures is deprecated,
| |
| users are encouraged to test with restrictive policies and file bugs.
| |
| | |
| Fedora 39: SHA-1 signatures are no longer trusted by default.
| |
