Fwd: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)

[Derek Weitzel]

anything we need to worry about here?  I know our default algorithms are RS256 (RSA with SHA256) and EC256.  If I remember my cryptography correctly, I think we’re good for now?

- Derek

Begin forwarded message:

From: Ben Cotton <bco...@redhat.com>

Subject: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)

Date: August 29, 2022 at 1:30:44 PM CDT

To: devel-a...@lists.fedoraproject.org

Cc: Development discussions related to Fedora <de...@lists.fedoraproject.org>

Reply-To: de...@lists.fedoraproject.org

https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2

== Summary ==

Cryptographic policies will be tightened in Fedora ''38''-39,
SHA-1 signatures will no longer be trusted by default.
Fedora ''38'' will do a "jump scare", introducing the change but then
reverting it in time for Beta.
Test your setup with TEST-FEDORA39 today and file bugs in advance so
you won't get bit by Fedora ''38''-39.


== Owner ==

* Name: [[User:Asosedkin| Alexander Sosedkin]]
* Email: asos...@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]].

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

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.


== Feedback ==

[https://lists.fedoraproject.org/archives/list/de...@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

* 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 | 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 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 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 ''Fedora 38''-times,
to be fixed by Fedora 39 release at the latest.

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


== How To Test ==

=== Testing actively ===

On a ''Fedora 38 rawhide'' system,
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 ===

On a ''Fedora 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.


== User Experience ==

Things will break.
All kinds of things depending on SHA-1 signatures, openly and secretly.
* On Fedora 36-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 ==

A small coordinated change with openssl is required.
In Fedora 38,
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 reverse dependencies of core cryptographic libraries are affected,
especially openssl ones relying on SHA-1 signatures.


== Contingency Plan ==

* Contingency mechanism: not needed for F38, change will be reverted
before Beta anyway
* Contingency deadline: not needed for F38, change will be reverted
before Beta anyway
* Blocks release? No


== Documentation ==
Workaround API
should be added to [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
Packaging guidelines should be modified accordingly.


== Release Notes ==

To be done, similarly to
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-a...@lists.fedoraproject.org
To unsubscribe send an email to devel-anno...@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-a...@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Bockelman, Brian]

Should be good.

- For RSA / DH params, that appears to be the same as RHEL8

- SHA-1 signatures on IGTF CAs might be a problem but I assume it's tracked at the IGTF level?

Brian

--
To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@sciauth.org.