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