Hi Paul, all, On Tue, Jun 29, 2021 at 1:40 AM Paul Wouters <paul@xxxxxxxxx> 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-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." > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
