On Thu, Apr 14, 2022 at 11:22:43AM +0530, Mukund Sivaraman wrote: > On Thu, Apr 14, 2022 at 10:32:18AM +0530, Shreyas Zare wrote: > > Hi, > > > > Apart from DNSSEC validation, have you also tested DNS servers hosting > > DNSSEC signed zones with NSEC3? This is since NSEC3 only has SHA1 specified > > <https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml> > > and this may cause the DNS server unable to update the zone to create new > > NSEC3 records. This will mean that even if the zone is signed with ECDSA > > algorithms but use NSEC3 then they are going to fail. > > Petr's email seems limited to use of RSASHA-1 and NSEC3RSASHA1 as RRSIG > algorithms, and possibly DS digest type. > > As you point out, SHA-1 is used in NSEC3. It is also used in TSIG > (hmac-sha1), but these are not affected in the same way currently as use > in RRSIG and DS. Removing SHA-1 support completely would be very > disruptive. Even removing support at the OS level for RRSIG and DS seems > extreme - it is better to allow this to be configured in the DNS > implementation. > > NSEC3 uses SHA-1 as a one-way hash function to obfuscate the > corresponding owner name so that a "zone walk" to enumerate all the > names in a zone is not as straightforward as with NSEC, but it does not > rely on cryptographic hash function properties such as second pre-image > resistance, pre-image resistance (back to the original owner name) or
This should say "*except* back to the original owner name". > even collision resistance. So the usage in NSEC3 would not be affected > by the current weaknesses in SHA-1. > > HMAC usage of SHA-1 is also still considered safe and "approved" for use > (e.g., NIST SP 800-57 Part 1 Rev 5 section 5.6.1.2), which is used with > TSIG. > > TKEY still makes use of MD5 - there was a dnsop thread by Mark Andrews > about updating it recently. > > Mukund > > > > > > Regards, > > *Shreyas Zare* > > Technitium <https://technitium.com/> > > > > On 4/13/2022 10:36 PM, Petr Menšík wrote: > > > > > > Hello DNS users, > > > > > > I have already created some bugs to inform some affected software > > > packages. But I would like to notify also here with prepared plan to > > > obsolete SHA-1 in upcoming RHEL 9.0. Final documentation is not yet > > > created for it, but it could be tested already on centos container: > > > > > > docker pull quay.io/centos/centos:stream9 > > > delv command from bind-utils or unbound-host -D from unbound can test > > > it. delv would still fail, because it does not follow crypto-policy > > > configuration which named consumes. > > > > > > I have filled tracker bug for EPEL9 components I know on bug #2073066 > > > [1]. If your software validates DNSSEC signatures, it might start > > > failing on domain names signed with RSASHA1 or NSEC3RSASHA1 algorithms. > > > If you have package validating DNSSEC on EPEL9 which I have not > > > mentioned and it is affected, please create a bug blocking this tracker > > > bug. If have created the bug but is not affected, please close it with > > > NOTABUG. > > > > > > Crypto-policy DEFAULT makes some openssl or gnutls methods to fail, when > > > RSASHA-1 key is used. That includes openssl function EVP_VerifyFinal > > > (used in bind) and EVP_DigestVerifyInit (used in unbound). Because used > > > crypto policy DEFAULT prevents such signature verification, DNSSEC > > > validators may start to return failures on those names. > > > > > > A simple workaround would be switching to crypto policy DEFAULT:SHA1: > > > > > > update-crypto-policies --set DEFAULT:SHA1 > > > > > > I have created list to TLD affected and attached them to the bug [2]. > > > But it includes many more names, such as icann.org, ietf.org or > > > paypal.com. > > > > > > I know it violates still active RFC 8624 [3], but because it is enforced > > > by lower-level API, it is possible just to follow or fail. I think so > > > far every crypto call failure results in bogus result and returns status > > > SERVFAIL on the reply. Would it make sense to create some common cases, > > > where the result would be fallback to insecure reply without AD bit, but > > > no failure? > > > > > > Supported bind and unbound packages will start considering those names > > > as insecure to prevent validation failures. There has been interesting > > > conversation on mattermost Town Square [4] on this topic. Worth noting > > > might be also threads on unbound [5] and Fedora discussion about > > > implementing the same way [6]. > > > > > > Best Regards, > > > > > > Petr > > > > > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=2073066 > > > 2. https://bugzilla.redhat.com/show_bug.cgi?id=2073066#c7 > > > 3. https://datatracker.ietf.org/doc/html/rfc8624#section-3.1 > > > 4. https://chat.dns-oarc.net/community/channels/town-square > > > 5. > > > https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-April/007709.html > > > 6. > > > https://lists.fedoraproject.org/archives/list/[email protected]/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/#W73IMPJVK3DNCRXS5OZXELVWJRDRT6KN > > > > > > -- > > > Petr Menšík > > > Software Engineer > > > Red Hat,http://www.redhat.com/ > > > email:[email protected] > > > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > > > > > _______________________________________________ > > > dns-operations mailing list > > > [email protected] > > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > > > _______________________________________________ > > dns-operations mailing list > > [email protected] > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations Mukund
signature.asc
Description: PGP signature
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
