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

Reply via email to