-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Several algorithms in DS or DNSKEY RRsets, Zonemaster should warn #344
Comments
From @cdybedahl on February 18, 2015 16:19 This needs to be sorted out at the specification level before any changes are made in the test engine. @pawal, can you move the issue to the zonemaster repo? |
@pawal move it to 2015.4 |
@pawal - need to write a test specification |
Since the specifications are still not there, moving the issues to 2017.1 |
We should probably add a new test case for this. |
Yes, also see #231. |
@matsduf @pawal . Hence, the idea is to reverse https://github.com/dotse/zonemaster/blob/master/docs/specifications/tests/DNSSEC-TP/dnssec07.md and check, if DS is present at parent, there should be DNSKEY as well at child ? |
From @bortzmeyer on February 18, 2015 16:15
Several algorithms in DS or DNSKEY RRsets, and consequences
The problem was noticed on cepn.asso.fr (the configuration changed
since). Some resolvers or DNS checkers complained about its setup,
while other accepted it. What was right?
Setup
The zone had the following DNSKEY RRset:
There are two keys, both with the same algorithm, RSASHA1. The DS
RRset in the parent zone was (signature ommitted):
This time, there are two algorithms, 5 (RSASHA1) for the key 36778 and
8 (RSASHA256) for the 13585 (the list of algorithms is
registered at IANA).
Note that only 36778 is in the zone (a dangling DS, which is legal, and
irrelevant here). Note also that both DS use the same digest type, 2
(SHA256).
Results
Unbound reliably servfails on this setup. DNSviz
indicates errors in the zone
and says "cepn.asso.fr./DNSKEY (alg 5, id 54030): The DS RRset for the
zone included algorithm 8 (RSASHA256), but no RRSIG with algorithm 8
covering the RRset was returned in the
response. (195.68.96.3, 217.70.177.40)"
BIND reliably validates the zone:
And so does Google Public DNS. The zone tester Zonemaster
does not indicate a problem (it
just emits a warning for a signature validity period which is too
long).
Standards
RFC 4035, section 2.2, said "There MUST be an RRSIG for each RRset
using at least one DNSKEY of each algorithm in the zone apex DNSKEY
RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm
appearing in the DS RRset located at the delegating parent (if
any). This is to avoid downgrade attacks, as explained in RFC 5702,
section 8.2.
RFC 6840, section 5.11, clarified that and says "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." The zone violated the first requirment (there was an algorithm
8 in the DS RRset but not in the DNSKEY RRset) but not the second
(there was only algorithm 5 in the DNSKEY RRset).
But the RFC 6840 adds "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,
and they MUST NOT insist that all algorithms signaled in the DNSKEY
RRset work. A validator MAY have a configuration option to perform a
signature completeness test to support troubleshooting."
Analysis
The important point is that the zone was wrong but it does not mean
the resolver should refuse to validate it (the second paragraph in RFC
6840 mentioned above).
So, Unbound was probably too strict here. There was a valid path from
fr to cepn.asso.fr and it should have validate, by using it, since
Unbound knows both algorithms (RSASHA1 and RSASHA256).
For programs which are not validators but zone testers, we expect them
to be picky and to report errors, even if they are not fatal. For
instance, an hypothetical validator which understands only RSASHA256
and not RSASHA1 (not possible with today's DNSSEC rules, where RSASHA1
is mandatory, see RFC 4034, section A.1) would have break with such a
setup. So, Zonemaster missed an opportunity to report the problem.
Thanks
Mark Andrews, Mukund Sivaraman, Yuri Schaeffer, and Casey Deccio, for
explanations.
Copied from original issue: zonemaster/zonemaster-engine#36
The text was updated successfully, but these errors were encountered: