Dear Björn, On Sun, Jun 9, 2024 at 12:39 AM Björn Persson <Bjorn@rombobjörn.se> wrote:
> > == Summary == > > OpenSSL will no longer trust cryptographic signatures using SHA-1 by > > default, starting from Fedora 41. > > 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 > > 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 > > Here's a crappy program that can show some statistics but won't let me > link directly to the relevant table: > > https://stats.dnssec-tools.org/ > > It shows about 140000 SHA-1-signed domains. That's only 6‰ of the signed > domains, but still a rather large absolute number. > I don't think that 140000 of something world-wide (22 mln of DNSSec signed domains) should be considered a large amount. > 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. > I agree that the maintainers of the DNSSec software have to consider the behavior of their software. But it doesn't mean that SHA1 for crypto purposes is of any security. > Will DNSsec validation be skipped whenever an algorithm number for SHA-1 > is encountered? That will make the resolver vulnerable to downgrade > attacks. An attacker can then disable DNSsec by sending manipulated > responses indicating for example RSA/SHA-1 for records that are actually > signed with RSA/SHA-256. > If an attacker can manipulate DNSSec so easily, it means it's completely broken. 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. > Looks reasonable to me. -- Dmitry Belyavskiy
-- _______________________________________________ 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
