From Fedora Project Wiki

(Created page with "<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> =...")
 
(Withdrawn by owner)
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->


= Change Proposal Name =
= Disable SHA1 In OpenDNSSec =
DisableSHA1InOpenDNSSec
 


== Summary ==
== Summary ==
Line 35: Line 35:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2633 #2633]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
Line 43: Line 43:
OpenDNSSec changed the default behavior to not include SHA1 DS by default, and added the -sha1 knob as an immediately-deprecated compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By default ‘ods-enforcer key export –ds’ included the SHA1 version of the DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS use the –sha1 flag. This flag is immediately deprecated and will be removed from future versions of OpenDNSSEC." (see ChangeLog: https://www.opendnssec.org/archive/releases/ ).
OpenDNSSec changed the default behavior to not include SHA1 DS by default, and added the -sha1 knob as an immediately-deprecated compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By default ‘ods-enforcer key export –ds’ included the SHA1 version of the DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS use the –sha1 flag. This flag is immediately deprecated and will be removed from future versions of OpenDNSSEC." (see ChangeLog: https://www.opendnssec.org/archive/releases/ ).


The proposal is to disable the -sha1 knob in Fedora. I will also propose the change upstream.
The proposal is to disable the -sha1 knob in Fedora. I will also open an issue upstream to remove all the sha1-related code.
 
Supporting statement from ICANN: https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en


Supporting statement [https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en [from ICANN] (2020-1-24): "Now is the time for administrators of zones at all levels of the DNS to stop using SHA-1 and change to algorithms using stronger hashes."


== Feedback ==
== Feedback ==
Line 64: Line 63:
-->
-->


This change makes sure OpenDNSSec in Fedora follows ICANN's guidelines and does not propose SHA1 DS.
* This change makes sure OpenDNSSec in Fedora follows ICANN's guidelines and does not propose SHA1 DS. This is is needed given the [https://sha-mbles.github.io/ latest attacks against SHA-1]. More in-depth articles are available [https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and [https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/ there].
It is aligned with previous features:
* This change is aligned with previous features:
[[ https://fedoraproject.org/wiki/Features/StrongerHashes || StrongerHashes ]]
** [[Features/StrongerHashes]]
[[ https://fedoraproject.org/wiki/Changes/StrongCryptoSettings || StrongCryptoSettings ]]
** [[Changes/StrongCryptoSettings]]
[[ https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 || StrongCryptoSettings2 ]]
** [[Changes/StrongCryptoSettings2]]
 


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners:
Patch the enforcer so that bsha1 is not honored anymore:
Patch the enforcer so that bsha1 is not honored anymore:
./enforcer/src/keystate/keystate_export_cmd.c-271-                break;
./enforcer/src/keystate/keystate_export_cmd.c-271-                break;
./enforcer/src/keystate/keystate_export_cmd.c-272-            case 's':
./enforcer/src/keystate/keystate_export_cmd.c-272-            case 's':
./enforcer/src/keystate/keystate_export_cmd.c:273:                bsha1 = 1;
./enforcer/src/keystate/keystate_export_cmd.c:273:                bsha1 = 1;
./enforcer/src/keystate/keystate_export_cmd.c-274-                break;  
./enforcer/src/keystate/keystate_export_cmd.c-274-                break;  
./enforcer/src/keystate/keystate_export_cmd.c-275-            default:
./enforcer/src/keystate/keystate_export_cmd.c-275-            default:


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 97: Line 95:
== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone.
Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone.  
This might break (very old) clients that only recognize SHA-1.  
This change might break (very old) clients that only recognize SHA-1 but these should already be broken (on the Internet at least) because the root zone is signed with SHA-256 only.




<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


== How To Test ==
== How To Test ==
Line 123: Line 120:


== User Experience ==
== User Experience ==
OpenDNSSec in Fedora can currently be used to sign zones with SHA1. With this change, this will no longer be possible. The migration from SHA1 is underway anyway.
<!-- If this change proposal is noticeable by users, how will their experiences change as a result?
<!-- If this change proposal is noticeable by users, how will their experiences change as a result?


Line 144: Line 144:


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: Keep the current -sha1 behavior.  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: Keep the current -sha1 knob's behavior (remove the patch).  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: Beta freeze  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: Beta freeze  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No, unless the change breaks IPA. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 


== Documentation ==
== Documentation ==

Latest revision as of 14:55, 6 July 2021


Disable SHA1 In OpenDNSSec

Summary

OpenDNSSec' enforcer has a (deprecated) -sha1 CLI option that brings back the old behavior, e.g. include the SHA1 version of the DS. As SHA1 use is deprecated in favour of SHA256, disable the -sha1 CLI knob so that it only displays a warning.

Owner


Current status

  • Targeted release: Fedora Linux 35
  • Last updated: 2021-07-06
  • FESCo issue: #2633
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

OpenDNSSec changed the default behavior to not include SHA1 DS by default, and added the -sha1 knob as an immediately-deprecated compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By default ‘ods-enforcer key export –ds’ included the SHA1 version of the DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS use the –sha1 flag. This flag is immediately deprecated and will be removed from future versions of OpenDNSSEC." (see ChangeLog: https://www.opendnssec.org/archive/releases/ ).

The proposal is to disable the -sha1 knob in Fedora. I will also open an issue upstream to remove all the sha1-related code.

Supporting statement [from ICANN (2020-1-24): "Now is the time for administrators of zones at all levels of the DNS to stop using SHA-1 and change to algorithms using stronger hashes."

Feedback

Benefit to Fedora

Scope

  • Proposal owners:

Patch the enforcer so that bsha1 is not honored anymore: 

./enforcer/src/keystate/keystate_export_cmd.c-271-                break;
./enforcer/src/keystate/keystate_export_cmd.c-272-            case 's':
./enforcer/src/keystate/keystate_export_cmd.c:273:                bsha1 = 1;
./enforcer/src/keystate/keystate_export_cmd.c-274-                break; 
./enforcer/src/keystate/keystate_export_cmd.c-275-            default:
  • Other developers:
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives: N/A

Upgrade/compatibility impact

Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone. This change might break (very old) clients that only recognize SHA-1 but these should already be broken (on the Internet at least) because the root zone is signed with SHA-256 only.


How To Test

User Experience

OpenDNSSec in Fedora can currently be used to sign zones with SHA1. With this change, this will no longer be possible. The migration from SHA1 is underway anyway.


Dependencies

FreeIPA (freeipa-server-dns) depends on OpenDNSSec.


Contingency Plan

  • Contingency mechanism: Keep the current -sha1 knob's behavior (remove the patch).
  • Contingency deadline: Beta freeze
  • Blocks release? No, unless the change breaks IPA.

Documentation

N/A (not a System Wide Change)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Change/DisableSHA1InOpenDNSSec&oldid=618741"