Re: [DNSOP] Resolver behaviour with multiple trust anchors

[Michael StJohns <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop