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
