The rules are there to ensure that if the resolver see an algorithm it supports then it can validate the response. If you fail to follow the rules answers won’t ALWAYS validate. If there is one level of validation happening the validator should recover by trying other servers. If you have chained validators all bets are off as you can cache a set that the next validator in the chain can’t validate successfully.
The resolver can check that the set of DNSKEY algorithms found in the DS set safely. It was the DNSKEY algorithms that don’t work in a loosely coherent database. There are timing constraints between DS and DNSKEY that allow determination of what the zone is signed with that are impossible to achieve with DNSKEY alone unless you pre publish signatures. -- Mark Andrews > On 4 Jul 2023, at 04:25, Peter Thomassen <[email protected]> wrote: > > Dear DNSOP, > > It's well-known that DNSSEC multi-signer setups are problematic when > providers want to sign with different algorithms. > > In a hypothetical scenario where signing requirements would be relaxed, I > have a very specific question about how resolvers should behave. Apologies > for the length of the message, and thank you for reading it. > > > To lay out the problem fully, here's an appetizer from the spec. RFC 6840 > Section 5.11 says (emphasizing a point from RFC 4035 Section 2.2): > > <quote> > A signed zone MUST include a DNSKEY for each algorithm present in > the zone's DS RRset and expected trust anchors for the zone. The > zone MUST also be signed with each algorithm (though not each key) > present in the DNSKEY RRset. [...] > > This requirement applies to servers, not validators. Validators > SHOULD accept any single valid path. They SHOULD NOT insist that all > algorithms signaled in the DS RRset work, [...] > </quote> > > > The second rule is not contentious. It basically says that validators SHOULD > NOT apply a "logical AND" on algorithms offered by the DS record set; > instead, "logical OR" is encouraged. There was an issue with this in Unbound, > but that's been solved ages ago. (Well,* ...) > > > However, the first rule is incompatible with certain use cases. In > particular, it is not possible to have the same zone served by several > operators, each signing with their own key and choice of algorithm. > > A special case of this is the glitch-free transfer of a domain name from one > DNS provider to another, while retaining DNSSEC validation. During the > transition, a multi-signer phase will be in effect, and if the old and new > provider don't support overlapping sets of algorithms, you'll run into the > aforementioned problem. > > For the sake of argument, let's replace the first rule by something like: > > Independent of the number of signing algorithms appearing in it, the > DS RRset MUST reference at least one DNSKEY that signs theDNSKEY > RRset. Other RRsets MUST be signed with at least one DNSKEY whose > algorithm appears in the DS RRset. > > More casually, "it's sufficient to sign with one algorithm from DS, as long > as it allows for authenticating along some valid path". > > (Note that from the resolver perspective, this is compatible with rule 2, as > long as all announced algorithms are supported.) > > > Next, consider that Red Hat turned off SHA-1-based signing algorithms in Red > Hat Enterprise Linux 9 and related distributions. As this is a system-wide > policy, it affects validation of DNSSEC algorithms 5 and 7 in resolvers. In > response, Unbound [1], Knot Resolver [2] and PowerDNS Recursor [3] all have > implemented ways to detect whether these algorithms work, and disable them if > not supported. > > That works great for zones that use algorithm 5 or 7 *only*: corresponding DS > records will be dropped from consideration, and as nothing is left, the zone > is treated as insure. > > > Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is not an > uncommon transition (ietf.org did it last month, except that they went > unsigned). In such a scenario, a resolver on Red Hat would only consider the > algo 13 DS records. > > Under the relaxed RRSIG presence rule, it would be fine to serve signatures > of *one* algorithm only (either 7 or 13). If only 7 is served, my > understanding is that this would lead to SERVFAIL, because signatures are > missing for the only supported algorithm. There is no valid path. > > This situation looks exactly like a double-algorithm setup where an on-wire > attacker stripped RRSIGs for algorithm 13 so they can mess with the response > (knowing that 7 is not going to get validated). -- This removes all of the > DNSSEC security guarantees, despite of algorithm 13 being advertised in the > DS RRset. > > > Here are the questions: > > 1.) Is SERVFAIL the correct behavior in the above scenario? > > 2.) Does anyone think that "insecure" is the right behavior? ("I can see > another signature of algorithm 7 which I can't validate; it might match, so > I'll pass this.") > > 3.) If anyone thinks that "insecure" is fine: Why should the resolver assume > that things are fine, and that the lack of signature is not an indication of > a downgrade-to-insecure attack? > > 4.) In fact, how would the resolver distinguish this from a > downgrade-to-insecure attack? > > 5.) If the authoritative server can't know what the resolver supports, how > could it ever be safe, by not sending RRSIGs for all algorithms, to introduce > the confusion of question (4)? > > > It is sometimes noted that Rule 1 above (signer requirement) and Rule 2 > (validator requirement) are contradictory. I'd like to point out that the > questions raised here have nothing to do with rule 2: Validators should > accept *any* valid path. This rule stands regardless of whether any > signatures missing or not. > > The issue is whether there's a supported path, and a safe response when a > valid path is lacking although one could expect one based on DS. This is not > about compatibility of the rules (rule 2 is compatible with anything), but > about which signer requirement makes sense. (Does the signer know enough > about the validator to decide which algorithms can be advertised but then > their signatures left off, because another advertised algorithm is surely > supported?) > > > Also note that the algorithms in this example (7 and 13) are both "MUST > implement" on the validator side, RFC 8624 Section 3.1. Some say that "MUST > implement" is different from "MUST support". > > 6.) Is "MUST implement" different from "MUST support"? > - e.g.: "we implemented but don't support usage for some reason" > > 7.) When defining which algorithm(s) to return signatures for, should that > requirement depend on any "MUST implement" requirements for the involved > algorithms? > - If so, why? (Is it practical? See algorithm 7.) > - If not, why not? > > 8.) If a resolver supports one of the algorithms offered via DS, is it > correct that (barring CD flag) it MUST NOT, under any circumstances, return > insecure data? > > Thanks, > Peter > > * Unbound's "harden-algo-downgrade" setting [4] recovers the "logical AND" > behavior. Google reveals a bunch of places using it [5-11], especially on > devices like Raspberry Pi (Pihole etc.). > > [1]: https://github.com/NLnetLabs/unbound/pull/660 > [2]: > https://gitlab.nic.cz/knot/knot-dns/-/commit/b0c6f0709aeab17e6db3dadc85d335848f5d681e > [3]: > https://docs.powerdns.com/recursor/settings.html#dnssec-disabled-algorithms > [4]: > https://nlnetlabs.nl/documentation/unbound/unbound.conf/#harden-algo-downgrade > [5]: https://www.google.com/search?q=%22harden-algo-downgrade:+yes%22 > [6]: https://forums.gentoo.org/viewtopic-p-8563219.html > [7]: > https://www.reddit.com/r/pihole/comments/11gm11r/unbound_doesnt_resolve_technology_tld/ > [8]: > https://forum.manjaro.org/t/pacman-mirrors-fasttrack-adding-slow-or-invalid-entries-to-mirrorlist/75348 > [9]: https://emeraldonion.org/2017/12/03/dns-for-tor.html > [10]: > https://blacklab.net/set-up-pi-hole-as-truly-self-contained-dns-resolver/ > [11]: https://dietpi.com/forum/t/problems-with-unbound/6503 > > -- > https://desec.io/ > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
