11:58 a.m.
https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec
== 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 ==
* Name: [[User:fcami| François Cami]]
* Email: fcami(a)redhat.com
== 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
[https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-s...
[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."
== Benefit to Fedora ==
* 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].
* This change is aligned with previous features:
** [[Features/StrongerHashes]]
** [[Changes/StrongCryptoSettings]]
** [[Changes/StrongCryptoSettings2]]
== 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:
* Release engineering:
* 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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
6:39 p.m.
New subject: F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change
proposal)
On Mon, 28 Jun 2021, Ben Cotton wrote:
== 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.
This change makes me a bit nervous, and I'm the author of RFC 8624 that
recommennds not using SHA-1 for DS/CDS records anymore.
https://datatracker.ietf.org/doc/html/rfc8624#section-3.3
Supporting statement
[https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-s...
[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."
While this is true, the order of where things need to change are:
1 Discourage, but not block, the use of SHA-1. Eg remove it from the default set.
2 Ensure the migration of SHA-1 based records to SHA-256 is taking place
3 remove support for SHA-1
This plan assumes we are in phase3. I would say we are in phase2.
Remember, any domain that depends on SHA-1 is going to be more secure
than being marked as insecure because SHA-1 is rejected. This is somewhat
different from like SHA-1 support for authentication where the rejection
of a weaker algorithm forces the use of a stronger algorithm.
The DNSSEC fallback when an algorithm is not supported is to go insecure,
not insist on a more secure SHA-2 that is not there. With DNSSEC,
there is not client-server exchange like with TLS or IPsec. There is
a producer on one end, and a consumer on the other end. The two do not
negotiate crypto parameters.
== Benefit to Fedora ==
* 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/
I know that a few people believe that shambles can in theory be abused
with DNSSEC, but a lot of people also believe the constrains of DNS
RRsets make this impossible. But even _if_ it is possible, it would
only affect multiple domains that share the same private key that made
the SHA-1 signature. And then we are talking about RRSIG records and
not, as in this proposal, the DS/CDS RDATA content.
Patch the enforcer so that bsha1 is not honored anymore:
I don't think fedora should move faster than upstream opendnssec. I
believe the people at the IETF and the software developers of the DNS
software are more aware of where we are in the migration path than
individual Fedora developers.
== Upgrade/compatibility impact ==
Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone.
The RRSIG signature is not related to the DS signature. Zone resigning
is something completely different from the DS/CDS records. Those records
are signed by the parent zone, and use whatever algorithm the parent
zone uses, which the child zone cannot dictate.
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.
The root zone has no DS record, so this statement does not make sense.
The RRSIG signature algorithm is unrelated to the DS/CDS record RRdata
that contains a hash of the child's public key, where the hash is created
with SHA-1 or SHA-2.
== 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.
So there are two things that really need to be clarified for this
proposal. Is it talking about DS/CDS signature algorithm as per IANA
registry http://www.iana.org/assignments/ds-rr-types, or are we talking
about DNSKEY signature algorithm, that is responsble for signing all
the zone data, that uses a hash algorithm or SHA-1 or better. Based on
the description, I am a bit worried that it is not entirely clear what
the proposed change actually is.
Please feel free to reach out to me directly to talk about this feature
request.
Paul
9:52 a.m.
Hi Paul, all,
On Tue, Jun 29, 2021 at 1:40 AM Paul Wouters <paul(a)nohats.ca> wrote:
On Mon, 28 Jun 2021, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec
> == 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.
This change makes me a bit nervous, and I'm the author of RFC 8624 that
recommennds not using SHA-1 for DS/CDS records anymore.
https://datatracker.ietf.org/doc/html/rfc8624#section-3.3
> Supporting statement
>
[https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-s...
> [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."
While this is true, the order of where things need to change are:
1 Discourage, but not block, the use of SHA-1. Eg remove it from the default set.
2 Ensure the migration of SHA-1 based records to SHA-256 is taking place
3 remove support for SHA-1
This plan assumes we are in phase3. I would say we are in phase2.
Remember, any domain that depends on SHA-1 is going to be more secure
than being marked as insecure because SHA-1 is rejected. This is somewhat
different from like SHA-1 support for authentication where the rejection
of a weaker algorithm forces the use of a stronger algorithm.
The DNSSEC fallback when an algorithm is not supported is to go insecure,
not insist on a more secure SHA-2 that is not there. With DNSSEC,
there is not client-server exchange like with TLS or IPsec. There is
a producer on one end, and a consumer on the other end. The two do not
negotiate crypto parameters.
> == Benefit to Fedora ==
> * 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/
I know that a few people believe that shambles can in theory be abused
with DNSSEC, but a lot of people also believe the constrains of DNS
RRsets make this impossible. But even _if_ it is possible, it would
only affect multiple domains that share the same private key that made
the SHA-1 signature. And then we are talking about RRSIG records and
not, as in this proposal, the DS/CDS RDATA content.
> Patch the enforcer so that bsha1 is not honored anymore:
I don't think fedora should move faster than upstream opendnssec. I
believe the people at the IETF and the software developers of the DNS
software are more aware of where we are in the migration path than
individual Fedora developers.
Thanks a lot for your input. I am withdrawing the change proposal now
as it makes no sense indeed to have Fedora move faster than upstream
on this.
Regards,
François
> > == Upgrade/compatibility impact ==
> > Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone.
>
> The RRSIG signature is not related to the DS signature. Zone resigning
> is something completely different from the DS/CDS records. Those records
> are signed by the parent zone, and use whatever algorithm the parent
> zone uses, which the child zone cannot dictate.
>
> > 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.
>
> The root zone has no DS record, so this statement does not make sense.
> The RRSIG signature algorithm is unrelated to the DS/CDS record RRdata
> that contains a hash of the child's public key, where the hash is created
> with SHA-1 or SHA-2.
>
> > == 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.
>
> So there are two things that really need to be clarified for this
> proposal. Is it talking about DS/CDS signature algorithm as per IANA
> registry http://www.iana.org/assignments/ds-rr-types, or are we talking
> about DNSKEY signature algorithm, that is responsble for signing all
> the zone data, that uses a hash algorithm or SHA-1 or better. Based on
> the description, I am a bit worried that it is not entirely clear what
> the proposed change actually is.
>
> Please feel free to reach out to me directly to talk about this feature
> request.
>
> Paul
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
1034
days inactive
1042
days old
2 comments
3 participants
participants (3)
-
Ben Cotton -
François Cami -
Paul Wouters