Hi Björn,
> On 9. Jun 2024, at 00:37, Björn Persson <bj...@xn--rombobjrn-67a.se> wrote: > > Validating DNS resolvers are still required to be able to validate > signatures made with SHA-1. RFC 8624 is still current as far as I can > tell: > > https://www.rfc-editor.org/rfc/rfc8624#section-3.1 > https://www.rfc-editor.org/rfc/rfc8624#section-3.3 That’s correct. There is some movement at the IETF, though. See [1] and thread. I’d also like to specifically point to [2], which I think sums up the discussion nicely. DNSSEC is a holdout, it feels like almost everybody else has moved by now to address the insecurity of SHA-1 in signatures. As you’ll also notice from the thread, there are a few voices that feel like we should not yet deprecate SHA-1 while it has not been completely broken. There have been publications that say that DNSSEC is actually affected today if control over a zone is (even just partially) shared, see [3]. Personally, I don’t believe in waiting until the cat’s out of the bag if it will be in the foreseeable future. I’m quoting Leurent and Peyrin, who wrote the SHA-1 is a Shambles paper [4] in 2020: "Since our attack on SHA-1 has pratical [sic] implications, in order to make sure proper countermeasures have been pushed we will wait for some time before releasing source code that allows to generate SHA-1 chosen-prefix collisions.” [5] I believe hoping that Leurent and Peyrin will continue to sit on their code for another 5 years isn’t a good strategy (remember, the paper is from 2020(!)). I’m hoping the DNSSEC community will realize this soon. [1]: https://mailarchive.ietf.org/arch/msg/dnsop/gp7caSkWA9ureUStNuXtCpGmGss/ [2]: https://mailarchive.ietf.org/arch/msg/dnsop/XopFnthm0nFWrJ_z1tJYUoBwxrU/ [3]: https://blog.apnic.net/2020/01/17/sha-1-chosen-prefix-collisions-and-dnssec/ [4]: https://eprint.iacr.org/2020/014.pdf [5]: https://sha-mbles.github.io/ > There have been reports of SHA-1 disablement causing name resolution > problems. Here's one example: > > https://lists.isc.org/pipermail/bind-users/2023-December/108182.html > > […] > > Before voting on this proposal, Fesco should be informed of what will > happen in Bind, Unbound and SystemD-ResolveD when users try to look up a > domain that is signed with SHA-1. To my knowledge, DNS resolvers in RHEL and their upstreams have been adjusted to handle this, since RHEL 9 shipped with this configuration. Are there DNS resolvers in Fedora that aren’t in RHEL? > Will SHA-1 signatures be treated as invalid signatures, causing the > resolver to return SERVFAIL? That will violate RFC 8624 and make users > scramble for quick workarounds. Many will apply far too big hammers, > such as disabling DNSsec validation entirely or switching their whole > system to the LEGACY policy just to be able to resolve a domain name > signed with SHA-1. In this case it should be announced far and wide how > users can unbreak DNS without weakening the security of the rest of > their system. Otherwise this change could easily do more harm than good. As far as I’m aware, the patches caused DNS resolvers to simply treat those zones as if they were unsigned. > It seems to me that the following would be the best way to distrust > SHA-1 in DNSsec: > > 1: If a valid chain of trust can be established where strong algorithms > are used throughout, then return the records to the client with the AD > bit set, per the standard, indicating that the data are authentic. > > 2: If there should be signatures, but no valid chain of trust can be > established because records are missing or signatures fail to verify, > then assume it's an attack and return SERVFAIL per the standard. > > 3: If one or more valid chains of trust are found, but they all involve > SHA-1 somewhere, then return the records to the client with the AD bit > zeroed, indicating that no attack was detected but the data should not > be trusted any more than an unsigned domain. > > To be able to distinguish between cases 2 and 3, the resolver must > remain able to verify SHA-1 signatures. DNS resolvers can write code to do this. This proposal does not completely remove support for SHA-1 in signatures, it just disables it by default. Non-standard OpenSSL configurations can still verify SHA-1 signatures. Hopefully the DNSSEC community will start discussions on what to do about post-quantum cryptographic signature algorithms soon, otherwise we’ll end up having the same discussion again in 10 years, when TLS and many other common protocols have moved. -- Clemens Lang RHEL Crypto Team Red Hat -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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, report it: https://pagure.io/fedora-infrastructure/new_issue
