On 10/31/2017 5:39 AM, Moritz Muller wrote:
Hi,
Together with my colleagues I have been stumbling upon a, for me, unclear case
when validating trust anchors.
Assuming that a resolver has enabled DNSSEC validation and has the root keys
configured.
Additionally, it has configured manually a trust anchor for a TLD (that has
also published its DS in the root zone).
Now, for example due to a key rollover at the TLD, the manually configured
trust anchor of the TLD does not match the DS in the root anymore.
How should a resolver treat the signatures of this TLD?
The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures of
the TLD as bogus, but we didn't find any specifics in RFC 4034 and 4035 that
describe how resolvers should behave in this case.
Knot resolver treats them as NOERROR (according to the developers).
If we interpret section 4.3 of RFC 4035 then we would have assumed that the
signature must be treated as secure.
Did we miss something, or is there indeed clarification needed?
A couple of things -
Make sure that the subordinate trust anchor is still a trust anchor.
It's possible that RFC5011, section 5 came into play:
Alternately, a trust point that is subordinate to another configured
trust point MAY be deleted by a resolver after 180 days, where such a
subordinate trust point validly chains to a superior trust point.
The decision to delete the subordinate trust anchor is a local
configuration decision. Once the subordinate trust point is deleted,
validation of the subordinate zone is dependent on validating the
chain of trust to the superior trust point
The idea here was to deal with the transition from unsigned root to
signed root, but still allow for situations where the subordinate zone
wanted to ensure it was able to manage its own trust point. This should
have been a bind/unbound/powerdns configuration item but who knows.
But sadly - the language in RFC6840 section 5.10 is controlling...
basically, any implementation can do whatever it wants.
A DNSSEC validator may be configured such that, for a given response,
more than one trust anchor could be used to validate the chain of
trust to the response zone. For example, imagine a validator
configured with trust anchors for "example." and "zone.example."
When the validator is asked to validate a response to
"www.sub.zone.example.", either trust anchor could apply.
When presented with this situation, DNSSEC validators have a choice
of which trust anchor(s) to use. Which to use is a matter of
implementation choice. Appendix C discusses several possible
algorithms.
And once again we see the folly of the words "implementation choice"
when trying to come up with a coherent DNS.
Later, Mike
— Moritz
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
