> 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?
Sometimes. If the validator supports 7 and not 13 and only gets 13. The DS
RRset says that both 7 and 13 are present.
> 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.")
If the validator doesn’t support both 7 and 13.
> 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?
It can’t.
> 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 isn’t.
> 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.
Rule one is about ensuring that the data is produced for the validator.
> 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"
MUST implement is about providing an interoperable path that leads to secure.
An operator is free to no use that path.
> 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?
It must not return unvalidated data. You can support the algorithms but not
have a trust path.
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
