KeyTrap fix breaks resolving semi-bogus paste.debian.net/snow-crash.org

[Mark Andrews]

To put more detail on this the DS is *only* used to verify the DNSKEY
RRset.  As long as that returns trusted *every* DNSKEY in that RRset is
valid for verifying the rest of the zone.  There is NO requirement to
look at the DS RRset when verifying anything other than the DNSKEY
RRset.

TA -> DNSKEY -> DS -> DNSKEY -> DS -> DNSKEY -> data

Any of those RRsets can have expired from the cache when data is being
verified.  Only the final DNSKEY RRset is required to be present and
to have been marked as trusted.

Now DNS_R_SIGFUTURE and DNS_R_SIGEXPIRED are detected before any crypto
is performed so it wouldn’t be too expensive to skip to the next RRSIG
on those error codes but really you shouldn’t be publishing broken RRSIGs.

Mark

> On 15 Feb 2024, at 11:25, Mark Andrews <marka at isc.org> wrote:
> 
> Well if you are attacking the resolver by sending invalid RRSIGs ...
> 
>> On 15 Feb 2024, at 11:15, Matt Nordhoff via bind-users <bind-users at lists.isc.org> wrote:
>> 
>> Hello,
>> 
>> I'm not sure if this is a bug or a feature, but the recent CVE fixes
>> prevent resolving paste.debian.net with DNSSEC validation on.
>> 
>> It is a CNAME:
>> 
>> $ dig +short paste.debian.net
>> apu.snow-crash.org.
>> p.snow-crash.org.
>> 148.251.236.38
>> 
>> debian.net is fine, but snow-crash.org is misconfigured: It has an
>> algorithm 13 DS record, is correctly signed with algorithm 13, but is
>> also signed using algorithm 8 with signatures that expired a year
>> ago(!).
>> 
>> <https://dnsviz.net/d/paste.debian.net/ZczXYw/dnssec/>
>> 
>> Other resolvers, and older versions of BIND, ignore the bad/irrelevant
>> signatures and can still resolve the zone.
>> 
>> With the recent CVE fixes, BIND sees the expired RRSIGs, decides it's
>> bogus, logs the below, and returns SERVFAIL. I imagine it hits
>> max-validation-failures-per-fetch or some internal limit.
>> 
>> named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to
>> bad signature (keyid=41523): RRSIG has expired
>> named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found
>> named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN':
>> 37.120.176.165#53
>> named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to
>> bad signature (keyid=41523): RRSIG has expired
>> named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found
>> named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN':
>> 148.251.236.38#53
>> named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to
>> bad signature (keyid=41523): RRSIG has expired
>> named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found
>> named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN':
>> 2a01:4f8:201:3437::2#53
>> 
>> snow-crash.org is clearly misconfigured, but resolvers usually succeed
>> when they encounter both valid and invalid DNSSEC signatures. And this
>> domain has no algorithm 8 DS records at all, so the signatures and
>> keys can be ignored entirely.
>> 
>> Regarding DoS attacks, a resolver can ignore signatures that are
>> expired or use algorithms not included in the DS record without any
>> expensive cryptography.
> 
> But that requires actually having the DS RRset at the time of the
> verification of the RRset/RRSIG.
> 
>> I'm not necessarily saying this is a bug, but it might be an
>> interesting data point regarding the experimental new limits, and you
>> might want to consider changing the default or the accounting.
>> 
>> I noticed the issue using Quad9's 9.9.9.11 DNS resolver, and then
>> reproduced it on an Ubuntu 23.10 (amd64) VM by installing Ubuntu's
>> bind9 1:9.18.18-0ubuntu2 package with the default configuration and
>> then upgrading it to 1:9.18.18-0ubuntu2.1.
>> 
>> Some copy-and-pasted information at
>> <https://gist.github.com/mnordhoff/9286a264633fc12a262213a8d389f517>.
>> (Since I couldn't use <https://paste.debian.net/>...)
>> 
>> (I also did/will tell Quad9 about it for their information.)
>> 
>> Cheers,
>> -- 
>> Matt Nordhoff
>> -- 
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
> 
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org