On Fri, 2022-04-29 at 17:49 -0400, Ben Cotton wrote: > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1 > > > == 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 FUTURE today and file bugs so you won't get bit > by Fedora 38-39. >
Changes like this have been very disruptive in the past because they haven't been completely thought through. Can we please make 100% sure these policies are not going to break things like VPN clients in the way that we have before. If you want to distrust a server SSL certificate because it's using SHA1, that's OK. But make the crypto libraries report that just like any *other* untrusted cert, in a way which allows the application (and ultimately the user) to decide to accept it this time. The blanket refusal we had in previous iterations was awful. Likewise for *client* certificates. If the server issues us a SHA1-based certificate and wants us to authenticate with it, that's the server's problem. Making in-distro software refuse to use that client cert just pushes uses back to using proprietary software and is overall detrimental to our users. I understand there has been some progress on fixing the crypto libraries to get this right, but I'd like FESCo to make those an absolute condition on any further crypto pedanty in Fedora — those things *have* to work on a per-application, user-overridable basis without introducing regressions, or the Feature is reverted. > == Owner == > > * Name: [[User:Asosedkin| Alexander Sosedkin]] > * Email: > asose...@redhat.com > > > > == 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]]. > > 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|StrongCryptoSettings3Fore > warning1]]''': > * (was initially reserved to implement logging of SHA-1 signature > operations) > > Fedora 38 > [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Fore > warning2]]: > * 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: > 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 == > > [ > 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 [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 [ > 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 > > * 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 | 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: 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 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 === > > 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 | > SHA1SignaturesGuidance]]. > Packaging guidelines should be modified accordingly. > > == Release Notes == > > https://pagure.io/fedora-docs/release-notes/issue/829 > > > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > _______________________________________________ > devel-announce mailing list -- > devel-annou...@lists.fedoraproject.org > > To unsubscribe send an email to > devel-announce-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
