F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)

[Ben Cotton]

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.

== Owner ==

* Name: [[User:Asosedkin| Alexander Sosedkin]]
* Email: [e-mail]

== 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|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:
 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/[e-mail]/...
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

[David Woodhouse]

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:
>
> [e-mail]
>
> == 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/[e-mail]/...
>
> 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]]:
> move away from trusting SHA-1 signatures entirely, or
> 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 -- 
> [e-mail]
>
> To unsubscribe send an email to 
> [e-mail]
>
> 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/[e-mail]...
>
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

[Dan Čermák]

Hi David,

David Woodhouse  writes:
> 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.

They are going to break things, but Ubuntu 22.04 deprecated SHA1
signatures already, so it's very likely that a good chunk of the fallout
will be cleared by the time Fedora 38 and 39 ship.

Cheers,

Dan

[Kevin P. Fleming]

On Sun, May 1, 2022 at 12:14 PM Dan Čermák 
wrote:
> They are going to break things, but Ubuntu 22.04 deprecated SHA1
> signatures already, so it's very likely that a good chunk of the fallout
> will be cleared by the time Fedora 38 and 39 ship.

In a similar (parallel) discussion related to future RHEL, it has been
found this change also breaks resolution of many DNSSEC-secured domains
which are still using SHA1 signatures. It is impossible to know how long it
will be before those domains upgrade to better signatures, and at the
moment it's rather challenging for resolvers to be able to determine that
the resolution failure was caused by local policy instead of an actual
invalid signature.

[Chris Adams]

Once upon a time, Kevin P. Fleming  said:
> In a similar (parallel) discussion related to future RHEL, it has been
> found this change also breaks resolution of many DNSSEC-secured domains
> which are still using SHA1 signatures. It is impossible to know how long it
> will be before those domains upgrade to better signatures, and at the
> moment it's rather challenging for resolvers to be able to determine that
> the resolution failure was caused by local policy instead of an actual
> invalid signature.

That's a really unacceptable break, and will just lead to people saying
"don't use Red Hat stuff for DNS servers".  If the public open-resolvers
(Google, Cloudflare, etc.) accept it, then it needs to continue to work on
RHEL/CentOS/Fedora.

[Gary Buhrmaster]

On Mon, May 2, 2022 at 12:54 PM Kevin P. Fleming  wrote:
> In a similar (parallel) discussion related to future RHEL, it has been found this change also breaks resolution of many DNSSEC-secured domains which are still using SHA1 signatures. It is impossible to know how long it will be before those domains upgrade to better signatures, and at the moment it's rather challenging for resolvers to be able to determine that the resolution failure was caused by local policy instead of an actual invalid signature.

It has been some time since I saw a report, but
a few years ago >200 TLDs were using SHA-1.
And while all have been encouraged to change
(ICANN, among others, have been pointing out
that while SHA-1, today, is not entirely broken,
it could end up being some future emergency
deprecation, and when the root itself was signed
it started with SHA-256), change tends to be slow
when the domain administrator wants to be sure
not to break existing usage.

I think you have pointed out an important issue
in that unless the app implements a lot of the
logic to validate the entire chain they are likely
to just break, and not produce useful warnings,
and having (for example) openssl produce the
warnings is differently problematic (to where
should the message go, for example).  There is
really no good answer here, as continuing
to use crypto policies that are known (or should
be known) to be weak is not a good answer
either (heck, there are still apps using des).
Damned if you want to be (more) secure,
damned if you want to be insecure.  I prefer
to be damned for being secure, but I do
understand there are others who prefer
otherwise.

Gary

[Florian Weimer]

* Kevin P. Fleming:
> In a similar (parallel) discussion related to future RHEL, it has been
> found this change also breaks resolution of many DNSSEC-secured
> domains which are still using SHA1 signatures. It is impossible to
> know how long it will be before those domains upgrade to better
> signatures, and at the moment it's rather challenging for resolvers to
> be able to determine that the resolution failure was caused by local
> policy instead of an actual invalid signature.

At least that's a solvable problem: perform DNSSEC validation (to
prevent actual attacks) and pretend to clients that you didn't do it (to
avoid relying on signatures which aren't policy-confiorming).  DNSSEC
supports that approach quite well for ordinary record types.  It's
different from the web, where https:// and http:// are not equivalent in
practice for many domains, and the schema is also visible to Javascript.

Thanks,
Florian

[Chris Adams]

Once upon a time, Florian Weimer  said:
> At least that's a solvable problem: perform DNSSEC validation (to
> prevent actual attacks) and pretend to clients that you didn't do it (to
> avoid relying on signatures which aren't policy-confiorming).  DNSSEC
> supports that approach quite well for ordinary record types.  It's
> different from the web, where https:// and http:// are not equivalent in
> practice for many domains, and the schema is also visible to Javascript.

A validating resolver only returns validated results to clients.
There's no "validate but pretend you didn't" mode - if you are a
validating resolver, you either return the record and NOERROR, or you
set SERVFAIL.

Different servers have some ways to override validation, typically on a
per-name basis (so when foo.com breaks their DNSSEC but you have too
many customers that need to get to foo.com to leave it broken).  I'm not
aware of any that any policy hooks to do something similar on an
algorithm basis, and definitely not to do the validation but then
pretend you didn't.  If you want to propose such behavior, you'll need
to get that upstream first (at least in BIND, Unbound, and dnsmasq).

[Kevin P. Fleming]

On Mon, May 2, 2022 at 3:28 PM Chris Adams  wrote:
> Once upon a time, Florian Weimer  said:
> > At least that's a solvable problem: perform DNSSEC validation (to
> > prevent actual attacks) and pretend to clients that you didn't do it (to
> > avoid relying on signatures which aren't policy-confiorming).  DNSSEC
> > supports that approach quite well for ordinary record types.  It's
> > different from the web, where https:// and http:// are not equivalent in
> > practice for many domains, and the schema is also visible to Javascript.
>
> A validating resolver only returns validated results to clients.
> There's no "validate but pretend you didn't" mode - if you are a
> validating resolver, you either return the record and NOERROR, or you
> set SERVFAIL.
>
> Different servers have some ways to override validation, typically on a
> per-name basis (so when foo.com breaks their DNSSEC but you have too
> many customers that need to get to foo.com to leave it broken).  I'm not
> aware of any that any policy hooks to do something similar on an
> algorithm basis, and definitely not to do the validation but then
> pretend you didn't.  If you want to propose such behavior, you'll need
> to get that upstream first (at least in BIND, Unbound, and dnsmasq).

And that behavior would also require that the underlying library be able to
expose the fact that the signature validation failed due to local policy,
so that the resolver could make use of that information.

It sounds like the proposal here would be:

* Do the validation; if it succeeds, tell the client (if they asked).

* If it fails, but due to local policy, then tell the client no validation
was attempted (if they asked).

* If it fails, but not due to local policy, then tell the client SERVFAIL.

[Florian Weimer]

* Chris Adams:
> Once upon a time, Florian Weimer  said:
> > At least that's a solvable problem: perform DNSSEC validation (to
> > prevent actual attacks) and pretend to clients that you didn't do it (to
> > avoid relying on signatures which aren't policy-confiorming).  DNSSEC
> > supports that approach quite well for ordinary record types.  It's
> > different from the web, where https:// and http:// are not equivalent in
> > practice for many domains, and the schema is also visible to Javascript.
>
> A validating resolver only returns validated results to clients.
> There's no "validate but pretend you didn't" mode - if you are a
> validating resolver, you either return the record and NOERROR, or you
> set SERVFAIL.

You can return NOERROR without the AD bit.  That's what I meant.

That's different from HTTPS: you can't pretend to a web page you
downloaded over HTTPS that it came in via HTTP.

Thanks,
Florian

[Clemens Lang]

Hi,
> > On Fri, 2022-04-29 at 17:49 -0400, Ben Cotton wrote:
> >
> > 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.

This is the reason why the proposal contains extensive methods to test
whether things are going to break by modifying the crypto-policy or using
bpftrace. Unfortunately there are hundreds of packages that depend on
cryptographic libraries, and millions of different configurations out there.
We can’t know ahead of time which ones of them are going to break, but the
proposal provides tools and a long transition period to identify and fix
them.
> Dan Čermák  wrote:
>
> They are going to break things, but Ubuntu 22.04 deprecated SHA1
> signatures already, so it's very likely that a good chunk of the fallout
> will be cleared by the time Fedora 38 and 39 ship.

This isn’t going to help our cause, but this isn’t correct from what I can
see. The Ubuntu 22.04 release notes [1] say:

"In particular, certificates using SHA1 or MD5 as hash algorithms are now
invalid under the default security level.”

Note that this only affects *certificates*, while our changes affect *all
signatures made with SHA1*, not just those in certificates.

I’ve also checked the published source package for Ubuntu, and it seems they
are just setting SECLEVEL to 2 plus raising the default TLS version to 1.2
when SECLEVEL is 2.

In conclusion: Ubuntu isn’t ahead of us here.

[1]: https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668

[David Woodhouse]

On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
> This is the reason why the proposal contains extensive methods to test
> whether things are going to break by modifying the crypto-policy or using
> bpftrace. Unfortunately there are hundreds of packages that depend on
> cryptographic libraries, and millions of different configurations out there.
> We can’t know ahead of time which ones of them are going to break, but the
> proposal provides tools and a long transition period to identify and fix
> them.

When changes like this broke things for users in the past, we talked
about a way to present the "insufficient crypto/digest/protocol" as
just another failure like server certificate validation failures, so
the application/user can *choose* to accept and proceed, in real time.

I'd like to see that as a *condition* of acceptance of further
restrictions in the policy.

I really don't want us continuing to break things for Fedora users and
driving them back to the proprietary VPN clients.

I am pleased to see some progress on this front with 
https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting but it isn't
clear to me that this gives us what we need. We *want* to warn users
that their VPN server doesn't meet modern crypto standards. We don't
want to just blindly re-enable ancient crap and have it silently work.
But we also do *need* it to work, after we've warned the user about it.

Which is why handling it like a certificate validation failure seems to
be the right answer, but I'm happy to explore other solutions... but
preferably *not* solutions like "manually set
GNUTLS_SYSTEM_PRIORTY_FILE=/dev/null in your Fedora package to
explicitly override all the Fedora crypto policies". That suggestion 
made me sad... :)

[Demi Marie Obenour]

On 5/3/22 18:41, David Woodhouse wrote:
> On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
> > This is the reason why the proposal contains extensive methods to test
> > whether things are going to break by modifying the crypto-policy or using
> > bpftrace. Unfortunately there are hundreds of packages that depend on
> > cryptographic libraries, and millions of different configurations out there.
> > We can’t know ahead of time which ones of them are going to break, but the
> > proposal provides tools and a long transition period to identify and fix
> > them.
>
> When changes like this broke things for users in the past, we talked
> about a way to present the "insufficient crypto/digest/protocol" as
> just another failure like server certificate validation failures, so
> the application/user can *choose* to accept and proceed, in real time.
>
> I'd like to see that as a *condition* of acceptance of further
> restrictions in the policy.

Agreed — with one caveat.  It is quite possible that support for
some ancient protocols may be outright removed from upstream projects.
In that case, there is nothing Fedora can do.
> I really don't want us continuing to break things for Fedora users and
> driving them back to the proprietary VPN clients.
>
> I am pleased to see some progress on this front with 
> https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting but it isn't
> clear to me that this gives us what we need. We *want* to warn users
> that their VPN server doesn't meet modern crypto standards. We don't
> want to just blindly re-enable ancient crap and have it silently work.
> But we also do *need* it to work, after we've warned the user about it.
>
> Which is why handling it like a certificate validation failure seems to
> be the right answer, but I'm happy to explore other solutions... but
> preferably *not* solutions like "manually set
> GNUTLS_SYSTEM_PRIORTY_FILE=/dev/null in your Fedora package to
> explicitly override all the Fedora crypto policies". That suggestion 
> made me sad... :)

I agree wholeheartedly.

[Alexander Sosedkin]

On Wed, May 4, 2022 at 12:43 AM David Woodhouse  wrote:
> On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
> > This is the reason why the proposal contains extensive methods to test
> > whether things are going to break by modifying the crypto-policy or using
> > bpftrace. Unfortunately there are hundreds of packages that depend on
> > cryptographic libraries, and millions of different configurations out there.
> > We can’t know ahead of time which ones of them are going to break, but the
> > proposal provides tools and a long transition period to identify and fix
> > them.
>
> When changes like this broke things for users in the past, we talked
> about a way to present the "insufficient crypto/digest/protocol" as
> just another failure like server certificate validation failures, so
> the application/user can *choose* to accept and proceed, in real time.
>
> I'd like to see that as a *condition* of acceptance of further
> restrictions in the policy.
>
> I really don't want us continuing to break things for Fedora users and
> driving them back to the proprietary VPN clients.
>
> I am pleased to see some progress on this front with
> https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting but it isn't
> clear to me that this gives us what we need. We *want* to warn users
> that their VPN server doesn't meet modern crypto standards. We don't
> want to just blindly re-enable ancient crap and have it silently work.
> But we also do *need* it to work, after we've warned the user about it.

If the error returned from GnuTLS isn't enough to infer
that you should make the user opt-in into a legacy algorithm
and then counter the restriction on the next attempt with
a priority string extension or gnutls_protocol_mark_enabled,
please file a bug with GnuTLS and describe your case.
Your continued input would be appreciated.
Same with the other libraries if you meant other libraries.

If you don't want to spend a connection on just probing,
but instead prefer to connect no matter what
and then query what has been negotiated
to make the warn/abort decisions on the application layer
that should also be possible.
> Which is why handling it like a certificate validation failure seems to
> be the right answer, but I'm happy to explore other solutions... but
> preferably *not* solutions like "manually set
> GNUTLS_SYSTEM_PRIORTY_FILE=/dev/null in your Fedora package to
> explicitly override all the Fedora crypto policies". That suggestion
> made me sad... :)

+1, this is not the way

[Vít Ondruch]

Dne 04. 05. 22 v 9:32 Alexander Sosedkin napsal(a):
> On Wed, May 4, 2022 at 12:43 AM David Woodhouse  wrote:
> > On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
> > > This is the reason why the proposal contains extensive methods to test
> > > whether things are going to break by modifying the crypto-policy or using
> > > bpftrace. Unfortunately there are hundreds of packages that depend on
> > > cryptographic libraries, and millions of different configurations out there.
> > > We can’t know ahead of time which ones of them are going to break, but the
> > > proposal provides tools and a long transition period to identify and fix
> > > them.
> >
> > When changes like this broke things for users in the past, we talked
> > about a way to present the "insufficient crypto/digest/protocol" as
> > just another failure like server certificate validation failures, so
> > the application/user can *choose* to accept and proceed, in real time.
> >
> > I'd like to see that as a *condition* of acceptance of further
> > restrictions in the policy.
> >
> > I really don't want us continuing to break things for Fedora users and
> > driving them back to the proprietary VPN clients.
> >
> > I am pleased to see some progress on this front with
> > https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting but it isn't
> > clear to me that this gives us what we need. We *want* to warn users
> > that their VPN server doesn't meet modern crypto standards. We don't
> > want to just blindly re-enable ancient crap and have it silently work.
> > But we also do *need* it to work, after we've warned the user about it.
>
> If the error returned from GnuTLS isn't enough to infer

While I don't know much about GnuTLS, I have yet to see single OpenSSL 
error message which would help user to understand the issue.

Vít
> that you should make the user opt-in into a legacy algorithm
> and then counter the restriction on the next attempt with
> a priority string extension or gnutls_protocol_mark_enabled,
> please file a bug with GnuTLS and describe your case.
> Your continued input would be appreciated.
> Same with the other libraries if you meant other libraries.
>
> If you don't want to spend a connection on just probing,
> but instead prefer to connect no matter what
> and then query what has been negotiated
> to make the warn/abort decisions on the application layer
> that should also be possible.
> > Which is why handling it like a certificate validation failure seems to
> > be the right answer, but I'm happy to explore other solutions... but
> > preferably *not* solutions like "manually set
> > GNUTLS_SYSTEM_PRIORTY_FILE=/dev/null in your Fedora package to
> > explicitly override all the Fedora crypto policies". That suggestion
> > made me sad... :)
>
> +1, this is not the way
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Alexander Sosedkin]

On Wed, May 4, 2022 at 12:52 PM Vít Ondruch  wrote:
> Dne 04. 05. 22 v 9:32 Alexander Sosedkin napsal(a):
> > On Wed, May 4, 2022 at 12:43 AM David Woodhouse  wrote:
> > > On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
> > > > This is the reason why the proposal contains extensive methods to test
> > > > whether things are going to break by modifying the crypto-policy or using
> > > > bpftrace. Unfortunately there are hundreds of packages that depend on
> > > > cryptographic libraries, and millions of different configurations out there.
> > > > We can’t know ahead of time which ones of them are going to break, but the
> > > > proposal provides tools and a long transition period to identify and fix
> > > > them.
> > >
> > > When changes like this broke things for users in the past, we talked
> > > about a way to present the "insufficient crypto/digest/protocol" as
> > > just another failure like server certificate validation failures, so
> > > the application/user can *choose* to accept and proceed, in real time.
> > >
> > > I'd like to see that as a *condition* of acceptance of further
> > > restrictions in the policy.
> > >
> > > I really don't want us continuing to break things for Fedora users and
> > > driving them back to the proprietary VPN clients.
> > >
> > > I am pleased to see some progress on this front with
> > > https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting but it isn't
> > > clear to me that this gives us what we need. We *want* to warn users
> > > that their VPN server doesn't meet modern crypto standards. We don't
> > > want to just blindly re-enable ancient crap and have it silently work.
> > > But we also do *need* it to work, after we've warned the user about it.
> >
> > If the error returned from GnuTLS isn't enough to infer
>
> While I don't know much about GnuTLS, I have yet to see single OpenSSL
> error message which would help user to understand the issue.

I was talking error codes, not error messages, but oof.
> > that you should make the user opt-in into a legacy algorithm
> > and then counter the restriction on the next attempt with
> > a priority string extension or gnutls_protocol_mark_enabled,
> > please file a bug with GnuTLS and describe your case.
> > Your continued input would be appreciated.
> > Same with the other libraries if you meant other libraries.
> >
> > If you don't want to spend a connection on just probing,
> > but instead prefer to connect no matter what
> > and then query what has been negotiated
> > to make the warn/abort decisions on the application layer
> > that should also be possible.
> > > Which is why handling it like a certificate validation failure seems to
> > > be the right answer, but I'm happy to explore other solutions... but
> > > preferably *not* solutions like "manually set
> > > GNUTLS_SYSTEM_PRIORTY_FILE=/dev/null in your Fedora package to
> > > explicitly override all the Fedora crypto policies". That suggestion
> > > made me sad... :)
> >
> > +1, this is not the way

[Alexander Sosedkin]

On Sat, Apr 30, 2022 at 4:28 PM David Woodhouse  wrote:
> 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

No arguing here...
> without introducing regressions, or the Feature is reverted.

... but not sure if I understand this bit.
Flipping a default and not introducing a regression
is only possible if each and every impacted workflow and scenario
is caught by one of the proposed testing strategies or something else.
As much as I'd love to see that happen
I think it's safe to say it's just not gonna happen
(hence the next "jump scare" phase + 2 following cycles).

[Ian Pilcher]

It sure feels like we're reaching the point where anyone who has to work
with any sort of older equipment or servers is going to to forced to
switch their entire system to the LEGACY policy, which seems really
unfortunate.

IMO, there's a rather desperate need to be able to override the system-
wide policy for individual processes, maybe via some sort of wrapper
around one of the containerization technologies.

[JT]

> IMO, there's a rather desperate need to be able to override the

system-wide policy for individual processes, maybe via some sort of wrapper
around one of the containerization technologies.

There's part of me that's almost surprised that there's not an SELinux
Policy flag of some kind that would restrict or allow access of individual
applications from using certain crypto bits.  That seems like something
that someone would have cooked up before, but perhaps it's just too
intrusive into every other piece of software for even the SELinux team to
want to futz with.
Alternatively I wouldn't be surprised if at some point the industry doesn't
unofficially opt for a legacy openssl option which could be utilized by
legacy code, but still allow all the modern code to use the new stuff.  But
of course if that did exist, tons of people would just refuse to update
their code and deps because they have an option not to.

On Mon, May 2, 2022 at 9:56 AM Ian Pilcher  wrote:
> It sure feels like we're reaching the point where anyone who has to work
> with any sort of older equipment or servers is going to to forced to
> switch their entire system to the LEGACY policy, which seems really
> unfortunate.
>
> IMO, there's a rather desperate need to be able to override the system-
> wide policy for individual processes, maybe via some sort of wrapper
> around one of the containerization technologies.
> --
> Google                                      Where SkyNet meets Idiocracy
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

[Robbie Harwood]

JT  writes:
> > IMO, there's a rather desperate need to be able to override the
> > system-wide policy for individual processes, maybe via some sort of
> > wrapper around one of the containerization technologies.
>
> Alternatively I wouldn't be surprised if at some point the industry
> doesn't unofficially opt for a legacy openssl option which could be
> utilized by legacy code, but still allow all the modern code to use
> the new stuff.  But of course if that did exist, tons of people would
> just refuse to update their code and deps because they have an option
> not to.

While I agree that per-application policy overrides would be really
helpful, these suggested solutions are overkill.

Concretely, crypto-policies works by managing various configuration
files.  All that's needed to override on a per-application or even
per-process basis is to look at a different configuration file.
Exposing an environment variable (when it's not already) or
initialization option from the crypto library suffices for this.

In any case, this seems like functionality best provided by
crypto-policies itself.

Be well,
--Robbie

[JT]

> While I agree that per-application policy overrides would be really

helpful, these suggested solutions are overkill.

Overkill is SELinux's middle name isn't it. :P It always struck me as being
intentionally heavy handed... which is kind of a good thing if you're
looking for control above all else. That being said though...
> In any case, this seems like functionality best provided by

crypto-policies itself.

Agreed, the simpler and less code complex the better.

On Mon, May 2, 2022 at 12:27 PM Robbie Harwood  wrote:
> JT  writes:
> > > IMO, there's a rather desperate need to be able to override the
> > > system-wide policy for individual processes, maybe via some sort of
> > > wrapper around one of the containerization technologies.
> >
> > Alternatively I wouldn't be surprised if at some point the industry
> > doesn't unofficially opt for a legacy openssl option which could be
> > utilized by legacy code, but still allow all the modern code to use
> > the new stuff.  But of course if that did exist, tons of people would
> > just refuse to update their code and deps because they have an option
> > not to.
>
> While I agree that per-application policy overrides would be really
> helpful, these suggested solutions are overkill.
>
> Concretely, crypto-policies works by managing various configuration
> files.  All that's needed to override on a per-application or even
> per-process basis is to look at a different configuration file.
> Exposing an environment variable (when it's not already) or
> initialization option from the crypto library suffices for this.
>
> In any case, this seems like functionality best provided by
> crypto-policies itself.
>
> Be well,
> --Robbie

[Alexander Sosedkin]

On Mon, May 2, 2022 at 6:28 PM Robbie Harwood  wrote:
> JT  writes:
> > > IMO, there's a rather desperate need to be able to override the
> > > system-wide policy for individual processes, maybe via some sort of
> > > wrapper around one of the containerization technologies.
> >
> > Alternatively I wouldn't be surprised if at some point the industry
> > doesn't unofficially opt for a legacy openssl option which could be
> > utilized by legacy code, but still allow all the modern code to use
> > the new stuff.  But of course if that did exist, tons of people would
> > just refuse to update their code and deps because they have an option
> > not to.
>
> While I agree that per-application policy overrides would be really
> helpful, these suggested solutions are overkill.
>
> Concretely, crypto-policies works by managing various configuration
> files.  All that's needed to override on a per-application or even
> per-process basis is to look at a different configuration file.
> Exposing an environment variable (when it's not already) or
> initialization option from the crypto library suffices for this.
>
> In any case, this seems like functionality best provided by
> crypto-policies itself.

crypto-policies' goal is to define system-wide *defaults*.

Cryptographic libraries already provide all kinds of finer API
to deviate from configuration file defaults
that isn't just envvars or pointing to configuration files;
API that applications are already supposed to be using
if they want to ensure that a specific algorithm is available
no matter what the local/vendor/whatever configuration is..
The sad thing though is that it's been long limited to just TLS
and routinely needs expansion to cover more.

Envvars and custom config files do exist and do function,
but I don't consider them enough.

[Robbie Harwood]

Alexander Sosedkin  writes:
> crypto-policies' goal is to define system-wide *defaults*.

Well, that's certainly part of it, but...

"The purpose is to unify the crypto policies used by different
applications and libraries. That is allow setting a consistent security
level for crypto on all applications in a Fedora system, irrespective of
the crypto library in use."

(from https://gitlab.com/redhat-crypto/fedora-crypto-policies#purpose )

"Unify the crypto policies used by different applications and
libraries. That is allow setting a consistent security level for crypto
on all applications in a Fedora system. The implementation approach will
be to initially modify SSL libraries to respect the policy and gradually
adding more libraries and applications."

(from https://fedoraproject.org/wiki/Changes/CryptoPolicy#Summary )

So to restate: from what Nikos wrote, I read an additional goal of
unification and centralization that I don't hear echoed in what you're
saying.
> Cryptographic libraries already provide all kinds of finer API to
> deviate from configuration file defaults that isn't just envvars or
> pointing to configuration files; API that applications are already
> supposed to be using if they want to ensure that a specific algorithm
> is available no matter what the local/vendor/whatever configuration
> is.

In many cases these APIs exist, but what you're proposing is a world
where applications generally need to care about their own crypto
settings.  In that world, there's little incentive to use the systemwide
settings at all, and we're back to each application deciding crypto for
themselves - which doesn't strike me as appealing.
> The sad thing though is that it's been long limited to just TLS and
> routinely needs expansion to cover more.

Yes, many things make the assumption that crypto == TLS.
crypto-policies already covers more than just TLS settings for
applications, so it needs to have solutions for more than just that.
> Envvars and custom config files do exist and do function, but I don't
> consider them enough.

So what solution do you propose that would be enough?

Be well,
--Robbie

[Alexander Sosedkin]

On Mon, May 2, 2022 at 7:18 PM Robbie Harwood  wrote:
> Alexander Sosedkin  writes:
> > crypto-policies' goal is to define system-wide *defaults*.
>
> Well, that's certainly part of it, but...
>
> "The purpose is to unify the crypto policies used by different
> applications and libraries. That is allow setting a consistent security
> level for crypto on all applications in a Fedora system, irrespective of
> the crypto library in use."
>
> (from https://gitlab.com/redhat-crypto/fedora-crypto-policies#purpose )
>
> "Unify the crypto policies used by different applications and
> libraries. That is allow setting a consistent security level for crypto
> on all applications in a Fedora system. The implementation approach will
> be to initially modify SSL libraries to respect the policy and gradually
> adding more libraries and applications."
>
> (from https://fedoraproject.org/wiki/Changes/CryptoPolicy#Summary )
>
> So to restate: from what Nikos wrote, I read an additional goal of
> unification and centralization that I don't hear echoed in what you're
> saying.

Unification and centralization of defaults.
And yes, I can't vouch that the early crypto-policies goal was to set defaults,
in fact some of the changes by Nikos set hard non-sidesteppable limits.
Now we're moving away from that to setting soft-defaults.
> > Cryptographic libraries already provide all kinds of finer API to
> > deviate from configuration file defaults that isn't just envvars or
> > pointing to configuration files; API that applications are already
> > supposed to be using if they want to ensure that a specific algorithm
> > is available no matter what the local/vendor/whatever configuration
> > is.
>
> In many cases these APIs exist, but what you're proposing is a world
> where applications generally need to care about their own crypto
> settings.  In that world, there's little incentive to use the systemwide
> settings at all, and we're back to each application deciding crypto for
> themselves - which doesn't strike me as appealing.

Absolutely not, quite the opposite, even.
I advocate for the world of applications that
1. practice cryptographic agility and trust the system defaults
2. when faced with an overly legacy scenario, fail by default
3. only if/when the operator explicitly opts to go unsafe,
   grant itself an exception and relax the list of what's allowed
+ more or less conveniently adjustable system defaults don't hurt

What I tried to say is,
for each and every configurable aspect of the library
nobody guarantees the app author that it's allowed on a select system.
Thus applications must be ready for any algorithm to be restricted
and act sensibly when it is.
This is the case for all distros and
works the same in the crypto-policies-less world.
> > The sad thing though is that it's been long limited to just TLS and
> > routinely needs expansion to cover more.
>
> Yes, many things make the assumption that crypto == TLS.
> crypto-policies already covers more than just TLS settings for
> applications, so it needs to have solutions for more than just that.
> > Envvars and custom config files do exist and do function, but I don't
> > consider them enough.
>
> So what solution do you propose that would be enough?

Something akin to gnutls' recently added gnutls_sign_set_secure,
we'll also need to propose something similar for OpenSSL.

[Kevin Kofler]

Ian Pilcher wrote:
> It sure feels like we're reaching the point where anyone who has to work
> with any sort of older equipment or servers is going to to forced to
> switch their entire system to the LEGACY policy, which seems really
> unfortunate.

Even worse is that even the LEGACY policy is getting stricter and stricter 
(more or less silently, because it is documented only in passing as part of 
the general crypto policy tightening, and the focus of the documentation is 
on DEFAULT).

I think we need a REALLY_LEGACY that continues allowing MD5 and the like.

Kevin Kofler

[Alexander Sosedkin]

On Tue, May 3, 2022 at 1:20 PM Kevin Kofler via devel
 wrote:
> Ian Pilcher wrote:
> > It sure feels like we're reaching the point where anyone who has to work
> > with any sort of older equipment or servers is going to to forced to
> > switch their entire system to the LEGACY policy, which seems really
> > unfortunate.
>
> Even worse is that even the LEGACY policy is getting stricter and stricter
> (more or less silently, because it is documented only in passing as part of
> the general crypto policy tightening, and the focus of the documentation is
> on DEFAULT).
>
> I think we need a REALLY_LEGACY that continues allowing MD5 and the like.

A resounding no from me.
If you want one, write a custom one
that's at least tailored to what exactly you want enabled.

[Clemens Lang]

Hi,

Kevin Kofler via devel  wrote:
> I think we need a REALLY_LEGACY that continues allowing MD5 and the like.

According to https://github.com/corkami/collisions#chosen-prefix-collisions,
a chosen-prefix collision on MD5 took 72 hours to compute in 2009. 13 years
later, you really should treat anything that still uses MD5 as if it was
completely unsigned. I’m almost tempted to invest some CPU/GPU time to
compute a MD5 hash collision of your message to prove the point.

I don’t believe this would be in the best interest of our users. Setting a
crypto-policy to REALLY_LEGACY would basically mean “I don’t care about
encryption”. In these cases, why not just use plain HTTP, or other
unencrypted protocols instead?

[Roberto Ragusa]

On 5/3/22 1:51 PM, Clemens Lang wrote:
> I don’t believe this would be in the best interest of our users. Setting a
> crypto-policy to REALLY_LEGACY would basically mean “I don’t care about
> encryption”. In these cases, why not just use plain HTTP, or other
> unencrypted protocols instead?

Easy answer: for compatibility with random ancient things.

[Richard W.M. Jones]

On Mon, May 02, 2022 at 08:56:06AM -0500, Ian Pilcher wrote:
> It sure feels like we're reaching the point where anyone who has to work
> with any sort of older equipment or servers is going to to forced to
> switch their entire system to the LEGACY policy, which seems really
> unfortunate.

See also:

https://bugzilla.redhat.com/show_bug.cgi?id=2064740

Rich.
> IMO, there's a rather desperate need to be able to override the system-
> wide policy for individual processes, maybe via some sort of wrapper
> around one of the containerization technologies.
> --
> Google                                      Where SkyNet meets Idiocracy
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Ian Pilcher]

On 5/2/22 08:56, Ian Pilcher wrote:
> IMO, there's a rather desperate need to be able to override the system-
> wide policy for individual processes, maybe via some sort of wrapper
> around one of the containerization technologies.

Just FYI, I managed to bang out a proof of concept of a "wrapper" that
runs a program with a different crypto policy.  I've successfully used
it to connect to a TLSv1-only HTTP server with both Firefox and curl on
a Fedora 36 system running the DEFAULT crypto policy.

https://bugzilla.redhat.com/show_bug.cgi?id=2064740#c8

[Garry T. Williams]

On Friday, April 29, 2022 5:49:05 PM EDT Ben Cotton wrote:
> 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.

[snip]

In case you want some feedback,
> 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.

I did that and several days later I did:

$ sudo dnf upgrade --enablerepo=updates-testing
    Errors during downloading metadata for repository 'fedora':
      - Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64&am... [SSL certificate problem: CA certificate key too weak]
      - Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64 [SSL certificate problem: CA certificate key too weak]
    Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64 [SSL certificate problem: CA certificate key too weak]
> Verify that the broken functionality works again
> if you the policy is relaxed back
> with, e.g., `update-crypto-policies --set FUTURE:SHA-1`,

This was a problem:

$ sudo update-crypto-policies --set FUTURE:SHA-1
    Unknown policy `SHA-1`: file `SHA-1.pmod` not found in (., policies/modules, /etc/crypto-policies/policies/modules, /usr/share/crypto-policies/policies/modules)

That seems like a typo.  After looking in
/usr/share/crypto-policies/policies/modules, I tried again with:

$ sudo update-crypto-policies --set FUTURE:SHA1
    Setting system policy to FUTURE:SHA1

But that didn't get me back.  I got the same error doing dnf upgrade.

I had to do:

$ sudo update-crypto-policies --set DEFAULT

to get back to dnf working again.
> file bug reports against the affected components if not filed already.

I really don't know what "component" to use filing a bug.

[Alexander Sosedkin]

On Mon, May 30, 2022 at 10:34 PM Garry T. Williams  wrote:
> On Friday, April 29, 2022 5:49:05 PM EDT Ben Cotton wrote:
> > 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.
>
> [snip]
>
> In case you want some feedback,

Thank you for taking time to do that.
> > 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.
>
> I did that and several days later I did:
> $ sudo dnf upgrade --enablerepo=updates-testing
> Errors during downloading metadata for repository 'fedora':
>   - Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64&countme=3 [SSL certificate problem: CA certificate key too weak]
>   - Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64 [SSL certificate problem: CA certificate key too weak]
> Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64 [SSL certificate problem: CA certificate key too weak]
>
> > Verify that the broken functionality works again
> > if you the policy is relaxed back
> > with, e.g., `update-crypto-policies --set FUTURE:SHA-1`,
>
> This was a problem:
> $ sudo update-crypto-policies --set FUTURE:SHA-1
> Unknown policy `SHA-1`: file `SHA-1.pmod` not found in (., policies/modules, /etc/crypto-policies/policies/modules, /usr/share/crypto-policies/policies/modules)
>
> That seems like a typo.

Indeed, thanks for spotting. Fixed in two places.
> After looking in
> /usr/share/crypto-policies/policies/modules, I tried again with:
> $ sudo update-crypto-policies --set FUTURE:SHA1
> Setting system policy to FUTURE:SHA1
>
> But that didn't get me back.  I got the same error doing dnf upgrade.
>
> I had to do:
> $ sudo update-crypto-policies --set DEFAULT
>
> to get back to dnf working again.
> > file bug reports against the affected components if not filed already.
>
> I really don't know what "component" to use filing a bug.

Yeah, that seems like a case when
the service administrator is the one to be notified.

[Petr Pisar]

V Tue, May 31, 2022 at 08:07:57AM +0200, Alexander Sosedkin napsal(a):
> On Mon, May 30, 2022 at 10:34 PM Garry T. Williams  wrote:
> > On Friday, April 29, 2022 5:49:05 PM EDT Ben Cotton wrote:
> > > 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.
> >
> > After looking in
> > /usr/share/crypto-policies/policies/modules, I tried again with:
> > $ sudo update-crypto-policies --set FUTURE:SHA1
> > Setting system policy to FUTURE:SHA1
> >
> > But that didn't get me back.  I got the same error doing dnf upgrade.
> >
> > I had to do:
> > $ sudo update-crypto-policies --set DEFAULT
> >
> > to get back to dnf working again.
> > > file bug reports against the affected components if not filed already.
> >
> > I really don't know what "component" to use filing a bug.
>
> Yeah, that seems like a case when
> the service administrator is the one to be notified.

Reported to https://pagure.io/fedora-infrastructure/issue/10737. The real
cause is not SHA-1. It's a 2048-bit RSA key of an intermediate certificate.

-- Petr

[Vitaly Zaitsev]

On 31/05/2022 08:59, Petr Pisar wrote:
> It's a 2048-bit RSA key of an intermediate certificate.

RSA-2048 is still okay. It should work without errors.

[Petr Pisar]

V Tue, May 31, 2022 at 10:20:10AM +0200, Vitaly Zaitsev via devel napsal(a):
> On 31/05/2022 08:59, Petr Pisar wrote:
> > It's a 2048-bit RSA key of an intermediate certificate.
>
> RSA-2048 is still okay. It should work without errors.

Not in current F37 FUTURE policy the user tested.

-- Petr

[Vitaly Zaitsev]

On 31/05/2022 10:21, Petr Pisar wrote:
> Not in current F37 FUTURE policy the user tested.

Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak, 
it should be reverted. Many servers still use RSA-2048 (the default in 
Let's Encrypt).

[Alexander Sosedkin]

On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel
 wrote:
> On 31/05/2022 10:21, Petr Pisar wrote:
> > Not in current F37 FUTURE policy the user tested.
>
> Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak,
> it should be reverted.

The actual proposal is in the OP.

Not only there's no such thing as "new F37 policy" happening,
the F39 DEFAULT does allow RSA-2048,
and this is spelled out upfront in the proposal text in the OP.
RSA-3072 is only the minimum for the opt-in FUTURE policy,
which has been the case since at least F28.
> Many servers still use RSA-2048 (the default in Let's Encrypt).

And that's why it is going to be accepted in DEFAULT even in F39+.

Please tone down the FUD,
your signal/noise ratio has been record low over the last few weeks,
with statements being technically true and most of the time agreeable,
yet inexplicably resulting in a net negative benefit to the discussion.

[Petr Pisar]

V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a):
> On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel
>  wrote:
> > On 31/05/2022 10:21, Petr Pisar wrote:
> > > Not in current F37 FUTURE policy the user tested.
> >
> > Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak,
> > it should be reverted.
>
> The actual proposal is in the OP.
>
> Not only there's no such thing as "new F37 policy" happening,
> the F39 DEFAULT does allow RSA-2048,
> and this is spelled out upfront in the proposal text in the OP.
> RSA-3072 is only the minimum for the opt-in FUTURE policy,
> which has been the case since at least F28.

I'm sorry. You are right that the key length limit won't change.

Probably what confused us is this sentence:

Test your setup with FUTURE today and file bugs so you won't get bit by
    Fedora 38-39.

That's obviously incorect because current FUTURE is not equvialent to the
proposed DEFAULT. I recommend you to reword the testing procedure so that
people are not bitten by this discrepancy.

Maybe you should prepare a policy DEFAULT-F39, package it into current Fedora,
and ask people to test DEFAULT-F39 instead of FUTURE or FUTURE:SHA1.

-- Petr

[Alexander Sosedkin]

On Tue, May 31, 2022 at 3:45 PM Petr Pisar  wrote:
> V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a):
> > On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel
> >  wrote:
> > > On 31/05/2022 10:21, Petr Pisar wrote:
> > > > Not in current F37 FUTURE policy the user tested.
> > >
> > > Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak,
> > > it should be reverted.
> >
> > The actual proposal is in the OP.
> >
> > Not only there's no such thing as "new F37 policy" happening,
> > the F39 DEFAULT does allow RSA-2048,
> > and this is spelled out upfront in the proposal text in the OP.
> > RSA-3072 is only the minimum for the opt-in FUTURE policy,
> > which has been the case since at least F28.
>
> I'm sorry. You are right that the key length limit won't change.
>
> Probably what confused us is this sentence:
> Test your setup with FUTURE today and file bugs so you won't get bit by
> Fedora 38-39.
>
> That's obviously incorect because current FUTURE is not equvialent to the
> proposed DEFAULT. I recommend you to reword the testing procedure so that
> people are not bitten by this discrepancy.
>
> Maybe you should prepare a policy DEFAULT-F39, package it into current Fedora,
> and ask people to test DEFAULT-F39 instead of FUTURE or FUTURE:SHA1.

That'd be TEST-FEDORA39, mentioned as an alternative in the same sentence:
> 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.

I chose to suggest them in this particular order
in hopes of bringing the world a tad closer to the FUTURE and not just
F39 DEFAULT.

Should I drop it?

[Petr Pisar]

V Tue, May 31, 2022 at 03:51:26PM +0200, Alexander Sosedkin napsal(a):
> On Tue, May 31, 2022 at 3:45 PM Petr Pisar  wrote:
> > V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a):
> > > On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel
> > >  wrote:
> > > > On 31/05/2022 10:21, Petr Pisar wrote:
> > > > > Not in current F37 FUTURE policy the user tested.
> > > >
> > > > Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak,
> > > > it should be reverted.
> > >
> > > The actual proposal is in the OP.
> > >
> > > Not only there's no such thing as "new F37 policy" happening,
> > > the F39 DEFAULT does allow RSA-2048,
> > > and this is spelled out upfront in the proposal text in the OP.
> > > RSA-3072 is only the minimum for the opt-in FUTURE policy,
> > > which has been the case since at least F28.
> >
> > I'm sorry. You are right that the key length limit won't change.
> >
> > Probably what confused us is this sentence:
> > Test your setup with FUTURE today and file bugs so you won't get bit by
> > Fedora 38-39.
> >
> > That's obviously incorect because current FUTURE is not equvialent to the
> > proposed DEFAULT. I recommend you to reword the testing procedure so that
> > people are not bitten by this discrepancy.
> >
> > Maybe you should prepare a policy DEFAULT-F39, package it into current Fedora,
> > and ask people to test DEFAULT-F39 instead of FUTURE or FUTURE:SHA1.
>
> That'd be TEST-FEDORA39, mentioned as an alternative in the same sentence:
> > 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.
>
> I chose to suggest them in this particular order
> in hopes of bringing the world a tad closer to the FUTURE and not just
> F39 DEFAULT.
>
> Should I drop it?

That would be great. If this change is about SHA-1, I would only keep
TEST-FEDORA39 in the Change page.

If you want to promote FUTURE, you can keep a small notice at the end of How
To Test section that people who want to sense security of far future, can try
FUTURE policy. But make sure that it's written in an obvious way that FUTURE
is out of scope of this Change.

-- Petr

[Alexander Sosedkin]

On Tue, May 31, 2022 at 4:09 PM Petr Pisar  wrote:
> V Tue, May 31, 2022 at 03:51:26PM +0200, Alexander Sosedkin napsal(a):
> > On Tue, May 31, 2022 at 3:45 PM Petr Pisar  wrote:
> > > V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a):
> > > > On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel
> > > >  wrote:
> > > > > On 31/05/2022 10:21, Petr Pisar wrote:
> > > > > > Not in current F37 FUTURE policy the user tested.
> > > > >
> > > > > Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak,
> > > > > it should be reverted.
> > > >
> > > > The actual proposal is in the OP.
> > > >
> > > > Not only there's no such thing as "new F37 policy" happening,
> > > > the F39 DEFAULT does allow RSA-2048,
> > > > and this is spelled out upfront in the proposal text in the OP.
> > > > RSA-3072 is only the minimum for the opt-in FUTURE policy,
> > > > which has been the case since at least F28.
> > >
> > > I'm sorry. You are right that the key length limit won't change.
> > >
> > > Probably what confused us is this sentence:
> > > Test your setup with FUTURE today and file bugs so you won't get bit by
> > > Fedora 38-39.
> > >
> > > That's obviously incorect because current FUTURE is not equvialent to the
> > > proposed DEFAULT. I recommend you to reword the testing procedure so that
> > > people are not bitten by this discrepancy.
> > >
> > > Maybe you should prepare a policy DEFAULT-F39, package it into current Fedora,
> > > and ask people to test DEFAULT-F39 instead of FUTURE or FUTURE:SHA1.
> >
> > That'd be TEST-FEDORA39, mentioned as an alternative in the same sentence:
> > > 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.
> >
> > I chose to suggest them in this particular order
> > in hopes of bringing the world a tad closer to the FUTURE and not just
> > F39 DEFAULT.
> >
> > Should I drop it?
>
> That would be great. If this change is about SHA-1, I would only keep
> TEST-FEDORA39 in the Change page.
>
> If you want to promote FUTURE, you can keep a small notice at the end of How
> To Test section that people who want to sense security of far future, can try
> FUTURE policy. But make sure that it's written in an obvious way that FUTURE
> is out of scope of this Change.

Fair.
Deprioritized testing FUTURE, warned that it's not gonna become defaults
and made TEST-FEDORA39 more prominent:
https://fedoraproject.org/w/index.php?title=Changes%2FStrongCryptoSettings3F...
https://fedoraproject.org/w/index.php?title=Changes%2FStrongCryptoSettings3F...

[Petr Pisar]

V Tue, May 31, 2022 at 04:25:28PM +0200, Alexander Sosedkin napsal(a):
> On Tue, May 31, 2022 at 4:09 PM Petr Pisar  wrote:
> > V Tue, May 31, 2022 at 03:51:26PM +0200, Alexander Sosedkin napsal(a):
> > > On Tue, May 31, 2022 at 3:45 PM Petr Pisar  wrote:
> > > > V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a):
> > > > > On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel
> > > > >  wrote:
> > > > > > On 31/05/2022 10:21, Petr Pisar wrote:
> > > > > > > Not in current F37 FUTURE policy the user tested.
> > > > > >
> > > > > > Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak,
> > > > > > it should be reverted.
> > > > >
> > > > > The actual proposal is in the OP.
> > > > >
> > > > > Not only there's no such thing as "new F37 policy" happening,
> > > > > the F39 DEFAULT does allow RSA-2048,
> > > > > and this is spelled out upfront in the proposal text in the OP.
> > > > > RSA-3072 is only the minimum for the opt-in FUTURE policy,
> > > > > which has been the case since at least F28.
> > > >
> > > > I'm sorry. You are right that the key length limit won't change.
> > > >
> > > > Probably what confused us is this sentence:
> > > > Test your setup with FUTURE today and file bugs so you won't get bit by
> > > > Fedora 38-39.
> > > >
> > > > That's obviously incorect because current FUTURE is not equvialent to the
> > > > proposed DEFAULT. I recommend you to reword the testing procedure so that
> > > > people are not bitten by this discrepancy.
> > > >
> > > > Maybe you should prepare a policy DEFAULT-F39, package it into current Fedora,
> > > > and ask people to test DEFAULT-F39 instead of FUTURE or FUTURE:SHA1.
> > >
> > > That'd be TEST-FEDORA39, mentioned as an alternative in the same sentence:
> > > > 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.
> > >
> > > I chose to suggest them in this particular order
> > > in hopes of bringing the world a tad closer to the FUTURE and not just
> > > F39 DEFAULT.
> > >
> > > Should I drop it?
> >
> > That would be great. If this change is about SHA-1, I would only keep
> > TEST-FEDORA39 in the Change page.
> >
> > If you want to promote FUTURE, you can keep a small notice at the end of How
> > To Test section that people who want to sense security of far future, can try
> > FUTURE policy. But make sure that it's written in an obvious way that FUTURE
> > is out of scope of this Change.
>
> Fair.
> Deprioritized testing FUTURE, warned that it's not gonna become defaults
> and made TEST-FEDORA39 more prominent:
> https://fedoraproject.org/w/index.php?title=Changes%2FStrongCryptoSettings3F...
> https://fedoraproject.org/w/index.php?title=Changes%2FStrongCryptoSettings3F...

Great.

-- Petr

[Kevin Fenzi]

On Tue, May 31, 2022 at 08:59:28AM +0200, Petr Pisar wrote:
> V Tue, May 31, 2022 at 08:07:57AM +0200, Alexander Sosedkin napsal(a):
> > On Mon, May 30, 2022 at 10:34 PM Garry T. Williams  wrote:
> > > On Friday, April 29, 2022 5:49:05 PM EDT Ben Cotton wrote:
> > > > 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.
> > >
> > > After looking in
> > > /usr/share/crypto-policies/policies/modules, I tried again with:
> > > $ sudo update-crypto-policies --set FUTURE:SHA1
> > > Setting system policy to FUTURE:SHA1
> > >
> > > But that didn't get me back.  I got the same error doing dnf upgrade.
> > >
> > > I had to do:
> > > $ sudo update-crypto-policies --set DEFAULT
> > >
> > > to get back to dnf working again.
> > > > file bug reports against the affected components if not filed already.
> > >
> > > I really don't know what "component" to use filing a bug.
> >
> > Yeah, that seems like a case when
> > the service administrator is the one to be notified.
>
> Reported to https://pagure.io/fedora-infrastructure/issue/10737. The real
> cause is not SHA-1. It's a 2048-bit RSA key of an intermediate certificate.

Right. This has been reported before: 
https://bugzilla.redhat.com/show_bug.cgi?id=1832292

As far as I can tell, we can't get a digicert cert that doesn't use
2048bit CA or intermediate. I think they do offer better/different, but
those are reserved for the EV certs which require a bunch of validation
of your business (which fedoraproject isn't).

We might be able to replace it with a letsencrypt cert, I've not looked
to see if they have moved to a higher bit CA/intermediate yet.

But even with that, do note that lots and lots and lots of other
websites will not work at all either, so I don't think setting FUTURE
is too great a experence right now. ;(

kevin